JP2023508171A - リアルタイムアプリケーション - Google Patents

Abstract

無線ローカルエリアネットワーク（ＷＬＡＮ）で使用されるＯＳＩモデルにおける相互作用通信の媒体アクセス制御（ＭＡＣ）層とアプリケーション（ＡＰＰ）層との間のリアルタイムアプリケーション（ＲＴＡ）インターフェイス。このＭＡＣ層とＡＰＰ層との間のインターフェイスをＲＴＡパケットのために利用できる一方で、非ＲＴＡパケットは依然として通常のＯＳＩモデルを使用することができる。新たなＲＴＡセッションを初期化する際に、ＡＰＰ層がＭＡＣ層に一連の要件を伝える。ＭＡＣ層はチャネルをモニタし、主要性能指標（ＫＰＩ）を測定し、要求を受け入れ又は拒絶する。このＡＰＰ層とＭＡＣ層との間の相互運用性は、ＲＴＡパケット遅延時間を低減する能力を高めるとともに他の利点ももたらす。
【選択図】図１９

Description

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

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

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

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

本開示の技術は、一般に無線ネットワーク通信に関し、具体的には、無線通信装置プロトコルの媒体アクセス制御（ＭＡＣ）層とアプリケーション層との間に特定のリアルタイムアプリケーション（ＲＴＡ）インターフェイスを実装することに関する。

オープンシステム相互接続（ＯＳＩ）モデルを使用するＩＥＥＥ８０２．１１プロトコルなどの現在の無線技術は低遅延能力を提供しない。しかしながら、リアルタイムアプリケーション（ＲＴＡ）などの幅広い用途は低遅延を必要とする。

ＲＴＡは低遅延通信を必要とし、最善努力型通信を使用する。ＲＴＡから生成されるデータはＲＴＡトラフィックと呼ばれ、送信側局（ＳＴＡ）においてＲＴＡパケットとしてパケット化される。これとは逆に、非時間依存アプリケーションから生成されるデータは、本明細書では非ＲＴＡトラフィックと呼ばれ、送信側ＳＴＡにおいて非ＲＴＡパケットとしてパケット化される。

ＲＴＡパケットは、パケット配信に関する高適時性要件に起因して低遅延を必要とする。ＲＴＡパケットは、一定期間内に配信される場合にのみ有効である。この要件を達成するために、ＯＳＩモデル、及びネットワーク層間の相互作用通信では新たな通信機能が必要である。

ＯＳＩは、国際標準化機構（ＩＯＳ）によって規定された、標準的な通信プロトコルを使用して様々なコンピュータシステム間の遠隔通信を確立するための概念モデルである。通常、ＯＳＩは、アプリケーション（ＡＰＰ）層、プレゼンテーション層、セッション層、トランスポート層、ネットワーク層、データリンク層及び物理層という７つの層から成る。これらの層は、様々な形態の通信において利用される機能の定義及び標準化のために使用される。２つのシステムが同じ層において同じ通信プロトコルを共有している場合、これらのシステムは互いに情報を交換することができる。

通信が発生すると、各層は、その上位層にサービスを提供して下位層にサービスを要求する。従って、ＯＳＩモデルにおけるネットワーク層間の相互作用通信は、これらのサービスを可能にするために利用される。

ＩＥＥＥ８０２．１１プロトコルは、データリンク（すなわち、ＭＡＣ）層及び物理（すなわち、ＰＨＹ）層における標準的な通信プロトコルを規定している。現在の８０２．１１プロトコルは、無線ネットワークのスループット性能を取得することにのみ焦点を当てている。一方で、無線ネットワークの遅延時間性能は考慮されておらず、ＲＴＡにとってはこれが問題である。ネットワークがＲＴＡパケットを送信する場合、通常、これらのパケットは一定期間のみにわたって有効であり、ＡＰＰ層及びＭＡＣ層は、この時間内に相互作用通信を確立してトラフィック送信の制御及びモニタリングを行う必要があり、従ってパケット遅延時間の制御手段が必要である。

既存の技術はＲＴＡパケットの適時性要件を満たしておらず、ＲＴＡパケットの送信遅延時間を最小化することに向けられたものではない。

従って、ＷＬＡＮシステムにおけるＲＴＡパケットトラフィックの遅延時間制御を強化するというニーズが存在する。本開示は、このニーズを満たすとともに、これまでの技術を凌駕するさらなる利点をもたらすものである。

ＩＥＥＥ８０２．１１の現在の無線通信システムは、ＲＴＡパケットと非ＲＴＡパケットとを識別しない。全てのパケットが同じＯＳＩモデルを使用する。ＩＥＥＥ８０２．１１の現在のＯＳＩモデルは、ＲＴＡパケットのための低遅延通信機能を特性化又は標準化していない。現時点で、ＩＥＥＥ８０２.１１標準は、ＲＴＡパケットが受ける遅延時間の制御に対処していない。現在のＩＥＥＥ８０２．１１プロトコルは、これらの機能の欠如によってＲＴＡパケットの低遅延要件を満たすことができていない。

本開示では、ＲＴＡトラフィックの低遅延要件を満たすために、ＲＴＡパケットを区別することについて説明し、ＯＳＩモデルにおける相互作用通信の一部である媒体アクセス制御（ＭＡＣ）層とアプリケーション（ＡＰＰ）層との間の有益なＲＴＡインターフェイスを提供する。

ＭＡＣ層とＡＰＰ層との間にＲＴＡインターフェイスを構築するタスクは、ネットワーク上にＲＴＡトラフィックと非ＲＴＡトラフィックとが共存することによって難易度が増す。このプロセスの課題は、（ａ）ＲＴＡパケットと非ＲＴＡパケットとを識別して区別すること、（ｂ）ＲＴＡパケットの低遅延要件をサポートする、ネットワーク層間の新たな相互作用通信を設計すること、及び（ｃ）ＲＴＡパケットが新たな相互作用通信を使用して低遅延サービスを取得する一方で、非ＲＴＡパケットが既存の相互作用通信を利用して高スループットサービスの恩恵を受けることを可能にすること、として要約することができる。

ＭＡＣ層とＡＰＰ層との間のＲＴＡインターフェイスは、ＲＴＡトラフィックの時間的有効性を考慮し、ＲＴＡ及び非ＲＴＡが無線ネットワーク内で共存する相互作用通信による低遅延サービスの可能性を提供することを目的とする。

ＭＡＣ層又はＰＨＹ層では、低遅延通信の複数の機能を特性化又は標準化することができる。ＩＥＥＥ８０２．１１のＯＳＩモデル内でこれらの機能を可能にするには、ＯＳＩモデルのネットワーク層間の新たな相互作用通信が必要である。

ＲＴＡトラフィックは、主に送信機のＡＰＰ層においてトラフィックが生成された時点から受信機のＡＰＰ層においてトラフィックが受け取られるまでの時間であるエンドツーエンド遅延時間に関連する。従って、ＲＴＡトラフィックのためにＭＡＣ層機能を制御してモニタする何らかの能力をＡＰＰ層に持たせることが有益である。

本開示では、ＲＴＡパケットのためのＯＳＩモデル内の相互作用通信の一部としてのＭＡＣ層とＡＰＰ層との間のＲＴＡインターフェイスを教示するが、非ＲＴＡパケットは依然として通常のＯＳＩモデルを使用することができる。本開示は、ＩＥＥＥ８０２．１１に適用することができ、さらに好ましくはＩＥＥＥ８０２．１１ｂｅ及びそれ以降に適用することができる。

ＭＡＣ層とＡＰＰ層との間のＲＴＡインターフェイスは、ＡＰＰ層がＭＡＣ層におけるＲＴＡセッションを管理することを可能にする。多くの場合、ＲＴＡは、接続型通信の形で定期的にトラフィックを生成する。アプリケーションによって確立されるＳＴＡ間のＲＴＡ接続型通信は、ＲＴＡセッションと呼ばれる。局（ＳＴＡ）は、ネットワーク内に複数のＲＴＡセッションを有することができる。ＡＰＰは、開示するＭＡＣ層とＡＰＰ層との間のインターフェイスを使用することによって、これらのＲＴＡセッションを適正に管理することができる。

ＭＡＣ層とＡＰＰ層との間のＲＴＡインターフェイスは、ＡＰＰ層がＭＡＣ層におけるＲＴＡ待ち行列を管理することを可能にする。ＡＰＰ層は、ＲＴＡインターフェイスを通じて、ＲＴＡ待ち行列のパラメータを設定するためのコマンドを送信することができる。このインターフェイスは、ＭＡＣ層がＡＰＰ層にＲＴＡ待ち行列の状態を報告することも可能にする。

ＭＡＣ層とＡＰＰ層との間のＲＴＡインターフェイスは、ＡＰＰ層がＭＡＣ層及びＰＨＹ層におけるＲＴＡ主要性能指標（ＲＴＡ Ｋｅｙ Ｐｅｒｆｏｒｍａｎｃｅ Ｉｎｄｉｃａｔｏｒｓ：ＫＰＩ）を測定することを可能にする。ＡＰＰ層は、ＭＡＣ層にＲＴＡ ＫＰＩ測定要求を送信し、ＭＡＣ層は、ＲＴＡインターフェイスを通じてＡＰＰ層にＫＰＩ測定結果を報告する。

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

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

キャリア検知多重アクセス／衝突回避（ＣＳＭＡ／ＣＡ）における従来の競合ベースチャネルアクセスのフロー図である。 ＲｅａｄｙＴｏＳｅｎｄ（送信要求）／ＣｌｅａｒＴｏＳｅｎｄ（送信可）（ＲＴＳ／ＣＴＳ）が使用できない時のＣＳＭＡ／ＣＡにおけるパケット送信を示すシグナリング図である。 拡張分散チャネルアクセス（Ｅｎｈａｎｃｅｄ Ｄｉｓｔｒｉｂｕｔｅｄ Ｃｈａｎｎｅｌ Ａｃｃｅｓｓ、ＥＤＣＡ）待ち行列システムのデータフロー図である。 本開示の少なくとも１つの実施形態に従って利用される無線ｍｍＷ通信局ハードウェアのブロック図である。 本開示のトポロジ例として使用される、２つのＡＰを有する小規模ＷＬＡＮネットワークのネットワークトポロジ図である。 本開示の少なくとも１つの実施形態による、オープンシステム相互接続（ＯＳＩ）モデル内のＲＴＡ及び非ＲＴＡトラフィック通信の階層的通信図である。 本開示の少なくとも１つの実施形態による、ＲＴＡトラフィック通信の事前ネゴシエーションを示す階層的通信図である。 本開示の少なくとも１つの実施形態による、送信側においてＲＴＡパケットを識別するフロー図である。 本開示の少なくとも１つの実施形態による、ＲＴＡセッション識別内のフィールドのデータフィールド図である。 本開示の少なくとも１つの実施形態による、ＡＰＰ層とＭＡＣ層との間のヘッダ情報交換を示す階層的通信図である。 本開示の少なくとも１つの実施形態による、受信側においてＲＴＡパケットを識別するフロー図である。 本開示の少なくとも１つの実施形態による、ＲＴＡ管理の相互作用モデルである。 本開示の少なくとも１つの実施形態による、ＲＴＡ管理の層管理モデルである。 本開示の少なくとも１つの実施形態による、ＲＴＡセッション情報フィールドを示すデータフィールド図である。 本開示の少なくとも１つの実施形態に従って実行されるＲＴＡセッション開始の通信シーケンス図である。 本開示の少なくとも１つの実施形態に従って実行されるＲＴＡセッション開始の通信シーケンス図である。 本開示の少なくとも１つの実施形態に従って実行されるＲＴＡセッション開始の通信シーケンス図である。 本開示の少なくとも１つの実施形態による、ＲＴＡセッション開始要求フレームフォーマットのデータフィールド図である。 本開示の少なくとも１つの実施形態による、ＲＴＡセッション開始応答フレームフォーマットのデータフィールド図である。 本開示の少なくとも１つの実施形態に従って実行されるＲＴＡセッション開始の代替手順の通信シーケンス図である。 本開示の少なくとも１つの実施形態に従って実行されるＲＴＡセッション開始の代替手順の通信シーケンス図である。 本開示の少なくとも１つの実施形態に従って実行される、ＲＴＡセッション開始が発信局（ＳＴＡ）によって拒絶される通信シーケンス図である。 本開示の少なくとも１つの実施形態に従って実行される、ＲＴＡセッション開始が受信局（ＳＴＡ）のＡＰＰ層によって拒絶される通信シーケンス図である。 本開示の少なくとも１つの実施形態に従って実行される、ＲＴＡセッション開始が受信局（ＳＴＡ）のＡＰＰ層によって拒絶される通信シーケンス図である。 本開示の少なくとも１つの実施形態に従って実行される、ＲＴＡセッション再開を例示する手順の通信シーケンス図である。 本開示の少なくとも１つの実施形態に従って実行される、ＲＴＡセッション再開を例示する手順の通信シーケンス図である。 本開示の少なくとも１つの実施形態に従って実行される、ＲＴＡセッション破棄を例示する手順の通信シーケンス図である。 本開示の少なくとも１つの実施形態による、ＲＴＡセッション破棄要求フレームフォーマットのデータフィールド図である。 本開示の少なくとも１つの実施形態による、ＲＴＡセッション告知を例示する手順の通信シーケンス図である。 本開示の少なくとも１つの実施形態による、ＲＴＡセッション告知フレームフォーマットのデータフィールド図である。 本開示の少なくとも１つの実施形態による、ＲＴＡ待ち行列パラメータ設定を例示する通信シーケンス図である。 本開示の少なくとも１つの実施形態による、ＲＴＡ待ち行列パラメータ設定を例示する通信シーケンス図である。 本開示の少なくとも１つの実施形態による、ＲＴＡ待ち行列パラメータ設定要求フレームのデータフィールド図である。 本開示の少なくとも１つの実施形態による、ＲＴＡ待ち行列パラメータ設定応答フレームのデータフィールド図である。 本開示の少なくとも１つの実施形態による、異なる重要度指標による待ち行列内のＲＴＡパケットの並べ替えを例示する待ち行列図である。 本開示の少なくとも１つの実施形態による、異なる待ち行列に対するチャネル時間の割り当てを例示する送信シーケンス図である。 本開示の少なくとも１つの実施形態に従って実行される、ＲＴＡ主要性能指標（ＫＰＩ）測定プロセスを例示する通信シーケンス図である。 本開示の少なくとも１つの実施形態による、ＲＴＡ主要性能指標（ＫＰＩ）測定要求フレームフォーマットのデータフィールド図である。 本開示の少なくとも１つの実施形態による、ＲＴＡ主要性能指標（ＫＰＩ）測定報告フレームフォーマットのデータフィールド図である。 本開示の少なくとも１つの実施形態による、チャネル帯域幅測定のためのＲＴＡ主要性能指標（ＫＰＩ）測定方法フィールドフォーマットのデータフィールド図である。 本開示の少なくとも１つの実施形態による、チャネル帯域幅測定のためのＲＴＡ ＫＰＩ主要性能指標（ＫＰＩ）測定報告フィールドフォーマットのデータフィールド図である。 本開示の少なくとも１つの実施形態によるチャネル帯域幅測定のフロー図である。 本開示の少なくとも１つの実施形態によるチャネル帯域幅測定のフロー図である。 本開示の少なくとも１つの実施形態による、パケット遅延時間のためのＲＴＡ ＫＰＩ測定方法フィールドフォーマットのデータフィールド図である。 本開示の少なくとも１つの実施形態による、パケット遅延時間のためのＲＴＡ ＫＰＩ測定報告フィールドフォーマットのデータフィールド図である。 本開示の少なくとも１つの実施形態によるパケット遅延時間測定手順のフロー図である。 本開示の少なくとも１つの実施形態によるパケット遅延時間測定手順のフロー図である。 本開示の少なくとも１つの実施形態による、チャネル使用量のためのＲＴＡ ＫＰＩ測定方法フィールドフォーマットのデータフィールド図である。 本開示の少なくとも１つの実施形態による、チャネル使用量測定のためのＲＴＡ ＫＰＩ測定報告フィールドフォーマットのデータフィールド図である。 本開示の少なくとも１つの実施形態によるチャネル使用量測定手順のフロー図である。 本開示の少なくとも１つの実施形態による、待ち行列状態測定のためのＲＴＡ ＫＰＩ測定方法フィールドフォーマットのデータフィールド図である。 本開示の少なくとも１つの実施形態による、待ち行列状態測定のためのＲＴＡ ＫＰＩ測定報告フィールドフォーマットのデータフィールド図である。 本開示の少なくとも１つの実施形態による待ち行列状態測定手順のフロー図である。 本開示の少なくとも１つの実施形態による、トラフィック分析のためのＲＴＡ ＫＰＩ測定方法フィールドフォーマットのデータフィールド図である。 本開示の少なくとも１つの実施形態による、トラフィック分析のためのＲＴＡ ＫＰＩ測定報告フィールドフォーマットのデータフィールド図である。 本開示の少なくとも１つの実施形態によるトラフィック分析手順のフロー図である。 本開示の少なくとも１つの実施形態による、測定結果をマルチリンク送信に使用する例を示す通信リンク図である。

１．８０２．１１ ＷＬＡＮシステム概論
１．１．ＣＳＭＡ／ＣＡ動作
図１に、キャリア検知多重アクセス／衝突回避（ＣＳＭＡ／ＣＡ）を使用して局（ＳＴＡ）がパケット送信及び再送のためにチャネルにランダムにアクセスすることを可能にする、ＩＥＥＥ８０２．１１に基づくＷＬＡＮシステムの詳細を示す。ＣＳＭＡ／ＣＡシステムでは、送信すべきデータが存在する場合、ＳＴＡが送信のためのチャネルを検知する。ＳＴＡは、各送信及び再送前にチャネルを検知し、チャネルアクセスを求めて競合するためにバックオフ時間を設定（待機）しなければならない。

バックオフ時間は、ゼロと競合ウィンドウ（ＣＷ）のサイズ（継続時間）との間の一様なランダム変数によって決定される。ＳＴＡは、バックオフ時間にわたって待機し、チャネルがアイドルであることを検知した後に、チャネル占有を確実にするためにＲＴＳフレームを送信すべきであるか否かを決定する。ＳＴＡは、ＲＴＳフレームを送信した場合にはＣＴＳフレームを受け取った時点でチャネル占有が確実になり、この時点でパケットを送信する。ＳＴＡは、ＲＴＳフレームを送信しない場合には直接パケットを送信できることもある。ＲＴＳフレームの送信後にＣＴＳフレームが受け取られなかった場合、或いはタイムアウト前にＳＴＡがＡＣＫを受け取らなかった場合には再送が必要である。一方で、ＣＴＳフレームを受け取った場合、送信は成功である。再送が必要である場合、ＳＴＡはパケットの再送回数をチェックし、再送回数が再試行制限を上回る場合にはパケットが廃棄されて再送はスケジュールされず、そうでなければ再送がスケジュールされる。再送がスケジュールされる場合には、再送のためのチャネルアクセスを求めて競合するために別のバックオフ時間が必要になる。競合ウィンドウのサイズが上限に達していない場合、ＳＴＡは競合ウィンドウのサイズを増やす。ＳＴＡは、新たな競合ウィンドウのサイズに応じて別のバックオフ時間を設定し、再送のためのバックオフ時間にわたって待機し、このプロセスが続く。

図２に、ＲＴＳ／ＣＴＳが使用できない場合のＣＳＭＡ／ＣＡにおける発信局と受信局との間のランダムチャネルアクセスの例を示す。送信側ＳＴＡのＭＡＣ層は、その上位層からデータを受け取ると、チャネルアクセス権を獲得するために競合する。送信側ＳＴＡは、チャネルを求めて競合する際に、競合ウィンドウのサイズがｎスロット（ＣＷ＝ｎスロット）であってバックオフ中にゼロまでカウントダウンするバックオフ時間まで待つ必要がある。このカウントダウンプロセスは、そのチャネルを介して他のパケット送信が発生している時には中断される（すなわち、クリアチャネル評価（ＣＣＡ）が使用中を示す）。送信側ＳＴＡは、データを送信するためのチャネルアクセス権を獲得した後に、このデータをパケットにパケット化し、チャネルを介してパケットを送信する。図示のように、初期パケット送信に失敗した場合にはパケットの再送が必要である。送信側ＳＴＡは、チャネルアクセスを求めて競合するために別のバックオフ時間を設定する。今回は、これが再送であるため、競合ウィンドウのサイズが２倍の２＊ｎスロット（ＣＷ＝２＊ｎスロット）である。この競合ウィンドウサイズによって予想バックオフ時間も２倍になる。バックオフ時間が長くなると、別のパケット送信によってカウントダウンプロセスが中断される（すなわち、ＣＣＡ使用中の）可能性も高まる。この図には、最初に送信に失敗した後にチャネルを求めて３回競合し、最終的に第１の再送を実行してＡＣＫを受け取った時に成功する様子を示す。

この図には、ＳＩＦＳ、ＤＩＦＳ及びＡＣＫタイムアウトを含むタイミングも示す。この図のＧ１は、無線装置がフレームを受け取ってからフレームに応答するまでの間に必要とする時間間隔であるショートフレーム間隔（ＳＩＦＳ）を表す。分散協調機能（ＤＣＦ）プロトコルは物理媒体へのアクセスを制御し、局は送信前に無線媒体の状態を検知しなければならない。ＤＣＦフレーム間隔（ＤＩＦＳ）期間にわたって媒体が継続的にアイドルであることが分かった場合、局はフレームを送信することができる。ＤＩＦＳ間隔中にチャネルが使用中であることが分かった場合、局は送信を保留すべきである。この図には、ＤＩＦＳをＧ２として表す。なお、従来のＤＩＦＳは、ＤＩＦＳ＝ＳＩＦＳ＋（２＊スロット時間）として計算される。Ｇ３は、送信の確認応答を受け取ることが認められる時間であるＡＣＫタイムアウト間隔を表し、これを過ぎると送信エラーが発生したと想定される。

１．２．ＥＤＣＡ待ち行列システム
図３に、ＷＬＡＮ拡張分散チャネルアクセス（Ｅｎｈａｎｃｅｄ Ｄｉｓｔｒｉｂｕｔｅｄ Ｃｈａｎｎｅｌ Ａｃｃｅｓｓ：ＥＤＣＡ）待ち行列システムを示す。ＷＬＡＮシステムでは、ＩＥＥＥ８０２．１１はＥＤＣＡプロトコルを使用して、それぞれがトラフィックの異なる優先度を表す異なるアクセスカテゴリ（ＡＣ）にパケットを分類する。ＳＴＡは、全てのパケットを異なるＡＣにマッピングし、これらをＡＣに関する独立した待ち行列に入れ込む。

この図には、ＥＤＣＡプロトコルを使用する待ち行列システムの参照実装モデルを示しており、ここでは左から右へと優先度が低下する音声（ＶＯ）、ビデオ（ＶＩ）、最善努力（ＢＥ）及びバックグラウンド（ＢＫ）などの４つのＡＣが見られる。各ＡＣは、パケット送信順を管理するために独立した待ち行列を有する。各待ち行列は、ＣＳＭＡ／ＣＡに基づくランダムチャネルアクセス機構に依拠してチャネルアクセス権を獲得する。チャネルアクセス権を獲得するためのバックオフ時間は、ＡＣのトラフィック優先度に応じて待ち行列毎に異なる。ＡＣのトラフィック優先度が高い場合、そのＡＣの待ち行列の平均バックオフ時間は短くなる。従って、優先度の高いＡＣの待ち行列内のパケットは、優先度の低いＡＣの待ち行列内のパケットよりも早くチャネルアクセス権を獲得する確率が高くなる。

