JP2024506354A

JP2024506354A - マルチリンクを用いる無線通信方法及びこれを用いる無線通信端末

Info

Publication number: JP2024506354A
Application number: JP2023548732A
Authority: JP
Inventors: ゴンジュン・コ; ジュヒョン・ソン; サンヒュン・キム; ジンサム・カク
Original assignee: ウィルスインスティテュートオブスタンダーズアンドテクノロジーインコーポレイティド
Priority date: 2021-02-10
Filing date: 2022-02-10
Publication date: 2024-02-13
Also published as: US20240049304A1; KR20230129510A; WO2022173251A1

Abstract

無線通信システムにおいてＳＴＡ（ｓｔａｔｉｏｎ：ＳＴＡ）がフレームを送信する方法が開示される。本発明に係るＳＴＡは、ＡＰ（ＡｃｃｅｓｓＰｏｉｎｔ）から上りリンク送信を指示するトリガーフレーム（ｔｒｉｇｇｅｒｆｒａｍｅ）を受信し、トリガーフレームに基づいて前記共有されたＴＸＯＰ内で前記ＡＰ及び／又は他のＳＴＡにＰＰＤＵ（ＰｈｙｓｉｃａｌｌａｙｅｒＰｒｏｔｏｃｏｌＤａｔａＵｎｉｔ）を送信する。この時、トリガーフレームは、前記ＡＰによって取得された送信機会（ｔｒａｎｓｍｉｓｓｉｏｎｏｐｐｏｒｔｕｎｉｔｙ：ＴＸＯＰ）の一部又は全部を前記ＳＴＡに共有するために用いられる。また、ＰＰＤＵは、前記ＰＰＤＵの送信のためのＴＸＯＰを指示するデュレーション情報を含み、デュレーション情報は、前記共有されたＴＸＯＰに基づいて設定される。

Description

本発明は、マルチリンクを用いる無線通信方法及びこれを用いる無線通信端末に関し、特に、ＴＸＯＰを設定してデータを送受信するための方法及び端末に関する。

最近、モバイル機器の普及が拡大されるにつれ、それらに速い無線インターネットサービスを提供し得る無線ＬＡＮ（ＷｉｒｅｌｅｓｓＬＡＮ）技術が脚光を浴びている。無線ＬＡＮ技術は、近距離で無線通信技術に基づいてスマートフォン、スマートパッド、ラップトップＰＣ、携帯型マルチメディアプレーヤー、インベデッド機器などのようなモバイル機器を家庭や企業、または特定サービス提供地域において、無線でインターネットに接続し得るようにする技術である。

ＩＥＥＥ（ＩｓｔｉｔｕｔｅｏｆＥｌｅｃｔｒｏｎｉｃｓＥｎｇｉｎｅｅｒｓ）８０２．１１は、２．４ＧＨのｚ周波数を利用した初期の無線ＬＡＮ技術を支援して以来、多様な技術の標準を実用化または開発中である。まず、ＩＥＥＥ８０２．１１ｂは２．４ＧＨｚバンドの周波数を使用し、最高１１Ｍｂｐｓの通信速度を支援する。ＩＥＥＥ８０２．１１ｂの後に商用化されたＩＥＥＥ８０２．１１ａは２．４ＧＨｚバンドではなく５ＧＨｚバンドの周波数を使用することで、相当混雑した２．４ＧＨｚバンドの周波数に比べ干渉への影響を減らしており、ＯＦＤＭ技術を使用して通信速度を最大５４Ｍｂｐｓまで向上させている。しかし、ＩＥＥＥ８０２．１１ａはＩＥＥＥ８０２．１１ｂに比べ通信距離が短い短所がある。そして、ＩＥＥＥ８０２．１１ｇはＩＥＥＥ８０２．１１ｂと同じく２．４ＧＨｚバンドの周波数を使用して最大５４Ｍｐｂｓの通信速度を具現し、下位互換性（ｂａｃｋｗａｒｄｃｏｍｐａｔｉｂｉｌｉｔｙ）を満足していて相当な注目を浴びたが、通信距離においてもＩＥＥＥ８０２．１１ａより優位にある。

そして、無線ＬＡＮで脆弱点として指摘されていた通信速度に関する限界を克服するために制定された技術規格として、ＩＥＥＥ８０２．１１ｎがある。ＩＥＥＥ８０２．１１ｎはネットワークの速度と信頼性を増加させ、無線ネットワークの運営距離を拡張することにその目的がある。詳しくは、ＩＥＥＥ８０２．１１ｎではデータ処理速度が最大５４０Ｍｂｐｓ以上の高処理率（ＨｉｇｈＴｈｒｏｕｇｈｐｕｔ、ＨＴ）を支援し、また、伝送エラーを最小化しデータの速度を最適化するために送信部と受信部の両端共に多重アンテナを使用するＭＩＭＯ（ＭｕｌｔｉｐｌｅＩｎｐｕｔｓａｎｄＭｕｌｔｉｐｌｅＯｕｔｐｕｔｓ）技術を基盤としている。また、この規格はデータの信頼性を上げるために重複する写本を複数個伝送するコーディング方式を使用している。

無線ＬＡＮの普及が活性化され、また、それを使用したアプリケーションが多様化するにつれ、ＩＥＥＥ８０２．１１ｎが支援するデータの処理速度より高い処理率（ＶｅｒｙＨｉｇｈＴｈｒｏｕｇｈｐｕｔ、ＶＨＴ）を支援するための新たな無線ＬＡＮシステムに対する必要性が台頭している。そのうち、ＩＥＥＥ８０２．１１ａｃは５ＧＨｚ周波数で広い帯域幅（８０ＭＨｚ～１６０ＭＨｚ）を支援する。ＩＥＥＥ８０２．１１ａｃ標準は５ＧＨｚ帯域でのみ定義されているが、従来の２．４ＧＨｚ帯域の製品との下位互換性のために、初期１１ａｃチップセットは２．４ＧＨｚ帯域での動作も支援すると考えられる。理論的に、この規格によると多重ステーションの無線ＬＡＮの速度は最小１Ｇｂｐｓ、最大単一リンク速度は最小５００Ｍｂｐｓまで可能になる。これはより広い無線周波数帯域幅（最大１６０ＭＨｚ）、より多いＭＩＭＯ空間的ストリーム（最大８個）、マルチユーザＭＩＭＯ、そして、高い密度の変調（最大２５６ＱＡＭ）など、８０２．１１ｎで受け入れられた無線インタフェースの概念を拡張して行われる。また、従来の２４ＧＨｚ／５ＧＨｚに代わって６０ＧＨｚバンドを利用してデータを伝送する方式として、ＩＥＥＥ８０２．１１ａｄがある。ＩＥＥＥ８０２．１１ａｄはビームフォーミング技術を利用して最大７Ｇｂｐｓの速度を提供する伝送規格であって、大容量のデータや無圧縮ＨＤビデオなど、高いビットレート動画のストリーミングに適合している。しかし、６０ＧＨｚ周波数バンドは障害物の通過が難しく、近距離空間でのデバイスの間でのみ利用可能な短所がある。

一方、８０２．１１ａｃ及び８０２．１１ａｄ以後の無線ＬＡＮ標準として、ＡＰと端末が密集した高密度環境における高効率及び高性能の無線ＬＡＮ通信技術を提供するためのＩＥＥＥ８０２．１１ａｘ（ＨｉｇｈＥｆｆｉｃｉｅｎｃｙＷＬＡＮ，ＨＥＷ）標準が開発され、完了段階にある。８０２．１１ａｘベース無線ＬＡＮ環境では、高密度のステーションとＡＰ（ＡｃｃｅｓｓＰｏｉｎｔ）の存在下に屋内／屋外で高い周波数効率の通信が提供される必要があり、これを具現するための様々な技術が開発されている。

また、高画質ビデオ、実時間ゲームなどのような新しいマルチメディア応用を支援するために、最大送信速度を上げるための新しい無線ＬＡＮ標準を開発し始めた。７世代無線ＬＡＮ標準であるＩＥＥＥ８０２．１１ｂｅ（ＥｘｔｒｅｍｅｌｙＨｉｇｈＴｈｒｏｕｇｈｐｕｔ，ＥＨＴ）では、２．４／５／６ＧＨｚの帯域でより広い帯域幅と増加した空間ストリーム及び多重ＡＰ協調などによって最大で３０Ｇｂｐｓの送信率を支援することを目標に標準開発を進行している。ＩＥＥＥ８０２．１１ｂｅでは３２０ＭＨｚの帯域幅、多重リンク（Ｍｕｌｔｉ－ｌｉｎｋ）動作、多重ＡＰ（Ｍｕｌｔｉ－ＡｃｃｅｓｓＰｏｉｎｔ、Ｍｕｌｔｉ－ＡＰ）動作、及び再伝送動作（ＨｙｂｒｉｄＡｕｔｏｍａｔｉｃＲｅｐｅａｔＲｅｑｕｅｓｔ、ＨＡＲＱ）などの技術が提案されている。

多重リンク動作はその動作方式及び具現方法によって多様な形態に動作される。この際、従来のＩＥＥＥ８０２．１１基盤の無線ＬＡＮ通信動作では発生していなかった問題が発生する可能性があることで、多重リンク動作における詳細な動作方法に対する定義が必要である。

一方、発明の背景になる技術は発明の背景に対する理解を増進するために作成されたものであって、この技術が属する分野における通常の知識を有する者に既に知られている従来技術ではない内容を含む。

本発明は、多重リンク動作において、送信機会（ｔｒａｎｓｍｉｓｓｉｏｎｏｐｐｏｒｔｕｎｉｔｙ：ＴＸＯＰ）の設定を用いてデータを送受信する方法及び装置を提供することにその目的がある。

また、本発明は、ＡＰ（ＡｃｃｅｓｓＰｏｉｎｔ）によって設定されたＴＸＯＰをｎｏｎ－ＡＰＳＴＡに共有することにより、ｎｏｎ－ＡＰＳＴＡがデータを送受信する方法及び装置を提供することにその目的がある。

また、本発明は、共有されたＴＸＯＰ内でｎｏｎ－ＡＰＳＴＡがデータを送受信するためにＮＡＶ（ｎｅｔｗｏｒｋａｌｌｏｃａｔｉｏｎｖｅｃｔｏｒ）を設定するための方法及び装置を提供することにその目的がある。

本明細書で遂げようとする技術的課題は、以上に言及している技術的課題に限定されず、言及していない別の技術的課題は、以下の記載から、本発明の属する技術の分野における通常の知識を有する者に明確に理解されるであろう。

無線通信システムのＳＴＡ（ｓｔａｔｉｏｎ：ＳＴＡ）は、送受信部；及び、前記送受信部を制御するプロセッサを含み、前記プロセッサは、ＡＰ（ＡｃｃｅｓｓＰｏｉｎｔ）から上りリンク送信を指示するトリガーフレーム（ｔｒｉｇｇｅｒｆｒａｍｅ）を受信し、前記トリガーフレームは、前記ＡＰによって取得された送信機会（ｔｒａｎｓｍｉｓｓｉｏｎｏｐｐｏｒｔｕｎｉｔｙ：ＴＸＯＰ）の一部又は全部を前記ＳＴＡに共有するために用いられ、前記トリガーフレームに基づいて、前記共有されたＴＸＯＰ内で前記ＡＰ及び／又は他のＳＴＡにＰＰＤＵ（ＰｈｙｓｉｃａｌｌａｙｅｒＰｒｏｔｏｃｏｌＤａｔａＵｎｉｔ）を送信し、前記ＰＰＤＵは、前記ＰＰＤＵの送信のためのＴＸＯＰを指示するデュレーション情報を含み、前記デュレーション情報は、前記共有されたＴＸＯＰに基づいて設定される。

また、本発明において、前記デュレーション情報によって指示されるデュレーションの終了時点は、前記共有されたＴＸＯＰの終了時点と同一である。

また、本発明において、前記デュレーション情報によって指示されるデュレーションは、前記共有されたＴＸＯＰの終了時点よりも以前に終了する。

また、本発明において、前記ＴＸＯＰ内で前記ＡＰによって送信されるフレームによってＮＡＶ（ｎｅｔｗｏｒｋａｌｌｏｃａｔｉｏｎｖｅｃｔｏｒ）が設定される場合に、前記ＰＰＤＵは、前記共有されたＴＸＯＰ内で前記設定されたＮＡＶに関係なく送信される。

また、本発明において、さらに他のＳＴＡによって前記トリガーフレームに基づいて、前記共有されたＴＸＯＰ内でＮＡＶ及び前記ＮＡＶの終了時間を示すＮＡＶタイムアウト周期（ｔｉｍｅｏｕｔｐｅｒｉｏｄ）が設定された場合に、前記共有されたＴＸＯＰ内で前記ＮＡＶタイムアウト周期が満了しても、前記共有されたＴＸＯＰ内で前記さらに他のＳＴＡによって設定された前記ＮＡＶは、前記ＮＡＶタイムアウト周期の満了によって解除されない。

また、本発明において、前記トリガーフレームは、前記トリガーフレームによる前記ＴＸＯＰの共有の有無を示すサブフィールドを含む。

また、本発明において、前記サブフィールドが前記ＴＸＯＰの共有を示す場合に、前記サブフィールドの値は、前記共有されたＴＸＯＰ内で前記他のＳＴＡと送受信可能であるか否かを示す。

また、本発明において、前記トリガーフレームは、前記トリガーフレームのタイプを示すタイプフィールドを含み、前記ＴＸＯＰの前記一部又は全部の共有は、前記タイプフィールドによる前記トリガーフレームの前記タイプによって設定される。

また、本発明は、ＡＰ（ＡｃｃｅｓｓＰｏｉｎｔ）から上りリンク送信を指示するトリガーフレーム（ｔｒｉｇｇｅｒｆｒａｍｅ）を受信する段階であって、前記トリガーフレームが、前記ＡＰによって取得された送信機会（ｔｒａｎｓｍｉｓｓｉｏｎｏｐｐｏｒｔｕｎｉｔｙ：ＴＸＯＰ）の一部又は全部を前記ＳＴＡに共有するために用いられる、段階；及び、前記トリガーフレームに基づいて、前記共有されたＴＸＯＰ内で前記ＡＰ及び／又は他のＳＴＡにＰＰＤＵ（ＰｈｙｓｉｃａｌｌａｙｅｒＰｒｏｔｏｃｏｌＤａｔａＵｎｉｔ）を送信する段階であって、前記ＰＰＤＵが、前記ＰＰＤＵの送信のためのＴＸＯＰを指示するデュレーション情報を含み、前記デュレーション情報が、前記共有されたＴＸＯＰに基づいて設定される、段階；を含む方法を提供する。

本発明の一実施例によれば、ＡＰによって設定されたＴＸＯＰをｎｏｎ－ＡＰＳＴＡに共有することにより、ｎｏｎ－ＡＰＳＴＡがデータを効率的に送受信できる効果がある。

また、本発明の一実施例によれば、共有されたＴＸＯＰ内でｎｏｎ－ＡＰＳＴＡがデータを送受信するためのＮＡＶを共有されたＴＸＯＰに基づいて設定したり、又は設定されたＮＡＶを共有されたＴＸＯＰによって解釈したりすることにより、データを効率的に送信できる効果がある。

本発明から得られる効果は、以上で言及した効果に限定されず、言及していない別の効果は、以下の記載から、本発明の属する技術の分野における通常の知識を有する者に明確に理解されるであろう。

本発明の一実施例による無線ＬＡＮシステムを示す図である。本発明の他の実施例による無線ＬＡＮシステムを示す図である。本発明の一実施例によるステーションの構成を示す図である。本発明の一実施例によるアクセスポイントの構成を示す図である。ＳＴＡがＡＰとリンクを設定する過程を概略的に示す図である。無線ＬＡＮ通信で使用されるＣＳＭＡ（ＣａｒｒｉｅｒＳｅｎｓｅＭｕｌｔｉｐｌｅＡｃｃｅｓｓ）／ＣＡ（ＣｏｌｌｉｓｉｏｎＡｖｏｉｄａｎｃｅ）方法を示す図である。様々な標準世代別ＰＰＤＵ（ＰＬＣＰＰｒｏｔｏｃｏｌＤａｔａＵｎｉｔ）フォーマットの一例を示す図である。本発明の実施例に係る様々なＥＨＴ（ＥｘｔｒｅｍｅｌｙＨｉｇｈＴｈｒｏｕｇｈｐｕｔ）ＰＰＤＵ（ＰｈｙｓｉｃａｌＰｒｏｔｏｃｏｌＤａｔａＵｎｉｔ）フォーマット及びこれを指示するための方法の一例を示す図である。本発明の一実施例に係る多重リンク（ｍｕｌｔｉ－ｌｉｎｋ）装置を示す図である。本発明の一実施例に係るＴＩＤ－ｔｏ－ｌｉｎｋマッピング方法の一例を示す図である。本発明の一実施例に係るｍｕｌｔｉ－ｌｉｎｋＮＡＶ設定動作の一例を示す図である。本発明の一実施例に係るｍｕｌｔｉ－ｌｉｎｋＮＡＶ設定動作のさらに他の例を示す図である。本発明の一実施例に係るＢＳＳ分類及びそれに基づく動作の一例を示す図である。本発明の一実施例に係る無線ＬＡＮ機能を示す図である。本発明の一実施例に係る上りリンク（Ｕｐｌｉｎｋ：ＵＬ）多重ユーザ（ｍｕｌｔｉｕｓｅｒ：ＭＵ）動作を示す図である。本発明の一実施例に係るトリガーフレーム（Ｔｒｉｇｇｅｒｆｒａｍｅ）フォーマットを示す図である。本発明の一実施例に係るトリガーベースＰＰＤＵフォーマットを指示するための方法を示す図である。本発明の一実施例に係るＵＬＭＵ動作の一例を示す図である。本発明の一実施例に係るＴＸＯＰを共有するための方法を示す図である。本発明の一実施例に係るＴＸＯＰの共有及びＮＡＶ設定と関連した方法を示す図である。本発明の一実施例に係るＴＸＯＰの共有及びＣＴＳフレームの送信を示す図である。本発明の一実施例に係るＴＸＯＰの共有のためのトリガーフレームの一例を示す図である。本発明の一実施例に係るＮＡＶタイムアウト（ｔｉｍｅｏｕｔ）を示す図である。本発明の一実施例に係るＴＸＯＰの共有及びＮＡＶタイムアウトを示す図である。本発明のさらに他の実施例に係るＴＸＯＰの共有及びＮＡＶタイムアウトを示す図である。本発明のさらに他の実施例に係るＴＸＯＰの共有及びＮＡＶタイムアウトを示す図である。本発明の一実施例によってＴＸＯＰ共有が適用される時に、ＳＴＡ及びＡＰがＮＡＶを適用することを示す図である。本発明の一実施例によってＳＴＡがＴＸＯＰの共有を終了することを示す図である。本発明の一実施例に係るＳＴＡの動作の一例を示すフローチャートである。

本明細書で使用される用語は、本発明での機能を考慮してできる限り現在広く使用されている一般的用語を選択しているが、これは該当技術分野に携わる技術者の意図、慣例、または新たな技術の出現などによって異なり得る。また、特定の場合は出願人が任意に選定した用語もあり、このような場合は該当する発明の説明部分でその意味を記載する。よって、本明細書で使用される用語は単なる用語の名称ではなく、その用語が有する実質的な意味と本明細書全般にわたる内容に基づいて解釈すべきであることを明らかにする。

明細書全体にわたって、ある構成が他の構成と「連結」されているとすると、これは「直接連結」されている場合だけでなく、その中間に他の構成要素を間に挟んで「電気的に連結」されている場合も含む。また、ある構成要素が特定の構成要素を「含む」とすると、これは特に反対する記載がない限り、他の構成要素を除くのではなく他の構成要素を更に含み得ることを意味する。加えて、特定臨界値を基準に「以上」または「以下」という限定事項は、実施例によってそれぞれ「超過」または「未満」に適切に代替され得る。以下、本発明において、フィールドとサブフィールドは同じ意味で使われてよい。

図１は、本発明の一実施例による無線ＬＡＮシステムを示す図である。

無線ＬＡＮシステムは、一つまたはそれ以上のベーシックサービスセット（ＢａｓｉｃＳｅｒｖｉｃｅＳｅｔ、ＢＳＳ）を含むが、ＢＳＳは同期化に成功し互いに通信し得る機器の集合を示す。一般に、ＢＳＳはインフラストラクチャＢＳＳ（ｉｎｆｒａｓｔｒｕｃｔｕｒｅＢＳＳ）と独立ＢＳＳ（ＩｎｄｅｐｅｎｄｅｎｔＢＳＳ、ＩＢＳＳ）に区分されるが、図１はこのうちインフラストラクチャＢＳＳを示している。

図１に示すように、インフラストラクチャＢＳＳＢＳＳ１，ＢＳＳ２は、１つ又はそれ以上のステーションＳＴＡ１，ＳＴＡ２，ＳＴＡ３，ＳＴＡ４，ＳＴＡ５、分配サービス（ＤｉｓｔｒｉｂｕｔｉｏｎＳｅｒｖｉｃｅ）を提供するステーションであるアクセスポイントＡＰ－１，ＡＰ－２、及び複数のアクセスポイントＡＰ－１，ＡＰ－２を連結させる分配システム（ＤｉｓｔｒｉｂｕｔｉｏｎＳｙｓｔｅｍ）ＤＳを含む。

ステーション（Ｓｔａｔｉｏｎ、ＳＴＡ）は、ＩＥＥＥ８０２．１１標準の規定に従う媒体接続制御（ＭｅｄｉｕｍＡｃｃｅｓｓＣｏｎｔｒｏｌ、ＭＡＣ）と無線媒体に対する物理層（ＰｈｙｓｉｃａｌＬａｙｅｒ）インタフェースを含む任意のデバイスであって、広い意味では非アクセスポイントｎｏｎ－ＡＰステーションのみならずアクセスポイントＡＰを全て含む。また、本明細書において、「端末」とはｎｏｎ－ＡＰまたはＡＰを指すか、両者を全て指す用語として使用される。無線通信のためのステーションはプロセッサと通信部を含み、実施例によってユーザインタフェース部とディスプレーユニットなどを更に含む。プロセッサは無線ネットワークを介して伝送するフレームを生成するか、または前記無線ネットワークを介して受信されたフレームを処理し、その他にステーションを制御するための多様な処理を行う。そして、通信部は前記プロセッサと機能的に連結されており、ステーションのために無線ネットワークを介してフレームを送受信する。本発明において、端末はユーザ端末機（ｕｓｅｒｅｑｕｉｐｍｅｎｔ、ＵＥ）を含む用語として使用される。

アクセスポイント（ＡｃｃｅｓｓＰｏｉｎｔ、ＡＰ）は、自らに結合された（ａｓｓｏｃｉａｔｅｄ）ステーションのために無線媒体を経由して分配システムＤＳに対する接続を提供する個体である。インフラストラクチャＢＳＳにおいて、非ＡＰステーション間の通信はＡＰを経由して行われることが原則であるが、ダイレクトリンクが設定されている場合は非ＡＰステーションの間でも直接通信が可能である。一方、本発明において、ＡＰはＰＣＰ（ＰｅｒｓｏｎａｌＢＳＳＣｏｏｒｄｉｎａｔｉｏｎＰｏｉｎｔ）を含む概念として使用されるが、広い意味では集中制御器、基地局（ＢａｓｅＳｔａｔｉｏｎ、ＢＳ）、ノードＢ、ＢＴＳ（ＢａｓｅＴｒａｎｓｃｅｉｖｅｒＳｙｓｔｅｍ）、またはサイト制御器などの概念を全て含む。本発明において、ＡＰはベース無線通信端末とも称されるが、ベース無線通信端末は、広い意味ではＡＰ、ベースステーション（ｂａｓｅｓｔａｔｉｏｎ）、ｅＮＢ（ｅＮｏｄｅＢ）、及びトランスミッションポイントＴＰを全て含む用語として使用される。それだけでなく、ベース無線通信端末は複数の無線通信端末との通信で通信媒介体（ｍｅｄｉｕｍ）資源を割り当て、スケジューリング（ｓｃｈｅｄｕｌｉｎｇ）を行う多様な形態の無線通信端末を含む。

複数のインフラストラクチャＢＳＳは、分配システムＤＳを介して互いに連結される。この際、分配システムを介して連結された複数のＢＳＳを拡張サービスセット（ＥｘｔｅｎｄｅｄＳｅｒｖｉｃｅＳｅｔ、ＥＳＳ）という。

図２は、本発明の他の実施例による無線ＬＡＮシステムである独立ＢＳＳを示す図である。図２の実施例において、図１の実施例と同じであるか相応する部分は重複する説明を省略する。

図２に示したＢＳＳ３は独立ＢＳＳであってＡＰを含まないため、全てのステーション（ＳＴＡ６、ＳＴＡ７）がＡＰと接続されていない状態である。独立ＢＳＳは分配システムへの接続が許容されず、自己完備的ネットワーク（ｓｅｌｆ－ｃｏｎｔａｉｎｅｄｎｅｔｗｏｒｋ）をなす。独立ＢＳＳにおいて、それぞれのステーション（ＳＴＡ６、ＳＴＡ７）はダイレクトに互いに連結される。

図３は、本発明の一実施例によるステーション１００の構成を示すブロック図である。図示したように、本発明の実施例によるステーション１００は、プロセッサ１１０、通信部１２０、ユーザインタフェース部１４０、ディスプレーユニット１５０、及びメモリ１６０を含む。

まず、通信部１２０は、無線ＬＡＮパケットなどの無線信号を送受信し、ステーション１００に組み込まれる又は外付けられて具備されてよい。実施例によれば、通信部１２０は、互いに異なる周波数バンドを用いる少なくとも１つの通信モジュールを含むことができる。例えば、前記通信部１２０は、２．４ＧＨｚ、５ＧＨｚ、６ＧＨｚ及び６０ＧＨｚなどの異なる周波数バンドの通信モジュールを含むことができる。一実施例によれば、ステーション１００は、７．１２５ＧＨｚ以上の周波数バンドを用いる通信モジュールと、７．１２５ＧＨｚ以下の周波数バンドを用いる通信モジュールを備えることができる。それぞれの通信モジュールは、当該通信モジュールが支援する周波数バンドの無線ＬＡＮ規格に基づいてＡＰ又は外部ステーションと無線通信を行うことができる。通信部１２０は、ステーション１００の性能及び要求事項に応じて１回に１つの通信モジュールのみを動作させるか、同時に複数の通信モジュールを共に動作させることができる。ステーション１００が複数の通信モジュールを含む場合に、各通信モジュールはそれぞれ独立した形態で備えられてもよく、複数のモジュールが１つのチップとして統合して備えられてもよい。本発明の実施例において、通信部１２０は、ＲＦ（ＲａｄｉｏＦｒｅｑｕｅｎｃｙ）信号を処理するＲＦ通信モジュールを表すことができる。

次に、ユーザインタフェース１４０は、ステーション１００に備えられた多様な形態の入出力手段を含む。つまり、ユーザインタフェース部１４０は多様な入力手段を利用してユーザの入力を受信し、プロセッサ１１０は受信されたユーザ入力に基づいてステーション１００を制御する。また、ユーザインタフェース部１４０は、多様な出力手段を利用してプロセッサ１１０の命令に基づく出力を行う。

次に、ディスプレーユニット１５０は、ディスプレー画面にイメージを出力する。前記ディスプレーユニット１５０は、プロセッサ１１０によって行われるコンテンツ、またはプロセッサ１１０の制御命令に基づくユーザインタフェースなどの多様なディスプレーオブジェクトを出力する。また、メモリ１６０は、ステーション１００で使用される制御プログラム及びそれによる各種データを貯蔵する。このような制御プログラムには、ステーション１００がＡＰまたは外部のステーションと接続を行うのに必要な接続プログラムが含まれる。

本発明のプロセッサ１１０は多様な命令またはプログラムを行い、ステーション１００内部のデータをプロセッシングする。また、前記プロセッサ１１０は上述したステーション１００の各ユニットを制御し、ユニット間のデータの送受信を制御する。本発明の実施例によると、プロセッサ１１０はメモリ１６０に貯蔵されたＡＰとの接続のためのプログラムを行い、ＡＰが伝送した通信設定メッセージを受信する。また、プロセッサ１１０は通信設定メッセージに含まれたステーション１００の優先条件に関する情報を読み取り、ステーション１００の優先条件に関する情報に基づいてＡＰに関する接続を要請する。本発明のプロセッサ１１０はステーション１００のメインコントロールユニットを指してもよく、実施例によってステーション１００の一部の構成、例えば、通信部１２０などを個別的に制御するためのコントロールユニットを指してもよい。つまり、プロセッサ１１０は通信部１２０から送受信される無線信号を変復調するモデム、または変復調部（ｍｏｄｕｌａｔｏｒａｎｄ／ｏｒｄｅｍｏｄｕｌａｔｏｒ）であってもよい。プロセッサ１１０は、本発明の実施例によるステーション１００の無線信号送受信の各種動作を制御する。それに関する詳しい実施例は後述する。

図３に示したステーション１００は本発明の一実施例によるブロック図であって、分離して示したブロックはデバイスのエレメントを論理的に区別して示したものである。よって、上述したデバイスのエレメントは、デバイスの設計に応じて一つのチップまたは複数のチップに取り付けられる。例えば、前記プロセッサ１１０及び通信部１２０は一つのチップに統合されて具現されてもよく、別途のチップで具現されてもよい。また、本発明の実施例において、前記ステーション１００の一部の構成、例えば、ユーザインタフェース部１４０及びディスプレーユニット１５０などはステーション１００に選択的に備えられてもよい。

図４は、本発明の一実施例によるＡＰ２００の構成を示すブロック図である。図示したように、本発明の実施例によるＡＰ２００は、プロセッサ２１０、通信部２２０、及びメモリ２６０を含む。図４において、ＡＰ２００の構成のうち図３のステーション１００の構成と同じであるか相応する部分については重複する説明を省略する。

図４を参照すると、本発明に係るＡＰ２００は、少なくとも１つの周波数バンドにおいてＢＳＳを運営するための通信部２２０を備える。図３の実施例において前述したように、前記ＡＰ２００の通信部２２０も、互いに異なる周波数バンドを用いる複数の通信モジュールを含むことができる。すなわち、本発明の実施例に係るＡＰ２００は、異なる周波数バンド、例えば、２．４ＧＨｚ、５ＧＨｚ、６ＧＨｚ及び６０ＧＨｚのいずれかを用いる２つ以上の通信モジュールを共に備えることができる。好ましくは、ＡＰ２００は、７．１２５ＧＨｚ以上の周波数バンドを用いる通信モジュールと、７．１２５ＧＨｚ以下の周波数バンドを用いる通信モジュールを備えることができる。それぞれの通信モジュールは、当該通信モジュールが支援する周波数バンドの無線ＬＡＮ規格に基づいてステーションと無線通信を行うことができる。前記通信部２２０は、ＡＰ２００の性能及び要求事項に応じて１回に１つの通信モジュールのみを動作させるか、同時に複数の通信モジュールを共に動作させることができる。本発明の実施例において、通信部２２０は、ＲＦ（ＲａｄｉｏＦｒｅｑｕｅｎｃｙ）信号を処理するＲＦ通信モジュールを表すことができる。

次に、メモリ２６０は、ＡＰ２００で使用される制御プログラム及びそれによる各種データを貯蔵する。このような制御プログラムには、ステーションの接続を管理する接続プログラムが含まれる。また、プロセッサ２１０はＡＰ２００の各ユニットを制御し、ユニット間のデータの送受信を制御する。本発明の実施例によると、プロセッサ２１０はメモリ２６０に貯蔵されたステーションとの接続のためのプログラムを行い、１つ以上のステーションに対する通信設定メッセージを伝送する。この際、通信設定メッセージには各ステーションの接続優先条件に関する情報が含まれる。また、プロセッサ２１０はステーションの接続要請に応じて接続設定を行う。一実施例によると、プロセッサ２１０は通信部２２０から送受信される無線信号を変復調するモデム、または変復調部である。プロセッサ２１０は、本発明の実施例によるＡＰ２００の無線信号送受信の各種動作を制御する。それに関する詳しい実施例は後述する。

図５は、ＳＴＡがＡＰとリンクを設定する過程を概略的に示す図である。

図５を参照すると、ＳＴＡ１００とＡＰ２００間のリンクは大きくスキャニング（ｓｃａｎｎｉｎｇ）、認証（ａｕｔｈｅｎｔｉｃａｔｉｏｎ）、及び結合（ａｓｓｏｃｉａｔｉｏｎ）の３つのステップを介して設定される。まず、スキャニングステップは、ＡＰ２００が運営するＢＳＳの接続情報をＳＴＡ１００が獲得するステップである。スキャニングを行うための方法としては、ＡＰ２００が周期的に伝送するビーコン（ｂｅａｃｏｎ）メッセージＳ１０１のみを活用して情報を取得するパッシブスキャニング（ｐａｓｓｉｖｅｓｃａｎｎｉｎｇ）方法と、ＳＴＡ１００がＡＰにプローブ要請（ｐｒｏｂｅｒｅｑｕｅｓｔ）を伝送しＳ１０３、ＡＰからプローブ応答（ｐｒｏｂｅｒｅｓｐｏｎｓｅ）を受信してＳ１０５、接続情報を取得するアクティブスキャニング（ａｃｔｉｖｅｓｃａｎｎｉｎｇ）方法がある。

スキャニングステップにおいて無線接続情報の受信に成功したＳＴＡ１００は、認証要請（ａｕｔｈｅｎｔｉｃａｔｉｏｎｒｅｑｕｅｓｔ）を伝送しＳ１０７ａ、ＡＰ２００から認証応答（ａｕｔｈｅｎｔｉｃａｔｉｏｎｒｅｓｐｏｎｓｅ）を受信してＳ１０７ｂ、認証ステップを行う。認証ステップが行われた後、ＳＴＡ１００は結合要請（ａｓｓｏｃｉａｔｉｏｎｒｅｑｕｅｓｔ）を伝送しＳ１０９ａ、ＡＰ２００から結合応答（ａｓｓｏｃｉａｔｉｏｎｒｅｓｐｏｎｓｅ）を受信してＳ１０９ｂ、結合ステップを行う。本明細書において、結合とは基本的に無線結合を意味するが、本発明はこれに限らず、広い意味での結合は無線結合及び有線結合を全て含む。

一方、追加に８０２．１Ｘ基盤の認証ステップＳ１１１、及びＤＨＣＰを介したＩＰアドレス獲得ステップＳ１１３が行われる。図５において、サーバ３００はＳＴＡ１００と８０２．１Ｘ基盤の認証を処理するサーバであって、ＡＰ２００に物理的に結合されて存在するか、別途のサーバとして存在してもよい。

図６は、無線ＬＡＮ通信で使用されるＣＳＭＡ（ＣａｒｒｉｅｒＳｅｎｓｅＭｕｌｔｉｐｌｅＡｃｃｅｓｓ）／ＣＡ（ＣｏｌｌｉｓｉｏｎＡｖｏｉｄａｎｃｅ）方法を示す図である。

無線ＬＡＮ通信を行う端末は、データを伝送する前にキャリアセンシング（ＣａｒｒｉｅｒＳｅｎｓｉｎｇ）を行ってチャネルが占有状態（ｂｕｓｙ）であるのか否かをチェックする。もし一定強度以上の無線信号が感知されれば該当チャネルが占有状態と判別され、前記端末は該当チャネルに対するアクセスを遅延する。このような過程をクリアチャネル評価（ＣｌｅａｒＣｈａｎｎｅｌＡｓｓｅｓｓｍｅｎｔ、ＣＣＡ）といい、該当信号の感知有無を決定するレベルをＣＣＡ臨界値（ＣＣＡｔｈｒｅｓｈｏｌｄ）という。もし端末に受信されたＣＣＡ臨界値以上の無線信号が該当端末を受信者とすれば、端末は受信された無線信号を処理する。一方、該当チャネルから無線信号が感知されないかＣＣＡ臨界値より小さい強度の無線信号が感知されれば、前記チャネルは遊休状態（ｉｄｌｅ）と判別される。

チャネルが遊休状態と判別されれば、伝送するデータがある各端末は、各端末の状況によるＩＦＳ（ＩｎｔｅｒＦｒａｍｅＳｐａｃｅ）、例えば、ＡＩＦＳ（ＡｒｂｉｔｒａｔｉｏｎＩＦＳ）、ＰＩＦＳ（ＰＣＦＩＦＳ）などの時間の後にバックオフ手順を行う。実施例によって、前記ＡＩＦＳは従来のＤＩＦＳ（ＤＣＦＩＦＳ）を代替する構成として使用される。各端末は、該当端末に決定された乱数（ｒａｎｄｏｍｎｕｍｂｅｒ）だけのスロットタイムを前記チャネルの遊休状態の間隔（ｉｎｔｅｒｖａｌ）の間に減少させながら待機し、スロットタイムを全て消尽した端末が該当チャネルに対するアクセスを試みる。このように、各端末がバックオフ手順を行う区間を競合ウィンドウ区間という。

もし特定端末が前記チャネルのアクセスに成功すれば、該当端末は前記チャネルを介してデータを伝送する。しかし、アクセスを試みた端末が他の端末と衝突すれば、衝突した端末はそれぞれ新しい乱数を割り当てられて更にバックオフ手順を行う。一実施例によると、各端末に新しく割り当てられる乱数は、該当端末が以前割り当てられた乱数の範囲（競合ウィンドウ、ＣＷ）の２倍の範囲（２＊ＣＷ）内で決定される。一方、各端末は、次の競合ウィンドウ区間で更にバックオフ手順を行ってアクセスを試みるが、この際、各端末は以前の競合ウィンドウ区間に残ったスロットタイムからバックオフ手順を行う。このような方法で無線ＬＡＮ通信を行う各端末は、特定チャネルに対する互いの衝突を回避することができる。

以下、本発明において、端末は、ｎｏｎ－ＡＰＳＴＡ、ＡＰＳＴＡ、ＡＰ、ＳＴＡ、受信装置又は送信装置と呼ぶことができ、本発明がこれに限定されるものではない。また、本発明において、ＡＰＳＴＡは、ＡＰと呼ぶことができる。

＜様々なＰＰＤＵフォーマットの実施例＞

図７には、様々な標準世代別ＰＰＤＵ（ＰＬＣＰＰｒｏｔｏｃｏｌＤａｔａＵｎｉｔ）フォーマットの一例を示す。より具体的に、図７（ａ）は、８０２．１１ａ／ｇに基づくレガシーＰＰＤＵフォーマットの一実施例、図７（ｂ）は、８０２．１１ａｘに基づくＨＥＰＰＤＵフォーマットの一実施例を示し、図７（ｃ）は、８０２．１１ｂｅに基づくノン－レガシーＰＰＤＵ（すなわち、ＥＨＴＰＰＤＵ）フォーマットの一実施例を示す。また、図７（ｄ）は、前記ＰＰＤＵフォーマットで共通に用いられるＬ－ＳＩＧ及びＲＬ－ＳＩＧの細部フィールド構成を示す。

図７（ａ）を参照すると、レガシーＰＰＤＵのプリアンブルは、Ｌ－ＳＴＦ（ＬｅｇａｃｙＳｈｏｒｔＴｒａｉｎｉｎｇｆｉｅｌｄ）、Ｌ－ＬＴＦ（ＬｅｇａｃｙＬｏｎｇＴｒａｉｎｉｎｇｆｉｅｌｄ）及びＬ－ＳＩＧ（ＬｅｇａｃｙＳｉｇｎａｌｆｉｅｌｄ）を含む。本発明の実施例において、前記Ｌ－ＳＴＦ、Ｌ－ＬＴＦ及びＬ－ＳＩＧは、レガシープリアンブルと呼ぶことができる。

図７（ｂ）を参照すると、ＨＥＰＰＤＵのプリアンブルは、前記レガシープリアンブルに、ＲＬ－ＳＩＧ（ＲｅｐｅａｔｅｄＬｅｇａｃｙＳｈｏｒｔＴｒａｉｎｉｎｇｆｉｅｌｄ）、ＨＥ－ＳＩＧ－Ａ（ＨｉｇｈＥｆｆｉｃｉｅｎｃｙＳｉｇｎａｌＡｆｉｅｌｄ）、ＨＥ－ＳＩＧ－Ｂ（ＨｉｇｈＥｆｆｉｃｉｅｎｃｙＳｉｇｎａｌＢｆｉｅｌｄ）、ＨＥ－ＳＴＦ（ＨｉｇｈＥｆｆｉｃｉｅｎｃｙＳｈｏｒｔＴｒａｉｎｉｎｇｆｉｅｌｄ）、ＨＥ－ＬＴＦ（ＨｉｇｈＥｆｆｉｃｉｅｎｃｙＬｏｎｇＴｒａｉｎｉｎｇｆｉｅｌｄ）をさらに含む。本発明の実施例において、前記ＲＬ－ＳＩＧ、ＨＥ－ＳＩＧ－Ａ、ＨＥ－ＳＩＧ－Ｂ、ＨＥ－ＳＴＦ及びＨＥ－ＬＴＦは、ＨＥプリアンブルと呼ぶことができる。ＨＥプリアンブルの具体的な構成は、ＨＥＰＰＤＵフォーマットによって変形されてよい。例えば、ＨＥ－ＳＩＧ－Ｂは、ＨＥＭＵＰＰＤＵフォーマットのみにおいて用いられてよい。

図７（ｃ）を参照すると、ＥＨＴＰＰＤＵのプリアンブルは、前記レガシープリアンブルに、ＲＬ－ＳＩＧ（ＲｅｐｅａｔｅｄＬｅｇａｃｙＳｈｏｒｔＴｒａｉｎｉｎｇｆｉｅｌｄ）、Ｕ－ＳＩＧ（ＵｎｉｖｅｒｓａｌＳｉｇｎａｌｆｉｅｌｄ）、ＥＨＴ－ＳＩＧ－Ａ（ＥｘｔｒｅｍｅｌｙＨｉｇｈＴｈｒｏｕｇｈｐｕｔＳｉｇｎａｌＡｆｉｅｌｄ）、ＥＨＴ－ＳＩＧ－Ａ（ＥｘｔｒｅｍｅｌｙＨｉｇｈＴｈｒｏｕｇｈｐｕｔＳｉｇｎａｌＢｆｉｅｌｄ）、ＥＨＴ－ＳＴＦ（ＥｘｔｒｅｍｅｌｙＨｉｇｈＴｈｒｏｕｇｈｐｕｔＳｈｏｒｔＴｒａｉｎｉｎｇｆｉｅｌｄ）、ＥＨＴ－ＬＴＦ（ＥｘｔｒｅｍｅｌｙＨｉｇｈＴｈｒｏｕｇｈｐｕｔＬｏｎｇＴｒａｉｎｉｎｇｆｉｅｌｄ）をさらに含む。本発明の実施例において、前記ＲＬ－ＳＩＧ、ＥＨＴ－ＳＩＧ－Ａ、ＥＨＴ－ＳＩＧ－Ｂ、ＥＨＴ－ＳＴＦ及びＥＨＴ－ＬＴＦは、ＥＨＴプリアンブルと呼ぶことができる。ノン－レガシープリアンブルの具体的な構成は、ＥＨＴＰＰＤＵフォーマットによって変形されてよい。例えば、ＥＨＴ－ＳＩＧ－ＡとＥＨＴ－ＳＩＧ－Ｂは、ＥＨＴＰＰＤＵフォーマットのうち一部のフォーマットのみにおいて用いられてよい。

ＰＰＤＵのプリアンブルに含まれたＬ－ＳＩＧフィールドは、６４ＦＦＴＯＦＤＭが適用され、総６４個のサブキャリアで構成される。このうち、ガードサブキャリア、ＤＣサブキャリア及びパイロットサブキャリアを除く４８個のサブキャリアが、Ｌ－ＳＩＧのデータ送信用に用いられる。Ｌ－ＳＩＧにはＢＰＳＫ、Ｒａｔｅ＝１／２のＭＣＳ（ＭｏｄｕｌａｔｉｏｎａｎｄＣｏｄｉｎｇＳｃｈｅｍｅ）が適用されるので、総２４ビットの情報を含むことができる。図７（ｄ）には、Ｌ－ＳＩＧの２４ビット情報構成を示す。

図７（ｄ）を参照すると、Ｌ－ＳＩＧ、は、Ｌ＿ＲＡＴＥフィールドとＬ＿ＬＥＮＧＴＨフィールドを含む。Ｌ＿ＲＡＴＥフィールドは、４ビットで構成され、データ送信に用いられたＭＣＳを示す。具体的に、Ｌ＿ＲＡＴＥフィールドは、ＢＰＳＫ／ＱＰＳＫ／１６－ＱＡＭ／６４－ＱＡＭなどの変調方式と１／２、２／３、３／４などの符号率を組み合わせた６／９／１２／１８／２４／３６／４８／５４Ｍｂｐｓの送信速度のうち１つの値を示す。Ｌ＿ＲＡＴＥフィールドとＬ＿ＬＥＮＧＴＨフィールドの情報を組み合わせると当該ＰＰＤＵの全長を示すことができる。ノン－レガシーＰＰＤＵフォーマットでは、Ｌ＿ＲＡＴＥフィールドを最小速度である６Ｍｂｐｓに設定する。

Ｌ＿ＬＥＮＧＴＨフィールドの単位はバイトであり、総１２ビットが割り当てられて最大４０９５までシグナルでき、Ｌ＿ＲＡＴＥフィールドとの組合せで該当ＰＰＤＵの長さを示すことができる。このとき、レガシー端末とノンレガシー端末はＬ＿ＬＥＮＧＴＨフィールドを別個の方法で解釈することができる。

まず、レガシー端末又はノンレガシー端末がＬ＿ＬＥＮＧＴＨフィールドを用いて該当ＰＰＤＵの長さを解釈する方法は次の通りである。Ｌ＿ＲＡＴＥフィールドの値が６Ｍｂｐｓを指示するように設定された場合に、６４ＦＦＴの１個のシンボルデュレーションである４ｕｓの間に３バイト（すなわち、２４ビット）が送信されてよい。したがって、Ｌ＿ＬＥＮＧＴＨフィールド値に、ＳＶＣフィールド及びＴａｉｌフィールドに該当する３バイトを足し、これを１個のシンボルの送信量である３バイトで割ると、Ｌ－ＳＩＧ以後の６４ＦＦＴ基準シンボル個数が取得される。取得されたシンボル個数に１個のシンボルデュレーションである４ｕｓをかけた後に、Ｌ－ＳＴＦ、Ｌ－ＬＴＦ及びＬ－ＳＩＧの送信にかかる２０ｕｓを足すと、該当ＰＰＤＵの長さ、すなわち、受信時間（ＲＸＴＩＭＥ）が得られる。これを数式で表現すれば、下記の式１の通りである。

このとき、
は、ｘより大きい又は等しい最小の自然数を表す。Ｌ＿ＬＥＮＧＴＨフィールドの最大値は４０９５であるので、ＰＰＤＵの長さは、最大５．４８４ｍｓまでに設定されてよい。当該ＰＰＤＵを送信するノン－レガシー端末は、Ｌ＿ＬＥＮＧＴＨフィールドを下記の式２のように設定しなければならない。

ここで、ＴＸＴＩＭＥは、当該ＰＰＤＵを構成する全体送信時間であり、下記の式３の通りである。このとき、ＴＸは、Ｘの送信時間を表す。

以上の式を参照すると、ＰＰＤＵの長さは、Ｌ＿ＬＥＮＧＴＨ／３の切上げ値に基づいて計算される。したがって、任意のｋ値に対してＬ＿ＬＥＮＧＴＨ＝｛３ｋ＋１，３ｋ＋２，３（ｋ＋１）｝の３つの異なる値が、同一のＰＰＤＵ長を指示する。

図７（ｅ）を参照すると、Ｕ－ＳＩＧ（ＵｎｉｖｅｒｓａｌＳＩＧ）フィールドは、ＥＨＴＰＰＤＵ及び後続世代の無線ＬＡＮのＰＰＤＵにおいて存続し、１１ｂｅを含めてどの世代のＰＰＤＵであるかを区分する役割を担う。Ｕ－ＳＩＧは、６４ＦＦＴベースのＯＦＤＭの２シンボルであり、総５２ビットの情報を伝達することができる。このうち、ＣＲＣ／テール９ビットを除く４３ビットは、大きく、ＶＩ（ＶｅｒｓｉｏｎＩｎｄｅｐｅｎｄｅｎｔ）フィールドとＶＤ（ＶｅｒｓｉｏｎＤｅｐｅｎｄｅｎｔ）フィールドに区分される。

ＶＩビットは、現在のビット構成を後にも維持し続け、後続世代のＰＰＤＵが定義されても、現在の１１ｂｅ端末が、当該ＰＰＤＵのＶＩフィールドから当該ＰＰＤＵに関する情報を得ることができる。そのために、ＶＩフィールドは、ＰＨＹバージョン、ＵＬ／ＤＬ、ＢＳＳカラー、ＴＸＯＰ、リザーブド（Ｒｅｓｅｒｖｅｄ）フィールドで構成される。ＰＨＹバージョンフィールドは３ビットであり、１１ｂｅ及び後続世代の無線ＬＡＮ標準を順次にバージョンで区分する役割を担う。１１ｂｅは０００ｂの値を有する。ＵＬ／ＤＬフィールドは、当該ＰＰＤＵが上りリンク／下りリンクＰＰＤＵのいずれであるかを区分する。ＢＳＳカラーは、１１ａｘで定義されたＢＳＳ別識別子を意味し、６ビット以上の値を有する。ＴＸＯＰは、ＭＡＣヘッダーで伝達されていた送信機会デュレーション（ＴｒａｎｓｍｉｔＯｐｐｏｒｔｕｎｉｔｙＤｕｒａｔｉｏｎ）を意味するが、ＰＨＹヘッダーに追加することにより、ＭＰＤＵをデコードすることなく、当該ＰＰＤＵが含まれたＴＸＯＰの長さを類推でき、７ビット以上の値を有する。

ＶＤフィールドは、１１ｂｅバージョンのＰＰＤＵにのみ有用なシグナリング情報としてＰＰＤＵフォーマット、ＢＷのように、如何なるＰＰＤＵフォーマットにも共通に用いられるフィールド、及びＰＰＤＵフォーマット別に異なるように定義されるフィールドで構成されてよい。ＰＰＤＵフォーマットは、ＥＨＴＳＵ（ＳｉｎｇｌｅＵｓｅｒ）、ＥＨＴＭＵ（ＭｕｌｔｉｐｌｅＵｓｅｒ）、ＥＨＴＴＢ（Ｔｒｉｇｇｅｒ－ｂａｓｅｄ）、ＥＨＴＥＲ（ＥｘｔｅｎｄｅｄＲａｎｇｅ）ＰＰＤＵなどを区分する区分子である。ＢＷフィールドは、大きく、２０、４０、８０、１６０（８０＋８０）、３２０（１６０＋１６０）ＭＨｚの５個の基本ＰＰＤＵＢＷオプション（２０＊２の冪乗の形態で表現可能なＢＷを基本ＢＷと呼ぶことができる。）と、プリアンブルパンクチャリング（ＰｒｅａｍｂｌｅＰｕｎｃｔｕｒｉｎｇ）によって構成される様々な残りのＰＰＤＵＢＷをシグナルする。また、３２０ＭＨｚでシグナルされた後、一部の８０ＭＨｚがパンクチャーされた形態でシグナルされてよい。また、パンクチャーされて変形されたチャネル形態は、ＢＷフィールドで直接シグナルされてもよく、或いはＢＷフィールドとＢＷフィールド以後に現れるフィールド（例えば、ＥＨＴ－ＳＩＧフィールド内のフィールド）を共に用いてシグナルされてもよい。仮に、ＢＷフィールドを３ビットとする場合に、総８個のＢＷシグナリングが可能なので、パンクチャリングモードは最大で３個をシグナルできる。仮にＢＷフィールドを４ビットとする場合に総１６個のＢＷシグナリングが可能なので、パンクチャリングモードは最大で１１個をシグナルできる。

ＢＷフィールド以後に位置するフィールドは、ＰＰＤＵの形態及びフォーマットによって異なり、ＭＵＰＰＤＵとＳＵＰＰＤＵは同一のＰＰＤＵフォーマットでシグナルされてよく、ＥＨＴ－ＳＩＧフィールドの前に、ＭＵＰＰＤＵとＳＵＰＰＤＵを区別するためのフィールドが位置してよく、そのための追加のシグナリングが行われてよい。ＳＵＰＰＤＵとＭＵＰＰＤＵは両方ともＥＨＴ－ＳＩＧフィールドを含んでいるが、ＳＵＰＰＤＵで不要な一部のフィールドが圧縮（ｃｏｍｐｒｅｓｓｉｏｎ）されてよい。この時、圧縮が適用されたフィールドの情報は省略されるか、あるいはＭＵＰＰＤＵに含まれる本来フィールドのサイズよりも縮小したサイズを有してよい。例えば、ＳＵＰＰＤＵの場合、ＥＨＴ－ＳＩＧの共通フィールドが省略又は代替されるか、ユーザ特定フィールドが代替されるか、或いは１個に縮小するなど、異なる構成を有してよい。

又は、ＳＵＰＰＤＵは、圧縮されたか否かを示す圧縮フィールドをさらに含むことができ、圧縮フィールドの値によって一部のフィールド（例えば、ＲＡフィールドなど）が省略されてよい。

ＳＵＰＰＤＵのＥＨＴ－ＳＩＧフィールドの一部が圧縮された場合に、圧縮されたフィールドに含まれる情報は、圧縮されていないフィールド（例えば、共通フィールドなど）で一緒にシグナルされてよい。ＭＵＰＰＤＵの場合、複数ユーザの同時受信のためのＰＰＤＵフォーマットであるので、Ｕ－ＳＩＧフィールド以後にＥＨＴ－ＳＩＧフィールドが必須に送信される必要があり、シグナルされる情報の量が可変的であってよい。すなわち、複数個のＭＵＰＰＤＵが複数個のＳＴＡに送信されるので、それぞれのＳＴＡは、ＭＵＰＰＤＵが送信されるＲＵの位置、それぞれのＲＵが割り当てられたＳＴＡ、及び送信されたＭＵＰＰＤＵが自分に送信されたか否かを認識しなければならない。したがって、ＡＰは、ＥＨＴ－ＳＩＧフィールドに上のような情報を含めて送信しなければならない。そのために、Ｕ－ＳＩＧフィールドではＥＨＴ－ＳＩＧフィールドを効率的に送信するための情報をシグナルし、これは、ＥＨＴ－ＳＩＧフィールドのシンボル数及び／又は変調方法であるＭＣＳであってよい。ＥＨＴ－ＳＩＧフィールドは、各ユーザに割り当てられたＲＵのサイズ及び位置情報を含むことができる。

ＳＵＰＰＤＵである場合、ＳＴＡに複数個のＲＵが割り当てられてよく、複数個のＲＵは連続又は不連続してよい。ＳＴＡに割り当てられたＲＵが連続しない場合、ＳＴＡは、中間にパンクチャーされたＲＵを認識してこそ、ＳＵＰＰＤＵを効率的に受信することができる。したがって、ＡＰは、ＳＵＰＰＤＵに、ＳＴＡに割り当てられたＲＵのうちパンクチャーされたＲＵの情報（例えば、ＲＵのパンクチャリングパターンなど）を含めて送信できる。すなわち、ＳＵＰＰＤＵの場合、パンクチャリングモードが適用されたか否か及びパンクチャリングパターンをビットマップ形式などで示す情報を含むパンクチャリングモードフィールドがＥＨＴ－ＳＩＧフィールドに含まれてよく、パンクチャリングモードフィールドは、帯域幅内で現れる不連続するチャネルの形態をシグナルできる。

シグナルされる不連続チャネルの形態は制限的であり、ＢＷフィールドの値と組み合わせてＳＵＰＰＤＵのＢＷ及び不連続チャネル情報を示す。例えば、ＳＵＰＰＤＵの場合、単一端末にのみ送信されるＰＰＤＵであるので、ＳＴＡは、ＰＰＤＵに含まれたＢＷフィールドから、自分に割り当てられた帯域幅が認識でき、ＰＰＤＵに含まれたＵ－ＳＩＧフィールド又はＥＨＴ－ＳＩＧフィールドのパンクチャリングモードフィールドから、割り当てられた帯域幅のうちパンクチャーされたリソースが認識できる。この場合、端末は、パンクチャーされたリソースユニットの特定チャネルを除く残りのリソースユニットでＰＰＤＵを受信できる。このとき、ＳＴＡに割り当てられた複数個のＲＵは、互いに異なる周波数帯域又はトーンで構成されてよい。

制限された形態の不連続チャネル形態のみがシグナルされる理由は、ＳＵＰＰＤＵのシグナリングオーバーヘッドを減らすためである。パンクチャリングは、２０ＭＨｚサブチャネル別に行われてよいので、８０、１６０、３２０ＭＨｚのように２０ＭＨｚサブチャネルを複数個有するＢＷに対してパンクチャリングを行うと、３２０ＭＨｚの場合、プライマリーチャネルを除く残りの２０ＭＨｚサブチャネル１５個の使用有無をそれぞれ表現して、不連続チャネル（端部２０ＭＨｚのみがパンクチーされた形態も不連続と見なす場合）形態をシグナルしなければならない。このように単一ユーザ送信の不連続チャネル形態をシグナルするために１５ビットを用いることは、シグナリング部分の低い送信速度を考慮したとき、過大なシグナリングオーバーヘッドとなり得る。

本発明は、ＳＵＰＰＤＵの不連続チャネル形態をシグナルする手法を提案し、提案した手法によって決定された不連続チャネル形態を示す。また、ＳＵＰＰＤＵの３２０ＭＨｚＢＷ構成において主（Ｐｒｉｍａｒｙ）１６０ＭＨｚと副（Ｓｅｃｏｎｄａｒｙ）１６０ＭＨｚのパンクチャリング形態をそれぞれシグナルする手法を提案する。

また、本発明の一実施例では、ＰＰＤＵフォーマットフィールドにシグナルされたＰＰＤＵフォーマットにしたがって、プリアンブルパンクチャリングＢＷ値が指示するＰＰＤＵの構成を異ならせる手法を提案する。ＢＷフィールドの長さが４ビットである場合を仮定し、ＥＨＴＳＵＰＰＤＵ又はＴＢＰＰＤＵである場合には、Ｕ－ＳＩＧ以後に１シンボルのＥＨＴ－ＳＩＧ－Ａをさらにシグナルするか、ＥＨＴ－ＳＩＧ－Ａを全くシグナルしなくてよいので、これを考慮してＵ－ＳＩＧのＢＷフィールドのみを用いて最大で１１個のパンクチャリングモードを全てシグナルする必要がある。しかしながら、ＥＨＴＭＵＰＰＤＵの場合、Ｕ－ＳＩＧ以後にＥＨＴ－ＳＩＧ－Ｂをさらにシグナルするので、最大で１１個のパンクチャリングモードをＳＵＰＰＤＵと異なる方法でシグナルしてよい。ＥＨＴＥＲＰＰＤＵの場合、ＢＷフィールドを１ビットに設定し、２０ＭＨｚ又は１０ＭＨｚの帯域を用いるＰＰＤＵであるかをシグナルすることができる。

図７（ｆ）には、Ｕ－ＳＩＧのＰＰＤＵフォーマットフィールドでＥＨＴＭＵＰＰＤＵと指示された場合に、ＶＤフィールドのフォーマット特異的（Ｆｏｒｍａｔ－ｓｐｅｃｉｆｉｃ）フィールドの構成を示す。ＭＵＰＰＤＵの場合、複数ユーザの同時受信のためのシグナリングフィールドであるＳＩＧ－Ｂが必須であり、Ｕ－ＳＩＧ後に別途のＳＩＧ－Ａ無しでＳＩＧ－Ｂが送信されてよい。そのために、Ｕ－ＳＩＧではＳＩＧ－Ｂをデコードするための情報をシグナルしなければならない。このようなフィールドは、ＳＩＧ－ＢＭＣＳ、ＳＩＧ－ＢＤＣＭ、ＳＩＧ－Ｂシンボルの数（ＮｕｍｂｅｒｏｆＳＩＧ－ＢＳｙｍｂｏｌｓ）、ＳＩＧ－Ｂ圧縮（ＳＩＧ－ＢＣｏｍｐｒｅｓｓｉｏｎ）、ＥＨＴ－ＬＴＦシンボルの数（ＮｕｍｂｅｒｏｆＥＨＴ－ＬＴＦＳｙｍｂｏｌｓ）フィールドなどである。

図８は、本発明の実施例に係る様々なＥＨＴ（ＥｘｔｒｅｍｅｌｙＨｉｇｈＴｈｒｏｕｇｈｐｕｔ）ＰＰＤＵ（ＰｈｙｓｉｃａｌＰｒｏｔｏｃｏｌＤａｔａＵｎｉｔ）フォーマット及びこれを指示するための方法の一例を示す。

図８を参照すると、ＰＰＤＵは、プリアンブルとデータ部分で構成されてよく、一つのタイプであるＥＨＴＰＰＤＵのフォーマットは、プリアンブルに含まれているＵ－ＳＩＧフィールドによって区別されてよい。具体的に、Ｕ－ＳＩＧフィールドに含まれているＰＰＤＵフォーマットフィールドに基づき、ＰＰＤＵのフォーマットがＥＨＴＰＰＤＵであるか否かが指示されてよい。

図８の（ａ）は、単一ＳＴＡのためのＥＨＴＳＵＰＰＤＵフォーマットの一例を示す。ＥＨＴＳＵＰＰＤＵは、ＡＰと単一ＳＴＡ間の単一ユーザ（ＳｉｎｇｌｅＵｓｅｒ：ＳＵ）送信のために用いられるＰＰＤＵであり、Ｕ－ＳＩＧフィールド以後に追加のシグナリングのためのＥＨＴ－ＳＩＧ－Ａフィールドが位置してよい。

図８の（ｂ）は、トリガーフレームに基づいて送信されるＥＨＴＰＰＤＵであるＥＨＴトリガーベース（Ｔｒｉｇｇｅｒ－ｂａｓｅｄ）ＰＰＤＵフォーマットの一例を示す。ＥＨＴトリガーベースＰＰＤＵは、トリガーフレームに基づいて送信されるＥＨＴＰＰＤＵであり、トリガーフレームに対する応答のために用いられる上りリンクＰＰＤＵである。ＥＨＴＰＰＤＵは、ＥＨＴＳＵＰＰＤＵとは違い、Ｕ－ＳＩＧフィールド以後にＥＨＴ－ＳＩＧ－Ａフィールドが位置しない。

図８の（ｃ）は、多重ユーザのためのＥＨＴＰＰＤＵであるＥＨＴＭＵＰＰＤＵフォーマットの一例を示す。ＥＨＴＭＵＰＰＤＵは、１つ以上のＳＴＡにＰＰＤＵを送信するために用いられるＰＰＤＵである。ＥＨＴＭＵＰＰＤＵフォーマットは、Ｕ－ＳＩＧフィールド以後にＨＥ－ＳＩＧ－Ｂフィールドが位置してよい。

図８の（ｄ）は、拡張された範囲にあるＳＴＡとの単一ユーザ送信のために用いられるＥＨＴＥＲＳＵＰＰＤＵフォーマットの一例を示す。ＥＨＴＥＲＳＵＰＰＤＵは、図８の（ａ）で説明したＥＨＴＳＵＰＰＤＵよりも広い範囲のＳＴＡとの単一ユーザ送信のために用いられてよく、時間軸上でＵ－ＳＩＧフィールドが反復して位置してよい。

図８の（ｃ）で説明したＥＨＴＭＵＰＰＤＵは、ＡＰが複数個のＳＴＡに下りリンク送信のために用いることができる。このとき、ＥＨＴＭＵＰＰＤＵは、複数個のＳＴＡがＡＰから送信されたＰＰＤＵを同時に受信できるようにスケジューリング情報を含むことができる。ＥＨＴＭＵＰＰＤＵは、ＥＨＴ－ＳＩＧ－Ｂのユーザ特定（ｕｓｅｒｓｐｅｃｉｆｉｃ）フィールドを通じて送信されるＰＰＤＵの受信者及び／又は送信者のＡＩＤ情報を、ＳＴＡに伝達することができる。したがって、ＥＨＴＭＵＰＰＤＵを受信した複数個の端末は、受信したＰＰＤＵのプリアンブルに含まれたユーザ特定フィールドのＡＩＤ情報に基づいて空間再使用（ｓｐａｔｉａｌｒｅｕｓｅ）動作を行うことができる。

具体的に、ＨＥＭＵＰＰＤＵに含まれたＨＥ－ＳＩＧ－Ｂフィールドのリソースユニット割り当て（ｒｅｓｏｕｒｃｅｕｎｉｔａｌｌｏｃａｔｉｏｎ，ＲＡ）フィールドは、周波数軸の特定帯域幅（例えば、２０ＭＨｚなど）におけるリソースユニットの構成（例えば、リソースユニットの分割形態）に関する情報を含むことができる。すなわち、ＲＡフィールドは、ＳＴＡがＰＰＤＵを受信するために、ＨＥＭＵＰＰＤＵの送信のための帯域幅で分割されたリソースユニットの構成を指示できる。分割された各リソースユニットに割り当て（又は、指定）されたＳＴＡの情報は、ＥＨＴ－ＳＩＧ－Ｂのユーザ特定フィールドに含まれてＳＴＡに送信されてよい。すなわち、ユーザ特定フィールドは、分割された各リソースユニットに対応する１つ以上のユーザフィールドを含むことができる。

例えば、分割された複数個のリソースユニットのうち、データ送信のために用いられる少なくとも１つのリソースユニットに対応するユーザフィールドは、受信者又は送信者のＡＩＤを含むことができ、データ送信に用いられない残りのリソースユニットに対応するユーザフィールドは、既に設定されたヌル（Ｎｕｌｌ）ＳＴＡＩＤを含むことができる。

図８に示す２個以上のＰＰＤＵを、同一のＰＰＤＵフォーマットを示す値で指示することができる。すなわち、２個以上のＰＰＤＵを同一の値によって同一のＰＰＤＵフォーマットと指示することができる。例えば、ＥＨＴＳＵＰＰＤＵとＥＨＴＭＵＰＰＤＵは、Ｕ－ＳＩＧＰＰＤＵフォーマットサブフィールドを用いて同一の値で指示することができる。このとき、ＥＨＴＳＵＰＰＤＵとＥＨＴＭＵＰＰＤＵは、ＰＰＤＵを受信するＳＴＡの個数によって区別されてよい。例えば、１個のＳＴＡのみが受信するＰＰＤＵは、ＥＨＴＳＵＰＰＤＵと識別されてよく、２個以上のＳＴＡが受信するようにＳＴＡの数が設定された場合に、ＥＨＴＭＵＰＰＤＵと識別されてよい。言い換えると、同一のサブフィールド値を用いて、図８に示す２個以上のＰＰＤＵフォーマットを指示することができる。

また、図８に示すフィールドのうち一部のフィールド又はフィールドの一部の情報は省略されてよく、このように一部のフィールド又はフィールドの一部の情報が省略される場合を圧縮モード（ｃｏｍｐｒｅｓｓｉｏｎｍｏｄｅ）又は圧縮されたモード（ｃｏｍｐｒｅｓｓｅｄｍｏｄｅ）と定義できる。

図９は、本発明の一実施例に係る多重リンク（ｍｕｌｔｉ－ｌｉｎｋ）装置を示す図である。

図９を参照すると、一つ以上のＳＴＡがアフィリエート（ａｆｆｉｌｉａｔｅ）されているデバイス（ｄｅｖｉｃｅ）の概念が定義されてよい。さらに他の実施例として、本発明の一実施例によれば、１個超過（すなわち、２個以上の）のＳＴＡがアフィリエートされているデバイスが定義されてよい。このとき、装置は論理的な（ｌｏｇｉｃａｌ）概念であってよい。したがって、このような概念の１個以上又は１個超過のＳＴＡがアフィリエートされているデバイスは、多重リンクデバイス（ｍｕｌｔｉ－ｌｉｎｋｄｅｖｉｃｅ：ＭＬＤ）、多重バンド（ｍｕｌｔｉ－ｂａｎｄ）デバイス又は多重リンク論理的エンティティ（ｍｕｌｔｉ－ｌｉｎｋｌｏｇｉｃａｌｅｎｔｉｔｙ：ＭＬＬＥ）と呼ぶことができる。

又は、上の概念のデバイスは、多重リンクエンティティ（ｍｕｌｔｉ－ｌｉｎｋｅｎｔｉｔｙ：ＭＬＥ）と呼ぶことができる。また、ＭＬＤは、一つのＭＡＣＳＡＰ（ｍｅｄｉｕｍａｃｃｅｓｓｃｏｎｔｒｏｌｓｅｒｖｉｃｅａｃｃｅｓｓｐｏｉｎｔ）をＬＬＣ（ｌｏｇｉｃａｌｌｉｎｋｃｏｎｔｒｏｌ）まで有してよく、ＭＬＤは一つのＭＡＣデータサービス（ＭＡＣｄａｔａｓｅｒｖｉｃｅ）を有してよい。

ＭＬＤに含まれたＳＴＡは、一つ以上のリンク（ｌｉｎｋ）又はチャネル（ｃｈａｎｎｅｌ）で動作することが可能である。すなわち、ＭＬＤに含まれたＳＴＡは、互いに異なる複数のチャネルで動作することが可能である。例えば、ＭＬＤに含まれたＳＴＡは、２．４ＧＨｚ、５ＧＨｚ、６ＧＨｚの互いに異なる周波数帯域のチャネルを用いて動作することが可能である。これにより、ＭＬＤはチャネル接続（ｃｈａｎｎｅｌａｃｃｅｓｓ）における利得を得、全体ネットワークの性能を上げることができる。既存の無線ＬＡＮは単一リンク（ｓｉｎｇｌｅｌｉｎｋ）で動作したが、ＭＬＤ動作は、複数個のリンクを用いてより多いチャネル接続機会を得るか、チャネルの状況を考慮して複数個のリンクでＳＴＡが効率的に動作することが可能である。

また、ＭＬＤにアフィリエートされたＳＴＡがＡＰである場合に、ＡＰがアフィリエートされたＭＬＤはＡＰＭＬＤであってよい。しかし、ＭＬＤにアフィリエートされたＳＴＡがｎｏｎ－ＡＰＳＴＡである場合に、ｎｏｎ－ＡＰがアフィリエートされたＭＬＤはｎｏｎ－ＡＰＭＬＤであってよい。

また、ＡＰＭＬＤ（Ｍｕｌｔｉ－ｌｉｎｋＤｅｖｉｃｅ）は、一つ以上の無線アクセスポイント（ＡＰ）を含む機器であってよく、上位層に一つのインタフェースを介して連結された機器であってよい。すなわち、ＡＰＭＬＤは、一つのインタフェースを介してＬＬＣ（ＬｏｇｉｃａｌＬｉｎｋＣｏｎｔｒｏｌ）層に連結されてよい。ＡＰＭＬＤに含まれた複数のＡＰは、ＭＡＣ層での一部の機能を共有してよい。ＡＰＭＬＤ内の各ＡＰは個別のリンクで動作してよい。ＳＴＡＭＬＤは、一つ以上のｎｏｎ－ＡＰＳＴＡを含む機器であってよく、一つのインタフェースを介して上位層に連結された機器であってよい。

すなわち、ＳＴＡＭＬＤは、一つのインタフェースを介してＬＬＣ層に連結されてよい。ＳＴＡＭＬＤに含まれた複数のＳＴＡは、ＭＡＣ層での一部の機能を共有してよい。また、ＳＴＡＭＬＤは、ｎｏｎ－ＡＰＭＬＤと呼ぶことができる。このとき、前記ＡＰＭＬＤ及びＳＴＡＭＬＤは、複数の個別リンクを用いて通信する多重リンク動作を行うことができる。すなわち、ＡＰＭＬＤが複数のＡＰを含んでいる場合に、各ＡＰは別個のリンクを構成し、ＳＴＡＭＬＤに含まれたそれぞれの端末と複数のリンクを用いたフレーム送受信動作を行うことができる。このとき、各リンクは２．４ＧＨｚ、５ＧＨｚ、又は６ＧＨｚの帯域で動作でき、各リンクでは帯域幅拡張動作を行うことができる。例えば、ＡＰＭＬＤが２．４ＧＨｚ帯域で一つのリンク、５ＧＨｚ帯域で２つのリンクを設定した場合に、２．４ＧＨｚ帯域では帯域幅拡張方式を用いて４０ＭＨｚの帯域幅でフレーム送信を行うことができ、５ＧＨｚ帯域を用いるそれぞれのリンクでは不連続の帯域幅を用いて最大で３２０ＭＨｚの帯域幅でフレーム送信を行うことができる。

一方、前記ＡＰＭＬＤ或いはＳＴＡＭＬＤは、機器内部の干渉の問題から、ＭＬＤ内の一つの端末が送信動作を行う間には他の端末が受信動作を行えないことがある。このようにＭＬＤ内の一つのＡＰ或いは端末が送信動作を行う途中に前記ＭＬＤ内の他のＡＰ或いは端末が受信する動作をＳＴＲ（ＳｉｍｕｌｔａｎｅｏｕｓＴｒａｎｓｍｉｔａｎｄＲｅｃｅｉｖｅ）という。前記ＡＰＭＬＤは全てのリンクに対してＳＴＲ動作が可能である。又は、前記ＡＰＭＬＤの一部のリンクでＳＴＲ動作が不可能である。ＡＰＭＬＤにはＳＴＲ動作可能な端末ＭＬＤが接続されることもあり、一部又は全体のリンクに対してＳＴＲ動作が不可能なＭＬＤが接続されることもある。また、ＡＰＭＬＤに含まれたＡＰには、ＭＬＤに所属していない端末（例えば、ＩＥＥＥ８０２．１１ａ／ｂ／ｇ／ｎ／ａｃ／ａｘ端末）がさらに接続されていることもある。

ＡＰＭＬＤとＳＴＡＭＬＤは、図５で説明したスキャニング及び接続過程において多重リンク利用動作のための交渉過程を行うことができる。例えば、図５で説明したスキャニング過程において、ＡＰＭＬＤに含まれたＡＰは、ビーコンフレームに、多重リンク動作が利用可能であることを指示する指示子、利用可能なリンク個数、利用可能な複数個のリンク情報を含めて送信できる。又は、ＳＴＡＭＬＤに属している端末は、プローブ要請フレームに、多重リンク動作が利用可能であることを指示する指示子を含めて送信でき、ＡＰＭＬＤに属しているＡＰは、プローブ応答フレームに、多重リンク動作が利用可能であることを指示する指示子を含めることができる。このとき、ＡＰは、多重リンク動作時に利用可能なリンク個数、リンク情報などをさらに含めて送信できる。

前記スキャニング過程でＡＰＭＬＤの多重リンク動作をするか否か、及び利用リンク情報を確認したＳＴＡＭＬＤは、ＡＰＭＬＤと接続過程を行うことができる。このとき、前記ＡＰＭＬＤとＳＴＡＭＬＤは多重リンク動作のための交渉過程を始めることができる。このとき、前記多重リンク動作のための交渉過程は、ＡＰＭＬＤに属したＡＰとＳＴＡＭＬＤに属した端末間の接続過程で行われてよい。すなわち、ＳＴＡＭＬＤに属した任意の端末（例えば、ＳＴＡ１）がＡＰＭＬＤに属した任意のＡＰ（例えば、ＡＰ１）に接続要請フレームを送りながら、端末の多重リンク動作が利用可能であることを指示する指示子及び多重リンク動作を行うことを要請する要請指示子を送ることができる。前記端末から接続要請フレームを受信したＡＰは、多重リンク動作を要請する指示子を確認でき、ＡＰが多重リンク動作可能である場合に多重リンク動作に用いるリンク情報及び各リンクで用いられるパラメータなどを含めて多重リンク動作を許容する接続応答フレームを当該端末に送信できる。前記多重リンク動作のためのパラメータは、用いられる各リンクの帯域、帯域幅拡張方向、ＴＢＴＴ（ＴａｒｇｅｔＢｅａｃｏｎＴｒａｎｓｍｉｓｓｉｏｎＴｉｍｅ）、ＳＴＲ動作の有無、のうち一つ以上を含んでよい。前記接続要請フレーム及び応答フレームが交換されて多重リンク動作の利用が確認されたＡＰＭＬＤ及びＳＴＡＭＬＤは、当該接続過程の後に、ＡＰＭＬＤに含まれた複数のＡＰ及びＳＴＡＭＬＤに含まれた複数の端末を介して複数のリンクでフレーム送信動作を行うことができる。

図９を参照すると、複数のＳＴＡを含むＭＬＤが存在してよく、ＭＬＤに含まれている複数のＳＴＡは複数のリンクで動作してよい。図９で、ＡＰであるＡＰ１、ＡＰ２、ＡＰ３を含むＭＬＤをＡＰＭＬＤと呼ぶことができ、ｎｏｎ－ＡＰＳＴＡであるｎｏｎ－ＡＰＳＴＡ１、ｎｏｎ－ＡＰＳＴＡ２、ｎｏｎ－ＡＰＳＴＡ３を含むＭＬＤをｎｏｎ－ＡＰＭＬＤと呼ぶことができる。ＭＬＤに含まれているＳＴＡは、リンク１（Ｌｉｎｋ１）、リンク２（Ｌｉｎｋ２）、リンク３（Ｌｉｎｋ３）、又はリンク１～３のうち一部のリンクで動作できる。

本発明の実施例によれば、多重リンク動作は多重リンク設定（ｍｕｌｔｉ－ｌｉｎｋｓｅｔｕｐ）動作を含んでよい。多重リンク設定動作は、単一リンク動作で行われるアソシエーション（ａｓｓｏｃｉａｔｉｏｎ）に対応する動作であってよい。多重リンクでフレームを交換するためには多重リンク設定が先行される必要がある。多重リンク設定動作は、多重リンク設定要素（ｍｕｌｔｉ－ｌｉｎｋｓｅｔｕｐｅｌｅｍｅｎｔ）を用いて行われてよい。ここで、多重リンク設定要素は、多重リンクに関連した能力情報（ｃａｐａｂｉｌｉｔｙｉｎｆｏｒｍａｔｉｏｎ）を含んでよく、能力情報は、ＭＬＤに含まれたＳＴＡが一つのリンクでフレームを受信すると同時にＭＬＤに含まれた他のＳＴＡが他のリンクでフレームを送信できるかに関する情報を含んでよい。すなわち、能力情報は、ＭＬＤに含まれたリンクを通じてＳＴＡ（ｎｏｎ－ＡＰＳＴＡ及び／又はＡＰ（又は、ＡＰＳＴＡ）が互いに異なる送信方向に同時にフレームを送信／受信できるかに関する情報を含んでよい。また、能力情報は、利用可能なリンク又は動作チャネル（ｏｐｅｒａｔｉｎｇｃｈａｎｎｅｌ）に関する情報をさらに含んでよい。多重リンク設定は、ピアＳＴＡ（ｐｅｅｒＳＴＡ）間の交渉（ｎｅｇｏｔｉａｔｉｏｎ）によって設定されてよく、一つのリンクを通じて多重リンク動作が設定されてよい。

本発明の一実施例によれば、ＴＩＤとＭＬＤのリンク間にマッピング関係が存在してよい。例えば、ＴＩＤとリンクがマップされる場合に、ＴＩＤは、マップされたリンクで送信されてよい。ＴＩＤとリンク間のマッピングは、送信方向ベース（ｄｉｒｅｃｔｉｏｎａｌ－ｂａｓｅｄ）でなされてよい。例えば、ＭＬＤ１とＭＬＤ２間の両方向の各方向に対してマッピングがなされてよい。また、ＴＩＤとリンク間のマッピングは基本（ｄｅｆａｕｌｔ）設定が存在してよい。例えば、ＴＩＤとリンク間のマッピングは基本的に、あるリンクに全てのＴＩＤがマップされたことであってよい。

図１０は、本発明の一実施例に係るＴＩＤ－ｔｏ－ｌｉｎｋマッピング方法の一例を示す図である。

図１０を参照すると、図９で説明したようにＴＩＤとリンク間のマッピング関係が存在してよい。また、本発明において、ＴＩＤとリンク間のマッピング関係をＴＩＤ－ｔｏ－ｌｉｎｋマッピング、ＴＩＤツーリンクマッピング、ＴＩＤマッピング、リンクマッピングなどと呼ぶことができる。ＴＩＤはトラフィック識別子（ｔｒａｆｆｉｃｉｄｅｎｔｉｆｉｅｒ）であってよい。また、ＴＩＤは、ＱｏＳ（ｑｕａｌｉｔｙｏｆｓｅｒｖｉｃｅ）を支援するためにトラフィック、データなどを分類するＩＤ（ｉｄｅｎｔｉｆｉｅｒ）であってよい。

また、ＴＩＤは、ＭＡＣ層よりも上位層で用いられたり、割り当てられたりするＩＤであってよい。ＴＩＤは、ＴＣ（ｔｒａｆｆｉｃｃａｔｅｇｏｒｉｅｓ）、ＴＳ（ｔｒａｆｆｉｃｓｔｒｅａｍｓ）を示すことが可能である。また、ＴＩＤは、１６個の値が可能であり、例えば、０から１５までの値で示されてよい。また、接続政策（ａｃｃｅｓｓｐｏｌｉｃｙ）又はチャネル接続、媒体接続（ｍｅｄｉｕｍａｃｃｅｓｓ）方法によって個別のＴＩＤ値を用いることが可能である。例えば、ＥＤＣＡ（ＨＣＦ（ｈｙｂｒｉｄｃｏｏｒｄｉｎａｔｉｏｎｆｕｎｃｔｉｏｎ）連結ベースのチャネル接続、拡張型分散チャネル接続）を用いる場合に可能なＴＩＤ値は０～７であってよい。また、ＥＤＣＡを用いる場合に、ＴＩＤ値はＵＰ（ｕｓｅｒｐｒｉｏｒｉｔｙ）を示すものであってよく、前記ＵＰはＴＣ又はＴＳに関するものであってよい。また、ＵＰは、ＭＡＣよりも上位層に割り当てられる値であってよい。また、ＨＣＣＡ（ＨＣＦｃｏｎｔｒｏｌｌｅｄｃｈａｎｎｅｌａｃｃｅｓｓ）又はＳＰＣＡを用いる場合に可能なＴＩＤ値は８～１５であってよい。また、ＨＣＣＡ又はＳＰＣＡを用いる場合にＴＩＤはＴＳＩＤを示すものであってよい。また、ＨＥＭＭ又はＳＥＭＭを用いる場合に可能なＴＩＤ値は８～１５であってよい。また、ＨＥＭＭ又はＳＥＭＭを用いる場合にＴＩＤはＴＳＩＤを示すものであってよい。

また、ＵＰと接続カテゴリー（ａｃｃｅｓｓｃａｔｅｇｏｒｙ：ＡＣ）間のマッピング関係が存在してよい。ＡＣは、ＥＤＣＡにおいてＱｏＳを提供するためのラベル（ｌａｂｅｌ）又はＥＤＣＡパラメータのセットを指示するラベルであってよい。ＥＤＣＡパラメータ又はＥＤＣＡパラメータのセットは、チャネル連結に用いられるものであってよい。ＡＣは、ＱｏＳＳＴＡで用いられてよい。

ＡＣの値はＡＣ＿ＢＫ、ＡＣ＿ＢＥ、ＡＣ＿ＶＩ、ＡＣ＿ＶＯのうち一つに設定されてよい。ＡＣ＿ＢＫ、ＡＣ＿ＢＥ、ＡＣ＿ＶＩ、ＡＣ＿ＶＯはそれぞれ、ｂａｃｋｇｒｏｕｎｄ、ｂｅｓｔｅｆｆｏｒｔ、ｖｉｄｅｏ、ｖｏｉｃｅを示すものであってよい。また、ＡＣ＿ＢＫ、ＡＣ＿ＢＥ、ＡＣ＿ＶＩ、ＡＣ＿ＶＯを細分化することが可能である。例えば、ＡＣ＿ＶＩがＡＣ＿ＶＩｐｒｉｍａｒｙとＡＣ＿ＶＩａｌｔｅｒｎａｔｅに細分化されてよい。また、ＡＣ＿ＶＯがＡＣ＿ＶＯｐｒｉｍａｒｙとＡＣ＿ＶＯａｌｔｅｒｎａｔｅに細分化されてよい。また、ＵＰ値又はＴＩＤ値はＡＣ値とマップされてよい。例えば、ＵＰ値又はＴＩＤ値１、２、０、３、４、５、６、７はそれぞれ、ＡＣ＿ＢＫ、ＡＣ＿ＢＫ、ＡＣ＿ＢＥ、ＡＣ＿ＢＥ、ＡＣ＿ＶＩ、ＡＣ＿ＶＩ、ＡＣ＿ＶＯ、ＡＣ＿ＶＯとマップされてよい。又は、ＵＰ値又はＴＩＤ値１、２、０、３、４、５、６、７はそれぞれ、ＡＣ＿ＢＫ、ＡＣ＿ＢＫ、ＡＣ＿ＢＥ、ＡＣ＿ＢＥ、ＡＣ＿ＶＩａｌｔｅｒｎａｔｅ、ＡＣ＿ＶＩｐｒｉｍａｒｙ、ＡＣ＿ＶＯｐｒｉｍａｒｙ、ＡＣ＿ＶＯａｌｔｅｒｎａｔｅとマップされてよい。また、ＵＰ値又はＴＩＤ値１、２、０、３、４、５、６、７は順に優先度（ｐｒｉｏｒｉｔｙ）が高いものであってよい。すなわち、１の方が低い優先度であり、７の方が高い優先度であってよい。したがって、ＡＣ＿ＢＫ、ＡＣ＿ＢＥ、ＡＣ＿ＶＩ、ＡＣ＿ＶＯの順に優先度が高くなるものであってよい。また、ＡＣ＿ＢＫ、ＡＣ＿ＢＥ、ＡＣ＿ＶＩ、ＡＣ＿ＶＯはそれぞれ、ＡＣＩ（ＡＣｉｎｄｅｘ）０、１、２、３に該当してよい。

したがって、ＴＩＤとＡＣ間の関係が存在することが可能である。したがって、本発明のＴＩＤ－ｔｏ－ｌｉｎｋマッピングは、ＡＣとリンク間のマッピング関係であってもよい。また、本発明において、ＴＩＤがマップされたということは、ＡＣがマップされたことであってもよく、その逆であってもよい。

本発明の一実施例によれば、ｍｕｌｔｉ－ｌｉｎｋの各リンクにマップされたＴＩＤが存在してよい。例えば、特定ＴＩＤ又は特定ＡＣが複数のリンクのうちいずれのリンクで送信、受信が許容されるかに対するマッピングが存在してよい。また、このようなマッピングは、リンクの両方向の各方向に対して個別に定義されてよい。また、前述したように、ＴＩＤとリンク間のマッピングは、基本（ｄｅｆａｕｌｔ）設定が存在してよい。例えば、ＴＩＤとリンク間のマッピングは基本的に、あるリンクに全てのＴＩＤがマップされてよい。また、一実施例によれば、特定時点に、あるＴＩＤ又はあるＡＣは少なくとも一つのリンクとはマップされていてよい。また、マネジメントフレーム（ｍａｎａｇｅｍｅｎｔｆｒａｍｅ）又は制御フレーム（ｃｏｎｔｒｏｌｆｒａｍｅ）は、全てのリンクで送信されてよい。

本発明において、リンクのいずれかの方向に対してマップされたＴＩＤ又はＡＣに該当するデータフレームが送信されてよい。また、リンクのいずれかの方向に対してマップされていないＴＩＤ又はＡＣに該当するデータフレームは送信されなくてよい。

一実施例によればＴＩＤ－ｔｏ－ｌｉｎｋマッピングがａｃｋｎｏｗｌｅｄｇｍｅｎｔにも適用されてよい。例えば、ｂｌｏｃｋａｃｋａｇｒｅｅｍｅｎｔがＴＩＤ－ｔｏ－ｌｉｎｋマッピングに基づき得る。又は、ＴＩＤ－ｔｏ－ｌｉｎｋマッピングはｂｌｏｃｋａｃｋａｇｒｅｅｍｅｎｔに基づき得る。例えば、ＴＩＤ－ｔｏ－ｌｉｎｋマップされたＴＩＤに対してｂｌｏｃｋａｃｋａｇｒｅｅｍｅｎｔが存在することが可能である。

ＴＩＤ－ｔｏ－ｌｉｎｋマッピングをすることによってＱｏＳサービスを提供することが可能である。例えば、チャネル状態が良い或いはＳＴＡが少ないリンクに、優先度の高いＡＣ、ＴＩＤをマップすることによって、当該ＡＣ、ＴＩＤのデータを迅速に送信することが可能である。又は、ＴＩＤ－ｔｏ－ｌｉｎｋマッピングをすることにより、特定リンクのＳＴＡが節電（ｐｏｗｅｒｓａｖｅ）できるように（又は、ｄｏｚｅ状態に入るように）助けることができる。

図１０を参照すると、ＡＰ１とＡＰ２を含むＡＰＭＬＤが存在してよい。また、ＳＴＡ１とＳＴＡ２を含むＮｏｎ－ＡＰＭＬＤが存在してよい。また、前記ＡＰＭＬＤに複数のリンクであるＬｉｎｋ１とＬｉｎｋ２が存在してよい。ＡＰ１とＳＴＡ１はＬｉｎｋ１でアソシエーションされ、ＡＰ２とＳＴＡ２はＬｉｎｋ２でアソシエーションされてよい。

したがって、Ｌｉｎｋ１は、ＡＰ１からＳＴＡ１へと送信するリンク及び／又はＳＴＡ１からＡＰ１へと送信するリンクを含んでよく、Ｌｉｎｋ２は、ＡＰ２からＳＴＡ２へと送信するリンク及び／又はＳＴＡ２からＡＰ２へと送信するリンクを含んでよい。このとき、それぞれのリンクはＴＩＤ及び／又はＡＣがマップされていてよい。

例えば、Ｌｉｎｋ１でＡＰ１からＳＴＡ１に送信するリンク、Ｌｉｎｋ１でＳＴＡ１からＡＰ１に送信するリンクには全てのＴＩＤ、全てのＡＣがマップされていてよい。また、Ｌｉｎｋ２でＳＴＡ２からＡＰ２に送信するリンクには、ＡＣ＿ＶＯ又はＡＣ＿ＶＯに該当するＴＩＤのみがマップされていてよい。また、マップされたＴＩＤ及び／又はＡＣのデータのみが当該リンクで送信されることが可能である。また、リンクにマップされていないＴＩＤ又はＡＣのデータは当該リンクで送信されることが不可能である。

図１１は、本発明の一実施例に係るｍｕｌｔｉ－ｌｉｎｋＮＡＶ設定動作の一例を示す図である。

ＭＬＤが同時に送信又は受信する動作（ＳＴＲ；ｓｉｍｕｌｔａｎｅｏｕｓｔｒａｎｓｍｉｔａｎｄｒｅｃｅｉｖｅ；ｓｉｍｕｌｔａｎｅｏｕｓｔｒａｎｓｍｉｓｓｉｏｎａｎｄｒｅｃｅｐｔｉｏｎ）は制限的であってよく、これは、多重リンク（ｍｕｌｔｉ－ｌｉｎｋ）で動作する複数のリンク間の周波数間隔と関連していてよい。

したがって、本発明の実施例によれば、リンク間の間隔がｍＭＨｚであるとき、同時に送信又は受信することが制限的であり、ｍよりも大きいｎに対してリンク間の間隔がｎＭＨｚであるとき、同時に送信又は受信することが制限的でなくてよい。本実施例は、同時に送信又は受信することが制限的である問題を解決するためのものであってよく、重複説明は省略されてよい。また、本実施例をＳＴＲ不可なＭＬＤに対して適用することが可能である。

本発明の一実施例によれば、多重リンクとして動作するリンク間に期間情報（ｄｕｒａｔｉｏｎｉｎｆｏｒｍａｔｉｏｎ）が共有されてよい。一実施例として、前記期間情報は、プリアンブルのシグナリングフィールドで送信されるＴＸＯＰｄｕｒａｔｉｏｎ情報であってよい。前記シグナリングフィールドは、前述したＵ－ＳＩＧフィールドであってよい。又は、前記シグナリングフィールドは、前述したＨＥ－ＳＩＧ－Ａフィールドであってよい。さらに他の実施例として、前記期間情報は、ＭＡＣｈｅａｄｅｒが含むＤｕｒａｔｉｏｎ／ＩＤフィールドが指示する期間情報であってよい。さらに他の実施例として、前記期間情報は、Ｌ－ＳＩＧフィールドが含むＬｅｎｇｔｈフィールド（ＬＬｅｎｇｔｈｆｉｅｌｄ）が指示する期間情報であってよい。一実施例によれば、Ｕ－ＳＩＧフィールド又はＨＥ－ＳＩＧ－Ａ又はＤｕｒａｔｉｏｎ／ＩＤフィールドが指示する期間情報は、ＴＸＯＰｄｕｒａｔｉｏｎを指示する値であってよい。一実施例によれば、Ｌ－ＳＩＧフィールドが指示する期間情報は、前記Ｌ－ＳＩＧフィールドを含むＰＰＤＵ（ｐｈｙｓｉｃａｌｌａｙｅｒｐｒｏｔｏｃｏｌｄａｔａｕｎｉｔ）の長さ又は前記Ｌ－ＳＩＧフィールドを含むＰＰＤＵの終わりを指示する値であってよい。

また、本発明の実施例によれば、リンク間に共有された期間情報に基づく期間に送信又はチャネル接続を行うことを制限することができる。送信又はチャネル接続を制限する方法は、ＮＡＶを設定することを含んでよい。又は、送信又はチャネル接続を再開するためにＮＡＶをリセットすることができる。このとき、ＮＡＶはｉｎｔｒａ－ＢＳＳＮＡＶであってよい。Ｉｎｔｒａ－ＢＳＳＮＡＶは、ｉｎｔｒａ－ＢＳＳフレーム（又は、ＰＰＤＵ）によって設定されるＮＡＶであってよい。すなわち、ＭＬＤに属したＳＴＡは、前記ＭＬＤに属した他のＳＴＡに向かうフレーム（又は、ＰＰＤＵ）に基づいてＮＡＶを設定することができる。

本発明の一実施例によれば、ｉｎｔｅｒ－ｌｉｎｋＮＡＶが存在してよい。Ｉｎｔｅｒ－ｌｉｎｋＮＡＶは、多重リンクで動作する場合に、あるＭＬＤに属した複数のリンクのＳＴＡが用いるＮＡＶであってよい。例えば、リンク１で受信した期間情報に基づいて設定したｉｎｔｅｒ－ｌｉｎｋＮＡＶに基づいてリンク２で送信をしなくてよい。また、ｉｎｔｅｒ－ｌｉｎｋＮＡＶは、ＳＴＲ不可なＭＬＤに対して存在又は利用することが可能である。例えば、ｉｎｔｅｒ－ｌｉｎｋＮＡＶが設定された場合に、当該ｉｎｔｅｒ－ｌｉｎｋＮＡＶを設定したＭＬＤは、複数のリンク（又は、ＭＬＤが用いる全てのリンク）で送信又はチャネル接続をしなくてよい。

また、ＮＡＶの種類としてｉｎｔｒａ－ＢＳＳＮＡＶの他にｂａｓｉｃＮＡＶが存在してよい。ＢａｓｉｃＮＡＶは、ｉｎｔｅｒ－ＢＳＳフレーム（又は、ＰＰＤＵ）によって設定されるＮＡＶであってよく、ｉｎｔｒａ－ＢＳＳかｉｎｔｅｒ－ＢＳＳかが判断されないフレーム（又は、ＰＰＤＵ）によってもｂａｓｉｃＮＡＶが設定されてよい。

Ｉｎｔｅｒ－ｌｉｎｋＮＡＶを別に用いる場合に、ｉｎｔｅｒ－ｌｉｎｋＮＡＶを用いない場合に比べて、ＮＡＶ設定がアップデートされる状況において長所を有し得る。例えば、他のリンクによって設定したＮＡＶをリセットしても構わない状況が発生し得る。例えば、あるフレーム（又は、ＰＰＤＵ）に基づいてｉｎｔｅｒ－ｌｉｎｋＮＡＶを設定したが、前記フレーム（又は、ＰＰＤＵ）が同一ＭＬＤに向かうものでないと判断され、設定したｉｎｔｅｒ－ｌｉｎｋＮＡＶをリセットしても構わないことがある。仮に、リンク１とリンク２で動作するＭＬＤが存在するとき、リンク１に対するＮＡＶが、リンク１で受信したフレームに基づいて設定されていてよい。その後、リンク２のフレームに基づいてリンク１のＮＡＶをアップデートしてよい。そして、リンク２によるＮＡＶは維持する必要がなくなったとき、リンク１のＮＡＶをリセットすれば、リンク１で受信したフレームに基づいて設定したＮＡＶ情報を失う不具合がある。仮にｉｎｔｅｒ－ｌｉｎｋＮＡＶを各リンクに対するＮＡＶと共に用いれば、ｉｎｔｅｒ－ｌｉｎｋＮＡＶをリセットしても各リンクに対するＮＡＶが維持され、上記の不具合を解決することができる。

本発明の実施例においてＮＡＶを設定することを取り上げたが、本発明の実施例は、これに限定されず、物理層にチャネル接続を中断するように指示するか、チャネル状態をｂｕｓｙと指示することにも適用可能である。また、ＮＡＶをリセットすることに限定されず、物理層にチャネル接続を続けるように指示したり、チャネル状態をｉｄｌｅと指示したりすることにも適用可能である。このとき、物理層とＭＡＣ層間に授受するｐｒｉｍｉｔｉｖｅが用いられてよい。又は、ＭＬＤの一つのＳＴＡと他のＳＴＡ間に授受するｐｒｉｍｉｔｉｖｅが用いられてよい。又は、ＭＬＤの一つのＭＡＣ層と他のＭＡＣ層間に授受するｐｒｉｍｉｔｉｖｅが用いられてよい。

本発明の実施例によれば、ＭＬＤに属したＳＴＡがＰＰＤＵ受信を始めると、前記ＭＬＤに属した他のＳＴＡはチャネル接続を止めなければならないことがある。前述したように、受信した期間情報に基づいてチャネル接続を止めてよいが、期間情報を含むフィールドの位置のため又はデコーディングなどにかかる時間のため、ＰＰＤＵを受信し始めた時点から期間情報を得るまで時間が存在し得る。このため、この時間においてチャネルにアクセスして送信を始めると前述の問題につながり得る。このため、本発明の一実施例によれば、ＭＬＤのＳＴＡは、前記ＭＬＤの他のＳＴＡが受信を始めた時点からチャネル接続を中断することができる。また、前記ＭＬＤの他のＳＴＡが受信を始めた後に受信したフレームが前記他のＳＴＡに向かうものでないことを確認した場合にチャネル接続を再び始めることがてきる。

図１２は、本発明の一実施例に係るｍｕｌｔｉ－ｌｉｎｋＮＡＶ設定動作のさらに他の例を示す図である。

図１２は、図１１で説明した実施例の具体的な方法に関する説明を具体化したものであり、重複説明は省略されてよい。

前述したように、ＭＬＤに属したあるＳＴＡが受信するフレーム又はＰＰＤＵに基づいて、同一ＭＬＤに属した他のＳＴＡがチャネル接続又は送信を中止又は再開することができる。本発明において、チャネル接続又は送信を中止することは、ＮＡＶを設定する（アップデートする）、チャネルをｂｕｓｙと判断する、又はＣＣＡを中止するなどの動作を含んでよい。また、チャネル接続又は送信を再開することは、ＮＡＶをリセットする、ＮＡＶ設定を取消（ｃａｎｃｅｌ）する、チャネルをｉｄｌｅと判断する、又はＣＣＡを行うなどの動作を含んでよい。以下では、このような動作を、チャネル接続を中止し再開することとして指示できる。また、以下、ＭＬＤにＳＴＡ１とＳＴＡ２が属しており、ＳＴＡ１とＳＴＡ２はそれぞれＬｉｎｋ１とＬｉｎｋ２で動作するとして説明できる。また、フレームとＰＰＤＵを相互互換的に指示できる。また、この時のＮＡＶは、図１１で説明したようにｉｎｔｒａ－ＢＳＳＮＡＶ又はｉｎｔｅｒ－ｌｉｎｋＮＡＶであってよい。

本発明の実施例によれば、ＳＴＡ１がフレーム受信し始めると、ＳＴＡ２はチャネル接続を中断してよい。また、ＳＴＡ１がＬ－ＳＩＧから期間情報（ｄｕｒａｔｉｏｎｉｎｆｏｒｍａｔｉｏｎ）を取得したとき、ＳＴＡ２はチャネル接続を中断した状態を持続してよい。この時、ＳＴＡ２がチャネル接続を中断した状態を、ＳＴＡ１が受信したフレームの終わりまでと決定できる。また、ＳＴＡ１がＬ－ＳＩＧを確かにデコードできなかった場合（ｉｎｖａｌｉｄＬ－ＳＩＧである場合）に、ＳＴＡ２はチャネル接続を再開できる。

また、ＳＴＡ１が受信するフレームのＵ－ＳＩＧからＴＸＯＰｄｕｒａｔｉｏｎとＢＳＳｃｏｌｏｒを受信することができる。仮に、受信したＢＳＳｃｏｌｏｒがｉｎｔｒａ－ＢＳＳであることを示すか、ＢＳＳｃｏｌｏｒがＳＴＡ１に該当するＢＳＳｃｏｌｏｒである場合に、チャネル接続を中断できる。一実施例として、この時にチャネル接続を中断する期間は、受信したフレームの終わりまでであってよい。この場合、受信したフレームが終わった後、より早くチャネル接続を開始できる長所がある。他の実施例として、この時にチャネル接続を中断する期間はＴＸＯＰｄｕｒａｔｉｏｎであってよい。この場合、Ｌ－ＳＩＧに基づいて中断したチャネル接続の期間はアップデートされてよい。この場合、受信するフレームに続くシーケンス（ｓｅｑｕｅｎｃｅ）をよりよく保護できる長所がある。

又は、ＳＴＡ１が受信するフレームのＵ－ＳＩＧからＴＸＯＰｄｕｒａｔｉｏｎとＢＳＳｃｏｌｏｒを受信したし、受信したＢＳＳｃｏｌｏｒがｉｎｔｒａ－ＢＳＳでないことを示すか、ＢＳＳｃｏｌｏｒがＳＴＡ１に該当するＢＳＳｃｏｌｏｒでない場合があり得る。又は、ＳＴＡ１がＵ－ＳＩＧを成功的にデコードできなかった場合があり得る。このような場合、ＳＴＡ２はチャネル接続を再開できる。

又は、ＳＴＡ１が受信するフレームのＵ－ＳＩＧから取得した情報が、当該フレームがＳＴＡ１が受信しないフレームであることを指示する場合に、ＳＴＡ２はチャネル接続を再開できる。例えば、Ｕ－ＳＩＧから取得したＰＨＹｉｄｅｎｔｉｆｉｅｒが、将来の標準に該当するＩＤ又は認識できないＩＤである場合に、ＳＴＡ２はチャネル接続を再開できる。

また、Ｕ－ＳＩＧを受信する場合を説明したが、同実施例を、ＨＥＰＰＤＵを受信するとき、ＨＥ－ＳＩＧ－Ａを受信する場合にも適用できる。例えば、ＨＥ－ＳＩＧ－ＡはＴＸＯＰｄｕｒａｔｉｏｎとＢＳＳｃｏｌｏｒを含んでよく、よって、前述したような動作を行うことができる。

また、ＳＴＡ１が受信するフレームのＥＨＴ－ＳＩＧからＳＴＡ－ＩＤを受信していることがある。仮に、受信したＳＴＡ－ＩＤがＳＴＡ１の受信するべき指示子であれば、例えば、ＳＴＡ－ＩＤがＳＴＡ１を示す、ＳＴＡ－ＩＤがＳＴＡ１の属したグループを示す、又はＳＴＡ－ＩＤがｂｒｏａｄｃａｓｔを示す場合に、ＳＴＡ２はチャネル接続を中断した状態を持続できる。

又は、ＳＴＡ１が受信するフレームのＥＨＴ－ＳＩＧからＳＴＡ－ＩＤを受信していることがある。仮に、受信したＳＴＡ－ＩＤがＳＴＡ１に該当しない指示子であれば、例えば、ＳＴＡ－ＩＤがＳＴＡ１に該当する指示子を示さない、ＳＴＡ－ＩＤがＳＴＡ１の属したグループを示さない、又はＳＴＡ－ＩＤがｂｒｏａｄｃａｓｔを示さない場合に、ＳＴＡ２はチャネル接続を再開できる。又は、ＳＴＡ１がＥＨＴ－ＳＩＧを成功的にデコードできなかった場合にもＳＴＡ２はチャネル接続を再開できる。

また、ＥＨＴ－ＳＩＧを受信する場合を説明したが、同実施例を、ＨＥＰＰＤＵを受信するとき、ＨＥ－ＳＩＧ－Ｂを受信する場合にも適用できる。例えば、ＨＥ－ＳＩＧ－ＢはＳＴＡ－ＩＤを含んでよく、よって、前述したような動作を行うことができる。

また、ＳＴＡ１が受信するフレームのＭＡＣｈｅａｄｅｒを受信していることがある。仮に、受信したＭＡＣｈｅａｄｅｒが含むＲＡ（ｒｅｃｅｉｖｅｒａｄｄｒｅｓｓ）又はＤＡ（ｄｅｓｔｉｎａｔｉｏｎａｄｄｒｅｓｓ）がＳＴＡ１の受信するべき値を示す場合に、例えば、ＲＡ又はＤＡがＳＴＡ１を示す、ＳＴＡ１の属したグループを示す、又はＳＴＡ－ＩＤがｂｒｏａｄｃａｓｔを示す場合に、ＳＴＡ２はチャネル接続を中断した状態を持続できる。この時、中断するチャネルアクセスの期間は、受信したＭＡＣｈｅａｄｅｒが含む期間情報に基づき得る。より具体的には、中断するチャネルアクセスの期間は、受信したＭＡＣｈｅａｄｅｒが含むＤｕｒａｔｉｏｎ／ＩＤフィールドが指示する期間情報に基づき得る。

また、ＳＴＡ１が受信するフレームのＭＡＣｈｅａｄｅｒを受信していることがある。仮に、受信したＭＡＣｈｅａｄｅｒが含むＲＡ又はＤＡが、ＳＴＡ１に該当しない指示子である場合に、例えば、ＲＡ又はＤＡがＳＴＡ１に該当する指示子を示さない、ＳＴＡ１の属したグループを示さない、又はｂｒｏａｄｃａｓｔを示さない場合に、ＳＴＡ２はチャネル接続を再開できる。又は、ＳＴＡ１が全てのＭＡＣｈｅａｄｅｒを受信していないことがある。例えば、ＳＴＡ１がＡ－ＭＰＤＵに含まれた全てのＭＰＤＵを受信失敗することがある。この場合、ＳＴＡ２はチャネル接続を再開できる。

図１２で説明したチャネル接続中断と再開は、ＳＴＡ１でフレーム（又は、ＰＰＤＵ）を受信し始めて順次にデコードして行くにつれてデコードされる順に動作してよい。デコードされる順序は、ＰＰＤＵフォーマット、フレームフォーマットなどに基づき得る。例えば、Ｌ－ＳＩＧ、Ｕ－ＳＩＧ、ＥＨＴ－ＳＩＧ、ＭＡＣｈｅａｄｅｒの順にデコードできる（ＥＨＴＰＰＤＵの場合）。又は、Ｌ－ＳＩＧ、ＨＥ－ＳＩＧ－Ａ、ＭＡＣｈｅａｄｅｒの順にデコードできる（ＨＥＳＵＰＰＤＵ、ＨＥＴＢＰＰＤＵの場合）。又は、Ｌ－ＳＩＧ、ＨＥ－ＳＩＧ－Ａ、ＨＥ－ＳＩＧ－Ｂ、ＭＡＣｈｅａｄｅｒの順にデコードできる（ＨＥＭＵＰＰＤＵの場合）。又は、Ｌ－ＳＩＧ、ＭＡＣｈｅａｄｅｒの順にデコードできる（１１ａ／ｇＰＰＤＵの場合）。

本発明の実施例によれば、先に言及したＳＴＡ－ＩＤは、ＰＰＤＵ又はＲＵ（ｒｅｓｏｕｒｃｅｕｎｉｔ）の意図した受信者を指示する値であってよい。また、ＳＴＡ－ＩＤは、ＥＨＴ－ＳＩＧフィールド又はＨＥ－ＳＩＧ－Ｂフィールドなどに含まれてよい。また、ＳＴＡ－ＩＤは、単一ＳＴＡに該当する値を示すことが可能である。例えば、複数のＳＴＡがＭＬＤに含まれるとき、ＳＴＡ－ＩＤは前記複数のＳＴＡのうち一つのＳＴＡに該当する値を示すことが可能である。また、ＳＴＡ－ＩＤは、ＳＴＡのＡＩＤ又はＭＡＣａｄｄｒｅｓｓに基づく値であってよい。

図１３は、本発明の一実施例に係るＢＳＳ分類及びそれに基づく動作の一例を示す図である。

本発明の一実施例によれば、ＳＴＡは、受信したフレーム又は受信したＰＰＤＵに基づいてＢＳＳを分類（ｃｌａｓｓｉｆｙ）（又は、判断）することが可能である。ＢＳＳを分類することは、受信したフレーム又は受信したＰＰＤＵが、分類するＳＴＡの属したＢＳＳに該当するか否かを分類する動作を含んでよい。又は、ＢＳＳを分類することは、受信したフレーム又は受信したＰＰＤＵが、分類するＳＴＡの属したＢＳＳから送信されたか否かを分類する動作を意味できる。また、ＢＳＳを分類することは、受信したフレーム又は受信したＰＰＤＵが、分類するＳＴＡの属していないＢＳＳに該当するか否かを分類する動作を含んでよい。又は、ＢＳＳを分類することは、受信したフレーム又は受信したＰＰＤＵが、分類するＳＴＡの属していないＢＳＳから送信されたか否かを分類する動作を意味できる。また、ＢＳＳを分類することは、受信したフレーム又は受信したＰＰＤＵがどのＢＳＳに属したかを分類する動作を含んでよい。又は、ＢＳＳを分類することは、受信したフレーム又は受信したＰＰＤＵがどのＢＳＳから送信されたかを分類する動作を意味できる。本発明の一実施例によれば、分類するＳＴＡの属したＢＳＳをｉｎｔｒａ－ＢＳＳと呼ぶことができる。又は、分類するＳＴＡの属したＢＳＳを含むＢＳＳをｉｎｔｒａ－ＢＳＳと呼ぶことができる。また、ｉｎｔｒａ－ＢＳＳでないＢＳＳをｉｎｔｅｒ－ＢＳＳと呼ぶことができる。又は、ｉｎｔｒａ－ＢＳＳでないＢＳＳはｉｎｔｅｒ－ＢＳＳであるか又は分類されないＢＳＳであってよい。又は、ｉｎｔｅｒ－ＢＳＳは、分類されないＢＳＳを含んでよい。また、分類するＳＴＡが属していないＢＳＳをｉｎｔｅｒ－ＢＳＳと呼ぶことができる。

一実施例によれば、受信したフレーム又は受信したＰＰＤＵがｉｎｔｒａ－ＢＳＳに該当したり又はｉｎｔｒａ－ＢＳＳから送信されたと判断されたりした場合に、前記受信したフレーム又は前記受信したＰＰＤＵをそれぞれｉｎｔｒａ－ＢＳＳフレーム、ｉｎｔｒａ－ＢＳＳＰＰＤＵということができる。また、受信したフレーム又は受信したＰＰＤＵがｉｎｔｅｒ－ＢＳＳに該当したり又はｉｎｔｅｒ－ＢＳＳから送信されたと判断されたりした場合に、前記受信したフレーム又は前記受信したＰＰＤＵをそれぞれｉｎｔｅｒ－ＢＳＳフレーム、ｉｎｔｅｒ－ＢＳＳＰＰＤＵということができる。また、ｉｎｔｒａ－ＢＳＳフレームを含むＰＰＤＵはｉｎｔｒａ－ＢＳＳＰＰＤＵであってよい。また、ｉｎｔｅｒ－ＢＳＳフレームを含むＰＰＤＵはｉｎｔｅｒ－ＢＳＳＰＰＤＵであってよい。

本発明の一実施例によれば、一つ以上のＢＳＳ分類条件に基づいてＢＳＳを分類できる。例えば、前記一つ以上のＢＳＳ分類条件のうち少なくとも一つの条件を満たすか否かによってＢＳＳを分類できる。

前記ＢＳＳ分類条件は、ＢＳＳｃｏｌｏｒに基づく条件を含んでよい。ＢＳＳｃｏｌｏｒは、ＢＳＳに対する識別子（ｉｄｅｎｔｉｆｉｅｒ）であってよい。また、ＢＳＳｃｏｌｏｒは、ＰＰＤＵのプリアンブル（ｐｒｅａｍｂｌｅ）、より具体的にはｓｉｇｎａｌｉｎｇフィールド（例えば、ＨＥ－ＳＩＧ－Ａフィールド又はＵ－ＳＩＧフィールド又はＶＨＴ－ＳＩＧ－Ａフィールド）に含まれてよい。また、ＢＳＳｃｏｌｏｒは、送信者のＭＡＣ層からＰＨＹ層へ伝達されるＴＸＶＥＣＴＯＲに含まれてよい。また、ＢＳＳｃｏｌｏｒは、受信者のＰＨＹ層からＭＡＣ層に伝達されるＲＸＶＥＣＴＯＲに含まれてよい。ＴＸＶＥＣＴＯＲ、ＲＸＶＥＣＴＯＲに含まれるパラメータをそれぞれ、ＴＸＶＥＣＴＯＲパラメータ、ＲＸＶＥＣＴＯＲパラメータと呼ぶことができる。また、ＢＳＳｃｏｌｏｒは、ＴＸＶＥＣＴＯＲパラメータ又はＲＸＶＥＣＴＯＲパラメータに含まれてよい。また、ＡＰが設定したＢＳＳｃｏｌｏｒをＳＴＡに知らせることができる。一実施例によれば、受信したＰＰＤＵに含まれたＢＳＳｃｏｌｏｒに基づいてＢＳＳを分類できる。仮に、ＳＴＡの受信したＰＰＤＵに含まれたＢＳＳｃｏｌｏｒが、ＳＴＡに該当するＢＳＳのＢＳＳｃｏｌｏｒと異なる場合に、前記受信したＰＰＤＵをｉｎｔｅｒ－ＢＳＳＰＰＤＵに分類できる。又は、仮に、ＳＴＡの受信したＰＰＤＵに含まれたＢＳＳｃｏｌｏｒが、ＳＴＡに該当するＢＳＳのＢＳＳｃｏｌｏｒと異なり、その値が０でない場合に、前記受信したＰＰＤＵをｉｎｔｅｒ－ＢＳＳＰＰＤＵに分類できる。また、仮に、ＳＴＡの受信したＰＰＤＵに含まれたＢＳＳｃｏｌｏｒが、ＳＴＡに該当するＢＳＳのＢＳＳｃｏｌｏｒと同一である場合に、前記受信したＰＰＤＵをｉｎｔｒａ－ＢＳＳＰＰＤＵに分類できる。

前記ＢＳＳ分類条件はＭＡＣａｄｄｒｅｓｓに基づく条件を含んでよい。ＭＡＣａｄｄｒｅｓｓは、フレームのＭＡＣｈｅａｄｅｒに含まれてよい。また、ＭＡＣａｄｄｒｅｓｓは、ＲＡ（ｒｅｃｅｉｖｅｒａｄｄｒｅｓｓ）、ＴＡ（ｔｒａｎｓｍｉｔｔｅｒａｄｄｒｅｓｓ）、ＢＳＳＩＤ、ＳＡ（ｓｏｕｒｃｅａｄｄｒｅｓｓ）、ＤＡ（ｄｅｓｔｉｎａｔｉｏｎａｄｄｒｅｓｓ）などを含んでよい。一実施例によれば、受信したフレームに含まれたＭＡＣａｄｄｒｅｓｓに基づいてＢＳＳを分類できる。仮に、受信したフレームに含まれたＭＡＣａｄｄｒｅｓｓが、ＳＴＡに該当するＢＳＳのＢＳＳＩＤと異なる場合に、前記受信したフレームをｉｎｔｅｒ－ＢＳＳフレームに分類できる。より具体的には、仮に受信したフレームに含まれたＭＡＣａｄｄｒｅｓｓがいずれも、ＳＴＡに該当するＢＳＳのＢＳＳＩＤと異なる場合に、前記受信したフレームをｉｎｔｅｒ－ＢＳＳフレームに分類できる。また、仮に、受信したフレームに含まれたＭＡＣａｄｄｒｅｓｓが、ＳＴＡに該当するＢＳＳのＢＳＳＩＤと同一である場合に、前記受信したフレームをｉｎｔｒａ－ＢＳＳフレームに分類できる。より具体的には、仮に、受信したフレームに含まれたＭＡＣａｄｄｒｅｓｓのうち少なくとも一つがＳＴＡに該当するＢＳＳのＢＳＳＩＤと同一である場合に、前記受信したフレームをｉｎｔｒａ－ＢＳＳフレームに分類できる。

前記該当するＢＳＳは、ＳＴＡがアソシエーションされたＢＳＳを含んでよい。また、前記該当するＢＳＳは、ＳＴＡがアソシエーションされたＢＳＳと同じｍｕｌｔｉｐｌｅＢＳＳＩＤｓｅｔに含まれたＢＳＳを含んでよい。また、前記該当するＢＳＳは、ＳＴＡがアソシエーションされたＢＳＳと同じｃｏ－ｈｏｓｔｅｄＢＳＳＩＤｓｅｔに含まれたＢＳＳを含んでよい。また、同じｍｕｌｔｉｐｌｅＢＳＳＩＤｓｅｔ又は同じｃｏ－ｈｏｓｔｅｄＢＳＳＩＤｓｅｔに含まれた一つ以上のＢＳＳは、一つのフレームを通じて前記一つ以上のＢＳＳに関する情報が伝達されてよい。

前記ＢＳＳ分類条件は、ＶＨＴＰＰＤＵに含まれたＰａｒｔｉａｌＡＩＤフィールド値に基づく条件を含んでよい。ＰａｒｔｉａｌＡＩＤフィールドは、ＶＨＴＰＰＤＵのプリアンブルに含まれてよい。また、ＰａｒｔｉａｌＡＩＤフィールドは、ＶＨＴＰＰＤＵに含まれたＶＨＴ－ＳＩＧ－Ａフィールドに含まれてよい。一実施例によれば、ＰａｒｔｉａｌＡＩＤフィールドは、ＢＳＳｃｏｌｏｒの一部を示すことが可能である。例えば、ｐａｒｔｉａｌＢＳＳｃｏｌｏｒ機能を用いる場合に、ＰａｒｔｉａｌＡＩＤフィールドは、ＢＳＳｃｏｌｏｒの一部を示すことが可能である。又は、ＡＩＤ割り当て規定（ＡＩＤａｓｓｉｇｎｍｅｎｔｒｕｌｅ）を用いる場合に、ＰａｒｔｉａｌＡＩＤフィールドは、ＢＳＳｃｏｌｏｒの一部を示すことが可能である。ＡＩＤ割り当て規定は、ＢＳＳｃｏｌｏｒに基づくＡＩＤを割り当てる方法であってよい。またＶＨＴＰＰＤＵのＶＨＴ－ＳＩＧ－Ａフィールドに含まれたＧｒｏｕｐＩＤフィールドが既に設定された値である場合（例えば、ＧｒｏｕｐＩＤフィールドが６３に設定された場合）に、ＰａｒｔｉａｌＡＩＤフィールドは、ＢＳＳｃｏｌｏｒの一部を示すことが可能である。一実施例によれば、受信したＰＰＤＵのＰａｒｔｉａｌＡＩＤフィールドがＢＳＳｃｏｌｏｒの一部を示す場合に、受信したＰａｒｔｉａｌＡＩＤフィールド値が受信したＳＴＡに該当するＢＳＳｃｏｌｏｒの一部と異なると、前記受信したＰＰＤＵをｉｎｔｅｒ－ＢＳＳＰＰＤＵに分類できる。

また、受信したＰＰＤＵのＰａｒｔｉａｌＡＩＤフィールドがＢＳＳｃｏｌｏｒの一部を示す場合に、受信したＰａｒｔｉａｌＡＩＤフィールド値が、受信したＳＴＡに該当するＢＳＳｃｏｌｏｒの一部と同一であれば、前記受信したＰＰＤＵをｉｎｔｒａ－ＢＳＳＰＰＤＵに分類できる。また、このとき、ＢＳＳｃｏｌｏｒの一部は、ＢＳＳｃｏｌｏｒの４ＬＳＢｓであることが可能である。さらに他の実施例によれば、ＰａｒｔｉａｌＡＩＤフィールドはＢＳＳＩＤの一部を示すことが可能である。例えば、ＶＨＴＰＰＤＵのＶＨＴ－ＳＩＧ－Ａフィールドに含まれたＧｒｏｕｐＩＤフィールドが既に設定された値である場合（例えば、ＧｒｏｕｐＩＤフィールドが０に設定された場合）に、ＰａｒｔｉａｌＡＩＤフィールドはＢＳＳＩＤの一部を示すことが可能である。一実施例によれば、受信したＰＰＤＵのＰａｒｔｉａｌＡＩＤフィールドがＢＳＳＩＤの一部を示す場合に、受信したＰａｒｔｉａｌＡＩＤフィールド値が、受信したＳＴＡに該当するＢＳＳＩＤの一部と異なると、前記受信したＰＰＤＵをｉｎｔｅｒ－ＢＳＳＰＰＤＵに分類できる。また、受信したＰＰＤＵのＰａｒｔｉａｌＡＩＤフィールドがＢＳＳＩＤの一部を示す場合に、受信したＰａｒｔｉａｌＡＩＤフィールド値が、受信したＳＴＡに該当するＢＳＳＩＤの一部と同一であれば、前記受信したＰＰＤＵをｉｎｔｒａ－ＢＳＳＰＰＤＵに分類できる。また、このとき、ＢＳＳＩＤの一部はＢＳＳＩＤの９ＭＳＢｓであることが可能である。また、ＰａｒｔｉａｌＡＩＤフィールド値は、ＴＸＶＥＣＴＯＲパラメータＰＡＲＴＩＡＬ＿ＡＩＤ又はＲＸＶＥＣＴＯＲパラメータＰＡＲＴＩＡＬ＿ＡＩＤに含まれてよい。また、ＧｒｏｕｐＩＤフィールド値は、ＴＸＶＥＣＴＯＲパラメータＧＲＯＵＰ＿ＩＤ又はＲＸＶＥＣＴＯＲパラメータＧＲＯＵＰ＿ＩＤに含まれてよい。

前記ＢＳＳ分類条件は、ＡＰが、既に設定された条件のＰＰＤＵを受信する条件を含んでよい。例えば、前記既に設定された条件のＰＰＤＵは、下りリンクＰＰＤＵを含んでよい。一実施例によれば、下りリンクＰＰＤＵは、ＶＨＴＭＵＰＰＤＵを含んでよい。また、下りリンクＰＰＤＵは、上りリンクか又は下りリンクかを指示するシグナリングが、既に設定された値に設定されたＰＰＤＵを含んでよい。上りリンクか又は下りリンクかを指示するシグナリングは、ＨＥＰＰＤＵのｓｉｇｎａｌｉｎｇフィールドに含まれてよい。又は、上りリンクか又は下りリンクかを指示するシグナリングはＵ－ＳＩＧに含まれてよい。Ｕ－ＳＩＧは、ＥＨＴＰＰＤＵ又はＥＨＴ標準以後のＰＰＤＵのプリアンブルに含まれてよい。

また、ｉｎｔｒａ－ＢＳＳＰＰＤＵ又はｉｎｔｅｒ－ＢＳＳＰＰＤＵに分類できない場合が存在し得る。例えば、前述したｉｎｔｒａ－ＢＳＳＰＰＤＵに分類する条件とｉｎｔｅｒ－ＢＳＳＰＰＤＵに分類する条件をいずれも満たせない場合に、ｉｎｔｒａ－ＢＳＳＰＰＤＵ又はｉｎｔｅｒ－ＢＳＳＰＰＤＵに分類できない。

また、ＢＳＳを分類するとき、複数の条件による分類結果が一致しないと、既に設定された条件によって最終結果を決定することが可能である。例えば、ＢＳＳｃｏｌｏｒに基づく条件による結果とＭＡＣａｄｄｒｅｓｓに基づく条件による結果とが一致しない場合に、ＭＡＣａｄｄｒｅｓｓに基づく条件による結果が優先するか、又はＭＡＣａｄｄｒｅｓｓに基づく条件による結果を最終結果として決定できる。又は、ｉｎｔｒａ－ＢＳＳＰＰＤＵに分類する条件とｉｎｔｅｒ－ＢＳＳＰＰＤＵに分類する条件を両方とも満たす場合に、ｉｎｔｒａ－ＢＳＳＰＰＤＵに分類できる。

本発明の一実施例によれば、ＳＴＡは、分類したＢＳＳに基づく動作を行うことができる。分類したＢＳＳに基づく動作は、ｉｎｔｒａ－ＰＰＤＵ節電（ｐｏｗｅｒｓａｖｅ）動作を含んでよい。ｉｎｔｒａ－ＰＰＤＵ節電動作は、受信したＰＰＤＵに基づく節電動作であってよい。既に設定された条件を満たす場合に、ｉｎｔｒａ－ＰＰＤＵ節電動作を行うことが可能である。前記既に設定された条件は、受信したＰＰＤＵをｉｎｔｒａ－ＢＳＳＰＰＤＵに分類する条件を含んでよい。また、前記既に設定された条件は、受信したＰＰＤＵの意図した受信者（ｉｎｔｅｎｄｅｄｒｅｃｅｉｖｅｒ）が前記ＰＰＤＵを受信したＳＴＡでない条件を含んでよい。例えば、ＰＰＤＵに含まれたＩＤ又はａｄｄｒｅｓｓが前記ＰＰＤＵを受信したＳＴＡに該当しない場合に、前記ＰＰＤＵの意図した受信者は、前記ＰＰＤＵを受信したＳＴＡでなくてよい。ＩＤは、ＰＰＤＵのプリアンブルに含まれてよい。例えば、ＩＤは、ＰＰＤＵのプリアンブルに含まれたＳＴＡ＿ＩＤであってよい。また、ＳＴＡ＿ＩＤは、ＨＥＭＵＰＰＤＵ又はＥＨＴＰＰＤＵに含まれてよい。また、ａｄｄｅｒｅｓｓは、前述したＭＡＣａｄｄｒｅｓｓであってよい。また、受信したＰＰＤＵに含まれた上りリンクか又は下りリンクかを指示するシグナリングが上りリンクを指示する場合に、前記ＰＰＤＵの意図した受信者は、前記ＰＰＤＵを受信したＳＴＡでなくてよい。また、受信したＰＰＤＵの設定が、前記ＰＰＤＵを受信したＳＴＡが支援しないものに設定された場合に、前記ＰＰＤＵの意図した受信者は、前記ＰＰＤＵを受信したＳＴＡでなくてよい。受信したＰＰＤＵの設定は、ＰＰＤＵのＭＣＳ、空間ストリーム（ｓｐａｔｉａｌｓｔｒｅａｍ）個数、チャネル幅（ｃｈａｎｎｅｌｗｉｄｔｈ）などを含んでよい。また、受信したＰＰＤＵの設定を、前記ＰＰＤＵを受信したＳＴＡが支援しない場合に、ＰＨＹ－ＲＸＥＮＤ．ｉｎｄｉｃａｔｉｏｎ（ＵｎｓｕｐｐｏｒｔｅｄＲａｔｅ）ｐｒｉｍｉｔｉｖｅが受信されてよい。また、受信したＰＰＤＵが既に設定されたフォーマットである場合に、前記ＰＰＤＵの意図した受信者は、前記ＰＰＤＵを受信したＳＴＡでなくてよい。前記既に設定されたフォーマットはＴＢＰＰＤＵを含んでよい。ＴＢＰＰＤＵは、ＨＥＴＢＰＰＤＵ、ＥＨＴＴＢＰＰＤＵを含んでよい。また、ＴＢＰＰＤＵは、トリガーするフレームによる応答として送信されるＰＰＤＵであってよい。トリガーするフレームは、トリガーフレームを含んでよい。トリガーするフレームは、トリガーする情報が含まれたフレームを含んでよい。トリガーする情報は、ＭＡＣｈｅａｄｅｒ、例えば、Ａ－ｃｏｎｔｒｏｌフィールドに含まれてよい。また、トリガーする情報又はトリガーフレームに含まれた情報は、応答するＰＰＤＵの長さ、応答時に用いるＲＵ、応答時に用いるＰＨＹｃｏｎｆｉｇｕｒａｔｉｏｎ、ＭＡＣｃｏｎｆｉｇｕｒａｔｉｏｎなどを含んでよい。ｉｎｔｒａ－ＰＰＤＵ節電動作は、受信したＰＰＤＵの終わりまでｄｏｚｅ状態に入り得る動作であってよい。さらに他の実施例として、ＳＴＡが受信したＰＰＤＵ又はフレームの意図した受信者が前記ＳＴＡでないと判断された場合に、ＰＰＤＵ又はフレームの受信又はデコーディングを中断できる。

分類したＢＳＳに基づく動作は、ＮＡＶを設定（又は、アップデート）する動作を含んでよい。一実施例によれば、ＳＴＡが一つ以上のＮＡＶを運用することが可能である。また、ＳＴＡがＰＰＤＵ又はフレームを受信した場合に、受信したＰＰＤＵ又は受信したフレームに基づいて分類したＢＳＳに該当するＮＡＶを設定することが可能である。例えばｉｎｔｒａ－ＢＳＳＮＡＶは、ｉｎｔｒａ－ＢＳＳＰＰＤＵに該当するＮＡＶであってよい。また、ｂａｓｉｃＮＡＶは、ｉｎｔｒａ－ＢＳＳＰＰＤＵでないＰＰＤＵに該当するＮＡＶであってよい。又は、ｂａｓｉｃＮＡＶは、ｉｎｔｅｒ－ＢＳＳＰＰＤＵに該当するＮＡＶであってよい。また、受信したＰＰＤＵ又は受信したフレームに基づいてＮＡＶを設定する時に、受信したＰＰＤＵ又は受信したフレームに含まれたｄｕｒａｔｉｏｎ情報を用いることが可能である。前記ｄｕｒａｔｉｏｎ情報は、ＴＸＯＰを含んでよい。ＴＸＯＰは、ＴＸＯＰフィールドに含まれた値を意味できる。ＴＸＯＰフィールドは、ＰＰＤＵのプリアンブルに含まれてよい。例えば、ＴＸＯＰフィールドは、ＨＥＰＰＤＵのＨＥ－ＳＩＧ－Ａフィールドに含まれてよい。又は、ＴＸＯＰフィールドは、ＥＨＴＰＰＤＵ又はＥＨＴ以後標準のＰＰＤＵのＵ－ＳＩＧフィールドに含まれてよい。また、前記ｄｕｒａｔｉｏｎ情報は、ＭＡＣｈｅａｄｅｒに含まれてよい。例えば、前記ｄｕｒａｔｉｏｎ情報は、ＭＡＣｈｅａｄｅｒに含まれたＤｕｒａｔｉｏｎ／ＩＤフィールドに含まれてよい。

分類したＢＳＳに基づく動作は、空間再利用（ｓｐａｔｉａｌｒｅｕｓｅ）動作を含んでよい。また、分類したＢＳＳに基づく動作は、チャネル接続動作を含んでよい。空間再利用動作はチャネル接続動作であってよい。ＳＴＡがＰＰＤＵ又はフレームを受信した時に、既に設定された条件を満たすと、空間再利用動作を行うことが可能である。既に設定された条件は、受信したＰＰＤＵ又は受信したフレームがｉｎｔｅｒ－ＢＳＳに該当する条件を含んでよい。また、既に設定された条件は、受信したＰＰＤＵ又は受信したフレームの信号強度（ｓｉｇｎａｌｓｔｒｅｎｇｔｈ）が閾値（ｔｈｒｅｓｈｏｌｄ）よりも小さい条件を含んでよい。例えば、閾値は可変的であってよい。また、閾値は、ＯＢＳＳＰＤベースの空間再利用（ＯＢＳＳＰＤ－ｂａｓｅｄＳｐａｔｉａｌｒｅｕｓｅ）動作のための閾値であってよい。また、閾値は、ＣＣＡ閾値以上の値であってよい。また、閾値は、送信しようとする電力（ｐｏｗｅｒ）に基づく値であってよい。空間再利用動作は、ＰＰＤＵを送信する動作を含んでよい。また、空間再利用動作は、ＰＨＹをリセットする動作を含んでよい。例えば、ＰＨＹをリセットする動作は、ＰＨＹ－ＣＣＡＲＥＳＥＴ．ｒｅｑｕｅｓｔｐｒｉｍｉｔｉｖｅを発行（ｉｓｓｕｅ）する動作であってよい。また、空間再利用動作は、受信したＰＰＤＵ又は受信したフレームに基づいてＮＡＶを設定しない動作を含んでよい。仮に、ＳＴＡが空間再利用動作を行う場合に、受信したＰＰＤＵ又は受信したフレームが送信又は受信される間に前記ＳＴＡがＰＰＤＵを送信することが可能である。

図１３を参照すると、ＢＳＳＡとＢＳＳＢが存在してよく、ＢＳＳＡとＢＳＳＢは互いに異なるＢＳＳであってよい。また、ＢＳＳＡとＢＳＳＢは互いにｉｎｔｅｒ－ＢＳＳに該当してよい。すなわち、ＢＳＳＡにアソシエーションされたＳＴＡがＢＳＳＢで送信したＰＰＤＵ又はフレームは、ｉｎｔｅｒ－ＢＳＳＰＰＤＵ又はｉｎｔｅｒ－ＢＳＳフレームに分類されてよい。また、ＢＳＳＡに属する（又は、ＢＳＳＡを運営するＡＰとアソシエーションされた）ＳＴＡ１、ＳＴＡ２が存在してよい。ＢＳＳＢに属する（又は、ＢＳＳＢを運営するＡＰとアソシエーションされた）ＳＴＡ３、ＳＴＡ４が存在してよい。図１３を参照すると、ＳＴＡ１がＰＰＤＵを送信できる。また、ＳＴＡ１の送信したＰＰＤＵはＢＳＳに対する情報を含んでよい。例えば、ＢＳＳに対する情報は、前述したＢＳＳを分類するための情報であってよい。また、ＳＴＡ１の送信したＰＰＤＵは、Ｄｕｒａｔｉｏｎ情報を含んでよい。

ＳＴＡ２は、ＳＴＡ１の送信したＰＰＤＵを受信し、このＰＰＤＵに対するＢＳＳを分類できる。また、ＳＴＡ２とＳＴＡ１はＢＳＳＡに属しているので、ＳＴＡ２の受信したＰＰＤＵはｉｎｔｒａ－ＢＳＳＰＰＤＵに分類されてよい。また、ＳＴＡ２の受信したＰＰＤＵはＵＬＰＰＤＵであるか、ＳＴＡが意図した受信者でないＰＰＤＵであってよい。したがって、前述した実施例によってＳＴＡ２はｉｎｔｒａ－ＰＰＤＵ節電を行うことが可能である。図１３を参照すると、ＳＴＡ２は、受信したＰＰＤＵ終わりの時間までｄｏｚｅ状態に入り得る。また、ＳＴＡ２は、受信したＰＰＤＵに含まれたＤｕｒａｔｉｏｎ情報に基づいてＮＡＶを設定することができる。ＳＴＡ２は、受信したＰＰＤＵをｉｎｔｒａ－ＢＳＳＰＰＤＵに分類したので、ｉｎｔｒａ－ＢＳＳＮＡＶを設定することが可能である。

ＳＴＡ３は、ＳＴＡ１の送信したＰＰＤＵを受信し、このＰＰＤＵに対するＢＳＳを分類できる。また、ＳＴＡ３とＳＴＡ１はそれぞれＢＳＳＢ、ＢＳＳＡに属しているので、ＳＴＡ３の受信したＰＰＤＵはｉｎｔｅｒ－ＢＳＳＰＰＤＵに分類されてよい。また、ＳＴＡ３は、受信したＰＰＤＵに含まれたＤｕｒａｔｉｏｎ情報に基づいてＮＡＶを設定できる。ＳＴＡ３は、受信したＰＰＤＵをｉｎｔｅｒ－ＢＳＳＰＰＤＵに分類したので、ｂａｓｉｃＮＡＶを設定することが可能である。

ＳＴＡ４は、ＳＴＡ１の送信したＰＰＤＵを受信し、このＰＰＤＵに対するＢＳＳを分類できる。また、ＳＴＡ４とＳＴＡ１はそれぞれＢＳＳＢ、ＢＳＳＡに属しているので、ＳＴＡ４の受信したＰＰＤＵはｉｎｔｅｒ－ＢＳＳＰＰＤＵに分類されてよい。また、ＳＴＡ４の受信したＰＰＤＵの信号強度が閾値よりも小さくてよい。したがって、ＳＴＡ４の受信したＰＰＤＵがｉｎｔｅｒ－ＢＳＳＰＰＤＵに分類されたし、ＳＴＡ４の受信したＰＰＤＵの信号強度が閾値よりも小さいので、ＳＴＡ４は空間再利用（ｓｐａｔｉａｌｒｅｕｓｅ）動作を行うことが可能である。したがって、ＳＴＡ４は、チャネル接続、バックオフ手順（ｂａｃｋｏｆｆｐｒｏｃｅｄｕｒｅ）を行うことができ、送信を始めることができる。例えば、ＳＴＡ１の送信したＰＰＤＵが終わらない時点に、ＳＴＡ４が送信を始めることが可能である。

図１４には、本発明の実施例に係るＳＴＡの機能を示す。

本発明の実施例によれば、ある無線ＬＡＮ標準に従うＳＴＡは、以前の無線ＬＡＮ標準の機能を含んでよい。これは、下位互換性のためのものである。例えば、特定の無線ＬＡＮ標準を支援するＳＴＡは、以前の世代の無線ＬＡＮ標準機能を支援し、新しい機能もさらに支援できる。例えば、ＨＴＳＴＡは、ＯＦＤＭＰＨＹＳＴＡの基本機能を支援できる。したがって、ＨＴＳＴＡは、ＯＦＤＭＰＨＹＳＴＡに分類されてよい。また、ＨＴＳＴＡは、ＯＦＤＭＰＨＹＳＴＡの機能の他、ＯＦＤＭＰＨＹＳＴＡが支援しない追加機能も支援できる。ＶＨＴＳＴＡは、ＨＴＳＴＡの基本機能を支援する他、ＨＴＳＴＡが支援しない機能も支援できる。ＶＨＴＳＴＡはＨＴＳＴＡに分類されてよい。また、ＨＥＳＴＡは、ＶＨＴＳＴＡの基本機能を支援する他、ＶＨＴＳＴＡが支援しない機能も支援できる。ＨＥＳＴＡはＶＨＴＳＴＡに分類されてよい。また、ＥＨＴＳＴＡはＨＥＳＴＡでもあり得る。また、ＥＨＴＳＴＡは、ＨＥＳＴＡの基本機能を支援する他、ＨＥＳＴＡが支援しない機能も支援できる。また、ＥＨＴＳＴＡはＨＥＳＴＡに分類されてよい。また、ＥＨＴ標準以降の無線ＬＡＮ標準が新しく定義されてよい。本発明において、ＥＨＴ標準以降の標準をＮＥＸＴ標準と呼び、ＮＥＸＴ標準に従うＳＴＡをＮＥＸＴＳＴＡと呼ぶ。ＮＥＸＴＳＴＡは、ＥＨＴＳＴＡの基本機能を支援する他、ＥＨＴＳＴＡが支援しない機能も支援できる。ＮＥＸＴＳＴＡはＥＨＴＳＴＡに分類されてよい。

図１４は、各無線ＬＡＮ標準を支援するＳＴＡ間の関係を示すダイヤグラムである。図１４を参照すると、ＥＨＴＳＴＡであれば、ＨＥＳＴＡで、ＶＨＴＳＴＡで、ＨＴＳＴＡで、ＯＦＤＭＰＨＹＳＴＡであってよい。また、ＮＥＸＴＳＴＡであれば、ＥＨＴＳＴＡで、ＨＥＳＴＡで、ＶＨＴＳＴＡで、ＨＴＳＴＡで、ＯＦＤＭＰＨＹＳＴＡであってよい。

図１５には、本発明の一実施例に係る上りリンク（Ｕｐｌｉｎｋ：ＵＬ）多重ユーザ（ｍｕｌｔｉｕｓｅｒ：ＭＵ）動作を示す。

本発明の一実施例において、アクセスポイントは、ＭＵ（ｍｕｌｔｉ－ｕｓｅｒ）送信を誘発（ｓｏｌｉｃｉｔ）するフレームを送信できる。このようなフレームをトリガリングフレームと呼ぶ。このとき、トリガリングフレームを受信した一つ以上のＳＴＡは、トリガリングフレームに基づいて上り送信を行うことができる。具体的には、トリガリングフレームを受信した一つ以上のＳＴＡは、フレームに対する応答フレームを送信できる。このとき、トリガリングフレームを含むＰＰＤＵと上り送信に用いられるＰＰＤＵとの間隔（ｉｎｔｅｒ－ｓｐａｃｅ）は、ＳＩＦＳであってよい。具体的には、複数のＳＴＡはトリガリングフレームを受信し、同時に（ｓｉｍｕｌｔａｎｅｏｕｓ）即刻の（ｉｍｍｅｄｉａｔｅ）応答を送信できる。即刻の応答は、先に受信したＰＰＤＵと応答を含むＰＰＤＵとの間の間隔がＳＩＦＳであることを示す。

トリガリングフレームは制御フレームの一種で、トリガー情報を含むトリガーフレームであってよい。また、トリガリングフレームは、トリガー情報をＭＡＣヘッダーに含むフレームであってよい。このとき、トリガー情報は、ＭＡＣヘッダーのＨＴＣｏｎｔｒｏｌフィールド、Ｃｏｎｔｒｏｌサブフィールド、又はＡ－Ｃｏｎｔｒｏｌサブフィールドに含まれるＴＲＳ（ｔｒｉｇｇｅｒｅｄｒｅｓｐｏｎｓｅｓｃｈｅｄｕｌｉｎｇ）であってよい。また、トリガー情報は、ＴＢＰＰＤＵの送信を誘発する情報であってよい。

ＴＢＰＰＤＵは、トリガリングフレームに対する応答フレームを含むＰＰＤＵフォーマットである。ＴＢＰＰＤＵは、ＨＥＴＢＰＰＤＵ及びＥＨＴＴＢＰＰＤＵを含んでよい。また、ＴＢＰＰＤＵは、ＮＥＸＴ無線ＬＡＮ標準で定義するＮＥＸＴＴＢＰＰＤＵを含んでよい。ＨＥＴＢＰＰＤＵは、Ｌ－ＳＴＦ、Ｌ－ＬＴＦ、Ｌ－ＳＩＧ、ＲＬ－ＳＩＧ、ＨＥ－ＳＩＧ－Ａ、ＨＥ－ＳＴＦ、ＨＥ－ＬＴＦを順に含むプリアンブルを含み、プリアンブルに続いてデータ、パケットエクステンション（ｐａｃｋｅｔｅｘｔｅｎｓｉｏｎ，ＰＥ）を含んでよい。また、ＥＨＴＴＢＰＰＤＵ、ＮＥＸＴＴＢＰＰＤＵは、Ｌ－ＳＴＦ、Ｌ－ＬＴＦ、Ｌ－ＳＩＧ、ＲＬ－ＳＩＧ、Ｕ－ＳＩＧ、（ＥＨＴ－／ＮＥＸＴ－）ＳＴＦ、（ＥＨＴ－／ＮＥＸＴ－）ＬＴＦを順に含むプリアンブルを含み、プリアンブルに続いてデータ、パケットエクステンション（ｐａｃｋｅｔｅｘｔｅｎｓｉｏｎ，ＰＥ）を含んでよい。

トリガリングフレームは、ＴＢＰＰＤＵ送信に必要な情報を含んでよい。ＭＡＣフレームのＴｙｐｅサブフィールド（Ｂ３Ｂ２）の値が０１_ｂであり、サブタイプサブフィールド（Ｂ７Ｂ６Ｂ５Ｂ４）の値が００１０_ｂである場合に、ＭＡＣフレームトリガーフレームであることを示し得る。

トリガーフレームに応答する複数のＳＴＡが互いに異なるフォーマットのＴＢＰＰＤＵを送信する場合に、アクセスポイントにとってＴＢＰＰＤＵが受信し難いことがある。また、複数のＳＴＡが送信するＰＰＤＵのプリアンブルが互いに異なる場合に、アクセスポイントにとってＴＢＰＰＤＵが受信し難いことがある。特に、互いに異なるフォーマットのＴＢＰＰＤＵが送信されるＲＵがオーバーラップする場合に、アクセスポイントにとってＴＢＰＰＤＵが受信し難いことがある。したがって、一つのトリガリングフレームに対する応答を送信する複数のＳＴＡは、同一のフォーマットのＴＢＰＰＤＵを用いることができる。また、一つのトリガリングフレームに対する応答を送信する複数のＳＴＡが送信するＴＢＰＰＤＵのプリアンブル情報は同一であってよい。

図１４で説明しているように、ＨＥＳＴＡは、ＨＥＴＢＰＰＤＵを送信できる。また、ＥＨＴＳＴＡは、ＥＨＴＴＢＰＰＤＵ又はＨＥＴＢＰＰＤＵを送信できる。また、ＮＥＸＴＳＴＡは、ＮＥＸＴＴＢＰＰＤＵ、ＥＨＴＴＢＰＰＤＵ又はＨＥＴＢＰＰＤＵを送信できる。

図１５の実施例において、ＡＰがＨＥＳＴＡ（ＨＥＳＴＡ）の送信とＥＨＴＳＴＡ（ＥＨＴＳＴＡ）の送信をスケジュールするトリガーフレームを送信する。このとき、トリガーフレームがトリガーフレームに対する応答のために送信されるＴＢＰＰＤＵのフォーマットについて指示しない場合に、ＨＥＳＴＡ（ＨＥＳＴＡ）とＥＨＴＳＴＡ（ＥＨＴＳＴＡ）又は互いに異なるＥＨＴＳＴＡ（ＥＨＴＳＴＡ）は、互いに異なるフォーマットのＴＢＰＰＤＵを送信することがある。このため、ＴＢＰＰＤＵの送信に失敗し、送信機会が浪費されることがある。説明の便宜のために、ＨＥ、ＥＨＴ、及びＮＥＸＴ標準で定義されたトリガーフレームをそれぞれ、ＨＥトリガーフレーム、ＥＨＴトリガーフレーム、及びＮＥＸＴトリガーフレームと呼ぶ。また、ＨＥ、ＥＨＴ、及びＮＥＸＴ標準で定義されたＴＲＳを、ＨＥＴＲＳ、ＥＨＴＴＲＳ、及びＮＥＸＴＴＲＳと呼ぶ。トリガーフレームのフォーマットについては図１６を用いて説明する。

図１６には、本発明の実施例に係るトリガーフレームのフォーマットと、トリガーフレームに含まれるサブフィールドを示す。

具体的には、図１６（ａ）は、トリガーフレームのフォーマットを示し、図１６（ｂ）は、トリガーフレームのＣｏｍｍｏｎＩｎｆｏフィールドを示し、図１６（ｃ）は、トリガーフレームのＵｓｅｒＩｎｆｏフィールドを示す。トリガーフレームのＭＡＣヘッダーは、ＦｒａｍｅＣｏｎｔｒｏｌフィールド、Ｄｕｒａｔｉｏｎフィールド、及びＡｄｄｒｅｓｓフィールドを含む。このとき、Ａｄｄｒｅｓｓフィールドは、ＲＡフィールド、ＴＡフィールドを含む。また、トリガーフレームは、ＣｏｍｍｏｎＩｎｆｏフィールドとＵｓｅｒＩｎｆｏＬｉｓｔフィールドを含む。ＣｏｍｍｏｎＩｎｆｏフィールドは、トリガーフレームがトリガーする全てのステーションのための情報を含む。また、ＵｓｅｒＩｎｆｏＬｉｓｔフィールドは、ＵｓｅｒＩｎｆｏフィールドを含んでよい。具体的な実施例において、特定タイプのトリガーフレームは、ＵｓｅｒＩｎｆｏＬｉｓｔフィールドを含まなくてよい。また、トリガーフレームは、ＰａｄｄｉｎｇフィールドとＦＣＳフィールドを含んでよい。Ｐａｄｄｉｎｇフィールドは、トリガーフレームを受信するＳＴＡが応答を準備するのにかかる時間を確保するためにｆｒａｍｅ長さを増やす役割を担うことができ、選択的に存在してよい。

ＣｏｍｍｏｎＩｎｆｏフィールドはＴｒｉｇｇｅｒＴｙｐｅサブフィールドを含んでよい。ＴｒｉｇｇｅｒＴｙｐｅサブフィールドは、トリガーフレームバリアント（ｖａｒｉａｎｔ）を識別（ｉｄｅｎｔｉｆｙ）する。トリガーフレームは、ＴｒｉｇｇｅｒＴｙｐｅサブフィールドの値でトリガーフレームのタイプを示すことができる。また、ＴｒｉｇｇｅｒＴｙｐｅサブフィールドによって、ＴｒｉｇｇｅｒＤｅｐｅｎｄｅｎｔＣｏｍｍｏｎＩｎｆｏサブフィールド、ＴｒｉｇｇｅｒＤｅｐｅｎｄｅｎｔＵｓｅｒＩｎｆｏサブフィールドに含まれる情報、及びＴｒｉｇｇｅｒＤｅｐｅｎｄｅｎｔＣｏｍｍｏｎＩｎｆｏサブフィールド、ＴｒｉｇｇｅｒＤｅｐｅｎｄｅｎｔＵｓｅｒＩｎｆｏサブフィールドの長さが決定されてよい。例えば、ＴｒｉｇｇｅｒＴｙｐｅサブフィールドをＣｏｍｍｏｎＩｎｆｏフィールドのＢ０からＢ３までのビットが示すことができる。

また、ＣｏｍｍｏｎＩｎｆｏフィールドはＵＬＬｅｎｇｔｈサブフィールドを含んでよい。ＵＬＬｅｎｇｔｈサブフィールドは、Ｔｒｉｇｇｅｒｆｒａｍｅに応答するＴＢＰＰＤＵの長さに関する情報を含んでよい。又は、ＵＬＬｅｎｇｔｈサブフィールドは、Ｔｒｉｇｇｅｒｆｒａｍｅに応答するｆｒａｍｅの長さに関する情報を含んでよい。また、ＵＬＬｅｎｇｔｈサブフィールドは、Ｔｒｉｇｇｅｒｆｒａｍｅに応答するＴＢＰＰＤＵのＬ－ＳＩＧのＬｅｎｇｔｈサブフィールドに含まれる値を指示することができる。したがって、ＴＢＰＰＤＵで応答するＳＴＡは、受信したＴｒｉｇｇｅｒｆｒａｍｅが含むＵＬＬｅｎｇｔｈサブフィールドの値に基づいてＴＢＰＰＤＵのＬ－ＳＩＧのＬｅｎｇｔｈサブフィールドを設定できる。より具体的には、ＴＢＰＰＤＵで応答するＳＴＡは、受信したＴｒｉｇｇｅｒｆｒａｍｅが含むＵＬＬｅｎｇｔｈサブフィールドの値でＴＢＰＰＤＵのＬ－ＳＩＧのＬｅｎｇｔｈサブフィールドを設定できる。例えば、ＵＬＬｅｎｇｔｈサブフィールドをＣｏｍｍｏｎＩｎｆｏｆｉｅｌｄのＢ４からＢ１５までのビットが示すことができる。

また、ＣｏｍｍｏｎＩｎｆｏフィールドはＵＬＢＷサブフィールドを含んでよい。ＵＬＢＷサブフィールドは、トリガーフレームに応答するＴＢＰＰＤＵのシグナリングフィールド、例えば、ＨＥ－ＳＩＧ－Ａフィールド又はＵ－ＳＩＧフィールドに含まれる帯域幅（ｂａｎｄｗｉｄｔｈ，ＢＷ）値を指示することができる。また、ＵＬＢＷサブフィールドは、Ｔｒｉｇｇｅｒｆｒａｍｅに応答するＴＢＰＰＤＵの最大帯域幅を示すことができる。

また、ＣｏｍｍｏｎＩｎｆｏフィールドは、トリガーフレームに応答するＴＢＰＰＤＵのシグナリングフィールド、例えば、ＨＥ－ＳＩＧ－Ａフィールド又はＵ－ＳＩＧフィールドに含まれる情報などを含んでよい。

ＵｓｅｒＩｎｆｏフィールドは、ＡＩＤ１２サブフィールドを含んでよい。ＡＩＤ１２サブフィールドは、ＡＩＤ１２サブフィールドを含むＵｓｅｒＩｎｆｏフィールドの意図した受信者又はＵｓｅｒＩｎｆｏフィールドの機能を指示する役割を担うことができる。したがって、ＡＩＤ１２サブフィールドは、ＡＩＤ１２サブフィールドを含むトリガーフレームの意図した受信者又はトリガーフレームの機能を指示する役割を担うことができる。例えば、ＡＩＤ１２サブフィールドの値が既に設定された値である場合に、ＵｓｅｒＩｎｆｏフィールドはＲＡ－ＲＵ（ｒａｎｄｏｍａｃｃｅｓｓｒｅｓｏｕｒｃｅｕｎｉｔ）を指示するものであることを示すことができる。より具体的には、ＡＩＤ１２サブフィールドの値が０である場合に、ＵｓｅｒＩｎｆｏフィールドは、連結された（ａｓｓｏｃｉａｔｅｄ）ＳＴＡのためのＲＡ－ＲＵを指示できる。また、ＡＩＤ１２サブフィールドの値が２０４５である場合に、ＵｓｅｒＩｎｆｏフィールドは、連結されていない（ｕｎａｓｓｏｃｉａｔｅｄ）ＳＴＡのためＲＡ－ＲＵを指示できる。また、ＡＩＤ１２サブフィールドの値が指示するＳＴＡＩＤ、例えば、ＡＩＤ（ａｓｓｏｃｉａｔｉｏｎＩＤ）に該当するＳＴＡＡＩＤ１２サブフィールドを含むＵｓｅｒＩｎｆｏフィールド又はＡＩＤ１２サブフィールドを含むトリガーフレームが応答をトリガーすることを示すことができる。例えば、ＡＩＤ１２サブフィールドは、ＡＩＤ又はＡＩＤの１２ＬＳＢｓを示すことができる。ＡＩＤ１２サブフィールドの値に該当するＳＴＡは、トリガーフレームにＴＢＰＰＤＵで応答することができる。また、ＡＩＤ１２サブフィールドの値は１から２００７までの範囲（１と２００７を含む。）であってよい。また、ＡＩＤ１２サブフィールドが既に設定された値、例えば２０４６である場合に、該当するＲＵはいかなるＳＴＡにも割り当てられていないことを指示できる。また、ＡＩＤ１２サブフィールドが既に設定された値、例えば４０９５である場合に、トリガーフレームのパディングが始まることを指示できる。

また、ＡＩＤ１２サブフィールドを含むＵｓｅｒＩｎｆｏフィールドの情報は、ＡＩＤ１２サブフィールドが指示するＳＴＡに該当する情報であってよい。例えば、ＲＵＡｌｌｏｃａｔｉｏｎサブフィールドは、ＲＵのサイズと位置を指示できる。このとき、ＡＩＤ１２サブフィールドを含むＵｓｅｒＩｎｆｏフィールドのＲＵＡｌｌｏｃａｔｉｏｎサブフィールドの値は、前記ＡＩＤ１２サブフィールドが指示するＳＴＡに該当する情報であってよい。また、ＵｓｅｒＩｎｆｏフィールドは、ＵｓｅｒＩｎｆｏフィールドを含むトリガーフレームの応答に用いられるコーディング方法（ＵＬＦＥＣＣｏｄｉｎｇＴｙｐｅ）、モジュレーション方法（ＵＬＨＥ－ＭＣＳ、ＵＬＤＣＭ）、送信電力（ＵＬＴａｒｇｅｔＲＳＳＩ）を指示できる。

前述したように、トリガーフレームに対する応答として同時に送信されるＴＢＰＰＤＵがいかなるＰＰＤＵのフォーマットで送信されるかによって問題になり得る。これに関連したトリガリングフレーム送信方法については図１７を用いて説明する。

図１７には、本発明の実施例によってトリガーフレームのＡＩＤ１２サブフィールドの値が指示する情報を示す。

本発明の実施例に係るＥＨＴＳＴＡは、ＨＥＴＢＰＰＤＵ、ＥＨＴＴＢＰＰＤＵを選択的に送信できる。また、ＮＥＸＴＳＴＡは、ＨＥＴＢＰＰＤＵ、ＥＨＴＴＢＰＰＤＵ、ＮＥＸＴＴＢＰＰＤＵを選択的に送信できる。これにより、一つのフレーム又は一つのＰＰＤＵで複数の無線ＬＡＮ標準のＳＴＡをスケジュールすることができる。これにより、送信媒体の使用効率を高めることができる。例えば、ＥＨＴ標準を支援しないＨＥＳＴＡとＥＨＴＳＴＡが一つのフレームでＨＥＴＢＰＰＤＵで応答するようにし得る。

また、ＴＢＰＰＤＵフォーマットを選択するための情報が、トリガーフレーム又はＴＲＳ又はトリガーフレームを含むＰＰＤＵ又はＴＲＳを含むＰＰＤＵに含まれてよい。

本発明の実施例によれば、応答するＴＢＰＰＤＵｆｏｒｍａｔに関する情報がＭＡＣｌｅｖｅｌに存在し得る。本発明の実施例によれば、トリガーフレームは、ＨＥトリガーフレーム、ＥＨＴトリガーフレーム及びＮＥＸＴトリガーフレームに区別されてよい。また、ＨＥトリガーフレーム、ＥＨＴトリガーフレーム、ＮＥＸＴトリガーフレームでトリガーされた応答は、それぞれ、ＨＥＴＢＰＰＤＵ、ＥＨＴＴＢＰＰＤＵ、ＮＥＸＴＴＢＰＰＤＵで応答できる。

また、ＨＥトリガーフレーム、ＥＨＴトリガーフレーム、ＮＥＸＴトリガーフレームを区別することは、トリガーフレームに応答するＴＢＰＰＤＵフォーマットをそれぞれ、ＨＥＴＢＰＰＤＵ、ＥＨＴＴＢＰＰＤＵ、ＮＥＸＴＴＢＰＰＤＵに区別するというのと同じ意味であってよい。すなわち、トリガーフレームのフォーマットによってそれに対するＴＢＰＰＤＵのフォーマットも変わってよく、次世代トリガーフレームは以前の世代ＴＢＰＰＤＵの送信も共に指示できる。すなわち、ＥＨＴトリガーフレームは、ＨＥＴＢＰＰＤＵとＥＨＴＴＢＰＰＤＵの送信を同時に指示できる。しかし、ＨＥトリガーフレームはＥＨＴＴＢＰＰＤＵの送信を指示することはできない。

具体的な実施例において、トリガーフレームが含むＭＡＣヘッダーのＦｒａｍｅＣｏｎｔｒｏｌフィールドによって、トリガーフレームがＨＥトリガーフレーム、ＥＨＴトリガーフレーム及びＮＥＸＴトリガーフレームのうちどのトリガーフレームに該当するかが決定されてよい。例えば、トリガーフレームが含むＭＡＣヘッダーのＦｒａｍｅＣｏｎｔｒｏｌフィールドのＴｙｐｅサブフィールド、Ｓｕｂｔｙｐｅサブフィールド又はＣｏｎｔｒｏｌＦｒａｍｅＥｘｔｅｎｓｉｏｎサブフィールドのうち少なくともいずれか一つによって、トリガーフレームがＨＥトリガーフレーム、ＥＨＴトリガーフレーム及びＮＥＸＴトリガーフレームのうちどのトリガーフレームに該当するかが決定されてよい。例えば、トリガーフレームが含むＭＡＣヘッダーのＦｒａｍｅＣｏｎｔｒｏｌフィールドのＴｙｐｅサブフィールド、Ｓｕｂｔｙｐｅサブフィールド又はＣｏｎｔｒｏｌＦｒａｍｅＥｘｔｅｎｓｉｏｎサブフィールドが第１値である場合に、トリガーフレームはＨＥトリガーフレームに分類されてよい。また、トリガーフレームが含むＭＡＣヘッダーのＦｒａｍｅＣｏｎｔｒｏｌフィールドのＴｙｐｅサブフィールド、Ｓｕｂｔｙｐｅサブフィールド又はＣｏｎｔｒｏｌＦｒａｍｅＥｘｔｅｎｓｉｏｎサブフィールドが第２値である場合に、トリガーフレームはＥＨＴトリガーフレームに分類されてよい。また、トリガーフレームが含むＭＡＣヘッダーのＦｒａｍｅＣｏｎｔｒｏｌフィールドのＴｙｐｅサブフィールド、Ｓｕｂｔｙｐｅサブフィールド又はＣｏｎｔｒｏｌＦｒａｍｅＥｘｔｅｎｓｉｏｎサブフィールドが第３値である場合に、トリガーフレームはＮＥＸＴトリガーフレームに分類されてよい。ＭＡＣヘッダーのＦｒａｍｅＣｏｎｔｒｏｌフィールドのＴｙｐｅサブフィールドの値が０１_ｂであり、サブタイプサブフィールドの値が００１０_ｂである場合に、トリガーフレームはＨＥトリガーフレームに分類されてよい。Ｔｙｐｅサブフィールド、Ｓｕｂｔｙｐｅサブフィールド及びＣｏｎｔｒｏｌＦｒａｍｅＥｘｔｅｎｓｉｏｎサブフィールドのそれぞれが２ビット、４ビット及び４ビットに限定される。このため、このような実施例は、限られたビットフィールドの値で将来に利用可能なタイプを制限するという短所がある。

さらに他の具体的な実施例において、トリガーフレームが含むＣｏｍｍｏｎＩｎｆｏフィールドによって、トリガーフレームがＨＥトリガーフレーム、ＥＨＴトリガーフレーム及びＮＥＸＴトリガーフレームのうちどのトリガーフレームに該当するかが決定されてよい。例えば、トリガーフレームのＣｏｍｍｏｎＩｎｆｏフィールドのＴｒｉｇｇｅｒＴｙｐｅサブフィールドの値が第１値である場合に、トリガーフレームはＨＥトリガーフレームに分類されてよい。トリガーフレームのＣｏｍｍｏｎＩｎｆｏフィールドのＴｒｉｇｇｅｒＴｙｐｅサブフィールドの値が第２値である場合に、トリガーフレームはＥＨＴトリガーフレームに分類されてよい。トリガーフレームのＣｏｍｍｏｎＩｎｆｏフィールドのＴｒｉｇｇｅｒＴｙｐｅサブフィールドの値が第３値である場合に、トリガーフレームはＮＥＸＴトリガーフレームに分類されてよい。具体的には、トリガーフレームのＣｏｍｍｏｎＩｎｆｏフィールドのＴｒｉｇｇｅｒＴｙｐｅサブフィールドの値が０～７である場合に、トリガーフレームはＨＥトリガーフレームに分類されてよい。また、トリガーフレームのＣｏｍｍｏｎＩｎｆｏフィールドのＴｒｉｇｇｅｒＴｙｐｅサブフィールドの値が０～７でない場合、トリガーフレームはＥＨＴトリガーフレーム又はＮＥＸＴトリガーフレームに分類されてよい。ＴｒｉｇｇｅｒＴｙｐｅサブフィールドのビット数が限定されているため、このような実施例は、限られたビットフィールドの値で将来に利用可能なトリガータイプを制限するという短所がある。

さらに他の具体的な実施例において、トリガーフレームが含むＵＬＬｅｎｇｔｈフィールドによって、トリガーフレームがＨＥトリガーフレーム、ＥＨＴトリガーフレーム及びＮＥＸＴトリガーフレームのうちどのトリガーフレームに該当するかが決定されてよい。例えば、トリガーフレームのＵＬＬｅｎｇｔｈフィールドの値を３で割った余りの値が第１値である場合に、トリガーフレームはＨＥトリガーフレームに分類されてよい。トリガーフレームのＵＬＬｅｎｇｔｈフィールドの値を３で割った余りの値が第２値である場合に、トリガーフレームはＥＨＴトリガーフレームに分類されてよい。トリガーフレームのＵＬＬｅｎｇｔｈフィールドの値を３で割った余りの値が第３値である場合に、トリガーフレームはＮＥＸＴトリガーフレームに分類されてよい。トリガーフレームのＵＬＬｅｎｇｔｈフィールドの値を３で割った余りの値が０でない場合に、トリガーフレームはＨＥトリガーフレームに分類されてよい。トリガーフレームのＵＬＬｅｎｇｔｈフィールドの値を３で割った余りの値が１である場合に、トリガーフレームはＨＥトリガーフレームに分類されてよい。トリガーフレームのＵＬＬｅｎｇｔｈフィールドの値を３で割った余りの値が０である場合に、トリガーフレームはＥＨＴトリガーフレーム又はＮＥＸＴトリガーフレームに分類されてよい。また、トリガーフレームのＵＬＬｅｎｇｔｈフィールドの値の他にも、トリガーフレームのＦｏｒｍａｔＩｄｅｎｔｉｆｉｅｒ、ＰＨＹＩｄｅｎｔｉｆｉｅｒ及びＴＢＰＰＤＵフォーマットシグナリングのうち少なくとも一つによって、トリガーフレームがＨＥトリガーフレーム、ＥＨＴトリガーフレーム及びＮＥＸＴトリガーフレームのうちどのトリガーフレームに該当するかが決定されてよい。

さらに他の具体的な実施例において、トリガーフレームが含むＵｓｅｒＩｎｆｏフィールドによって、トリガーフレームがＨＥトリガーフレーム、ＥＨＴトリガーフレーム及びＮＥＸＴトリガーフレームのうちどのトリガーフレームに該当するかが決定されてよい。具体的には、トリガーフレームのＵｓｅｒＩｎｆｏフィールドのＡＩＤ１２サブフィールドの値によってトリガーフレームがＨＥトリガーフレーム、ＥＨＴトリガーフレーム及びＮＥＸＴトリガーフレームのうちどのトリガーフレームに該当するかが決定されてよい。例えば、トリガーフレームのＵｓｅｒＩｎｆｏフィールドのＡＩＤ１２サブフィールドの値があらかじめ指定された値であるかによって、トリガーフレームがＨＥトリガーフレーム、ＥＨＴトリガーフレーム及びＮＥＸＴトリガーフレームのうちどのトリガーフレームに該当するかが決定されてよい。このとき、トリガーフレームのタイプを示すＡＩＤ１２サブフィールドを含むＵｓｅｒＩｎｆｏフィールドは、ＵｓｅｒＩｎｆｏフィールドリストにおいて最初のＵｓｅｒＩｎｆｏフィールドであってよい。トリガーフレームのタイプを示すＡＩＤ１２サブフィールドを含むＵｓｅｒＩｎｆｏフィールドは、ＳＴＡのＡＩＤを指示するＡＩＤ１２サブフィールドを含むＵｓｅｒＩｎｆｏフィールドよりも前に位置してよい。これにより、トリガーフレームを受信するＳＴＡがトリガーフレームのタイプを早期に判断することができる。さらに他の具体的な実施例において、トリガーフレームのタイプを示すＡＩＤ１２サブフィールドを含むＵｓｅｒＩｎｆｏフィールドは、ＵｓｅｒＩｎｆｏフィールドリストにおいてＨＥＳＴＡのためのＵｓｅｒＩｎｆｏフィールドの後に位置してよい。これにより、レガシーＳＴＡ、すなわちＨＥＳＴＡがＡＩＤ１２サブフィールドの値の意味を判断できないことから発生する問題を防止することができる。また、トリガーフレームのタイプを示すＡＩＤ１２サブフィールドを含むＵｓｅｒＩｎｆｏフィールドは、ＡＩＤ１２サブフィールド以外のサブフィールドを含まなくてよい。当該ＵｓｅｒＩｎｆｏフィールドはトリガーフレームタイプを指示するためのものであり、トリガーフレームタイプ以外の情報は必要としなくて済むことがあるためである。このような実施例において、ＵｓｅｒＩｎｆｏフィールドの長さは、ＡＩＤ１２サブフィールドの値によって変化する。図１７に、このような実施例が適用されるとき、ＡＩＤ１２サブフィールドの値が示す意味を示す。ＡＩＤ１２サブフィールドの値が第１値である場合に、ＡＩＤ１２サブフィールドは、ＡＩＤ１２サブフィールドを含むトリガーフレームがＥＨＴＴＢＰＰＤＵの送信をトリガーすることを示すことができる。第１値は２０４７であってよい。ＡＩＤ１２サブフィールドの値が第２値である場合に、ＡＩＤ１２サブフィールドは、ＡＩＤ１２サブフィールドを含むトリガーフレームがＮＥＸＴＴＢＰＰＤＵの送信をトリガーすることを示すことができる。第２値は２０４８であってよい。

さらに他の具体的な実施例において、ＳＴＡは、ＳＴＡをトリガーするＵｓｅｒＩｎｆｏフィールドの位置によって、トリガーフレームに対する応答として送信するＴＢＰＰＤＵのフォーマットを決定することができる。具体的には、ＳＴＡは、ＳＴＡをトリガーするＵｓｅｒＩｎｆｏフィールドが、あらかじめ指定された値を有するＡＩＤ１２サブフィールドを含むＵｓｅｒＩｎｆｏフィールドの後に位置するか否かに基づいて、トリガーフレームに対する応答として送信するＴＢＰＰＤＵのフォーマットを決定できる。このとき、ＳＴＡは、ＳＴＡをトリガーするＵｓｅｒＩｎｆｏフィールドが、第１値を有するＡＩＤ１２サブフィールドを含むＵｓｅｒＩｎｆｏフィールドの後に位置するか否かと第２値を有するＡＩＤ１２サブフィールドを含むＵｓｅｒＩｎｆｏフィールドの後に位置するか否かに基づいて、トリガーフレームに対する応答として送信するＴＢＰＰＤＵのフォーマットを決定できる。図１７の実施例において、ＳＴＡをトリガーするＵｓｅｒＩｎｆｏフィールドが、２０４７を有するＡＩＤ１２サブフィールドを含むＵｓｅｒＩｎｆｏフィールドの後に位置するとき、ＳＴＡは、トリガーフレームに対する応答としてＥＨＴＴＢＰＰＤＵを送信できる。また、ＳＴＡをトリガーするＵｓｅｒＩｎｆｏフィールドが２０４８を有するＡＩＤ１２サブフィールドを含むＵｓｅｒＩｎｆｏフィールドの後に位置するとき、ＳＴＡは、トリガーフレームに対する応答としてＮＥＸＴＴＢＰＰＤＵを送信できる。また、ＳＴＡをトリガーするＵｓｅｒＩｎｆｏフィールドが、２０４７を有するＡＩＤ１２サブフィールドを含むＵｓｅｒＩｎｆｏフィールドと２０４８を有するＡＩＤ１２サブフィールドを含むＵｓｅｒＩｎｆｏフィールドの後に位置するとき、ＳＴＡは、トリガーフレームに対する応答としてＮＥＸＴＴＢＰＰＤＵを送信できる。また、ＳＴＡをトリガーするＵｓｅｒＩｎｆｏフィールドが、２０４７を有するＡＩＤ１２サブフィールドを含むＵｓｅｒＩｎｆｏフィールドと２０４８を有するＡＩＤ１２サブフィールドを含むＵｓｅｒＩｎｆｏフィールドの前に位置するとき、ＳＴＡは、トリガーフレームに対する応答としてＨＥＴＢＰＰＤＵを送信できる。

ＡＩＤ１２サブフィールド以外のＵｓｅｒＩｎｆｏフィールドのサブフィールドによって、トリガーフレームがＨＥトリガーフレーム、ＥＨＴトリガーフレーム及びＮＥＸＴトリガーフレームのうちどのトリガーフレームに該当するかが決定されてよい。

トリガーフレームのＰａｄｄｉｎｇフィールドによって、トリガーフレームがＨＥトリガーフレーム、ＥＨＴトリガーフレーム及びＮＥＸＴトリガーフレームのうちどのトリガーフレームに該当するかが決定されてよい。例えば、トリガーフレームのＰａｄｄｉｎｇフィールドが、あらかじめ指定された値を含むか否かによって、ＨＥトリガーフレーム、ＥＨＴトリガーフレーム及びＮＥＸＴトリガーフレームのうちどのトリガーフレームに該当するかが決定されてよい。

また、これらの実施例は結合して適用されてよい。例えば、上記のトリガーフレームがＨＥトリガーフレーム、ＥＨＴトリガーフレーム及びＮＥＸＴトリガーフレームのいずれかであるかを判断するのに影響を与える要素が結合して判断されてよい。

また、これらの実施例は、ＴＲＳフィールドに対する応答として送信されるＴＢＰＰＤＵのフォーマットを決定するために用いられてよい。

図１８には、本発明の実施例に係るＵＬＭＵ動作を示す。

前述したように、トリガーフレームは、ＭＡＣフレームヘッダーにＴＲＳを含んでよい。ＴＲＳは、前述したように、ＨＴＣｏｎｔｒｏｌフィールドに含まれてよい。具体的には、ＨＴＣｏｎｔｒｏｌフィールドは、Ａ－Ｃｏｎｔｒｏｌフィールドを含むとき、ＴＲＳを含んでよい。また、ＴＲＳはＴＲＳＣｏｎｔｒｏｌフィールドに含まれてよい。Ａ－ＣｏｎｔｒｏｌフィールドにＣｏｎｔｒｏｌＬｉｓｔフィールドが連続して位置してよい。このとき、ＣｏｎｔｒｏｌＬｉｓｔフィールドがＴＲＳを含んでよい。

ＴＲＳを含むＭＡＣフレームの意図した受信者に該当するＳＴＡは、ＴＲＳに基づいてＰＰＤＵを送信できる。このとき、ＴＲＳは、ＳＴＡがＴＲＳを含むＭＡＣフレームに対する応答として送信するＰＰＤＵ又はフレームの長さに関する情報（ＵＬＤａｔａＳｙｍｂｏｌｓ）を含んでよい。ＴＲＳを含むＭＡＣフレームに対する応答送信の電力に関する情報（ＡＰＴｘＰｏｗｅｒ、ＵＬＴａｒｇｅｔＲＳＳＩ）、ＴＲＳを含むＭＡＣフレームに対する応答を送信する時に用いるＲＵの位置及びサイズ（ＲＵＡｌｌｏｃａｔｉｏｎ）、ＴＲＳを含むＭＡＣフレームに対する応答送信のモジュレーション方法に関する情報（ＵＬＨＥ－ＭＣＳ）を含んでよい。

ＴＲＳは、無線ＬＡＮ標準別に定義されてよい。このとき、ＴＲＳを含むＭＡＣフレームを受信したＳＴＡは、ＴＲＳのフォーマット、すなわち、どの無線ＬＡＮ標準で定義されたＴＲＳであるかによって、ＴＲＳに対する応答として送信されるＴＢＰＰＤＵのフォーマットを決定することができる。具体的には、ＳＴＡがＨＥＴＲＳを受信した場合に、ＳＴＡは、ＴＲＳに対する応答としてＨＥＴＢＰＰＤＵを送信できる。また、ＳＴＡがＥＨＴＴＲＳを受信した場合に、ＳＴＡは、ＴＲＳに対する応答としてＥＨＴＴＢＰＰＤＵを送信できる。また、ＳＴＡがＮＥＸＴＴＲＳを受信した場合に、ＳＴＡは、ＴＲＳに対する応答としてＮＥＸＴＴＢＰＰＤＵを送信できる。このとき、ＳＴＡは、Ａ－ＣｏｎｔｒｏｌサブフィールドのＣｏｎｔｒｏｌＩＤサブフィールドに基づいて、どの無線ＬＡＮ標準で定義されたＴＲＳであるかが判断できる。ＴＲＳは、ＨＥＴＲＳと、ＨＥＴＲＳでないＴＲＳとに区別されてよい。

ＴＲＳのフォーマットは、ＴＲＳが含まれるＨＴＣｏｎｔｒｏｌフィールドがＨＥバリアント（ｖａｒｉａｎｔ）なのか、ＥＨＴバリアントなのか、ＮＥＸＴバリアントなのかによって決定されてよい。ＴＲＳが含まれるＨＴＣｏｎｔｒｏｌフィールドがＥＨＴバリアント（ｖａｒｉａｎｔ）である場合に、ＴＲＳはＥＨＴＴＲＳであってよい。また、ＴＲＳが含まれるＨＴＣｏｎｔｒｏｌフィールドがＮＥＸＴバリアント（ｖａｒｉａｎｔ）である場合に、ＴＲＳはＮＥＸＴＴＲＳであってよい。また、ＴＲＳのフォーマットは、ＴＲＳが含まれるＨＴＣｏｎｔｒｏｌフィールドのビットのうちあらかじめ指定されたビットがどの値であるかによって、ＨＴＣｏｎｔｒｏｌフィールドがＨＥバリアントなのか、ＥＨＴバリアントなのか、ＮＥＸＴバリアントなのかが決定されてよい。例えば、ＨＴＣｏｎｔｒｏｌフィールドの１番目、２番目のビット（Ｂ０，Ｂ１）値が１１_ｂである場合に、ＨＴＣｏｎｔｒｏｌフィールドはＨＥバリアントであってよい。また、ＨＴＣｏｎｔｒｏｌフィールドの１番目、２番目のビット（Ｂ０，Ｂ１）と追加のビット、例えば３２番目のビット（Ｂ３１）に基づいてＨＴＣｏｎｔｒｏｌフィールドがＨＥｖａｒｉａｎｔなのか、ＥＨＴｖａｒｉａｎｔなのか、ＮＥＸＴｖａｒｉａｎｔなのかが決定されてよい。

図１８の実施例において、ＴＲＳがＨＥＰＰＤＵに含まれる場合に、ＨＥＰＰＤＵを受信したＳＴＡは、ＴＲＳに対する応答としてＨＥＴＢＰＰＤＵを送信する。ＴＲＳがＥＨＴＰＰＤＵに含まれる場合に、ＥＨＴＰＰＤＵを受信したＳＴＡは、ＴＲＳに対する応答としてＥＨＴＴＢＰＰＤＵを送信する。ＴＲＳがＮＥＸＴＰＰＤＵに含まれる場合に、ＮＥＸＴＰＰＤＵを受信したＳＴＡは、ＴＲＳに対する応答としてＮＥＸＴＴＢＰＰＤＵを送信する。

また、ＴＲＳが含まれたＰＰＤＵフォーマットによって、ＴＲＳが含むサブフィールドが示す情報が変わってよい。ＴＲＳがＨＥＰＰＤＵに含まれる場合に、ＴＲＳが含むＭＣＳに関するサブフィールド、例えばＵＬＨＥ－ＭＣＳサブフィールドは、ＨＥＭＣＳテーブルに該当する値を指示できる。また、ＴＲＳがＥＨＴＰＰＤＵに含まれる場合に、ＴＲＳが含むＭＣＳに関するサブフィールド、例えばＵＬＨＥ－ＭＣＳサブフィールドは、ＥＨＴＭＣＳテーブルに該当する値を指示できる。また、ＴＲＳがＮＥＸＴＰＰＤＵに含まれる場合に、ＴＲＳが含むＭＣＳに関するサブフィールド、例えばＵＬＨＥ－ＭＣＳサブフィールドは、ＮＥＸＴＭＣＳテーブルに該当する値を指示できる。また、ＴＲＳが含まれるＰＰＤＵフォーマットによって、ＲＵＡｌｌｏｃａｔｉｏｎサブフィールドが示す情報が変わってよい。

図１９は、本発明の一実施例に係るＴＸＯＰを共有するための方法を示す図である。

図１９を参照すると、ＡＰによって設定されたＴＸＯＰの一部又は全部がｎｏｎ－ＡＰＳＴＡに共有され、ｎｏｎ－ＡＰＳＴＡは、共有されたＴＸＯＰを用いて他のｎｏｎ－ＡＰＳＴＡ（第３ＳＴＡ）及び／又はＡＰにＰＰＤＵ（ＰＬＣＰＰｒｏｔｏｃｏｌＤａｔａＵｎｉｔ）を送信することができる。以下、本発明では、他のＳＴＡにＴＸＯＰを共有することをＴＸＯＰ共有（ｓｈａｒｉｎｇ）と称することができる。また、ＳＴＡは、トリガーフレーム（ｔｒｉｇｇｅｒｆｒａｍｅ）を送信するＡＰ又はＡＰ－ＳＴＡであるか、トリガーフレームを受信するｎｏｎ－ＡＰＳＴＡであってよい。また、ＳＴＡは、ＴＸＯＰを共有したり、又はＴＸＯＰが共有されてよい。

具体的には、ＳＴＡは、ＴＸＯＰを設定するためのフレームを送信した後、これに対する応答を受信することにより、ＴＸＯＰを設定（又は、取得）することができる。ＳＴＡはＴＸＯＰを設定した後に、設定されたＴＸＯＰを共有することによって、ＴＸＯＰ共有を果たすことができる。ＴＸＯＰを設定するためのフレームに対する応答は、ＴＸＯＰの長さに関する情報を含んでよく、ＴＸＯＰの長さは０より大きくてよい。このとき、ＴＸＯＰを設定するためのフレームに対する応答は、即刻の応答（ｉｍｍｅｄｉａｔｅｒｅｓｐｏｎｓｅ）であってよく、ＴＸＯＰを設定するためのフレーム（例えば、ＰＰＤＵ）の終わりから特定時間（例えば、ＳＩＦＳ）後に送信されてよい。

ＴＸＯＰの長さは、ＳＴＡが送信するフレームに含まれるデュレーション情報（ｄｕｒａｔｉｏｎｉｎｆｏｒｍａｔｉｏｎ）に基づいて指示されてよい。例えば、デュレーション情報は、ＰＰＤＵのＭＡＣヘッダーのデュレーション／ＩＤフィールドに含まれてよく、ＴＸＯＰの長さはデュレーション情報に基づくことができる。ＴＸＯＰの長さはＳＴＡによって送信されるフレームのＰＰＤＵに含まれたプリアンブルに含まれてよい。すなわち、デュレーション情報は、ＰＰＤＵのシグナリングフィールド（ｓｉｇｎａｌｉｎｇｆｉｅｌｄ）に含まれるＴＸＯＰフィールドに含まれてよく、シグナリングフィールドはＨＥ－ＳＩＧ－Ａフィールド又はＵ－ＳＩＧフィールドであってよい。

ＴＸＯＰ共有は、設定されたＴＸＯＰ内で共有されてよく、設定されたＴＸＯＰの間に一つ以上のＴＸＯＰが共有されてよい。すなわち、ＳＴＡによって設定されたＴＸＯＰ内で他のＳＴＡに一つ以上のＴＸＯＰが共有されてよい。

ＴＸＯＰが共有されたＳＴＡは、共有されたＴＸＯＰの間にＰＰＤＵを、ＴＸＯＰを共有したＳＴＡ又は他のＳＴＡに送信でき、この時、送信されるＰＰＤＵは、ＴＢＰＰＤＵでないＰＰＤＵ（例えば、ｎｏｎ－ＴＢＰＰＤＵ）であってよい。すなわち、ＴＸＯＰが共有されたＳＴＡは、共有されたＴＸＯＰの間にＡＰからトリガーフレームを受信しなくてもＰＰＤＵを送信することができる。言い換えると、ＴＸＯＰが共有されたＳＴＡは、共有されたＴＸＯＰの間にトリガーフレームによって別途のＲＵが個別的に割り当てられなくても、ＴＸＯＰが共有される時に送信されたトリガーフレームによって、割り当てられたＲＵを用いて、共有されたＴＸＯＰが終了するまで追加のトリガーフレームを受信しなくてもＰＰＤＵを送信することができる。したがって、共有されたＴＸＯＰの間にＳＴＡによって送信されるＰＰＤＵの例示として、ｎｏｎ－ＨＴＰＰＤＵ、ＨＥＰＰＤＵ、ＶＨＴＰＰＤＵ、ＨＥＳＵＰＰＤＵ又はＥＨＴＭＵＰＰＤＵがあり得る。

ＴＸＯＰの共有において、共有されたＴＸＯＰの間に、ＴＸＯＰが共有されたＳＴＡは、ＴＸＯＰを共有したＳＴＡ又は第３ＳＴＡ（さらに他のＳＴＡ）にフレームを送信することができる。すなわち、ＡＰがＴＸＯＰを設定し、設定されたＴＸＯＰの一部又は全部をＳＴＡに共有する場合に、ＴＸＯＰが共有されたＳＴＡは、ＴＸＯＰを共有したＡＰ又は第３ＳＴＡにフレームを送信することができる。このとき、ＳＴＡが第３ＳＴＡに送信するフレームは、ｎｏｎ－ＡＰＳＴＡ同士間で送信するフレームであることから、Ｐ２Ｐ（ｐｅｅｒｔｏｐｅｅｒ）フレームであり得る。

このようなＴＸＯＰの共有は特定フレームによって設定されてよい。すなわち、特定フレームによって設定されたＴＸＯＰの一部又は全部が共有されるということが指示されてよく、ＳＴＡは、当該フレームを受信し、共有されたＴＸＯＰを用いることができる。このとき、特定フレームは、ＴＸＯＰを共有するＳＴＡによって送信されてよい。例えば、ＡＰによって送信されるトリガーフレームによってＴＸＯＰ共有が行われてよい。この場合、ＴＸＯＰ共有のためのトリガーフレームは、特定タイプのトリガーフレーム（例えば、ＭＵ－ＲＴＳフレーム、又はＭＵ－ＲＴＳトリガーフレームなど）であってよく、図１６で説明したトリガーフレームのトリガータイプサブフィールドの値によって識別されてよい。すなわち、トリガータイプサブフィールドの値が既に設定された値（例えば、「３」）に設定された場合に、トリガーフレームを受信したＳＴＡは、ＴＸＯＰが共有されることを認識でき、共有されたＴＸＯＰでＰＰＤＵを送信できる。

ＴＸＯＰを共有するためのフレームであるＭＵ－ＲＴＳフレームは、一つ以上のＳＴＡからＣＴＳフレームの送信を指示するフレームであってよい。例えば、ＭＵ－ＲＴＳフレームに対する即刻の応答としてＣＴＳフレームが送信されてよく、ＣＴＳフレームはｎｏｎ－ＨＴＰＰＤＵであってよい。以下、本発明において、ＴＸＯＰの共有のためのＭＵ－ＲＴＳフレームは、ｍｏｄｉｆｉｅｄＭＵ－ＲＴＳフレーム又はＭＵ－ＲＴＳＴＸＳトリガーフレームと呼ぶことができる。ただし、これに限定されるものではなく、ＴＸＯＰの共有のためのフレームは様々な呼称としてもよい。

ＴＸＯＰの一部又は全部の共有は、１個のＳＴＡにのみ設定されたり、１個以上のＳＴＡに設定されたりしてよい。すなわち、フレームを用いたＴＸＯＰの共有では、ＴＸＯＰ共有のための一つ又はそれ以上のＳＴＡがフレームによって指示されてよい。このとき、ＴＸＯＰの共有は、前述したように、共有するＳＴＡによって設定されたＴＸＯＰ内で設定されてよい。すなわち、共有されるＴＸＯＰは、共有するＳＴＡによって設定されたＴＸＯＰを超えることがない。

共有されるＴＸＯＰのデュレーションは、ＴＸＯＰの共有のための特定フレーム（例えば、ｍｏｄｉｆｉｅｄＭＵ－ＲＴＳフレーム）を通じて指示されてよい。例えば、ｍｏｄｉｆｉｅｄＭＵ－ＲＴＳフレームは、ＵＬ長さサブフィールドを含んでよく、ＵＬ長さサブフィールドは、共有されるＴＸＯＰのデュレーションを含んでよい。このとき、ＵＬ長さサブフィールドは、図１６で説明したＵＬ長さサブフィールドであってよい。ＵＬ長さサブフィールドは、トリガーフレームがＴＢＰＰＤＵの送信を指示する場合に、指示されたＴＢＰＰＤＵの長さに関する情報（又は、ＴＢＰＰＤＵの送信のための区間情報）を含んでよい。

送信されるＭＵ－ＲＴＳフレームがＴＸＯＰの共有のためのＭＵ－ＲＴＳフレーム（ｍｏｄｉｆｉｅｄＭＵ－ＲＴＳフレーム）であるか又はＴＸＯＰの共有のために用いられないＭＵ－ＲＴＳフレームであるかは、フレームに含まれた特定フィールドによって指示されてよい。例えば、フレームに含まれた特定フィールドの値が既に設定された値である場合に、当該ＭＵ－ＲＴＳフレームは、ＴＸＯＰ共有のためのｍｏｄｉｆｉｅｄＭＵ－ＲＴＳフレームであってよい。このとき、特定フレームは、ＧＩＡｎｄＨＥ－ＬＴＦタイプサブフィールドであってよい。例えば、トリガーフレームに含まれたタイプフィールドがＭＵ－ＲＴＳフレームを指示する場合に、ＧＩＡｎｄＨＥ－ＬＴＦタイプサブフィールドの値によって、ＭＵ－ＲＴＳフレームがＴＸＯＰの共有のためのトリガーフレームであるか否かが識別されてよい。すなわち、ＧＩＡｎｄＨＥ－ＬＴＦタイプサブフィールドが既に設定された値に設定された場合に、当該トリガーフレームはＴＸＯＰの共有のためのトリガーフレーム（例えば、ｍｏｄｉｆｉｅｄＭＵ－ＲＴＳフレーム又はＭＵ－ＲＴＳＴＸＳトリガーフレーム）であってよい。

又は、受信されたフレームがＴＸＯＰの共有のためのＭＵ－ＲＴＳフレーム（ｍｏｄｉｆｉｅｄＭＵ－ＲＴＳフレーム又はＭＵ－ＲＴＳＴＸＳトリガーフレーム）であるか否かは、ＭＵ－ＲＴＳフレームに特定フィールドが含まれるか否か及び／又は特定フィールドの個数に基づいて決定されてよい。このとき、特定フィールドは、図１６で説明したユーザ情報フィールド（ＵｓｅｒＩｎｆｏｆｉｅｌｄ）又はユーザ情報リストフィールド（ＵｓｅｒＩｎｆｏＬｉｓｔｆｉｅｌｄ）であってよい。具体的には、ＭＵ－ＲＴＳフレームに含まれたユーザ情報フィールドの個数に基づいて、受信されたＭＵ－ＲＴＳフレームがＴＸＯＰの共有のためのフレームであるか否かが判断されてよい。例えば、ＭＵ－ＲＴＳフレームがユーザ情報フィールドを含まない場合（ユーザ情報フィールドの個数が「０」である場合）に、当該ＭＵ－ＲＴＳフレームはＴＸＯＰ共有のためのフレームであってよい。このとき、ＭＵ－ＲＴＳフレームがＴＸＯＰ共有のためのフレームでない場合に、当該ＭＵ－ＲＴＳフレームは、一つ以上のＳＴＡに既存のＣＴＳフレームの送信を指示するＭＵ－ＲＴＳフレームであるか、既存のＭＵ－ＲＴＳフレームは、８０２．１１ａｘ標準で定義したＭＵ－ＲＴＳフレームであってよい。

既存のＭＵ－ＲＴＳフレームに対する応答としてＣＴＳフレームが送信された直後には、前記既存のＭＵ－ＲＴＳフレームを送信したＳＴＡ（例えば、ＡＰ）がフレーム又はＰＰＤＵを送信できる。また、ｍｏｄｉｆｉｅｄＭＵ－ＲＴＳフレームに対する応答としてＣＴＳフレームが送信された直後には、前記ＣＴＳフレームを送信したＳＴＡがフレーム又はＰＰＤＵを送信できる。又は、ｍｏｄｉｆｉｅｄＭＵ－ＲＴＳフレームに対する応答としてＴＸＯＰ共有を受けたＳＴＡが、ＣＴＳフレームでないフレーム又はＰＰＤＵを送信できる。このとき、フレーム、ＰＰＤＵはそれぞれ、前述の共有されたＴＸＯＰの間にＴＸＯＰ共有を受けたＳＴＡが送信するフレーム、共有されたＴＸＯＰの間にＴＸＯＰ共有を受けたＳＴＡが送信するフレームを含むＰＰＤＵであってよい。すなわち、フレーム又はＰＰＤＵは、ＡＰに向かうものであるか、Ｐ２Ｐフレームであってよい。

本発明において、ＭＵ－ＲＴＳフレームと表記されたものは、既存のＭＵ－ＲＴＳフレームであってよい。すなわち、本発明においてＭＵ－ＲＴＳフレームと表記されたものは、ｍｏｄｉｆｉｅｄＭＵ－ＲＴＳフレームでないＭＵ－ＲＴＳフレームであってよい。

本発明の一実施例によれば、ｍｏｄｉｆｉｅｄＭＵ－ＲＴＳフレームに対する応答としてＣＴＳフレームが送信されてよい。前記ＣＴＳフレームはＴＸＯＰ共有を受けるＳＴＡが送信するものであってよい。このような場合、ＴＸＯＰ共有を受けるＳＴＡは、ＣＴＳフレームを送信した直後にフレームを送信することができる。ＴＸＯＰ共有を受けるＳＴＡは、ＣＴＳフレームを含むＰＰＤＵを送信した直後にフレームを送信することができる。ＣＴＳフレームを送信した直後に送信する前記フレームは、前述の共有されたＴＸＯＰの間にＴＸＯＰ共有を受けたＳＴＡが送信するＰＰＤＵに含まれたものであってよい。又は、ＣＴＳフレームを送信した直後に送信する前記フレームは、前述したｎｏｎ－ＴＢＰＰＤＵに含まれて送信されるものであってよい。また、本発明において直後に送信するということは、ＣＴＳフレームを含むＰＰＤＵの終わりからＳＩＦＳ又はＰＩＦＳ時間以後に送信することを意味できる。ＣＴＳフレームは、ＴＸＯＰ共有を受けるＳＴＡが、ＴＸＯＰ共有を受けたということを知らせる役割を担うことができる。

さらに他の実施例によれば、ｍｏｄｉｆｉｅｄＭＵ－ＲＴＳフレームに対する応答としてＣＴＳフレームが送信されなくてよい。また、ｍｏｄｉｆｉｅｄＭＵ－ＲＴＳフレームの直後に、ＴＸＯＰ共有を受けるＳＴＡはフレームを送信できる。又は、ｍｏｄｉｆｉｅｄＭＵ－ＲＴＳフレームを含むＰＰＤＵ直後に、ＴＸＯＰ共有を受けるＳＴＡはＰＰＤＵを送信できる。この時に送信する前記フレームは、前述の共有されたＴＸＯＰの間に、ＴＸＯＰ共有を受けたＳＴＡが送信するＰＰＤＵに含まれたものであってよい。又は、この時に送信する前記フレームは、前述したｎｏｎ－ＴＢＰＰＤＵに含まれて送信されるものであってよい。また、本発明において、直後に送信するということは、ｍｏｄｉｆｉｅｄＭＵ－ＲＴＳフレームを含むＰＰＤＵの終わりからＳＩＦＳ又はＰＩＦＳ時間以後に送信することを意味してよい。

一実施例によれば、ｍｏｄｉｆｉｅｄＭＵ－ＲＴＳフレームは、ＴＸＯＰ共有を受けるＳＴＡがＣＴＳフレームを送信しなければならないか否かに対するシグナリングを含んでよい。一実施例によれば、ＴＸＯＰ共有を受けるＳＴＡがＡＰに送るフレームを送信する場合に、ＣＴＳフレーム無しで共有されたＴＸＯＰを使用することが可能である。また、ＴＸＯＰ共有を受けるＳＴＡがＰ２Ｐフレームを送信する場合に、ＣＴＳフレームを送信し、共有されたＴＸＯＰを使用することが可能である。また、ＴＸＯＰ共有を受けるＳＴＡがＰ２Ｐフレームを送信する場合にも、ｍｏｄｉｆｉｅｄＭＵ－ＲＴＳフレームの直後に送信するＣＴＳフレームのＲＡフィールドは、前記ｍｏｄｉｆｉｅｄＭＵ－ＲＴＳフレームを送信したＳＴＡのＭＡＣａｄｄｒｅｓｓとして設定されることが可能である。これは、ＴＸＯＰ共有を受けるＳＴＡがｍｏｄｉｆｉｅｄＭＵ－ＲＴＳフレームを受信した後、前記ｍｏｄｉｆｉｅｄＭＵ－ＲＴＳフレームを送信したＳＴＡのａｄｄｒｅｓｓを含むフレームを送信しない場合に、ＴＸＯＰ共有をするＳＴＡは、ＴＸＯＰ共有を受けるＳＴＡがｍｏｄｉｆｉｅｄＭＵ－ＲＴＳフレームを成功的に受信したか否かが分かり難いためである。

図１９を参照すると、ＳＴＡ１とＳＴＡ２が存在してよく、互いに結合（ａｓｓｏｃｉａｔｉｏｎ）されていてよい。また、ＳＴＡ１はＡＰであってよい。ＳＴＡ２はｎｏｎ－ＡＰＳＴＡであってよい。ＳＴＡ１はＭＵ－ＲＴＳフレームを送信することが可能である。前記ＭＵ－ＲＴＳフレームは既存のＭＵ－ＲＴＳフレームであってよい。前記ＭＵ－ＲＴＳフレームは、ＴＸＯＰｄｕｒａｔｉｏｎに関するｄｕｒａｔｉｏｎｉｎｆｏｒｍａｔｉｏｎを含んでよい。前記ＭＵ－ＲＴＳフレームは一つ以上のＳＴＡからＣＴＳフレームを誘発（ｓｏｌｉｃｉｔ）することができる。このとき、前記一つ以上のＳＴＡはＳＴＡ２を含んでよい。ＳＴＡ２は、前記ＭＵ－ＲＴＳフレームに対する応答としてＣＴＳフレームを送信できる。この場合、ＳＴＡ１はＴＸＯＰｈｏｌｄｅｒになり得る。ＴＸＯＰｈｏｌｄｅｒは、ＴＸＯＰを得たＳＴＡであってよい。ＴＸＯＰｈｏｌｄｅｒは、ＴＸＯＰの間に、送信しようとするフレームを送信できる。また、この場合、ＳＴＡ２はＴＸＯＰｒｅｓｐｏｎｄｅｒになり得る。ＴＸＯＰｒｅｓｐｏｎｄｅｒは、ＴＸＯＰｈｏｌｄｅｒが送ったフレームに対する応答を送信したＳＴＡであってよい。ＴＸＯＰｒｅｓｐｏｎｄｅｒは、ＴＸＯＰの間にＴＸＯＰｈｏｌｄｅｒが送信したフレームに対する応答（ｒｅｓｐｏｎｓｅ）を送信することが可能である。又は、ＴＸＯＰｒｅｓｐｏｎｄｅｒは、ＴＸＯＰの間にＴＸＯＰｈｏｌｄｅｒが許容したフレームを送信することが可能である。図１９の実施例において、ＭＵ－ＲＴＳフレーム、ＣＴＳフレームの交換（ｅｘｃｈａｎｇｅ）に基づいてＴＸＯＰが取得される例を説明したが、本発明は、これに限定されず、他のフレーム交換に基づいてＴＸＯＰが取得されることにも適用可能である。

図１９において、ＳＴＡ１がＴＸＯＰを取得した後にＴＸＯＰ共有を行うことが可能である。例えば、ＳＴＡ１は、ＴＸＯＰ共有を知らせるフレームであるｍｏｄｉｆｉｅｄＭＵ－ＲＴＳフレームを送信することができる。例えば、ｍｏｄｉｆｉｅｄＭＵ－ＲＴＳフレームをＳＴＡ２に送信できる。前記ｍｏｄｉｆｉｅｄＭＵ－ＲＴＳフレームのＴＡ（ｔｒａｎｓｍｉｔｔｅｒａｄｄｒｅｓｓ）は、ＳＴＡ１のＭＡＣａｄｄｒｅｓｓ又はＳＴＡ１のＭＡＣａｄｄｒｅｓｓに基づく値に設定されてよい。前記ｍｏｄｉｆｉｅｄＭＵ－ＲＴＳフレームのＲＡ（ｒｅｃｅｉｖｅｒａｄｄｒｅｓｓ）は、ＳＴＡ２のＭＡＣａｄｄｒｅｓｓ又はＳＴＡ２のＭＡＣａｄｄｒｅｓｓに基づく値に設定されてよい。また、前記ｍｏｄｉｆｉｅｄＭＵ－ＲＴＳフレームが含むＵｓｅｒＩｎｆｏフィールドは、ＡＩＤ１２サブフィールド値がＳＴＡ２を指示できる。すなわち、前記ｍｏｄｉｆｉｅｄＭＵ－ＲＴＳフレームが含むＵｓｅｒＩｎｆｏフィールドは、ＡＩＤ１２サブフィールド値がＳＴＡ２のＡＩＤの１２ＬＳＢｓを指示できる。前記ｍｏｄｉｆｉｅｄＭＵ－ＲＴＳフレームは、共有されたＴＸＯＰのｄｕｒａｔｉｏｎに関する情報を含んでよい。

一実施例によれば、ＳＴＡ２は、ｍｏｄｉｆｉｅｄＭＵ－ＲＴＳフレームに対する応答としてＣＴＳフレームを送信できる。また、ＳＴＡ２は、ＣＴＳフレームを送信した後にフレームを送信できる。ＳＴＡ２がＣＴＳフレームを送信した後に送信するフレームは、ＣＴＳフレームでなくてよい。さらに他の実施例によれば、ＳＴＡ２は、ｍｏｄｉｆｉｅｄＭＵ－ＲＴＳフレームに対する応答としてＣＴＳフレームを送信しなくてよい。この場合、ＳＴＡ２は、ｍｏｄｉｆｉｅｄＭＵ－ＲＴＳフレームが送信された後に、ＣＴＳフレームでないフレームを送信できる。また、ＳＴＡ２がｍｏｄｉｆｉｅｄＭＵ－ＲＴＳフレームを受信した後に送信するＣＴＳフレームでないフレームは、一実施例によれば、ＳＴＡ１に送信するフレームであってよい。他の実施例によれば、ＳＴＡ２がｍｏｄｉｆｉｅｄＭＵ－ＲＴＳフレームを受信した後に送信するＣＴＳフレームでないフレームは、ＳＴＡ３に送信するフレームであってよい。

例えば、ＡＰはｎｏｎ－ＡＰＳＴＡ（又は、ＳＴＡ）にトリガーフレームを送信することにより、ＡＰのＴＸＯＰを設定することができる。この時、ＡＰはトリガーフレームを送信したｎｏｎ－ＡＰＳＴＡに、ＡＰによって設定されたＴＸＯＰの一部又は全部を共有しようとする場合に、トリガーフレームの特定フィールド（例えば、ＧＩＡｎｄＨＥ－ＬＴＦタイプサブフィールド）を既に設定された値に設定して送信することができる。このとき、特定フィールドは、ＧＩＡｎｄＨＥ－ＬＴＦタイプ／トリガーされたＴＸＯＰ共有モードサブフィールド（ｔｒｉｇｇｅｒｅｄＴＸＯＰｓｈａｒｉｎｇｍｏｄｅｓｕｂｆｉｅｌｄ）と呼ぶことができる。具体的には、ＡＰがＡＰによって設定されたＴＸＯＰを共有しない場合に、ＧＩＡｎｄＨＥ－ＬＴＦタイプ／トリガーされたＴＸＯＰ共有モードサブフィールドは「０」に設定され、ＧＩＡｎｄＨＥ－ＬＴＦタイプサブフィールドと解釈されてよい。しかし、ＡＰがＡＰによって設定されたＴＸＯＰを共有しない場合に、ＧＩＡｎｄＨＥ－ＬＴＦタイプ／トリガーされたＴＸＯＰ共有モードサブフィールドは「１」又は「２」の値に設定され、トリガーされたＴＸＯＰ共有モードサブフィールドと解釈されてよい。仮に、ＧＩＡｎｄＨＥ－ＬＴＦタイプ／トリガーされたＴＸＯＰ共有モードサブフィールドの値が「１」又は「２」である場合に、当該トリガーフレームは、ｍｏｄｉｆｉｅｄＭＵ－ＲＴＳフレーム又はＭＵ－ＲＴＳＴＸＳトリガーフレームと呼ぶことができる。ＡＰがＡＰによって設定されたＴＸＯＰの一部又は全部を共有する場合に、ＴＸＯＰの共有のためのトリガーフレームのＧＩＡｎｄＨＥ－ＬＴＦタイプ／トリガーされたＴＸＯＰ共有モードサブフィールドは、ＴＸＯＰの共有モードを示す。例えば、ＧＩＡｎｄＨＥ－ＬＴＦタイプ／トリガーされたＴＸＯＰ共有モードサブフィールドは、ＴＸＯＰの共有がＴＸＯＰを設定したＡＰとの送受信においてのみ共有されるか、又はＡＰの他に第３ＳＴＡ（さらに他のＳＴＡ）との送受信においても共有されるかを示す。すなわち、ＧＩＡｎｄＨＥ－ＬＴＦタイプ／トリガーされたＴＸＯＰ共有モードサブフィールドの値が「１」である場合に、共有されたＴＸＯＰの間にＳＴＡはＡＰにのみＰＰＤＵを送信できる。しかし、ＧＩＡｎｄＨＥ－ＬＴＦタイプ／トリガーされたＴＸＯＰ共有モードサブフィールドの値が「２」である場合に、共有されたＴＸＯＰの間にＳＴＡはＡＰの他に別のＳＴＡにもＰＰＤＵを送信することができる。すなわち、ＧＩＡｎｄＨＥ－ＬＴＦタイプ／トリガーされたＴＸＯＰ共有モードサブフィールドの値が「２」である場合に、共有されたＴＸＯＰの間にＳＴＡはＰ２Ｐ通信も行うことができる。

下表１は、ＧＩＡｎｄＨＥ－ＬＴＦタイプ／トリガーされたＴＸＯＰ共有モードサブフィールドの値によるＴＸＯＰ共有の有無及びモードの一例を示す。

図２０は、本発明の一実施例に係るＴＸＯＰの共有及びＮＡＶ設定と関連した方法を示す図である。

図２０の実施例は、図１９で説明した動作を行い難い問題とそれに対する解決方法を説明する実施例であり得る。図１９で説明した内容は省略されてよい。

本発明の一実施例によれば、ＳＴＡは、受信したフレーム又は受信したＰＰＤＵが含むデュレーション情報に基づいてＮＡＶ（ｎｅｔｗｏｒｋａｌｌｏｃａｔｉｏｎｖｅｃｔｏｒ）を設定できる。ＮＡＶが設定されたか否かに基づいて、ｖｉｒｔｕａｌＣＳ（ｃａｒｒｉｅｒｓｅｎｓｅ）結果がｉｄｌｅであるか、ｂｕｓｙであるかが決定されてよい。ＮＡＶ値が０である場合に、ｖｉｒｔｕａｌＣＳ結果がｉｄｌｅであってよい。ＮＡＶ値が０よりも大きい場合に、ｖｉｒｔｕａｌＣＳ結果がｂｕｓｙであってよい。ＰｈｙｓｉｃａｌＣＳは、ＣＣＡ（ｃｌｅａｒｃｈａｎｎｅｌａｓｓｅｓｓｍｅｎｔ）であってよい。仮にｖｉｒｔｕａｌＣＳ又はｐｈｙｓｉｃａｌＣＳの少なくとも一つがｂｕｓｙである場合に、ＣＳ結果はｂｕｓｙであってよい。仮にｖｉｒｔｕａｌＣＳとｐｈｙｓｉｃａｌＣＳの両方がｉｄｌｅである場合に、ＣＳ結果はｉｄｌｅであってよい。また、ＳＴＡがＮＡＶを多数含む場合が存在してよい。例えば、ＳＴＡは、ｉｎｔｒａ－ＢＳＳＮＡＶとｂａｓｉｃＮＡＶを含んでよい。Ｉｎｔｒａ－ＢＳＳＮＡＶは、ｉｎｔｒａ－ＢＳＳフレーム又はｉｎｔｒａ－ＢＳＳＰＰＤＵによって設定されるＮＡＶであってよい。ＲｅｇｕｌａｒＮＡＶは、ｉｎｔｅｒ－ＢＳＳフレーム又はｉｎｔｅｒ－ＢＳＳＰＰＤＵ又はｉｎｔｒａ－ＢＳＳなのかｉｎｔｅｒ－ＢＳＳなのかが判断できないフレーム又はＰＰＤＵによって設定されるＮＡＶであってよい。また、ｉｎｔｒａ－ＢＳＳＮＡＶ、ｂａｓｉｃＮＡＶのうち少なくとも一つが０よりも大きい値である場合に、ｖｉｒｔｕａｌＣＳはｂｕｓｙであってよい。又は、ｉｎｔｒａ－ＢＳＳＮＡＶ、ｂａｓｉｃＮＡＶのうち少なくとも一つが０よりも大きい値である場合に、ＮＡＶが０よりも大きい値であるといえる。ｉｎｔｒａ－ＢＳＳＮＡＶ、ｂａｓｉｃＮＡＶの両方が０である場合に、ｖｉｒｔｕａｌＣＳはｉｄｌｅであってよい。又は、ｉｎｔｒａ－ＢＳＳＮＡＶ、ｂａｓｉｃＮＡＶの両方が０である場合に、ＮＡＶが０であるといえる。

あるＳＴＡにとって、ｉｎｔｒａ－ＢＳＳフレーム又はｉｎｔｒａ－ＢＳＳＰＰＤＵは、前記ＳＴＡと同じＢＳＳから送信されたと判断されるフレーム又はＰＰＤＵであってよい。あるＳＴＡにとって、ｉｎｔｅｒ－ＢＳＳフレーム又はｉｎｔｅｒ－ＢＳＳＰＰＤＵは、前記ＳＴＡと異なるＢＳＳから送信されたと判断されるフレーム又はＰＰＤＵであってよい。また、同じＢＳＳから送信されたか、或いは異なるＢＳＳから送信されたかに対する判断は、ＰＰＤＵのプリアンブルが含むＢＳＳｃｏｌｏｒフィールド、ＭＡＣｈｅａｄｅｒが含むａｄｄｒｅｓｓフィールドなどに基づいて決定されてよい。例えば、ＢＳＳｃｏｌｏｒフィールド又はａｄｄｒｅｓｓフィールドが同じＢＳＳに該当する値である場合に、ｉｎｔｒａ－ＢＳＳフレーム又はｉｎｔｒａ－ＢＳＳＰＰＤＵと判断できる。また、ＢＳＳｃｏｌｏｒフィールド又はａｄｄｒｅｓｓフィールドが同じＢＳＳに該当する値を含まない場合に、ｉｎｔｅｒ－ＢＳＳフレーム又はｉｎｔｅｒ－ＢＳＳＰＰＤＵと判断できる。前記ａｄｄｒｅｓｓフィールドは、ＲＡフィールド、ＴＡフィールド、ＢＳＳＩＤフィールドなどを含んでよい。

一実施例によれば、ＳＴＡは、受信したフレームのリソース割り当てフィールド（ＲｅｓｏｕｒｃｅＡｌｌｏｃａｔｉｏｎ（ＲＡ）ｆｉｅｌｄ）が自分のＭＡＣａｄｄｒｅｓｓでない場合に、前記受信したフレームに基づいてＮＡＶを設定できる。又は、ＳＴＡは、受信したトリガーフレームに基づいてＮＡＶを設定できる。より具体的には、ＳＴＡは、受信したｉｎｔｒａ－ＢＳＳフレームであるトリガーフレームに基づいてＮＡＶを設定できる。このとき、ＮＡＶはｉｎｔｒａ－ＢＳＳＮＡＶであってよい。このとき、前記トリガーフレームが前記ＳＴＡをトリガーするか否かに関係なくＮＡＶを設定できる。又は、ＳＴＡは、受信したフレーム又は受信したＰＰＤＵが前記ＳＴＡから即刻の応答を指示しない場合にＮＡＶを設定できる。

本発明の一実施例によれば、ＣＳがｂｕｓｙである場合に、ＳＴＡはフレーム又はＰＰＤＵを送信できないことがある。

本発明の一実施例によれば、ＮＡＶが０より大きい値に設定されたＳＴＡは、フレーム又はＰＰＤＵを送信できないことがある。より具体的には、ＮＡＶが０より大きい値に設定されたＳＴＡは、既に設定された条件を満たさない場合に、フレーム又はＰＰＤＵを送信できないことがある。

一実施例によれば、ＳＴＡは、受信したフレームが前記ＳＴＡにアドレスされており、即刻の応答を要求する場合に、ＮＡＶに関係なく（又は、ＮＡＶを考慮しないで）送信することが可能である。より具体的には、前記受信したフレームはＲＴＳフレームでなく、トリガーフレームでなくてよい。すなわち、ＳＴＡは、ＮＡＶが０より大きい値に設定されても、受信したフレームが前記ＳＴＡにアドレスされており、即刻の応答を要求する場合に、ＮＡＶに関係なく送信することが可能である。また、フレームがＳＴＡにアドレスされた場合は、前記フレームのＲＡフィールドが前記ＳＴＡのａｄｄｒｅｓｓとして設定された場合を含んでよい。又は、フレームがＳＴＡにアドレスされた場合は、前記フレームが、前記ＳＴＡに該当するｉｄｅｎｔｉｆｉｅｒを含む場合を含んでよい。前記ｉｄｅｎｔｉｆｉｅｒは、ＭＡＣａｄｄｒｅｓｓ、ＡＩＤ（ａｓｓｏｃｉａｔｉｏｎＩＤ）、ＭＡＣａｄｄｒｅｓｓに基づくＩＤ、ＡＩＤに基づくＩＤなどを含んでよい。

さらに他の実施例によれば、ＳＴＡは、受信したフレームがＴＸＯＰｈｏｌｄｅｒから送信された場合に、ＮＡＶに関係なくそれに対する応答を送信することが可能である。このとき、前記ＮＡＶは、前記ＴＸＯＰｈｏｌｄｅｒが送ったフレーム又はＰＰＤＵによって設定されたＮＡＶであってよい。又は、前記ＮＡＶは、ｉｎｔｒａ－ＢＳＳＮＡＶであってよい。また、前記受信したフレームは、ＲＴＳフレームであってよい。フレームがＴＸＯＰｈｏｌｄｅｒから送信されたことは、前記フレームが含むＴＡフィールドに基づいて判断することができる。ＳＴＡは、ＴＸＯＰｈｏｌｄｅｒａｄｄｒｅｓｓを保存することができる。仮にＳＴＡがＴＸＯＰｈｏｌｄｅｒの送信したＲＴＳフレームを受信し、前記ＲＴＳフレームが前記ＳＴＡにアドレスされた場合に、ＮＡＶを考慮しないでＲＴＳフレームに応答できる。このとき、ＲＴＳフレームに対する応答としてＣＴＳフレームを送信できる。

さらに他の実施例によれば、ＳＴＡは、トリガーフレームを受信した場合に、ＮＡＶに関係なくそれに対する応答を送信することが可能である。このとき、前記ＮＡＶは、ｉｎｔｒａ－ＢＳＳＮＡＶに限定されてよい。したがって、ＳＴＡは、同じＢＳＳのＳＴＡ又は同じＢＳＳのＡＰによってＮＡＶが設定された場合に、トリガーフレームによって応答が指示されるとき、ＮＡＶに関係なくそれに対する応答を送信することが可能である。ＳＴＡはトリガーフレームを受信した場合に、ｉｎｔｒａ－ＢＳＳＮＡＶは考慮し、ｂａｓｉｃＮＡＶは考慮しないで、それに対する応答を送信するか否かを決定することが可能である。また、ＳＴＡがトリガーフレームを受信したとき、ＣＳ結果に基づいて前記トリガーフレームに対する応答を送信するか否かを決定することが可能である。例えば、トリガーフレームは、前記トリガーフレームを受信したとき、応答を送信するか否かをＣＳ結果に基づいて決定するか否かを指示するシグナリングを含んでよい。例えば、前記シグナリングは、図１６に示したＣＳＲｅｑｕｉｒｅｄサブフィールドであってよい。仮にＣＳＲｅｑｕｉｒｅｄサブフィールドがＣＳ結果に基づいて応答するか否かを決定することと指示する場合に、ＳＴＡは、ｖｉｒｔｕａｌＣＳとｐｈｙｓｉｃａｌＣＳがｉｄｌｅを示す場合にトリガーフレームに対して応答し、ｖｉｒｔｕａｌＣＳ又はｐｈｙｓｉｃａｌＣＳがｂｕｓｙを示す場合にトリガーフレームに応答しなくてよい。このとき、ｖｉｒｔｕａｌＣＳでｉｎｔｒａ－ＢＳＳＮＡＶは考慮せず、ｂａｓｉｃＮＡＶを考慮することが可能である。また、仮にＣＳＲｅｑｕｉｒｅｄサブフィールドがＣＳ結果に基づかないで応答することを指示する場合に、ＳＴＡは、ＣＳ結果確認無しでトリガーフレームに対して応答することが可能である。

図１９の実施例において、ｍｏｄｉｆｉｅｄＭＵ－ＲＴＳフレームを受信したＳＴＡはＮＡＶが設定されたため、共有されたＴＸＯＰの間に、ＣＴＳフレームでないフレームを送信することが不可能なことがある。図２０でこれについてさらに説明する。

図２０と関連して図１９で説明した内容は省略されてもよい。図２０を参照すると、ＳＴＡ１とＳＴＡ２が存在してよく、互いに結合（ａｓｓｏｃｉａｔｉｏｎ）されていてよい。また、ＳＴＡ１はＡＰであってよい。ＳＴＡ２はｎｏｎ－ＡＰＳＴＡであってよい。ＳＴＡ１は、ＭＵ－ＲＴＳフレームを送信できる。また、ＳＴＡ２は、前記ＭＵ－ＲＴＳフレームに応答してＣＴＳフレームを送信できる。このとき、ＳＴＡ２がＣＴＳフレームを送信したことは、ＳＴＡ２のｐｈｙｓｉｃａｌＣＳ結果がｉｄｌｅであり、ｂａｓｉｃＮＡＶが設定されていないからであってよい。又は、ＳＴＡ２がＣＴＳフレームを送信したことは、ＳＴＡ２が、自分にアドレスされ、即刻の応答を要求するフレームを受信したからであってよい。このとき、ＭＵ－ＲＴＳフレームとＣＴＳフレームの交換（ｅｘｃｈａｎｇｅ）の他に別のフレーム交換が起きる場合にも、ＳＴＡ２は、ＳＴＡ１から受信したフレームに基づいて、前記フレームがＳＴＡ２にアドレスされ、即刻の応答を要求しているため、応答するフレームを送信することが可能である。また、ＳＴＡ２は、ＭＵ－ＲＴＳフレーム又はＳＴＡ１が送信したＭＵ－ＲＴＳフレームの他に別のフレームに基づいてＮＡＶを設定していてもよい。このとき、ＮＡＶはｉｎｔｒａ－ＢＳＳＮＡＶであってよい。

また、ＳＴＡ１はＳＴＡ２にＴＸＯＰ共有（ｓｈａｒｉｎｇ）を行うことができる。すなわち、ＳＴＡ１は、ｍｏｄｉｆｉｅｄＭＵ－ＲＴＳフレームをＳＴＡ２に送信することができる。このとき、前述したように、ＳＴＡ２は、ｓｈａｒｅｄＴＸＯＰを用いて、１）ＣＴＳフレームを送信し、続いて他のフレームを送信したり、２）ＣＴＳフレーム送信無しで他のフレームを送信してよい。ところが、このとき、ＮＡＶが設定されているため、ＳＴＡ２はフレームを送信し難いことがある。例えば、ＳＴＡ２は、ＳＴＡ１がｓｈａｒｅｄＴＸＯＰを割り当てる前に、ＴＸＯＰを得るために送信したフレームによってＮＡＶが設定されていることがあり得る。すなわち、ＳＴＡ２は、ＳＴＡ１がｍｏｄｉｆｉｅｄＭＵ－ＲＴＳフレームを送信する前に送信したフレームを受信し、ＮＡＶが設定されていることがあり得る。又は、ＳＴＡ２は、自分にアドレスされたｍｏｄｉｆｉｅｄＭＵ－ＲＴＳフレームを受信する前に、同じＴＸＯＰの間に他のＳＴＡから送信されたフレームを受信し、ＮＡＶが設定されていることがあり得る。又は、ＳＴＡ２は、自分にアドレスされたｍｏｄｉｆｉｅｄＭＵ－ＲＴＳフレームに基づいてＮＡＶが設定されていることがあり得る。すなわち、ＳＴＡ２は、ｓｈａｒｅｄＴＸＯＰを用いる際に、少なくともｍｏｄｉｆｉｅｄＭＵ－ＲＴＳフレームを受信するはずであるため、ＮＡＶが設定されていることがある。このため、ＳＴＡ２はｓｈａｒｅｄＴＸＯＰを活用してフレームを送信し難いことがある。

したがって、本発明の一実施例によれば、ＴＸＯＰ共有を受けたＳＴＡは、ＮＡＶに関係なくフレームを送信することができる。例えば、ＴＸＯＰ共有を受けたＳＴＡは、共有されたＴＸＯＰの間にＮＡＶに関係なくフレームを送信することができる。例えば、ＴＸＯＰが共有されたＳＴＡは、ＮＡＶが設定されていても（又は、ＮＡＶが０より大きい場合でも）フレームを送信できる。より具体的な実施例によれば、このとき、ＮＡＶは、ｉｎｔｒａ－ＢＳＳＮＡＶに限定されることが可能である。例えば、ＴＸＯＰが共有されたＳＴＡは、ｉｎｔｒａ－ＢＳＳＮＡＶに関係なくフレームを送信することが可能である。また、ＴＸＯＰが共有されたＳＴＡは、ｂａｓｉｃＮＡＶが設定されている場合に、フレームを送信できないことがある。又は、ＴＸＯＰが共有されたＳＴＡは、結合されたＡＰが送ったフレーム又はＰＰＤＵによって設定されたＮＡＶに関係なくフレームを送信することができる。例えば、ＴＸＯＰが共有されたＳＴＡのＮＡＶが結合されたＡＰでないＳＴＡが送ったフレームによって設定された場合に、共有されたＴＸＯＰの間にフレームを送信できないことがある。

すなわち、ＳＴＡは、ＴＸＯＰが共有された場合に、共有されたＴＸＯＰ内に設定されたＮＡＶに関係なくＰＰＤＵを送信することができる。具体的には、ＡＰがＴＸＯＰの共有のためにトリガーフレーム（ｍｏｄｉｆｉｅｄＭＵ－ＲＴＳフレーム又はＭＵ－ＲＴＳＴＸＳトリガーフレーム）を送信した場合に、共有されたＴＸＯＰ内にＡＰによってＮＡＶが設定されてよい。この場合、ＴＸＯＰが共有されたＳＴＡは、共有されたＴＸＯＰ内で設定されたＮＡＶであるがため、ＰＰＤＵの送信が不可能になることがある。したがって、ＴＸＯＰが共有されたＳＴＡは、共有されたＴＸＯＰ内にＴＸＯＰを共有したＡＰによって設定されたＮＡＶを無視してＰＰＤＵを送信することができる。

本発明において、フレームと表示したものは、フレームを含むＰＰＤＵに代えて発明を適用することもできる。

また、このとき、ＴＸＯＰ共有されたＳＴＡがＮＡＶに関係なく送信するフレームは、前のＰＰＤＵからＳＩＦＳ後に送信する場合であってよい。

さらに他の実施例によれば、ＴＸＯＰ共有されたＳＴＡがフレームを送信するとき、前のＰＰＤＵからＰＩＦＳ後にフレームを送信する場合には、ＮＡＶを考慮することが可能である。

図２０を参照すると、ＳＴＡ２は、ＭＵ－ＲＴＳフレーム又はｍｏｄｉｆｉｅｄＭＵ－ＲＴＳフレームに基づいてＮＡＶが設定されてよい。例えば、ｉｎｔｒａ－ＢＳＳＮＡＶが設定されてよい。又は、ＳＴＡ２は、ｉｎｔｒａ－ＢＳＳフレームに基づいてＮＡＶが設定されてよい。又は、ＳＴＡ２は、結合されたＡＰが送信したフレームに基づいてＮＡＶが設定されてよい。本実施例において、ＮＡＶとは、上記のようなＮＡＶを総称するものであってよい。ＳＴＡ１はＳＴＡ２にＴＸＯＰ共有を行うことができる。ＳＴＡ２は、ｍｏｄｉｆｉｅｄＭＵ－ＲＴＳフレームによってＴＸＯＰ共有を受けることができる。ＳＴＡ２は、ｓｈａｒｅｄＴＸＯＰでフレームを送信する時に、ＮＡＶに関係なくフレームを送信することが可能である。この時に送信するフレームは、一実施例によれば、受信したｍｏｄｉｆｉｅｄＭＵ－ＲＴＳフレームの直後に送信したＣＴＳフレームの直後に送信するフレームであってよい。さらに他の実施例によれば、この時に送信するフレームは、受信したｍｏｄｉｆｉｅｄＭＵ－ＲＴＳフレームの直後に送信するフレームであってよい。また、一実施例によれば、ＳＴＡ２が送信するフレームは、ｍｏｄｉｆｉｅｄＭＵ－ＲＴＳフレームを送信したＳＴＡに送るフレームであってよい。すなわち、送信するフレームのＲＡフィールドが、受信したｍｏｄｉｆｉｅｄＭＵ－ＲＴＳフレームのＴＡフィールドの値に設定されてよい。又は、送信するフレームのＲＡフィールドが、ＡＰのＭＡＣａｄｄｒｅｓｓに設定されてよい。他の実施例によれば、ＳＴＡ２が送信するフレームは、ＳＴＡ３に送信するフレームであってよい。また、フレームを直後に送信するということは、前記フレームを含むＰＰＤＵの送信開始時点が、前のＰＰＤＵの終わりからＳＩＦＳ後である場合を意味できる。

図２１は、本発明の一実施例に係るＴＸＯＰの共有及びＣＴＳフレームの送信を示す図である。

図２１の実施例は、図１９及び図２０で説明した問題を解決するための方法であってよい。したがって、前述した内容は説明を省略してもよい。

本発明の一実施例によれば、ＮＡＶを考慮して共有されたＴＸＯＰの間にフレームを送信し難い問題を解決するために、ＮＡＶに関係なく応答を送信できる条件が満たされるようにフレームシーケンスを続けていくことができる。

本発明の実施例によれば、ＴＸＯＰ共有を受けたＳＴＡは、ｍｏｄｉｆｉｅｄＭＵ－ＲＴＳフレームに対する応答としてＣＴＳ－ｔｏ－ｓｅｌｆフレームを送信することができる。ＣＴＳ－ｔｏ－ｓｅｌｆフレームは、ＲＡフィールドが、前記ＣＴＳ－ｔｏ－ｓｅｌｆフレームを送信するＳＴＡのＭＡＣａｄｄｒｅｓｓに設定されたＣＴＳフレームであってよい。このような場合、ＴＸＯＰ共有をするＳＴＡは、ｍｏｄｉｆｉｅｄＭＵ－ＲＴＳフレームを送信した後に、ＴＸＯＰ共有を受けるＳＴＡのＭＡＣａｄｄｒｅｓｓを含むフレームを受信すると、共有されたＴＸＯＰ割り当てに成功したと判断できる。

図２１を参照すると、ＳＴＡ２はＳＴＡ１からｍｏｄｉｆｉｅｄＭＵ－ＲＴＳフレームを受信することができる。また、ＳＴＡ２は、前記ｍｏｄｉｆｉｅｄＭＵ－ＲＴＳフレームの直後にＣＴＳ－ｔｏ－ｓｅｌｆフレームを送信することができる。すなわち、ＳＴＡ２は、ＣＴＳフレームのＲＡフィールドを前記ＳＴＡ２のＭＡＣａｄｄｒｅｓｓに設定してＣＴＳフレームを送信することができる。このような場合、ＳＴＡ２の送ったＣＴＳ－ｔｏ－ｓｅｌｆフレームに対して、自分にアドレスされ、即刻の応答を要求するフレームであると見なすことができる。又は、ＳＴＡ２は、ＣＴＳ－ｔｏ－ｓｅｌｆフレームを送信したことに対して、自分にアドレスされ、即刻の応答を要求するフレームを受信したと見なすことができる。したがって、ＳＴＡ２は、ＮＡＶが設定されていても、ＣＴＳ－ｔｏ－ｓｅｌｆフレームの直後にフレームを送信することができる。

本発明の実施例によれば、ＲＴＳフレーム又はＭＵ－ＲＴＳフレームに対する応答として送信するＣＴＳフレームのＲＡフィールドは、前記ＲＴＳフレーム又は前記ＭＵ－ＲＴＳフレームのＴＡフィールド値又はＴＡフィールド値においてＩｎｄｉｖｉｄｕａｌ／Ｇｒｏｕｐｂｉｔを０に設定した値に設定できる。ところが、図２１で説明したようなＣＴＳ－ｔｏ－ｓｅｌｆフレームを送信するために、追加のＣＴＳフレームのＲＡフィールド設定方法が定義されてよい。例えば、ｍｏｄｉｆｉｅｄＭＵ－ＲＴＳフレームに対する応答として送信するＣＴＳフレームのＲＡフィールドは、前記ＣＴＳフレームを送信するＳＴＡのＭＡＣａｄｄｒｅｓｓに設定されることが可能である。

本発明の一実施例によれば、ＴＸＯＰ共有を受けたＳＴＡは、共有されたＴＸＯＰ内でリカバリー（ｒｅｃｏｖｅｒｙ）を行うことが可能である。すなわち、ＴＸＯＰ共有を受けたＳＴＡは、共有されたＴＸＯＰ内で自分の送信したフレームが失敗した場合にリカバリーを行うことが可能である。例えば、ＴＸＯＰ共有を受けたＳＴＡは、共有されたＴＸＯＰ内で自分の送信したフレームが失敗した場合に、ＰＩＦＳ以後にフレームを送信することが可能である。本発明の実施例によれば、ＴＸＯＰｈｏｌｄｅｒは、リカバリーを行うことが可能である。これに加え、ＴＸＯＰｈｏｌｄｅｒがＴＸＯＰ共有を行った場合に、ＴＸＯＰ共有を受けたＳＴＡがリカバリーを行うことが可能である。すなわち、１）ＴＸＯＰｒｅｓｐｏｎｄｅｒであるか、２）ＴＸＯＰｈｏｌｄｅｒでもＴＸＯＰｒｅｓｐｏｎｄｅｒでもないＳＴＡがＴＸＯＰ共有を受けたＳＴＡになる場合にリカバリーを行うことが可能である。また、ＴＸＯＰ共有を受けたＳＴＡは、ｍｏｄｉｆｉｅｄＭＵ－ＲＴＳフレームを受信した以後に最初のＣＴＳフレームでないフレームを送信した場合にも、前記ＣＴＳフレームでないフレームが失敗するとリカバリー動作を行うことが可能である。例えば、ＴＸＯＰｈｏｌｄｅｒは、シーケンスの最初に送信したフレームが失敗した場合にリカバリー動作を行うことができず、このとき、ＴＸＯＰが得られなかったといえる。しかし、ＴＸＯＰ共有を受けたＳＴＡは、共有されたＴＸＯＰで送信した最初のＣＴＳフレームでないフレームが失敗する場合にもリカバリー動作を行うことができる。

図２１を参照すると、ＳＴＡ２は、図面に表示したＵＬフレームを送信し、それが失敗した場合にリカバリー動作を行うことができる。すなわち、ＳＴＡ２は、ＵＬフレームを送信し、図面に表示したＤＬフレームを受信していない場合にフレームを再び送信することができる。このとき、再び送信するフレームは、図面に表示した失敗したＵＬフレームを含むＰＰＤＵの終わりからＰＩＦＳ後に送信を始めることができる。また、リカバリー中にチャネルがｉｄｌｅであるか否かが確認できる。また、ＴＸＯＰ共有を受けたＳＴＡが行うリカバリー動作では、ｖｉｒｔｕａｌＣＳを考慮せず、ｐｈｙｓｉｃａｌＣＳのみを考慮できる。

図２２は、本発明の一実施例に係るＴＸＯＰの共有のためのトリガーフレームの一例を示す図である。

図１９で説明したように、ｍｏｄｉｆｉｅｄＭＵ－ＲＴＳフレームであるか否かは、ユーザ情報フィールドの個数に基づくことができる。ところが、８０２．１１ａｘ標準で定義したトリガーフレームは、以後の標準で機能が拡張されることを考慮しないで設計されたものであり得る。したがって、例えば、図１６（ｂ）に示した共通情報フィールド（ＣｏｍｍｏｎＩｎｆｏｆｉｅｌｄ）は、拡張された機能を含むにはシグナリング空間が不足し得る。したがって、本発明の一実施例によれば、既に設定されたＡＩＤ１２サブフィールド値を含むユーザ情報フィールドは、図１６（ｃ）に示したのと異なるフォーマットを有してよい。また、既に設定されたＡＩＤ１２サブフィールド値を含むユーザ情報フィールドは、前記ユーザ情報フィールドを含むトリガーフレームの全ての受信者又は一つ以上の受信者に該当する情報を含んでよい。例えば、既に設定されたＡＩＤ１２サブフィールド値を含むユーザ情報フィールドは、ＰＨＹｖｅｒｓｉｏｎＩＤ、帯域幅ｅｘｔｅｎｓｉｏｎ、帯域幅、ｓｐａｔｉａｌｒｅｕｓｅ、Ｕ－ＳＩＧｒｅｓｅｒｖｅｄｂｉｔｓのうち少なくとも一つの情報を含んでよい。また、前記既に設定されたＡＩＤ１２サブフィールド値は、実際ＡＩＤとして割り当てられない値に基づくことができる。前記既に設定されたＡＩＤ１２サブフィールド値は、実際ＡＩＤとして割り当てられない値の１２ＬＳＢｓであってよい。例えば、前記既に設定されたＡＩＤ１２サブフィールド値は、２００７であってよい。

また、先に言及した拡張された機能は、例えば、広くなった帯域幅を含んでよい。例えば、帯域幅が最大で１６０ＭＨｚから最大で３２０ＭＨｚに拡張されてよい。また、拡張された機能は、Ｕ－ＳＩＧフィールドを生成するための情報を含んでよい。

したがって、本発明の実施例によれば、ｍｏｄｉｆｉｅｄＭＵ－ＲＴＳフレーム又は共有されたＴＸＯＰ内においても拡張された機能を使用するために、ｍｏｄｉｆｉｅｄＭＵ－ＲＴＳフレームは、先に言及した既に設定されたＡＩＤ１２サブフィールド値を含むユーザ情報フィールドを含んでよい。

本発明の実施例によれば、ｍｏｄｉｆｉｅｄＭＵ－ＲＴＳフレームは、ユーザ情報フィールドを一つも含まないか、先に言及した既に設定されたＡＩＤ１２サブフィールド値を含むユーザ情報フィールドのみをユーザ情報フィールドに含んでよい。すなわち、受信したトリガーフレームがユーザ情報フィールドを一つも含まないか、先に言及した既に設定されたＡＩＤ１２サブフィールド値を含むユーザ情報フィールドのみをユーザ情報フィールドに含む場合に、前記トリガーフレームをｍｏｄｉｆｉｅｄＭＵ－ＲＴＳフレームとして判断できる。又は、受信したＭＵ－ＲＴＳフレームがユーザ情報フィールドを一つも含まないか、先に言及した既に設定されたＡＩＤ１２サブフィールド値を含むユーザ情報フィールドのみをユーザ情報フィールドに含む場合に、前記ＭＵ－ＲＴＳフレームをｍｏｄｉｆｉｅｄＭＵ－ＲＴＳフレームとして判断できる。このとき、ＴＸＯＰ共有を受けるＳＴＡは、トリガーフレームのＲＡフィールドによって指示されてよい。

図２２を参照すると、ｍｏｄｉｆｉｅｄＭＵ－ＲＴＳフレームは、タイプサブフィールドがＭＵ－ＲＴＳに設定されてよい。また、ｍｏｄｉｆｉｅｄＭＵ－ＲＴＳフレームは、ユーザ情報フィールドが１個存在することが可能であり、このとき、前記ユーザ情報フィールドが含むＡＩＤ１２サブフィールドは、既に設定された値に設定されてよい。このとき、前記既に設定された値はＡＩＤとして割り当てられない値であってよい。また、前記既に設定された値は、前記ｍｏｄｉｆｉｅｄＭＵ－ＲＴＳフレームのＲＡフィールド値をＭＡＣａｄｄｒｅｓｓとして有するＳＴＡのＡＩＤの１２ＬＳＢｓと異なる値であってよい。例えば、前記既に設定された値は、２００７であってよい。又は、ｍｏｄｉｆｉｅｄＭＵ－ＲＴＳフレームは、ユーザ情報フィールドを一つも含まないことが可能である。すなわち、トリガーフレームを受信したＳＴＡは、前記トリガーフレームのＴｙｐｅがＭＵ－ＲＴＳフレームとして設定された場合に、前記トリガーフレームがユーザ情報フィールドを一つも含まないか、又は既に設定された値のＡＩＤ１２サブフィールドを含むユーザ情報フィールドのみを含む場合に、前記トリガーフレームをｍｏｄｉｆｉｅｄＭＵ－ＲＴＳフレームとして判断できる。

図２３は、本発明の一実施例に係るＮＡＶタイムアウト（ｔｉｍｅｏｕｔ）を示す図である。

本発明の一実施例によれば、ＳＴＡは、設定したＮＡＶを解除（ｒｅｓｅｔ）することが可能である。例えば、ＲＴＳフレーム又はＭＵ－ＲＴＳフレームに基づいてＮＡＶを設定した場合に、ＮＡＶを解除することが可能である。より具体的には、ＲＴＳフレーム又はＭＵ－ＲＴＳフレームに基づいてＮＡＶを設定した場合に、既に設定された時間の間にＰＰＤＵ受信を成功的に開始できなかった場合にＮＡＶを解除することが可能である。このような動作をＮＡＶタイムアウト又はＮＡＶＴｉｍｅｏｕｔと呼ぶことができる。既に設定された時間をＮＡＶＴｉｍｅｏｕｔｐｅｒｉｏｄ又はＮＡＶタイムアウト周期と呼ぶことができる。ＮＡＶＴｉｍｅｏｕｔｐｅｒｉｏｄは、ＲＴＳフレーム又はＭＵ－ＲＴＳフレームに該当するＰＨＹ－ＲＸＥＮＤ．ｉｎｄｉｃａｔｉｏｎｐｒｉｍｉｔｉｖｅを受けた時に始まってよい。

本発明の実施例において、ＲＴＳフレーム又はＭＵ－ＲＴＳフレームに基づいてＮＡＶを設定した場合は、直近のＮＡＶアップデートがＲＴＳフレーム又はＭＵ－ＲＴＳフレームに基づいてなされた場合を意味できる。仮にＳＴＡがＲＴＳフレーム又はＭＵ－ＲＴＳフレームから受信したデュレーション情報が、前記ＳＴＡの現在ＮＡＶ値よりも大きい場合に、前記ＲＴＳフレーム又はＭＵ－ＲＴＳフレームに基づいてＮＡＶを設定又はアップデートすることができる。前記デュレーション情報は、ＭＡＣｈｅａｄｅｒが含むＤｕｒａｔｉｏｎ／ＩＤフィールドに基づいて得るか、ＰＰＤＵのプリアンブルに含まれたＴＸＯＰデュレーション又はＴＸＯＰフィールドに基づいて得ることができる。

また、本発明の実施例において、ＰＰＤＵ受信を成功的に始めた場合に、ＰＨＹ－ＲＸＳＴＡＲＴ．ｉｎｄｉｃａｔｉｏｎｐｒｉｍｉｔｉｖｅを受けることができる。又は、ＰＰＤＵ受信を成功的に始めた場合に、ＰＨＹ－ＲＸＳＴＡＲＴ．ｉｎｄｉｃａｔｉｏｎｐｒｉｍｉｔｉｖｅが発行されてよい。ＰＨＹ－ＲＸＳＴＡＲＴ．ｉｎｄｉｃａｔｉｏｎｐｒｉｍｉｔｉｖｅは、ＰＨＹからＭＡＣに伝達されるものであってよい。例えば、ＰＨＹがＰＰＤＵの有効な（ｖａｌｉｄ）開始を受信した場合にＰＨＹ－ＲＸＳＴＡＲＴ．ｉｎｄｉｃａｔｉｏｎｐｒｉｍｉｔｉｖｅが生成されてよい。また、ＰＰＤＵの有効な開始を受信したことは、有効なＰＨＹｈｅａｄｅｒを受信した場合を意味できる。また、ＰＨＹ－ＲＸＳＴＡＲＴ．ｉｎｄｉｃａｔｉｏｎｐｒｉｍｉｔｉｖｅは、ＰＰＤＵフォーマットを判断した後に生成されることが可能である。ＰＨＹ－ＲＸＳＴＡＲＴ．ｉｎｄｉｃａｔｉｏｎｐｒｉｍｉｔｉｖｅが生成された場合に、ＰＰＤＵの長さ又はＰＰＤＵのプリアンブルが指示する長さの間に、ＰＨＹはｐｈｙｓｉｃａｌｍｅｄｉｕｍをｂｕｓｙｓｔａｔｕｓとして維持することができる。仮にＰＨＹ－ＲＸＳＴＡＲＴ．ｉｎｄｉｃａｔｉｏｎｐｒｉｍｉｔｉｖｅが生成されると、ＰＰＤＵの中間に受信に失敗しても、ＰＰＤＵの長さ又はＰＰＤＵのプリアンブルが指示する長さの間に、ＰＨＹはｐｈｙｓｉｃａｌｍｅｄｉｕｍをｂｕｓｙｓｔａｔｕｓとして維持できる。また、ＰＰＤＵ受信を終了した場合にＰＨＹ－ＲＸＥＮＤ．ｉｎｄｉｃａｔｉｏｎが生成されてよい。

本発明の実施例によれば、先に言及したＮＡＶタイムアウト周期は、ＲＴＳフレーム又はＭＵ－ＲＴＳフレームに対する応答時間に基づくものであってよい。すなわち、ＲＴＳフレーム又はＭＵ－ＲＴＳフレームに対する応答がＣＴＳフレームである場合に、ＮＡＶタイムアウト周期は、ＣＴＳフレーム時間に基づくものであってよい。前記ＣＴＳフレーム時間をＣＴＳ＿Ｔｉｍｅと示すことができる。又は、ＲＴＳフレーム又はＭＵ－ＲＴＳフレームに対する応答時間をＣＴＳ＿Ｔｉｍｅと示すことができる。このとき、ＲＴＳフレーム又はＭＵ－ＲＴＳフレームに対する応答時間は、前記応答を含むＰＰＤＵの長さを意味できる。

一実施例によれば、ＮＡＶタイムアウト周期は、次のうち少なくとも一つに基づくものであってよい。

１）ＣＴＳ＿Ｔｉｍｅ

２）ａＳＩＦＳＴｉｍｅ

３）ａＲｘＰＨＹＳｔａｒｔＤｅｌａｙ

４）ａＳｌｏｔＴｉｍｅ

一実施例によれば、ＣＴＳ＿Ｔｉｍｅは、既に設定された比率（ｒａｔｅ）に基づいて計算することが可能である。すなわち、ＣＴＳ＿Ｔｉｍｅは、既に設定された比率に基づいて計算したＣＴＳフレームの長さであってよい。又は、すなわち、ＣＴＳ＿Ｔｉｍｅは、既に設定された比率に基づいて計算したＣＴＳフレームを含むＰＰＤＵの長さであってよい。例えば、既に設定された比率は６Ｍｂｐｓであってよい。例えば、ＣＴＳ＿Ｔｉｍｅは、６Ｍｂｐｓのデータ比率（ｄａｔａｒａｔｅ）に基づいて計算することが可能である。又は、既に設定されたｒａｔｅは、ＮＡＶを設定するようにしたＲＴＳフレーム又はＭＵ－ＲＴＳフレームの比率であってよい。又は、既に設定されたｒａｔｅは、ＮＡＶを設定するようにしたＲＴＳフレーム又はＭＵ－ＲＴＳフレームが指示する比率であってよい。

一実施例によれば、ａＳＩＦＳＴｉｍｅは、ＳＩＦＳ長さであってよい。例えば、ａＳＩＦＳＴｉｍｅは２．４ＧＨｚ帯域で動作する場合に、１０ｕｓであってよい。例えば、ａＳＩＦＳＴｉｍｅは、５ＧＨｚ帯域又は６ＧＨｚ帯域で動作する場合に、１６ｕｓであってよい。

一実施例によれば、ａＲｘＰＨＹＳｔａｒｔＤｅｌａｙは、ＰＰＤＵの始めから受信者（ｒｅｃｅｉｖｅｒ）がＰＨＹ－ＲＸＳＴＡＲＴ．ｉｎｄｉｃａｔｉｏｎｐｒｉｍｉｔｉｖｅを生成するまでにかかる遅延（ｄｅｌａｙ）であってよい。例えば、ａＲｘＰＨＹＳｔａｒｔＤｅｌａｙは、ＰＰＤＵの始めからＰＰＤＵｆｏｒｍａｔを判断するまでにかかる時間であってよい。例えば、ａＲｘＰＨＹＳｔａｒｔＤｅｌａｙは、ＰＰＤＵフォーマットによって異なってよい。ａＲｘＰＨＹＳｔａｒｔＤｅｌａｙは、ｎｏｎ－ＨＴＰＰＤＵに対して２０ｕｓであってよい。また、ａＲｘＰＨＹＳｔａｒｔＤｅｌａｙは、ＨＴ－ｍｉｘｅｄｆｏｒｍａｔのＨＴＰＰＤＵに対して２８ｕｓであってよい。また、ａＲｘＰＨＹＳｔａｒｔＤｅｌａｙは、ＨＴ－ｇｒｅｅｎｆｉｅｌｄｆｏｒｍａｔのＨＴＰＰＤＵに対して２４ｕｓであってよい。また、ａＲｘＰＨＹＳｔａｒｔＤｅｌａｙは、ＶＨＴＰＰＤＵに対して（３６＋４＊（ｔｈｅｍａｘｉｍｕｍｐｏｓｓｉｂｌｅｖａｌｕｅｆｏｒＮ＿ＶＨＴ－ＬＴＦｓｕｐｐｏｒｔｅｄ）＋４）ｕｓであってよい。Ｎ＿ＶＨＴ－ＬＴＦは、ＶＨＴ－ＬＴＦの個数であってよい。また、ａＲｘＰＨＹＳｔａｒｔＤｅｌａｙは、ＨＥＳＵＰＰＤＵ又はＨＥＴＢＰＰＤＵに対して３２ｕｓであってよい。また、ａＲｘＰＨＹＳｔａｒｔＤｅｌａｙは、ＨＥＥＲＳＵＰＰＤＵに対して４０ｕｓであってよい。また、ａＲｘＰＨＹＳｔａｒｔＤｅｌａｙは、ＨＥＭＵＰＰＤＵに対して（３２＋４＊Ｎ＿ＨＥ－ＳＩＧ－Ｂ）ｕｓであってよい。Ｎ＿ＨＥ－ＳＩＧ－Ｂは、ＨＥ－ＳＩＧ－ＢフィールドのＯＦＤＭシンボル個数であってよい。また、ａＲｘＰＨＹＳｔａｒｔＤｅｌａｙは、ＥＨＴＭＵＰＰＤＵ又はＥＨＴＴＢＰＰＤＵに対して３２ｕｓであってよい。

一実施例によれば、ＮＡＶｔｉｍｅｏｕｔｐｅｒｉｏｄは、（（２＊ａＳＩＦＳＴｉｍｅ）＋（ＣＴＳ＿Ｔｉｍｅ）＋ａＲｘＰＨＹＳｔａｒｔＤｅｌａｙ＋（２＊ａＳｌｏｔＴｉｍｅ））であってよい。

本発明の実施例によれば、ＲＴＳフレームは、ＣＴＳフレームを指示するフレームであってよい。又は、ＲＴＳフレームは、単一（ｓｉｎｇｌｅ）ＳＴＡからＣＴＳフレームを指示するフレームであってよい。ＲＴＳフレームは、フレームＣｏｎｔｒｏｌフィールド、デュレーションフィールド、ＲＡフィールド、ＴＡフィールド、ＦＣＳフィールドを含んでよい。デュレーションフィールドは、前記デュレーションフィールドを受信するＳＴＡがＮＡＶを設定するための時間情報が含まれてよい。また、ＲＡフィールドには、意図した即刻の応答者（ｉｎｔｅｎｄｅｄｉｍｍｅｄｉａｔｅｒｅｃｉｐｉｅｎｔ）のアドレスが含まれてよい。例えば、ＳＴＡが受信したＲＴＳフレームが含むＲＡフィールドが前記ＳＴＡのアドレスである場合に、前記ＲＴＳフレームに対してＣＴＳフレームで応答することが可能である。また、フレームがＲＴＳフレームであることは、前記フレームが含むフレームＣｏｎｔｒｏｌフィールドに基づいて判断されてよい。例えば、フレームがＲＴＳフレームであることは、前記フレームが含むフレームＣｏｎｔｒｏｌフィールドに含まれたＴｙｐｅサブフィールド、Ｓｕｂｔｙｐｅサブフィールド基づいて判断されてよい。例えば、Ｔｙｐｅサブフィールドが０１（Ｂ３Ｂ２）であり、Ｓｕｂｔｙｐｅサブフィールドが１０１１（Ｂ７Ｂ６Ｂ５Ｂ４）である場合に、前記Ｔｙｐｅサブフィールド及び前記Ｓｕｂｔｙｐｅサブフィールドを含むフレームがＲＴＳフレームであることを指示できる。例えば、ＲＴＳフレームはＣｏｎｔｒｏｌフレームであってよい。

ＣＴＳフレームは、フレームＣｏｎｔｒｏｌフィールド、デュレーションフィールド、ＲＡフィールド、ＦＣＳフィールドを含んでよい。デュレーションフィールドは、前記デュレーションフィールドを受信するＳＴＡがＮＡＶを設定するための時間情報が含まれてよい。例えば、Ｔｙｐｅサブフィールドが０１（Ｂ３Ｂ２）であり、Ｓｕｂｔｙｐｅサブフィールドが１１００（Ｂ７Ｂ６Ｂ５Ｂ４）である場合に、前記Ｔｙｐｅサブフィールド及び前記Ｓｕｂｔｙｐｅサブフィールドを含むフレームがＣＴＳフレームであることを指示できる。例えば、ＣＴＳフレームはＣｏｎｔｒｏｌフレームであってよい。

図２３の１番目のシーケンスを参照すると、ＳＴＡ１、ＳＴＡ２、ＳＴＡ３が存在してよい。また、ＳＴＡ１がＲＴＳフレーム又はＭＵ－ＲＴＳフレームをＳＴＡ２に送信できる。例えば、前記ＲＴＳフレーム又は前記ＭＵ－ＲＴＳフレームのＲＡフィールドがＳＴＡ２のアドレスに設定された場合に、前記ＲＴＳフレーム又は前記ＭＵ－ＲＴＳフレームはＳＴＡ２に送信されるものであってよい。又は、前記ＭＵ－ＲＴＳフレームが含むＵｓｅｒＩｎｆｏフィールドがＳＴＡ２を指示する場合に、前記ＭＵ－ＲＴＳフレームはＳＴＡ２に送信されるものであってよい。仮にＳＴＡ２が前記ＲＴＳフレーム又は前記ＭＵ－ＲＴＳフレームを成功的に受信した場合に、ＣＴＳフレームで応答することが可能である。このとき、ＳＴＡ２がキャリアセンス（ｃａｒｒｉｅｒｓｅｎｓｅ，ＣＡ）結果に基づいて応答することができる。また、ＳＴＡ３が前記ＲＴＳフレーム又は前記ＭＵ－ＲＴＳフレームを受信する場合に、前記ＲＴＳフレーム又は前記ＭＵ－ＲＴＳフレームが含むデュレーション情報又は前記ＲＴＳフレーム又は前記ＭＵ－ＲＴＳフレームを含むＰＰＤＵが含むデュレーション情報に基づいて、ＳＴＡ３はＮＡＶを設定できる。また、ＳＴＡ１がＳＴＡ２の送信したＣＴＳフレームを成功的に受信した場合に、ＳＴＡ１はＳＴＡ２にフレームを送信できる。また、ＳＴＡ３はＮＡＶを設定した後、ＳＴＡ２が送信したＣＴＳフレーム又はＳＴＡ１がＳＴＡ２に送信したフレームを受信していてよい。このような場合、ＳＴＡ３は、ＮＡＶＴｉｍｅｏｕｔｐｅｒｉｏｄ内にＰＨＹ－ＲＸＳＴＡＲＴ．ｉｎｄｉｃａｔｉｏｎｐｒｉｍｉｔｉｖｅを受けることができる。したがって、ＳＴＡ３が設定したＮＡＶを解除できないことがある。

図２３の２番目のシーケンスを参照すると、ＳＴＡ１、ＳＴＡ２、ＳＴＡ３が存在してよい。また、ＳＴＡ１がＲＴＳフレーム又はＭＵ－ＲＴＳフレームをＳＴＡ２に送信することができる。仮にＳＴＡ２が前記ＲＴＳフレーム又は前記ＭＵ－ＲＴＳフレームを成功的に受信できなかった場合に、ＣＴＳフレームで応答できないことがある。又は、ＳＴＡ２が前記ＲＴＳフレーム又は前記ＭＵ－ＲＴＳフレームを成功的に受信したが、キャリアセンス結果に基づいてＣＴＳフレームで応答できないことがある。このような場合、ＳＴＡ１がＳＴＡ２に送るフレームシーケンスが続かないことがある。

また、ＳＴＡ３が前記ＲＴＳフレーム又は前記ＭＵ－ＲＴＳフレームを受信する場合に、前記ＲＴＳフレーム又は前記ＭＵ－ＲＴＳフレームが含むデュレーション情報又は前記ＲＴＳフレーム又は前記ＭＵ－ＲＴＳフレームを含むＰＰＤＵが含むデュレーション情報に基づいて、ＳＴＡ３はＮＡＶを設定できる。また、ＳＴＡ３はＮＡＶを設定した後に、ＳＴＡ２が送信したＣＴＳフレーム又はＳＴＡ１がＳＴＡ２に送信したフレームを受信することができないことがある。このような場合、ＳＴＡ３は、ＮＡＶＴｉｍｅｏｕｔｐｅｒｉｏｄ内にＰＨＹ－ＲＸＳＴＡＲＴ．ｉｎｄｉｃａｔｉｏｎｐｒｉｍｉｔｉｖｅを受信できない。したがって、ＳＴＡ３が設定したＮＡＶを解除することができる。これにより、シーケンスが続かなかったにもかかわらず、ＳＴＡ３がＮＡＶを維持することからチャネルに接続（ａｃｃｅｓｓ）できない問題を解決することができる。

図２４は、本発明の一実施例に係るＴＸＯＰの共有及びＮＡＶタイムアウトを示す図である。

図２４を参照すると、前述したように、ＳＴＡ１がＳＴＡ２にＴＸＯＰ共有を行うことが可能である。ＳＴＡ１は、ＴＸＯＰ共有をするＳＴＡであり、ＳＴＡ２は、ＴＸＯＰ共有を受けるＳＴＡであってよい。ＳＴＡ１はＳＴＡ２にシーケンスの１番目のフレームを送信することができる。図２４を参照すると、ＳＴＡ１がＳＴＡ２に送信するシーケンスの１番目のフレームはＭＵ－ＲＴＳフレームであってよい。また、前記ＭＵ－ＲＴＳフレームに対する応答であるＣＴＳフレームが送信されてよい。

例えば、ＳＴＡ２を含むＳＴＡからＣＴＳフレームが送信されてよい。ＳＴＡ１はＴＸＯＰを得ることができる。また、ＳＴＡ３は、前記ＭＵ－ＲＴＳフレームと前記ＣＴＳフレームを成功的に受信できないことがある。ＳＴＡ１は、ｍｏｄｉｆｉｅｄＭＵ－ＲＴＳフレームをＳＴＡ２に送信できる。すなわち、ＳＴＡ１はＳＴＡ２にＴＸＯＰ共有を行うことができる。また、ＳＴＡ３は、前記ｍｏｄｉｆｉｅｄＭＵ－ＲＴＳフレームを成功的に受信することができる。したがって、ＳＴＡ３は前記ｍｏｄｉｆｉｅｄＭＵ－ＲＴＳフレームに基づいてＮＡＶを設定することができる。この場合、ＳＴＡ３は、ＭＵ－ＲＴＳフレームに基づいてＮＡＶを設定したものであってよい。また、前述したＴＸＯＰ共有シーケンスによれば、ｍｏｄｉｆｉｅｄＭＵ－ＲＴＳフレームに対してＳＴＡ２が、１）ＣＴＳフレームを送信し、ＣＴＳフレームを送信した直後にフレームを送信することができる。又は、ｍｏｄｉｆｉｅｄＭＵ－ＲＴＳフレームに対してＳＴＡ２が、２）ＣＴＳフレームを送信せず、フレームを送信することができる。また、ＳＴＡ３がＳＴＡ２からのフレーム又はＰＰＤＵを受信できないことがある。例えば、ＳＴＡ３がＳＴＡ２からｈｉｄｄｅｎである位置に存在し得る。例えば、ＳＴＡ２が送信する電力がＳＴＡ３に受信される程度に十分でないことがあり得る。このような場合、ＳＴＡ３は、ＮＡＶタイムアウト周期の間にＰＰＤＵを受信できないことがある。ＮＡＶｔｉｍｅｏｕｔｐｅｒｉｏｄは、ＣＴＳ＿Ｔｉｍｅに基づいて決定されるためであり得る。すなわち、ＳＴＡ２がＣＴＳフレーム送信後にフレームを送信する場合に、ＳＴＡ３は、前記フレームが送信される間にＮＡＶＴｉｍｅｏｕｔｐｅｒｉｏｄが終わるはずである。又は、ＳＴＡ２がＣＴＳフレーム送信無しでフレームを送信する場合に、前記フレームはＣＴＳフレームよりも長い可能性が高いため、ＳＴＡ３は、前記フレームが送信される間にＮＡＶＴｉｍｅｏｕｔｐｅｒｉｏｄが終わるはずである。したがって、ＳＴＡ３はＮＡＶを解除することが可能である。仮にＳＴＡ３がＮＡＶを解除すると、ＳＴＡ３がチャネルに接続し、共有されたＴＸＯＰの間のシーケンスを妨害することがある。

図２５は、本発明のさらに他の実施例に係るＴＸＯＰの共有及びＮＡＶタイムアウトを示す図である。

図２５を参照すると、ＡＰによってＴＸＯＰが共有された場合に、ＡＰによってＴＸＯＰが共有されたＳＴＡでない他のＳＴＡ（第３ＳＴＡ）は、ＴＸＯＰが共有されたＳＴＡからＣＴＳフレーム又は他のフレームが一定時間の間に送信されない場合にも、共有されたＴＸＯＰを解除しなくてよい。図２５の実施例は、図２３及び図２４で説明した問題を解決するためのものであってよい。また、前述した内容は省略されてもよい。

具体的には、ＡＰから送信されたトリガーフレーム（例えば、ＭＵ－ＲＴＳフレーム）が、ＴＸＯＰを共有するためのｍｏｄｉｆｉｅｄＭＵ－ＲＴＳフレーム又はＭＵ－ＲＴＳＴＸＳトリガーフレームであるか否かに基づいて、ＴＸＯＰを解除するためのＮＡＶタイムアウトが許容されたり或いは許容されなくてよい。すなわち、一般的に設定されたＴＸＯＰであるか又はＡＰによって設定されたＴＸＯＰの全部又は一部が共有されたＴＸＯＰであるかによって、ＴＸＯＰが設定されたＳＴＡでない他のＳＴＡが設定されたＴＸＯＰを解除するためのＮＡＶタイムアウトが許容されるか否かが決定されてよい。

例えば、設定されたＴＸＯＰの一部又は全部の共有のためのフレーム（ｍｏｄｉｆｉｔｅｄＭＵ－ＲＴＳフレーム又はＭＵ－ＲＴＳＴＸＳトリガーフレーム）でないＭＵ－ＲＴＳフレームに基づいてＮＡＶが設定された場合に、ＮＡＶタイムアウトが許容されてよい。すなわち、ＳＴＡがＭＵ－ＲＴＳフレームに基づいてＮＡＶを設定した場合に、前記ＭＵ－ＲＴＳフレームがｍｏｄｉｆｉｅｄＭＵ－ＲＴＳフレームでない場合に、ＮＡＶＴｉｍｅｏｕｔｐｅｒｉｏｄの間にＰＰＤＵ受信を成功的に開始できなかった場合に、ＮＡＶを解除することが可能である。

しかし、設定されたＴＸＯＰの一部又は全部を共有するためのフレームであるｍｏｄｉｆｉｅｄＭＵ－ＲＴＳフレーム又はＭＵ－ＲＴＳＴＸＳトリガーフレームによってＮＡＶが設定された場合に、ＮＡＶタイムアウトは許容されなくてよい。すなわち、ＳＴＡがＭＵ－ＲＴＳフレームに基づいてＮＡＶを設定した場合に、当該ＭＵ－ＲＴＳフレームがＴＸＯＰ共有のためのｍｏｄｉｆｉｅｄＭＵ－ＲＴＳフレーム又はＭＵ－ＲＴＳＴＸＳトリガーフレームであれば、ＳＴＡはＮＡＶＴｉｍｅｏｕｔｐｅｒｉｏｄの間にＰＰＤＵ受信を成功的に開始できなくても、ＮＡＶを解除することが不可である。

すなわち、ＳＴＡがＮＡＶアップデートのために直近に受信したフレームが、ＴＸＯＰ共有のためのフレームであるｍｏｄｉｆｉｅｄＭＵ－ＲＴＳフレーム又はＭＵ－ＲＴＳＴＸＳトリガーフレームであれば、ＳＴＡは、ＮＡＶＴｉｍｅｏｕｔが満了した後、ＮＡＶをリセットしてはならない。

受信したＭＵ－ＲＴＳフレームがｍｏｄｉｆｉｅｄＭＵ－ＲＴＳフレームであるか否かの決定は、前述した実施例に従うことができる。例えば、ＭＵ－ＲＴＳフレームが含むＧＩＡｎｄＨＥ－ＬＴＦＴｙｐｅサブフィールドに基づいて、ｍｏｄｉｆｉｅｄＭＵ－ＲＴＳフレームであるか否かが決定されてよい。例えば、ＧＩＡｎｄＨＥ－ＬＴＦＴｙｐｅサブフィールド値が０である場合に、前記ＧＩＡｎｄＨＥ－ＬＴＦＴｙｐｅサブフィールドを含むＭＵ－ＲＴＳフレームは、ｍｏｄｉｆｉｅｄＭＵ－ＲＴＳフレームでなくてよい。また、ＧＩＡｎｄＨＥ－ＬＴＦＴｙｐｅサブフィールド値が０でない場合に、前記ＧＩＡｎｄＨＥ－ＬＴＦＴｙｐｅサブフィールドを含むＭＵ－ＲＴＳフレームは、ｍｏｄｉｆｉｅｄＭＵ－ＲＴＳフレームであってよい。例えば、ＧＩＡｎｄＨＥ－ＬＴＦＴｙｐｅサブフィールド値が１又は２である場合に、前記ＧＩＡｎｄＨＥ－ＬＴＦＴｙｐｅサブフィールドを含むＭＵ－ＲＴＳフレームは、ｍｏｄｉｆｉｅｄＭＵ－ＲＴＳフレームであってよい。

本発明の実施例により、図２４で説明した問題、すなわち、ＳＴＡがｍｏｄｉｆｉｅｄＭＵ－ＲＴＳフレームに基づいてＮＡＶを設定した後、ＮＡＶｔｉｍｅｏｕｔ動作を行うことによって共有されたＴＸＯＰのシーケンスを妨害する問題を防止することができる。

また、このような実施例を、８０２．１１ｂｅ標準以降の端末（ＥＨＴ標準を含むその以後の標準の端末）が行い、８０２．１１ａｘ標準の端末（ＨＥＳＴＡ）は行うことができないことがある。ＨＥＳＴＡがこれを行うことができなくても、上記の実施例により、説明した問題が発生する確率を減らすことができる。

図２５を参照すると、ＳＴＡ１、ＳＴＡ２、ＳＴＡ３が存在してよい。また、ＳＴＡ１がＳＴＡ２にＭＵ－ＲＴＳフレームを送信できる。例えば、ＳＴＡ１が、ｍｏｄｉｆｉｅｄＭＵ－ＲＴＳフレームでないＭＵ－ＲＴＳフレームを送信できる。ところが、前記ＭＵ－ＲＴＳフレームの意図した受信者（ｉｎｔｅｎｄｅｄｒｅｃｅｉｖｅｒ）であるＳＴＡ２が前記ＭＵ－ＲＴＳフレームに応答できないことがある。したがって、ＳＴＡ２がＣＴＳフレームを送信できないことがある。また、ＳＴＡ３は、前記ＭＵ－ＲＴＳフレームに基づいてＮＡＶを設定することができる。ところが、ＳＴＡ２がＣＴＳフレームを送信できなかったため、ＳＴＡ３はＮＡＶＴｉｍｅｏｕｔｐｅｒｉｏｄの間にＰＰＤＵ受信を成功的に開始できていないことがある。この場合、ＮＡＶｔｉｍｅｏｕｔ動作に基づいて、ＳＴＡ３は、設定したＮＡＶを解除することが可能である。これは、ＳＴＡ３がＮＡＶを設定するようにしたフレームが、ｍｏｄｉｆｉｅｄＭＵ－ＲＴＳフレームでないＭＵ－ＲＴＳフレームであるからである。

また、ＳＴＡ１がｍｏｄｉｆｉｅｄＭＵ－ＲＴＳフレームを送信することができる。図２５では、ｍｏｄｉｆｉｅｄＭＵ－ＲＴＳフレームの前のフレームが省略されていてよい。前記ｍｏｄｉｆｉｅｄＭＵ－ＲＴＳフレームの意図した受信者であるＳＴＡ２が、前記ｍｏｄｉｆｉｅｄＭＵ－ＲＴＳフレームに応答できる。また、ＳＴＡ３は、前記ｍｏｄｉｆｉｅｄＭＵ－ＲＴＳフレームに基づいてＮＡＶを設定できる。ところが、ＳＴＡ２が前記ｍｏｄｉｆｉｅｄＭＵ－ＲＴＳフレームに対して送信した応答をＳＴＡ３が受信できていないことがある。例えば、ＳＴＡ３にＳＴＡ２が送信した応答が十分に大きい電力で聞こえないからである。例えば、ＳＴＡ３とＳＴＡ２が遠く離れているからである。このような場合、ＳＴＡ３は、ＮＡＶＴｉｍｅｏｕｔｐｅｒｉｏｄの間にＰＰＤＵ受信を成功的に開始できていないことがある。これは、ＳＴＡ２がｍｏｄｉｆｉｅｄＭＵ－ＲＴＳフレーム後に、ＣＴＳフレームを送信した後にフレームを送信したためであり得る。又は、これは、ＳＴＡ２がｍｏｄｉｆｉｅｄＭＵ－ＲＴＳフレーム後に、ＣＴＳフレームよりも長いフレームを送信したためであり得る。又は、これは、ＳＴＡ２がｍｏｄｉｆｉｅｄＭＵ－ＲＴＳフレーム後に、ＣＴＳフレームを含むＰＰＤＵよりも長いＰＰＤＵを送信したためであり得る。この場合、ＳＴＡ３は、ＮＡＶｔｉｍｅｏｕｔ動作に基づくＮＡＶを解除する動作を行うことができないことがある。これは、ＳＴＡ３がＮＡＶを設定するようにしたフレームが、ｍｏｄｉｆｉｅｄＭＵ－ＲＴＳフレームであるＭＵ－ＲＴＳフレームであるためであり得る。

図２６は、本発明のさらに他の実施例に係るＴＸＯＰの共有及びＮＡＶタイムアウトを示す図である。

図２６の実施例は、図２３及び図２４で説明した問題を解決するためのものであってよい。また、前述した内容は省略されてもよい。

本発明の一実施例によれば、ＭＵ－ＲＴＳフレームがｍｏｄｉｆｉｅｄＭＵ－ＲＴＳフレームであるか否かに基づいてＮＡＶｔｉｍｅｏｕｔｐｅｒｉｏｄが個別に決定されてよい。例えば、ＭＵ－ＲＴＳフレームがｍｏｄｉｆｉｅｄＭＵ－ＲＴＳフレームであるか否かに基づいてＣＴＳ＿Ｔｉｍｅが個別に決定されてよい。一実施例によれば、ＭＵ－ＲＴＳフレームがｍｏｄｉｆｉｅｄＭＵ－ＲＴＳフレームである場合に、ＮＡＶｔｉｍｅｏｕｔｐｅｒｉｏｄは、ＭＵ－ＲＴＳフレームがｍｏｄｉｆｉｅｄＭＵ－ＲＴＳフレームでない場合のＮＡＶｔｉｍｅｏｕｔｐｅｒｉｏｄよりも長くてよい。本実施例において、ＭＵ－ＲＴＳフレームがｍｏｄｉｆｉｅｄＭＵ－ＲＴＳフレームである場合に、ＮＡＶｔｉｍｅｏｕｔｐｅｒｉｏｄをｅｘｔｅｎｄｅｄＮＡＶＴｉｍｅｏｕｔｐｅｒｉｏｄと呼ぶことができる。図２３で説明したＮＡＶＴｉｍｅｏｕｔｐｅｒｉｏｄとｅｘｔｅｎｄｅｄＮＡＶＴｉｍｅｏｕｔｐｅｒｉｏｄは、同一時点に始まってよい。すなわち、ＭＵ－ＲＴＳフレームに該当するＰＨＹ－ＲＸＥＮＤ．ｉｎｄｉｃａｔｉｏｎｐｒｉｍｉｔｉｖｅを受けた時に始まってよい。図２３で説明したＮＡＶＴｉｍｅｏｕｔｐｅｒｉｏｄは、ＣＴＳフレーム時間に基づく時間であってよい。例えば、図２３で説明したＮＡＶＴｉｍｅｏｕｔｐｅｒｉｏｄは、ＣＴＳフレームを６Ｍｂｐｓで送信するのにかかる時間に基づく時間であってよい。

本発明の実施例によれば、ＳＴＡがｍｏｄｉｆｉｅｄＭＵ－ＲＴＳフレームに基づいてＮＡＶを設定した場合に、ｅｘｔｅｎｄｅｄＮＡＶＴｉｍｅｏｕｔｐｅｒｉｏｄの間にＰＰＤＵ受信を成功的に開始できなかった場合に、ＮＡＶを解除することが可能である。ＳＴＡがｍｏｄｉｆｉｅｄＭＵ－ＲＴＳフレームに基づいてＮＡＶを設定した場合に、図２３で説明したＮＡＶＴｉｍｅｏｕｔｐｅｒｉｏｄの間にＰＰＤＵ受信を成功的に開始できなかった場合にもＮＡＶを解除できないことがある。

また、ＳＴＡがｍｏｄｉｆｉｅｄＭＵ－ＲＴＳフレームでないＭＵ－ＲＴＳフレームに基づいてＮＡＶを設定した場合に、図２３で説明したＮＡＶＴｉｍｅｏｕｔｐｅｒｉｏｄの間にＰＰＤＵ受信を成功的に開始できなかった場合に、ＮＡＶを解除することが可能である。

本発明の実施例によれば、ｅｘｔｅｎｄｅｄＮＡＶＴｉｍｅｏｕｔｐｅｒｉｏｄは、ｍｏｄｉｆｉｅｄＭＵ－ＲＴＳフレームが含む長さ情報に基づいて決定されてよい。例えば、ｍｏｄｉｆｉｅｄＭＵ－ＲＴＳフレームが含む長さ情報に基づいてＣＴＳ＿Ｔｉｍｅが決定されてよい。又は、ｅｘｔｅｎｄｅｄＮＡＶＴｉｍｅｏｕｔｐｅｒｉｏｄは、ｍｏｄｉｆｉｅｄＭＵ－ＲＴＳフレームが含む長さ情報とｍｏｄｉｆｉｅｄＭＵ－ＲＴＳフレームに該当するｒａｔｅに基づいて決定されてよい。例えば、ｍｏｄｉｆｉｅｄＭＵ－ＲＴＳフレームが含む長さ情報とｍｏｄｉｆｉｅｄＭＵ－ＲＴＳフレームに該当するｒａｔｅに基づいてＣＴＳ＿Ｔｉｍｅが決定されてよい。例えば、ｍｏｄｉｆｉｅｄＭＵ－ＲＴＳフレームが含む長さ情報は、図１６に示したＵＬＬｅｎｇｔｈサブフィールドに含まれてよい。さらに他の実施例において、ｍｏｄｉｆｉｅｄＭＵ－ＲＴＳフレームが含む長さ情報は、図１６に示したＵｓｅｒＩｎｆｏフィールドに含まれてよい。より具体的には、ｍｏｄｉｆｉｅｄＭＵ－ＲＴＳフレームが含む長さ情報は、図１６に示したＵｓｅｒＩｎｆｏフィールドのうち、ＴＸＯＰ共有を受けるＳＴＡを指示するＵｓｅｒＩｎｆｏフィールドに含まれてよい。

また、ＴＸＯＰ共有を受けたＳＴＡは、ｍｏｄｉｆｉｅｄＭＵ－ＲＴＳフレームが含む長さ情報に基づいてＰＰＤＵを送信することができる。例えば、ＴＸＯＰ共有を受けたＳＴＡは、ｍｏｄｉｆｉｅｄＭＵ－ＲＴＳフレームが含む長さ情報に基づいて、共有されたＴＸＯＰの最初のＰＰＤＵを送信できる。又は、ＴＸＯＰ共有を受けたＳＴＡは、ｍｏｄｉｆｉｅｄＭＵ－ＲＴＳフレームが含む長さ情報に基づいて、共有されたＴＸＯＰのＣＴＳフレームを含まない最初のＰＰＤＵを送信できる。共有されたＴＸＯＰのＣＴＳフレームを含まない最初のＰＰＤＵは、ＣＴＳフレームを含むＰＰＤＵ次の最初のＰＰＤＵであってよい。

図２６を参照すると、ＳＴＡ１、ＳＴＡ２、ＳＴＡ３が存在してよい。また、ＳＴＡ１がＳＴＡ２にＭＵ－ＲＴＳフレームを送信することができる。例えばＳＴＡ１がｍｏｄｉｆｉｅｄＭＵ－ＲＴＳフレームでないＭＵ－ＲＴＳフレームを送信できる。ところが、前記ＭＵ－ＲＴＳフレームの意図した受信者であるＳＴＡ２が前記ＭＵ－ＲＴＳフレームに応答できないことがある。したがって、ＳＴＡ２がＣＴＳフレームを送信できないことがある。また、ＳＴＡ３は、前記ＭＵ－ＲＴＳフレームに基づいてＮＡＶを設定できる。ところが、ＳＴＡ２がＣＴＳフレームを送信できなかったため、ＳＴＡ３はＮＡＶＴｉｍｅｏｕｔｐｅｒｉｏｄの間にＰＰＤＵ受信を成功的に開始できないことがある。この場合、ＮＡＶｔｉｍｅｏｕｔ動作に基づいて、ＳＴＡ３は、設定したＮＡＶを解除することが可能である。これは、ＳＴＡ３がＮＡＶを設定するようにしたフレームがｍｏｄｉｆｉｅｄＭＵ－ＲＴＳフレームでないＭＵ－ＲＴＳフレームであるため、決定したＮＡＶＴｉｍｅｏｕｔｐｅｒｉｏｄに基づく動作であってよい。すなわち、ＳＴＡ３がＮＡＶを設定するようにしたフレームがｍｏｄｉｆｉｅｄＭＵ－ＲＴＳフレームでないＭＵ－ＲＴＳフレームであるため、ＮＡＶＴｉｍｅｏｕｔｐｅｒｉｏｄを、ＣＴＳフレームを送信するのにかかる時間に基づいて決定することができる。

また、ＳＴＡ１がｍｏｄｉｆｉｅｄＭＵ－ＲＴＳフレームを送信することができる。図２６は、ｍｏｄｉｆｉｅｄＭＵ－ＲＴＳフレームの前のフレームを省略したものであってよい。前記ｍｏｄｉｆｉｅｄＭＵ－ＲＴＳフレームの意図した受信者であるＳＴＡ２が、前記ｍｏｄｉｆｉｅｄＭＵ－ＲＴＳフレームに応答することができる。また、ＳＴＡ３は、前記ｍｏｄｉｆｉｅｄＭＵ－ＲＴＳフレームに基づいてＮＡＶを設定することができる。ところが、ＳＴＡ２が前記ｍｏｄｉｆｉｅｄＭＵ－ＲＴＳフレームに対して送信した応答をＳＴＡ３が受信できないことがある。例えば、ＳＴＡ３にＳＴＡ２が送信した応答が十分に大きい電力で聞こえないためであり得る。例えば、ＳＴＡ３とＳＴＡ２が遠く離れているためであり得る。このような場合、ＳＴＡ３は、図２３で説明したＮＡＶＴｉｍｅｏｕｔｐｅｒｉｏｄの間にＰＰＤＵ受信を成功的に開始できないことがある。しかし、このような場合、ＳＴＡ３は、ｅｘｔｅｎｄｅｄＮＡＶＴｉｍｅｏｕｔｐｅｒｉｏｄの間にＰＰＤＵ受信を成功的に始めることができる。したがって、ＳＴＡ３は、ＮＡＶｔｉｍｅｏｕｔ動作を行わなくてよい。ＳＴＡ３が図２３で説明したＮＡＶＴｉｍｅｏｕｔｐｅｒｉｏｄが過ぎた時にＮＡＶ解除動作をせずに、ｅｘｔｅｎｄｅｄＮＡＶＴｉｍｅｏｕｔｐｅｒｉｏｄを待つことができたのは、ＳＴＡ３がＮＡＶを設定するようにしたフレームがｍｏｄｉｆｉｅｄＭＵ－ＲＴＳフレームであるＭＵ－ＲＴＳフレームであるためであり得る。

仮に前記ｍｏｄｉｆｉｅｄＭＵ－ＲＴＳフレームを受信したＳＴＡ２が応答できなかった場合に、ＳＴＡ１は、リカバリー（ｒｅｃｏｖｅｒｙ）動作を行うことができる。したがって、ＳＴＡ３がＮＡＶｔｉｍｅｏｕｔ動作をする前にＰＰＤＵ受信を成功的に始めることができる。

又は、前記ｍｏｄｉｆｉｅｄＭＵ－ＲＴＳフレームを受信したＳＴＡ２が応答できなかった場合に、共有されたＴＸＯＰのシーケンスが絶えることがある。この場合、ＳＴＡ３は、ＮＡＶｔｉｍｅｏｕｔ動作を行い、実際フレーム交換が発生しない時に不要にＮＡＶを設定していてチャネルに接続できない問題を解決することができる。

ＴＸＯＰ共有において、ＡＰによって設定されたＴＸＯＰの一部又は全部が共有されたスケジュールドＳＴＡが、設定されたＮＡＶによって送信を行い難い問題と解決方法について図２０で説明した。さらに他の実施例に係る解決方法について図２７を用いて説明する。以下、スケジュールドＳＴＡとＴＸＯＰが共有されたＳＴＡとは同じＳＴＡであり、呼称は相互交換的に使われてよい。

図２７は、本発明の一実施例によってＴＸＯＰ共有が適用される時に、ＳＴＡ及びＡＰがＮＡＶを適用することを示す図である。

ＴＸＯＰ共有において、スケジュールドＳＴＡはＮＡＶを設定しなくてよい。具体的には、ＴＸＯＰ共有において、スケジュールドＳＴＡは、ＴＸＯＰ共有設定のためのＭＵ－ＲＴＳフレームであるｍｏｄｉｆｉｅｄＭＵ－ＲＴＳフレーム又はＭＵ－ＲＴＳＴＸＳトリガーフレームに基づいてＮＡＶを設定しなくてよい。ＴＸＯＰ共有設定のためのＭＵ－ＲＴＳフレームを受信したＳＴＡは、ＴＸＯＰ共有設定のためのＭＵ－ＲＴＳフレームに基づいてＮＡＶを設定しなくてよい。ＴＸＯＰ共有設定のためのＭＵ－ＲＴＳフレームによってスケジュールされたＳＴＡは、ＴＸＯＰ共有設定のためのＭＵ－ＲＴＳフレームに基づいてＮＡＶを設定しなくてよい。したがって、ＳＴＡがトリガーフレームを受信し、トリガーフレームがＳＴＡにＴＸＯＰ共有をスケジュールする場合に、ＳＴＡはトリガーフレームに基づいてＮＡＶを設定しなくてよい。すなわち、トリガーフレームがＴＸＯＰを共有するためのトリガーフレームであるか否かによって、ＳＴＡは、受信されたトリガーフレームに基づいてＮＡＶを設定することができる。例えば、受信されたＭＵ－ＲＴＳフレームがＴＸＯＰの共有のためのｍｏｄｉｆｉｅｄＭＵ－ＲＴＳフレーム又はＭＵ－ＲＴＳＴＸＳトリガーフレームである場合に、ＳＴＡは、受信されたＭＵ－ＲＴＳフレームに基づくＮＡＶを設定しない。しかし、受信されたＭＵ－ＲＴＳフレームがＴＸＯＰの共有のためのｍｏｄｉｆｉｅｄＭＵ－ＲＴＳフレーム又はＭＵ－ＲＴＳＴＸＳトリガーフレームでない場合に、ＳＴＡは、受信されたＭＵ－ＲＴＳフレームに基づくＮＡＶを設定する。

また、ＴＸＯＰ共有において、スケジュールドＳＴＡは、共有されたＴＸＯＰ内で受信したフレームに基づいてＮＡＶを設定しなくてよい。

この時、共有されたＴＸＯＰ内とは、共有されたＴＸＯＰの期間（ｄｕｒａｔｉｏｎ）が全て活用されない場合にも、共有されたＴＸＯＰが終了するまでのことを指すことができる。共有されたＴＸＯＰのスケジュールドＳＴＡがＰＰＤＵを送信し、ＰＰＤＵが即刻の応答を要請しないフレームのみを含む場合に、ＳＴＡがＰＰＤＵを送信した時にＴＸＯＰが終了する。したがって、共有されたＴＸＯＰ内は、ＴＸＯＰ共有が設定された時からＴＸＯＰ共有のスケジュールドＳＴＡが即刻の応答を要請しないフレームのみを含むＰＰＤＵを送信した時までであってよい。ＴＸＯＰ共有のスケジュールドＳＴＡが、共有されたＴＸＯＰの終了をシグナルした場合に、共有されたＴＸＯＰが終了してよい。したがって、共有されたＴＸＯＰ内は、ＴＸＯＰ共有が設定された時からＴＸＯＰ共有のスケジュールドＳＴＡが共有されたＴＸＯＰの終了をシグナルした時までであってよい。また、ＴＸＯＰ内は、ＴＸＯＰ共有が設定された時から共有されたＴＸＯＰデュレーションが経過した時までであってよい。又は、ＴＸＯＰ共有を受けたＳＴＡ（又は、ＴＸＯＰ共有をしたＳＴＡ）が共有されたＴＸＯＰが終了する旨のシグナリングを送受信した場合に、共有されたＴＸＯＰは終了してよい。この場合、共有されたＴＸＯＰとＡＰが共有のために用いたＴＸＯＰ（最初ＡＰのフレームによって取得されたＴＸＯＰ）のデュレーションは同一であるか、共有されたＴＸＯＰのデュレーションがＴＸＯＰのデュレーションよりも短い。したがって、共有されたＴＸＯＰが終了してもＴＸＯＰは終了しなくて済む。すなわち、共有されたＴＸＯＰのデュレーションとＴＸＯＰのデュレーションとが同一である場合に、共有されたＴＸＯＰが終了するとＴＸＯＰも共に終了するが、共有されたＴＸＯＰのデュレーションがＴＸＯＰのデュレーションよりも短い場合に、共有されたＴＸＯＰが終了してもＴＸＯＰは維持され得る。

さらに他の具体的な実施例において、共有されたＴＸＯＰが共有されたＴＸＯＰ期間前に終了しても、共有されたＴＸＯＰ期間内は、ＴＸＯＰ共有が設定された時から共有されたＴＸＯＰデュレーションが経過した時までであってよい。

前述したように、ＴＸＯＰ共有において、スケジュールドＳＴＡは、ＮＡＶに関係なくフレームを送信することができる。すなわち、ＡＰによって設定されたＴＸＯＰ内でＮＡＶが設定された場合に（例えば、ｉｎｔｒａ－ＢＳＳＰＰＤＵによって設定されたＮＡＶ）、スケジュールドＳＴＡは、共有されたＴＸＯＰ内では、設定されたＮＡＶとは関係なくＰＰＤＵを送信することができる。言い換えると、ＴＸＯＰが共有されたＳＴＡは、ＴＸＯＰを共有したＳＴＡによって送信されるフレームによって設定されるＮＡＶを、共有されたＴＸＯＰ内では無視してフレームを送信することができる。このとき、共有されたＴＸＯＰは、ＭＵ－ＲＴＳフレームによって設定された区間よりも前に終了してよい。すなわち、共有されたＴＸＯＰ内でＭＵ－ＲＴＳによって設定された区間以前に、ＴＸＯＰが共有されたＳＴＡがＴＸＯＰの共有の中断を要請するためのシグナリングを送信することによってＴＸＯＰの共有を中断することができる。例えば、ｎｏｎ－ＡＰＳＴＡはＡＰからＴＸＯＰの全部又は一部が共有された場合に、送信する（又は、ペンドされた）ＰＰＤＵがないと、共有されたＴＸＯＰを終了するために、ＴＸＯＰ共有を終了するためのシグナリングをＡＰに送信し、ＴＸＯＰの共有を中断することができる。ＴＸＯＰ共有が中断される時点は、ｎｏｎ－ＡＰＳＴＡがＴＸＯＰ共有の中断を要請するシグナリングを送信する時点又は当該シグナリングに対する応答フレームを受信する時点のいずれか一つであってよい。このとき、ＴＸＯＰの共有のためのシグナリングは即刻の応答を要求しても要求しなくてもよい。また、この場合、ｎｏｎ－ＡＰＳＴＡは、ＭＵ－ＲＴＳフレームによって設定されるＴＸＯＰが共有される区間よりも早い時点にＴＸＯＰ共有が中断されるため、ＴＸＯＰの共有が終了する時点のみまで、設定されたＮＡＶを無視できる。

この時、ＴＸＯＰ共有を設定したＳＴＡも、ＮＡＶに関係なくフレームを送信することができる。図２７の実施例において、第１ＳＴＡ（ＳＴＡ１）は第２ＳＴＡ（ＳＴＡ２）にＴＸＯＰ共有設定のためのＭＵ－ＲＴＳフレームを送信する。このとき、第１ＳＴＡ（ＳＴＡ１）はＡＰであってよい。第２ＳＴＡ（ＳＴＡ２）はＴＸＯＰ共有設定のためのＭＵ－ＲＴＳフレームを受信し、ＴＸＯＰ共有設定のためのＭＵ－ＲＴＳフレームに対する応答としてＣＴＳフレームを送信する。第２ＳＴＡ（ＳＴＡ２）は、共有されたＴＸＯＰ内でフレーム交換を行う。第１ＳＴＡ（ＳＴＡ１）は、第２ＳＴＡ（ＳＴＡ２）が送信したり第２ＳＴＡ（ＳＴＡ２）に送信されるフレームに基づいてＮＡＶを設定できる。例えば、共有されたＴＸＯＰ内で第２ＳＴＡ（ＳＴＡ２）は第３ＳＴＡ（ＳＴＡ３）とフレーム交換を行うことができる。この時、第１ＳＴＡ（ＳＴＡ１）は、第３ＳＴＡ（ＳＴＡ３）が第２ＳＴＡ（ＳＴＡ２）に送信したフレームに基づいてＮＡＶを設定できる。また、第１ＳＴＡ（ＳＴＡ１）は、第２ＳＴＡ（ＳＴＡ２）が第３ＳＴＡ（ＳＴＡ３）に送信したフレームに基づいてＮＡＶを設定できる。このように第１ＳＴＡ（ＳＴＡ１）がＮＡＶを設定した場合に、共有されたＴＸＯＰが割り当てられたＴＸＯＰ内でフレームを送信し難いことがある。例えば、共有されたＴＸＯＰが終了した後に第１ＳＴＡ（ＳＴＡ１）がフレームを送信しようとするとき、共有されたＴＸＯＰ内で設定されたＮＡＶによってフレームを送信できないことがある。具体的には、共有されたＴＸＯＰ内で送信されたＰＰＤＵが含むフレームが第１ＳＴＡ（ＳＴＡ１）から即刻の応答を誘発するフレームでない場合に、第１ＳＴＡ（ＳＴＡ１）は、設定されたＮＡＶによってフレームを送信できないことがある。

ＴＸＯＰ共有を設定したＳＴＡは、ＳＴＡが取得したＴＸＯＰ内でＮＡＶに関係なくフレームを送信することができる。さらに他の具体的な実施例において、ＴＸＯＰ共有を設定したＳＴＡは、共有されたＴＸＯＰが終了した時から取得したＴＸＯＰ内でＮＡＶに関係なくフレームを送信することができる。ＴＸＯＰ共有を設定したＳＴＡは、ＴＸＯＰ共有を設定するためのＭＵ－ＲＴＳフレームを送信したＳＴＡ又はＴＸＯＰホルダーであってよい。

この時、前述したように、共有されたＴＸＯＰは、ＭＵ－ＲＴＳフレームによって設定された区間以前に終了してよい。すなわち、共有されたＴＸＯＰ内でＭＵ－ＲＴＳによって設定された区間以前に、ＴＸＯＰが共有されたＳＴＡがＴＸＯＰの共有の中断を要請するためのシグナリングを送信することによってＴＸＯＰの共有を中断できる。例えば、ｎｏｎ－ＡＰＳＴＡは、ＡＰからＴＸＯＰの全部又は一部が共有された場合に、送信する（又は、ペンドされた）ＰＰＤＵがないと、共有されたＴＸＯＰを終了するために、ＴＸＯＰ共有を終了するためのシグナリングをＡＰに送信してＴＸＯＰの共有を中断することができる。ＴＸＯＰ共有が中断される時点は、ｎｏｎ－ＡＰＳＴＡがＴＸＯＰ共有の中断を要請するシグナリングを送信する時点又は当該シグナリングに対する応答フレームを受信する時点のいずれか一つであってよい。この時、ＴＸＯＰの共有のためのシグナリングは、即刻の応答を要求しても要求しなくてもよい。また、この場合、ＭＵ－ＲＴＳフレームによって設定されるＴＸＯＰが共有される区間よりも早い時点にＴＸＯＰ共有が中断されるため、ＴＸＯＰの共有が終了する時点から、ＡＰは、ｎｏｎ－ＡＰＳＴＡによって送受信されたＰＰＤＵに基づいてＡＰによって設定されたＮＡＶを無視できる。

前述した実施例において、ＴＸＯＰ共有を設定したＳＴＡがＮＡＶに関係なくフレームを送信することは、ＴＸＯＰ共有内でスケジュールドＳＴＡが交換したフレームに基づいて設定されたＮＡＶに関係なくフレームを送信することを表すことができる。ＴＸＯＰ共有を設定したＳＴＡが、ＴＸＯＰ共有内でスケジュールドＳＴＡが交換しなかったフレームに基づいて設定されたＮＡＶに関係なくフレームを送信する場合に、他のＳＴＡのフレーム交換を妨害することがあるためである。また、ＳＴＡは、ＴＸＯＰ共有内でスケジュールドＳＴＡが交換したフレームであるかを、フレームのＭＡＣヘッダーに基づいて判断できる。具体的には、ＳＴＡは、ＴＸＯＰ共有内でスケジュールドＳＴＡが交換したフレームであるかを、フレームのａｄｄｒｅｓｓフィールドに基づいて判断できる。ａｄｄｒｅｓｓフィールドは、ＲＡフィールド、ＴＡフィールド、及びＢＳＳＩＤフィールドのうち少なくともいずれか一つを含んでよい。例えば、フレームのａｄｄｒｅｓｓフィールドのうち一つのフィールドがＳＴＡのＭＡＣアドレスを指示する場合に、ＳＴＡは、ＴＸＯＰ共有内でスケジュールドＳＴＡが交換したフレームであると判断できる。また、ＳＴＡは、ＴＸＯＰ共有内でスケジュールドＳＴＡが交換したフレームであるかを、フレームを含むＰＰＤＵのプリアンブルに基づいて判断できる。また、ＳＴＡは、ＴＸＯＰ共有内でスケジュールドＳＴＡが交換したフレームであるかを、フレームを含むＰＰＤＵのプリアンブルが含むＢＳＳカラー及びＳＴＡＩＤのうち少なくともいずれか一つに基づいて判断できる。ＰＰＤＵのプリアンブルがＴＸＯＰ共有のスケジュールドＳＴＡの属したＢＳＳのＢＳＳカラーを含み、ＰＰＤＵのプリアンブルがＴＸＯＰ共有のスケジュールドＳＴＡに該当するＳＴＡＩＤを含む場合に、ＳＴＡは、ＰＰＤＵが含むフレームをスケジュールドＳＴＡが交換したフレームであると判断できる。このとき、ＳＴＡＩＤは、ＳＴＡのＡＩＤに基づいて設定された値であってよい。

さらに他の具体的な実施例において、ＴＸＯＰ共有を設定したＳＴＡがＮＡＶに関係なく送信することは、フレームを送信する時にＣＳ（ｃａｒｒｉｅｒｓｅｎｓｉｎｇ）として物理的（ｐｈｙｓｉｃａｌ）ＣＳ、例えばＣＣＡのみを用いることができる。したがって、ＳＴＡは仮想（ｖｉｒｔｕａｌ）ＣＳを行わなくてよい。

本明細書において、ＮＡＶを設定することは、ＮＡＶをアップデートすることと相互交換的に使われてよい。また、本明細書において、ＮＡＶはＩｎｔｒａ－ＢＳＳＮＡＶ又はベーシックＮＡＶのうち少なくともいずれか一つを含んでよい。また、ＮＡＶの種類に対して特に言及がない場合、ＮＡＶはＩｎｔｒａ－ＢＳＳＮＡＶのことを指してよい。また、本明細書において、ＳＴＡがいずれかのフレームに基づいてＮＡＶを設定することは、フレームを含むＰＰＤＵに基づいてＮＡＶを設定することを含んでよい。したがって、本明細書において、ＳＴＡがいずれかのフレームに基づいてＮＡＶを設定しないことは、フレームを含むＰＰＤＵに基づいてＮＡＶを設定しないことを含んでよい。

ＴＸＯＰ共有を設定するためのＭＵ－ＲＴＳフレームは、ＭＡＣアドレス、例えば、ＲＡフィールド又はＵｓｅｒＩｎｆｏフィールドを用いてＴＸＯＰのスケジュールドＳＴＡを指示できる。フレームやＰＰＤＵのデュレーション情報に基づいてＮＡＶを設定することは、直近に設定したＮＡＶがフレームやＰＰＤＵのデュレーション情報に基づいてＮＡＶが設定されることを表すことができる。

さらに他の具体的な実施例において、共有されたＴＸＯＰ内で送信されるフレームのＤｕｒａｔｉｏｎ／ＩＤフィールド又はフレームを含むＰＰＤＵのＴＸＯＰは、共有されたＴＸＯＰに基づいて設定されてよい。具体的には、共有されたＴＸＯＰ内で送信されるフレームのＤｕｒａｔｉｏｎ／ＩＤフィールド又はフレームを含むＰＰＤＵのＴＸＯＰは、共有されたＴＸＯＰを超えて設定されることが許容されなくてよい。これにより、共有されたＴＸＯＰを設定したＳＴＡが共有されたＴＸＯＰの終了後にもフレームを送信できない問題を防止することができる。

すなわち、ＡＰによって設定されたＴＸＯＰがトリガーフレームによってＳＴＡに共有される場合に、共有されたＴＸＯＰ内で送信されるフレーム（例えば、ＰＰＤＵ）に含まれるデュレーション情報（例えば、Ｄｕｒａｔｉｏｎ／ＩＤフィールド）は、共有されたＴＸＯＰに基づいて設定されてよい。具体的には、共有されたＴＸＯＰ内で送信されるフレームのＴＸＯＰは、共有されたＴＸＯＰを超えて設定されることが許容されない。したがって、共有されたＴＸＯＰ内でＴＸＯＰを設定したＡＰ又はＰ２Ｐ通信のための第３ＳＴＡに送信されるＰＰＤＵのＴＸＯＰは、共有されたＴＸＯＰと同一であるか、より以前に終了しなければならない。したがって、ＰＰＤＵに含まれるデュレーション情報によって指示されるデュレーションの終了時点は、共有されたＴＸＯＰの終了時点と同一であるか、以前であってよい。言い換えると、ＡＰによって設定されたＴＸＯＰの一部又は全部が特定ＳＴＡに共有された場合に、特定ＳＴＡによって送信されるＰＰＤＵのＴＸＯＰは、共有されたＴＸＯＰを超えてはならず、以前に満了しなければならない。したがって、特定ＳＴＡによってＡＰ又はＰ２Ｐ通信のために第３ＳＴＡに送信されるＰＰＤＵの長さ（又は、ＴＸＯＰ）の終了時点は、共有されたＴＸＯＰの終了時点の以後であってはならず、以前でなければならない。この場合、ＰＰＤＵの長さ（又は、ＴＸＯＰ）の終了時点は、共有されたＴＸＯＰの終了時点と同一であるか、以前でなければならず、よって、ＰＰＤＵに含まれるデュレーション情報によって指示される値は、共有されたＴＸＯＰに基づいて設定されてよい。

さらに他の具体的な実施例において、共有されたＴＸＯＰを設定したＳＴＡは、ＴＸＯＰ共有のスケジュールドＳＴＡが交換するフレームに基づいてＮＡＶを設定しなくてよい。

共有されたＴＸＯＰ内で共有されたＴＸＯＰを設定したＳＴＡは、トリガーフレームを送信しなくてよい。共有されたＴＸＯＰ内で共有されたＴＸＯＰを設定したＳＴＡがトリガーフレームを送信する場合に、トリガーフレームによってトリガーされたフレームとスケジュールドＳＴＡのフレーム交換とがオーバーラップすることがあるためである。また、共有されたＴＸＯＰ内で共有されたＴＸＯＰを設定したＳＴＡがスケジュールドＳＴＡにトリガーフレームを送信する場合に、スケジュールドＳＴＡは、トリガーフレームに対する応答を送信しなければならないことがある。したがって、これは、共有されたＴＸＯＰを設定した目的に符合しないことがある。このような実施例において、トリガーフレームは、ＴＸＯＰ共有を設定するためのＭＵ－ＲＴＳフレームを含んでよい。このような実施例において、共有されたＴＸＯＰが終了した後、共有されたＴＸＯＰを設定したＳＴＡはトリガーフレームを送信できる。

前述した実施例において、共有されたＴＸＯＰを設定したＳＴＡが送信できないトリガーフレームは、ＴＸＯＰ共有のスケジュールドＳＴＡのみへのトリガーフレーム以外の残りトリガーフレームであってよい。したがって、共有されたＴＸＯＰを設定したＳＴＡは、共有されたＴＸＯＰ内でＴＸＯＰ共有のスケジュールドＳＴＡのみにトリガーフレームを送信できる。例えば、共有されたＴＸＯＰを設定したＳＴＡは、共有されたＴＸＯＰを延長するために、ＴＸＯＰ共有を設定するためのＭＵ－ＲＴＳフレームを送信できる。この時、ＴＸＯＰ共有を設定するためのＭＵ－ＲＴＳフレームを受信したＳＴＡは、ＣＴＳフレームを送信しないでフレーム交換を始めることができる。具体的には、ＴＸＯＰ共有においてＴＸＯＰ共有を設定したＳＴＡとのフレーム交換のみが許容される場合に、ＴＸＯＰ共有を設定するためのＭＵ－ＲＴＳフレームを受信したＳＴＡは、ＣＴＳフレームを送信しないでフレーム交換を始めることができる。

本明細書において、共有されたＴＸＯＰの間に行われる動作は、ＴＸＯＰ共有のスケジュールドＳＴＡによって共有されたＴＸＯＰが活用される動作であってよい。共有されたＴＸＯＰの間に行われる動作は、ＴＸＯＰ共有のスケジュールドＳＴＡがＴＸＯＰ共有を設定するためのＭＵ－ＲＴＳフレームに対する応答としてフレームを送信すること、又はＴＸＯＰ共有のスケジュールドＳＴＡが共有されたＴＸＯＰ内でフレームを送信することであってよい。このとき、ＴＸＯＰ共有を設定するためのＭＵ－ＲＴＳフレームに対する応答フレームは、ＣＴＳフレームであってよい。

ＴＸＯＰ共有動作のためのシグナリングについて説明する。ＳＴＡは、ＴＸＯＰ共有のスケジュールドＳＴＡとして動作できるか否かをシグナルすることができる。この時、ＳＴＡは、ＥＨＴＣａｐａｂｉｌｉｔｉｅｓエレメントを用いて、ＴＸＯＰ共有のスケジュールドＳＴＡとして動作できるかをシグナルすることができる。また、ＳＴＡは、ＴＸＯＰ共有のスケジュールドＳＴＡとして動作できるかを示すシグナリングを（再）連結要請フレーム又はプローブ要請フレームを用いて送信できる。ＴＸＯＰ共有を設定しようとするＳＴＡは、ＴＸＯＰ共有のスケジュールドＳＴＡとして動作できることをシグナルしたＳＴＡにのみ、ＴＸＯＰ共有を設定するためのＭＵ－ＲＴＳフレームを送信できる。また、ＴＸＯＰ共有を設定しようとするＳＴＡは、ＴＸＯＰ共有のスケジュールドＳＴＡとして動作できないことをシグナルしたＳＴＡに、ＴＸＯＰ共有を設定するためのＭＵ－ＲＴＳフレームを送信できなくてよい。

また、ＭＵ－ＲＴＳフレームは、ＭＵ－ＲＴＳフレームがＴＸＯＰ共有を設定するためのＭＵ－ＲＴＳフレームであるか否かを指示する情報を含んでよい。また、ＭＵ－ＲＴＳフレームがＴＸＯＰ共有を設定するためのＭＵ－ＲＴＳフレームである場合に、ＭＵ－ＲＴＳフレームは、ＴＸＯＰ共有のモードも指示することができる。ＴＸＯＰ共有のモードは、ＴＸＯＰ共有のスケジュールドＳＴＡがどのＳＴＡにフレームを送信できるかを指示できる。例えば、第１モードで、ＴＸＯＰ共有のスケジュールドＳＴＡは、ＴＸＯＰ共有を設定したＳＴＡにのみフレームを送信できる。また、第２モードで、ＴＸＯＰ共有のスケジュールドＳＴＡは、ＴＸＯＰ共有を設定したＳＴＡにフレームを送信したり又はＰ２Ｐフレームを送信できる。ＭＵ－ＲＴＳフレームがＴＸＯＰ共有を設定するためのＭＵ－ＲＴＳフレームであるか否かを指示する情報の値が１である場合に、第１モードを指示できる。また、ＭＵ－ＲＴＳフレームがＴＸＯＰ共有を設定するためのＭＵ－ＲＴＳフレームであるか否かを指示する情報の値が２である場合に、第２モードを指示できる。また、ＭＵ－ＲＴＳフレームがＴＸＯＰ共有を設定するためのＭＵ－ＲＴＳフレームであるか否かを指示する情報の値が０である場合に、ＭＵ－ＲＴＳフレームがＴＸＯＰ共有を設定するためのＭＵ－ＲＴＳフレームでないことを指示できる。

これらの実施例において、ＧＩＡｎｄＨＥ－ＬＴＦＴｙｐｅサブフィールドは、ＭＵ－ＲＴＳフレームがＴＸＯＰ共有を設定するためのＭＵ－ＲＴＳフレームであるか否かを指示できる。ＭＵ－ＲＴＳフレームがＴＸＯＰ共有を設定するためのＭＵ－ＲＴＳフレームである場合に、ＧＩＡｎｄＨＥ－ＬＴＦＴｙｐｅサブフィールドは、前述したように、ＴＸＯＰ共有のモードを指示できる。このとき、ＧＩＡｎｄＨＥ－ＬＴＦＴｙｐｅサブフィールドは、ＴＸＯＰＳｈａｒｉｎｇＭｏｄｅサブフィールドと呼ぶことができる。ＴＸＯＰＳｈａｒｉｎｇＭｏｄｅサブフィールドは、図１６のＣｏｍｍｏｎＩｎｆｏフィールドの２１番目のビット（Ｂ２０）から２２番目のビット（Ｂ２１）のサブフィールドであってよい。

ＴＸＯＰ共有を終了する方法については図２８を用いて説明する。

図２８は、本発明の一実施例によってＳＴＡがＴＸＯＰの共有を終了することを示す図である。

ＴＸＯＰ共有のスケジュールドＳＴＡは、ＴＸＯＰ共有の終了をシグナルすることができる。ＴＸＯＰ共有を設定したＳＴＡがＴＸＯＰ共有の終了シグナリングを受信した場合に、ＴＸＯＰ共有を設定したＳＴＡはＴＸＯＰホルダーになり得る。また、ＴＸＯＰ共有を設定したＳＴＡがＴＸＯＰ共有の終了シグナリングを受信した場合に、ＴＸＯＰ共有を設定したＳＴＡはフレーム又はＰＰＤＵを送信できる。具体的には、ＴＸＯＰ共有を設定したＳＴＡがＴＸＯＰ共有の終了シグナリングを受信した場合に、共有されたＴＸＯＰ内であっても、ＴＸＯＰ共有を設定したＳＴＡはフレーム又はＰＰＤＵを送信できる。また、ＴＸＯＰ共有のスケジュールドＳＴＡがＴＸＯＰ共有の終了をシグナルした場合に、ＴＸＯＰ共有のスケジュールドＳＴＡは、残っている共有されたＴＸＯＰ内でいかなるフレームやＰＰＤＵも送信できなくてよい。

ＴＸＯＰ共有のスケジュールドＳＴＡは、Ａ－Ｃｏｎｔｒｏｌサブフィールドを用いてＴＸＯＰ共有の終了をシグナルすることができる。具体的には、Ａ－ＣｏｎｔｒｏｌサブフィールドのＳＲＳ（ｓｉｎｇｌｅｒｅｓｐｏｎｓｅｓｃｈｅｄｕｌｉｎｇ）Ｃｏｎｔｒｏｌサブフィールドは、ＴＸＯＰ共有の終了をシグナルすることができる。ＳＲＳＣｏｎｔｒｏｌサブフィールドを受信したＳＴＡは、ＳＲＳＣｏｎｔｒｏｌサブフィールドを含むフレームに、ＴＢＰＰＤＵでないＰＰＤＵで応答することができる。また、ＳＲＳＣｏｎｔｒｏｌサブフィールドを含むフレームに対する応答ＰＰＤＵの長さは、ＳＲＳＣｏｎｔｒｏｌサブフィールドに基づいて決定されてよい。具体的には、ＳＲＳＣｏｎｔｒｏｌサブフィールドを受信したＳＴＡは、ＳＲＳＣｏｎｔｒｏｌサブフィールドを含むフレームに対する応答ＰＰＤＵの長さをＳＲＳＣｏｎｔｒｏｌサブフィールドが指示する長さに設定できる。

図２８（ａ）は、ＳＲＳＣｏｎｔｒｏｌサブフィールドのフォーマットを示す。前述したように、ＳＲＳＣｏｎｔｒｏｌサブフィールドは、ＳＲＳＣｏｎｔｒｏｌサブフィールドを含むＭＡＣフレームに対する応答であるＰＰＤＵの長さを指示するフィールドを含んでよい。このとき、フィールドは、ＰＰＤＵＲｅｓｐｏｎｓｅＤｕｒａｔｉｏｎフィールドと呼ぶことができる。ＰＰＤＵＲｅｓｐｏｎｓｅＤｕｒａｔｉｏｎフィールドは、４ｕｓ単位で時間を指示できる。ＰＰＤＵＲｅｓｐｏｎｓｅＤｕｒａｔｉｏｎフィールドが指示するＰＰＤＵの長さは、ＰＰＤＵＲｅｓｐｏｎｓｅＤｕｒａｔｉｏｎフィールドの値×４ｕｓであってよい。また、ＰＰＤＵＲｅｓｐｏｎｓｅＤｕｒａｔｉｏｎフィールドは、８ビットフィールドであってよい。

また、ＳＴＡは、ＳＲＳＣｏｎｔｒｏｌサブフィールドに対する能力（ｃａｐａｂｉｌｉｔｙ）をシグナルすることができる。具体的には、ＳＴＡは、ＳＲＳＣｏｎｔｒｏｌサブフィールドを受信できるか否かをシグナルすることができる。また、ＳＴＡは、ＳＲＳＣｏｎｔｒｏｌサブフィールドを含むフレームに応答できるか否かをシグナルすることができる。ＳＴＡは、ＳＲＳＣｏｎｔｒｏｌサブフィールドに対する動作を支援しないことをシグナルしたＳＴＡにＳＲＳＣｏｎｔｒｏｌサブフィールドを送信できない。ＳＴＡは、ＳＲＳＣｏｎｔｒｏｌサブフィールドに対する動作を支援することをシグナルしたＳＴＡにＳＲＳＣｏｎｔｒｏｌサブフィールドを送信できる。

また、ＳＲＳＣｏｎｔｒｏｌフィールドは、ＴＸＯＰ共有の終了をシグナルするフィールドを含んでよい。ＴＸＯＰ共有の終了をシグナルするフィールドは、ＳｈａｒｅｄＴＸＯＰＴｅｒｍｉｎａｔｉｏｎフィールドと呼ぶことができる。ＳｈａｒｅｄＴＸＯＰＴｅｒｍｉｎａｔｉｏｎフィールドは、１ビットフィールドであってよい。ＳｈａｒｅｄＴＸＯＰＴｅｒｍｉｎａｔｉｏｎフィールドの値が１である場合に、ＳｈａｒｅｄＴＸＯＰＴｅｒｍｉｎａｔｉｏｎフィールドは、ＴＸＯＰ共有が終了することを示すことができる。ＳｈａｒｅｄＴＸＯＰＴｅｒｍｉｎａｔｉｏｎフィールドの値が０である場合に、ＳｈａｒｅｄＴＸＯＰＴｅｒｍｉｎａｔｉｏｎフィールドは、ＴＸＯＰ共有が終了しないことを示すことができる。ＳＴＡがＳｈａｒｅｄＴＸＯＰＴｅｒｍｉｎａｔｉｏｎフィールドの値が１であるＱｏＳＤａｔａフレーム又はＱｏＳＮｕｌｌフレームを受信した場合に、ＳＴＡは、ＴＸＯＰ共有が終了すると判断できる。

さらに他の具体的な実施例において、あらかじめ指定された設定を有するフレームがＴＸＯＰ共有の終了をシグナルすることができる。このとき、あらかじめ指定された設定を有するフレームは、ＱｏｓＮｕｌｌフレームであってよい。具体的には、あらかじめ指定された設定を有するフレームは、Ａ－Ｃｏｎｔｒｏｌサブフィールドを含まないＱｏＳＮｕｌｌフレームであってよい。また、あらかじめ指定された設定を有するフレームは、ＳＲＳＣｏｎｔｒｏｌサブフィールドを含まないＱｏＳＮｕｌｌフレームであってよい。ＴＸＯＰ共有のスケジュールドＳＴＡは、あらかじめ指定された設定を有するフレームを送信してＴＸＯＰ共有の終了をシグナルすることができる。また、ＴＸＯＰ共有を設定したＳＴＡがあらかじめ指定された設定を有するフレームを受信した場合に、ＴＸＯＰ共有を設定したＳＴＡは、ＴＸＯＰ共有が終了すると判断できる。

ＴＸＯＰ共有のスケジュールドＳＴＡがＴＸＯＰ共有の終了シグナリングを送信したが、ＴＸＯＰ共有を設定したＳＴＡはシグナリングを受信できないことがある。このとき、ＴＸＯＰ共有のスケジュールドＳＴＡは、ＴＸＯＰ共有が終了したと判断し、フレームを送信しなくてよい。また、ＴＸＯＰ共有を設定したＳＴＡは、ＴＸＯＰ共有が終了していないと判断し、フレームを送信しなくてよい。

具体的な実施例において、ＴＸＯＰ共有の終了をシグナルしたＴＸＯＰ共有のスケジュールドＳＴＡがシグナリングに対する応答を受信した場合に、ＴＸＯＰ共有のスケジュールドＳＴＡは、ＴＸＯＰ共有が終了したと判断できる。この時、ＴＸＯＰ共有のスケジュールドＳＴＡは、ＴＸＯＰ共有が終了したと判断し、フレームを送信しなくてよい。ＴＸＯＰ共有の終了シグナリングに対する応答は即刻の応答であってよい。また、ＴＸＯＰ共有の終了シグナリングに対する応答はＡＣＫであってよい。ただし、このような実施例は、ＴＸＯＰ共有の終了シグナリングのＡｃｋ政策（Ｐｏｌｉｃｙ）が即刻の応答を要求するように設定された場合にのみ適用されてよい。具体的には、ＴＸＯＰ共有の終了シグナリングのＡｃｋ政策（Ｐｏｌｉｃｙ）が即刻の応答を要求する場合に、ＴＸＯＰ共有の終了をシグナルしたＴＸＯＰ共有のスケジュールドＳＴＡがシグナリングに対する応答を受信すると、ＴＸＯＰ共有のスケジュールドＳＴＡは、ＴＸＯＰ共有が終了したと判断できる。ＴＸＯＰ共有の終了シグナリングのＡｃｋ政策（Ｐｏｌｉｃｙ）が即刻の応答を要求しない場合に、例えば、ＮｏＡＣＫ、ＴＸＯＰ共有の終了をシグナルしたＴＸＯＰ共有のスケジュールドＳＴＡがシグナリングに対する応答を受信しなくても、ＴＸＯＰ共有のスケジュールドＳＴＡは、ＴＸＯＰ共有が終了したと判断できる。この時、ＴＸＯＰ共有のスケジュールドＳＴＡは、ＴＸＯＰ共有の終了シグナリングを送信すると、ＴＸＯＰ共有が終了したと判断できる。また、ＴＸＯＰ共有の終了シグナリング送信に失敗した場合に、エラー回復（ｒｅｃｏｖｅｒｙ）動作が行われてよい。具体的には、ＴＸＯＰ共有のスケジュールドＳＴＡは、エラー回復（ｒｅｃｏｖｅｒｙ）動作を行うことができる。また、ＴＸＯＰ共有を設定したＳＴＡは、エラー回復（ｒｅｃｏｖｅｒｙ）動作を行うことができる。

図２８（ｂ）において、第１ＳＴＡ（ＳＴＡ１）は第２ＳＴＡ（ＳＴＡ２）にＴＸＯＰ共有設定のためのＭＵ－ＲＴＳフレームを送信する。このとき、第１ＳＴＡ（ＳＴＡ１）はＡＰであってよい。第２ＳＴＡ（ＳＴＡ２）は、ＴＸＯＰ共有設定のためのＭＵ－ＲＴＳフレームを受信し、ＴＸＯＰ共有設定のためのＭＵ－ＲＴＳフレームに対する応答としてＣＴＳフレームを送信する。共有されたＴＸＯＰ内で第２ＳＴＡ（ＳＴＡ２）は第１ＳＴＡ（ＳＴＡ１）にＴＸＯＰ共有の終了シグナリング（ＦｒａｍｅｔｏＳＴＡ１ｉｎｄｉｃａｔｉｎｇｔｅｒｍｉｎａｔｉｏｎ）を送信する。第１ＳＴＡ（ＳＴＡ１）は、ＴＸＯＰ共有の終了シグナリング（ＦｒａｍｅｔｏＳＴＡ１ｉｎｄｉｃａｔｉｎｇｔｅｒｍｉｎａｔｉｏｎ）受信に失敗する。この時、第１ＳＴＡ（ＳＴＡ１）は、ＴＸＯＰ共有が終了していないと判断する。前述したように、第１ＳＴＡ（ＳＴＡ１）又は第２ＳＴＡ（ＳＴＡ２）は、エラー回復動作を行うことができる。エラー回復動作後に、第２ＳＴＡ（ＳＴＡ２）は第１ＳＴＡ（ＳＴＡ１）にＴＸＯＰ共有の終了シグナリング（ＦｒａｍｅｔｏＳＴＡ１ｉｎｄｉｃａｔｉｎｇｔｅｒｍｉｎａｔｉｏｎ）を送信する。第１ＳＴＡ（ＳＴＡ１）は第２ＳＴＡ（ＳＴＡ２）にＴＸＯＰ共有の終了シグナリング（ＦｒａｍｅｔｏＳＴＡ１ｉｎｄｉｃａｔｉｎｇｔｅｒｍｉｎａｔｉｏｎ）に対する応答であるＡＣＫ（ＡｃｋｔｏＳＴＡ２）を送信する。ＡＣＫ（ＡｃｋｔｏＳＴＡ２）を受信した第２ＳＴＡ（ＳＴＡ２）は、ＴＸＯＰ共有が終了したと判断する。

ＴＸＯＰ共有が終了した後でも、ＴＸＯＰ共有を設定したＳＴＡが応答を指示した場合に、ＴＸＯＰ共有のスケジュールドＳＴＡはフレームを送信することができる。

前述したように、ＳＲＳＣｏｎｔｒｏｌサブフィールドに対する動作を支援しないことをシグナルしたＳＴＡにＳＲＳＣｏｎｔｒｏｌサブフィールドを送信できなくてよい。ＳＲＳＣｏｎｔｒｏｌサブフィールドでＴＸＯＰ共有の終了がシグナルされる場合に、ＳＲＳＣｏｎｔｒｏｌサブフィールドに対する動作を支援しないことをシグナルしたＳＴＡは、ＴＸＯＰ共有の終了シグナリングを受信できなくてよい。したがって、ＴＸＯＰ共有のスケジュールドＳＴＡは、ＳＲＳＣｏｎｔｒｏｌサブフィールドに対する動作を支援しないことをシグナルしたＳＴＡにも、ＴＸＯＰ共有の終了をシグナルするＳＲＳＣｏｎｔｒｏｌサブフィールドを送信できる。ＴＸＯＰ共有の終了をシグナルするＳＲＳＣｏｎｔｒｏｌサブフィールドは、ＴＸＯＰＴｅｒｍｉｎａｔｉｏｎサブフィールドの値が１であるＳＲＳＣｏｎｔｒｏｌサブフィールドであってよい。ＴＸＯＰ共有のスケジュールドＳＴＡは、ＳＲＳＣｏｎｔｒｏｌサブフィールドに対する動作を支援しないことをシグナルしたＳＴＡに、ＴＸＯＰＴｅｒｍｉｎａｔｉｏｎサブフィールドの値が０であるＳＲＳＣｏｎｔｒｏｌサブフィールドを送信できない。また、ＳＲＳＣｏｎｔｒｏｌサブフィールドに対する動作を支援しないことをシグナルしたＳＴＡに、ＳＲＳＣｏｎｔｒｏｌサブフィールドを送信できない制限は、共有されたＴＸＯＰ外でＳＲＳＣｏｎｔｒｏｌサブフィールドが送信された場合にのみ適用されてよい。

ＳＲＳＣｏｎｔｒｏｌサブフィールドがＴＸＯＰ共有の終了をシグナルする場合に、ＰＰＤＵＲｅｓｐｏｎｓｅＤｕｒａｔｉｏｎサブフィールドは、リザーブドフィールドとして設定されてよい。リザーブドフィールドの全てのビットは０に設定されてよい。ＳＲＳＣｏｎｔｒｏｌサブフィールドがＴＸＯＰ共有の終了をシグナルしない場合に、ＰＰＤＵＲｅｓｐｏｎｓｅＤｕｒａｔｉｏｎサブフィールドは、ＳＲＳＣｏｎｔｒｏｌサブフィールドを含むフレームに対する応答であるフレームを含むＰＰＤＵの長さを指示できる。

ＳＲＳＣｏｎｔｒｏｌサブフィールドがＴＸＯＰ共有の終了をシグナルする場合に、ＳＲＳＣｏｎｔｒｏｌサブフィールドを受信したＳＴＡは、ＳＲＳＣｏｎｔｒｏｌサブフィールドを含むフレームに対する応答を送信しなくてよい。さらに他の具体的な実施例において、ＳＲＳＣｏｎｔｒｏｌサブフィールドがＴＸＯＰ共有の終了をシグナルする場合に、ＳＲＳＣｏｎｔｒｏｌサブフィールドを受信したＳＴＡは、ＳＲＳＣｏｎｔｒｏｌサブフィールドを含むフレームに対する応答を、ＳＲＳＣｏｎｔｒｏｌフィールドがシグナルする情報に関係なく送信できる。この時、ＳＲＳＣｏｎｔｒｏｌサブフィールドを受信したＳＴＡは、ＳＲＳＣｏｎｔｒｏｌサブフィールドがシグナルするＳＲＳＣｏｎｔｒｏｌサブフィールドを含むフレームに対する応答ＰＰＤＵの長さに関係なく応答ＰＰＤＵを送信できる。

共有されたＴＸＯＰ内でＳＲＳＣｏｎｔｒｏｌサブフィールドを受信したＳＴＡは、ＳＲＳＣｏｎｔｒｏｌサブフィールドを含むフレームに対する応答を送信しなくてよい。さらに他の具体的な実施例において、共有されたＴＸＯＰ内でＳＲＳＣｏｎｔｒｏｌサブフィールドを受信したＳＴＡは、ＳＲＳＣｏｎｔｒｏｌサブフィールドを含むフレームに対する応答を、ＳＲＳＣｏｎｔｒｏｌフィールドがシグナルする情報に関係なく送信できる。この時、ＳＲＳＣｏｎｔｒｏｌサブフィールドを受信したＳＴＡは、ＳＲＳＣｏｎｔｒｏｌサブフィールドがシグナルするＳＲＳＣｏｎｔｒｏｌサブフィールドを含むフレームに対する応答ＰＰＤＵの長さに関係なく応答ＰＰＤＵを送信できる。

又は、ｓｈａｒｅｄＴＸＯＰ内でＳＲＳＣｏｎｔｒｏｌサブフィールドを受信するＳＴＡは、前記ＳＲＳＣｏｎｔｒｏｌサブフィールドが含むｄｕｒａｔｉｏｎ情報（ＰＰＤＵＲｅｓｐｏｎｓｅＤｕｒａｔｉｏｎサブフィールド値）に基づいて応答しなくてよい。例えば、ｓｈａｒｅｄＴＸＯＰ内でＳＲＳＣｏｎｔｒｏｌサブフィールドを受信するＳＴＡは、前記ＳＲＳＣｏｎｔｒｏｌサブフィールドが含むｄｕｒａｔｉｏｎ情報（ＰＰＤＵＲｅｓｐｏｎｓｅＤｕｒａｔｉｏｎサブフィールド値）に関係なく応答することが可能である。

本発明の一実施例によれば、ｍｏｄｉｆｉｅｄＭＵ－ＲＴＳフレームは、ＴＸＯＰ内で最初のフレームでなくてよい。例えば、ＴＸＯＰｈｏｌｄｅｒがＴＸＯＰを得るためにｍｏｄｉｆｉｅｄＭＵ－ＲＴＳフレームを送信せず、他のフレームを送信してもよい。これにより、あるＳＴＡがｍｏｄｉｆｉｅｄＭＵ－ＲＴＳフレームに基づいてＮＡＶを設定する前にＮＡＶを設定することができる。すなわち、前記ＳＴＡは、ＴＸＯＰにおいて前記ｍｏｄｉｆｉｅｄＭＵ－ＲＴＳフレームよりも先に送信されたフレームに基づいてＮＡＶを設定することができる。前述したＮＡＶｔｉｍｅｏｕｔ動作は、ＮＡＶ設定がＲＴＳフレーム又はＭＵ－ＲＴＳフレームに基づいてなされた場合に行うことが可能であるが、ＴＸＯＰにおいてｍｏｄｉｆｉｅｄＭＵ－ＲＴＳフレームよりも先にフレーム送信を存在させることにより、ＲＴＳフレーム又はＭＵ－ＲＴＳフレームに基づいてＮＡＶが設定されることを少なく発生させることができる。また、ｍｏｄｉｆｉｅｄＭＵ－ＲＴＳフレームが含むデュレーション情報はＴＸＯＰを増やせずに済む。

図２９は、本発明の一実施例に係るＳＴＡの動作の一例を示すフローチャートである。

図２９を参照すると、ＳＴＡはＡＰからＴＸＯＰの一部又は全部が共有されてよく、これに基づいて共有されたＴＸＯＰ内でＰＰＤＵを送信することができる。

具体的には、ＳＴＡはＡＰ（ＡｃｃｅｓｓＰｏｉｎｔ）から上りリンク送信を指示するトリガーフレーム（ｔｒｉｇｇｅｒｆｒａｍｅ）を受信することができる（Ｓ２９０１０）。このとき、トリガーフレームは、前記ＡＰによって取得された送信機会（ｔｒａｎｓｍｉｓｓｉｏｎｏｐｐｏｒｔｕｎｉｔｙ：ＴＸＯＰ）の一部又は全部を前記ＳＴＡに共有するために用いられてよく、ＴＸＯＰの一部又は共有のために用いられる場合に、ｍｏｄｉｆｉｅｄＭＵ－ＲＴＳフレーム又はＭＵ－ＲＴＳＴＸＳトリガーフレームと呼ぶことができる。この時、ＳＴＡは、受信されたフレームがＴＸＯＰの共有のためのフレームであるか否かを、前述したトリガーフレームのタイプフィールドから認識できる。

その後、ＳＴＡは、トリガーフレームに基づいて、前記共有されたＴＸＯＰ内で前記ＡＰ及び／又は他のＳＴＡにＰＰＤＵを送信できる（Ｓ２９０２０）。ＰＰＤＵは、前記ＰＰＤＵの送信のためのＴＸＯＰを指示するデュレーション情報を含み、前記デュレーション情報は、前記共有されたＴＸＯＰに基づいて設定されてよい。

デュレーション情報によって指示されるデュレーションの終了時点は、前記共有されたＴＸＯＰの終了時点と同一であるか、以前に終了してよい。

ＴＸＯＰ内で前記ＡＰによって送信されるフレームによってＮＡＶ（ｎｅｔｗｏｒｋａｌｌｏｃａｔｉｏｎｖｅｃｔｏｒ）が設定される場合に、前記ＰＰＤＵは、前記共有されたＴＸＯＰ内で前記設定されたＮＡＶに関係なく送信される。

さらに他のＳＴＡによって前記トリガーフレームに基づいて、前記共有されたＴＸＯＰ内でＮＡＶ及び前記ＮＡＶの終了時間を示すＮＡＶタイムアウト周期（ｔｉｍｅｏｕｔｐｅｒｉｏｄ）が設定された場合に、前記共有されたＴＸＯＰ内で前記ＮＡＶタイムアウト周期が満了しても、前記共有されたＴＸＯＰ内で前記さらに他のＳＴＡによって設定された前記ＮＡＶは、前記ＮＡＶタイムアウト周期の満了によって解除されなくてよい。

トリガーフレームは、前記トリガーフレームによる前記ＴＸＯＰの共有の有無を示すサブフィールドを含む。

前記サブフィールドが前記ＴＸＯＰの共有を示す場合に、前記サブフィールドの値は、前記共有されたＴＸＯＰ内で前記他のＳＴＡと送受信できるか否かを示す。

前記トリガーフレームは、前記トリガーフレームのタイプを示すタイプフィールドを含み、前記ＴＸＯＰの前記一部又は全部の共有は、前記タイプフィールドによる前記トリガーフレームの前記タイプによって設定される。

前述した本発明の説明は例示のためのものであり、本発明の属する技術の分野における通常の知識を有する者は、本発明の技術的思想や必須の特徴を変更することなく他の具体的な形態に容易に変形可能であるということが理解できよう。したがって、以上に述べた実施例はいかなる面においても例示的であり、限定的でないものと理解すべきである。例えば、単一型として説明されている各構成要素は、分散して実施されてもよく、同様に、分散していると説明されている構成要素も、結合した形態で実施されてよい。

本発明の範囲は、上述した詳細な説明よりは、後述する特許請求の範囲によって示され、特許請求の範囲の意味及び範囲そしてその均等概念から導出されるあらゆる変更又は変形された形態が本発明の範囲に含まれるものとして解釈されるべきである。

１００ステーション
１１０プロセッサ
１２０通信部
１４０ユーザインタフェース部
１５０ディスプレーユニット
１６０メモリ
２１０プロセッサ
２２０通信部
２６０メモリ
３００サーバ

Claims

無線通信システムのステーション（ｓｔａｔｉｏｎ：ＳＴＡ）であって、
送受信部；及び
前記送受信部を制御するプロセッサを含み、
前記プロセッサは、
ＡＰ（ＡｃｃｅｓｓＰｏｉｎｔ）から上りリンク送信を指示するトリガーフレーム（ｔｒｉｇｇｅｒｆｒａｍｅ）を受信し、
前記トリガーフレームは、前記ＡＰによって取得された送信機会（ｔｒａｎｓｍｉｓｓｉｏｎｏｐｐｏｒｔｕｎｉｔｙ：ＴＸＯＰ）の一部又は全部を前記ＳＴＡに共有するために用いられ、
前記トリガーフレームに基づいて、前記共有されたＴＸＯＰ内で前記ＡＰ及び／又は他のＳＴＡにＰＰＤＵ（ＰｈｙｓｉｃａｌｌａｙｅｒＰｒｏｔｏｃｏｌＤａｔａＵｎｉｔ）を送信し、
前記ＰＰＤＵは、前記ＰＰＤＵの送信のためのＴＸＯＰを指示するデュレーション情報を含み、
前記デュレーション情報は、前記共有されたＴＸＯＰに基づいて設定されるＳＴＡ。
前記デュレーション情報によって指示されるデュレーションの終了時点は、前記共有されたＴＸＯＰの終了時点と同一である、請求項１に記載のＳＴＡ。
前記デュレーション情報によって指示されるデュレーションは、前記共有されたＴＸＯＰの終了時点よりも以前に終了する、請求項１に記載のＳＴＡ。
前記ＴＸＯＰ内で前記ＡＰによって送信されるフレームによってＮＡＶ（ｎｅｔｗｏｒｋａｌｌｏｃａｔｉｏｎｖｅｃｔｏｒ）が設定される場合に、前記ＰＰＤＵは、前記共有されたＴＸＯＰ内で前記設定されたＮＡＶに関係なく送信される、請求項１に記載のＳＴＡ。
さらに他のＳＴＡによって前記トリガーフレームに基づいて、前記共有されたＴＸＯＰ内でＮＡＶ及び前記ＮＡＶの終了時間を示すＮＡＶタイムアウト周期（ｔｉｍｅｏｕｔｐｅｒｉｏｄ）が設定された場合に、前記共有されたＴＸＯＰ内で前記ＮＡＶタイムアウト周期が満了しても、前記共有されたＴＸＯＰ内で前記さらに他のＳＴＡによって設定された前記ＮＡＶは、前記ＮＡＶタイムアウト周期の満了によって解除されない、請求項１に記載のＳＴＡ。
前記トリガーフレームは、前記トリガーフレームによる前記ＴＸＯＰの共有の有無を示すサブフィールドを含む、請求項１に記載のＳＴＡ。
前記サブフィールドが前記ＴＸＯＰの共有を示す場合に、前記サブフィールドの値は、前記共有されたＴＸＯＰ内で前記他のＳＴＡと送受信可能であるか否かを示す、請求項６に記載のＳＴＡ。
前記トリガーフレームは、前記トリガーフレームのタイプを示すタイプフィールドを含み、
前記ＴＸＯＰの前記一部又は全部の共有は、前記タイプフィールドによる前記トリガーフレームの前記タイプによって設定される、請求項１に記載のＳＴＡ。
無線通信システムにおいてステーション（ｓｔａｔｉｏｎ：ＳＴＡ）がフレームを送信する方法であって、
ＡＰ（ＡｃｃｅｓｓＰｏｉｎｔ）から上りリンク送信を指示するトリガーフレーム（ｔｒｉｇｇｅｒｆｒａｍｅ）を受信する段階であって、前記トリガーフレームは、前記ＡＰによって取得された送信機会（ｔｒａｎｓｍｉｓｓｉｏｎｏｐｐｏｒｔｕｎｉｔｙ：ＴＸＯＰ）の一部又は全部を前記ＳＴＡに共有するために用いることができる、段階；及び、
前記トリガーフレームに基づいて、前記共有されたＴＸＯＰ内で前記ＡＰ及び／又は他のＳＴＡにＰＰＤＵ（ＰｈｙｓｉｃａｌｌａｙｅｒＰｒｏｔｏｃｏｌＤａｔａＵｎｉｔ）を送信する段階であって、前記ＰＰＤＵは、前記ＰＰＤＵの送信のためのＴＸＯＰを指示するデュレーション情報を含み、前記デュレーション情報は、前記共有されたＴＸＯＰに基づいて設定される、段階；を含む方法。
前記デュレーション情報によって指示されるデュレーションの終了時点は、前記共有されたＴＸＯＰの終了時点と同一である、請求項９に記載の方法。
前記デュレーション情報によって指示されるデュレーションは、前記共有されたＴＸＯＰの終了時点よりも以前に終了する、請求項９に記載の方法。
前記ＴＸＯＰ内で前記ＡＰによって送信されるフレームによってＮＡＶ（ｎｅｔｗｏｒｋａｌｌｏｃａｔｉｏｎｖｅｃｔｏｒ）が設定される場合に、前記ＰＰＤＵは、前記共有されたＴＸＯＰ内で前記設定されたＮＡＶに関係なく送信される、請求項９に記載の方法。
さらに他のＳＴＡによって前記トリガーフレームに基づいて、前記共有されたＴＸＯＰ内でＮＡＶ及び前記ＮＡＶの終了時間を示すＮＡＶタイムアウト周期（ｔｉｍｅｏｕｔｐｅｒｉｏｄ）が設定された場合に、前記共有されたＴＸＯＰ内で前記ＮＡＶタイムアウト周期が満了しても、前記共有されたＴＸＯＰ内で前記さらに他のＳＴＡによって設定された前記ＮＡＶは、前記ＮＡＶタイムアウト周期の満了によって解除されない、請求項９に記載の方法。
前記トリガーフレームは、前記トリガーフレームによる前記ＴＸＯＰの共有の有無を示すサブフィールドを含む、請求項９に記載の方法。
前記サブフィールドが前記ＴＸＯＰの共有を示す場合に、前記サブフィールドの値は、前記共有されたＴＸＯＰ内で前記他のＳＴＡと送受信可能であるか否かを示す、請求項１４に記載の方法。
前記トリガーフレームは、前記トリガーフレームのタイプを示すタイプフィールドを含み、
前記ＴＸＯＰの前記一部又は全部の共有は、前記タイプフィールドによる前記トリガーフレームの前記タイプによって設定される、請求項９に記載の方法。