２．課題の記述
ＩＥＥＥ８０２.１１の現在の無線通信システムは、ＲＴＡパケットと非ＲＴＡパケットとの識別及び区別を行わず、全てのパケットは同じ従来のＯＳＩモデルに従って処理され、ＲＴＡパケットの遅延時間問題に特に対処していなかった。ＩＥＥＥ８０２.１１の現在のＯＳＩモデルは、現時点でＲＴＡパケットのための低遅延通信機能を特性化又は標準化していない。これらの機能の欠如は、現在のＩＥＥＥ８０２.１１プロトコルがＲＴＡパケットの低遅延要件を満たすことができないことを意味する。

３．本発明の寄与
低遅延通信をサポートするために、本明細書では、ＭＡＣ層又はＰＨＹ層において特性化又は標準化される複数の機能について説明する。ＩＥＥＥ８０２．１１のＯＳＩモデルにおいてこれらの機能を可能にするには、ＯＳＩモデルのネットワーク層間の相互作用通信モデルの変更が必要である。

ＲＴＡトラフィックでは、送信機のＡＰＰ層においてトラフィックが生成された時点から受信機のＡＰＰ層においてトラフィックが受け取られるまでの時間であるエンドツーエンド遅延時間が非常に重要な因子である。従って、ＲＴＡトラフィックのためにＭＡＣ層機能を制御してモニタする何らかの能力をＡＰＰ層に持たせることが有益である。

本開示では、ＲＴＡパケットのためのＯＳＩモデル内の相互作用通信の一部としてのＭＡＣ層とＡＰＰ層との間のＲＴＡインターフェイスについて説明するが、非ＲＴＡパケットは依然として従来の（通常の）ＯＳＩモデルの要素に依拠することができる。

ＭＡＣ層とＡＰＰ層との間のＲＴＡインターフェイスは、ＡＰＰ層がＭＡＣ層におけるＲＴＡセッションを管理することを可能にする。多くの場合、ＲＴＡは、接続型通信の形態として定期的にトラフィックを生成する。ＳＴＡ間のアプリケーションによって確立されるＲＴＡ接続型通信はＲＴＡセッションと呼ばれる。ＳＴＡは、ネットワーク内に複数のＲＴＡセッションを有することができる。ＡＰＰは、開示するＭＡＣ層とＡＰＰ層との間のインターフェイスを使用することによって、これらのＲＴＡセッションを適正に管理することができる。

ＭＡＣ層とＡＰＰ層との間のＲＴＡインターフェイスは、ＡＰＰ層がＭＡＣ層におけるＲＴＡ待ち行列を管理することを可能にする。ＡＰＰ層は、ＲＴＡインターフェイスを通じて、ＲＴＡ待ち行列のパラメータを設定するためのコマンドを送信することができる。このインターフェイスは、ＭＡＣ層がＡＰＰ層にＲＴＡ待ち行列の状態を報告することも可能にする。

ＭＡＣ層とＡＰＰ層との間のＲＴＡインターフェイスは、ＡＰＰ層がＭＡＣ層及びＰＨＹ層におけるＲＴＡ主要性能指標（ＫＰＩ）を測定することを可能にする。ＡＰＰ層は、ＭＡＣ層にＲＴＡ ＫＰＩ測定要求を送信し、ＭＡＣ層は、ＲＴＡインターフェイスを通じてＡＰＰ層にＫＰＩ測定結果を報告する。

４．ハードウェアの実施形態
４．１．局（ＳＴＡ）ハードウェア構成
図４に、本開示によるＷＬＡＮ局の実施形態例１０を示す。この図には、少なくとも１つのコンピュータプロセッサ（ＣＰＵ）１８と、メモリ（ＲＡＭ）２０と、少なくとも１つのモデム２２とに接続されたバス１６を有する回路ブロック１２内へのＩ／Ｏ経路１４を示す。バス１４は、センサ及びアクチュエータなどの様々な装置をＣＰＵに接続することができる。プロセッサ１８上では、ＳＴＡがアクセスポイント（ＡＰ）局又は通常の局（ＳＴＡ）の機能を実行できるように通信プロトコルを実装するプログラムを実行するための、メモリ２０からの命令が実行される。また、このプログラミングは、現在の通信状況でどのような役割を果たしているかに応じて異なるモード（ソース、中間、宛先、第１のＡＰ、他のＡＰ、第１のＡＰに関連する局、他のＡＰに関連する局、調整機（ｃｏｏｒｄｉｎａｔｏｒ）、被調整機（ｃｏｏｒｄｉｎａｔｅｅ）など）で動作するように構成されると理解されたい。

この図示のホストマシンは、少なくとも１つのモデム及びＲＦ回路を含むように構成される。限定ではなく一例として、ｍｍＷモデム２２は、複数のアンテナ２６ａ、２６ｂ、２６ｃ～２６ｎ（例えば、アンテナアレイ）に接続して近隣ＳＴＡとの間でフレームを送受信する少なくとも１つの無線周波数（ＲＦ）回路２４に結合される。プロセッサ、モデム及びＲＦ回路の組み合わせは、ビームフォーミングされた（指向性）通信のサポート、及びアンテナアレイからの準全方向（本明細書では単純に全方向と呼ぶ）モード送信のサポートを可能にする。また、少なくとも１つの好ましい実施形態では、選択方向（セクタ）を遮蔽し、従って局間の干渉を抑えるために、アンテナアレイによって生成される指向性パターンでヌルを生成することもできる。この例には、全方向性ＲＦ回路２８及びアンテナ２９に結合されたモデム２２も示す。

従って、図示のＳＴＡ ＨＷは、少なくとも１つの帯域上での通信を提供するために少なくとも１つのモデム及び関連するＲＦ回路で構成される。限定ではなく一例として、対象の指向性通信帯は、ｍｍＷ帯でデータを送受信するためにｍｍＷ帯モデム及びその関連するＲＦ回路で実現される。いくつかの実装では、限定ではなく一例としてｓｕｂ－６ＧＨｚ帯でデータを送受信するためにｓｕｂ－６ＧＨｚモデム及びその関連するＲＦ回路を含むことができる、一般に発見帯と呼ばれる別の帯域をハードウェアにおいてサポートすることもできる。

なお、本開示は、それぞれがいずれかの任意の数のＲＦ回路に結合された複数のモデム２２で構成することができると理解されたい。一般に、使用するＲＦ回路の数が多ければ多いほど、アンテナビーム方向のカバレッジが広くなる。なお、利用するＲＦ回路の数及びアンテナの数は、特定の装置のハードウェア制約によって決まると理解されたい。ＲＦ回路及びアンテナの中には、ＳＴＡが近隣ＳＴＡと通信する必要がないと判断した時に無効にできるものもある。少なくとも１つの実施形態では、ＲＦ回路が周波数変換器及びアレイアンテナコントローラなどを含み、送受信のためにビームフォーミングを実行するように制御される複数のアンテナに接続される。このように、ＳＴＡは、各ビームパターン方向がアンテナセクタとみなされる複数のビームパターンの組を使用して信号を送信することができる。

４．２．例示的なトポロジ
図５に、提案する技術の動作を説明するためのネットワークシナリオ実施形態例５０を示す。なお、本開示は、２つよりも多くのＡＰを含む大規模ネットワークのシナリオ、いずれかの所望の数のＳＴＡのシナリオ、いずれかの相対的な向きのＳＴＡ及びＡＰのシナリオ、並びにいずれかの任意の又は固定されたブロードキャストエリアの境界を有するシナリオにおいて利用することもできるので、この特定のシナリオに限定されるものではないと理解されたい。このシナリオ例には、室内又はローカルエリア６８内の２つのベーシックサービスセット（ＢＳＳ）内のＳＴＡ０（ＡＰ）５２、ＳＴＡ５（ＡＰ）６２、及び他の６つのＳＴＡ（ＳＴＡ１ ５４、ＳＴＡ２ ５６、ＳＴＡ３ ５８、ＳＴＡ４ ６０、ＳＴＡ６ ６４、及びＳＴＡ７ ６６）を示す。なお、ベーシックサービスセット（ＢＳＳ）は、ネットワーク内のＡＰと正常に同期した一連の局（ＳＴＡ）から成る。各ＳＴＡは、同じＢＳＳ内の他のＳＴＡと通信することができる。全てのＳＴＡは、非ＲＴＡパケットのためのランダムチャネルアクセスにＣＳＭＡ／ＣＡを使用する。ＳＴＡの位置及びその伝送リンクは図示の通りである。

４．３．局（ＳＴＡ）層モデル
本開示は、無線通信システム内のパケットをＲＴＡパケット又は非ＲＴＡパケットのいずれかとして分類する。ＲＴＡパケットは、本開示をパケット送信に使用するのに対し、非ＲＴＡパケットは、通常のＩＥＥＥ８０２．１１ ＣＳＭＡ／ＣＡスキームを使用することができる。この目的のために、ＳＴＡは、ＭＡＣ層においてＲＴＡパケットと非ＲＴＡパケットとを識別する。

図６に、ＯＳＩモデルにおけるＲＴＡ及び非ＲＴＡトラフィック通信の実施形態例７０を示す。本節では、トラフィック通信のためのＳＴＡ階層モデルについて説明する。この例に示すように、ＳＴＡ１ ７２及びＳＴＡ２ ７４という２つのＳＴＡは、ＲＴＡトラフィック及び非ＲＴＡトラフィック８０、８２を生成し、互いにＲＴＡパケット８４及び非ＲＴＡパケット８６を通信する。以下、全体的プロセスについて説明する。

ＲＴＡトラフィック及び非ＲＴＡトラフィックは、いずれも送信側ＳＴＡのＡＰＰ層７６ａ、７８ａによって生成される。送信側ＳＴＡのＡＰＰ層は、中間の層７６ｂ、７８ｂを介して（通じて）ＲＴＡトラフィック及び非ＲＴＡトラフィックをＭＡＣ層７６ｃ、７８ｃに受け渡す。ＭＡＣ層７６ｃ、７８ｃ及びＰＨＹ層７６ｄ、７８ｄは、ＭＡＣヘッダ及びＰＬＣＰヘッダ内のさらなる信号フィールドをパケットに添付し、これらのパケットがネットワークのＰＨＹ層を介して送信される。

受信側ＳＴＡは、これらのパケットをＰＨＹ層において受け取り、復号し、パケットが正しく復号された場合にはそのＭＡＣ層に送信し、その後に中間の層を通じて（介して）受信側ＳＴＡのＡＰＰ層にデータが供給される。

４．４．ＲＴＡパケットと非ＲＴＡパケットとを識別する機構
開示する技術は、無線通信システム内のパケットをＲＴＡ又は非ＲＴＡのいずれかとして分類する。ＲＴＡパケットはパケット再送に即時再送スキームを使用するのに対し、非ＲＴＡパケットは通常のＣＳＭＡ／ＣＡスキームを使用することができる。この目的のために、ＳＴＡは、ＭＡＣ層においてＲＴＡパケットと非ＲＴＡパケットとを識別する。

図６に示すＳＴＡ層モデルによれば、送信側ＳＴＡのＭＡＣ層は、上位層からのＲＴＡトラフィックと非ＲＴＡトラフィックとを識別し、これらをそれぞれＲＴＡパケット及び非ＲＴＡパケットにパケット化することができる。本節では、送信側ＳＴＡが事前ネゴシエーションを使用してＲＴＡトラフィックを識別する方法の詳細を示す。

図６に示すＳＴＡ層モデルによれば、送信側ＳＴＡは、ネットワークのＰＨＹ層を介して受信側ＳＴＡにパケットを送信する。受信側ＳＴＡは、ＭＡＣ層においてパケットを受け取ると、ＭＡＣヘッダ又はＰＬＣＰヘッダに埋め込まれた情報に基づいて、ＲＴＡパケットと非ＲＴＡパケットとを識別することができる。本節では、受信側ＳＴＡがＰＬＣＰ又はＭＡＣヘッダ情報に基づいてＲＴＡパケットを識別する方法の詳細を示す。

ＲＴＡトラフィックは、データの有効性を保証するために所与の有効期限内に通信される必要がある。換言すれば、この有効期限の満了前にＲＴＡトラフィックが受信側によって受け取られなかった場合、このＲＴＡトラフィックは無効であり、廃棄することができる。ＳＴＡは、ＰＨＹ層を通じて送信するためにＲＴＡトラフィックをＲＴＡパケットにパケット化する。従って、ＲＴＡパケットは、送信のための有効期限も有する。本節では、ＳＴＡがＲＴＡパケットの有効期限の満了にどのように対処するかについての詳細を示す。

４．４．１．事前ネゴシエーション
多くの場合、ＲＴＡは、接続型通信の形で定期的にトラフィックを生成する。ＳＴＡ間のアプリケーションによって確立されるＲＴＡ接続型通信はＲＴＡセッションと呼ばれる。ＳＴＡは、ネットワーク内に複数のＲＴＡセッションを有することができる。本開示による各ＳＴＡは、これらのＲＴＡセッションを適正に管理することができる。

ＲＴＡセッションがＲＴＡトラフィックの送信を開始する前には、接続を確立するために送信側ＳＴＡと受信側ＳＴＡとの間で事前ネゴシエーションが行われる。この事前ネゴシエーション中、送信側ＳＴＡ及び受信側ＳＴＡは、送信側のＭＡＣ層におけるＲＴＡトラフィックと受信側のＭＡＣ層におけるＲＴＡトラフィックとを識別するために使用できるＲＴＡセッション識別情報を含むＲＴＡセッションを記録する。

図６に示すように、送信側においてＡＰＰ層がＭＡＣ層にトラフィックを受け渡すと、中間の層がトラフィックにヘッダ情報を追加する。送信側ＳＴＡのＭＡＣ層は、上位層からトラフィックを受け取ると、上位層からヘッダ情報を抽出して、事前ネゴシエーションによって作成されたＲＴＡセッション記録を調べる（検索する）。ヘッダ情報が記録内の１つのＲＴＡセッションに一致した場合、このトラフィックはＲＴＡであり、そうでなければこのトラフィックは非ＲＴＡであるとみなされる。テーブル１に、ＲＴＡトラフィックを識別するために使用できるヘッダ情報をリストする。本節では、事前ネゴシエーションの詳細について説明する。

受信側ＳＴＡは、事前ネゴシエーションの結果に従って、時間、周波数及びその他の指標などのパケット送信のチャネルリソースによってＲＴＡパケットと非ＲＴＡパケットとを分類することもできる。ＲＴＡパケットのために許可されたチャネルリソースを使用してパケットが受け取られた場合、ＳＴＡはこれをＲＴＡパケットとして識別する。そうでなければ、このパケットは非ＲＴＡパケットである。このシナリオは、４．６．２．２節において説明するマルチユーザアップリンクモードでパケットが送信される際に使用される。

図７に、送信側９２及び受信側９４におけるＲＴＡトラフィックパケットのための事前ネゴシエーションの実施形態例９０を示す。なお、１回の事前ネゴシエーションは１つのＲＴＡセッションを確立し、このＲＴＡセッションによって生成される全てのＲＴＡパケットに使用することができると理解されたい。この図には、図６に示すようなＳＴＡ層モデルにおける２つのＳＴＡ間でＲＴＡセッションを確立するための事前ネゴシエーションを示す。図示のように、送信側ＳＴＡ９２は、層ＡＰＰ９６ａ、中間の層９６ｂ、ＭＡＣ層９６ｃ及びＰＨＹ層９６ｄを有し、受信側ＳＴＡ９４は、同じ層ＡＰＰ９８ａ、中間の層９８ｂ、ＭＡＣ層９８ｃ及びＰＨＹ層９８ｄを有する。以下、事前ネゴシエーションのプロセスについて説明する。

図７を参照すると、以下のステップが見られる。送信側９２のＡＰＰ層９６ａが、リソース（例えば、時間、チャネル）ネゴシエーションを要求する（１０４）。従って、送信側ＳＴＡではＡＰＰ層がＲＴＡセッションを開始し、そのＲＴＡトラフィック送信のために、時間及び帯域幅などのチャネルリソースでのネゴシエーションを要求する。このネゴシエーション要求は、ＡＰＰ層の管理エンティティからＭＡＣ層内に存在する管理エンティティに送信される。

送信側ＳＴＡのＭＡＣ層は、上位層からネゴシエーション要求を受け取って、自機側のリソースの利用可能性をチェックする（１０６）。また、送信側ＳＴＡのＭＡＣ層は、上位層によって提供される、セッション内のＲＴＡトラフィックを識別するためのＲＴＡセッション識別情報を記録する。識別情報の記録は、テーブル１にリストされるＴＣＰ／ＵＤＰポート番号及びサービスタイプなどの情報から選別することができる。リソースが利用可能でない場合、送信側ＳＴＡのＭＡＣ層は上位層からの要求を拒絶し、又は上位層と再ネゴシエートすることができる。

送信側ＳＴＡのＭＡＣ層は、利用可能なリソースを発見した場合、受信側ＳＴＡのＭＡＣ層にネゴシエーション要求フレームを送信する（１０８）。このネゴシエーションフレームは、受信側が記録して後で使用できるようにＲＴＡセッションの識別情報を含む。

受信側ＳＴＡのＭＡＣ層は、ネゴシエーション要求フレームを受け取った後に、ＭＡＣ層内の管理エンティティからＡＰＰ層内の管理エンティティにネゴシエーション要求を送信することによって、そのＡＰＰ層にＲＴＡパケットを受け取る準備を整えるように通知する（１１０）。ＡＰＰ層がＲＴＡ送信に利用可能でない場合、このネゴシエーションは失敗することがある。

受信側のＡＰＰ層は、その層におけるリソースの利用可能性を認め、この情報をＡＰＰ層内の管理層からＭＡＣ層内に存在する管理エンティティに送信する（１１２）。

次に、受信側ＳＴＡのＭＡＣ層は、自機側のリソース利用可能性をチェックする（１１４）。リソースが利用可能でない場合、ＭＡＣ層は拒絶又は再ネゴシエートすることができる。受信側ＳＴＡのＭＡＣ層は、自機側の全てのネゴシエーション情報を収集して送信側のＭＡＣ層に報告する（１１６）。

送信側のＭＡＣ層は、ネゴシエーション結果を受け取ってそのＡＰＰ層に転送する（１１８）。ネゴシエーションが成功した場合、ＡＰＰ層は、両ＳＴＡによって認められたリソースを使用してＲＴＡトラフィックを送信し始めることができる。

送信側ＳＴＡのＭＡＣ層は、事前ネゴシエーションによって作成されたＲＴＡセッション記録に従って、上位層からのヘッダ情報によってＲＴＡトラフィックと非ＲＴＡトラフィックとを識別する。ＡＰＰ層がＲＴＡトラフィックを生成すると、このＲＴＡトラフィックは、中間の層によって提供されるヘッダ情報と共にそのＭＡＣ層に受け渡される。送信側ＳＴＡは、事前ネゴシエーションによって作成されたＲＴＡセッション記録を調べることによって、このヘッダ情報を使用してＲＴＡトラフィックを識別し、ＭＡＣ層においてＲＴＡトラフィックをＲＴＡパケットにパケット化することができる。

図８に、送信側においてＲＴＡパケットトラフィックを識別する実施形態例１３０を示す。ルーチンが開始し（１３２）、送信側ＳＴＡのＭＡＣ層が上位層からトラフィックを受け取る（１３４）。ＭＡＣ層は、上位層によって埋め込まれた、ＲＴＡトラフィックを識別するための情報を抽出し（１３６）、サービスタイプ及びＴＣＰ／ＵＤＰポート番号などの上位層のヘッダ情報をチェックする。

送信側ＳＴＡのＭＡＣ層は、上位層からのヘッダ情報と、事前ネゴシエーションによって作成されたＲＴＡセッション記録とを比較する（１３８）。ヘッダ情報についてチェック１４０を行う。上位層からのヘッダ情報が記録内の１つのＲＴＡセッションに一致する場合には、ブロック１４４に到達してトラフィックがＲＴＡトラフィックであると判定し、そうでなければ、ブロック１４２に到達してトラフィックが非ＲＴＡトラフィックであると判定する。処理は、パケットを識別した後に終了する（１４６）。

４．４．２．パケットヘッダ情報
図９に、ＲＴＡセッション識別情報フォーマットの実施形態例１５０を示す。送信側ＳＴＡは、ＲＴＡパケットを生成すると、ＰＬＣＰ又はＭＡＣヘッダ内にさらなる信号フィールドを追加する。さらなる信号フィールドがＲＴＡセッション識別情報を含む場合、受信側ＳＴＡは、ＰＬＣＰ又はＭＡＣヘッダ内のＲＴＡセッション識別情報を使用して、ＭＡＣ層においてＲＴＡパケットと非ＲＴＡパケットとを区別することができる。この図には、ＲＴＡセッション識別情報の一例を示す。

図１０に、ＡＰＰ層とＭＡＣ層との間のヘッダ情報交換１８０、１８２の実施形態例１７０を示す。送信側ＳＴＡ１７２は、ＡＰＰ層１７６ａ、中間の層１７６ｂ、ＭＡＣ層１７６ｃ及びＰＨＹ層１７６ｄを有することが分かる。受信側ＳＴＡ１７４は、同じ層であるＡＰＰ層１７８ａ、中間の層１７８ｂ、ＭＡＣ層１７８ｃ及びＰＨＹ層１７８ｄを有することが分かる。

この図には、ＳＴＡ層モデルにおける２つのＳＴＡ間でこのプロセスがどのように作用するかについての詳細を示す。送信側ＳＴＡのＡＰＰ層は、ＲＴＡトラフィックを生成して（１８４）ＭＡＣ層に受け渡す。トラフィックは、中間の層を通じて受け渡される際に、サービスタイプフィールド及びＴＣＰ／ＵＤＰポート番号などのヘッダ情報を追加される。

送信側ＳＴＡのＭＡＣ層は、上位層からＲＴＡトラフィックを受け取ると、トラフィックからサービスタイプ及びＴＣＰ／ＵＤＰポート番号などのヘッダ情報を抽出する。ＭＡＣ層は、先行技術によって作成されたＲＴＡセッション記録を調べることによって、トラフィックがＲＴＡトラフィックであることを識別する（１８６）。

次に、送信側ＳＴＡのＭＡＣ層は、トラフィックをＲＴＡパケット１８０にパケット化し、サービスタイプ及びＴＣＰ／ＵＤＰポート番号をＲＴＡセッション識別情報としてＭＡＣヘッダ又はＰＬＣＰヘッダに埋め込む。ＲＴＡセッション識別情報の一例は図９に示した。次に、送信側ＳＴＡは受信側ＳＴＡにＲＴＡパケットを送信し（１８８）、受信側ＳＴＡはパケット１８２を受け取る。

受信側ＳＴＡは、そのＭＡＣ層においてＲＴＡパケットを受け取ると、ＰＬＣＰ又はＭＡＣヘッダ内のＲＴＡセッション識別情報に基づいてＲＴＡパケットを識別することができる（１８９）。

図１１に、受信側のＭＡＣ層においてＲＴＡパケットを識別するプロセスの実施形態例１９０を示す。プロセスが開始し（１９２）、受信側がＰＨＹ層においてパケットを受け取る（１９４）。図１０で説明したように、ＲＴＡパケットのＭＡＣヘッダ又はＰＬＣＰヘッダは、ＲＴＡセッションの識別情報を含む。再び図１１を参照して、識別情報が存在するかどうかを判定するチェックを行う（１９６）。識別情報が存在する場合、実行はブロック２００に進み、受信側ＳＴＡがパケットをＲＴＡパケットであると判定する。一方で、情報が存在しない場合、実行はブロック１９６から１９８に進み、パケットは非ＲＴＡであると判定される。その後にプロセスは終了する（２０２）。

４．５．ＲＴＡインターフェイス
４．５．１．参照モデル
ＲＴＡユーザがＲＴＡセッションを開始すると、図７で説明したようにアプリケーション層によって開始手順が開始されてＭＡＣ層において実行される。通信には２つのタイプがある。一方のタイプの通信は、１つのＳＴＡ内の異なるネットワーク層間で発生する。他方のタイプの通信は、２つのＳＴＡ間で発生する。

図１２に、開示するＲＴＡ管理のための相互作用モデルの実施形態例２１０を示す。この図には、ＲＴＡユーザ２１４及びその他の上位層２１４を示す。図示のＭＡＣ副層２１６は、上位層との間にＭＡＣサービスアクセスポイント（ＳＡＰ）２１８を含む。物理（ＰＨＹ）及び物理媒体依存（ＰＭＤ）副層２２２にもＰＨＹ層のための同様のＳＡＰが接続していることが分かる（２２０）。図示のＭＡＣ層管理エンティティ（ＭＬＭＥ）２２４は、ＭＡＣ副層２１６において、ＭＬＭＥ－ＰＨＹ層管理エンティティ（ＰＬＭＥ）ＳＡＰ２２６を通じてＰＬＭＥ２２８と通信する。図の右下には、ＲＴＡユーザ２１２と通信するためのＲＴＡ管理機能２３２を有する局管理エンティティ（ＳＭＥ）２３０を示す。また、ＳＭＥは、ＭＬＭＥと通信するためのＭＬＭＥ ＳＡＰ２３４、及びＰＬＭＥ２２８と通信するためのＰＬＭＥ ＳＡＰ２３６を有することが分かる。

動作中、１つのＳＴＡの異なるネットワーク層間の通信が発生すると、ＲＴＡユーザは、層間インターフェイスを通じてＲＴＡアクティビティを管理することができる。ＲＴＡユーザは、ＭＡＣ層、及びＡＰＰ層などの上位層と通信して情報を交換することができる。

ＡＰＰ層におけるＲＴＡユーザは、ＭＡＣ層に複数のＲＴＡサービスを提供することができる。例えば、ＳＴＡは、（ａ）ＲＴＡセッション管理などのＲＴＡイベントサービス、（ｂ）ＲＴＡ待ち行列設定などのＲＴＡコマンドサービス、及び（ｃ）ＲＴＡ ＫＰＩ測定などのＲＴＡ情報サービスを提供することができる。

ＲＴＡユーザは、ＭＡＣ層における局管理エンティティ（ＳＭＥ）２３０のＲＴＡ管理２３２を通じてこれらのサービス要求を受け渡すことができる。その後、ＳＭＥは、要求情報に従って、ＭＡＣ副層管理エンティティサービスアクセスポイント（ＭＬＭＥ ＳＡＰ）インターフェイス２３４を通じてＭＡＣ層において動作を行うことができる。

２つのＳＴＡ間で通信が発生した場合、ＲＴＡユーザは、層間インターフェイスを通じてメッセージを受け渡し、ＭＡＣに２つのＳＴＡ間でフレームの送受信を行わせることができる。

ＡＰＰ層におけるＲＴＡユーザは、ＲＴＡユーザとＳＭＥとの間の直接メッセージ交換に加えて、ＭＡＣ状態一般収束機能（ＭＡＣ Ｓｔａｔｅ Ｇｅｎｅｒｉｃ Ｃｏｎｖｅｒｇｅｎｃｅ Ｆｕｎｃｔｉｏｎ：ＭＳＧＣＦ）を通じてＳＭＥとメッセージを交換することもでき、従ってＩＥＥＥ８０２．１１で規定されるＭＳＧＣＦ ＳＡＰ及びＭＳＧＣＦ－ＳＭＥ ＳＡＰを介してメッセージを転送することができる。

図１３に、ＲＴＡ管理のための層管理モデルの実施形態例２５０を示す。この図には、ＳＭＥ２５２、ＭＬＭＥ２５４及びＭＡＣ副層２５６を示す。（図１２のブロック２３２として示す）ＲＴＡ管理２５８は、ＲＴＡ待ち行列管理２６０、ＲＴＡ ＫＰＩ測定ポリシー２６２及びＲＴＡセッション管理２６４のためのモジュールを有することが分かる。ＭＬＭＥレベルでは、ＲＴＡ待ち行列設定２６６ａ、外部ＲＴＡ待ち行列設定２６６ｂ、ＲＴＡ ＫＰＩ測定２６６ｃ、ＲＴＡ ＫＰＩ測定要求及び報告２６６ｄ、並びにＲＴＡセッション開始及び破棄２６６ｅのための一連の機能が見られる。なお、上記の機能は特定の実施形態のための一例として示すものであるが、これらの機能は本開示の教示から逸脱することなく縮小又は拡張することができると理解されたい。一連のモジュールは、ＲＴＡ待ち行列動作プロトコル２７０ａ、ＲＴＡ待ち行列設定フレーム２７０ｂ、ＲＴＡ ＫＰＩ測定プロトコル２７０ｃ、ＲＴＡ ＫＰＩ測定フレーム２７０ｄ、及びＲＴＡセッションイベント２７０ｅなどの機能に結合されていることが分かる。これらの下位には、ＭＡＣ副層の待ち行列構造２７６に結合されたＲＴＡ待ち行列制御及びモニタリング２７４機能が見られる。また、ブロック２７０ａ～２７０ｅと通信するＭＡＣタイミング（ＴＳＦトレーニング）ブロック２７２も見られる。

層管理は、ＭＬＭＥとＳＭＥとの間に特定の機能区分を有する。図示のように、ＳＭＥ２５２内に存在するＲＴＡ管理エンティティ２５８は管理決定を表す一方で、ＭＬＭＥ内に存在する機能は、ＳＭＥからの管理決定に従って動作を行う。ＳＭＥ内のＲＴＡ管理は、ＲＴＡ待ち行列管理、ＲＴＡ ＫＰＩ測定ポリシー及びＲＴＡセッション管理のための決定を行ってフィードバックを受け取ることができる。

ＲＴＡ管理エンティティ２５８は、ＲＴＡセッション管理２６４に関して決定を行う場合、ＭＬＭＥにおけるＲＴＡセッションイベント機能２７０ｅを呼び出す。ＳＴＡは、この決定に従って別のＳＴＡとのＲＴＡセッションの開始、再開又は破棄を行うことができる（２６６ｅ）。さらなる詳細については、４．５．２節で説明する。

ＲＴＡ管理エンティティ２５８は、ＲＴＡ待ち行列管理２６０に関して決定を行う場合、ＭＡＣ副層における内部待ち行列を制御する（２６６ａ）ために、ＭＬＭＥにおけるＲＴＡ待ち行列動作プロトコル２７０ａ機能を呼び出し、或いは外部待ち行列を設定する（２６６ｂ）管理フレームを送信するために、ＭＬＭＥにおけるＲＴＡ待ち行列設定フレーム機能２７０ｂを呼び出す。ＲＴＡ待ち行列動作プロトコル機能２７０ａは、ＲＴＡ管理エンティティ２５８に待ち行列の状態を報告することができる。ＲＴＡ待ち行列設定フレーム機能２７０ｂは、他のＳＴＡからフレームを受け取ってＲＴＡ管理にフレーム内の情報を受け渡すことができる。さらなる詳細については、４．５．３節で説明する。

ＲＴＡ管理は、ＲＴＡ ＫＰＩ測定ポリシー２６２に関して決定を行う場合、ＭＡＣ層及びＰＨＹ層におけるＲＴＡ ＫＰＩ測定２６６ｃを開始するために、ＭＬＭＥにおけるＲＴＡ ＫＰＩ測定プロトコル機能２７０ｃを呼び出し、或いは別のＳＴＡにおけるＲＴＡ ＫＰＩ測定２６６ｄをスケジュールする管理フレームを他のＳＴＡに送信するために、ＭＬＭＥにおけるＲＴＡ ＫＰＩ測定フレーム機能２７０ｄを呼び出す。ＲＴＡ ＫＰＩ測定プロトコル機能２７０ｃは、ＲＴＡ管理２５８に測定結果を報告することができる。ＲＴＡ ＫＰＩ測定フレーム機能２７０ｄは、他のＳＴＡから測定報告フレームを受け取ってＲＴＡ管理に報告を受け渡すことができる。さらなる詳細については、４．５．４節で説明する。

ＭＬＭＥにおける機能は、ＳＭＥにおけるＲＴＡ管理によって下された決定に従って動作を行う場合、ＭＡＣ層におけるＴＳＦタイミングなどのタイムスタンプを時間基準として使用することができる。

４．５．２．ＲＴＡセッション管理
本節では、ＳＴＡがＳＭＥにおけるＲＴＡセッション管理とＭＬＭＥにおけるＲＴＡセッションイベント機能との間のインターフェイスを使用することによってＲＴＡセッションの開始、再開及び破棄をどのように行うかの詳細について説明する。

図１４に、識別情報２９２、状態情報２９４、要件情報２９６、送信情報２９８、待ち行列情報３００及び測定情報３０２を含むＲＴＡセッション情報の実施形態例２９０を示す。

２つのＳＴＡがＲＴＡセッションを確立する場合、これらはＲＴＡセッションのための情報を交換する必要がある。この図には、ＲＴＡセッション情報の例を示す。その内容は、以下のメッセージ及びフィールドを含む。

識別情報（Ｉｄｅｎｔｉｆｙｉｎｇ Ｉｎｆｏ）２９２は、セッションＩＤ（Ｓｅｓｓｉｏｎ ＩＤ）、サービスタイプ（Ｔｙｐｅ ｏｆ Ｓｅｒｖｉｃｅ）、発信元ＩＰアドレス（Ｓｏｕｒｃｅ ＩＰ Ａｄｄｒｅｓｓ）、発信元ポート（Ｓｏｕｒｃｅ Ｐｏｒｔ）、宛先ＩＰアドレス（Ｄｅｓｔｉｎａｔｉｏｎ ＩＰ Ａｄｄｒｅｓｓ）、宛先ポート（Ｄｅｓｔｉｎａｔｉｏｎ Ｐｏｒｔ）などの、テーブル１にリストするようなＭＡＣ層よりも上位の層からのものである、発信元ＭＡＣアドレス（Ｓｏｕｒｃｅ ＭＡＣ Ａｄｄｒｅｓｓ）及び宛先ＭＡＣアドレス（Ｄｅｓｔｉｎａｔｉｏｎ ＭＡＣ Ａｄｄｒｅｓｓ）などのＭＡＣヘッダからの識別情報である。

状態情報（Ｓｔａｔｕｓ Ｉｎｆｏ）２９４は、セッション状態（Ｓｅｓｓｉｏｎ Ｓｔａｔｕｓ）、コメント（Ｃｏｍｍｅｎｔ）及び最終アクティブ時間（Ｌａｓｔ Ａｃｔｉｖｅ Ｔｉｍｅ）などの状態を含む状態情報である。セッション状態は、ＲＴＡセッションがトラフィックを生成するように設定されているかどうかを示す。テーブル２に、考えられるＲＴＡセッション状態をリストする。ＲＴＡセッション状態がアクティブである場合には、ＲＴＡセッションが有効になってＲＴＡトラフィックを生成する。ＲＴＡセッション状態が非アクティブである場合には、ＲＴＡセッションが無効になってユーザからのＲＴＡトラフィックを生成しない。ＲＴＡセッション状態がエラーである場合、ＲＴＡセッションはエラーに起因してＲＴＡトラフィックを生成又は送信することができない。コメントフィールドは、ＲＴＡセッション状態の詳細を示すために利用することができる。このフィールドは、警告又はエラーメッセージを伝えるために使用することができる。例えば、コメントは、セッション内で多数のＲＴＡパケットが破損した時に送信品質が低いことを示すことができる。コメントは、新たなＲＴＡセッションを作成するための動作パラメータを提案する情報を伝えるために使用することもできる。最終アクティブ時間フィールドは、ＲＴＡセッションの状態をチェックする何らかのイベントをトリガするために使用することができる。最終アクティブ時間は、ＲＴＡセッションのためのＲＴＡパケット送信が行われる度に更新される。この情報は、ＲＴＡトラフィックが定期的に生成又は供給されているかどうかを追跡するために使用することができる。一定期間にわたって最終アクティブ時間が更新されない場合、ＲＴＡセッションはＲＴＡトラフィックの生成又は供給を行っていない。エラーが発生したかどうかを判定するにはＲＴＡセッション状態をチェックすべきである。

要件情報（Ｒｅｑｕｉｒｅｍｅｎｔ Ｉｎｆｏ）２９６は、帯域幅要件（Ｂａｎｄｗｉｄｔｈ Ｒｅｑｕｉｒｅｍｅｎｔ）、遅延要件（Ｄｅｌａｙ Ｒｅｑｕｉｒｅｍｅｎｔ）、ジッタ要件（Ｊｉｔｔｅｒ Ｒｅｑｕｉｒｅｍｅｎｔ）、周期（Ｐｅｒｉｏｄｉｃ Ｔｉｍｅ）、セッション開始時点（Ｓｅｓｓｉｏｎ Ｓｔａｒｔ Ｔｉｍｅ）、及びセッション終了時点（Ｓｅｓｓｉｏｎ Ｅｎｄ Ｔｉｍｅ）を含む要件情報に関するフィールドを含む。帯域幅要件フィールドは、送信すべきＲＴＡトラフィック量を示す。ＳＴＡは、チャネル帯域幅を測定する場合、測定された帯域幅と必要な帯域幅とを比較することができる。帯域幅測定の詳細については、４．５．４．２．１節で説明する。測定結果が要件を満たすことができない場合、ＳＴＡはＲＴＡセッション開始を拒絶することができる。

遅延要件フィールドは、ＲＴＡパケットの送信遅延を示す。ＳＴＡは、パケット送信遅延時間を測定する場合、測定された遅延時間と必要な遅延とを比較することができる。遅延時間測定の詳細については、４．５．４．２．２節で説明する。測定結果が要件を満たすことができない場合、ＳＴＡはＲＴＡセッション開始を拒絶することができる。

ジッタ要件フィールドは、各周期的送信時間中の最大ＲＴＡパケット遅延差を示す。ＳＴＡは、パケット送信遅延時間を測定する際に、ジッタ情報を取得してジッタ要件と比較することができる。遅延時間測定の詳細については、４．５．４．２．２節で説明する。測定結果が要件を満たすことができない場合、ＳＴＡはＲＴＡセッション開始を拒絶することができる。

周期は、ＲＴＡセッションがＲＴＡトラフィックを１回生成するまでの継続時間を示し、すなわちＲＴＡセッションは周期毎にトラフィックを生成する。セッション開始時点フィールド及び終了時点フィールドは、ＲＴＡセッションの開始時点及び終了時点を示す。

送信情報（Ｔｒａｎｓｍｉｓｓｉｏｎ Ｉｎｆｏ）２９８は、時間割り当て（Ｔｉｍｅ Ａｌｌｏｃａｔｉｏｎ）、ＲＵ割り当て（ＲＵ Ａｌｌｏｃａｔｉｏｎ）、及びＳＳ割り当て（ＳＳ Ａｌｌｏｃａｔｉｏｎ）のためのフィールドを含む送信情報メッセージである。時間割り当てフィールドは、送信のためにＲＴＡセッションに配分されるチャネル時間の量を示す。

ＲＵ割り当てフィールドは、送信のためにＲＴＡセッションに配分されるチャネルのリソースユニット（ＲＵ）を示す。ＲＵは、ＩＥＥＥ８０２．１１ａｘで使用されるＯＦＤＭＡ用語での単位である。ＲＵは、どのチャネル周波数を送信に使用すべきであるかを決定する。

ＳＳ割り当てフィールドは、ＲＴＡセッショントラフィック送信のための空間ストリーム割り当てを示す。ＳＳ割り当ては、ＩＥＥＥ８０２．１１で使用されるＭＩＭＯ用語での単位、又はビームフォーミング用語での指向性アンテナパターンの指標とすることができる。

待ち行列情報（Ｑｕｅｕｅ Ｉｎｆｏ）３００は待ち行列情報を提供し、初期待ち行列タイプ（Ｉｎｉｔｉａｌ Ｑｕｅｕｅ Ｔｙｐｅｓ）、有効期限（Ｌｉｆｅｔｉｍｅ）、ＲＴＡ優先度（ＲＴＡ Ｐｒｉｏｒｉｔｙ）を含むフィールドを含む。初期待ち行列タイプは、ＲＴＡセッションによってトラフィックが生成された時にこのトラフィックをどの待ち行列に入れ込むべきであるかを示す。有効期限は、待ち行列においてＲＴＡパケットを記憶できる時間を表す。有効期限が満了すると、パケットは破棄される。本開示の少なくとも１つの実施形態による１つのモードでは、より満了時間に近いＲＴＡパケットが最初に送信される。ＲＴＡ優先度フィールドは、ＲＴＡパケットの優先度を示す。本開示の少なくとも１つの実施形態による１つのモードでは、より優先度の高いＲＴＡトラフィックが最初に送信されるべきである。

測定情報（Ｍｅａｓｕｒｅｍｅｎｔ Ｉｎｆｏ）３０２－測定情報は、測定指示（Ｍｅａｓｕｒｅｍｅｎｔ Ｉｎｄｉｃａｔｉｏｎ）、ＲＴＡ ＫＰＩ測定方法（ＲＴＡ ＫＰＩｓ Ｍｅａｓｕｒｅ Ｍｅｔｈｏｄ）、ＲＴＡ ＫＰＩ測定報告（ＲＴＡ ＫＰＩ Ｍｅａｓｕｒｅ Ｒｅｐｏｒｔ）を含むフィールドを有する。測定指示サブフィールドは、１ビット指示として実装することができる。このサブフィールドが第１の状態（例えば、１）に設定された場合、ＳＴＡは、ＲＴＡセッションの開始前にＲＴＡ ＫＰＩ測定を要求し、一方でこのサブフィールドが第２の状態（例えば、０）に設定された場合、ＲＴＡセッション開始によってＲＴＡ ＫＰＩ測定が要求されない。

ＲＴＡ ＫＰＩ測定方法フィールドは、ＲＴＡセッション開始手順中にどのタイプのＲＴＡ ＫＰＩ測定を開始すべきであるかを示す。測定の複数の例については、４．５．４．２節に示す。ＲＴＡ ＫＰＩ測定報告フィールドは、ＲＴＡ ＫＰＩ測定結果を伝える。

４．５．２．１．ＲＴＡセッション開始
図１５Ａ～図１５Ｃに、ＲＴＡセッション開始の完全な手順と、それぞれがＡＰＰ層３１６、３２６、ＳＭＥ層３１８、３２４、ＭＬＭＥ層３２０、３２２を有する発信側３１２と受信側との間のメッセージ交換とを例示する実施形態例３１０を示す。なお、実際のメッセージは、これらの２つのＳＴＡのＭＡＣ層間で交換される。

発信側ＳＴＡのＲＴＡユーザは、ＲＴＡセッションを開始すると決定（判定）した場合（３２８）、そのＳＭＥにテーブル３に示すようなＲＴＡＳＥＳＳＩＯＮＥＶＥＮＴ．ｒｅｑｕｅｓｔメッセージ３３０を送信する。この時、ＳＭＥは、ＲＴＡセッションを確立するためにチャネルリソースが利用可能であることを確実にするために、最初にＲＴＡ ＫＰＩを測定することなどによってＲＴＡセッションを開始（３３２）する必要がある。発信側ＳＴＡのＳＭＥにおけるＲＴＡセッション管理は決定を行い、ＭＬＭＥ層３２０におけるＲＴＡ ＫＰＩ測定プロトコル機能にＲＴＡＫＰＩＭＥＡＳＵＲＥ．ｒｅｑｕｅｓｔメッセージ３３４を送信する。ＲＴＡＫＰＩＭＥＡＳＵＲＥ．ｒｅｑｕｅｓｔメッセージのフォーマットについてはテーブル３０で説明する。

次に、ＭＬＭＥは、ＲＴＡＫＰＩＭＥＡＳＵＲＥ．ｒｅｑｕｅｓｔメッセージ内の要求に従ってＲＴＡ ＫＰＩ測定手順を開始する（３３６）。例えば、発信側ＳＴＡがＲＴＡパケットを送信する予定である場合、ここで４．５．４．２．１節で説明するようなチャネル帯域幅測定を実行することができる。ＲＴＡ ＫＰＩ測定手順については、４．５．４節で説明する。ＭＬＭＥは、測定手順を終了した後に、テーブル３１で説明するようなＲＴＡＫＰＩＭＥＡＳＵＲＥ．ｃｏｎｆｉｒｍメッセージ３３８を送信して測定結果を報告する。

発信側ＳＴＡのＳＭＥは、ＲＴＡ ＫＰＩ測定結果を受け取ると、測定結果を取りまとめて（３４０）ＲＴＡセッションの開始を継続すべきであるか否かを決定する（３４２）。例えば、ＳＴＡは、チャネル帯域幅などのＲＴＡ ＫＰＩ測定結果を（図１４に定める）ＲＴＡセッションの要件情報と比較することができる。測定結果が要件を満たす場合、ＳＴＡはＲＴＡセッション開始を継続する。

ＳＴＡがＲＴＡセッション開始を継続すると決定した場合、発信側ＳＴＡのＳＭＥにおけるＲＴＡセッション管理は、ＭＬＭＥ ＳＡＰインターフェイスを介してＭＬＭＥにおけるＲＴＡセッションイベント機能にＲＴＡＳＥＳＳＩＯＮＩＮＩＴ．ｒｅｑｕｅｓｔメッセージ３４４を送信する。ＲＴＡＳＥＳＳＩＯＮＩＮＩＴ．ｒｅｑｕｅｓｔメッセージのフォーマットについてはテーブル７で説明する。

発信側ＳＴＡのＭＬＭＥは、ＲＴＡＳＥＳＳＩＯＮＩＮＩＴ．ｒｅｑｕｅｓｔメッセージを受け取ると、ＲＴＡＳＥＳＳＩＯＮＩＮＩＴ．ｒｅｑｕｅｓｔメッセージ内のＲＴＡセッション情報を収集して受信側ＳＴＡにＲＴＡセッション開始要求フレーム３４６を送信する。ＲＴＡセッション開始要求フレームのフォーマットは図１６に示す。受信側ＳＴＡ３１４のＭＬＭＥは、このフレームを受け取り、ＭＬＭＥ ＳＡＰインターフェイスを介して自機のＳＭＥに対し、テーブル６に示すようなＲＴＡＳＥＳＳＩＯＮＩＮＩＴ．ｉｎｄｉｃａｔｉｏｎメッセージ３４８を生成する。

次に、ＳＭＥ層３２４は、受信側ＳＴＡのＡＰＰ層のＲＴＡユーザに、テーブル４に示すようなＲＴＡＳＥＳＳＩＯＮＩＮＩＴＥＶＥＮＴ．ｉｎｄｉｃａｔｅメッセージを受け渡す（３５０）。図１５Ｂにおいて、受信側ＳＴＡのＡＰＰ層におけるＲＴＡユーザは、開始イベントに従うことを決定（３５２）した場合、テーブル５に示すようなＲＴＡＳＥＳＳＩＯＮＩＮＩＴＥＶＥＮＴ．ｒｅｓｐｏｎｓｅメッセージ３５４をＳＭＥ層に返送する。ＡＰＰ層は、この応答メッセージ内で開始を継続すると決定していた場合、この例ではＲＴＡＳＥＳＳＩＯＮＩＮＩＴＥＶＥＮＴ．ｒｅｓｐｏｎｓｅメッセージ内のＦｏｌｌｏｗＥｖｅｎｔフィールドを「１」に設定することなどによって設定を行って開始イベントに従うことを示す。

その後、ＳＭＥは、ＲＴＡセッション開始手順に従い続ける（３５６）。図４．４．１で説明するように、受信側ＳＴＡは、チャネルリソースの利用可能性をチェックしてＲＴＡセッション開始要求を認めるべきであるかどうかを決定する必要がある。受信側ＳＴＡは、この決定を行うために、自機側のＲＴＡ ＫＰＩを測定する必要がある。ＲＴＡ ＫＰＩ測定手順は発信側ＳＴＡのものと同じであり、ＲＴＡＫＰＩＭＥＡＳＵＲＥ．ｒｅｑｕｅｓｔメッセージ３５８を送信し、これに応答してＫＰＩ測定プロセスが実行され（３６０）、ＳＭＥにＲＴＡＫＰＩＭＥＡＳＵＲＥ．ｃｏｎｆｉｒｍメッセージ３６２が返送される。例えば、受信側ＳＴＡがＲＴＡパケットを受け取る予定である場合には、ここで４．５．４．２．２節で説明するようなパケット送信遅延時間測定を実行することができる。測定情報が取りまとめられ（３６４）、図１５ＣにおいてＲＴＡセッション開始を認めるべきであるか否かが決定される（３６６）。

次に、受信側ＳＴＡのＳＭＥは、そのＭＬＭＥに、フィードバック情報を含むＲＴＡＳＥＳＳＩＯＮＩＮＩＴ．ｒｅｓｐｏｎｓｅメッセージ３６８を送信する。ＲＴＡＳＥＳＳＩＯＮＩＮＩＴ．ｒｅｓｐｏｎｓｅメッセージのフォーマットについてはテーブル９で説明する。次に、受信側ＳＴＡのＭＬＭＥは、発信側ＳＴＡのＭＬＭＥにＲＴＡセッション開始応答フレーム３７０を送信する。発信側ＳＴＡのＭＬＭＥはこのフレームを受け取り、そのＳＭＥにテーブル１０に示すようなＲＴＡＳＥＳＳＩＯＮＩＮＩＴ．ｃｏｎｆｉｒｍメッセージ３７２を送信し、ＳＭＥはセッション開始合意を認識するようになる（３７４）。次に、発信側のＳＭＥは、ＲＴＡＳＥＳＳＩＯＮＩＮＩＴＥＶＥＮＴ．ｃｏｎｆｉｒｍメッセージを通じてＲＴＡセッションの開始に成功したか否かをＲＴＡユーザに通知し（３８０）、受信側ＳＭＥ３２４からそのＡＰＰ層におけるユーザに同様のＲＴＡＳＥＳＳＩＯＮＩＮＩＴＥＶＥＮＴ．ｃｏｎｆｉｒｍメッセージ３７８が送信されることでＲＴＡセッション開始が完了する（３８２）。

発信側ＳＴＡ及び受信側ＳＴＡの両方のＳＭＥは、ＲＴＡセッション開始結果を認識する。これらのＳＭＥは、テーブル６に示すようなＲＴＡＳＥＳＳＩＯＮＩＮＩＴＥＶＥＮＴ．ｃｏｎｆｉｒｍメッセージを介してＡＰＰ層に結果を転送する。

図１６に、以下のフィールドを有するＲＴＡセッション開始要求フレームフォーマットの実施形態例３９０を示す。フレーム制御（Ｆｒａｍｅ Ｃｏｎｔｒｏｌ）フィールドは、フレームのタイプを示す。継続時間（Ｄｕｒａｔｉｏｎ）フィールドは、ＣＳＭＡ／ＣＡチャネルアクセスに使用されるＮＡＶ情報を含む。ＲＡフィールドは、フレームの受信者のアドレスを含む。ＴＡフィールドは、フレームを送信したＳＴＡのアドレスを含む。アクション（Ａｃｔｉｏｎ）フィールドは管理フレームのタイプを示し、この場合は管理フレームがＲＴＡセッション開始要求フレームであることを示す。

開始要求情報（Ｉｎｉｔｉａｔｉｏｎ Ｒｅｑｕｅｓｔ Ｉｎｆｏｒｍａｔｉｏｎ）フィールドは、フレームがＲＴＡセッション開始要求フレームであることがアクションフィールドによって示される場合にアクションフィールドに後続する。開始要求情報フィールドは以下のサブフィールドを含む。（ａ）ＲＴＡセッションＩＤ（ＲＴＡ Ｓｅｓｓｉｏｎ ＩＤ）サブフィールドはＲＴＡセッションを識別し、その内容については図９に示している。（ｂ）リソース要件（Ｒｅｓｏｕｒｃｅ Ｒｅｑｕｉｒｅｍｅｎｔ）サブフィールドは、図１４で説明したようなＲＴＡセッションの要件情報を含む。（ｃ）待ち行列情報（Ｑｕｅｕｅ Ｉｎｆｏｒｍａｔｉｏｎ）サブフィールドは、図１４で説明したようなＲＴＡセッションの待ち行列情報を提供する。（ｄ）測定指示（Ｍｅａｓｕｒｅｍｅｎｔ Ｉｎｄｉｃａｔｉｏｎ）サブフィールドは、ＲＴＡ開始のために測定が必要であるかどうかを示し、１ビット指示として実装することができる。このフィールドが第１の状態（例えば、「１」）に設定された場合には、ＲＴＡセッション開始のために測定が必要であり、このフィールドが第２の状態（例えば、「０」）に設定された場合には、測定は不要である。（ｅ）ＲＴＡ ＫＰＩ測定方法サブフィールドは、受信側ＳＴＡにおけるＲＴＡ ＫＰＩの測定方法に関する情報を伝える。このフィールドは、４．５．４．２節で説明するフォーマットを使用することができる。例えば、このフィールドは、４．５．４．２．２節の図３７で説明するようなパケット送信遅延時間測定とすることができる。

図１７に、ＲＴＡセッション開始応答フレームの実施形態例４１０を示す。フレーム制御フィールドは、フレームのタイプを示す。継続時間フィールドは、ＣＳＭＡ／ＣＡチャネルアクセスに使用されるＮＡＶ情報を含む。ＲＡフィールドは、フレームの受信者のアドレスを含む。ＴＡフィールドは、フレームを送信したＳＴＡのアドレスを含む。アクションフィールドは管理フレームのタイプを示し、この場合は管理フレームがＲＴＡセッション開始応答フレームであることを示す。

開始応答情報（Ｉｎｉｔｉａｔｉｏｎ Ｒｅｓｐｏｎｓｅ Ｉｎｆｏｒｍａｔｉｏｎ）フィールドは、このフレームがＲＴＡセッション開始応答フレームであることがアクションフィールドによって示される場合にアクションフィールドに後続し、以下のサブフィールドを含む。ＲＴＡセッションＩＤサブフィールドは、ＲＴＡセッションの識別情報を提供する。このフィールドの内容については図１９に示す。開始結果（Ｉｎｉｔｉａｔｉｏｎ Ｒｅｓｕｌｔ）サブフィールドは、開始が認められるか否かを示す指示（例えば、１ビット）を提供する。このフィールドが第１の状態（例えば「１」）に設定された場合には、他方のＳＴＡによって開始が認められ、そうでなければこのフィールドは第２の状態（例えば「０」）に設定される。送信情報（Ｔｒａｎｓｍｉｓｓｉｏｎ Ｉｎｆｏｒｍａｔｉｏｎ）サブフィールドは、図１４で説明したようなＲＴＡセッションの送信情報を提供する。状態情報（Ｓｔａｔｕｓ Ｉｎｆｏｒｍａｔｉｏｎ）サブフィールドは、図１４で説明したようなＲＴＡセッションの状態情報を含む。測定指示サブフィールドは、測定結果が含まれているかどうかを示す。一例として、このフィールドが第１の状態（例えば「１」）に設定された場合には測定結果が含まれており、このフィールドが第２の状態（例えば「０」）に設定された場合には測定値が含まれていない。ＲＴＡ ＫＰＩ測定報告（ＲＴＡ ＫＰＩ Ｍｅａｓｕｒｅ Ｒｅｐｏｒｔ）サブフィールドは、ＲＴＡ ＫＰＩ測定結果を伝える。

図１８Ａ及び図１８Ｂに、ＲＴＡセッション開始を実行する代替手順の実施形態例４３０を示す。いくつかの状況では、発信側ＳＴＡが、受信側ＳＴＡとネゴシエーションすることなくＲＴＡセッションを開始する。この図では、ＲＴＡセッション開始を完了するための２つのＳＴＡ間の別のメッセージ交換例を提供する。この図には、図１５Ａ～図１５Ｃと同様の発信側と受信側との間の通信を示す。

発信側ＳＴＡのＲＴＡユーザは、ＲＴＡセッションを開始すると決定し（３２８）、そのＳＭＥにＲＴＡＳＥＳＳＩＯＮＥＶＥＮＴ．ｒｅｑｕｅｓｔメッセージ３３０を送信する。ＲＴＡＳＥＳＳＩＯＮＥＶＥＮＴ．ｒｅｑｕｅｓｔメッセージ３３０はテーブル３に示す。次に、ＳＭＥは、ＲＴＡセッションを開始する前にいくつかのことを決定（３３２）する必要がある。最初に、ＳＭＥは、ＲＴＡセッションを確立するのに十分なチャネルリソースが利用可能であることを確実にするためにＲＴＡ ＫＰＩを測定する。この事例では、発信側ＳＴＡのＳＭＥにおけるＲＴＡセッション管理がＲＴＡセッションを開始すると決定し、ＭＬＭＥ層におけるＲＴＡ ＫＰＩ測定プロトコル機能にＲＴＡＫＰＩＭＥＡＳＵＲＥ．ｒｅｑｕｅｓｔメッセージ３３４を送信する。ＲＴＡＫＰＩＭＥＡＳＵＲＥ．ｒｅｑｕｅｓｔメッセージのフォーマットについてはテーブル３０で説明する。

次に、ＭＬＭＥは、ＲＴＡＫＰＩＭＥＡＳＵＲＥ．ｒｅｑｕｅｓｔメッセージ内の要求に従ってＲＴＡ ＫＰＩ測定手順を開始する（３３６）。例えば、発信側ＳＴＡがＲＴＡパケットを送信する予定である場合には、この時点で４．５．４．２．１節で説明するようなチャネル帯域幅測定を実行することができる。ＲＴＡ ＫＰＩ測定手順については、４．５．４節で説明する。ＭＬＭＥは、測定手順を終了した後に、テーブル３１で説明するようなＲＴＡＫＰＩＭＥＡＳＵＲＥ．ｃｏｎｆｉｒｍメッセージ３３８を送信して測定結果を報告する。

図１８Ｂにおいて、発信側ＳＴＡのＳＭＥは、ＲＴＡ ＫＰＩ測定結果を受け取って取りまとめると（３４０）、ＲＴＡセッションを確立すべきであるかどうかを決定する（３４２）。例えば、ＳＴＡは、ＲＴＡ ＫＰＩ測定結果を（図１４に定める）ＲＴＡセッションの要件情報と比較することができる。測定結果が要件を満たす場合、ＳＴＡはＲＴＡセッションを確立すると決定する。

ＳＴＡがＲＴＡセッション開始を継続すると決定した場合、発信側ＳＴＡのＳＭＥにおけるＲＴＡセッション管理は、ＭＬＭＥ ＳＡＰインターフェイスを介してＭＬＭＥにおけるＲＴＡセッションイベント機能に、テーブル１７に示すようなＲＴＡＳＥＳＳＩＯＮＡＮＮＯＵＮＣＥ．ｒｅｑｕｅｓｔメッセージ４３２を送信する。発信側ＳＴＡのＭＬＭＥは、ＲＴＡＳＥＳＳＩＯＮＡＮＮＯＵＮＣＥ．ｒｅｑｕｅｓｔメッセージを受け取ると、ＳＥＳＳＩＯＮＡＮＮＯＵＮＣＥ．ｒｅｑｕｅｓｔメッセージ内のＲＴＡセッション情報を収集して受信側ＳＴＡにＲＴＡセッション告知要求フレーム４３４を送信する。ＲＴＡセッション告知要求フレームのフォーマットは図２５に示す。受信側ＳＴＡのＭＬＭＥは、このフレームを受け取り、ＭＬＭＥ ＳＡＰインターフェイスを介して自機のＳＭＥに対し、テーブル１８に示すようなＲＴＡＳＥＳＳＩＯＮＡＮＮＯＵＮＣＥ．ｃｏｎｆｉｒｍメッセージ３４８を生成する。

発信側ＳＴＡ及び受信側ＳＴＡの両方のＳＭＥは、ＲＴＡセッション開始結果を認識する（４３８、４４２）。これらのＳＭＥは、ＲＴＡＳＥＳＳＩＯＮＩＮＩＴＥＶＥＮＴ．ｃｏｎｆｉｒｍメッセージ４４０、４４４を介してそれぞれのＡＰＰ層に結果を転送し、これによってＲＴＡセッション開始は完了する（４４６）。ＲＴＡＳＥＳＳＩＯＮＩＮＩＴＥＶＥＮＴ．ｃｏｎｆｉｒｍメッセージはテーブル６に示す。

テーブル１１に、図５のネットワークトポロジを検討する際にＳＴＡ０におけるＲＴＡセッション開始手順によって作成されるＲＴＡセッションテーブルの例を示す。このテーブル内のＲＴＡセッションは、図１４にリストした全ての情報を含むことができる。ＲＴＡセッションテーブルを理解しやすくするために、このテーブルは図１４にリストしたＲＴＡセッション情報の一部しか含んでいない。テーブル１１に示すようなＳＴＡ０（ＡＰ）におけるＲＴＡセッションテーブルは、３つのＲＴＡセッションを含む。テーブル内の各列はＲＴＡセッションを表す。セッションＩＤは、インデックス番号（「＃」）に単純化されている。

第１のセッションＩＤ列は、ＳＴＡ０からＳＴＡ２にＲＴＡトラフィックを送信するＲＴＡセッション１（単純化されたセッションＩＤ）を表す。ＲＴＡセッション１は、１ｍｓ（セッション開始時点）で開始して９００ｍｓ（セッション終了時点）で終了する。ＳＴＡ０は、ＲＴＡセッションがトラフィックを生成する度に、チャネル時間（時間割り当てオプション）、ＲＵ（ＲＵ割り当てオプション）及び空間ストリーム（ＳＳ割り当てオプション）を割り当てる完全な柔軟性を有する。ＲＴＡセッション１の周期は０ｍｓであり、すなわちＲＴＡセッション１は１０ｍｓ毎にＲＴＡトラフィックを生成する。ＲＴＡ優先度は５であり、これはＶＩ待ち行列を通じて送信される。セッション状態はアクティブであり、すなわちＲＴＡセッション開始は正常に完了し、セッションはＲＴＡパケットを生成している。

第２のセッションＩＤ列は、ＳＴＡ３からＳＴＡ０にＲＴＡトラフィックを送信するＲＴＡセッション２を表す。ＲＴＡセッション２は、３ｍｓで開始して８００ｍｓで終了する。ＳＴＡ０は、ＲＴＡセッションがトラフィックを生成する度にチャネル時間（時間割り当てオプション）、ＲＵ（ＲＵ割り当てオプション）を割り当てる完全な柔軟性を有するが、空間ストリーム（ＳＳ割り当てオプション）は固定されていなければならない。ＲＴＡセッション２の周期は２０ｍｓであり、すなわちＲＴＡセッション２は２０ｍｓ毎にＲＴＡトラフィックを生成する。ＲＴＡ優先度は５であり、これはＶＩ待ち行列を通じて送信される。セッション状態はアクティブであり、すなわちＲＴＡセッション開始は正常に完了して、セッションはＲＴＡパケットを生成している。

第３のセッションＩＤ列は、ＳＴＡ４からＳＴＡ０にＲＴＡトラフィックを送信するＲＴＡセッション３を表す。ＲＴＡセッション３は、３ｍｓで開始して７００ｍｓで終了する。ＳＴＡ０は、ＲＴＡセッションがトラフィックを生成する度に、チャネル時間（時間割り当てオプション）、ＲＵ（ＲＵ割り当てオプション）及び空間ストリーム（ＳＳ割り当てオプション）を割り当てる完全な柔軟性を有する。ＲＴＡセッション３の周期は０ｍｓであり、すなわちＲＴＡセッション３は定期的にＲＴＡトラフィックを生成しない。ＲＴＡ優先度は、他の２つのＲＴＡセッションよりも高い６である。このＲＴＡセッションによって生成されるパケットは、ＶＯ待ち行列を通じて送信される。セッション状態はアクティブであり、すなわちＲＴＡセッション開始は正常に完了して、セッションはＲＴＡパケットを生成している。

図１９に、ＲＴＡセッション開始が発信側ＳＴＡによって拒絶される実施形態例４７０を示す。図１８Ａ及び図１８Ｂに示すように、発信側においてＡＰＰ、ＳＭＥ及びＭＬＭＥ間の通信が発生して、ＳＭＥが測定値を取りまとめる（３４０）時点までＡＰＰ層からＳＭＥ及びＭＬＭＥへの通信が行われ、この例では、図１８Ａ及び図１８Ｂのように開始を受け入れると決定する代わりに開始を拒絶すると決定する（４７２）。ＳＭＥは、ＩｎｉｔｉａｔｉｏｎＳｕｃｃｅｓｓフィールドが「０」に設定されたＲＴＡＳＥＳＳＩＯＮＩＮＩＴＥＶＥＮＴ．ｃｏｎｆｉｒｍメッセージ４７４をＡＰＰに受け渡し、従ってＡＰＰ層におけるＲＴＡユーザは、このメッセージを受け取った時点でＲＴＡセッション開始に失敗した（４７６）ことが分かる。

図２０Ａ及び図２０Ｂに、ＲＴＡセッション開始が受信側ＳＴＡによって拒絶される実施形態例４９０を示す。図１８Ａ及び図１８Ｂと同様に、図２０Ｂにおいて発信側でＡＰＰ、ＳＭＥ及びＭＬＭＥの間の通信が発生して、ＳＭＥが測定値を取りまとめる（３４０）時点までＡＰＰ層からＳＭＥ及びＭＬＭＥへの通信が行われ、ここではＳＭＥが、受信側ＡＰＰにセッション開始を要求すると決定する（４９２）。ＭＬＭＥにＲＴＡＳＥＳＳＩＯＮＩＮＩＴ．ｒｅｑｕｅｓｔメッセージ４９４が送信され、ＭＬＭＥが受信側のＭＬＭＥに対してＲＴＡセッション開始要求フレーム４９６を生成する。受信側ＭＬＭＥは、この入力を受け取って、そのＳＭＥに対してＲＴＡＳＥＳＳＩＯＮＩＮＩＴ．ｉｎｄｉｃａｔｉｏｎメッセージ４９８を生成し、ＳＭＥは、さらにＡＰＰ層に対してＲＴＡＳＥＳＳＩＯＮＩＮＩＴＥＶＥＮＴ．ｉｎｄｉｃａｔｅメッセージ５００を生成する。ＡＰＰ層は、開始を拒絶すると決定して（５０２）、そのＳＭＥに開始が拒絶されることを示すＲＴＡＳＥＳＳＩＯＮＩＮＩＴＥＶＥＮＴ．ｒｅｓｐｏｎｓｅメッセージ５０４を送信し、ＳＭＥは、そのＭＬＭＥにＲＴＡＳＥＳＳＩＯＮＩＮＩＴ．ｒｅｓｐｏｎｓｅメッセージ５０６を送信し、ＭＬＭＥは、発信局のＭＬＭＥにＲＴＡセッション開始応答フレーム５０８を送信する。発信側ＭＬＭＥは、そのＳＭＥにＲＴＡ ＳＥＳＳＩＯＮＩＮＩＴ．ｃｏｎｆｉｒｍメッセージ５１０を送信し、ＳＭＥは、ＡＰＰ層に開始拒絶の指示を含むＲＴＡＳＥＳＳＩＯＮＩＮＩＴＥＶＥＮＴ．ｃｏｎｆｉｒｍメッセージ５１２を送信し、ＡＰＰ層はＲＴＡセッション開始に失敗する（５１４）。

テーブル１２に、ＳＴＡ０とＳＴＡ１との間で新たなＲＴＡセッションが開始された後のＳＴＡ０におけるＲＴＡセッションテーブルの例を示す。開始手順前のＲＴＡセッションテーブルはテーブル１１に示す。ここでは、ＲＴＡセッションテーブルに新たなＲＴＡセッション４が挿入されている。セッションＩＤは、単純化されたＲＴＡセッション識別情報を表す。新たなＲＴＡセッションでは、ＳＴＡ０によってセッション開始が拒絶されたので、セッション状態がエラーである。

４．５．２．２．ＲＴＡセッション再開
図２１Ａ及び図２１Ｂに、ＲＴＡセッション再開手順の実施形態例５３０を示す。発信側ＳＴＡは、受信側ＳＴＡによって開始要求が拒絶された時にＲＴＡセッションを再開することができる。この図には、ＲＴＡセッション再開のための２つのＳＴＡ間におけるメッセージ交換を示す。ＲＴＡセッション再開手順は、両方の側においてＲＴＡ ＫＰＩ測定手順が省略される点を除き、図１５Ａ～図１５Ｃに示すＲＴＡセッション開始の完全な手順と同じである。ＳＴＡは、メッセージ内のＭｅａｓｕｒｅｍｅｎｔＩｎｄｉｃａｔｉｏｎパラメータを「０」に設定することによって測定が不要であることを示すことができる。

発信側ＳＴＡのＲＴＡユーザは、ＲＴＡセッションを開始すると決定（判定）（５３２）すると、そのＳＭＥにＲＴＡＳＥＳＳＩＯＮＥＶＥＮＴ．ｒｅｑｕｅｓｔメッセージ５３４を送信する。このメッセージは測定が不要であるとの情報を含んでいるので、ＳＭＥは直ちにＲＴＡセッションを開始し（５３６）、ＭＬＭＥ ＳＡＰインターフェイスを介してＭＬＭＥにおけるＲＴＡセッションイベント機能にＲＴＡＳＥＳＳＩＯＮＩＮＩＴ．ｒｅｑｕｅｓｔメッセージ５３８を送信する。ＲＴＡＳＥＳＳＩＯＮＩＮＩＴ．ｒｅｑｕｅｓｔメッセージのフォーマットについてはテーブル７で説明する。

発信側ＳＴＡのＭＬＭＥは、ＲＴＡＳＥＳＳＩＯＮＩＮＩＴ．ｒｅｑｕｅｓｔメッセージを受け取ると、ＲＴＡＳＥＳＳＩＯＮＩＮＩＴ．ｒｅｑｕｅｓｔメッセージ内のＲＴＡセッション情報を収集し、受信側ＳＴＡのＭＬＭＥにＲＴＡセッション開始要求フレーム５４０を送信する。受信側ＳＴＡのＭＬＭＥは、このフレームを受け取り、ＭＬＭＥ ＳＡＰインターフェイスを介して、そのＳＭＥに対してテーブル８に示すようなＲＴＡＳＥＳＳＩＯＮＩＮＩＴ．ｉｎｄｉｃａｔｉｏｎメッセージ５４２を生成する。

次に、受信側ＳＭＥは、受信側ＳＴＡのＡＰＰ層のＲＴＡユーザに、テーブル４に示すようなＲＴＡＳＥＳＳＩＯＮＩＮＩＴＥＶＥＮＴ．ｉｎｄｉｃａｔｅメッセージ５４４を送信する。受信側ＳＴＡのＡＰＰ層におけるＲＴＡユーザは、開始イベントを許可すると決定した場合、再びＳＭＥ層に対してテーブル５に示すようなＲＴＡＳＥＳＳＩＯＮＩＮＩＴＥＶＥＮＴ．ｒｅｓｐｏｎｓｅメッセージ５４８を生成する。ＡＰＰ層が開始を継続すると決定したので、ＲＴＡユーザは、この応答メッセージ内でＲＴＡＳＥＳＳＩＯＮＩＮＩＴＥＶＥＮＴ．ｒｅｓｐｏｎｓｅメッセージ５４８内のＦｏｌｌｏｗＥｖｅｎｔフィールドを「１」に設定している。

その後、ＳＭＥは、図２１Ｂで分かるようにＲＴＡセッション開始手順に従い続け、発信側から示されたように測定を行うことなく進むことができる。ＲＴＡセッション開始を認めるとの決定が行われる（５５２）。受信側ＳＴＡのＳＭＥは、そのＭＬＭＥにフィードバック情報を含むＲＴＡＳＥＳＳＩＯＮＩＮＩＴ．ｒｅｓｐｏｎｓｅメッセージ５５４を送信する。ＲＴＡＳＥＳＳＩＯＮＩＮＩＴ．ｒｅｓｐｏｎｓｅメッセージのフォーマットについてはテーブル９で説明する。次に、受信側ＳＴＡのＭＬＭＥは、発信側ＳＴＡにＲＴＡセッション開始応答フレーム５５６を送信する。発信側ＳＴＡのＭＬＭＥは、このフレームを受け取って、そのＳＭＥにテーブル１０に示すようなＲＴＡＳＥＳＳＩＯＮＩＮＩＴ．ｃｏｎｆｉｒｍメッセージ５５８を送信し、ＳＭＥはセッション開始合意を認識するようになる（５６０）。その後、発信側のＳＭＥは、ＲＴＡＳＥＳＳＩＯＮＩＮＩＴＥＶＥＮＴ．ｃｏｎｆｉｒｍメッセージ５６２の送信を通じてＲＴＡセッションの開始に成功したか否かをＲＴＡユーザに通知してＲＴＡセッション開始を完了する（５６４）。なお、受信側のＳＭＥも同様にセッション開始の合意を認識するようになり（５６６）、そのＡＰＰ層におけるユーザにＲＴＡＳＥＳＳＩＯＮＩＮＩＴＥＶＥＮＴ．ｃｏｎｆｉｒｍメッセージ５６８を送信する。

テーブル１３に、ＳＴＡ０とＳＴＡ１との間でＲＴＡセッション４が再開された後のＳＴＡ０におけるＲＴＡセッションテーブルの例を示す。開始手順前のＲＴＡセッションテーブルはテーブル１２に示す。ＲＴＡセッション４の開始は、図１４に示すようなＲＴＡセッション情報のコメントフィールドでセッション開始時点を引き延ばすように提案されている。従って、この事例では、新たなセッション開始時点でＳＴＡ１及びＳＴＡ０によってＲＴＡセッション４が再開される。ＳＴＡ０は、ＲＴＡセッション４の再開を認める。

４．５．２．３．ＲＴＡセッション破棄
図２２に、発信側ＳＴＡと受信側ＳＴＡとの間でＲＴＡセッション破棄を実行する手順の実施形態例５９０を示す。発信側ＳＴＡのＲＴＡユーザは、ＲＴＡセッションを破棄（終了／クローズ）すると決定（５９２）すると、そのＳＭＥにＲＴＡＳＥＳＳＩＯＮＤＥＳＴＲＵＣＴ．ｒｅｑｕｅｓｔメッセージ５９４を送信する。すると、発信側ＳＴＡのＳＭＥにおけるＲＴＡセッション管理はセッションの破棄を開始し（５９６）、ＭＬＭＥにおけるＲＴＡセッションイベント機能にＭＬＭＥ ＳＡＰインターフェイスを介してＲＴＡＳＥＳＳＩＯＮＤＥＳＴＲＵＣＴ．ｒｅｑｕｅｓｔメッセージ５９８を送信する。ＲＴＡＳＥＳＳＩＯＮＤＥＳＴＲＵＣＴ．ｒｅｑｕｅｓｔメッセージのフォーマットについてはテーブル１４で説明する。発信側ＳＴＡのＭＬＭＥは、ＲＴＡＳＥＳＳＩＯＮＤＥＳＴＲＵＣＴ．ｒｅｑｕｅｓｔメッセージを受け取ると、ＲＴＡＳＥＳＳＩＯＮＤＥＳＴＲＵＣＴ．ｒｅｑｕｅｓｔメッセージ内のＲＴＡセッション情報を収集して受信側ＳＴＡにＲＴＡセッション破棄要求フレーム６００を送信する。ＲＴＡセッション破棄要求フレームのフォーマットについては図２３に示す。受信側ＳＴＡのＭＬＭＥは、このフレームを受け取り、ＭＬＭＥ ＳＡＰインターフェイスを介してそのＳＭＥに対してテーブル１５に示すようなＲＴＡＳＥＳＳＩＯＮＤＥＳＴＲＵＣＴ．ｃｏｎｆｉｒｍメッセージ６０２を生成し、これを受信側のＡＰＰ層におけるＲＴＡユーザに転送する（６０４）。

図２３に、ＲＴＡセッション開始要求フレームの実施形態例６１０を示す。フレーム制御フィールドは、フレームのタイプを示す。継続時間フィールドは、ＣＳＭＡ／ＣＡチャネルアクセスに使用されるＮＡＶ情報を含む。ＲＡフィールドは、フレームの受信者のアドレスを含む。ＴＡフィールドは、フレームを送信したＳＴＡのアドレスを含む。アクションフィールドは管理フレームのタイプを示し、この例では管理フレームがＲＴＡセッション破棄要求フレームであることを示す。ＲＴＡセッションＩＤフィールドは、図９に示すＲＴＡセッションの識別情報を示す。

テーブル１６に、ＲＴＡセッション３が破棄された後のＳＴＡ０におけるＲＴＡセッションテーブルの例を示す。開始手順前のＲＴＡセッションテーブルはテーブル１３に示す。

４．５．２．４．ＲＴＡセッション告知
図２４に、ＲＴＡセッション告知を実行する手順の実施形態例６３０を示しており、ここではＳＴＡがそのＲＴＡセッション情報を近隣ＳＴＡに通知することができる。この図には、ＲＴＡセッション情報を共有する２つのＳＴＡ間のメッセージ交換が見られる。１つのＳＴＡが別のＳＴＡとＲＴＡセッションを共有する方法の詳細について以下のように説明する。

発信側ＳＴＡのＡＰＰ層におけるＲＴＡユーザは、ＲＴＡセッションを共有又は告知すると決定（６３２）すると、この発信側ＳＴＡのＳＭＥにおけるＲＴＡセッション管理にＲＴＡＳＥＳＳＩＯＮＡＮＮＯＵＮＣＥ．ｒｅｑｕｅｓｔメッセージ６３４を送信し、ＲＴＡセッション管理はＲＴＡセッションを告知すると決定し（６３６）、ＭＬＭＥ ＳＡＰインターフェイスを介してＭＬＭＥにおけるＲＴＡセッションイベント機能にメッセージ６３８を転送する。ＲＴＡＳＥＳＳＩＯＮＡＮＮＯＵＮＣＥ．ｒｅｑｕｅｓｔメッセージのフォーマットについてはテーブル１７で説明する。

発信側ＳＴＡのＭＬＭＥは、ＲＴＡＳＥＳＳＩＯＮＡＮＮＯＵＮＣＥ．ｒｅｑｕｅｓｔメッセージ６３８を受け取ると、ＲＴＡＳＥＳＳＩＯＮＡＮＮＯＵＮＣＥ．ｒｅｑｕｅｓｔメッセージ内のＲＴＡセッション情報を収集して、受信側ＳＴＡにＲＴＡセッション告知要求フレームを送信する（６４０）。ＲＴＡセッション告知要求フレームのフォーマットは図２５に示す。受信側ＳＴＡのＭＬＭＥは、このフレームを受け取り、そのＳＭＥに対して、ＭＬＭＥ ＳＡＰインターフェイスを介してテーブル１８に示すようなＲＴＡＳＥＳＳＩＯＮＡＮＮＯＵＮＣＥ．ｃｏｎｆｉｒｍメッセージを生成する（６４２）。その後、ＳＭＥは、このメッセージをＡＰＰ層のＲＴＡユーザに転送する（６４４）。

図２５に、以下のフィールドを有するＲＴＡセッション告知フレームフォーマットの実施形態例６５０を示す。フレーム制御フィールドは、フレームのタイプを示す。継続時間フィールドは、ＣＳＭＡ／ＣＡチャネルアクセスに使用されるＮＡＶ情報を含む。ＲＡフィールドは、フレームの受信者のアドレスを含む。ＴＡフィールドは、フレームを送信したＳＴＡのアドレスを含む。アクションフィールドは管理フレームのタイプを示し、この場合は管理フレームがＲＴＡセッション告知フレームであることを示す。

フレームがＲＴＡセッション告知フレームであることがアクションフィールドによって示される場合には、アクションフィールドの後に告知情報（Ａｎｎｏｕｎｃｅｍｅｎｔ Ｉｎｆｏｒｍａｔｉｏｎ）フィールドが続く。告知情報フィールドは、以下のサブフィールドを含む。ＲＴＡセッションＩＤサブフィールドは、ＲＴＡセッションの識別情報を提供する。このＲＴＡセッションＩＤサブフィールドの内容は図９に示す。要件情報サブフィールドは、図１４で説明したようなＲＴＡセッションの要件情報を含む。送信情報サブフィールドは、図１４で説明したようなＲＴＡセッションの送信情報を提供する。状態情報サブフィールドは、図１４で説明したようなＲＴＡセッションの状態情報を含む。

テーブル１９に、ＳＴＡ５がＲＴＡセッション５を確立したことを告知した後のＳＴＡ０におけるＲＴＡセッションテーブルの例を示す。開始手順前のＲＴＡセッションテーブルはテーブル１６に示す。

４．５．３．ＲＴＡ待ち行列管理
図２６Ａ及び図２６Ｂに、ＲＴＡ待ち行列パラメータ設定の実施形態例６７０を示す。本節では、ＳＭＥにおけるＲＴＡ待ち行列管理と、ＭＬＭＥにおけるＲＴＡ待ち行列動作プロトコル機能及びＲＴＡ待ち行列設定フレーム機能との間のインターフェイスを使用して、ＳＴＡがどのように待ち行列パラメータを設定するかの詳細について説明する。この図には、発信側ＳＴＡが受信側ＳＴＡにおける待ち行列のパラメータを設定する際の２つのＳＴＡ間のメッセージ交換を示す。

発信側ＳＴＡが受信側ＳＴＡのＲＴＡ待ち行列パラメータを設定すると決定（６７２）すると、ＡＰＰ層におけるＲＴＡセッション管理がＲＴＡＱＵＥＵＥＰＡＲＡＳＥＴＲＥＱＵＥＳＴ．ｒｅｑｕｅｓｔメッセージ６７４を送信し、このメッセージがＭＬＭＥ ＳＡＰインターフェイスを介してＭＬＭＥにおけるＲＴＡセッションイベント機能に転送される（６７６）。ＲＴＡＱＵＥＵＥＰＡＲＡＳＥＴＲＥＱＵＥＳＴ．ｒｅｑｕｅｓｔメッセージのフォーマットについてはテーブル２０で説明する。

発信側ＳＴＡのＭＬＭＥは、ＲＴＡＱＵＥＵＥＰＡＲＡＳＥＴＲＥＱＵＥＳＴ．ｒｅｑｕｅｓｔメッセージを受け取ると、ＲＴＡＱＵＥＵＥＰＡＲＡＳＥＴＲＥＱＵＥＳＴ．ｒｅｑｕｅｓｔメッセージ内のＲＴＡＱｕｅｕｅＰａｒａを収集して受信側ＳＴＡにＲＴＡ待ち行列パラメータ設定要求フレーム６７８を送信する。ＲＴＡ待ち行列パラメータ設定要求フレームのフォーマットは図２７に示す。受信側ＳＴＡのＭＬＭＥはこのフレームを受け取り、図２６Ｂにおいて、そのＳＭＥに対してＭＬＭＥ ＳＡＰインターフェイスを介してテーブル２１に示すようなＲＴＡＱＵＥＵＥＰＡＲＡＳＥＴＲＥＱＵＥＳＴ．ｉｎｄｉｃａｔｉｏｎメッセージ６８０を生成する。

次に、受信側ＳＴＡのＳＭＥにおけるＲＴＡセッション管理は、ＭＬＭＥ層におけるＲＴＡ待ち行列動作プロトコル機能に、ＲＴＡ待ち行列パラメータ設定６８４を実行するためのＲＴＡＱＵＥＵＥＰＡＲＡＳＥＴ．ｒｅｑｕｅｓｔメッセージ６８２を送信する。ＲＴＡＱＵＥＵＥＰＡＲＡＳＥＴ．ｒｅｑｕｅｓｔメッセージのフォーマットについてはテーブル２４で説明する。次に、ＭＬＭＥは、ＲＴＡＱＵＥＵＥＰＡＲＡＳＥＴ．ｒｅｑｕｅｓｔメッセージ内のＲＴＡＱｕｅｕｅＰａｒａに従って待ち行列パラメータを設定する。

ＭＬＭＥは、待ち行列パラメータ設定を終了した後に、テーブル２５で説明するようなＲＴＡＱＵＥＵＥＰＡＲＡＳＥＴ．ｃｏｎｆｉｒｍメッセージ６８６を送信してパラメータ設定結果を報告する。次に、受信側ＳＴＡのＳＭＥは２つのメッセージを送信する。ＳＭＥは、受信側ＡＰＰ層に、待ち行列のパラメータ更新について通知するＲＴＡＱＵＥＵＥＰＡＲＡＳＥＴＲＥＱＵＥＳＴ．ｃｏｎｆｉｒｍメッセージ６８８を送信する。ＳＭＥは、そのＭＬＭＥにパラメータ設定結果を含むＲＴＡＱＵＥＵＥＰＡＲＡＳＥＴＲＥＱＵＥＳＴ．ｒｅｓｐｏｎｓｅメッセージ６９０も送信する。ＲＴＡＱＵＥＵＥＰＡＲＡＳＥＴＲＥＱＵＥＳＴ．ｒｅｓｐｏｎｓｅメッセージのフォーマットについてはテーブル２２で説明する。次に、受信側ＳＴＡのＭＬＭＥは、発信側ＳＴＡにＲＴＡ待ち行列パラメータ設定応答フレーム６９２を送信する。発信側ＳＴＡのＭＬＭＥは、このフレームを受け取り、そのＳＭＥにテーブル２３に示すようなＲＴＡＱＵＥＵＥＰＡＲＡＳＥＴＲＥＱＵＥＳＴ．ｃｏｎｆｉｒｍメッセージ６９４を送信する。次に、発信側のＳＭＥは、ＲＴＡセッションの開始に成功したか否かについてＲＴＡユーザに通知するメッセージ６９６を転送する。

図２７に、以下のフィールドを有するＲＴＡ待ち行列パラメータ設定要求フレームの実施形態例７１０を示す。フレーム制御フィールドは、フレームのタイプを示す。継続時間フィールドは、ＣＳＭＡ／ＣＡチャネルアクセスに使用されるＮＡＶ情報を含む。ＲＡフィールドは、フレームの受信側のアドレスを含む。ＴＡフィールドは、フレームを送信したＳＴＡのアドレスを含む。アクションフィールドは管理フレームのタイプを示し、この場合は管理フレームがＲＴＡ待ち行列パラメータ設定要求フレームであることを示す。

ＲＴＡ待ち行列パラメータ）フィールドは、以下のサブフィールドを有するＲＴＡ待ち行列パラメータ設定情報を含む。待ち行列タイプ（Ｑｕｅｕｅ Ｔｙｐｅ）サブフィールドは、パラメータを設定すべきであるＶＯ、ＶＩ、ＢＥ、ＢＫなどの待ち行列のタイプを示す。最大バッファサイズ（Ｍａｘ Ｂｕｆｆｅｒ Ｓｉｚｅ）サブフィールドは、待ち行列の最大バッファサイズを示す。最大チャネル時間（Ｍａｘ Ｃｈａｎｎｅｌ Ｔｉｍｅ）サブフィールドは、待ち行列に割り当てることができるチャネル時間の最大比率を示す。最大ＲＴＡセッション数（Ｍａｘ Ｎｕｍｂｅｒ ｏｆ ＲＴＡ Ｓｅｓｓｉｏｎｓ）サブフィールドは、パケットがＲＴＡ待ち行列内で待機できる最大ＲＴＡセッション数を示す。有効期限サブフィールドは、待ち行列内のパケットの有効期限を示し、有効期限が満了するとパケットは破棄される。並べ替え方法（Ｓｏｒｔｉｎｇ Ｍｅｔｈｏｄ）サブフィールドは、待ち行列内のパケットの並べ替えにおいて使用される方法を示す。待ち行列チャネル時間割り当て（Ｑｕｅｕｅ Ｃｈａｎｎｅｌ Ｔｉｍｅ Ａｌｌｏｃａｔｉｏｎ）サブフィールドは、待ち行列がパケット送信を許可される時間を示し、周期、開始時点、各期間の継続時間及び終了時点のためのサブフィールドと共に示す。

図２８に、以下のフィールドを有するＲＴＡ待ち行列パラメータ設定応答フレームの実施形態例７３０を示す。フレーム制御フィールドは、フレームのタイプを示す。継続時間フィールドは、ＣＳＭＡ／ＣＡチャネルアクセスに使用されるＮＡＶ情報を含む。ＲＡフィールドは、フレームの受信側のアドレスを含む。ＴＡフィールドは、フレームを送信したＳＴＡのアドレスを含む。アクションフィールドは管理フレームのタイプを示し、この場合は管理フレームがＲＴＡ待ち行列パラメータ設定応答フレームであることを示す。ＲＴＡ待ち行列パラメータ設定結果（ＲＴＡ Ｑｕｅｕｅ Ｐａｒａｍｅｔｅｒ ｓｅｔｔｉｎｇ ｒｅｓｕｌｔ）フィールドは、ＲＴＡ待ち行列パラメータ設定に成功したか否かを示す。

図２９及び図３０に、待ち行列パラメータの設定に応答するＲＴＡ待ち行列動作の実施形態例７５０、７７０を示す。

図２９には、ＲＴＡパケットを重要度指標によって並べ替える事例を示す。この図では、ＳＴＡがそのＶＩ待ち行列内のパケットの送信順を変更するためにどのように並べ替え方法を設定するかの詳細について説明する。ＶＩ待ち行列は、パケットをＲＴＡ優先度によって並べ替え（７５２）、待ち行列内の最も優先度の高いパケットが最初に送信されることが分かる。この図には、ＳＴＡがパケットを満了時間によって並べ替える（７５４）ように並べ替え方法を変更する（７５６）例を示しており、ここでは最も満了時間の近いパケットが最初に送信されるようなパケットの異なる並べ替え順を示す。

図３０には、局が異なる待ち行列にどのようにしてチャネル時間を割り当てるかについての例を示す。ＳＴＡは、ＥＤＣＡ内のＶＯ待ち行列７７４、ＶＩ待ち行列７７６、ＢＥ待ち行列７７８、ＢＫ待ち行列７８０などの異なる待ち行列に、周期７７２毎に別個のチャネル時間を割り当てる。１つの待ち行列にチャネル時間が割り当てられると、ＳＴＡはこの待ち行列からのみパケットを送信する。

４．５．４．ＲＴＡ ＫＰＩ測定
４．５．４．１．一般的シナリオ
本節では、ＳＭＥにおけるＲＴＡセッション管理と、ＭＬＭＥにおけるＲＴＡ ＫＰＩ測定プロトコル機能及びＲＴＡ ＫＰＩ測定フレーム機能との間のインターフェイスを使用することによって局がどのようにＲＴＡ ＫＰＩを測定するかの詳細について説明する。

図３１に、発信側のＭＡＣ層と受信側のＭＡＣ層との間のＲＴＡ ＫＰＩ測定プロセスのシナリオ例において、発信側ＳＴＡが受信側ＳＴＡにおけるＲＴＡ ＫＰＩ測定を要求する際のメッセージ交換を示す実施形態例７９０を示す。

発信側ＳＴＡのＡＰＰ層におけるＲＴＡユーザは、受信側ＳＴＡにおけるＲＴＡ ＫＰＩ測定を要求すると決定（７９２）すると、発信側ＳＴＡのＳＭＥにおけるＲＴＡセッション管理にＲＴＡＫＰＩＭＲＥＱＵＥＳＴ．ｒｅｑｕｅｓｔメッセージ７９４を送信し、ＲＴＡセッション管理は、ＭＬＭＥ ＳＡＰインターフェイスを介してＭＬＭＥにおけるＲＴＡ ＫＰＩ測定フレーム機能にこのメッセージを転送する（７９６）。ＲＴＡＫＰＩＭＲＥＱＵＥＳＴ．ｒｅｑｕｅｓｔメッセージのフォーマットについてはテーブル２６で説明する。発信側ＳＴＡのＭＬＭＥは、ＲＴＡＫＰＩＭＲＥＱＵＥＳＴ．ｒｅｑｕｅｓｔメッセージを受け取ると、ＲＴＡＫＰＩＭＲＥＱＵＥＳＴ．ｒｅｑｕｅｓｔメッセージ７９６内のＲＴＡ ＫＰＩ測定方法及び報告方法を収集し、受信側ＳＴＡのＭＬＭＥにＲＴＡ ＫＰＩ測定要求フレーム７９８を送信する。ＲＴＡ ＫＰＩ測定要求フレームのフォーマットは図３２に示す。受信側ＳＴＡのＭＬＭＥは、このフレームを受け取り、そのＳＭＥに対してＭＬＭＥ ＳＡＰインターフェイスを介してテーブル２７に示すようなＲＴＡＫＰＩＭＲＥＱＵＥＳＴ．ｉｎｄｉｃａｔｉｏｎメッセージ８００を生成する。

次に、受信側ＳＴＡのＳＭＥにおけるＲＴＡセッション管理は、ＭＬＭＥ層におけるＲＴＡ ＫＰＩ測定プロトコル機能にＲＴＡＫＰＩＭＥＡＳＵＲＥ．ｒｅｑｕｅｓｔメッセージ８０２を受け渡す。ＲＴＡＫＰＩＭＥＡＳＵＲＥ．ｒｅｑｕｅｓｔメッセージのフォーマットについてはテーブル３０で説明する。次に、ＭＬＭＥは、ＲＴＡ ＫＰＩ測定プロセス８０４においてＲＴＡ ＫＰＩの測定を開始する。ＭＬＭＥは、ＲＴＡ ＫＰＩ測定を終了した後に、テーブル３１で説明するようなＲＴＡＫＰＩＭＥＡＳＵＲＥ．ｃｏｎｆｉｒｍメッセージ８０６を送信して測定結果を報告する。

次に、受信側ＳＴＡのＳＭＥは、ＫＰＩ測定報告を取りまとめ（８０８）、そのＭＬＭＥに測定結果を含むＲＴＡＫＰＩＭＲＥＰＯＲＴ．ｒｅｑｕｅｓｔメッセージ８１０を送信する。ＲＴＡＫＰＩＭＲＥＰＯＲＴ．ｒｅｓｐｏｎｓｅメッセージのフォーマットについてはテーブル２８で説明する。次に、受信側ＳＴＡのＭＬＭＥは、発信側ＳＴＡにＲＴＡ ＫＰＩ測定報告フレーム８１２を送信する。ＲＴＡ ＫＰＩ測定報告フレームのフォーマットは図３３に示す。発信側ＳＴＡのＭＬＭＥは、このフレームを受け取り、そのＳＭＥにテーブル２９に示すようなＲＴＡＫＰＩＭＲＥＰＯＲＴ．ｃｏｎｆｉｒｍメッセージ８１４を送信する。その後、発信側のＳＭＥは、ＲＴＡユーザにこのメッセージを転送（８１６）してＲＴＡ ＫＰＩ測定結果を提供する。

図３２に、以下のフィールドを有するＲＴＡ ＫＰＩ測定要求フレームフォーマットの実施形態例８３０を示す。フレーム制御フィールドは、フレームのタイプを示す。継続時間フィールドは、ＣＳＭＡ／ＣＡチャネルアクセスに使用されるＮＡＶ情報を含む。ＲＡフィールドは、フレームの受信側のアドレスを含む。ＴＡフィールドは、フレームを送信したＳＴＡのアドレスを含む。アクションフィールドは管理フレームのタイプを示し、この場合は管理フレームがＲＴＡ ＫＰＩ測定要求フレームであることを示す。ＲＴＡ ＫＰＩ測定方法フィールドは、ＲＴＡ ＫＰＩの測定方法を指定する。このフィールドのフォーマットの複数の例については４．５．４．２節で説明する。ＲＴＡ ＫＰＩ報告方法（ＲＴＡ ＫＰＩｓ Ｒｅｐｏｒｔ Ｍｅｔｈｏｄ）フィールドは、ＲＴＡ ＫＰＩの報告方法を指定する。少なくとも１つの実施形態では、このフィールドを１ビット指示として実装することができる。このフィールドが第１の状態（例えば、「１」）に設定されている場合には、ＲＴＡ ＫＰＩ測定が終了した直後に報告が送信され、一方でこのフィールドが第２の状態（例えば、「０」）に設定されている場合には、後で報告が送信される。

図３３に、以下のフィールドを有するＲＴＡ ＫＰＩ測定報告フレームフォーマットの実施形態例８５０を示す。フレーム制御フィールドは、フレームのタイプを示す。継続時間フィールドは、ＣＳＭＡ／ＣＡチャネルアクセスに使用されるＮＡＶ情報を含む。ＲＡフィールドは、フレームの受信側のアドレスを含む。ＴＡフィールドは、フレームを送信したＳＴＡのアドレスを含む。アクションフィールドは管理フレームのタイプを示し、この場合は管理フレームがＲＴＡ ＫＰＩ測定報告フレームであることを示す。ＲＴＡ ＫＰＩ測定報告フィールドは、ＲＴＡ ＫＰＩ測定結果を伝える。このフィールドのフォーマットは、ＲＴＡ ＫＰＩ測定方法に依存する。このフィールドのフォーマットの複数の例については４．５．４．２節に示す。

４．５．４．２．ＲＴＡ ＫＰＩ測定の例
４．５．４．２．１．チャネル帯域幅測定
本節では、ＲＴＡ ＫＰＩ測定手順を使用してチャネル帯域幅を測定する例を示す。

図３４に、チャネル帯域幅測定のためのＲＴＡ ＫＰＩ測定方法フィールドの実施形態例８７０を示す。この図には、ＲＴＡ ＫＰＩ測定手順中にＳＴＡがチャネル帯域幅を測定するように要求する際の、図３２に示すＲＴＡ ＫＰＩ測定方法フィールドの内容を示す。測定コード（Ｍｅａｓｕｒｅ Ｃｏｄｅ）フィールドはＲＴＡ ＫＰＩ測定のタイプを示し、この場合はＲＴＡ ＫＰＩ測定がチャネル帯域幅測定であることを示す。開始時点（Ｓｔａｒｔ Ｔｉｍｅ）フィールドは、測定の開始時点を示す。終了時点（Ｅｎｄ Ｔｉｍｅ）フィールドは、測定の終了時点を示す。タイムアウト（Ｔｉｍｅｏｕｔ）フィールドは、ＳＴＡがパケットを送信してチャネル状態を測定するために必要とする最長間隔を示す。

図３５に、ＳＴＡがＲＴＡ ＫＰＩ測定手順中にチャネル帯域幅測定結果を報告する際の、図３３に示すＲＴＡ ＫＰＩ測定報告フィールドの内容の実施形態例８９０を示す。測定コードフィールドはＲＴＡ ＫＰＩ測定のタイプを示し、この場合はＲＴＡ ＫＰＩ測定がチャネル帯域幅測定であることを示す。チャネル帯域幅測定時間（Ｃｈａｎｎｅｌ ｂａｎｄｗｉｄｔｈ ｍｅａｓｕｒｅｍｅｎｔ ｔｉｍｅ）フィールドは、測定の継続時間を示す。最良スループット変調及び符号化スキーム（ＭＣＳ）（Ｂｅｓｔ ｔｈｒｏｕｇｈｐｕｔ Ｍｏｄｕｌａｔｉｏｎ ａｎｄ Ｃｏｄｉｎｇ Ｓｃｈｅｍｅ （ＭＣＳ））フィールドは、ＳＴＡが最も高いスループットを達成するために使用できる推定ＭＣＳを示す。最良スループットＭＣＳのＰＥＲ（ＰＥＲ ｏｆ ｔｈｅ ｂｅｓｔ ｔｈｒｏｕｇｈｐｕｔ ＭＣＳ）フィールドは、最良スループットＭＣＳを送信に使用する際のパケット誤り率を示す。次善スループットＭＣＳ（Ｓｅｃｏｎｄ ｂｅｓｔ ｔｈｒｏｕｇｈｐｕｔ ＭＣＳ）フィールドは、ＳＴＡが２番目に高いスループットを達成するために使用できる推定ＭＣＳを示す。次善スループットＭＣＳのＰＥＲ（ＰＥＲ ｏｆ ｔｈｅ Ｓｅｃｏｎｄ ｂｅｓｔ ｔｈｒｏｕｇｈｐｕｔ ＭＣＳ）フィールドは、次善スループットＭＣＳを送信に使用する際のパケット誤り率を示す。

最高確率ＭＣＳ（Ｂｅｓｔ ｐｒｏｂａｂｉｌｉｔｙ ＭＣＳ）フィールドは、ＳＴＡが最も低いパケットロスを達成するために使用できる推定ＭＣＳを示す。最高確率ＭＣＳのＰＥＲ（ＰＥＲ ｏｆ Ｂｅｓｔ ｐｒｏｂａｂｉｌｉｔｙ ＭＣＳ）フィールドは、最高確率ＭＣＳを送信に使用する際のパケット誤り率を示す。平均チャネルアクセス遅延（Ａｖｅｒａｇｅ ｃｈａｎｎｅｌ ａｃｃｅｓｓ ｄｅｌａｙ）フィールドは、ＳＴＡがチャネル競合に費やす平均時間を示す。チャネルアクセス遅延の偏差（Ｄｅｖｉａｔｉｏｎ ｏｆ ｃｈａｎｎｅｌ ａｃｃｅｓｓ ｄｅｌａｙ）フィールドは、ＳＴＡがチャネル競合に費やす時間の偏差を示す。送信時間（Ｔｒａｎｓｍｉｓｓｉｏｎ ｔｉｍｅ）フィールドは、測定中におけるＳＴＡの送信時間を示す。推定チャネル帯域幅（Ｅｓｔｉｍａｔｅｄ ｃｈａｎｎｅｌ ｂａｎｄｗｉｄｔｈ）フィールドは、推定されるチャネル帯域幅を示す。限定ではなく一例として、このための１つのアルゴリズムは、（推定チャネル帯域幅）＝（最良スループットＭＣＳ）＊（送信時間）／（チャネル帯域幅測定時間）である。

図３６Ａ及び図３６Ｂに、チャネル帯域幅測定手順の実施形態例９００を示す。ＳＴＡは、開始時点でチャネル帯域幅測定を開始する（９０２）。ＳＴＡがタイムアウト前に送信すべきパケットを待ち行列内に有しているかどうかをチェックする（９０４）。パケットが存在する場合、ＳＴＡは待ち行列からパケットを送信し（９０８）、そうでなければ局はプローブパケットを生成する（９０６）。いずれの場合にもブロック９１０に到達し、ＳＴＡは、ＭＣＳ、チャネルアクセス遅延、パケット誤り及びパケット送信時間を記録する。測定期間が満了したかどうかをチェックする（９１２）。依然として測定期間中である場合、実行はブロック９０４に戻り、ＳＴＡは測定のためのパケットの送信を継続する。そうでなければ期間は満了しており、実行はブロック９１４に到達する。

ブロック９１４において、ＳＴＡは、測定中の記録に従って最良スループットＭＣＳ、次善スループット及び最高確率ＭＣＳを計算する。最良スループットＭＣＳは、ＭＣＳ＊（１－ＰＥＲＭＣＳ）の最大値を有するＭＣＳであり、ここでＰＥＲＭＣＳは、ＭＣＳのパケット誤り率として示される。次善スループットＭＣＳは、ＭＣＳ＊（１－ＰＥＲＭＣＳ）の２番目に大きな値を有するＭＣＳである。最高確率ＭＣＳは、最も低いＰＥＲＭＣＳ値を有するＭＣＳである。ＳＴＡは、図３６Ｂにおいて、測定中のパケットのチャネルアクセス遅延の平均及び偏差も計算する（９１６）。最後に、ＳＴＡは、測定中における総ＳＴＡ送信時間を計算し（９１８）、図３５に示すフォーマットを使用してチャネル帯域幅測定報告を生成（９２０）し、その後にプロセスは終了する（９２２）。

４．５．４．２．２．パケット送信遅延時間
本節では、ＲＴＡ ＫＰＩ測定手順を使用してパケット送信遅延時間を測定する例を示す。

図３７に、パケット遅延時間測定のためのＲＴＡ ＫＰＩ測定方法フィールドフォーマットの実施形態例９３０を示す。この図には、ＳＴＡがＲＴＡ ＫＰＩ測定手順中にパケット送信遅延時間を測定するように要求する際の、図３２に示すＲＴＡ ＫＰＩ測定方法フィールドの内容を示す。測定コードフィールドはＲＴＡ ＫＰＩ測定のタイプを示し、この場合はＲＴＡ ＫＰＩ測定がパケット遅延時間測定であることを示す。開始時点フィールドは、測定の開始時点を示す。終了時点フィールドは、測定の終了時点を示す。タイムアウトフィールドは、ＳＴＡがパケットを送信してチャネル状態を測定するために必要とする最長間隔を示す。ＳＴＡは、タイムアウト前に送信すべきパケットを有していない場合、図３９Ａの９７６に示すように遅延時間測定のためにプローブパケットを生成して送信する。

図３８に、パケット遅延時間測定のためのＲＴＡ ＫＰＩ測定報告フィールドフォーマットの実施形態例９５０を示す。この図には、ＳＴＡがＲＴＡ ＫＰＩ測定手順中にパケット送信遅延時間測定結果を報告する際の、図３３に示すＲＴＡ ＫＰＩ測定報告フィールドの内容を示す。測定コードフィールドはＲＴＡ ＫＰＩ測定のタイプを示し、この場合はパケット遅延時間測定である。平均送信遅延時間（Ａｖｇ ｔｒａｎｓｍｉｓｓｉｏｎ ｌａｔｅｎｃｙ）フィールドは、測定中の平均パケット送信遅延時間を示す。ジッタ（Ｊｉｔｔｅｒ）フィールドは、測定中のパケット送信遅延時間の標準偏差を示す。最大送信遅延時間（Ｍａｘ ｔｒａｎｓｍｉｓｓｉｏｎ ｌａｔｅｎｃｙ）フィールドは、測定中の最大パケット送信遅延時間を示す。

図３９Ａ及び図３９Ｂに、パケット遅延時間測定手順の実施形態例９７０を示す。この例では、説明を単純にするために、送信側ＳＴＡと受信側ＳＴＡとのタイミングがＩＥＥＥ８０２．１ＡＳに基づいて達成できるように十分に同期しているものと想定するが、システムは、本開示の教示から逸脱することなく同期するように、及び／又は同期問題を解決するように構成することができる。

受信側ＳＴＡは、開始時点でチャネル帯域幅測定を開始し（９７２）、図３７に示すＲＴＡ ＫＰＩ測定方法フィールドを含む図３２と同様のフレームを送信することによって送信側ＳＴＡに測定の開始を通知する（９７４）。送信側ＳＴＡがタイムアウト前に送信すべきパケットを待ち行列内に有しているかどうかをチェックする（９７６）。待ち行列内にパケットが存在する場合、送信側ＳＴＡは待ち行列からパケットを送信するように準備する（９８０）。一方で、ブロック９７６において待ち行列内にパケットが存在しないと判定された場合、ＳＴＡは送信すべきプローブパケットを生成する（９７８）。次に、いずれの場合にも実行はブロック９８０に到達し、送信側ＳＴＡは、現在のＴＳＦタイミングスタンプが埋め込まれたパケットを送信する（９８２）。受信側ＳＴＡは、このパケットを受け取ると、パケット内のＴＳＦタイミングと現在のＴＳＦタイミングとの間の差分（デルタ）を計算することによってパケット送信遅延時間を決定することができる（９８４）。

図３９Ｂのチェック９８６において、依然として測定が進行中であるかどうかを判定する。測定が未だ終了していない場合、実行はブロック９７６に戻り、送信側ＳＴＡは測定のためにパケットを送信し続ける。一方で、ブロック９８６において測定期間が満了したと判定された場合、受信側ＳＴＡは、平均遅延時間、ジッタ及び最大遅延時間を計算（９８８）した後に、図３８に示すフォーマットを使用してパケット送信遅延時間測定報告を生成し（９９０）、その後にプロセスは終了する（９９２）。

４．５．４．２．３．チャネル使用量
本節では、ＲＴＡ ＫＰＩ測定手順を実行したことに応答してチャネル使用量を測定する例を示す。

図４０に、ＲＴＡ ＫＰＩ測定手順中にＳＴＡがチャネル使用量を測定するように要求する際チャネル使用量測定を行うための、図３２に示すＲＴＡ ＫＰＩ測定方法フィールドフォーマットの実施形態例１０１０を示す。測定コードフィールドは、ＲＴＡ ＫＰＩ測定のタイプを示す。この事例では、ＲＴＡ ＫＰＩ測定がチャネル使用量測定である。開始時点フィールドは、測定の開始時点を示す。終了時点フィールドは、測定の終了時点を示す。

図４１に、ＲＴＡ ＫＰＩ測定手順中にＳＴＡがパケット送信遅延時間測定結果を報告する際の、図３３に示すＲＴＡ ＫＰＩ測定報告フィールドの内容の実施形態例１０３０を示す。測定コードフィールドはＲＴＡ ＫＰＩ測定のタイプを示し、ここではＲＴＡ ＫＰＩ測定がチャネル使用量測定であることを示す。チャネル帯域幅測定時間フィールドは、測定の継続時間を示す。平均ＮＡＶ時間（Ａｖｇ ＮＡＶ ｔｉｍｅ）フィールドは、測定中のＮＡＶ期間の平均時間を示す。ＮＡＶ時間の偏差（Ｄｅｖｉａｔｉｏｎ ｏｆ ＮＡＶ ｔｉｍｅ）フィールドは、測定中のＮＡＶ期間の時間の偏差を示す。８０２．１１パケットに起因する平均クリアチャネル評価（ＣＣＡ）使用中時間（Ａｖｇ Ｃｌｅａｒ Ｃｈａｎｎｅｌ Ａｓｓｅｓｓｍｅｎｔ（ＣＣＡ） ｂｕｓｙ ｔｉｍｅ ｄｕｅ ｔｏ ８０２．１１ ｐａｃｋｅｔ）フィールドは、測定中の８０２．１１パケット送信に起因するＣＣＡ使用中期間の平均時間を示す。８０２．１１パケットに起因するＣＣＡ使用中時間の偏差（Ｄｅｖｉａｔｉｏｎ ｏｆ ＣＣＡ ｂｕｓｙ ｔｉｍｅ ｄｕｅ ｔｏ ８０２．１１ ｐａｃｋｅｔ）フィールドは、測定中の８０２．１１パケット送信に起因するＣＣＡ使用中期間の時間の偏差を示す。非８０２．１１パケットに起因する平均ＣＣＡ使用中時間（Ａｖｇ ＣＣＡ ｂｕｓｙ ｔｉｍｅ ｄｕｅ ｔｏ ｎｏｎ ８０２．１１ ｐａｃｋｅｔ）フィールドは、測定中の非８０２．１１パケット送信に起因するＣＣＡ使用中期間の平均時間を示す。Ｄｅｖｉａｔｉｏｎ ｏｆ ＣＣＡ ｂｕｓｙ ｔｉｍｅ ｄｕｅ ｔｏ ｎｏｎ ８０２．１１ ｐａｃｋｅｔ（非８０２．１１パケットに起因するＣＣＡ使用中時間の偏差）フィールドは、測定中の非８０２．１１パケット送信に起因するＣＣＡ使用中期間の時間の偏差を示す。平均チャネルアイドル時間（Ａｖｇ ｃｈａｎｎｅｌ ｉｄｌｅ ｔｉｍｅ）フィールドは、測定中のチャネルアイドル期間の平均時間を示す。チャネルアイドル時間の偏差（Ｄｅｖｉａｔｉｏｎ ｏｆ ｃｈａｎｎｅｌ ｉｄｌｅ ｔｉｍｅ）フィールドは、測定中のチャネルアイドル期間の時間の偏差を示す。

図４２に、チャネル使用量測定手順の実施形態例１０５０を示す。送信側ＳＴＡは、開始時点でチャネル使用量測定を開始する（１０５２）。ＳＴＡは、パケットの送信を停止してチャネルをモニタする（１０５４）。ＳＴＡは、ＮＡＶ時間、８０２．１１パケットに起因するＣＣＡ使用中時間、非８０２．１１パケットに起因するＣＣＡ使用中時間、及びチャネルアイドル時間を記録する（１０５６）。ＳＴＡは、測定終了時点で、測定中の記録に従ってＮＡＶ時間の平均及び偏差、８０２．１１パケットに起因するＣＣＡ使用中時間、非８０２．１１パケットに起因するＣＣＡ使用中時間、及びチャネルアイドル時間を計算する（１０５８）。その後、ＳＴＡは、図４１に示すフォーマットを使用してチャネル使用量測定報告を生成し（１０６０）、プロセスは終了する（１０６２）。

４．５．４．２．４．待ち行列状態
本節では、ＲＴＡ ＫＰＩ測定手順を使用して待ち行列状態を測定する例を示す。

図４３に、待ち行列状態測定のためのＲＴＡ ＫＰＩ測定方法フィールドフォーマットの実施形態例１０７０を示す。ＲＴＡ ＫＰＩ測定手順中にＳＴＡが待ち行列状態を測定するように要求する際のＲＴＡ ＫＰＩ測定方法フィールドの内容は図３２に示す。測定コードフィールドはＲＴＡ ＫＰＩ測定のタイプを示し、この場合はＲＴＡ ＫＰＩ測定が待ち行列状態測定であることを示す。開始時点フィールドは測定の開始時点を示し、終了時点フィールドは測定の終了時点を示す。

図４４に、待ち行列状態測定のためのＲＴＡ ＫＰＩ測定報告フィールドフォーマットの実施形態例１０９０を示す。ＲＴＡ ＫＰＩ測定手順中にＳＴＡが待ち行列状態測定結果を報告する際のＲＴＡ ＫＰＩ測定報告フィールドの内容は図３３に示す。測定コードフィールドはＲＴＡ ＫＰＩ測定のタイプを示し、この場合はＲＴＡ ＫＰＩ測定が待ち行列状態測定であることを示す。待ち行列数（Ｎｕｍ ｏｆ Ｑｕｅｕｅｓ）フィールドは、この報告に状態が含まれている待ち行列の数を示す。待ち行列状態（Ｑｕｅｕｅｓ ｓｔａｔｕｓ）フィールド１～Ｎは、待ち行列１～Ｎの待ち行列状態に関する測定結果を示す。状態フィールドは、以下のサブフィールドを含む。待ち行列タイプ（Ｑｕｅｕｅ ｔｙｐｅ）サブフィールドは、待ち行列の識別を示す。最大待ち行列サイズ（Ｍａｘ ｑｕｅｕｅ ｓｉｚｅ）サブフィールドは、測定中の最大待ち行列サイズを示す。最小待ち行列サイズ（Ｍｉｎ ｑｕｅｕｅ ｓｉｚｅ）サブフィールドは、測定中の最小待ち行列サイズを示す。パケット到着率（Ｐａｃｋｅｔ ａｒｒｉｖａｌ ｒａｔｅ）サブフィールドは、測定中に待ち行列に入れられたパケットの比率を示す。パケットサービス率（Ｐａｃｋｅｔ ｓｅｒｖｉｃｅ ｒａｔｅ）サブフィールドは、測定中に待ち行列から出されたパケットの比率を示す。平均待ち行列遅延（Ａｖｇ．ｑｕｅｕｉｎｇ ｄｅｌａｙ）サブフィールドは、測定中の待ち行列内のパケットの平均待ち時間を示す。待ち行列遅延の偏差（Ｄｅｖｉａｔｉｏｎ ｏｆ ｑｕｅｕｉｎｇ ｄｅｌａｙ）サブフィールドは、測定中の待ち行列内のパケットの待ち時間の偏差を示す。

図４５に、待ち行列状態測定手順の実施形態例１１１０を示す。ＳＴＡは、開始時点で待ち行列状態測定を開始する（１１１２）。ＳＴＡは、測定中の各待ち行列の最大待ち行列サイズ、最小待ち行列サイズ、パケット到着率及びパケットサービス率を記録する（１１１４）。ＳＴＡは、測定終了時点で、測定中のパケットの待ち行列遅延の平均及び偏差を計算する（１１１６）。ＳＴＡは、図４４に示すフォーマットを使用して待ち行列状態測定報告を生成し（１１１８）、プロセスは終了する（１１２０）。

４．５．４．２．５．トラフィック分析
本節では、ＲＴＡ ＫＰＩ測定手順を使用したトラフィック分析の例を示す。

図４６に、トラフィック分析のためのＲＴＡ ＫＰＩ測定方法フィールドフォーマットの実施形態例１１３０を示す。ＳＴＡがＲＴＡ ＫＰＩ測定手順中に待ち行列状態の測定を要求する際のＲＴＡ ＫＰＩ測定方法フィールドの内容は図３２に示す。測定コードフィールドはＲＴＡ ＫＰＩ測定のタイプを示し、例えばこの場合はＲＴＡ ＫＰＩ測定が待ち行列状態測定であることを示す。開始時点フィールドは、測定の開始時点を示す。終了時点フィールドは、測定の終了時点を示す。タイムアウトフィールドは、ＳＴＡがパケットを送信してチャネル状態を測定するために必要とする最長間隔を示す。

図４７に、トラフィック分析のためのＲＴＡ ＫＰＩ測定報告フィールドフォーマットの実施形態例１１５０を示す。ＲＴＡ ＫＰＩ測定手順中にＳＴＡがトラフィック分析結果を報告する際のＲＴＡ ＫＰＩ測定報告フィールドの内容は図３３に示す。測定コードフィールドはＲＴＡ ＫＰＩ測定のタイプを示し、この例ではＲＴＡ ＫＰＩ測定がトラフィック分析測定であることを示す。トラフィックタイプ数（Ｎｕｍ ｏｆ ｔｒａｆｆｉｃ ｔｙｐｅｓ）フィールドは、この報告で分析されるトラフィックタイプの数を示す。

トラフィックタイプ状態（Ｔｒａｆｆｉｃ Ｔｙｐｅ Ｓｔａｔｕｓ）フィールド１～Ｎは、各トラフィックタイプの分析結果を示し、以下のサブフィールドを有する。トラフィックタイプ（Ｔｒａｆｆｉｃ ｔｙｐｅ）サブフィールドは、非ＲＴＡトラフィックのアクセスカテゴリ又はＲＴＡトラフィックのＲＴＡ優先度を示す。平均再試行回数（Ａｖｇ． ｒｅｔｒｙ ｃｏｕｎｔ）サブフィールドは、測定中のパケットの平均再試行回数を示す。再試行回数の偏差（Ｄｅｖｉａｔｉｏｎ ｏｆ ｒｅｔｒｙ ｃｏｕｎｔ）サブフィールドは、測定中のパケットの再試行回数の偏差を示す。平均競合時間（Ａｖｇ． ｃｏｎｔｅｎｔｉｏｎ ｔｉｍｅ）サブフィールドは、測定中のパケットの平均競合時間を示す。競合時間の偏差（Ｄｅｖｉａｔｉｏｎ ｏｆ ｃｏｎｔｅｎｔｉｏｎ ｔｉｍｅ）サブフィールドは、測定中のパケットの競合時間の偏差を示す。平均再送時間（Ａｖｇ． ｒｅｔｒａｎｓｍｉｓｓｉｏｎ ｔｉｍｅ）サブフィールドは、第１の再送の開始から最後の再送の終了までの平均時間を示す。再送時間の偏差（Ｄｅｖｉａｔｉｏｎ ｏｆ ｒｅｔｒａｎｓｍｉｓｓｉｏｎ ｔｉｍｅ）サブフィールドは、第１の再送の開始から最後の再送の終了までの時間の偏差を示す。パケット誤り率（Ｐａｃｋｅｔ ｅｒｒｏｒ ｒａｔｅ：ＰＥＲ）サブフィールドは、パケット送信に失敗した確率を示す。総トラフィック量（Ｔｏｔａｌ ａｍｏｕｎｔ ｏｆ ｔｒａｆｆｉｃ）サブフィールドは、測定中の総トラフィック量（バイト）を示す。

図４８に、トラフィック分析手順の実施形態例１１７０を示す。ＳＴＡは、開始時点でトラフィック分析を開始する（１１７２）。ＳＴＡがタイムアウト前に送信すべきパケットを有しているかどうかを判定するチェックを行う（１１７４）。送信すべきパケットが存在する場合、ＳＴＡは、ブロック１１７６においてパケットを送信し、パケットのＡＣ／ＲＴＡ優先度、長さ、再試行回数、競合時間及び再送時間を記録した後でブロック１１７８に到達する。ブロック１１７４において、ＳＴＡがタイムアウト前に送信すべきパケットを有していない場合、又はＳＴＡが１つのパケットの送信を終えた場合、実行はチェック１１７４からブロック１１７８に進む。

ブロック１１７８において、依然として測定期間が進行中であるかどうかをチェックする。測定が終了していない場合、実行はブロック１１７４に戻り、ＳＴＡは測定のために別のパケットを送信しようと試みる。一方で、ブロック１１７８において測定期間が終了したと判定された場合、ＳＴＡは、ブロック１１８０において再試行回数の平均及び偏差、競合時間及び再送時間、パケットロス及び各トラフィックタイプの総量を計算する。ＳＴＡは、図４７に示すフォーマットを使用してトラフィック分析報告を生成し（１１８２）、プロセスは終了する（１１８４）。

４．５．４．３．ＲＴＡ ＫＰＩ測定の用途
図４９に、ＲＴＡ ＫＰＩ測定をＲＴＡパケット送信に使用する場合に測定結果をマルチリンク送信に使用する実施形態例１２１０を示す。この図には、複数のリンク（マルチリンク）を介してＲＴＡパケット送信をスケジュールするためのＲＴＡ ＫＰＩ測定結果の使用方法を示す。この図には複数のリンクを示しており、ここでは限定ではなく一例として、Ｌｉｎｋ１ １２１２、Ｌｉｎｋ２ １２１４、Ｌｉｎｋ３ １２１６及びＬｉｎｋ４ １２１８という４つのリンクが見られる。この図には複数のオプションを示しており、ここでは限定ではなく一例として、オプション＃１ １２２０、オプション＃２ １２２２、オプション＃３ １２２４、及びオプション＃４ １２２６という４つのオプションが見られる。この用途の目的は、図示のようないくつかのマルチリンク送信オプションを発見することである。ＳＴＡがＲＴＡセッションによって生成されたＲＴＡパケットを送信する１つのオプションを使用し、送信失敗率がＲＴＡセッションのパケットロス要件を下回る場合には、ＲＴＡパケットのパケットロスが要件を満たしており、再送は不要である。

各オプションは、マルチリンクを介した重複パケットの同時送信を表す。各リンク上のパケット送信のＭＣＳは固定である。例えば、図のオプション＃１ １２２０は、ＭＣＳ８を使用するリンク１ １２１２と、ＭＣＳ５を使用するリンク２ １２１４とを介したパケット１の同時マルチリンク送信を表す。オプション＃２ １２２２は、ＭＣＳ７を使用するリンク３ １２１６と、ＭＣＳ９を使用するリンク４ １２１８とを介したパケット２の同時マルチリンク送信を示す。ＭＣＳ１０を使用するリンク１ １２１２と、ＭＣＳ１０を使用するリンク２ １２１４と、ＭＣＳ９を使用するリンク４ １２１８とを介した同時マルチリンク送信でのパケット３を示すオプション＃３ １２２４に示すように、１つのオプション内のマルチリンク送信は、送信のために２つよりも多くのリンクを選別することもできる。

あるオプション内で同じリンクを介して重複送信を行うこともできる。例えば、図のオプション＃４ １２２６は、ＭＣＳ１１を使用するリンク１ １２１２と、ＭＣＳ３を使用するリンク３ １２１６とを介したパケット４の同時マルチリンク送信を表す。図では、パケットがリンク１を介して複数回送信されることが分かる。

ＳＴＡは、ＲＴＡ ＫＰＩ測定を使用することによって、１つのオプションを使用する送信失敗率を推定することができる。ｐ_fail（Ｏｐｔｉｏｎ_i）によって示されるオプションｉのマルチリンク送信失敗率は以下の通りであり、

ここでＯｐｔｉｏｎ_iは、Ｏｐｔｉｏｎｉ（ｉ＝１，２，・・・）での送信に使用される一連のリンクを表し、ｐ_fail（ｌｉｎｋ_j）は、リンクｊ（ｊ＝１，２，３，・・・）における送信失敗率を表す。リンクｊにおける送信失敗率は、以下の数式によって計算することができ、

ここでｐ_fail（ＭＣＳ_k，ｌｉｎｋ_j）は、リンクｊ上でＭＣＳｋ（ｋ＝０，１，２，・・・）を使用してパケットを送信する際のパケット誤り率を表し、ｎは重複パケット送信の回数を表す。パケット誤り率は、４．５．４．２．１節で説明したチャネル帯域幅測定によって測定することができる。

ＲＴＡセッションのパケット到着率の場合、ＳＴＡは、オプションを使用してパケット送信又はポーリングをスケジュールすることができる。また、再送が不要であるため、再試行上限を０にすることができる。

５．実施形態の一般的範囲
提示した技術の説明した強化は、様々な無線通信局及び関連するプロトコル内に容易に実装することができる。また、通信局が、１又は２以上のコンピュータプロセッサ装置（例えば、ＣＰＵ、マイクロプロセッサ、マイクロコントローラ、コンピュータ対応ＡＳＩＣなど）、及び命令を記憶する関連するメモリ（例えば、ＲＡＭ、ＤＲＡＭ、ＮＶＲＡＭ、ＦＬＡＳＨ（登録商標）、コンピュータ可読媒体など）を含むように実装されることにより、メモリに記憶されたプログラム（命令）がプロセッサ上で実行されて、本明細書で説明した様々なプロセス法のステップを実行することが好ましいと理解されたい。

当業者は、無線データ通信に関連するステップを実行するコンピュータ装置の使用を認識しているため、単純化のために図にはコンピュータ及びメモリデバイスを示していない。提示した技術は、メモリ及びコンピュータ可読媒体が非一時的であり、従って一時的電子信号を構成しない限り、これらに関して限定するものではない。

また、これらのコンピュータシステムにおけるコンピュータ可読媒体（命令を記憶するメモリ）は「非一時的」なものであり、ありとあらゆる形態のコンピュータ可読媒体を含むが、唯一の例外が一時的伝搬信号であると理解されるであろう。従って、開示した技術は、ランダムアクセス型であるもの（例えば、ＲＡＭ）、定期的なリフレッシュを必要とするもの（例えば、ＤＲＡＭ）、時間と共に劣化するもの（例えば、ＥＥＰＲＯＭ、ディスク媒体）、又は短期間にのみ及び／又は電力の存在時にのみデータを記憶するものを含むいずれかの形態のコンピュータ可読媒体を含むことができ、一時的な電子信号には「コンピュータ可読媒体」という用語が当てはまらないという点が唯一の制約である。

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

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

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

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

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

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

１．ネットワークにおける無線通信装置であって、（ａ）自機の受信エリア内の少なくとも１つの他のローカルエリアネットワーク（ＷＬＡＮ）局とチャネルを介して無線で通信する無線通信回路と、（ｂ）前記ＷＬＡＮ上で動作するように構成された局内の、前記無線通信回路に結合されたプロセッサと、（ｃ）前記プロセッサが実行できる命令を記憶した非一時的メモリとを備え、（ｄ）前記命令は、前記プロセッサによって実行された時に、（ｄ）（ｉ）通信遅延の影響を受けやすいリアルタイムアプリケーション（ＲＴＡ）パケットの通信及び非リアルタイムパケットの通信をサポートするように構成されたＷＬＡＮ局として前記無線通信回路を動作させ、リアルタイムアプリケーション（ＲＴＡ）パケットと非リアルタイムアプリケーション（非ＲＴＡ）パケットとを区別することを含み、（ｄ）（ｉｉ）前記命令は、アプリケーションデータの生成及び受信を行うアプリケーション（ＡＰＰ）層と、エンドツーエンドピア無線通信回路及びネクストホップピア無線通信回路装置へのルートを決定するネットワーク層と、無線媒体アクセスプロトコルを制御する媒体アクセス制御（ＭＡＣ）層と、前記ネクストホップピア無線通信回路との間で物理信号を送受信する物理（ＰＨＹ）層と、新たなリアルタイムアプリケーション（ＲＴＡ）セッションを生成し、ＭＡＣ層管理エンティティ（ＭＬＭＥ）と通信するインターフェイスを有するアプリケーション層とで構成され、前記アプリケーション層が、（ｄ）（ｉｉｉ）前記ＳＴＡの前記アプリケーション（ＡＰＰ）層が所与の一連の要件を有する新たなセッションを開始するように前記ＭＡＣ層に要求する要求を生成することと、（ｄ）（ｉｖ）前記ＭＡＣ層による前記チャネルをモニタし、主要性能指標（ＫＰＩ）を取得して前記ＡＰＰ層への応答を導出することと、（ｄ）（ｖ）前記ＭＡＣ層が前記ＡＰＰ層による新たなセッションを開始するための前記要求を前記ＲＴＡセッション要件及び測定されたＫＰＩに従って受け入れ又は拒絶することと、（ｄ）（ｖｉ）前記新たなセッション開始が拒絶された場合、前記ＡＰＰ層による前記新たなセッション適応要求を調整されたパラメータで再発行することと、をさらに含む１又は２以上のステップを実行する、装置。

２．ネットワークにおける無線通信装置であって、（ａ）自機の受信エリア内の少なくとも１つの他のローカルエリアネットワーク（ＷＬＡＮ）局とチャネルを介して無線で通信する無線通信回路と、（ｂ）前記ＷＬＡＮ上で動作するように構成された局内の、前記無線通信回路に結合されたプロセッサと、（ｃ）前記プロセッサが実行できる命令を記憶した非一時的メモリとを備え、（ｄ）前記命令は、前記プロセッサによって実行された時に、（ｄ）（ｉ）通信遅延の影響を受けやすいリアルタイムアプリケーション（ＲＴＡ）パケットの通信及び非リアルタイムパケットの通信をサポートするように構成されたＷＬＡＮ局として前記無線通信回路を動作させ、リアルタイムアプリケーション（ＲＴＡ）パケットと非リアルタイムアプリケーション（非ＲＴＡ）パケットとを区別することを含み、（ｄ）（ｉｉ）前記命令は、アプリケーションデータの生成及び受信を行うアプリケーション（ＡＰＰ）層と、エンドツーエンドピア無線通信回路及びネクストホップピア無線通信回路装置へのルートを決定するネットワーク層と、無線媒体アクセスプロトコルを制御する媒体アクセス制御（ＭＡＣ）層と、前記ネクストホップピア無線通信回路との間で物理信号を送受信する物理（ＰＨＹ）層と、新たなリアルタイムアプリケーション（ＲＴＡ）セッションを生成し、ＭＡＣ層管理エンティティ（ＭＬＭＥ）と通信するインターフェイスを有するアプリケーション層とで構成され、前記アプリケーション層が、（ｄ）（ｉｉｉ）前記ＳＴＡの前記アプリケーション（ＡＰＰ）層が所与の一連の要件を有する新たなセッションを開始するように前記ＭＡＣ層に要求する要求を生成することと、（ｄ）（ｉｖ）前記ＭＡＣ層による前記チャネルをモニタし、主要性能指標（ＫＰＩ）を取得して前記ＡＰＰ層への応答を導出することと、（ｄ）（ｖ）前記ＭＡＣ層において、前記ＡＰＰ層による新たなセッションを開始するための前記要求を前記ＲＴＡセッション要件及び測定されたＫＰＩに従って受け入れ又は拒絶することと、（ｄ）（ｖｉ）前記ＡＰＰ層による新たなＲＴＡセッションを開始するための前記要求が前記ＭＡＣ層において受け入れられた場合、前記ＡＰＰ層が、前記ＭＡＣ層において新たなＲＴＡセッションを開始して、（Ａ）待ち行列管理を行うためにＲＴＡパケットの有効期限値を設定し、又は（Ｂ）待ち行列管理を行うためにＲＴＡパケットの優先度値を設定し、又は（Ｃ）要求されたＲＴＡパケットの遅延時間を設定し、又は（Ｄ）ＲＴＡパケットの目標パケットロス率を、変調符号化スキーム（ＭＣＳ）及びＲＴＡパケットの再試行上限を調整するための目標パケットロス率として、或いはパケット送信又はマルチリンク送信を重複させるための目標パケットロス率として設定することと、（ｄ）（ｖｉｉ）前記新たなセッション開始が拒絶された場合、前記ＡＰＰ層による新たなセッションを開始するための前記要求を調整されたパラメータで再発行することと、をさらに含む１又は２以上のステップを実行する、装置。

３．ネットワークにおける無線通信方法であって、（ａ）自機の受信エリア内の少なくとも１つの他のローカルエリアネットワーク（ＷＬＡＮ）局とチャネルを介して無線で通信し、通信遅延の影響を受けやすいリアルタイムアプリケーション（ＲＴＡ）パケットの通信及び非リアルタイムパケットの通信をサポートするように構成された無線通信局として無線通信回路を動作させ、リアルタイムアプリケーション（ＲＴＡ）パケットと非リアルタイムアプリケーション（非ＲＴＡ）パケットとを区別することを含み、（ｂ）前記命令は、アプリケーションデータの生成及び受信を行うアプリケーション（ＡＰＰ）層と、エンドツーエンドピア無線通信回路及びネクストホップピア無線通信回路装置へのルートを決定するネットワーク層と、無線媒体アクセスプロトコルを制御する媒体アクセス制御（ＭＡＣ）層と、前記ネクストホップピア無線通信回路との間で物理信号を送受信する物理（ＰＨＹ）層と、新たなリアルタイムアプリケーション（ＲＴＡ）セッションを生成し、ＭＡＣ層管理エンティティ（ＭＬＭＥ）と通信するインターフェイスを有するアプリケーション層とで構成され、前記アプリケーション層が、（ｃ）前記ＳＴＡの前記アプリケーション（ＡＰＰ）層が所与の一連の要件を有する新たなセッションを開始するように前記ＭＡＣ層に要求する要求を生成することと、（ｄ）前記ＭＡＣ層による前記チャネルをモニタし、主要性能指標（ＫＰＩ）を取得して前記ＡＰＰ層への応答を導出することと、（ｅ）前記ＭＡＣ層が前記ＡＰＰ層による新たなセッションを開始するための前記要求を前記ＲＴＡセッション要件及び測定されたＫＰＩに従って受け入れ又は拒絶することと、（ｆ）前記新たなセッション開始が拒絶された場合、前記ＡＰＰ層による新たなセッションを開始するための前記要求を調整されたパラメータで再発行することと、をさらに含み、（ｇ）前記方法は、非一時的媒体上に記憶された命令を実行するプロセッサによって実行される、方法。

４．パケットの送信を実行する無線通信システム／装置であって、アプリケーション層がアプリケーションデータの生成及び受信を行い、ネットワーク層がエンドツーエンドピア通信装置及びネクストホップ無線通信ピア装置へのルートを決定し、ＭＡＣ層が無線媒体アクセスプロトコルを制御し、ＰＨＹ層が前記ネクストホップ無線通信ピア装置との間で物理信号を送受信し、前記アプリケーション層が、ＭＡＣ層管理エンティティと通信するためのインターフェイスを有し、前記アプリケーション層が、前記システム／装置において新たなリアルタイムアプリケーション（ＲＴＡ）セッションを生成し、（ａ）ＳＴＡの前記アプリケーション層（ＡＰＰ層）が、要件を含む新たなセッションを開始するようにＭＡＣ層に要求し、（ｂ）前記ＭＡＣ層が、チャネルをモニタして、前記ＡＰＰ層に対する前記応答を導出するために主要性能指標（ＫＰＩ）を取得し、（ｃ）前記ＭＡＣ層が、前記ＲＴＡセッション要件及び測定されたＫＰＩに従って前記ＡＰＰ層の新たなセッション適応に対する受け入れ又は拒絶を行い、（ｄ）前記新たなセッション開始が拒絶された場合、前記ＡＰＰ層が前記要求を調整されたパラメータで再発行することを含む、無線通信システム／装置。

５．前記命令は、前記プロセッサによって実行された時に、前記ＡＰＰ層が前記ＭＡＣ層において新たなＲＴＡセッションを開始し、待ち行列管理を行うためにＲＴＡパケットの有効期限値を設定することを含む１又は２以上のステップをさらに実行する、いずれかの先行する実施形態の装置、システム又は方法。

６．前記命令は、前記プロセッサによって実行された時に、前記ＡＰＰ層が前記ＭＡＣ層において新たなＲＴＡセッションを開始し、待ち行列管理を行うためにＲＴＡパケットの優先度値を設定することを含む１又は２以上のステップをさらに実行する、いずれかの先行する実施形態の装置、システム又は方法。

７．前記命令は、前記プロセッサによって実行された時に、前記ＡＰＰ層が前記ＭＡＣ層において新たなＲＴＡセッションを開始し、ＲＴＡパケットの目標パケットロス率を設定することを含む１又は２以上のステップをさらに実行する、いずれかの先行する実施形態の装置、システム又は方法。

８．前記命令は、前記プロセッサによって実行された時に、前記局の前記ＭＡＣ層が変調符号化スキーム（ＭＣＳ）及びＲＴＡパケットの再試行上限を調整するための目標パケットロス率として前記目標パケットロス率を設定することを含む１又は２以上のステップをさらに実行する、いずれかの先行する実施形態の装置、システム又は方法。

９．前記命令は、前記プロセッサによって実行された時に、前記局の前記ＭＡＣ層がパケット送信又はマルチリンク送信を重複させるための前記目標パケットロス率として前記目標パケットロス率を設定することを含む１又は２以上のステップをさらに実行する、いずれかの先行する実施形態の装置、システム又は方法。

１０．前記命令は、前記プロセッサによって実行された時に、前記ＡＰＰ層が前記ＭＡＣ層において新たなＲＴＡセッションを開始し、要求されたＲＴＡパケットの遅延時間を設定することを含む１又は２以上のステップをさらに実行する、いずれかの先行する実施形態の装置、システム又は方法。

１１．前記命令は、前記プロセッサによって実行された時に、前記ＭＡＣ層が前記チャネルをモニタして前記チャネルの主要性能指標（ＫＰＩ）を測定することを含む１又は２以上のステップをさらに実行する、いずれかの先行する実施形態の装置、システム又は方法。

１２．前記チャネルの前記主要性能指標（ＫＰＩ）は、帯域幅、変調符号化スキーム（ＭＣＳ）、チャネルアクセス率、パケット誤り率（ＰＥＲ）、及びパケットを送信するためにチャネルが使用される前記時間比から成る前記一群の性能指標から選択される、いずれかの先行する実施形態の装置、システム又は方法。

１３．前記命令は、前記プロセッサによって実行された時に、前記チャネルの前記主要性能指標（ＫＰＩ）を測定する前記ＭＡＣ層が測定結果を利用してパケット送信又はマルチリンク送信を重複させることを含む１又は２以上のステップをさらに実行する、いずれかの先行する実施形態の装置、システム又は方法。

１４．前記命令は、前記プロセッサによって実行された時に、前記チャネルをモニタする前記ＭＡＣ層がパケット遅延時間の前記主要性能指標（ＫＰＩ）に関する統計値を取得し、これらをＲＴＡによって要求された遅延時間と比較することを含む１又は２以上のステップをさらに実行する、いずれかの先行する実施形態の装置、システム又は方法。

１５．前記命令は、前記プロセッサによって実行された時に、前記ＭＡＣ層がパケット遅延時間の前記主要性能指標（ＫＰＩ）に関する前記統計値を取得してこれらをＲＴＡによって要求された遅延時間と比較する際に、前記ＭＡＣ層における前記タイムスタンプを利用することを含む１又は２以上のステップをさらに実行する、いずれかの先行する実施形態の装置、システム又は方法。

１６．前記命令は、前記プロセッサによって実行された時に、パケット遅延時間の前記統計値を取得する前記ＭＡＣ層が送信機及び前記受信機の両方において遅延時間の測定を実行することを含む１又は２以上のステップをさらに実行する、いずれかの先行する実施形態の装置、システム又は方法。

１７．前記命令は、前記プロセッサによって実行された時に、パケット遅延時間の前記統計値を取得する前記ＭＡＣ層が平均再送率の測定を実行することを含む１又は２以上のステップをさらに実行する、いずれかの先行する実施形態の装置、システム又は方法。

１８．前記命令は、前記プロセッサによって実行された時に、前記ＭＡＣ層が前記チャネルをモニタし、チャネル未使用間の平均時間及び標準偏差、並びにチャネル占有間の平均時間を決定する際にパケット到着率の主要性能指標（ＫＰＩ）を測定することを含む１又は２以上のステップをさらに実行する、いずれかの先行する実施形態の装置、システム又は方法。

１９．前記命令は、前記プロセッサによって実行された時に、前記ＭＡＣ層が前記パケット到着率の前記測定を利用して、ＲＴＡセッション中の前記要求されたパケット到着率に基づいてパケット送信をスケジュールし、又はポーリングを実行することを含む１又は２以上のステップをさらに実行する、いずれかの先行する実施形態の装置、システム又は方法。

２０．前記命令は、前記プロセッサによって実行された時に、前記ＭＡＣ層が前記チャネルのモニタリングを実行して待ち行列状態の主要性能指標（ＫＰＩ）を測定することを含む１又は２以上のステップをさらに実行する、いずれかの先行する実施形態の装置、システム又は方法。

２１．前記命令は、前記プロセッサによって実行された時に、前記ＭＡＣ層が前記チャネルのモニタリングを実行して現在の待ち行列サイズを含む前記主要性能指標（ＫＰＩ）を測定することを含む１又は２以上のステップをさらに実行する、いずれかの先行する実施形態の装置、システム又は方法。

２２．前記命令は、前記プロセッサによって実行された時に、前記ＭＡＣ層が前記チャネルをモニタして主要性能指標（ＫＰＩ）を測定するとともに、パケットトラフィックの変化に関する履歴情報を記録することを含む１又は２以上のステップをさらに実行する、いずれかの先行する実施形態の装置、システム又は方法。

２３．前記命令は、前記プロセッサによって実行された時に、前記ＭＡＣ層が前記チャネルをモニタして主要性能指標（ＫＰＩ）を測定し、測定されたＫＰＩをＲＴＡセッション要件と比較し、測定されたＫＰＩが前記ＲＴＡセッション要件を満たしていない場合にＲＴＡセッション開始を拒絶することを含む１又は２以上のステップをさらに実行する、いずれかの先行する実施形態の装置、システム又は方法。

２４．前記命令は、前記プロセッサによって実行された時に、新たなＲＴＡセッションを拒絶した前記ＭＡＣ層が、該ＭＡＣ層において取得された主要性能指標（ＫＰＩ）を前記ＡＰＰ層に報告することを含む１又は２以上のステップをさらに実行する、いずれかの先行する実施形態の装置、システム又は方法。

２５．前記命令は、前記プロセッサによって実行された時に、前記ＭＡＣ層が新たなＲＴＡセッションを拒絶して、新たなＲＴＡセッションを作成するための動作パラメータを前記ＡＰＰ層に提案することを含む１又は２以上のステップをさらに実行する、いずれかの先行する実施形態の装置、システム又は方法。

２６．ＭＡＣ層において新たなＲＴＡセッションを開始する前記ＡＰＰ層は、待ち行列管理のために使用できる前記ＲＴＡパケットの有効期限を設定することができる、いずれかの先行する実施形態の装置、システム又は方法。

２７．ＭＡＣ層において新たなＲＴＡセッションを開始する前記ＡＰＰ層は、待ち行列管理のために使用できる前記ＲＴＡパケットの優先度を設定することができる、いずれかの先行する実施形態の装置、システム又は方法。

２８．ＭＡＣ層において新たなＲＴＡセッションを開始する前記ＡＰＰ層は、前記ＲＴＡパケットの目標パケットロス率を設定することができる、いずれかの先行する実施形態の装置、システム又は方法。

２９．ＭＡＣ層において新たなＲＴＡセッションを開始する前記ＡＰＰ層は、前記ＲＴＡパケットの要求された遅延時間を設定することができる、いずれかの先行する実施形態の装置、システム又は方法。

３０．前記チャネルをモニタするＳＴＡの前記ＭＡＣ層は、帯域幅、ＭＣＳ、チャネルアクセス率、パケット誤り率、及びパケットを送信するためにチャネルが使用される時間比などの、前記チャネルのＫＰＩを測定することができる、いずれかの先行する実施形態の装置、システム又は方法。

３１．前記チャネルをモニタするＳＴＡの前記ＭＡＣ層は、前記パケット遅延時間の統計値などの前記ＫＰＩを測定し、これをＲＴＡによって要求される遅延時間と比較することができる、いずれかの先行する実施形態の装置、システム又は方法。

３２．前記チャネルをモニタするＳＴＡの前記ＭＡＣ層は、チャネル空孔間の前記平均時間、チャネル未使用間の平均時間及びその標準偏差を取得するために前記パケット到着率などの前記ＫＰＩを測定することができる、いずれかの先行する実施形態の装置、システム又は方法。

３３．前記チャネルをモニタするＳＴＡの前記ＭＡＣ層は、前記現在の待ち行列サイズなどの前記待ち行列状態の前記ＫＰＩを測定することができる、いずれかの先行する実施形態の装置、システム又は方法。

３４．前記チャネルをモニタして前記ＫＰＩを取得するＳＴＡの前記ＭＡＣ層は、前記トラフィックの変化の履歴を記録することができる、いずれかの先行する実施形態の装置、システム又は方法。

３５．前記チャネルをモニタして前記ＫＰＩを取得するＳＴＡの前記ＭＡＣ層は、前記測定されたＫＰＩをＲＴＡセッション要件と比較することができ、前記測定されたＫＰＩが前記要件を満たさない場合に前記ＲＴＡセッション開始を拒絶する、いずれかの先行する実施形態の装置、システム又は方法。

３６．新たなＲＴＡセッションを拒絶する前記ＭＡＣ層は、前記ＭＡＣ層において取得された前記ＫＰＩを前記ＡＰＰ層に報告することができる、いずれかの先行する実施形態の装置、システム又は方法。

３７．新たなＲＴＡセッションを拒絶する前記ＭＡＣ層は、新たなＲＴＡセッションを作成する動作パラメータを前記ＡＰＰ層に提案することができる、いずれかの先行する実施形態の装置、システム又は方法。

３８．前記ＲＴＡパケットの前記目標パケットロス率を設定するＳＴＡの前記ＭＡＣ層は、前記目標パケットロス率を使用してＭＣＳ及び前記ＲＴＡパケットの前記再試行上限を調整することができる、いずれかの先行する実施形態の装置、システム又は方法。

３９．前記ＲＴＡパケットの前記目標パケットロス率を設定するＳＴＡの前記ＭＡＣ層は、重複するパケット送信又はマルチリンク送信のために前記目標パケットロス率を使用することができる、いずれかの先行する実施形態の装置、システム又は方法。

４０．前記チャネルの前記ＫＰＩを測定するＳＴＡの前記ＭＡＣ層は、重複するパケット送信又はマルチリンク送信のために前記測定結果を使用することができる、いずれかの先行する実施形態の装置、システム又は方法。

４１．前記パケット遅延時間の前記統計値を取得するＳＴＡの前記ＭＡＣ層は、前記ＭＡＣ層における前記タイムスタンプを使用することができる、いずれかの先行する実施形態の装置、システム又は方法。

４２．前記パケット遅延時間の前記統計値を取得するＳＴＡの前記ＭＡＣ層は、前記送信機及び前記受信機の両方において前記遅延時間を測定することができる、いずれかの先行する実施形態の装置、システム又は方法。

４３．前記パケット遅延時間の前記統計値を取得するＳＴＡの前記ＭＡＣ層は、前記平均再送率を測定することができる、いずれかの先行する実施形態の装置、システム又は方法。

４４．前記パケット到着率を測定するＳＴＡの前記ＭＡＣ層は、前記測定を使用して、ＲＴＡセッションの前記要求パケット到着率に基づいてパケット送信又はポーリングをスケジュールすることができる、いずれかの先行する実施形態の装置、システム又は方法。

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

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

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

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

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

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

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

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

Claims (24)

1. ネットワークにおける無線通信装置であって、
   （ａ）自機の受信エリア内の少なくとも１つの他のローカルエリアネットワーク（ＷＬＡＮ）局とチャネルを介して無線で通信する無線通信回路と、
   （ｂ）前記ＷＬＡＮ上で動作するように構成された局（ＳＴＡ）内の、前記無線通信回路に結合されたプロセッサと、
   （ｃ）前記プロセッサが実行できる命令を記憶した非一時的メモリと、
   を備え、
   （ｄ）前記命令は、前記プロセッサによって実行された時に、
   （ｉ）通信遅延の影響を受けやすいリアルタイムアプリケーション（ＲＴＡ）パケットの通信及び非リアルタイムパケットの通信をサポートするように構成されたＷＬＡＮ局として前記無線通信回路を動作させ、リアルタイムアプリケーション（ＲＴＡ）パケットと非リアルタイムアプリケーション（非ＲＴＡ）パケットとを区別することを含み、
   （ｉｉ）前記命令は、アプリケーションデータの生成及び受信を行うアプリケーション（ＡＰＰ）層と、エンドツーエンドピア無線通信回路及びネクストホップピア無線通信回路装置へのルートを決定するネットワーク層と、無線媒体アクセスプロトコルを制御する媒体アクセス制御（ＭＡＣ）層と、前記ネクストホップピア無線通信回路との間で物理信号を送受信する物理（ＰＨＹ）層と、新たなリアルタイムアプリケーション（ＲＴＡ）セッションを生成し、ＭＡＣ層管理エンティティ（ＭＬＭＥ）と通信するインターフェイスを有するアプリケーション層とで構成され、前記アプリケーション層が、
   （ｉｉｉ）前記ＳＴＡの前記アプリケーション（ＡＰＰ）層が要求を生成し、所与の一連の要件を有する新たなセッションを開始するように前記ＭＡＣ層に要求することと、
   （ｉｖ）前記ＭＡＣ層が前記チャネルをモニタし、主要性能指標（ＫＰＩ）を取得して前記ＡＰＰ層への応答を導出することと、
   （ｖ）前記ＭＡＣ層において、前記ＡＰＰ層による新たなセッションを開始するための前記要求を前記ＲＴＡセッション要件及び測定されたＫＰＩに従って受け入れ又は拒絶することと、
   （ｖｉ）前記新たなセッション開始が拒絶された場合、前記ＡＰＰ層による新たなセッションを開始するための前記要求を調整されたパラメータで再発行することと、
   をさらに含む１又は２以上のステップを実行する、
   ことを特徴とする装置。
2. 前記命令は、前記プロセッサによって実行された時に、前記ＡＰＰ層が前記ＭＡＣ層において新たなＲＴＡセッションを開始し、待ち行列管理を行うためにＲＴＡパケットの有効期限値を設定することを含む１又は２以上のステップをさらに実行する、
   請求項１に記載の装置。
3. 前記命令は、前記プロセッサによって実行された時に、前記ＡＰＰ層が前記ＭＡＣ層において新たなＲＴＡセッションを開始し、待ち行列管理を行うためにＲＴＡパケットの優先度値を設定することを含む１又は２以上のステップをさらに実行する、
   請求項１に記載の装置。
4. 前記命令は、前記プロセッサによって実行された時に、前記ＡＰＰ層が前記ＭＡＣ層において新たなＲＴＡセッションを開始し、ＲＴＡパケットの目標パケットロス率を設定することを含む１又は２以上のステップをさらに実行する、
   請求項１に記載の装置。
5. 前記命令は、前記プロセッサによって実行された時に、前記局の前記ＭＡＣ層が変調符号化スキーム（ＭＣＳ）及びＲＴＡパケットの再試行上限を調整するための目標パケットロス率として前記目標パケットロス率を設定することを含む１又は２以上のステップをさらに実行する、
   請求項４に記載の装置。
6. 前記命令は、前記プロセッサによって実行された時に、前記局の前記ＭＡＣ層がパケット送信又はマルチリンク送信を重複させるための前記目標パケットロス率として前記目標パケットロス率を設定することを含む１又は２以上のステップをさらに実行する、
   請求項４に記載の装置。
7. 前記命令は、前記プロセッサによって実行された時に、前記ＡＰＰ層が前記ＭＡＣ層において新たなＲＴＡセッションを開始し、要求されたＲＴＡパケットの遅延時間を設定することを含む１又は２以上のステップをさらに実行する、
   請求項１に記載の装置。
8. 前記命令は、前記プロセッサによって実行された時に、前記ＭＡＣ層が前記チャネルをモニタして前記チャネルの主要性能指標（ＫＰＩ）を測定することを含む１又は２以上のステップをさらに実行する、
   請求項１に記載の装置。
9. 前記チャネルの前記主要性能指標（ＫＰＩ）は、帯域幅、変調符号化スキーム（ＭＣＳ）、チャネルアクセス率、パケット誤り率（ＰＥＲ）、及びパケットを送信するためにチャネルが使用される前記時間比から成る前記一群の性能指標から選択される、
   請求項８に記載の装置。
10. 前記命令は、前記プロセッサによって実行された時に、前記チャネルの前記主要性能指標（ＫＰＩ）を測定する前記ＭＡＣ層が測定結果を利用してパケット送信又はマルチリンク送信を重複させることを含む１又は２以上のステップをさらに実行する、
    請求項８に記載の装置。
11. 前記命令は、前記プロセッサによって実行された時に、前記チャネルをモニタする前記ＭＡＣ層がパケット遅延時間の前記主要性能指標（ＫＰＩ）に関する統計値を取得し、これらをＲＴＡによって要求された遅延時間と比較することを含む１又は２以上のステップをさらに実行する、
    請求項１に記載の装置。
12. 前記命令は、前記プロセッサによって実行された時に、前記ＭＡＣ層がパケット遅延時間の前記主要性能指標（ＫＰＩ）に関する前記統計値を取得してこれらをＲＴＡによって要求された遅延時間と比較する際に、前記ＭＡＣ層における前記タイムスタンプを利用することを含む１又は２以上のステップをさらに実行する、
    請求項１１に記載の装置。
13. 前記命令は、前記プロセッサによって実行された時に、パケット遅延時間の前記統計値を取得する前記ＭＡＣ層が送信機及び前記受信機の両方において遅延時間の測定を実行することを含む１又は２以上のステップをさらに実行する、
    請求項１２に記載の装置。
14. 前記命令は、前記プロセッサによって実行された時に、パケット遅延時間の前記統計値を取得する前記ＭＡＣ層が平均再送率の測定を実行することを含む１又は２以上のステップをさらに実行する、
    請求項１１に記載の装置。
15. 前記命令は、前記プロセッサによって実行された時に、前記ＭＡＣ層が前記チャネルをモニタし、チャネル未使用間の平均時間及び標準偏差、並びにチャネル占有間の平均時間を決定する際にパケット到着率の主要性能指標（ＫＰＩ）を測定することを含む１又は２以上のステップをさらに実行する、
    請求項１に記載の装置。
16. 前記命令は、前記プロセッサによって実行された時に、前記ＭＡＣ層が前記パケット到着率の前記測定を利用して、ＲＴＡセッション中の前記要求されたパケット到着率に基づいてパケット送信をスケジュールし、又はポーリングを実行することを含む１又は２以上のステップをさらに実行する、
    請求項１５に記載の装置。
17. 前記命令は、前記プロセッサによって実行された時に、前記ＭＡＣ層が前記チャネルのモニタリングを実行して待ち行列状態の主要性能指標（ＫＰＩ）を測定することを含む１又は２以上のステップをさらに実行する、
    請求項１に記載の装置。
18. 前記命令は、前記プロセッサによって実行された時に、前記ＭＡＣ層が前記チャネルのモニタリングを実行して現在の待ち行列サイズを含む前記主要性能指標（ＫＰＩ）を測定することを含む１又は２以上のステップをさらに実行する、
    請求項１７に記載の装置。
19. 前記命令は、前記プロセッサによって実行された時に、前記ＭＡＣ層が前記チャネルをモニタして主要性能指標（ＫＰＩ）を測定するとともに、パケットトラフィックの変化に関する履歴情報を記録することを含む１又は２以上のステップをさらに実行する、
    請求項１に記載の装置。
20. 前記命令は、前記プロセッサによって実行された時に、前記ＭＡＣ層が前記チャネルをモニタして主要性能指標（ＫＰＩ）を測定し、測定されたＫＰＩをＲＴＡセッション要件と比較し、測定されたＫＰＩが前記ＲＴＡセッション要件を満たしていない場合にＲＴＡセッション開始を拒絶することを含む１又は２以上のステップをさらに実行する、
    請求項１に記載の装置。
21. 前記命令は、前記プロセッサによって実行された時に、新たなＲＴＡセッションを拒絶した前記ＭＡＣ層が、該ＭＡＣ層において取得された主要性能指標（ＫＰＩ）を前記ＡＰＰ層に報告することを含む１又は２以上のステップをさらに実行する、
    請求項１に記載の装置。
22. 前記命令は、前記プロセッサによって実行された時に、前記ＭＡＣ層が新たなＲＴＡセッションを拒絶して、新たなＲＴＡセッションを作成するための動作パラメータを前記ＡＰＰ層に提案することを含む１又は２以上のステップをさらに実行する、
    請求項１に記載の装置。
23. ネットワークにおける無線通信装置であって、
    （ａ）自機の受信エリア内の少なくとも１つの他のローカルエリアネットワーク（ＷＬＡＮ）局とチャネルを介して無線で通信する無線通信回路と、
    （ｂ）前記ＷＬＡＮ上で動作するように構成された局（ＳＴＡ）内の、前記無線通信回路に結合されたプロセッサと、
    （ｃ）前記プロセッサが実行できる命令を記憶した非一時的メモリと、
    を備え、
    （ｄ）前記命令は、前記プロセッサによって実行された時に、
    （ｉ）通信遅延の影響を受けやすいリアルタイムアプリケーション（ＲＴＡ）パケットの通信及び非リアルタイムパケットの通信をサポートするように構成されたＷＬＡＮ局として前記無線通信回路を動作させ、リアルタイムアプリケーション（ＲＴＡ）パケットと非リアルタイムアプリケーション（非ＲＴＡ）パケットとを区別することを含み、
    （ｉｉ）前記命令は、アプリケーションデータの生成及び受信を行うアプリケーション（ＡＰＰ）層と、エンドツーエンドピア無線通信回路及びネクストホップピア無線通信回路装置へのルートを決定するネットワーク層と、無線媒体アクセスプロトコルを制御する媒体アクセス制御（ＭＡＣ）層と、前記ネクストホップピア無線通信回路との間で物理信号を送受信する物理（ＰＨＹ）層と、新たなリアルタイムアプリケーション（ＲＴＡ）セッションを生成し、ＭＡＣ層管理エンティティ（ＭＬＭＥ）と通信するインターフェイスを有するアプリケーション層とで構成され、前記アプリケーション層が、
    （ｉｉｉ）前記ＳＴＡの前記アプリケーション（ＡＰＰ）層が要求を生成し、所与の一連の要件を有する新たなセッションを開始するように前記ＭＡＣ層に要求する要求を生成することと、
    （ｉｖ）前記ＭＡＣ層が前記チャネルをモニタし、主要性能指標（ＫＰＩ）を取得して前記ＡＰＰ層への応答を導出することと、
    （ｖ）前記ＭＡＣ層において、前記ＡＰＰ層による新たなセッションを開始するための前記要求を前記ＲＴＡセッション要件及び測定されたＫＰＩに従って受け入れ又は拒絶することと、
    （ｖｉ）前記ＡＰＰ層による新たなＲＴＡセッションを開始するための前記要求が前記ＭＡＣ層において受け入れられた場合、前記ＡＰＰ層が、前記ＭＡＣ層において新たなＲＴＡセッションを開始して、（Ａ）待ち行列管理を行うためにＲＴＡパケットの有効期限値を設定し、又は（Ｂ）待ち行列管理を行うためにＲＴＡパケットの優先度値を設定し、又は（Ｃ）要求されたＲＴＡパケットの遅延時間を設定し、又は（Ｄ）ＲＴＡパケットの目標パケットロス率を、変調符号化スキーム（ＭＣＳ）及びＲＴＡパケットの再試行上限を調整するための目標パケットロス率として、或いはパケット送信又はマルチリンク送信を重複させるための目標パケットロス率として設定することと、
    （ｖｉｉ）前記新たなセッション開始が拒絶された場合、前記ＡＰＰ層による新たなセッションを開始するための前記要求を調整されたパラメータで再発行することと、
    をさらに含む１又は２以上のステップを実行する、
    ことを特徴とする装置。
24. ネットワークにおける無線通信方法であって、
    （ａ）自機の受信エリア内の少なくとも１つの他のローカルエリアネットワーク（ＷＬＡＮ）局とチャネルを介して無線で通信し、通信遅延の影響を受けやすいリアルタイムアプリケーション（ＲＴＡ）パケットの通信及び非リアルタイムパケットの通信をサポートするように構成された無線通信局として無線通信回路を動作させ、リアルタイムアプリケーション（ＲＴＡ）パケットと非リアルタイムアプリケーション（非ＲＴＡ）パケットとを区別することを含み、
    （ｂ）前記命令は、アプリケーションデータの生成及び受信を行うアプリケーション（ＡＰＰ）層と、エンドツーエンドピア無線通信回路及びネクストホップピア無線通信回路装置へのルートを決定するネットワーク層と、無線媒体アクセスプロトコルを制御する媒体アクセス制御（ＭＡＣ）層と、前記ネクストホップピア無線通信回路との間で物理信号を送受信する物理（ＰＨＹ）層と、新たなリアルタイムアプリケーション（ＲＴＡ）セッションを生成し、ＭＡＣ層管理エンティティ（ＭＬＭＥ）と通信するインターフェイスを有するアプリケーション層とで構成され、前記アプリケーション層が、
    （ｃ）前記ＳＴＡの前記アプリケーション（ＡＰＰ）層が要求を生成し、所与の一連の要件を有する新たなセッションを開始するように前記ＭＡＣ層に要求することと、
    （ｄ）前記ＭＡＣ層による前記チャネルをモニタし、主要性能指標（ＫＰＩ）を取得して前記ＡＰＰ層への応答を導出することと、
    （ｅ）前記ＭＡＣ層において、前記ＡＰＰ層による新たなセッションを開始するための前記要求を前記ＲＴＡセッション要件及び測定されたＫＰＩに従って受け入れ又は拒絶することと、
    （ｆ）前記新たなセッション開始が拒絶された場合、前記ＡＰＰ層による新たなセッションを開始するための前記要求を調整されたパラメータで再発行することと、
    をさらに含み、
    （ｇ）前記方法は、非一時的媒体上に記憶された命令を実行するプロセッサによって実行される、
    ことを特徴とする方法。

Images