▶ エルジー エレクトロニクス インコーポレイティドの特許一覧
特表2024-542648無線ＬＡＮシステムにおいて制限されたターゲットウエイクタイムベースの通信実行方法及び装置
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公表特許公報(A)
(11)【公表番号】
(43)【公表日】2024-11-15
(54)【発明の名称】無線ＬＡＮシステムにおいて制限されたターゲットウエイクタイムベースの通信実行方法及び装置
(51)【国際特許分類】
H04W 52/02 20090101AFI20241108BHJP
H04W 84/12 20090101ALI20241108BHJP
H04W 72/0446 20230101ALI20241108BHJP
【ＦＩ】
H04W52/02 111
H04W84/12
H04W72/0446
【審査請求】有
【予備審査請求】未請求
(21)【出願番号】P 2024532244
(86)(22)【出願日】2023-03-08
(85)【翻訳文提出日】2024-05-29
(86)【国際出願番号】 KR2023003186
(87)【国際公開番号】W WO2023172068
(87)【国際公開日】2023-09-14
(31)【優先権主張番号】10-2022-0029623
(32)【優先日】2022-03-08
(33)【優先権主張国・地域又は機関】KR
(31)【優先権主張番号】10-2022-0032850
(32)【優先日】2022-03-16
(33)【優先権主張国・地域又は機関】KR
(81)【指定国・地域】
(71)【出願人】
【識別番号】502032105
【氏名又は名称】エルジー エレクトロニクス インコーポレイティド
【氏名又は名称原語表記】ＬＧ ＥＬＥＣＴＲＯＮＩＣＳ ＩＮＣ．
【住所又は居所原語表記】１２８， Ｙｅｏｕｉ－ｄａｅｒｏ， Ｙｅｏｎｇｄｅｕｎｇｐｏ－ｇｕ， ０７３３６ Ｓｅｏｕｌ，Ｒｅｐｕｂｌｉｃ ｏｆ Ｋｏｒｅａ
(74)【代理人】
【識別番号】100099759
【弁理士】
【氏名又は名称】青木 篤
(74)【代理人】
【識別番号】100123582
【弁理士】
【氏名又は名称】三橋 真二
(74)【代理人】
【識別番号】100165191
【弁理士】
【氏名又は名称】河合 章
(74)【代理人】
【識別番号】100114018
【弁理士】
【氏名又は名称】南山 知広
(74)【代理人】
【識別番号】100159259
【弁理士】
【氏名又は名称】竹本 実
(72)【発明者】
【氏名】ペク ソンヒ
(72)【発明者】
【氏名】チャン インソン
(72)【発明者】
【氏名】チェ チンス
(72)【発明者】
【氏名】キム チーン
【テーマコード（参考）】
5K067
【Ｆターム（参考）】
5K067AA43
5K067EE02
5K067EE10
(57)【要約】
無線ＬＡＮシステムにおいて通信を行うための方法及び装置が開示される。無線ＬＡＮシステムにおいて第１ステーション（ＳＴＡ）によって通信を行う方法は、制限されたターゲットウエイクタイム（ｒｅｓｔｒｉｃｔｅｄ ｔａｒｇｅｔ ｗａｋｅ ｔｉｍｅ，ｒ－ＴＷＴ）メンバーシップセットアップ手順を第２ＳＴＡと行う段階と、ブロードキャスト（ｂｒｏａｄｃａｓｔ）ＴＷＴ要素（ｅｌｅｍｅｎｔ）に含まれたｒ－ＴＷＴスケジュール情報を第２ＳＴＡから受信する段階と、を含み、前記ｒ－ＴＷＴスケジュール情報によって公知されたｒ－ＴＷＴ ＳＰ（ｓｅｒｖｉｃｅ ｐｅｒｉｏｄ）内の第１ＴＸＯＰ（ｔｒａｎｓｍｉｓｓｉｏｎ ｏｐｐｏｒｔｕｎｉｔｙ）の特定部分が、少なくとも１つのｒ－ＴＷＴ下りリンク（ｄｏｗｎｌｉｎｋ，ＤＬ）トラフィック識別（ｔｒａｆｆｉｃ ｉｄｅｎｔｉｆｉｅｒ，ＴＩＤ）に対応するＤＬフレームの伝達又は少なくとも１つのｒ－ＴＷＴ上りリンク（ｕｐｌｉｎｋ，ＵＬ）ＴＩＤに対応するＵＬフレームの要請に用いられないことに基づいて、前記第１ＴＸＯＰは前記ｒ－ＴＷＴ ＳＰの開始時間前に終了してよい。
【選択図】図２０
【選択図】図２０
【特許請求の範囲】
【請求項1】
無線ＬＡＮシステムにおいて第１ステーション（ＳＴＡ）によって通信を行う方法であって、制限されたターゲットウエイクタイム（ｒｅｓｔｒｉｃｔｅｄ ｔａｒｇｅｔ ｗａｋｅ ｔｉｍｅ，ｒ－ＴＷＴ）メンバーシップセットアップ手順を第２ＳＴＡと行う段階と、
ブロードキャスト（ｂｒｏａｄｃａｓｔ）ＴＷＴ要素（ｅｌｅｍｅｎｔ）に含まれたｒ－ＴＷＴスケジュール情報を前記第２ＳＴＡから受信する段階と、を含み、
前記ｒ－ＴＷＴスケジュール情報によって公知されたｒ－ＴＷＴ ＳＰ（ｓｅｒｖｉｃｅ ｐｅｒｉｏｄ）内の第１ＴＸＯＰ（ｔｒａｎｓｍｉｓｓｉｏｎ ｏｐｐｏｒｔｕｎｉｔｙ）の特定部分が、少なくとも１つのｒ－ＴＷＴ下りリンク（ｄｏｗｎｌｉｎｋ，ＤＬ）トラフィック識別（ｔｒａｆｆｉｃ ｉｄｅｎｔｉｆｉｅｒ，ＴＩＤ）に対応するＤＬフレームの伝達又は少なくとも１つのｒ－ＴＷＴ上りリンク（ｕｐｌｉｎｋ，ＵＬ）ＴＩＤに対応するＵＬフレームの要請に用いられないことに基づいて、前記第１ＴＸＯＰは前記ｒ－ＴＷＴ ＳＰの開始時間前に終了する、方法。
【請求項2】
前記第１ＴＸＯＰの特定部分が前記少なくとも１つのｒ－ＴＷＴ ＤＬ ＴＩＤに対応するＤＬフレームの伝達又は前記少なくとも１つのｒ－ＴＷＴ ＵＬ ＴＩＤに対応するＵＬフレームの要請に用いられることに基づいて、前記第１ＴＸＯＰは前記ｒ－ＴＷＴ ＳＰの開始時間後にも終了しない、請求項１に記載の方法。
【請求項3】
前記少なくとも１つのｒ－ＴＷＴ ＤＬ ＴＩＤ又は前記少なくとも１つのｒ－ＴＷＴ ＵＬ ＴＩＤが、前記第１ＳＴＡ及び前記第２ＳＴＡによって設定される、請求項１に記載の方法。
【請求項4】
前記第２ＳＴＡは、前記第１ＴＸＯＰのホルダー（ｈｏｌｄｅｒ）である、請求項１に記載の方法。
【請求項5】
前記第１ＳＴＡが第２ＴＸＯＰのホルダーであることに基づいて、前記第２ＴＸＯＰは前記ｒ－ＴＷＴ ＳＰの開始時間前に終了する、請求項１に記載の方法。
【請求項6】
前記ｒ－ＴＷＴスケジュール情報は、ビーコンフレーム又はプローブ（ｐｒｏｂｅ）応答フレームで前記第２ＳＴＡから受信される、請求項１に記載の方法。
【請求項7】
前記第１ＴＸＯＰが前記ｒ－ＴＷＴ ＳＰの開始時間後に終了しないことに基づいて、前記ｒ－ＴＷＴ ＳＰの終了時間が延期される、請求項２に記載の方法。
【請求項8】
前記第１ＳＴＡは非（ｎｏｎ）－ＡＰ（ａｃｃｅｓｓ ｐｏｉｎｔ）ＥＨＴ（ｅｘｔｒｅｍｅｌｙ ｈｉｇｈ ｔｈｒｏｕｇｈｐｕｔ）ＳＴＡであり、前記第２ＳＴＡはＡＰである、請求項１に記載の方法。
【請求項9】
無線ＬＡＮシステムにおいて通信を行う第１ステーション（ＳＴＡ）であって、前記ＳＴＡは、１つ以上の送受信機と、
前記１つ以上の送受信機と連結された１つ以上のプロセッサと、を含み、
前記１つ以上のプロセッサは、
制限されたターゲットウエイクタイム（ｒｅｓｔｒｉｃｔｅｄ ｔａｒｇｅｔ ｗａｋｅ ｔｉｍｅ，ｒ－ＴＷＴ）メンバーシップセットアップ手順を第２ＳＴＡと行い、
ブロードキャスト（ｂｒｏａｄｃａｓｔ）ＴＷＴ要素（ｅｌｅｍｅｎｔ）に含まれたｒ－ＴＷＴスケジュール情報を前記第２ＳＴＡから前記１つ以上の送受信機を介して受信する、ように設定され、
前記ｒ－ＴＷＴスケジュール情報によって公知されたｒ－ＴＷＴ ＳＰ（ｓｅｒｖｉｃｅ ｐｅｒｉｏｄ）内の第１ＴＸＯＰ（ｔｒａｎｓｍｉｓｓｉｏｎ ｏｐｐｏｒｔｕｎｉｔｙ）の特定部分が、少なくとも１つのｒ－ＴＷＴ下りリンク（ｄｏｗｎｌｉｎｋ，ＤＬ）トラフィック識別（ｔｒａｆｆｉｃ ｉｄｅｎｔｉｆｉｅｒ，ＴＩＤ）に対応するＤＬフレームの伝達又は少なくとも１つのｒ－ＴＷＴ上りリンク（ｕｐｌｉｎｋ，ＵＬ）ＴＩＤに対応するＵＬフレームの要請に用いられないことに基づいて、前記第１ＴＸＯＰは前記ｒ－ＴＷＴ ＳＰの開始時間前に終了する、第１ＳＴＡ。
【請求項10】
無線ＬＡＮシステムにおいて第２ステーション（ＳＴＡ）によって通信を行う方法であって、前記方法は、制限されたターゲットウエイクタイム（ｒｅｓｔｒｉｃｔｅｄ ｔａｒｇｅｔ ｗａｋｅ ｔｉｍｅ，ｒ－ＴＷＴ）メンバーシップセットアップ手順を第１ＳＴＡと行う段階と、
ブロードキャスト（ｂｒｏａｄｃａｓｔ）ＴＷＴ要素（ｅｌｅｍｅｎｔ）に含まれたｒ－ＴＷＴスケジュール情報を第１ＳＴＡに送信する段階と、を含み、
前記ｒ－ＴＷＴスケジュール情報によって公知されたｒ－ＴＷＴ ＳＰ（ｓｅｒｖｉｃｅ ｐｅｒｉｏｄ）内の第１ＴＸＯＰ（ｔｒａｎｓｍｉｓｓｉｏｎ ｏｐｐｏｒｔｕｎｉｔｙ）の特定部分が、少なくとも１つのｒ－ＴＷＴ下りリンク（ｄｏｗｎｌｉｎｋ，ＤＬ）トラフィック識別（ｔｒａｆｆｉｃ ｉｄｅｎｔｉｆｉｅｒ，ＴＩＤ）に対応するＤＬフレームの伝達又は少なくとも１つのｒ－ＴＷＴ上りリンク（ｕｐｌｉｎｋ，ＵＬ）ＴＩＤに対応するＵＬフレームの要請に用いられないことに基づいて、前記第１ＴＸＯＰは前記ｒ－ＴＷＴ ＳＰの開始時間前に終了する、方法。
【請求項11】
無線ＬＡＮシステムにおいて通信を行う第２ステーション（ＳＴＡ）であって、前記第２ＳＴＡは、１つ以上の送受信機と、
前記１つ以上の送受信機と連結された１つ以上のプロセッサと、を含み、
前記１つ以上のプロセッサは、
制限されたターゲットウエイクタイム（ｒｅｓｔｒｉｃｔｅｄ ｔａｒｇｅｔ ｗａｋｅ ｔｉｍｅ，ｒ－ＴＷＴ）メンバーシップセットアップ手順を第１ＳＴＡと行い、
ブロードキャスト（ｂｒｏａｄｃａｓｔ）ＴＷＴ要素（ｅｌｅｍｅｎｔ）に含まれたｒ－ＴＷＴスケジュール情報を第１ＳＴＡに前記１つ以上の送受信機を介して送信する、ように設定され、
前記ｒ－ＴＷＴスケジュール情報によって公知されたｒ－ＴＷＴ ＳＰ（ｓｅｒｖｉｃｅ ｐｅｒｉｏｄ）内の第１ＴＸＯＰ（ｔｒａｎｓｍｉｓｓｉｏｎ ｏｐｐｏｒｔｕｎｉｔｙ）の特定部分が、少なくとも１つのｒ－ＴＷＴ下りリンク（ｄｏｗｎｌｉｎｋ，ＤＬ）トラフィック識別（ｔｒａｆｆｉｃ ｉｄｅｎｔｉｆｉｅｒ，ＴＩＤ）に対応するＤＬフレームの伝達又は少なくとも１つのｒ－ＴＷＴ上りリンク（ｕｐｌｉｎｋ，ＵＬ）ＴＩＤに対応するＵＬフレームの要請に用いられないことに基づいて、前記第１ＴＸＯＰは前記ｒ－ＴＷＴ ＳＰの開始時間前に終了する、第２ＳＴＡ。
【請求項12】
無線ＬＡＮシステムにおいて通信を行うために第１ステーション（ＳＴＡ）を制御するように設定されるプロセシング装置であって、前記プロセシング装置は、１つ以上のプロセッサと、
前記１つ以上のプロセッサに動作可能に連結され、前記１つ以上のプロセッサによって実行されることに基づいて、動作を行う命令を保存する１つ以上のコンピュータメモリと、を含み、
前記動作は、
制限されたターゲットウエイクタイム（ｒｅｓｔｒｉｃｔｅｄ ｔａｒｇｅｔ ｗａｋｅ ｔｉｍｅ，ｒ－ＴＷＴ）メンバーシップセットアップ手順を第２ＳＴＡと行う動作と、
ブロードキャスト（ｂｒｏａｄｃａｓｔ）ＴＷＴ要素（ｅｌｅｍｅｎｔ）に含まれたｒ－ＴＷＴスケジュール情報を第２ＳＴＡから受信する動作と、を含み、
前記ｒ－ＴＷＴスケジュール情報によって公知されたｒ－ＴＷＴ ＳＰ（ｓｅｒｖｉｃｅ ｐｅｒｉｏｄ）内の第１ＴＸＯＰ（ｔｒａｎｓｍｉｓｓｉｏｎ ｏｐｐｏｒｔｕｎｉｔｙ）の特定部分が、少なくとも１つのｒ－ＴＷＴ下りリンク（ｄｏｗｎｌｉｎｋ，ＤＬ）トラフィック識別（ｔｒａｆｆｉｃ ｉｄｅｎｔｉｆｉｅｒ，ＴＩＤ）に対応するＤＬフレームの伝達又は少なくとも１つのｒ－ＴＷＴ上りリンク（ｕｐｌｉｎｋ，ＵＬ）ＴＩＤに対応するＵＬフレームの要請に用いられないことに基づいて、前記第１ＴＸＯＰは前記ｒ－ＴＷＴ ＳＰの開始時間前に終了する、プロセシング装置。
【請求項13】
１つ以上の命令を保存する１つ以上の非一時的（ｎｏｎ－ｔｒａｎｓｉｔｏｒｙ）コンピュータ可読媒体であって、前記１つ以上の命令は１つ以上のプロセッサによって実行され、無線ＬＡＮシステムにおいて通信を行う第１ステーション（ＳＴＡ）が、
制限されたターゲットウエイクタイム（ｒｅｓｔｒｉｃｔｅｄ ｔａｒｇｅｔ ｗａｋｅ ｔｉｍｅ，ｒ－ＴＷＴ）メンバーシップセットアップ手順を第２ＳＴＡと行い、
ブロードキャスト（ｂｒｏａｄｃａｓｔ）ＴＷＴ要素（ｅｌｅｍｅｎｔ）に含まれたｒ－ＴＷＴスケジュール情報を第２ＳＴＡから受信する、ように設定され、
前記ｒ－ＴＷＴスケジュール情報によって公知されたｒ－ＴＷＴ ＳＰ（ｓｅｒｖｉｃｅ ｐｅｒｉｏｄ）内の第１ＴＸＯＰ（ｔｒａｎｓｍｉｓｓｉｏｎ ｏｐｐｏｒｔｕｎｉｔｙ）の特定部分が、少なくとも１つのｒ－ＴＷＴ下りリンク（ｄｏｗｎｌｉｎｋ，ＤＬ）トラフィック識別（ｔｒａｆｆｉｃ ｉｄｅｎｔｉｆｉｅｒ，ＴＩＤ）に対応するＤＬフレームの伝達又は少なくとも１つのｒ－ＴＷＴ上りリンク（ｕｐｌｉｎｋ，ＵＬ）ＴＩＤに対応するＵＬフレームの要請に用いられないことに基づいて、前記第１ＴＸＯＰは前記ｒ－ＴＷＴ ＳＰの開始時間前に終了する、コンピュータ可読媒体。
【発明の詳細な説明】
【技術分野】
【0001】
本開示は、無線ＬＡＮ（Ｗｉｒｅｌｅｓｓ Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ，ＷＬＡＮ）システムにおける通信実行方法及び装置に関し、より詳細には、次世代無線ＬＡＮシステムにおける制限された（ｒｅｓｔｒｉｃｔｅｄ）ターゲットウエイクタイム（ｔａｒｇｅｔ ｗａｋｅ ｔｉｍｅ，ＴＷＴ）ベースの通信実行方法及び装置に関する。
【背景技術】
【0002】
無線ＬＡＮ（ＷＬＡＮ）に対して伝送レート向上、帯域幅増加、信頼性向上、エラー減少、レイテンシー減少などのための新しい技術が導入されてきている。無線ＬＡＮ技術の中で、ＩＥＥＥ（Ｉｎｓｔｉｔｕｔｅ ｏｆ Ｅｌｅｃｔｒｉｃａｌ ａｎｄ Ｅｌｅｃｔｒｏｎｉｃｓ Ｅｎｇｉｎｅｅｒｓ）８０２．１１系列の標準を、Ｗｉ－Ｆｉ（登録商標）と称することができる。例えば、最近に無線ＬＡＮに導入された技術は、８０２．１１ａｃ標準のＶＨＴ（Ｖｅｒｙ Ｈｉｇｈ－Ｔｈｒｏｕｇｈｐｕｔ）のための改善事項（ｅｎｈａｎｃｅｍｅｎｔ）、ＩＥＥＥ ８０２．１１ａｘ標準のＨＥ（Ｈｉｇｈ Ｅｆｆｉｃｉｅｎｃｙ）のための改善事項などを含む。
【0003】
より向上した無線通信環境を提供するために、ＥＨＴ（Ｅｘｔｒｅｍｅｌｙ Ｈｉｇｈ Ｔｈｒｏｕｇｈｐｕｔ）のための改善技術が論議されている。例えば、増加した帯域幅、多重帯域の効率的活用、増加した空間ストリームを支援するＭＩＭＯ（Ｍｕｌｔｉｐｌｅ Ｉｎｐｕｔ Ｍｕｌｔｉｐｌｅ Ｏｕｔｐｕｔ）、多重アクセスポイント（ＡＰ）調整のための技術が研究されており、特に、低いレイテンシー（ｌｏｗ ｌａｔｅｎｃｙ）又は実時間（ｒｅａｌ ｔｉｍｅ）特性のトラフィックを支援するための様々な技術が研究されている。
【発明の概要】
【発明が解決しようとする課題】
【0004】
本開示の技術的課題は、無線ＬＡＮシステムにおいてレイテンシー敏感（ｌａｔｅｎｃｙ ｓｅｎｓｉｔｉｖｅ）データ／トラフィックを送信するための方法及び装置を提供することである。
【0005】
本開示の更なる技術的課題は、無線ＬＡＮシステムにおいて条件付きｒ－ＴＷＴ ＳＰ（ｓｅｒｖｉｃｅ ｐｅｒｉｏｄ） ＴＸＯＰ規則を実行する方法及び装置を提供することである。
【0006】
本開示で遂げようとする技術的課題は、以上で言及した技術的課題に限定されず、言及していない別の技術的課題は、以下の記載から、本開示の属する技術の分野における通常の知識を有する者に明確に理解されるであろう。
【課題を解決するための手段】
【0007】
本開示の一態様に係る無線ＬＡＮシステムにおいて第１ＳＴＡによって通信を行う方法は、制限されたターゲットウエイクタイム（ｒｅｓｔｒｉｃｔｅｄ ｔａｒｇｅｔ ｗａｋｅ ｔｉｍｅ，ｒ－ＴＷＴ）メンバーシップセットアップ手順を第２ＳＴＡと行う段階と、ブロードキャスト（ｂｒｏａｄｃａｓｔ）ＴＷＴ要素（ｅｌｅｍｅｎｔ）に含まれたｒ－ＴＷＴスケジュール情報を第２ＳＴＡから受信する段階と、を含み、前記ｒ－ＴＷＴスケジュール情報によって公知されたｒ－ＴＷＴ ＳＰ（ｓｅｒｖｉｃｅ ｐｅｒｉｏｄ）内の第１ＴＸＯＰ（ｔｒａｎｓｍｉｓｓｉｏｎ ｏｐｐｏｒｔｕｎｉｔｙ）の特定部分が、少なくとも一つのｒ－ＴＷＴ下りリンク（ｄｏｗｎｌｉｎｋ，ＤＬ）トラフィック識別（ｔｒａｆｆｉｃ ｉｄｅｎｔｉｆｉｅｒ，ＴＩＤ）に対応するＤＬフレームの伝達又は少なくとも一つのｒ－ＴＷＴ上りリンク（ｕｐｌｉｎｋ，ＵＬ）ＴＩＤに対応するＵＬフレームの要請に用いられないことに基づいて、前記第１ＴＸＯＰは前記ｒ－ＴＷＴ ＳＰの開始時間前に終了してよい。
【0008】
本開示の一態様に係る無線ＬＡＮシステムにおいて第２ＳＴＡによって通信を行う方法は、制限されたターゲットウエイクタイム（ｒｅｓｔｒｉｃｔｅｄ ｔａｒｇｅｔ ｗａｋｅ ｔｉｍｅ，ｒ－ＴＷＴ）メンバーシップセットアップ手順を第１ＳＴＡと行う段階と、ブロードキャスト（ｂｒｏａｄｃａｓｔ）ＴＷＴ要素（ｅｌｅｍｅｎｔ）に含まれたｒ－ＴＷＴスケジュール情報を第１ＳＴＡに送信する段階と、を含み、前記ｒ－ＴＷＴスケジュール情報によって公知されたｒ－ＴＷＴ ＳＰ（ｓｅｒｖｉｃｅ ｐｅｒｉｏｄ）内の第１ＴＸＯＰ（ｔｒａｎｓｍｉｓｓｉｏｎ ｏｐｐｏｒｔｕｎｉｔｙ）の特定部分が、少なくとも一つのｒ－ＴＷＴ下りリンク（ｄｏｗｎｌｉｎｋ，ＤＬ）トラフィック識別（ｔｒａｆｆｉｃ ｉｄｅｎｔｉｆｉｅｒ，ＴＩＤ）に対応するＤＬフレームの伝達又は少なくとも一つのｒ－ＴＷＴ上りリンク（ｕｐｌｉｎｋ，ＵＬ）ＴＩＤに対応するＵＬフレームの要請に用いられないことに基づいて、前記第１ＴＸＯＰは前記ｒ－ＴＷＴ ＳＰの開始時間前に終了してよい。
【発明の効果】
【0009】
本開示によれば、無線ＬＡＮシステムにおいてレイテンシー敏感（ｌａｔｅｎｃｙ ｓｅｎｓｉｔｉｖｅ）データ／トラフィックを送信するための方法及び装置を提供することができる。
【0010】
本開示によれば、無線ＬＡＮシステムにおいて条件付きｒ－ＴＷＴ ＳＰ（ｓｅｒｖｉｃｅ ｐｅｒｉｏｄ）ＴＸＯＰ規則を実行する方法及び装置を提供することができる。
【0011】
本開示によれば、ｒ－ＴＷＴ ＳＰのＴＸＯＰ規則が、目的とする予測可能な低遅延サービスの他にも、既存のデータ送受信の流れを妨害しない方式により、遅延敏感データ／トラフィック送信の効率性を高めることができる。
【0012】
本開示から得られる効果は、以上で言及した効果に限定されず、言及していない別の効果は、以下の記載から、本開示の属する技術の分野における通常の知識を有する者に明確に理解されるであろう。
【図面の簡単な説明】
【0013】
本開示に関する理解を助けるために詳細な説明の一部として含まれる添付の図面は、本開示に対する実施例を提供し、詳細な説明と一緒に本開示の技術的特徴を説明する。
【0014】
【図1】本開示の一実施例に係る無線通信装置を例示するブロック構成図である。。
【0015】
【図2】本開示の適用が可能な無線ＬＡＮシステムの例示的な構造を示す図である。
【0016】
【図3】本開示の適用が可能なリンクセットアップ（ｌｉｎｋ ｓｅｔｕｐ）過程を説明するための図である。
【0017】
【図4】本開示の適用が可能なバックオフ過程を説明するための図である。
【0018】
【図5】本開示の適用が可能なＣＳＭＡ／ＣＡベースフレーム送信動作を説明するための図である。
【0019】
【図6】本開示の適用が可能な無線ＬＡＮシステムにおいて用いられるフレーム構造の例示を説明するための図である。
【0020】
【図7】本開示の適用が可能なＩＥＥＥ ８０２．１１標準で定義されるＰＰＤＵの例示を示す図である。
【0021】
【図8-10】本開示の適用が可能な無線ＬＡＮシステムのリソースユニットの例示を説明するための図である。
【0022】
【図11】ＨＥ－ＳＩＧ－Ｂフィールドの例示的な構造を示す図である。
【0023】
【図12】複数のユーザ／ＳＴＡが１つのＲＵに割り当てられるＭＵ－ＭＩＭＯ方式を説明するための図である。
【0024】
【図13】本開示の適用が可能なＰＰＤＵフォーマットの例示を示す図である。
【0025】
【図14】本開示の適用が可能な個別ＴＷＴ動作の一例を説明するための図である。
【0026】
【図15】本開示の適用が可能なブロードキャストＴＷＴ動作の一例を説明するための図である。
【0027】
【図16】ＴＷＴ情報要素フォーマットの一例を説明するための図である。
【0028】
【図17】個別ＴＷＴパラメータセットフィールドフォーマットの例示を説明するための図である。
【0029】
【図18】ブロードキャストＴＷＴパラメータセットフィールドフォーマットの例示を説明するための図である。
【0030】
【図19】本開示の一例に係るＳＴＡの制限されたＴＷＴ動作を説明するための図である。
【0031】
【図20】本開示の一例に係る第１ＳＴＡの制限されたＴＷＴ動作を説明するための図である。
【0032】
【図21】本開示の一例に係る第２ＳＴＡの制限されたＴＷＴ動作を説明するための図である。
【0033】
【図22-25】本開示の一例に係るｒ－ＴＷＴ ＳＰの条件付きＴＸＯＰ規則が適用される過程を例示する図である。
【0034】
【図26-28】本開示の一例に係る、ＡＰがｒ－ＴＷＴに関する情報を他のＳＴＡに知らせる過程を例示する図である。
【発明を実施するための形態】
【0035】
以下、本開示に係る好ましい実施形態を、添付の図面を参照して詳細に説明する。添付の図面と共に以下に開示される詳細な説明は、本開示の例示的な実施形態を説明するためのもので、本開示の実施が可能な唯一の実施形態を示すためのものではない。以下の詳細な説明は、本開示の完全な理解を提供するために具体的細部事項を含む。ただし、当業者には、このような具体的細部事項無しにも本開示が実施可能であることが理解される。
【0036】
場合によって、本開示の概念が曖昧になることを避けるために、公知の構造及び装置が省略されてもよく、各構造及び装置の核心機能を中心にしたブロック図の形式で示されてもよい。
【0037】
本開示において、ある構成要素が他の構成要素と「連結」、「結合」又は「接続」されているするとき、これは直接の連結関係の他、それらの間にさらに他の構成要素が存在する間接的な連結関係も含んでよい。また、本開示において用語「含む」又は「有する」とは、言及された特徴、段階、動作、要素及び／又は構成要素の存在を特定するものの、１つ以上の他の特徴、段階、動作、要素、構成要素及び／又はそれらのグループの存在又は追加を排除しない。
【0038】
本開示において、「第１」、「第２」などの用語は、一つの構成要素を他の構成要素から区別する目的に使われるだけで、構成要素を限定するために使われることはなく、特に言及されない限り、構成要素間の順序又は重要度などを限定しない。したがって、本開示の範囲内で、一実施例における第１構成要素は他の実施例において第２構成要素と称することもでき、同様に、一実施例における第２構成要素を他の実施例において第１構成要素と称することもできる。
【0039】
本開示で使われる用語は、特定実施例に関する説明のためのもので、特許請求の範囲を限定するためのものではない。実施例の説明及び添付する特許請求の範囲で使用される通り、単数形態は、文脈において特に断らない限り、複数形態も含むように意図したものである。本開示に使われる用語「及び／又は」は、関連した列挙項目のうちの一つを指してもよく、又はそれらのうち２つ以上の任意の及び全ての可能な組合せを指して含むことを意味する。また、本開示において、単語の間における「／」は、別に断らない限り、「及び／又は」と同じ意味を有する。
【0040】
本開示の例示は、様々な無線通信システムに適用されてよい。例えば、本開示の例示は、無線ＬＡＮシステムに適用されてよい。例えば、本開示の例示は、ＩＥＥＥ ８０２．１１ａ／ｇ／ｎ／ａｃ／ａｘ標準ベース無線ＬＡＮに適用されてよい。なお、本開示の例示は、新しく提案されるＩＥＥＥ ８０２．１１ｂｅ（又は、ＥＨＴ）標準ベース無線ＬＡＮに適用されてよい。本開示の例示は、ＩＥＥＥ ８０２．１１ｂｅリリース（ｒｅｌｅａｓｅ）－１標準の更なる改善技術に該当するＩＥＥＥ ８０２．１１ｂｅリリース－２標準ベース無線ＬＡＮに適用されてもよい。さらに、本開示の例示は、ＩＥＥＥ ８０２．１１ｂｅ後の次世代標準ベース無線ＬＡＮに適用されてもよい。また、本開示の例示は、セルラー無線通信システムに適用されてもよい。例えば、３ＧＰＰ（登録商標）（３ｒｄ Ｇｅｎｅｒａｔｉｏｎ Ｐａｒｔｎｅｒｓｈｉｐ Ｐｒｏｊｅｃｔ）標準のＬＴＥ（Ｌｏｎｇ Ｔｅｒｍ Ｅｖｏｌｕｔｉｏｎ）系列の技術及び５Ｇ ＮＲ（Ｎｅｗ Ｒａｄｉｏ）系列の技術に基づくセルラー無線通信システムに適用されてよい。
【0041】
以下、本開示の例示が適用され得る技術的特徴について説明する。
【0042】
図１は、本開示の一実施例に係る無線通信装置を例示するブロック構成図である。
【0043】
図１に例示している第１デバイス１００と第２デバイス２００は、端末（Ｔｅｒｍｉｎａｌ）、無線機器（ｗｉｒｅｌｅｓｓ ｄｅｖｉｃｅ）、ＷＴＲＵ（Ｗｉｒｅｌｅｓｓ Ｔｒａｎｓｍｉｔ Ｒｅｃｅｉｖｅ Ｕｎｉｔ）、ＵＥ（Ｕｓｅｒ Ｅｑｕｉｐｍｅｎｔ）、ＭＳ（Ｍｏｂｉｌｅ Ｓｔａｔｉｏｎ）、ＵＴ（ｕｓｅｒ ｔｅｒｍｉｎａｌ）、ＭＳＳ（Ｍｏｂｉｌｅ Ｓｕｂｓｃｒｉｂｅｒ Ｓｔａｔｉｏｎ）、ＭＳＳ（Ｍｏｂｉｌｅ Ｓｕｂｓｃｒｉｂｅｒ Ｕｎｉｔ）、ＳＳ（Ｓｕｂｓｃｒｉｂｅｒ Ｓｔａｔｉｏｎ）、ＡＭＳ（Ａｄｖａｎｃｅｄ Ｍｏｂｉｌｅ Ｓｔａｔｉｏｎ）、ＷＴ（Ｗｉｒｅｌｅｓｓ ｔｅｒｍｉｎａｌ）、又は簡単にユーザ（ｕｓｅｒ）などの様々な用語に言い換えられてよい。また、第１デバイス１００と第２デバイス２００は、アクセスポイント（Ａｃｃｅｓｓ Ｐｏｉｎｔ，ＡＰ）、ＢＳ（Ｂａｓｅ Ｓｔａｔｉｏｎ）、固定局（ｆｉｘｅｄ ｓｔａｔｉｏｎ）、Ｎｏｄｅ Ｂ、ＢＴＳ（ｂａｓｅ ｔｒａｎｓｃｅｉｖｅｒ ｓｙｓｔｅｍ）、ネットワーク、ＡＩ（Ａｒｔｉｆｉｃｉａｌ Ｉｎｔｅｌｌｉｇｅｎｃｅ）システム、ＲＳＵ（ｒｏａｄ ｓｉｄｅ ｕｎｉｔ）、リピータ、ルータ、リレー（ｒｅｌａｙ）、ゲートウェイなどの様々な用語に言い換えられてよい。
【0044】
図１に例示しているデバイス１００，２００は、ステーション（ｓｔａｔｉｏｎ，ＳＴＡ）と称することもできる。例えば、図１に例示しているデバイス１００，２００は、送信デバイス、受信デバイス、送信ＳＴＡ、受信ＳＴＡなどの様々な用語と称することができる。例えば、ＳＴＡ１１０，２００は、ＡＰ（ａｃｃｅｓｓ Ｐｏｉｎｔ）又はｎｏｎ－ＡＰの役割を担うことができる。すなわち、本開示において、ＳＴＡ１１０，２００は、ＡＰ及び／又はｎｏｎ－ＡＰの機能を有してよい。ＳＴＡ１１０，２００がＡＰ機能を有する場合に、簡単にＡＰと呼ぶこともでき、ＳＴＡ１１０，２００がｎｏｎ－ＡＰ機能を有する場合に、単にＳＴＡと呼ぶことができる。また、本開示において、ＡＰはＡＰ ＳＴＡと表示されてもよい。
【0045】
図１を参照すると、第１デバイス１００と第２デバイス２００は、様々な無線ＬＡＮ技術（例えば、ＩＥＥＥ ８０２．１１系列）を用いて無線信号を送受信することができる。第１デバイス１００と第２デバイス２００は、ＩＥＥＥ ８０２．１１標準の規定に従う媒体接続制御（ｍｅｄｉｕｍ ａｃｃｅｓｓ ｃｏｎｔｒｏｌ，ＭＡＣ）層及び物理層（ｐｈｙｓｉｃａｌ ｌａｙｅｒ，ＰＨＹ）に対するインターフェースを含んでよい。
【0046】
また、第１デバイス１００と第２デバイス２００は、無線ＬＡＮ技術以外の様々な通信標準（例えば、３ＧＰＰ ＬＴＥ系列、５Ｇ ＮＲ系列の標準など）技術をさらに支援することもできる。また、本開示のデバイスは、携帯電話、車両（ｖｅｈｉｃｌｅ）、個人用コンピュータ、ＡＲ（Ａｕｇｍｅｎｔｅｄ Ｒｅａｌｉｔｙ）装備、ＶＲ（Ｖｉｒｔｕａｌ Ｒｅａｌｉｔｙ）装備などの様々な装置によって具現されてよい。また、本明細書のＳＴＡは、音声通話、画像通話、データ通信、自律走行（Ａｕｔｏｎｏｍｏｕｓ－Ｄｒｉｖｉｎｇ）、ＭＴＣ（Ｍａｃｈｉｎｅ－Ｔｙｐｅ Ｃｏｍｍｕｎｉｃａｔｉｏｎ）、Ｍ２Ｍ（Ｍａｃｈｉｎｅ－ｔｏ－Ｍａｃｈｉｎｅ）、Ｄ２Ｄ（Ｄｅｖｉｃｅ－ｔｏ－Ｄｅｖｉｃｅ）、ＩｏＴ（Ｉｎｔｅｒｎｅｔ－ｏｆ－Ｔｈｉｎｇｓ）などの様々な通信サービスを支援することができる。
【0047】
第１デバイス１００は、１つ以上のプロセッサ１０２及び１つ以上のメモリ１０４を含み、追加的に１つ以上の送受信機（ｔｒａｎｓｃｅｉｖｅｒ）１０６及び／又は１つ以上のアンテナ１０８をさらに含んでよい。プロセッサ１０２は、メモリ１０４及び／又は送受信機１０６を制御し、本開示における説明、機能、手順、提案、方法、及び／又は動作順図を具現するように構成されてよい。例えば、プロセッサ１０２は、メモリ１０４内の情報を処理して第１情報／信号を生成した後、送受信機１０６を介して、第１情報／信号を含む無線信号を送信することができる。また、プロセッサ１０２は、送受信機１０６を介して、第２情報／信号を含む無線信号を受信した後、第２情報／信号の信号処理から得た情報をメモリ１０４に保存することができる。メモリ１０４は、プロセッサ１０２に連結されてよく、プロセッサ１０２の動作に関する様々な情報を保存することができる。例えば、メモリ１０４は、プロセッサ１０２によって制御されるプロセスの一部又は全部を実行するか、本開示における説明、機能、手順、提案、方法及び／又は動作順序図を実行するための命令語（ｉｎｓｔｒｕｃｔｉｏｎ）を含むソフトウェアコードを保存することができる。ここで、プロセッサ１０２とメモリ１０４は、無線ＬＡＮ技術（例えば、ＩＥＥＥ ８０２．１１系列）を具現するように設計された通信モデム／回路／チップの一部であってよい。送受信機１０６はプロセッサ１０２と連結されてよく、１つ以上のアンテナ１０８を介して無線信号を送信及び／又は受信することができる。送受信機１０６は、送信機及び／又は受信機を含んでよい。送受信機１０６は、ＲＦ（Ｒａｄｉｏ Ｆｒｅｑｕｅｎｃｙ）ユニットと同じ意味で使われてよい。本開示において、デバイスは通信モデム／回路／チップを意味することもできる。
【0048】
第２デバイス２００は、１つ以上のプロセッサ２０２、１つ以上のメモリ２０４を含み、追加的に１つ以上の送受信機２０６及び／又は１つ以上のアンテナ２０８をさらに含んでよい。プロセッサ２０２は、メモリ２０４及び／又は送受信機２０６を制御し、本開示に開示された説明、機能、手順、提案、方法及び／又は動作順序図を具現するように構成されてよい。例えば、プロセッサ２０２は、メモリ２０４内の情報を処理して第３情報／信号を生成した後、送受信機２０６を介して、第３情報／信号を含む無線信号を送信することができる。また、プロセッサ２０２は、送受信機２０６を介して、第４情報／信号を含む無線信号を受信した後、第４情報／信号の信号処理から得た情報をメモリ２０４に保存することができる。メモリ２０４はプロセッサ２０２と連結されてよく、プロセッサ２０２の動作と関連した様々な情報を保存することができる。例えば、メモリ２０４は、プロセッサ２０２によって制御されるプロセスの一部又は全部を実行するか、本開示に開示された説明、機能、手順、提案、方法及び／又は動作順序図を実行するための命令語を含むソフトウェアコードを保存することができる。ここで、プロセッサ２０２とメモリ２０４は、無線ＬＡＮ技術（例えば、ＩＥＥＥ ８０２．１１系列）を具現するように設計された通信モデム／回路／チップの一部であってよい。送受信機２０６はプロセッサ２０２と連結されてよく、１つ以上のアンテナ２０８を介して無線信号を送信及び／又は受信することができる。送受信機２０６は、送信機及び／又は受信機を含んでよい。送受信機２０６はＲＦユニットと同じ意味で使われてよい。本開示において、デバイスは通信モデム／回路／チップを意味することもできる。
【0049】
以下、デバイス１００，２００のハードウェア要素についてより具体的に説明する。これに限定されるものではないが、１つ以上のプロトコル層が１つ以上のプロセッサ１０２，２０２によって具現されてよい。例えば、１つ以上のプロセッサ１０２，２０２は、１つ以上の層（例えば、ＰＨＹ、ＭＡＣのような同じ機能的な層）を具現することができる。１つ以上のプロセッサ１０２，２０２は、本開示における説明、機能、手順、提案、方法及び／又は動作順序図によって１つ以上のＰＤＵ（Ｐｒｏｔｏｃｏｌ Ｄａｔａ Ｕｎｉｔ）及び／又は１つ以上のＳＤＵ（Ｓｅｒｖｉｃｅ Ｄａｔａ Ｕｎｉｔ）を生成できる。１つ以上のプロセッサ１０２，２０２は、本開示における説明、機能、手順、提案、方法及び／又は動作順序図によってメッセージ、制御情報、データ、又は情報を生成することができる。１つ以上のプロセッサ１０２，２０２は、本開示における機能、手順、提案及び／又は方法によってＰＤＵ、ＳＤＵ、メッセージ、制御情報、データ、又は情報を含む信号（例えば、ベースバンド信号）を生成し、１つ以上の送受信機１０６，２０６に提供することができる。１つ以上のプロセッサ１０２，２０２は、１つ以上の送受信機１０６，２０６から信号（例えば、ベースバンド信号）を受信することができ、本開示における説明、機能、手順、提案、方法及び／又は動作順序図によってＰＤＵ、ＳＤＵ、メッセージ、制御情報、データ、又は情報を取得することができる。
【0050】
１つ以上のプロセッサ１０２，２０２は、コントローラ、マイクロコントローラ、マイクロプロセッサ又はマイクロコンピュータと呼ぶことができる。１つ以上のプロセッサ１０２，２０２は、ハードウェア、ファームウェア、ソフトウェア、又はそれらの組合せによって具現されてよい。一例として、１つ以上のＡＳＩＣ（Ａｐｐｌｉｃａｔｉｏｎ Ｓｐｅｃｉｆｉｃ Ｉｎｔｅｇｒａｔｅｄ Ｃｉｒｃｕｉｔ）、１つ以上のＤＳＰ（Ｄｉｇｉｔａｌ Ｓｉｇｎａｌ Ｐｒｏｃｅｓｓｏｒ）、１つ以上のＤＳＰＤ（Ｄｉｇｉｔａｌ Ｓｉｇｎａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｄｅｖｉｃｅ）、１つ以上のＰＬＤ（Ｐｒｏｇｒａｍｍａｂｌｅ Ｌｏｇｉｃ Ｄｅｖｉｃｅ）又は１つ以上のＦＰＧＡ（Ｆｉｅｌｄ Ｐｒｏｇｒａｍｍａｂｌｅ Ｇａｔｅ Ａｒｒａｙｓ）が１つ以上のプロセッサ１０２，２０２に含まれてよい。本開示に開示された説明、機能、手続、提案、方法及び／又は動作順序図は、ファームウェア又はソフトウェアを用いて具現されてよく、ファームウェア又はソフトウェアは、モジュール、手続、機能などを含むように具現されてよい。本開示に開示された説明、機能、手続、提案、方法及び／又は動作順序図を実行するように設定されたファームウェア又はソフトウェアは、１つ以上のプロセッサ１０２，２０２に含まれるか、１つ以上のメモリ１０４，２０４に保存され、１つ以上のプロセッサ１０２，２０２によって駆動されてよい。本開示に開示された説明、機能、手続、提案、方法及び／又は動作順序図は、コード、命令語及び／又は命令語の集合の形態でファームウェア又はソフトウェアによって具現されてよい。
【0051】
１つ以上のメモリ１０４，２０４は１つ以上のプロセッサ１０２，２０２と連結されてよく、様々な形態のデータ、信号、メッセージ、情報、プログラム、コード、指示及び／又は命令を保存することができる。１つ以上のメモリ１０４，２０４は、ＲＯＭ、ＲＡＭ、ＥＰＲＯＭ、フラッシュメモリ、ハードドライブ、レジスター、キャッシュメモリ、コンピュータ可読記憶媒体及び／又はそれらの組合せによって構成されてよい。１つ以上のメモリ１０４，２０４は、１つ以上のプロセッサ１０２，２０２の内部及び／又は外部に位置してよい。また、１つ以上のメモリ１０４，２０４は、有線又は無線連結のような様々な技術によって１つ以上のプロセッサ１０２，２０２と連結されてよい。
【0052】
１つ以上の送受信機１０６，２０６は、１つ以上の他の装置に、本開示の方法及び／又は動作順序図などで言及されるユーザデータ、制御情報、無線信号／チャネルなどを送信できる。１つ以上の送受信機１０６，２０６は、１つ以上の他の装置から、本開示に開示された説明、機能、手続、提案、方法及び／又は動作順序図などで言及されるユーザデータ、制御情報、無線信号／チャネルなどを受信することができる。例えば、１つ以上の送受信機１０６，２０６は１つ以上のプロセッサ１０２，２０２と連結されてよく、無線信号を送受信できる。例えば、１つ以上のプロセッサ１０２，２０２は、１つ以上の送受信機１０６，２０６が１つ以上の他の装置にユーザデータ、制御情報又は無線信号を送信するように制御できる。また、１つ以上のプロセッサ１０２，２０２は、１つ以上の送受信機１０６，２０６が１つ以上の他の装置からユーザデータ、制御情報又は無線信号を受信するように制御できる。また、１つ以上の送受信機１０６，２０６は１つ以上のアンテナ１０８，２０８と連結されてよく、１つ以上の送受信機１０６，２０６は１つ以上のアンテナ１０８，２０８を介して、本開示に開示された説明、機能、手続、提案、方法及び／又は動作順序図などで言及されるユーザデータ、制御情報、無線信号／チャネルなどを送受信するように設定されてよい。本開示において、１つ以上のアンテナは複数の物理アンテナであるか、複数の論理アンテナ（例えば、アンテナポート）であってよい。１つ以上の送受信機１０６，２０６は、受信されたユーザデータ、制御情報、無線信号／チャネルなどを１つ以上のプロセッサ１０２，２０２を用いて処理するために、受信された無線信号／チャネルなどをＲＦバンド信号からベースバンド信号に変換（Ｃｏｎｖｅｒｔ）してよい。１つ以上の送受信機１０６，２０６は、１つ以上のプロセッサ１０２，２０２を用いて処理されたユーザデータ、制御情報、無線信号／チャネルなどを、ベースバンド信号からＲＦバンド信号に変換してよい。そのために、１つ以上の送受信機１０６，２０６は（アナログ）オシレーター及び／又はフィルターを含んでよい。
【0053】
例えば、ＳＴＡ１００，２００のいずれか一方は、ＡＰの意図された動作を行い、ＳＴＡ１００，２００のいずれか他方は、ｎｏｎ－ＡＰ ＳＴＡの意図された動作を行うことができる。例えば、図１の送受信機１０６，２０６は、信号（例えば、ＩＥＥＥ ８０２．１１ａ／ｂ／ｇ／ｎ／ａｃ／ａｘ／ｂｅなどに従うパケット又はＰＰＤＵ（Ｐｈｙｓｉｃａｌ ｌａｙｅｒ Ｐｒｏｔｏｃｏｌ Ｄａｔａ Ｕｎｉｔ））の送受信動作を行うことができる。また、本開示において、様々なＳＴＡが送受信信号を生成したり送受信信号のために事前にデータ処理や演算を行う動作は、図１のプロセッサ１０２，２０２で行われてよい。例えば、送受信信号を生成したり送受信信号のために事前にデータ処理や演算を行う動作の一例は、１）ＰＰＤＵ内に含まれるフィールド（ＳＩＧ（ｓｉｇｎａｌ）、ＳＴＦ（ｓｈｏｒｔ ｔｒａｉｎｉｎｇ ｆｉｅｌｄ）、ＬＴＦ（ｌｏｎｇ ｔｒａｉｎｉｎｇ ｆｉｅｌｄ）、Ｄａｔａなど）のビット情報を決定／取得／構成／演算／デコード／エンコードする動作、２）ＰＰＤＵ内に含まれるフィールド（ＳＩＧ、ＳＴＦ、ＬＴＦ、Ｄａｔａなど）のために使用される時間リソースや周波数リソース（例えば、サブキャリアリソース）などを決定／構成／取得する動作、３）ＰＰＤＵ内に含まれるフィールド（ＳＩＧ、ＳＴＦ、ＬＴＦ、Ｄａｔａなど）のために使用される特定のシーケンス（例えば、パイロットシーケンス、ＳＴＦ／ＬＴＦシーケンス、ＳＩＧに適用されるエクストラシーケンス）などを決定／構成／取得する動作、４）ＳＴＡに対して適用される電力制御動作及び／又はパワーセービング動作、５）ＡＣＫ信号の決定／取得／構成／演算／デコーディング／エンコーディングなどに関連した動作を含んでよい。また、以下の一例において様々なＳＴＡが送受信信号の決定／取得／構成／演算／デコーディング／エンコーディングのために使用する様々な情報（例えば、フィールド／サブフィールド／制御フィールド／パラメータ／パワーなどに関する情報）は、図１のメモリ１０４，２０４に保存されてよい。
【0054】
以下において、下りリンク（ｄｏｗｎｌｉｎｋ，ＤＬ）は、ＡＰ ＳＴＡからｎｏｎ－ＡＰ ＳＴＡへの通信のためのリンクを意味し、下りリンクを通じて下りリンクＰＰＤＵ／パケット／信号などが送受信されてよい。下りリンク通信において、送信機はＡＰ ＳＴＡの一部であり、受信機はｎｏｎ－ＡＰ ＳＴＡの一部であってよい。上りリンク（ｕｐｌｉｎｋ，ＵＬ）は、ｎｏｎ－ＡＰ ＳＴＡからＡＰ ＳＴＡへの通信のためのリンクを意味し、上りリンクを通じて上りリンクＰＰＤＵ／パケット／信号などが送受信されてよい。上りリンク通信において、送信機はｎｏｎ－ＡＰ ＳＴＡの一部であり、受信機はＡＰ ＳＴＡの一部であってよい。
【0055】
図２は、本開示の適用が可能な無線ＬＡＮシステムの例示的な構造を示す図である。
【0056】
無線ＬＡＮシステムの構造は、複数個の構成要素（ｃｏｍｐｏｎｅｎｔ）で構成されてよい。複数の構成要素の相互作用によって上位層に対してトランスペアレントなＳＴＡ移動性を支援する無線ＬＡＮが提供されてよい。ＢＳＳ（Ｂａｓｉｃ Ｓｅｒｖｉｃｅ Ｓｅｔ）は、無線ＬＡＮの基本的な構成ブロックに該当する。図２では、２個のＢＳＳ（ＢＳＳ１及びＢＳＳ２）が存在し、各ＢＳＳのメンバーとして２個のＳＴＡが含まれる（ＳＴＡ１及びＳＴＡ２はＢＳＳ１に含まれ、ＳＴＡ３及びＳＴＡ４はＢＳＳ２に含まれる）ことを例示する。図２で、ＢＳＳを表す楕円は、当該ＢＳＳに含まれたＳＴＡが通信を維持するカバレッジ領域を表すものと理解されてもよい。この領域をＢＳＡ（Ｂａｓｉｃ Ｓｅｒｖｉｃｅ Ａｒｅａ）と称することができる。ＳＴＡがＢＳＡ外に移動すると、当該ＢＳＡ内の他のＳＴＡと直接通信できなくなる。
【0057】
図２に示すＤＳを考慮しないと、無線ＬＡＮにおいて最も基本的なタイプのＢＳＳは、独立したＢＳＳ（Ｉｎｄｅｐｅｎｄｅｎｔ ＢＳＳ，ＩＢＳＳ）である。例えば、ＩＢＳＳは、２個のＳＴＡのみで構成された最小の形態を有し得る。例えば、他の構成要素が省略されたものを仮定し、ＳＴＡ１及びＳＴＡ２のみで構成されたＢＳＳ１、又はＳＴＡ３及びＳＴＡ４のみで構成されたＢＳＳ２はそれぞれ、ＩＢＳＳの代表的な例示に該当し得る。このような構成は、ＳＴＡがＡＰ無しで直接通信できる場合に可能である。また、このような形態の無線ＬＡＮにおいてあらかじめ計画して構成されるものではなく、ＬＡＮが必要とする場合に構成されてよく、これをアドホック（ａｄ－ｈｏｃ）ネットワークと称することもできる。ＩＢＳＳは、ＡＰを含まないので、中央で管理機能を行う個体（ｃｅｎｔｒａｌｉｚｅｄ ｍａｎａｇｅｍｅｎｔ ｅｎｔｉｔｙ）がない。すなわち、ＩＢＳＳにおいて、ＳＴＡは、分散された方式（ｄｉｓｔｒｉｂｕｔｅｄ ｍａｎｎｅｒ）で管理される。ＩＢＳＳでは全てのＳＴＡが移動ＳＴＡで構成されてよく、分散システム（ＤＳ）への接続が許容されず、自己完備的ネットワーク（ｓｅｌｆ－ｃｏｎｔａｉｎｅｄ ｎｅｔｗｏｒｋ）をなす。
【0058】
ＳＴＡがついたり消えたりすること、ＳＴＡがＢＳＳ領域に入ったり離脱したりすることなどにより、ＢＳＳにおいてＳＴＡのメンバーシップが動的に変更されることがある。ＢＳＳのメンバーになるためには、ＳＴＡは、同期化過程を用いてＢＳＳにジョインすることができる。ＢＳＳベース構造の全てのサービスにアクセスするためには、ＳＴＡはＢＳＳに結合（ａｓｓｏｃｉａｔｅｄ）される必要がある。このような結合（ａｓｓｏｃｉａｔｉｏｎ）は動的に設定されてよく、分散システムサービス（Ｄｉｓｔｒｉｂｕｔｉｏｎ Ｓｙｓｔｅｍ Ｓｅｒｖｉｃｅ，ＤＳＳ）の利用を含んでよい。
【0059】
無線ＬＡＮにおいて直接的なＳＴＡ－対－ＳＴＡの距離はＰＨＹ性能によって制限されてよい。ある場合にはこのような距離の限界が十分であるが、場合によっては、より遠い距離のＳＴＡ間の通信を必要とすることもある。拡張されたカバレッジを支援するために分散システム（ＤＳ）が構成されてよい。
【0060】
ＤＳは、ＢＳＳが相互連結される構造を意味する。具体的に、図２のように、複数個のＢＳＳで構成されたネットワークの拡張された形態の構成要素としてＢＳＳが存在してもよい。ＤＳは論理的な概念であり、分散システム媒体（ＤＳＭ）の特性によって特定されてよい。これと関連して、無線媒体（Ｗｉｒｅｌｅｓｓ Ｍｅｄｉｕｍ，ＷＭ）とＤＳＭは論理的に区分されてよい。それぞれの論理的媒体は互いに異なる目的のために用いられ、互いに異なる構成要素によって使用される。これらの媒体が同一のものに制限されることもなく、異なるものに制限されることもない。このように複数個の媒体が論理的に互いに異なるという点で、無線ＬＡＮ構造（ＤＳ構造又は他のネットワーク構造）の柔軟性が説明され得る。すなわち、無線ＬＡＮ構造は様々に具現されてよく、それぞれの具現例の物理的な特性によって独立して当該無線ＬＡＮ構造が特定されてよい。
【0061】
ＤＳは、複数個のＢＳＳのシームレス（ｓｅａｍｌｅｓｓ）な統合を提供し、宛先へのアドレスを扱う上で必要な論理的サービスを提供することによって移動デバイスを支援することができる。また、ＤＳは、無線ＬＡＮと他のネットワーク（例えば、ＩＥＥＥ ８０２．Ｘ）との連結のためのブリッジの働きをするポータル（ｐｏｒｔａｌ）という構成要素をさらに含んでよい。
【0062】
ＡＰは、結合されたｎｏｎ－ＡＰ ＳＴＡに対してＷＭを通じてＤＳへのアクセスを可能にし、ＳＴＡの機能性も有するエンティティ（ｅｎｔｉｔｙ）を意味する。ＡＰを介してＢＳＳとＤＳとのデータ移動が行われ得る。例えば、図２に示すＳＴＡ２及びＳＴＡ３は、ＳＴＡの機能性を有しながら、結合されたｎｏｎ－ＡＰ ＳＴＡ（ＳＴＡ１及びＳＴＡ４）がＤＳにアクセス可能にする機能を提供する。また、全てのＡＰは基本的にＳＴＡに該当するので、全てのＡＰはアドレス可能なエンティティである。ＷＭ上における通信のためにＡＰによって使用されるアドレスと、ＤＳＭ上における通信のためにＡＰによって使用されるアドレスとが必ず同一である必要はない。ＡＰと１つ以上のＳＴＡで構成されるＢＳＳをインフラストラクチャー（ｉｎｆｒａｓｔｒｕｃｔｕｒｅ ＢＳＳ）と称することができる。
【0063】
ＡＰに結合されたＳＴＡのうち一つから当該ＡＰのＳＴＡアドレスに送信されるデータは、常に非制御ポート（ｕｎｃｏｎｔｒｏｌｌｅｄ ｐｏｒｔ）で受信され、ＩＥＥＥ ８０２．１Ｘポートアクセスエンティティによって処理されてよい。また、制御ポート（ｃｏｎｔｒｏｌｌｅｄ ｐｏｒｔ）が認証されると送信データ（又は、フレーム）はＤＳに伝達され得る。
【0064】
前述したＤＳの構造に、さらに広いカバレッジを提供するための拡張されたサービスセット（Ｅｘｔｅｎｄｅｄ Ｓｅｒｖｉｃｅ Ｓｅｔ，ＥＳＳ）が設定されてよい。
【0065】
ＥＳＳは、任意の（ａｒｂｉｔｒａｒｙ）大きさ及び複雑度を有するネットワークがＤＳ及びＢＳＳで構成されたネットワークを意味する。ＥＳＳは、１つのＤＳに連結されたＢＳＳの集合に該当し得る。しかし、ＥＳＳがＤＳを含むことはない。ＥＳＳネットワークは、ＬＬＣ（Ｌｏｇｉｃａｌ Ｌｉｎｋ Ｃｏｎｔｒｏｌ）層ではＩＢＳＳとして見える点が特徴である。ＥＳＳに含まれるＳＴＡは互いに通信でき、移動ＳＴＡはＬＬＣにトランスペアレントに一つのＢＳＳから他のＢＳＳに（同じＥＳＳ内で）移動することができる。一つのＥＳＳに含まれるＡＰは、同じＳＳＩＤ（ｓｅｒｖｉｃｅ ｓｅｔ ｉｄｅｎｔｉｆｉｃａｔｉｏｎ）を有してよい。ＳＳＩＤは、ＢＳＳの識別子であるＢＳＳＩＤと区別される。
【0066】
無線ＬＡＮシステムではＢＳＳの相対的な物理的位置に対して何にも仮定せず、次のような形態のいずれをも可能である。ＢＳＳは部分的に重なってよく、これは、連続するカバレッジを提供するために一般的に利用される形態である。また、ＢＳＳは物理的に連結されていなくてよく、論理的にはＢＳＳ間の距離に制限はない。また、ＢＳＳは、物理的に同じ位置に位置してよく、これはリダンダンシーを提供するために利用されてよい。また、１つ（又は、１つ以上の）ＩＢＳＳ又はＥＳＳネットワークが１つ（又は、１つ以上の）ＥＳＳネットワークとして同一空間に物理的に存在してよい。これは、ＥＳＳネットワークが存在する位置にアドホックネットワークが動作する場合、互いに異なる機関（ｏｒｇａｎｉｚａｔｉｏｎｓ）によって物理的に重なる無線ネットワークが構成される場合、又は同一位置で２以上の互いに異なるアクセス及び保安政策が必要な場合などにおけるＥＳＳネットワーク形態に該当し得る。
【0067】
図３は、本開示の適用が可能なリンクセットアップ（ｌｉｎｋ ｓｅｔｕｐ）過程を説明するための図である。
【0068】
ＳＴＡがネットワークに対してリンクをセットアップしデータを送受信するためには、まず、ネットワークを発見（ｄｉｓｃｏｖｅｒｙ）し、認証（ａｕｔｈｅｎｔｉｃａｔｉｏｎ）を行い、結合（ａｓｓｏｃｉａｔｉｏｎ）を確立（ｅｓｔａｂｌｉｓｈ）し、保安（ｓｅｃｕｒｉｔｙ）のための認証手順などを行わなければならない。リンクセットアップ過程を、セッション開始過程、セッションセットアップ過程と称することができる。また、リンクセットアップ過程の発見、認証、結合、保安設定の過程を総称して結合過程ということもできる。
【0069】
段階Ｓ３１０で、ＳＴＡはネットワーク発見動作を行うことができる。ネットワーク発見動作は、ＳＴＡのスキャニング（ｓｃａｎｎｉｎｇ）動作を含んでよい。すなわち、ＳＴＡがネットワークにアクセスするためには、参加可能なネットワークを探さなければならない。ＳＴＡは、無線ネットワークに参加する前に互換可能なネットワークを識別しなければならないが、特定領域に存在するネットワーク識別過程をスキャニングという。
【0070】
スキャニング方式には、能動的スキャニング（ａｃｔｉｖｅ ｓｃａｎｎｉｎｇ）と受動的スキャニング（ｐａｓｓｉｖｅ ｓｃａｎｎｉｎｇ）がある。図３では、例示的に、能動的スキャニング過程を含むネットワーク発見動作を示す。能動的スキャニングにおいて、スキャニングを行うＳＴＡは、チャネルを移しながら周辺にどのようなＡＰが存在するかを探索するために、プローブ要請フレーム（ｐｒｏｂｅ ｒｅｑｕｅｓｔ ｆｒａｍｅ）を送信し、それに対する応答を待つ。応答者（ｒｅｓｐｏｎｄｅｒ）は、プローブ要請フレームを送信したＳＴＡに、プローブ要請フレームに対する応答としてプローブ応答フレーム（ｐｒｏｂｅ ｒｅｓｐｏｎｓｅ ｆｒａｍｅ）を送信する。ここで、応答者は、スキャニングされているチャネルのＢＳＳで最後にビーコンフレーム（ｂｅａｃｏｎ ｆｒａｍｅ）を送信したＳＴＡであってよい。ＢＳＳではＡＰがビーコンフレームを送信するので、ＡＰが応答者となり、ＩＢＳＳでは、ＩＢＳＳ内のＳＴＡが交番にビーコンフレームを送信するので、応答者が一定でない。例えば、１番チャネルでプローブ要請フレームを送信し、１番チャネルでプローブ応答フレームを受信したＳＴＡは、受信したプローブ応答フレームに含まれたＢＳＳ関連情報を保存し、次のチャネル（例えば、２番チャネル）に移動して同じ方法でスキャニング（すなわち、２番チャネル上でプローブ要請／応答を送受信）を行うことができる。
【0071】
図３では示していないが、スキャニング動作は、受動的スキャニング方式で行われてもよい。受動的スキャニングにおいて、キャニングを行うＳＴＡは、チャネルを移しながらビーコンフレームを待つ。ビーコンフレームは、ＩＥＥＥ ８０２．１１で定義される管理フレーム（ｍａｎａｇｅｍｅｎｔ ｆｒａｍｅ）の一つで、無線ネットワークの存在を知らせ、スキャニングを行うＳＴＡにとって無線ネットワークを探して無線ネットワークに参加できるように、周期的に送信される。ＢＳＳでＡＰがビーコンフレームを周期的に送信する役割を担い、ＩＢＳＳではＩＢＳＳ内のＳＴＡが交番にビーコンフレームを送信する。スキャニングを行うＳＴＡは、ビーコンフレームを受信すると、ビーコンフレームに含まれたＢＳＳに関する情報を保存し、他のチャネルに移動しながら各チャネルでビーコンフレーム情報を記録する。ビーコンフレームを受信したＳＴＡは、受信したビーコンフレームに含まれたＢＳＳ関連情報を保存し、次のチャネルに移動して同じ方法で次のチャネルでスキャニングを行うことができる。能動的スキャニングと受動的スキャニングとを対比すれば、能動的スキャニングが受動的スキャニングに比べてディレー（ｄｅｌａｙ）及び電力消耗が小さいという長所がある。
【0072】
ＳＴＡがネットワークを発見した後に、段階Ｓ３２０で認証過程が行われてよい。このような認証過程は、後述する段階Ｓ３４０の保安セットアップ動作と明確に区分するために、最初の認証（ｆｉｒｓｔ ａｕｔｈｅｎｔｉｃａｔｉｏｎ）過程と呼ぶことができる。
【0073】
認証過程は、ＳＴＡが認証要請フレーム（ａｕｔｈｅｎｔｉｃａｔｉｏｎ ｒｅｑｕｅｓｔ ｆｒａｍｅ）をＡＰに送信し、これに応答してＡＰが認証応答フレーム（ａｕｔｈｅｎｔｉｃａｔｉｏｎ ｒｅｓｐｏｎｓｅ ｆｒａｍｅ）をＳＴＡに送信する過程を含む。認証要請／応答に用いられる認証フレーム（ａｕｔｈｅｎｔｉｃａｔｉｏｎ ｆｒａｍｅ）は、管理フレームに該当する。
【0074】
認証フレームは、認証アルゴリズム番号（ａｕｔｈｅｎｔｉｃａｔｉｏｎ ａｌｇｏｒｉｔｈｍ ｎｕｍｂｅｒ）、認証トランザクションシーケンス番号（ａｕｔｈｅｎｔｉｃａｔｉｏｎ ｔｒａｎｓａｃｔｉｏｎ ｓｅｑｕｅｎｃｅ ｎｕｍｂｅｒ）、状態コード（ｓｔａｔｕｓ ｃｏｄｅ）、検問テキスト（ｃｈａｌｌｅｎｇｅ ｔｅｘｔ）、ＲＳＮ（Ｒｏｂｕｓｔ Ｓｅｃｕｒｉｔｙ Ｎｅｔｗｏｒｋ）、有限循環グループ（Ｆｉｎｉｔｅ Ｃｙｃｌｉｃ Ｇｒｏｕｐ）などに関する情報を含んでよい。これは、認証要請／応答フレームに含み得る情報の一部の例示に該当し、他の情報に代替されるか、追加の情報がさらに含まれてよい。
【0075】
ＳＴＡは認証要請フレームをＡＰに送信できる。ＡＰは、受信した認証要請フレームに含まれた情報に基づいて、当該ＳＴＡに対する認証を許容するか否かを決定できる。ＡＰは、認証処理の結果を認証応答フレームを用いてＳＴＡに提供できる。
【0076】
ＳＴＡが成功裏に認証された後に、段階Ｓ３３０で結合過程が行われてよい。結合過程は、ＳＴＡが結合要請フレーム（ａｓｓｏｃｉａｔｉｏｎ ｒｅｑｕｅｓｔ ｆｒａｍｅ）をＡＰに送信し、それに応答してＡＰが結合応答フレーム（ａｓｓｏｃｉａｔｉｏｎ ｒｅｓｐｏｎｓｅ ｆｒａｍｅ）をＳＴＡに送信する過程を含む。
【0077】
例えば、結合要請フレームは、様々なキャパビリティ（ｃａｐａｂｉｌｉｔｙ）に関する情報、ビーコン聴取間隔（ｌｉｓｔｅｎ ｉｎｔｅｒｖａｌ）、ＳＳＩＤ（ｓｅｒｖｉｃｅ ｓｅｔ ｉｄｅｎｔｉｆｉｅｒ）、支援レート（ｓｕｐｐｏｒｔｅｄ ｒａｔｅｓ）、支援チャネル（ｓｕｐｐｏｒｔｅｄ ｃｈａｎｎｅｌｓ）、ＲＳＮ、移動性ドメイン、支援オペレーティングクラス（ｓｕｐｐｏｒｔｅｄ ｏｐｅｒａｔｉｎｇ ｃｌａｓｓｅｓ）、ＴＩＭブロードキャスト要請（Ｔｒａｆｆｉｃ Ｉｎｄｉｃａｔｉｏｎ Ｍａｐ Ｂｒｏａｄｃａｓｔ ｒｅｑｕｅｓｔ）、相互動作（ｉｎｔｅｒｗｏｒｋｉｎｇ）サービスキャパビリティなどに関する情報を含んでよい。例えば、結合応答フレームは、様々なキャパビリティに関する情報、状態コード、ＡＩＤ（Ａｓｓｏｃｉａｔｉｏｎ ＩＤ）、支援レート、ＥＤＣＡ（Ｅｎｈａｎｃｅｄ Ｄｉｓｔｒｉｂｕｔｅｄ Ｃｈａｎｎｅｌ Ａｃｃｅｓｓ）パラメータセット、ＲＣＰＩ（Ｒｅｃｅｉｖｅｄ Ｃｈａｎｎｅｌ Ｐｏｗｅｒ Ｉｎｄｉｃａｔｏｒ）、ＲＳＮＩ（Ｒｅｃｅｉｖｅｄ Ｓｉｇｎａｌ ｔｏ Ｎｏｉｓｅ Ｉｎｄｉｃａｔｏｒ）、移動性ドメイン、タイムアウト間隔（例えば、結合カムバック時間（ａｓｓｏｃｉａｔｉｏｎ ｃｏｍｅｂａｃｋ ｔｉｍｅ））、重複（ｏｖｅｒｌａｐｐｉｎｇ）ＢＳＳスキャンパラメータ、ＴＩＭブロードキャスト応答、ＱｏＳ（Ｑｕａｌｉｔｙ ｏｆ Ｓｅｒｖｉｃｅ）マップなどの情報を含んでよい。これは、結合要請／応答フレームに含み得る情報の一部の例示に該当し、他の情報に代替されるか、追加の情報がさらに含まれてよい。
【0078】
ＳＴＡがネットワークに成功裏に結合された後に、段階Ｓ３４０で保安セットアップ過程が行われてよい。段階Ｓ３４０の保安セットアップ過程は、ＲＳＮＡ（Ｒｏｂｕｓｔ Ｓｅｃｕｒｉｔｙ Ｎｅｔｗｏｒｋ Ａｓｓｏｃｉａｔｉｏｎ）要請／応答を用いた認証過程ということもでき、前記段階Ｓ３２０の認証過程を最初の認証（ｆｉｒｓｔ ａｕｔｈｅｎｔｉｃａｔｉｏｎ）過程といい、段階Ｓ３４０の保安セットアップ過程を単に認証過程ということもできる。
【0079】
段階Ｓ３４０の保安セットアップ過程は、例えば、ＥＡＰＯＬ（Ｅｘｔｅｎｓｉｂｌｅ Ａｕｔｈｅｎｔｉｃａｔｉｏｎ Ｐｒｏｔｏｃｏｌ ｏｖｅｒ ＬＡＮ）フレームを用いた４ウェイ（ｗａｙ）ハンドシェーキングを用いて、プライベートキーセットアップ（ｐｒｉｖａｔｅ ｋｅｙ ｓｅｔｕｐ）をする過程を含んでよい。また、保安セットアップ過程は、ＩＥＥＥ ８０２．１１標準で定義しない保安方式によって行われてもよい。
【0080】
図４は、本開示の適用が可能なバックオフ過程を説明するための図である。
【0081】
無線ＬＡＮシステムにおいて、ＭＡＣ（Ｍｅｄｉｕｍ Ａｃｃｅｓｓ Ｃｏｎｔｒｏｌ）の基本アクセスメカニズムは、ＣＳＭＡ／ＣＡ（Ｃａｒｒｉｅｒ Ｓｅｎｓｅ Ｍｕｌｔｉｐｌｅ Ａｃｃｅｓｓ ｗｉｔｈ Ｃｏｌｌｉｓｉｏｎ Ａｖｏｉｄａｎｃｅ）メカニズムである。ＣＳＭＡ／ＣＡメカニズムは、ＩＥＥＥ ８０２．１１ ＭＡＣの分配調整機能（Ｄｉｓｔｒｉｂｕｔｅｄ Ｃｏｏｒｄｉｎａｔｉｏｎ Ｆｕｎｃｔｉｏｎ，ＤＣＦ）とも呼ばれるが、基本的に「話す前に聞く（ｌｉｓｔｅｎ ｂｅｆｏｒｅ ｔａｌｋ）」アクセスメカニズムを採用している。このような類型のアクセスメカニズムによれば、ＡＰ及び／又はＳＴＡは、送信を始めるに先立ち、所定の時間区間（例えば、ＤＩＦＳ（ＤＣＦ Ｉｎｔｅｒ－Ｆｒａｍｅ Ｓｐａｃｅ）で無線チャネル又は媒体（ｍｅｄｉｕｍ）をセンシング（ｓｅｎｓｉｎｇ）するＣＣＡ（Ｃｌｅａｒ Ｃｈａｎｎｅｌ Ａｓｓｅｓｓｍｅｎｔ）を行うことができる。センシングの結果、万一、媒体が遊休状態（ｉｄｌｅ ｓｔａｔｕｓ）であると判断されれば、当該媒体を通じてフレーム送信を始める。一方、媒体が占有された（ｏｃｃｕｐｉｅｄ）状態又はビジー（ｂｕｓｙ）状態として感知されれば、当該ＡＰ及び／又はＳＴＡは、自分の送信を始めず、媒体アクセスのための遅延期間（例えば、ランダムバックオフ期間（ｒａｎｄｏｍ ｂａｃｋｏｆｆ ｐｅｒｉｏｄ））を設定して待った後、フレーム送信を試みることができる。ランダムバックオフ期間の適用により、複数のＳＴＡは互いに異なる時間待機した後にフレーム送信を試みることが期待されるので、衝突（ｃｏｌｌｉｓｉｏｎ）を最小化させることができる。
【0082】
また、ＩＥＥＥ ８０２．１１ ＭＡＣプロトコルは、ＨＣＦ（Ｈｙｂｒｉｄ Ｃｏｏｒｄｉｎａｔｉｏｎ Ｆｕｎｃｔｉｏｎ）を提供する。ＨＣＦは、前記ＤＣＦとＰＣＦ（Ｐｏｉｎｔ Ｃｏｏｒｄｉｎａｔｉｏｎ Ｆｕｎｃｔｉｏｎ）に基づく。ＰＣＦは、ポーリング（ｐｏｌｌｉｎｇ）ベースの同期式アクセス方式で、すべての受信ＡＰ及び／又はＳＴＡがデータフレームを受信できるように周期的にポールする方式のことを指す。また、ＨＣＦは、ＥＤＣＡ（Ｅｎｈａｎｃｅｄ Ｄｉｓｔｒｉｂｕｔｅｄ Ｃｈａｎｎｅｌ Ａｃｃｅｓｓ）とＨＣＣＡ（ＨＣＦ Ｃｏｎｔｒｏｌｌｅｄ Ｃｈａｎｎｅｌ Ａｃｃｅｓｓ）を有する。ＥＤＣＡは、提供者が複数のユーザにデータフレームを提供するためのアクセス方式を競合ベースとすることであり、ＨＣＣＡは、ポーリング（ｐｏｌｌｉｎｇ）メカニズムを用いた非競合ベースのチャネルアクセス方式を用いることである。また、ＨＣＦは、無線ＬＡＮのＱｏＳ（Ｑｕａｌｉｔｙ ｏｆ Ｓｅｒｖｉｃｅ）を向上させるための媒体アクセスメカニズムを含み、競合期間（Ｃｏｎｔｅｎｔｉｏｎ Ｐｅｒｉｏｄ，ＣＰ）と非競合期間（Ｃｏｎｔｅｎｔｉｏｎ Ｆｒｅｅ Ｐｅｒｉｏｄ，ＣＦＰ）のいずれにおいてもＱｏＳデータを送信できる。
【0083】
図４を参照してランダムバックオフ周期に基づく動作について説明する。占有された／ビジー状態であった媒体が遊休状態に変更されると、複数のＳＴＡは、データ（又は、フレーム）送信を試みることができる。衝突を最小化するための方案として、ＳＴＡはそれぞれランダムバックオフカウントを選択し、それに該当するスロット時間だけ待機した後に、送信を試みることができる。ランダムバックオフカウントは、擬似ランダム整数（ｐｓｅｕｄｏ－ｒａｎｄｏｍ ｉｎｔｅｇｅｒ）値を有し、０～ＣＷの範囲の値のいずれか１つに決定されてよい。ここで、ＣＷは、競合ウィンドウ（Ｃｏｎｔｅｎｔｉｏｎ Ｗｉｎｄｏｗ）パラメータ値である。ＣＷパラメータは、初期値としてＣＷｍｉｎが与えられるが、送信失敗の場合（例えば、送信されたフレームに対するＡＣＫを受信できなかった場合）に２倍の値を取ることができる。ＣＷパラメータ値がＣＷｍａｘになると、データ送信に成功するまでＣＷｍａｘ値を維持しながらデータ送信を試みることができ、データ送信に成功する場合にはＣＷｍｉｎ値にリセットされる。ＣＷ、ＣＷｍｉｎ及びＣＷｍａｘ値は、２ｎ－１（ｎ＝０，１，２，．．．）に設定されることが好ましい。
【0084】
ランダムバックオフ過程が始まると、ＳＴＡは、決定されたバックオフカウント値によってバックオフスロットをカウントダウンする間に続けて媒体をモニターする。媒体が占有状態としてモニターされると、カウントダウンを止めて待機し、媒体が遊休状態になると、残りのカウントダウンを再開する。
【0085】
図４の例示において、ＳＴＡ３のＭＡＣに、送信するパケットが到達した場合に、ＳＴＡ３は、ＤＩＦＳだけ媒体が遊休状態であることを確認し、直ちにフレームを送信できる。残りのＳＴＡは、媒体が占有／ビジー状態であることをモニターし、待機する。そうする間に、ＳＴＡ１、ＳＴＡ２及びＳＴＡ５のそれぞれにおいても送信するデータが発生することがあり、各ＳＴＡは、媒体が遊休状態としてモニターされると、ＤＩＦＳだけ待機した後に、各自が選択したランダムバックオフカウント値によってバックオフスロットのカウントダウンを行うことができる。ＳＴＡ２が最小のバックオフカウント値を選択し、ＳＴＡ１が最大のバックオフカウント値を選択した場合を仮定する。すなわち、ＳＴＡ２がバックオフカウントを終えてフレーム送信を始める時点においてＳＴＡ５の残余バックオフ時間はＳＴＡ１の残余バックオフ時間よりも短い場合を例示する。ＳＴＡ１及びＳＴＡ５は、ＳＴＡ２が媒体を占有する間にしばらくカウントダウンを止めて待機する。ＳＴＡ２の占有が終了して媒体が再び遊休状態になると、ＳＴＡ１及びＳＴＡ５はＤＩＦＳだけ待機した後に、止めていたバックオフカウントを再開する。すなわち、残余バックオフ時間だけの残余バックオフスロットをカウントダウンした後にフレーム送信を開始することができる。ＳＴＡ５の残余バックオフ時間がＳＴＡ１よりも短かったので、ＳＴＡ５がフレーム送信を始めるようになる。ＳＴＡ２が媒体を占有する間にＳＴＡ４においても送信するデータが発生することがある。ＳＴＡ４の立場では、媒体が遊休状態になると、ＤＩＦＳだけ待機した後、自分が選択したランダムバックオフカウント値によるカウントダウンを行い、フレーム送信を始めることができる。図４の例示では、ＳＴＡ５の残余バックオフ時間がＳＴＡ４のランダムバックオフカウント値と偶然に一致する場合を示しており、この場合、ＳＴＡ４とＳＴＡ５との間に衝突が発生することがある。衝突が発生する場合には、ＳＴＡ４とＳＴＡ５は両方ともＡＣＫを受信できず、データ送信に失敗することになる。この場合、ＳＴＡ４とＳＴＡ５は、ＣＷ値を２倍に増やした後にランダムバックオフカウント値を選択し、カウントダウンを行うことができる。ＳＴＡ１は、ＳＴＡ４とＳＴＡ５の送信によって媒体が占有状態である間に待機しているが、媒体が遊休状態になるとＤＩＦＳだけ待機した後、残余バックオフ時間が過ぎるとフレーム送信を始めることができる。
【0086】
図４の例示におけるように、データフレームは、上位レイヤにフォワードされるデータの送信のために用いられるフレームであり、媒体が遊休状態になった時からＤＩＦＳの経過後に行われるバックオフ後に送信されてよい。さらに、管理フレームは、上位レイヤにフォワードされない管理情報の交換のために用いられるフレームであり、ＤＩＦＳ又はＰＩＦＳ（Ｐｏｉｎｔ ｃｏｏｒｄｉｎａｔｉｏｎ ｆｕｎｃｔｉｏｎ ＩＦＳ）のようなＩＦＳの経過後に行われるバックオフ後に送信される。管理フレームのサブタイプフレームとして、ビーコン（Ｂｅａｃｏｎ）、結合要請／応答（Ａｓｓｏｃｉａｔｉｏｎ ｒｅｑｕｅｓｔ／ｒｅｓｐｏｎｓｅ）、再（ｒｅ）－結合要請／応答、プローブ要請／応答（ｐｒｏｂｅ ｒｅｑｕｅｓｔ／ｒｅｓｐｏｎｓｅ）、認証要請／応答（ａｕｔｈｅｎｔｉｃａｔｉｏｎ ｒｅｑｕｅｓｔ／ｒｅｓｐｏｎｓｅ）などがある。制御フレームは、媒体にアクセスを制御するために用いられるフレームである。制御フレームのサブタイプフレームとして、ＲＴＳ（Ｒｅｑｕｅｓｔ－Ｔｏ－Ｓｅｎｄ）、ＣＴＳ（Ｃｌｅａｒ－Ｔｏ－Ｓｅｎｄ）、ＡＣＫ（Ａｃｋｎｏｗｌｅｄｇｍｅｎｔ）、ＰＳ－Ｐｏｌｌ（Ｐｏｗｅｒ Ｓａｖｅ－Ｐｏｌｌ）、ブロックＡＣＫ（ＢｌｏｃｋＡｃｋ）、ブロックＡＣＫ要請（ＢｌｏｃｋＡＣＫＲｅｑ）、ＮＤＰ公知（ｎｕｌｌ ｄａｔａ ｐａｃｋｅｔ ａｎｎｏｕｎｃｅｍｅｎｔ）、トリガー（Ｔｒｉｇｇｅｒ）などがある。制御フレームは、以前フレームの応答フレームでない場合に、ＤＩＦＳの経過後に行われるバックオフ後に送信され、以前フレームの応答フレームである場合に、ＳＩＦＳ（ｓｈｏｒｔ ＩＦＳ）経過後にバックオフ無しで送信される。フレームのタイプとサブタイプは、フレーム制御（ＦＣ）フィールド内のタイプ（ｔｙｐｅ）フィールドとサブタイプ（ｓｕｂｔｙｐｅ）フィールドによって識別されてよい。
【0087】
ＱｏＳ（Ｑｕａｌｉｔｙ ｏｆ Ｓｅｒｖｉｃｅ）ＳＴＡは、フレームの属するアクセスカテゴリー（ａｃｃｅｓｓ ｃａｔｅｇｏｒｙ，ＡＣ）のためのＡＩＦＳ（ａｒｂｉｔｒａｔｉｏｎ ＩＦＳ）、すなわち、ＡＩＦＳ［ｉ］（ここで、ｉは、ＡＣによって決定される値）の経過後に行われるバックオフ後にフレームを送信できる。ここで、ＡＩＦＳ［ｉ］の使用が可能なフレームは、データフレーム、管理フレームになり得、また、応答フレームでない制御フレームになり得る。
【0088】
図５は、本開示の適用が可能なＣＳＭＡ／ＣＡベースフレーム送信動作を説明するための図である。
【0089】
前述したように、ＣＳＭＡ／ＣＡメカニズムは、ＳＴＡが媒体を直接センシングする物理的キャリアセンシング（ｐｈｙｓｉｃａｌ ｃａｒｒｉｅｒ ｓｅｎｓｉｎｇ）の他に仮想キャリアセンシング（ｖｉｒｔｕａｌ ｃａｒｒｉｅｒ ｓｅｎｓｉｎｇ）も含む。仮想キャリアセンシングは、隠れノード問題（ｈｉｄｄｅｎ ｎｏｄｅ ｐｒｏｂｌｅｍ）などのように、媒体アクセスで発生し得る問題を補完するためのものである。仮想キャリアセンシングのために、ＳＴＡのＭＡＣは、ＮＡＶ（Ｎｅｔｗｏｒｋ Ａｌｌｏｃａｔｉｏｎ Ｖｅｃｔｏｒ）を利用できる。ＮＡＶは、現在媒体を使用しているか又は使用する権限があるＳＴＡが、媒体が利用可能な状態になるまで残っている時間を、他のＳＴＡに指示（ｉｎｄｉｃａｔｅ）する値である。したがって、ＮＡＶとして設定された値は、当該フレームを送信するＳＴＡによって媒体の使用が予定されている期間に該当し、ＮＡＶ値を受信するＳＴＡは当該期間において媒体アクセスが禁止される。例えば、ＮＡＶは、フレームのＭＡＣヘッダー（ｈｅａｄｅｒ）の「ｄｕｒａｔｉｏｎ」フィールドの値に基づいて設定されてよい。
【0090】
図５の例示において、ＳＴＡ１はＳＴＡ２にデータを送信しようとしており、ＳＴＡ３はＳＴＡ１とＳＴＡ２との間に送受信されるフレームの一部又は全部をオーバーヒヤリング（ｏｖｅｒｈｅａｒｉｎｇ）し得る位置にあると仮定する。
【0091】
ＣＳＭＡ／ＣＡベースフレーム送信動作において複数のＳＴＡの送信の衝突可能性を減少させるために、ＲＴＳ／ＣＴＳフレームを利用するメカニズムが適用されてよい。図５の例示で、ＳＴＡ１の送信が行われる間に、ＳＴＡ３のキャリアセンシングの結果、媒体が遊休状態であると決定することもある。すなわち、ＳＴＡ１がＳＴＡ３には隠れノードに該当し得る。又は、図５の例示で、ＳＴＡ２の送信が行われる間に、ＳＴＡ３のキャリアセンシングの結果、媒体が遊休状態であると決定することもある。すなわち、ＳＴＡ２がＳＴＡ３には隠れノードに該当し得る。ＳＴＡ１とＳＴＡ２間のデータ送受信を行う前に、ＲＴＳ／ＣＴＳフレームの交換により、ＳＴＡ１又はＳＴＡ２のいずれか一方の送信範囲外のＳＴＡ、又はＳＴＡ１又はＳＴＡ３からの送信に対するキャリアセンシング範囲外のＳＴＡが、ＳＴＡ１とＳＴＡ２間のデータ送受信の間にチャネル占有を試みないようにすることができる。
【0092】
具体的には、ＳＴＡ１は、キャリアセンシング（ｃａｒｒｉｅｒ ｓｅｎｓｉｎｇ）を用いて、チャネルが使用されているか否かを決定できる。物理的キャリアセンシングの側面で、ＳＴＡ１は、チャネルから検出されるエネルギー大きさ又は信号相関度（ｃｏｒｒｅｌａｔｉｏｎ）に基づいてチャネル占有遊休状態を決定できる。また、仮想キャリアセンシング側面で、ＳＴＡ１は、ＮＡＶ（ｎｅｔｗｏｒｋ ａｌｌｏｃａｔｉｏｎ ｖｅｃｔｏｒ）タイマー（ｔｉｍｅｒ）を用いて、チャネルの占有状態を判断できる。
【0093】
ＳＴＡ１は、ＤＩＦＳにおいてチャネルが遊休状態である場合に、バックオフを行った後にＲＴＳフレームをＳＴＡ２に送信できる。ＳＴＡ２は、ＲＴＳフレームを受信した場合に、ＳＩＦＳ後にＲＴＳフレームに対する応答であるＣＴＳフレームをＳＴＡ１に送信することができる。
【0094】
ＳＴＡ３がＳＴＡ２からのＣＴＳフレームをオーバーヒヤリングすることはできないが、ＳＴＡ１からのＲＴＳフレームをオーバーヒヤリングできる場合には、ＳＴＡ３は、ＲＴＳフレームに含まれたデュレーション（ｄｕｒａｔｉｏｎ）情報を用いて、後で連続して送信されるフレーム送信期間（例えば、ＳＩＦＳ＋ＣＴＳフレーム＋ＳＩＦＳ＋データフレーム＋ＳＩＦＳ＋ＡＣＫフレーム）に対するＮＡＶタイマーを設定することができる。又は、ＳＴＡ３がＳＴＡ１からのＲＴＳフレームをオーバーヒヤリングすることはできないが、ＳＴＡ２からのＣＴＳフレームをオーバーヒヤリングできる場合には、ＳＴＡ３は、ＣＴＳフレームに含まれたデュレーション情報を用いて、後で連続して送信されるフレーム送信期間（例えば、ＳＩＦＳ＋データフレーム＋ＳＩＦＳ＋ＡＣＫフレーム）に対するＮＡＶタイマーを設定できる。すなわち、ＳＴＡ３は、ＳＴＡ１又はＳＴＡ２の少なくとも一方からのＲＴＳ又はＣＴＳフレームのうち１つ以上をオーバーヒヤリングできる場合に、それに基づいてＮＡＶを設定できる。ＳＴＡ３は、ＮＡＶタイマーが満了する前に新しいフレームを受信した場合に、新しいフレームに含まれたデュレーション情報を用いて、ＮＡＶタイマーを更新することができる。ＳＴＡ３は、ＮＡＶタイマーが満了するまでチャネルアクセスを試みない。
【0095】
ＳＴＡ１は、ＳＴＡ２からＣＴＳフレームを受信した場合に、ＣＴＳフレームの受信が完了した時点からＳＩＦＳ後に、データフレームをＳＴＡ２に送信することができる。ＳＴＡ２は、データフレームを成功裏に受信した場合に、ＳＩＦＳ後に、データフレームに対する応答であるＡＣＫフレームを、ＳＴＡ１に送信できる。ＳＴＡ３は、ＮＡＶタイマーが満了した場合に、キャリアセンシングを用いて、チャネルが使用されているか否かを決定できる。ＳＴＡ３は、ＮＡＶタイマーの満了後からＤＩＦＳの間にチャネルが他の端末によって使用されないと決定した場合に、ランダムバックオフによる競合ウィンドウ（ＣＷ）が過ぎた後にチャネルアクセスを試みることができる。
【0096】
図６は、本開示の適用が可能な無線ＬＡＮシステムにおいて用いられるフレーム構造の例示を説明するための図である。
【0097】
ＭＡＣ層からの命令語（ｉｎｓｔｒｕｃｔｉｏｎ）又はプリミティブ（ｐｒｉｍｉｔｉｖｅ）（命令語又はパラメータのセットを意味）によって、ＰＨＹ層は、送信されるＭＰＤＵ（ＭＡＣ ＰＤＵ）を準備することができる。例えば、ＰＨＹ層の送信開始を要請する命令語をＭＡＣ層から受けると、ＰＨＹ層では送信モードにスイッチし、ＭＡＣ層から提供される情報（例えば、データ）をフレームの形態で構成して送信することができる。また、ＰＨＹ層では、受信するフレームの有効なプリアンブル（ｐｒｅａｍｂｌｅ）を検出すると、プリアンブルのヘッダーをモニターし、ＰＨＹ層の受信開始を知らせる命令語をＭＡＣ層に送る。
【0098】
このように、無線ＬＡＮシステムにおける情報送信／受信はフレームの形態でなされ、そのために、ＰＨＹ層プロトコルデータユニット（Ｐｈｙｓｉｃａｌ ｌａｙｅｒ Ｐｒｏｔｏｃｏｌ Ｄａｔａ Ｕｎｉｔ，ＰＰＤＵ）フレームフォーマットが定義される。
【0099】
基本的なＰＰＤＵフレームは、ＳＴＦ（Ｓｈｏｒｔ Ｔｒａｉｎｉｎｇ Ｆｉｅｌｄ）、ＬＴＦ（Ｌｏｎｇ Ｔｒａｉｎｉｎｇ Ｆｉｅｌｄ）、ＳＩＧ（ＳＩＧＮＡＬ）フィールド、及びデータ（Ｄａｔａ）フィールドを含んでよい。最も基本的な（例えば、ｎｏｎ－ＨＴ（Ｈｉｇｈ Ｔｈｒｏｕｇｈｐｕｔ））ＰＰＤＵフレームフォーマットは、Ｌ－ＳＴＦ（Ｌｅｇａｃｙ－ＳＴＦ）、Ｌ－ＬＴＦ（Ｌｅｇａｃｙ－ＬＴＦ）、ＳＩＧフィールド、及びデータフィールドのみで構成されてよい。また、ＰＰＤＵフレームフォーマットの種類（例えば、ＨＴ－ｍｉｘｅｄフォーマットＰＰＤＵ、ＨＴ－ｇｒｅｅｎｆｉｅｌｄフォーマットＰＰＤＵ、ＶＨＴ（Ｖｅｒｙ Ｈｉｇｈ Ｔｈｒｏｕｇｈｐｕｔ）ＰＰＤＵなど）によって、ＳＩＧフィールドとデータフィールドとの間に追加の（又は、他の種類の）ＳＴＦ、ＬＴＦ、ＳＩＧフィールドが含まれてもよい（これについては図７を参照して後述する）。
【0100】
ＳＴＦは、信号検出、ＡＧＣ（Ａｕｔｏｍａｔｉｃ Ｇａｉｎ Ｃｏｎｔｒｏｌ）、ダイバーシチ選択、精密な時間同期などのための信号であり、ＬＴＦは、チャネル推定、周波数誤差推定などのための信号である。ＳＴＦとＬＴＦは、ＯＦＤＭ物理層の同期化及びチャネル推定のための信号であるといえる。
【0101】
ＳＩＧフィールドは、ＲＡＴＥフィールド及びＬＥＮＧＴＨフィールドなどを含んでよい。ＲＡＴＥフィールドは、データの変調及びコーディングレートに関する情報を含んでよい。ＬＥＮＧＴＨフィールドは、データの長さに関する情報を含んでよい。さらに、ＳＩＧフィールドは、パリティ（ｐａｒｉｔｙ）ビット、ＳＩＧ ＴＡＩＬビットなどを含んでよい。
【0102】
データフィールドは、ＳＥＲＶＩＣＥフィールド、ＰＳＤＵ（Ｐｈｙｓｉｃａｌ ｌａｙｅｒ Ｓｅｒｖｉｃｅ Ｄａｔａ Ｕｎｉｔ）、ＰＰＤＵ ＴＡＩＬビットを含んでよく、必要な場合には、パディングビットも含んでよい。ＳＥＲＶＩＣＥフィールドの一部ビットは、受信端におけるデスクランブラの同期化のために用いられてよい。ＰＳＤＵは、ＭＡＣ層で定義されるＭＡＣ ＰＤＵに対応し、上位層で生成／利用されるデータを含んでよい。ＰＰＤＵ ＴＡＩＬビットは、エンコーダを０状態にリターンするために用いられてよい。パディングビットは、データフィールドの長さを所定の単位に合わせるために用いられてよい。
【0103】
ＭＡＣ ＰＤＵは、様々なＭＡＣフレームフォーマットによって定義され、基本的なＭＡＣフレームは、ＭＡＣヘッダー、フレームボディー、及びＦＣＳ（Ｆｒａｍｅ Ｃｈｅｃｋ Ｓｅｑｕｅｎｃｅ）で構成される。ＭＡＣフレームはＭＡＣ ＰＤＵで構成され、ＰＰＤＵフレームフォーマットのデータ部分のＰＳＤＵによって送信／受信されてよい。
【0104】
ＭＡＣヘッダーは、フレーム制御（Ｆｒａｍｅ Ｃｏｎｔｒｏｌ）フィールド、デュレーション（Ｄｕｒａｔｉｏｎ）／ＩＤフィールド、アドレス（Ａｄｄｒｅｓｓ）フィールドなどを含む。フレーム制御フィールドは、フレーム送信／受信に必要な制御情報を含んでよい。デュレーション／ＩＤフィールドは、当該フレームなどを送信するための時間に設定されてよい。ＭＡＣヘッダーのＳｅｑｕｅｎｃｅ Ｃｏｎｔｒｏｌ、ＱｏＳ Ｃｏｎｔｒｏｌ、ＨＴ Ｃｏｎｔｒｏｌサブフィールドの具体的な内容は、ＩＥＥＥ ８０２．１１標準文書を参照できる。
【0105】
ヌルデータパケット（ＮＤＰ）フレームフォーマットは、データパケットを含まない形態のフレームフォーマットを意味する。すなわち、ＮＤＰフレームは、一般的なＰＰＤＵフレームフォーマットにおいてＰＬＣＰ（ｐｈｙｓｉｃａｌ ｌａｙｅｒ ｃｏｎｖｅｒｇｅｎｃｅ ｐｒｏｃｅｄｕｒｅ）ヘッダー部分（すなわち、ＳＴＦ、ＬＴＦ、及びＳＩＧフィールド）を含み、残りの部分（すなわち、データフィールド）は含まないフレームフォーマットを意味する。ＮＤＰフレームは、短い（ｓｈｏｒｔ）フレームフォーマットと称することもできる。
【0106】
図７は、本開示の適用が可能なＩＥＥＥ ８０２．１１標準において定義されるＰＰＤＵの例示を示す図である。
【0107】
ＩＥＥＥ ８０２．１１ａ／ｇ／ｎ／ａｃ／ａｘなどの標準では様々な形態のＰＰＤＵが使用されている。基本的なＰＰＤＵフォーマット（ＩＥＥＥ ８０２．１１ａ／ｇ）は、Ｌ－ＬＴＦ、Ｌ－ＳＴＦ、Ｌ－ＳＩＧ、及びＤａｔａフィールドを含む。基本的なＰＰＤＵフォーマットをｎｏｎ－ＨＴ ＰＰＤＵフォーマットと称することもできる。
【0108】
ＨＴ ＰＰＤＵフォーマット（ＩＥＥＥ ８０２．１１ｎ）は、ＨＴ－ＳＩＧ、ＨＴ－ＳＴＦ、ＨＴ－ＬＦＴ（ｓ）フィールドを、基本的なＰＰＤＵフォーマットにさらに含む。図７に示すＨＴ ＰＰＤＵフォーマットは、ＨＴ－ｍｉｘｅｄフォーマットと称することができる。ＨＴ－ｇｒｅｅｎｆｉｅｌｄフォーマットＰＰＤＵがさらに定義されてよく、これは、Ｌ－ＳＴＦ、Ｌ－ＬＴＦ、Ｌ－ＳＩＧを含まず、ＨＴ－ＧＦ－ＳＴＦ、ＨＴ－ＬＴＦ１、ＨＴ－ＳＩＧ、１つ以上のＨＴ－ＬＴＦ、Ｄａｔａフィールドで構成されるフォーマットに該当する（図示せず）。
【0109】
ＶＨＴ ＰＰＤＵフォーマット（ＩＥＥＥ ８０２．１１ａｃ）の一例は、ＶＨＴ ＳＩＧ－Ａ、ＶＨＴ－ＳＴＦ、ＶＨＴ－ＬＴＦ、ＶＨＴ－ＳＩＧ－Ｂフィールドを、基本的なＰＰＤＵフォーマットにさらに含む。
【0110】
ＨＥ ＰＰＤＵフォーマット（ＩＥＥＥ ８０２．１１ａｘ）の一例は、ＲＬ－ＳＩＧ（Ｒｅｐｅａｔｅｄ Ｌ－ＳＩＧ）、ＨＥ－ＳＩＧ－Ａ、ＨＥ－ＳＩＧ－Ｂ、ＨＥ－ＳＴＦ、ＨＥ－ＬＴＦ（ｓ）、ＰＥ（Ｐａｃｋｅｔ Ｅｘｔｅｎｓｉｏｎ）フィールドを、基本的なＰＰＤＵフォーマットにさらに含む。ＨＥ ＰＰＤＵフォーマットの細部例示によって、一部のフィールドが除外されるか又はその長さが変わることがある。例えば、ＨＥ－ＳＩＧ－Ｂフィールドは、多重ユーザ（ＭＵ）のためのＨＥ ＰＰＤＵフォーマットに含まれ、単一ユーザ（ＳＵ）のためのＨＥ ＰＰＤＵフォーマットにはＨＥ－ＳＩＧ－Ｂが含まれない。また、ＨＥトリガーベース（ｔｒｉｇｇｅｒ－ｂａｓｅｄ，ＴＢ）ＰＰＤＵフォーマットはＨＥ－ＳＩＧ－Ｂを含まず、ＨＥ－ＳＴＦフィールドの長さが８ｕｓに変わってよい。ＨＥ ＥＲ（Ｅｘｔｅｎｄｅｄ Ｒａｎｇｅ）ＳＵ ＰＰＤＵフォーマットはＨＥ－ＳＩＧ－Ｂフィールドを含まず、ＨＥ－ＳＩＧ－Ａフィールドの長さが１６ｕｓに変わってよい。
【0111】
【0112】
図８～図１０を参照して、無線ＬＡＮシステムにおいて定義されるリソースユニット（ｒｅｓｏｕｒｃｅ ｕｎｉｔ，ＲＵ）について説明する。ＲＵは、複数個のサブキャリア（又は、トーン）を含んでよい。ＲＵは、ＯＦＤＭＡ手法に基づいて複数のＳＴＡに信号を送信する場合に用いられてよい。また、１つのＳＴＡに信号を送信する場合にも、ＲＵが定義されてよい。ＲＵは、ＰＰＤＵのＳＴＦ、ＬＴＦ、データフィールドなどのために用いられてよい。
【0113】
図８～図１０に示すように、互いに異なる個数のトーン（すなわち、サブキャリア）に対応するＲＵが使用され、２０ＭＨｚ、４０ＭＨｚ、又は８０ＭＨｚ Ｘ－ＰＰＤＵ（Ｘは、ＨＥ、ＥＨＴなど）の一部フィールドを構成することができる。例えば、Ｘ－ＳＴＦ、Ｘ－ＬＴＦ、Ｄａｔａフィールドに対して示すＲＵ単位でリソースが割り当てられてよい。
【0114】
図８は、２０ＭＨｚ帯域上で用いられるリソースユニット（ＲＵ）の例示的な配置を示す図である。
【0115】
図８の最上端に示すように、２６ユニット（すなわち、２６個のトーンに相応するユニット）が配置（ａｌｌｏｃａｔｅ）されてよい。２０ＭＨｚ帯域の最左側（ｌｅｆｔｍｏｓｔ）帯域には６個のトーンがガード（Ｇｕａｒｄ）帯域として用いられ、２０ＭＨｚ帯域の最右側（ｒｉｇｈｔｍｏｓｔ）帯域には５個のトーンがガード帯域として用いられてよい。また、中心帯域、すなわちＤＣ帯域には７個のＤＣトーンが挿入され、ＤＣ帯域の左右側にそれぞれ１３個のトーンに相応する２６ユニットが存在してよい。また、その他の帯域には２６ユニット、５２ユニット、１０６ユニットが割り当てられてよい。各ユニットは、ＳＴＡ又はユーザのために割り当てられてよい。
【0116】
図８のＲＵ配置は、複数のユーザ（ＭＵ）のための状況だけでなく、単一ユーザ（ＳＵ）のための状況においても活用され、この場合には、図８の最下端に示すように１個の２４２ユニットを使用することが可能である。この場合には、３個のＤＣトーンが挿入されてよい。
【0117】
図８の一例では、様々なサイズのＲＵ、すなわち、２６－ＲＵ、５２－ＲＵ、１０６－ＲＵ、２４２－ＲＵなどが例示されるが、このようなＲＵの具体的なサイズは縮小又は拡張されてよい。したがって、本開示において各ＲＵの具体的なサイズ（すなわち、相応するトーンの個数）は限定されず、例示的なものである。また、本開示において、所定の帯域幅（例えば、２０、４０、８０、１６０、３２０ＭＨｚ、．．．）内で、ＲＵの個数はＲＵのサイズによって異なってよい。以下に説明する図９及び／又は図１０の例示においてＲＵのサイズ及び／又は個数が変更され得るという点は、図８の例示と同一である。
【0118】
図９は、４０ＭＨｚ帯域上で用いられるリソースユニット（ＲＵ）の例示的な配置を示す図である。
【0119】
図８の一例において様々なサイズのＲＵが用いられたのと同一に、図９の一例においても２６－ＲＵ、５２－ＲＵ、１０６－ＲＵ、２４２－ＲＵ、４８４－ＲＵなどが用いられてよい。また、中心周波数には５個のＤＣトーンが挿入されてよく、４０ＭＨｚ帯域の最左側（ｌｅｆｔｍｏｓｔ）帯域には１２個のトーンがガード（Ｇｕａｒｄ）帯域として用いられ、４０ＭＨｚ帯域の最右側（ｒｉｇｈｔｍｏｓｔ）帯域には１１個のトーンがガード帯域として用いられてよい。
【0120】
また、同図に示すように、単一ユーザのために用いられる場合に、４８４－ＲＵが用いられてよい。
【0121】
図１０は、８０ＭＨｚ帯域上で用いられるリソースユニット（ＲＵ）の例示的な配置を示す図である。
【0122】
図８及び図９の一例において様々なサイズのＲＵが用いられたのと同一に、図１０の一例においても２６－ＲＵ、５２－ＲＵ、１０６－ＲＵ、２４２－ＲＵ、４８４－ＲＵ、９９６－ＲＵなどが用いられてよい。また、８０ＭＨｚ ＰＰＤＵでは、ＨＥ ＰＰＤＵとＥＨＴ ＰＰＤＵのＲＵ配置が互いに異なってよく、図１０の例示は、８０ＭＨｚ ＥＨＴ ＰＰＤＵに対するＲＵ配置の例示を示す。図１０の例示において、８０ＭＨｚ帯域の最左側（ｌｅｆｔｍｏｓｔ）帯域には１２個のトーンがガード（Ｇｕａｒｄ）帯域として用いられ、８０ＭＨｚ帯域の最右側（ｒｉｇｈｔｍｏｓｔ）帯域には１１個のトーンがガード帯域として用いられる点は、ＨＥ ＰＰＤＵとＥＨＴ ＰＰＤＵにおいて同一である。ＨＥ ＰＰＤＵにおいてＤＣ帯域に７個のＤＣトーンが挿入され、ＤＣ帯域の左右側に、各１３個のトーンに相応する１つの２６－ＲＵが存在するのと違い、ＥＨＴ ＰＰＤＵでは、ＤＣ帯域は２３個のＤＣトーンが挿入され、ＤＣ帯域左側及び右側に１つずつの２６－ＲＵが存在する。ＨＥ ＰＰＤＵにおいて中心帯域でない２４２－ＲＵの間に１つのヌルサブキャリアが存在するのと違い、ＥＨＴ ＰＰＤＵでは５個のヌルサブキャリアが存在する。ＨＥ ＰＰＤＵにおいて１つの４８４－ＲＵはヌルサブキャリアを含まないが、ＥＨＴ ＰＰＤＵでは１つの４８４－ＲＵが５個のヌルサブキャリアを含む。
【0123】
また、同図に示すように、単一ユーザのために用いられる場合に、９９６－ＲＵが用いられてよく、この場合に５個のＤＣトーンが挿入されることは、ＨＥ ＰＰＤＵとＥＨＴ ＰＰＤＵにおいて共通する。
【0124】
１６０ＭＨｚ以上のＥＨＴ ＰＰＤＵは、図１０の８０ＭＨｚサブブロックの複数個で設定されてよい。それぞれの８０ＭＨｚサブブロックに対するＲＵ配置は、図１０の８０ＭＨｚ ＥＨＴ ＰＰＤＵのＲＵ配置と同一であってよい。１６０ＭＨｚ又は３２０ＭＨｚ ＥＨＴ ＰＰＤＵの８０ＭＨｚサブブロックがパンクチャリング（ｐｕｎｃｔｕｒｉｎｇ）されず、全体８０ＭＨｚサブブロックがＲＵ又はＭＲＵ（Ｍｕｌｔｉｐｌｅ ＲＵ）の一部として用いられる場合に、８０ＭＨｚサブブロックは、図１０の９９６－ＲＵを使用することができる。
【0125】
ここで、ＭＲＵは、複数のＲＵで構成されるサブキャリア（又は、トーン）のグループに該当し、ＭＲＵを構成する複数のＲＵは、同じサイズのＲＵであってもよく、互いに異なるサイズのＲＵであってもよい。例えば、単一ＭＲＵは、５２＋２６－トーン、１０６＋２６－トーン、４８４＋２４２－トーン、９９６＋４８４－トーン、９９６＋４８４＋２４２－トーン、２×９９６＋４８４－トーン、３×９９６－トーン、又は３×９９６＋４８４－トーンと定義されてよい。ここで、１つのＭＲＵを構成する複数のＲＵは、小さなサイズ（例えば、２６、５２、１０６）のＲＵに該当するか、又は大きなサイズ（例えば、２４２、４８４、９９６など）のＲＵに該当してよい。すなわち、小さいサイズのＲＵと大きいサイズのＲＵを含む１つのＭＲＵは、設定／定義されなくてもよい。また、１つのＭＲＵを構成する複数のＲＵは、周波数ドメインにおいて連続してもよく、連続しなくてもよい。
【0126】
８０ＭＨｚサブブロックが９９６トーンよりも小さいＲＵを含むか、８０ＭＨｚサブブロックの部分がパンクチャリングされた場合に、８０ＭＨｚサブブロックは、９９６－トーンＲＵを除くＲＵ配置を使用することができる。
【0127】
本開示のＲＵは、上りリンク（ＵＬ）及び／又は下りリンク（ＤＬ）通信に用いられてよい。例えば、トリガーベース（ｔｒｉｇｇｅｒ－ｂａｓｅｄ）ＵＬ－ＭＵ通信が行われる場合に、トリガーを送信するＳＴＡ（例えば、ＡＰ）は、トリガー情報（例えば、トリガーフレーム又はＴＲＳ（ｔｒｉｇｇｅｒｅｄ ｒｅｓｐｏｎｓｅ ｓｃｈｅｄｕｌｉｎｇ））を用いて、第１ＳＴＡには第１ＲＵ（例えば、２６／５２／１０６／２４２－ＲＵなど）を割り当て、第２ＳＴＡには第２ＲＵ（例えば、２６／５２／１０６／２４２－ＲＵなど）を割り当てることができる。その後、第１ＳＴＡは、第１ＲＵに基づいて第１のトリガーベース（ＴＢ） ＰＰＤＵを送信でき、第２ＳＴＡは、第２ＲＵに基づいて第２のＴＢ ＰＰＤＵを送信できる。第１／第２のＴＢ ＰＰＤＵは、同じ時間区間でＡＰに送信されてよい。
【0128】
例えば、ＤＬ ＭＵ ＰＰＤＵが構成される場合に、ＤＬ ＭＵ ＰＰＤＵを送信するＳＴＡ（例えば、ＡＰ）は、第１ＳＴＡには第１ＲＵ（例えば、２６／５２／１０６／２４２－ＲＵなど）を割り当て、第２ＳＴＡには第２ＲＵ（例えば、２６／５２／１０６／２４２－ＲＵなど）を割り当てることができる。すなわち、送信ＳＴＡ（例えば、ＡＰ）は、１つのＭＵ ＰＰＤＵ内で第１ＲＵを用いて第１ＳＴＡのためのＨＥ－ＳＴＦ、ＨＥ－ＬＴＦ、Ｄａｔａフィールドを送信でき、第２ＲＵを用いて第２ＳＴＡのためのＨＥ－ＳＴＦ、ＨＥ－ＬＴＦ、Ｄａｔａフィールドを送信できる。
【0129】
ＲＵの配置に関する情報は、ＨＥ ＰＰＤＵフォーマットのＨＥ－ＳＩＧ－Ｂでシグナルされてよい。
【0130】
図１１は、ＨＥ－ＳＩＧ－Ｂフィールドの例示的な構造を示す。
【0131】
同図に示すように、ＨＥ－ＳＩＧ－Ｂフィールドは、共通（ｃｏｍｍｏｎ）フィールド及びユーザ－特定（ｕｓｅｒ－ｓｐｅｃｉｆｉｃ）フィールドを含んでよい。ＨＥ－ＳＩＧ－Ｂ圧縮（ｃｏｍｐｒｅｓｓｉｏｎ）が適用される場合（例えば、全帯域幅ＭＵ－ＭＩＭＯ送信である場合）に、共通フィールドは、ＨＥ－ＳＩＧ－Ｂに含まれなくてもよく、ＨＥ－ＳＩＧ－Ｂコンテンツチャネル（ｃｏｎｔｅｎｔ ｃｈａｎｎｅｌ）は、ユーザ－特定フィールドのみを含んでよい。ＨＥ－ＳＩＧ－Ｂ圧縮が適用されない場合に、共通フィールドはＨＥ－ＳＩＧ－Ｂに含まれてよい。
【0132】
共通フィールドは、ＲＵ配置（ａｌｌｏｃａｔｉｏｎ）に関する情報（例えば、ＲＵ割り当て（ａｓｓｉｇｎｍｅｎｔ）、ＭＵ－ＭＩＭＯのために配置されるＲＵ、ＭＵ－ＭＩＭＯユーザ（ＳＴＡ）数など）に関する情報を含んでよい。
【0133】
共通フィールドは、Ｎ＊８個のＲＵ ａｌｌｏｃａｔｉｏｎサブフィールドを含んでよい。ここで、Ｎはサブフィールドの個数であり、２０又は４０ＭＨｚ ＭＵ ＰＰＤＵである場合にＮ＝１、８０ＭＨｚ ＭＵ ＰＰＤＵである場合にＮ＝２、１６０ＭＨｚ又は８０＋８０ＭＨｚ ＭＵ ＰＰＤＵである場合にＮ＝４、．．．の値を有してよい。１つの８ビットのＲＵ ａｌｌｏｃａｔｉｏｎサブフィールドは、２０ＭＨｚ帯域に含まれるＲＵのサイズ（２６、５２、１０６など）及び周波数位置（又は、ＲＵインデックス）を指示することができる。
【0134】
例えば、８ビットのＲＵ ａｌｌｏｃａｔｉｏｎサブフィールドの値が００００００００であれば、図８の例示の最左側から最右側まで９個の２６－ＲＵが順に配置され、その値が０００００００１であれば、７個の２６－ＲＵ及び１個の５２－ＲＵが最左側から最右側まで順に配置され、その値が００００００１０であれば、５個の２６－ＲＵ、１個の５２－ＲＵ、２個の２６－ＲＵが最左側から最右側まで順に配置されることを示すことができる。
【0135】
追加の例示として、８ビットのＲＵ ａｌｌｏｃａｔｉｏｎサブフィールドの値が０１０００ｙ２ｙ１ｙ０であれば、図８の例示の最左側から最右側まで１個の１０６－ＲＵ、５個の２６－ＲＵが順に配置されることを示すことができる。この場合、１０６－ＲＵに対しては、ＭＵ－ＭＩＭＯ方式で複数のユーザ／ＳＴＡが割り当てられてよい。具体的には、１０６－ＲＵに対しては最大で８個のユーザ／ＳＴＡが割り当てられてよく、１０６－ＲＵに割り当てられるユーザ／ＳＴＡの個数は、３ビット情報（すなわち、ｙ２ｙ１ｙ０）に基づいて決定される。例えば、３ビット情報（ｙ２ｙ１ｙ０）が十進数値Ｎに該当する場合に、１０６－ＲＵに割り当てられるユーザ／ＳＴＡの個数はＮ＋１であってよい。
【0136】
基本的に、複数のＲＵのそれぞれに対して１つのユーザ／ＳＴＡが割り当てられてよく、互いに異なるＲＵに対して互いに異なるユーザ／ＳＴＡが割り当てられてよい。所定のサイズ以上のＲＵ（例えば、１０６、２４２、４８４、９９６－トーン、．．．）に対しては、複数のユーザ／ＳＴＡが１つのＲＵに割り当てられてもよく、当該複数のユーザ／ＳＴＡに対してＭＵ－ＭＩＭＯ方式が適用されてよい。
【0137】
ユーザ－特定フィールドの集合は、当該ＰＰＤＵの全てのユーザ（ＳＴＡ）が、自分のペイロードをどのようにデコードするかに関する情報を含む。ユーザ－特定フィールドは、０以上のユーザブロックフィールドを含んでよい。最後でない（ｎｏｎ－ｆｉｎａｌ）ユーザブロックフィールドは、２つのユーザフィールド（すなわち、２つのＳＴＡにおけるデコーディングに用いられる情報）を含む。最後の（ｆｉｎａｌ）ユーザブロックフィールドは、１つ又は２つのユーザフィールドを含む。ユーザフィールドの個数は、ＨＥ－ＳＩＧ－ＢのＲＵ ａｌｌｏｃａｔｉｏｎサブフィールドによって指示されるか、ＨＥ－ＳＩＧ－Ｂのシンボル個数によって指示されるか、又はＨＥ－ＳＩＧ－ＡのＭＵ－ＭＩＭＯユーザフィールドによって指示されてもよい。ユーザ－特定フィールドは共通フィールドと別に又は独立にエンコードされてよい。
【0138】
図１２は、複数のユーザ／ＳＴＡが１つのＲＵに割り当てられるＭＵ－ＭＩＭＯ方式を説明するための図である。
【0139】
図１２の例示では、ＲＵ ａｌｌｏｃａｔｉｏｎサブフィールドの値が０１００００１０である場合を仮定する。これは、０１０００ｙ２ｙ１ｙ０においてｙ２ｙ１ｙ０＝０１０である場合に該当する。０１０は十進数で２に該当し（すなわち、Ｎ＝２）、３（＝Ｎ＋１）個のユーザが１個のＲＵに割り当てられることを示すことができる。この場合、特定２０ＭＨｚ帯域／チャネルの最左側から最右側まで１個の１０６－ＲＵ、及び５個の２６－ＲＵが順に配置されてよい。１０６－ＲＵには、３個のユーザ／ＳＴＡがＭＵ－ＭＩＭＯ方式で割り当てられてよい。結果的に、総８個のユーザ／ＳＴＡが２０ＭＨｚ帯域／チャネルに割り当てられ、ＨＥ－ＳＩＧ－Ｂのユーザ－特定フィールドは８個のユーザフィールド（すなわち、４個のユーザブロックフィールド）を含んでよい。８個のユーザフィールドは、図１２に示すようにＲＵに割り当て（ａｓｓｉｇｎ）られてよい。
【0140】
ユーザフィールドは、２個のフォーマットに基づいて構成されてよい。ＭＵ－ＭＩＭＯ割り当てに対するユーザフィールドは、第１フォーマットで構成され、非－ＭＵ－ＭＩＭＯ割り当てに対するユーザフィールドは、第２フォーマットで構成されてよい。図１２の一例を参照すると、ユーザフィールド１～ユーザフィールド３は、第１フォーマットに基づくものであってよく、ユーザフィールド４～ユーザフィールド８は、第２フォーマットに基づくものであってよい。第１フォーマット及び第２フォーマットは、同じ長さ（例えば、２１ビット）のビット情報を含んでよい。
【0141】
第１フォーマット（すなわち、ＭＵ－ＭＩＭＯ割り当てに対するフォーマット）のユーザフィールドは、次のように構成されてよい。例えば、１つのユーザフィールドの全体２１ビットのうち、Ｂ０～Ｂ１０は、当該ユーザの識別情報（例えば、ＳＴＡ－ＩＤ、ＡＩＤ、部分ＡＩＤなど）を含み、Ｂ１１～１４は、当該ユーザに対する空間ストリームの個数などの空間設定（ｓｐａｔｉａｌ ｃｏｎｆｉｇｕｒａｔｉｏｎ）情報を含み、Ｂ１５～Ｂ１８は、当該ＰＰＤＵのＤａｔａフィールドに適用されるＭＣＳ（Ｍｏｄｕｌａｔｉｏｎ ａｎｄ ｃｏｄｉｎｇ ｓｃｈｅｍｅ）情報を含み、Ｂ１９は、留保された（ｒｅｓｅｒｖｅｄ）フィールドと定義され、Ｂ２０は、当該ＰＰＤＵのＤａｔａフィールドに適用されるコーディングタイプ（例えば、ＢＣＣ（ｂｉｎａｒｙ ｃｏｎｖｏｌｕｔｉｏｎａｌ ｃｏｄｉｎｇ）又はＬＤＰＣ（ｌｏｗ－ｄｅｎｓｉｔｙ ｐａｒｉｔｙ ｃｈｅｃｋ））情報を含んでよい。
【0142】
第２フォーマット（すなわち、非－ＭＵ－ＭＩＭＯ割り当てに対するフォーマット）のユーザフィールドは、次のように構成されてよい。例えば、１つのユーザフィールドの全体２１ビットのうち、Ｂ０～Ｂ１０は、当該ユーザの識別情報（例えば、ＳＴＡ－ＩＤ、ＡＩＤ、部分ＡＩＤなど）を含み、Ｂ１１～Ｂ１３は、当該ＲＵに適用される空間ストリームの個数（ＮＳＴＳ）情報を含み、Ｂ１４は、ビームフォーミングの可否（又は、ビームフォーミングステアリング行列適用の可否）を示す情報を含み、Ｂ１５～Ｂ１８は、当該ＰＰＤＵのＤａｔａフィールドに適用されるＭＣＳ（Ｍｏｄｕｌａｔｉｏｎ ａｎｄ ｃｏｄｉｎｇ ｓｃｈｅｍｅ）情報を含み、Ｂ１９は、ＤＣＭ（ｄｕａｌ ｃａｒｒｉｅｒ ｍｏｄｕｌａｔｉｏｎ）適用の可否を示す情報を含み、Ｂ２０は、当該ＰＰＤＵのＤａｔａフィールドに適用されるコーディングタイプ（例えば、ＢＣＣ又はＬＤＰＣ）情報を含んでよい。
【0143】
本開示で用いられるＭＣＳ、ＭＣＳ情報、ＭＣＳインデックス、ＭＣＳフィールドなどは、特定のインデックス値と表示されてよい。例えば、ＭＣＳ情報は、インデックス０～インデックス１１と表示されてよい。ＭＣＳ情報は、星状変調タイプ（例えば、ＢＰＳＫ、ＱＰＳＫ、１６－ＱＡＭ、６４－ＱＡＭ、２５６－ＱＡＭ、１０２４－ＱＡＭなど）に関する情報、及びコーディングレート（例えば、１／２、２／３、３／４、５／６など）に関する情報を含んでよい。ＭＣＳ情報には、チャネルコーディングタイプ（例えば、ＢＣＣ又はＬＤＰＣ）に関する情報が省かれてもよい。
【0144】
図１３は、本開示の適用が可能なＰＰＤＵフォーマットの例示を示す。
【0145】
図１３のＰＰＤＵは、ＥＨＴ ＰＰＤＵ、送信ＰＰＤＵ、受信ＰＰＤＵ、第１タイプ又は第ＮタイプＰＰＤＵなどの様々な名称とされてよい。例えば、本開示のＰＰＤＵ又はＥＨＴ ＰＰＤＵは、送信ＰＰＤＵ、受信ＰＰＤＵ、第１タイプ又は第ＮタイプＰＰＤＵなどの様々な名称とすることができる。また、ＥＨＴ ＰＰＵは、ＥＨＴシステム及び／又はＥＨＴシステムを改善した新しい無線ＬＡＮシステムにおいて利用可能である。
【0146】
図１３のＥＨＴ ＭＵ ＰＰＤＵは、１つ以上のユーザに対する１つ以上のデータ（又は、ＰＳＤＵ）を搬送する（ｃａｒｒｙ）ＰＰＤＵに該当する。すなわち、ＥＨＴ ＭＵ ＰＰＤＵは、ＳＵ送信及びＭＵ送信のいずれの送信にも用いられてよい。例えば、ＥＨＴ ＭＵ ＰＰＤＵは、１つの受信ＳＴＡ又は複数の受信ＳＴＡのためのＰＰＤＵに該当し得る。
【0147】
図１３のＥＨＴ ＴＢ ＰＰＤＵは、ＥＨＴ ＭＵ ＰＰＤＵに対比してＥＨＴ－ＳＩＧが省略される。ＵＬ ＭＵ送信のためのトリガー（例えば、トリガーフレーム又はＴＲＳ）を受信したＳＴＡは、ＥＨＴ ＴＢ ＰＰＤＵフォーマットに基づいてＵＬ送信を行うことができる。
【0148】
図１３のＥＨＴ ＰＰＤＵフォーマットの例示において、Ｌ－ＳＴＦ～ＥＨＴ－ＬＴＦは、プリアンブル（ｐｒｅａｍｂｌｅ）又は物理プリアンブル（ｐｈｙｓｉｃａｌ ｐｒｅａｍｂｌｅ）に該当し、物理層で生成／送信／受信／取得／デコードされてよい。
【0149】
Ｌ－ＳＴＦ、Ｌ－ＬＴＦ、Ｌ－ＳＩＧ、ＲＬ－ＳＩＧ、Ｕ－ＳＩＧ（Ｕｎｉｖｅｒｓａｌ ＳＩＧＮＡＬ）、ＥＨＴ－ＳＩＧフィールド（これらをプレＥＨＴ変調（ｐｒｅ－ＥＨＴ ｍｏｄｕｌａｔｅｄ）フィールドと称する。）のサブキャリア周波数間隔（ｓｕｂｃａｒｒｉｅｒ ｆｒｅｑｕｅｎｃｙ ｓｐａｃｉｎｇ）は、３１２．５ｋＨｚと定められてよい。ＥＨＴ－ＳＴＦ、ＥＨＴ－ＬＴＦ、Ｄａｔａ、ＰＥフィールド（これらをＥＨＴ変調（ＥＨＴ ｍｏｄｕｌａｔｅｄ）フィールドと称する。）のサブキャリア周波数間隔は、７８．１２５ｋＨｚと定められてよい。すなわち、Ｌ－ＳＴＦ、Ｌ－ＬＴＦ、Ｌ－ＳＩＧ、ＲＬ－ＳＩＧ、Ｕ－ＳＩＧ、ＥＨＴ－ＳＩＧフィールドのトーン／サブキャリアインデックスは、３１２．５ｋＨｚ単位で表示され、ＥＨＴ－ＳＴＦ、ＥＨＴ－ＬＴＦ、Ｄａｔａ、ＰＥフィールドのトーン／サブキャリアインデックスは、７８．１２５ｋＨｚ単位で表示されてよい。
【0150】
【0151】
図１３のＬ－ＳＩＧフィールドは、２４ビットで構成され、レート及び長さ情報を通信するために用いられてよい。例えば、Ｌ－ＳＩＧフィールドは、４ビットのレート（Ｒａｔｅ）フィールド、１ビットの留保（Ｒｅｓｅｒｖｅｄ）ビット、１２ビットの長さ（Ｌｅｎｇｔｈ）フィールド、１ビットのパリティ（Ｐａｒｉｔｙ）フィールド、及び６ビットのテール（Ｔａｉｌ）フィールドを含んでよい。例えば、１２ビットのＬｅｎｇｔｈフィールドは、ＰＰＤＵの長さ又は時間デュレーションに関する情報を含んでよい。例えば、１２ビットのＬｅｎｇｔｈフィールドの値は、ＰＰＤＵのタイプに基づいて決定されてよい。例えば、ｎｏｎ－ＨＴ、ＨＴ、ＶＨＴ、又はＥＨＴ ＰＰＤＵに対して、Ｌｅｎｇｔｈフィールドの値は３の倍数と決定されてよい。例えば、ＨＥ ＰＰＤＵに対して、Ｌｅｎｇｔｈフィールドの値は３の倍数＋１又は３の倍数＋２と決定されてよい。
【0152】
例えば、送信ＳＴＡは、Ｌ－ＳＩＧフィールドの２４ビット情報に対して１／２のコーディングレートに基づくＢＣＣエンコーディングを適用することができる。その後、送信ＳＴＡは、４８ビットのＢＣＣ符号化ビットを取得できる。４８ビットの符号化ビットに対してはＢＰＳＫ変調が適用され、４８個のＢＰＳＫシンボルが生成されてよい。送信ＳＴＡは、４８個のＢＰＳＫシンボルを、パイロットサブキャリア（例えば、｛サブキャリアインデックス－２１，－７，＋７，＋２１｝）及びＤＣサブキャリア（例えば、｛サブキャリアインデックス０｝）を除く位置にマップすることができる。結果的に、４８個のＢＰＳＫシンボルは、サブキャリアインデックス－２６～－２２、－２０～－８、－６～－１、＋１～＋６、＋８～＋２０、及び＋２２～＋２６にマップされてよい。送信ＳＴＡは、サブキャリアインデックス｛－２８，－２７，＋２７，＋２８｝に｛－１，－１，－１，１｝の信号をさらにマップすることができる。該信号は｛－２８，－２７，＋２７，＋２８｝に相応する周波数領域に対するチャネル推定のために用いられてよい。
【0153】
送信ＳＴＡは、Ｌ－ＳＩＧと同一に生成されるＲＬ－ＳＩＧを生成できる。ＲＬ－ＳＩＧに対してはＢＰＳＫ変調が適用される。受信ＳＴＡは、ＲＬ－ＳＩＧの存在に基づいて、受信ＰＰＤＵがＨＥ ＰＰＤＵ又はＥＨＴ ＰＰＤＵであることが分かる。
【0154】
図１３のＲＬ－ＳＩＧの後にはＵ－ＳＩＧ（Ｕｎｉｖｅｒｓａｌ ＳＩＧ）が挿入されてよい。Ｕ－ＳＩＧは、第１ＳＩＧフィールド、第１ＳＩＧ、第１タイプＳＩＧ、制御シグナル、制御シグナルフィールド、第１（タイプ）制御シグナルなどの様々な名称とすることができる。
【0155】
Ｕ－ＳＩＧは、Ｎビットの情報を含んでよく、ＥＨＴ ＰＰＤＵのタイプを識別するための情報を含んでよい。例えば、Ｕ－ＳＩＧは、２個のシンボル（例えば、連続する２個のＯＦＤＭシンボル）に基づいて構成されてよい。Ｕ－ＳＩＧのための各シンボル（例えば、ＯＦＤＭシンボル）は、４ｕｓのデュレーションを有してよく、Ｕ－ＳＩＧは、全体８ｕｓのデュレーションを有してよい。Ｕ－ＳＩＧの各シンボルは、２６ビット情報を送信するために用いられてよい。例えば、Ｕ－ＳＩＧの各シンボルは、５２個のデータトーンと４個のパイロットトーンに基づいて送受信されてよい。
【0156】
Ｕ－ＳＩＧ（又は、Ｕ－ＳＩＧフィールド）では、例えばＡビット情報（例えば、５２コードされていないビット（ｕｎ－ｃｏｄｅｄ ｂｉｔ））が送信されてよく、Ｕ－ＳＩＧの第１シンボル（例えば、Ｕ－ＳＩＧ－１）は、総Ａビット情報のうち、先頭のＸビット情報（例えば、２６ ｕｎ－ｃｏｄｅｄ ｂｉｔ）を送信し、Ｕ－ＳＩＧの第２シンボル（例えば、Ｕ－ＳＩＧ－２）は、総Ａビット情報のうち、残りのＹビット情報（例えば、２６ ｕｎ－ｃｏｄｅｄ ｂｉｔ）を送信できる。例えば、送信ＳＴＡは、各Ｕ－ＳＩＧシンボルに含まれる２６ ｕｎ－ｃｏｄｅｄ ｂｉｔを取得できる。送信ＳＴＡは、Ｒ＝１／２のレートに基づいてコンボリューションエンコーディング（例えば、ＢＣＣエンコーディング）を行って５２－ｃｏｄｅｄ ｂｉｔを生成し、５２－ｃｏｄｅｄ ｂｉｔに対するインターリービングを行うことができる。送信ＳＴＡは、インターリーブされた５２－ｃｏｄｅｄ ｂｉｔに対してＢＰＳＫ変調を行い、各Ｕ－ＳＩＧシンボルに割り当てられる５２個のＢＰＳＫシンボルを生成することができる。１つのＵ－ＳＩＧシンボルはＤＣインデックス０を除き、サブキャリアインデックス－２８からサブキャリアインデックス＋２８までの５６個トーン（サブキャリア）に基づいて送信されてよい。送信ＳＴＡが生成した５２個のＢＰＳＫシンボルは、パイロットトーンである－２１、－７、＋７、＋２１のトーンを除く残りのトーン（サブキャリア）に基づいて送信されてよい。
【0157】
例えば、Ｕ－ＳＩＧによって送信されるＡビット情報（例えば、５２ ｕｎ－ｃｏｄｅｄ ｂｉｔ）は、ＣＲＣフィールド（例えば、４ビット長のフィールド）及びテールフィールド（例えば、６ビット長のフィールド）を含んでよい。前記ＣＲＣフィールド及びテールフィールドは、Ｕ－ＳＩＧの第２シンボルで送信されてよい。前記ＣＲＣフィールドは、Ｕ－ＳＩＧの第１シンボルに割り当てられる２６ビットと、第２シンボル内で前記ＣＲＣ／テールフィールドを除く残りの１６ビットに基づいて生成されてよく、従来のＣＲＣ計算アルゴリズムに基づいて生成されてよい。また、前記テールフィールドは、コンボリューションデコーダのトレリス（ｔｒｅｌｌｉｓ）を終了（ｔｅｒｍｉｎａｔｅ）するために用いられてよく、例えば、０に設定されてよい。
【0158】
Ｕ－ＳＩＧ（又は、Ｕ－ＳＩＧフィールド）によって送信されるＡビット情報（例えば、５２ ｕｎ－ｃｏｄｅｄ ｂｉｔ）は、バージョン独立的（ｖｅｒｓｉｏｎ－ｉｎｄｅｐｅｎｄｅｎｔ）ビットとバージョン依存的（ｖｅｒｓｉｏｎ－ｄｅｐｅｎｄｅｎｔ）ビットとに区別できる。例えば、バージョン独立的ビットのサイズは、固定又は可変されてよい。例えば、バージョン独立的ビットは、Ｕ－ＳＩＧの第１シンボルにのみ割り当てられるか、又はバージョン独立的ビットはＵ－ＳＩＧの第１シンボル及び第２シンボルの両方に割り当てられてよい。例えば、バージョン独立的ビットとバージョン依存的ビットは、第１制御ビット及び第２制御ビットなどの様々な名称としてもよい。
【0159】
例えば、Ｕ－ＳＩＧのバージョン独立的ビットは、３ビットの物理層バージョン識別子（ＰＨＹ ｖｅｒｓｉｏｎ ｉｄｅｎｔｉｆｉｅｒ）を含んでよい。例えば、３ビットの物理層バージョン識別子は、送受信ＰＰＤＵの物理層バージョン（ＰＨＹ ｖｅｒｓｉｏｎ）に関する情報を含んでよい。例えば、３ビットの物理層バージョン識別子の第１値は、送受信ＰＰＤＵがＥＨＴ ＰＰＤＵであることを指示できる。言い換えると、送信ＳＴＡはＥＨＴ ＰＰＤＵを送信する場合に、３ビットの物理層バージョン識別子を第１値に設定できる。言い換えると、受信ＳＴＡは、第１値を有する物理層バージョン識別子に基づいて、受信ＰＰＤＵがＥＨＴ ＰＰＤＵであることを判断できる。
【0160】
例えば、Ｕ－ＳＩＧのバージョン独立的ビットは、１ビットのＵＬ／ＤＬフラグ（ｆｌａｇ）フィールドを含んでよい。１ビットのＵＬ／ＤＬ ｆｌａｇフィールドの第１値はＵＬ通信に関連し、ＵＬ／ＤＬ ｆｌａｇフィールドの第２値はＤＬ通信に関連する。
【0161】
例えば、Ｕ－ＳＩＧのバージョン独立的ビットは、ＴＸＯＰ（ｔｒａｎｓｍｉｓｓｉｏｎ ｏｐｐｏｒｔｕｎｉｔｙ）の長さに関する情報、ＢＳＳカラー（ｃｏｌｏｒ）ＩＤに関する情報を含んでよい。
【0162】
例えば、ＥＨＴ ＰＰＤＵが様々なタイプ（例えば、ＳＵモードに関連したＥＨＴ ＰＰＤＵ、ＭＵモードに関連したＥＨＴ ＰＰＤＵ、ＴＢモードに関連したＥＨＴ ＰＰＤＵ、Ｅｘｔｅｎｄｅｄ Ｒａｎｇｅ送信に関連したＥＨＴ ＰＰＤＵなどの様々なタイプ）に区分される場合に、ＥＨＴ ＰＰＤＵのタイプに関する情報は、Ｕ－ＳＩＧのバージョン依存的ビットに含まれてよい。
【0163】
例えば、Ｕ－ＳＩＧは、１）帯域幅に関する情報を含む帯域幅フィールド、２）ＥＨＴ－ＳＩＧに適用されるＭＣＳ手法に関する情報を含むフィールド、３）ＥＨＴ－ＳＩＧにＤＣＭ手法が適用されるか否かに関する情報を含む指示フィールド、４）ＥＨＴ－ＳＩＧのために用いられるシンボルの個数に関する情報を含むフィールド、５）ＥＨＴ－ＳＩＧが全帯域にわたって生成されるか否かに関する情報を含むフィールド、６）ＥＨＴ－ＬＴＦ／ＳＴＦのタイプに関する情報を含むフィールド、７）ＥＨＴ－ＬＴＦの長さ及びＣＰ長さを指示するフィールドに関する情報を含んでよい。
【0164】
図１３のＰＰＤＵには、プリアンブルパンクチャリング（ｐｕｎｃｔｕｒｉｎｇ）が適用されてよい。プリアンブルパンクチャリングは、ＰＰＤＵの帯域幅において１つ以上の２０ＭＨｚサブチャネルに信号が存在（ｐｒｅｓｅｎｔ）しないＰＰＤＵの送信を意味できる。プリアンブルパンクチャリングは、１つ以上のユーザに送信されるＰＰＤＵに適用されてよい。例えば、プリアンブルパンクチャリングの分解度（ｒｅｓｏｌｕｔｉｏｎ）は、４０ＭＨｚよりも大きい帯域幅のＯＦＤＭＡ送信及び８０ＭＨｚ及び１６０ＭＨｚ帯域幅の非ＯＦＤＭＡ送信におけるＥＨＴ ＭＵ ＰＰＤＵに対して２０ＭＨｚであってよい。すなわち、上のケースにおいて２４２－トーンＲＵよりも小さいサブチャネルに対するパンクチャリングは許容されなくてもよい。また、３２０ＭＨｚ帯域幅の非ＯＦＤＭＡ送信におけるＥＨＴ ＭＵ ＰＰＤＵに対しては、プリアンブルパンクチャリングの分解度は４０ＭＨｚであってよい。すなわち、３２０ＭＨｚ帯域幅において４８４－トーンＲＵよりも小さいサブチャネルに対するパンクチャリングは許容されなくてよい。また、ＥＨＴ ＭＵ ＰＰＤＵにおいてプライマリ２０ＭＨｚチャネルに対してはプリアンブルパンクチャリングが適用されなくてよい。
【0165】
例えば、ＥＨＴ ＭＵ ＰＰＤＵに対して、プリアンブルパンクチャリングに関する情報は、Ｕ－ＳＩＧ及び／又はＥＨＴ－ＳＩＧに含まれてよい。例えば、Ｕ－ＳＩＧの第１フィールドは、ＰＰＤＵの連続する帯域幅（ｃｏｎｔｉｇｕｏｕｓ ｂａｎｄｗｉｄｔｈ）に関する情報を含み、Ｕ－ＳＩＧの第２フィールドは、ＰＰＤＵに適用されるプリアンブルパンクチャリングに関する情報を含んでよい。
【0166】
例えば、Ｕ－ＳＩＧ及びＥＨＴ－ＳＩＧは、下の方法に基づいてプリアンブルパンクチャリングに関する情報を含むことができる。ＰＰＤＵの帯域幅が８０ＭＨｚを超える場合に、Ｕ－ＳＩＧは、８０ＭＨｚ単位で個別に構成されてよい。例えば、ＰＰＤＵの帯域幅が１６０ＭＨｚである場合に、当該ＰＰＤＵには、１番目の８０ＭＨｚ帯域のための第１Ｕ－ＳＩＧ、及び２番目の８０ＭＨｚ帯域のための第２Ｕ－ＳＩＧが含まれてよい。この場合、第１Ｕ－ＳＩＧの第１フィールドは、１６０ＭＨｚ帯域幅に関する情報を含み、第１Ｕ－ＳＩＧの第２フィールドは、１番目の８０ＭＨｚ帯域に適用されたプリアンブルパンクチャリングに関する情報（すなわち、プリアンブルパンクチャリングパターンに関する情報）を含んでよい。また、第２Ｕ－ＳＩＧの第１フィールドは、１６０ＭＨｚ帯域幅に関する情報を含み、第２Ｕ－ＳＩＧの第２フィールドは、２番目の８０ＭＨｚ帯域に適用されたプリアンブルパンクチャリングに関する情報（すなわち、プリアンブルパンクチャリングパターンに関する情報）を含んでよい。第１Ｕ－ＳＩＧに連続するＥＨＴ－ＳＩＧは、２番目の８０ＭＨｚ帯域に適用されたプリアンブルパンクチャリングに関する情報（すなわち、プリアンブルパンクチャリングパターンに関する情報）を含んでよく、第２Ｕ－ＳＩＧに連続するＥＨＴ－ＳＩＧは、１番目の８０ＭＨｚ帯域に適用されたプリアンブルパンクチャリングに関する情報（すなわち、プリアンブルパンクチャリングパターンに関する情報）を含んでよい。
【0167】
追加又は代案として、Ｕ－ＳＩＧ及びＥＨＴ－ＳＩＧは、下の方法に基づいて、プリアンブルパンクチャリングに関する情報を含んでよい。Ｕ－ＳＩＧは、全帯域に関するプリアンブルパンクチャリングに関する情報（すなわち、プリアンブルパンクチャリングパターンに関する情報）を含んでよい。すなわち、ＥＨＴ－ＳＩＧは、プリアンブルパンクチャリングに関する情報を含まず、Ｕ－ＳＩＧのみがプリアンブルパンクチャリングに関する情報（すなわち、プリアンブルパンクチャリングパターンに関する情報）を含んでよい。
【0168】
Ｕ－ＳＩＧは、２０ＭＨｚ単位で構成されてよい。例えば、８０ＭＨｚ ＰＰＤＵが構成される場合に、Ｕ－ＳＩＧが複製されてよい。すなわち、８０ＭＨｚ ＰＰＤＵ内に同一の４個のＵ－ＳＩＧが含まれてよい。８０ＭＨｚ帯域幅を超えるＰＰＤＵは、互いに異なるＵ－ＳＩＧを含んでよい。
【0169】
図１３のＥＨＴ－ＳＩＧは、受信ＳＴＡのための制御情報を含んでよい。ＥＨＴ－ＳＩＧは、少なくとも１つのシンボルで送信されてよく、１つのシンボルは、４ｕｓの長さを有してよい。ＥＨＴ－ＳＩＧのために用いられるシンボルの個数に関する情報は、Ｕ－ＳＩＧに含まれてよい。
【0170】
ＥＨＴ－ＳＩＧは、図１１及び図１２で説明されたＨＥ－ＳＩＧ－Ｂの技術的特徴を含んでよい。例えば、ＥＨＴ－ＳＩＧは、図８の一例と同一に、共通フィールド（ｃｏｍｍｏｎ ｆｉｅｌｄ）及びユーザ－特定フィールド（ｕｓｅｒ－ｓｐｅｃｉｆｉｃ ｆｉｅｌｄ）を含んでよい。ＥＨＴ－ＳＩＧの共通フィールドは省略されてよく、ユーザ－特定フィールドの個数は、ユーザ（ｕｓｅｒ）の個数に基づいて決定されてよい。
【0171】
図１１の一例と同一に、ＥＨＴ－ＳＩＧの共通フィールド及びＥＨＴ－ＳＩＧのユーザ－特定フィールドは個別にコードされてよい。ユーザ－特定フィールドに含まれる１つのユーザブロックフィールド（Ｕｓｅｒ ｂｌｏｃｋ ｆｉｅｌｄ）は、２個のユーザ（ｕｓｅｒ）フィールドのための情報を含むが、ユーザ－特定フィールドに含まれる最後のユーザブロックフィールドは、１個又は２個のユーザフィールドを含んでよい。すなわち、ＥＨＴ－ＳＩＧの１つのユーザブロックフィールドは、最大で２個のユーザフィールド（ｕｓｅｒ ｆｉｅｌｄ）を含んでよい。図１２の一例と同一に、各ユーザフィールド（ｕｓｅｒ ｆｉｅｌｄ）は、ＭＵ－ＭＩＭＯ割り当てに関連するか、ｎｏｎ－ＭＵ－ＭＩＭＯ割り当てに関連してよい。
【0172】
図１１の一例と同一に、ＥＨＴ－ＳＩＧの共通フィールドは、ＣＲＣビットとＴａｉｌビットを含んでよく、ＣＲＣビットの長さは４ビットと決定されてよく、Ｔａｉｌビットの長さは６ビットと決定され、００００００に設定されてよい。
【0173】
図１１の一例と同一に、ＥＨＴ－ＳＩＧの共通フィールドは、ＲＵ割り当て情報（ＲＵ ａｌｌｏｃａｔｉｏｎ ｉｎｆｏｒｍａｔｉｏｎ）を含んでよい。ＲＵ ａｌｌｏｃａｔｉｏｎ ｉｎｆｏｒｍａｔｉｏｎは、複数のユーザ（すなわち、複数の受信ＳＴＡ）が割り当てられるＲＵの位置（ｌｏｃａｔｉｏｎ）に関する情報を意味できる。ＲＵ ａｌｌｏｃａｔｉｏｎ ｉｎｆｏｒｍａｔｉｏｎは、９ビット（又は、Ｎビット）単位で構成されてよい。
【0174】
ＥＨＴ－ＳＩＧの共通フィールドが省略されるモードが支援されてよい。ＥＨＴ－ＳＩＧの共通フィールドが省略されるモードは、圧縮モード（ｃｏｍｐｒｅｓｓｅｄ ｍｏｄｅ）と呼ぶことができる。ｃｏｍｐｒｅｓｓｅｄ ｍｏｄｅが用いられる場合に、ＥＨＴ ＰＰＤＵの複数のユーザ（すなわち、複数の受信ＳＴＡ）は、ｎｏｎ－ＯＦＤＭＡに基づいてＰＰＤＵ（例えば、ＰＰＤＵのデータフィールド）をデコードすることができる。すなわち、ＥＨＴ ＰＰＤＵの複数のユーザは、同じ周波数帯域で受信されるＰＰＤＵ（例えば、ＰＰＤＵのデータフィールド）をデコードすることができる。非－圧縮モード（ｎｏｎ－ｃｏｍｐｒｅｓｓｅｄ ｍｏｄｅ）が用いられる場合に、ＥＨＴ ＰＰＤＵの複数のユーザは、ＯＦＤＭＡに基づいてＰＰＤＵ（例えば、ＰＰＤＵのデータフィールド）をデコードすることができる。すなわち、ＥＨＴ ＰＰＤＵの複数のユーザは、互いに異なる周波数帯域でＰＰＤＵ（例えば、ＰＰＤＵのデータフィールド）を受信することができる。
【0175】
ＥＨＴ－ＳＩＧは、様々なＭＣＳ手法に基づいて構成されてよい。上述したように、ＥＨＴ－ＳＩＧに適用されるＭＣＳ手法に関する情報は、Ｕ－ＳＩＧに含まれてよい。ＥＨＴ－ＳＩＧはＤＣＭ手法に基づいて構成されてよい。ＤＣＭ手法は、同一の信号を２つのサブキャリア上で再使用（ｒｅｕｓｅ）して周波数ダイバーシチと類似の効果を提供し、干渉を低減させ、カバレッジを改善できる。例えば、可用なトーン／サブキャリア上で同一の変調手法が適用された変調シンボルが反復してマップされてよい。例えば、ＥＨＴ－ＳＩＧのために割り当てられたＮ個のデータトーン（例えば、５２個のデータトーン）のうち、先頭に連続する半分のトーン（例えば、１番目～２６番目のトーン）には、特定変調手法が適用された変調シンボル（例えば、ＢＰＳＫ変調シンボル）がマップされ、残りの連続する半分のトーン（例えば、２７番目～５２番目トーン）に、同一の特定変調手法が適用された変調シンボル（例えば、ＢＰＳＫ変調シンボル）がマッピングされてよい。すなわち、１番目のトーンにマップされる変調シンボルと、２７番目のトーンにマップされる変調シンボルとが同一になる。上述したように、ＥＨＴ－ＳＩＧにＤＣＭ手法が適用されるか否かに関する情報（例えば、１ビットフィールド）は、Ｕ－ＳＩＧに含まれてよい。図１３のＥＨＴ－ＳＴＦは、ＭＩＭＯ環境又はＯＦＤＭＡ環境で自動利得制御推定（ａｕｔｏｍａｔｉｃ ｇａｉｎ ｃｏｎｔｒｏｌ（ＡＧＣ） ｅｓｔｉｍａｔｉｏｎ）を向上させるために用いられてよい。図１３のＥＨＴ－ＬＴＦは、ＭＩＭＯ環境又はＯＦＤＭＡ環境においてチャネルを推定するために用いられてよい。
【0176】
ＳＴＦ及び／又はＬＴＦのタイプに関する情報（ＬＴＦに適用されるＧＩ（ｇｕａｒｄ ｉｎｔｅｒｖａｌ）に関する情報も含まれる）は、図１３のＵ－ＳＩＧフィールド及び／又はＥＨＴ－ＳＩＧフィールドなどに含まれてよい。
【0177】
【0178】
例えば、２０ＭＨｚ帯域上で送信されるＥＨＴ ＰＰＤＵ、すなわち、２０ＭＨｚ ＥＨＴ ＰＰＤＵは、図８のＲＵに基づいて構成されてよい。すなわち、ＥＨＴ ＰＰＤＵに含まれるＥＨＴ－ＳＴＦ、ＥＨＴ－ＬＴＦ、データフィールドのＲＵの位置（ｌｏｃａｔｉｏｎ）は、図８のように決定されてよい。４０ＭＨｚ帯域上で送信されるＥＨＴ ＰＰＤＵ、すなわち４０ＭＨｚ ＥＨＴ ＰＰＤＵは、図９のＲＵに基づいて構成されてよい。すなわち、ＥＨＴ ＰＰＤＵに含まれるＥＨＴ－ＳＴＦ、ＥＨＴ－ＬＴＦ、データフィールドのＲＵの位置（ｌｏｃａｔｉｏｎ）は、図９のように決定されてよい。
【0179】
８０ＭＨｚ帯域上で送信されるＥＨＴ ＰＰＤＵ、すなわち８０ＭＨｚ ＥＨＴ ＰＰＤＵは、図１０のＲＵに基づいて構成されてよい。すなわち、ＥＨＴ ＰＰＤＵに含まれるＥＨＴ－ＳＴＦ、ＥＨＴ－ＬＴＦ、データフィールドのＲＵの位置（ｌｏｃａｔｉｏｎ）は、図１０のように決定されてよい。図１０の８０ＭＨｚのためのトーン－プラン（ｔｏｎｅ－ｐｌａｎ）は、図９の４０ＭＨｚのためのトーン－プランの２回の反復に対応し得る。
【0180】
【0181】
図１３のＰＰＤＵは、以下の方法に基づいてＥＨＴ ＰＰＤＵとして識別されてよい。
【0182】
受信ＳＴＡは、次の事項に基づいて受信ＰＰＤＵのタイプを、ＥＨＴ ＰＰＤＵと判断できる。例えば、１）受信ＰＰＤＵのＬ－ＬＴＦ信号以後の最初のシンボルがＢＰＳＫであり、２）受信ＰＰＤＵのＬ－ＳＩＧが反復されるＲＬ－ＳＩＧが検出（ｄｅｔｅｃｔ）され、３）受信ＰＰＤＵのＬ－ＳＩＧのＬｅｎｇｔｈフィールドの値に対してｍｏｄｕｌｏ ３演算を適用した結果（すなわち、３で割った余り）が０と検出される場合に、受信ＰＰＤＵはＥＨＴ ＰＰＤＵと判断されてよい。受信ＰＰＤＵがＥＨＴ ＰＰＤＵと判断される場合に、受信ＳＴＡは、図１３のＲＬ－ＳＩＧ後のシンボルに含まれるビット情報に基づいてＥＨＴ ＰＰＤＵのタイプを決定することができる。言い換えると、受信ＳＴＡは、１）ＢＳＰＫであるＬ－ＬＴＦ信号後の最初のシンボル、２）Ｌ－ＳＩＧフィールドに連続し、Ｌ－ＳＩＧと同一であるＲＬ－ＳＩＧ、及び３）ｍｏｄｕｌｏ ３を適用した結果が０と設定されるＬｅｎｇｔｈフィールドを含むＬ－ＳＩＧに基づいて、受信ＰＰＤＵをＥＨＴ ＰＰＤＵと判断できる。
【0183】
例えば、受信ＳＴＡは、次の事項に基づいて、受信ＰＰＤＵのタイプをＨＥ ＰＰＤＵと判断できる。例えば、１）Ｌ－ＬＴＦ信号後の最初のシンボルがＢＰＳＫであり、２）Ｌ－ＳＩＧが反復されるＲＬ－ＳＩＧが検出（ｄｅｔｅｃｔ）され、３）Ｌ－ＳＩＧのＬｅｎｇｔｈ値に対してｍｏｄｕｌｏ ３を適用した結果が１又は２と検出される場合に、受信ＰＰＤＵはＨＥ ＰＰＤＵと判断されてよい。
【0184】
例えば、受信ＳＴＡは、次の事項に基づいて、受信ＰＰＤＵのタイプをｎｏｎ－ＨＴ、ＨＴ及びＶＨＴ ＰＰＤＵと判断できる。例えば、１）Ｌ－ＬＴＦ信号後の最初のシンボルがＢＰＳＫであり、２）Ｌ－ＳＩＧが反復されるＲＬ－ＳＩＧが検出されない場合に、受信ＰＰＤＵは、ｎｏｎ－ＨＴ、ＨＴ及びＶＨＴ ＰＰＤＵと判断されてよい。
【0185】
また、受信ＳＴＡが、受信したＰＰＤＵからＬ－ＳＩＧが反復されるＲＬ－ＳＩＧを検出した場合に、ＨＥ ＰＰＤＵ又はＥＨＴ ＰＰＤＵであると判断できる。この場合、レート（６Ｍｂｐｓ）チェックに失敗すれば、受信ＰＰＤＵは、ｎｏｎ－ＨＴ、ＨＴ、又はＶＨＴ ＰＰＤＵと判断されてよい。レート（６Ｍｂｐｓ）チェック及びパリティーチェックを通過すれば、Ｌ－ＳＩＧのＬｅｎｇｔｈ値に対してｍｏｄｕｌｏ ３を適用した結果が０と検出される場合には、受信ＰＰＤＵはＥＨＴ ＰＰＤＵと判断されてよく、Ｌｅｎｇｔｈ ｍｏｄ ３の結果が０でない場合にＨＥ ＰＰＤＵと判断されてよい。
【0186】
図１３のＰＰＤＵは、様々なタイプのフレームを送受信するために用いられてよい。例えば、図１３のＰＰＤＵは、制御フレーム、管理フレーム、又はデータフレームのうち１つ以上の（同時）送受信のために用いられてもよい。
【0187】
以下では、ＥＨＴ ＰＰＤＵに含まれるＵ－ＳＩＧについてより具体的に説明する。
【0188】
４０ＭＨｚ ＥＨＴ ＰＰＤＵ又はＥＲ（Ｅｘｔｅｎｄｅｄ Ｒａｎｇｅ）プリアンブルに対して、Ｕ－ＳＩＧコンテンツは２個の２０ＭＨｚサブチャネルにおいて同一である。８０ＭＨｚ ＥＨＴ ＰＰＤＵ又はＥＲプリアンブルに対して、Ｕ－ＳＩＧコンテンツは、パンクチャリングされていない（ｎｏｎ－ｐｕｎｃｔｕｒｅｄ）２０ＭＨｚサブチャネルの全てにおいて同一である。１６０／３２０ＭＨｚ ＥＨＴ ＰＰＤＵ又はＥＲプリアンブルに対して、Ｕ－ＳＩＧコンテンツは、それぞれの８０ＭＨｚサブブロック内でパンクチャリングされていない２０ＭＨｚサブチャネルの全てにおいて同一であり、他の８０ＭＨｚサブブロックにおけるＵ－ＳＩＧコンテンツとは異なってもよい。
【0189】
ＥＨＴ ＭＵ ＰＰＤＵのＵ－ＳＩＧのＵ－ＳＩＧ－１パートは、ＰＨＹバージョン識別子（Ｂ０～Ｂ２）、ＢＷ（Ｂ３～Ｂ５）、ＵＬ／ＤＬ（Ｂ６）、ＢＳＳカラー（Ｂ７～Ｂ１２）、及びＴＸＯＰ（Ｂ１３～Ｂ１９）を含んでよく、Ｕ－ＳＩＧ－２パートは、ＰＰＤＵタイプ及び圧縮モード（Ｂ０～Ｂ１）、有効化（ｖａｌｉｄａｔｅ）（Ｂ２）、パンクチャリングされたチャネル情報（ｐｕｎｃｔｕｒｅｄ ｃｈａｎｎｅｌ ｉｎｆｏｒｍａｔｉｏｎ）（Ｂ３～Ｂ７）、有効化（Ｂ８）、ＥＨＴ－ＳＩＧ ＭＣＳ（Ｂ９～Ｂ１０）、ＥＨＴ－ＳＩＧシンボルの個数（Ｂ１１～Ｂ１５）、ＣＲＣ（Ｂ１６～Ｂ１９）、及びテール（Ｂ２０～Ｂ２５）を含んでよい。
【0190】
次に、ＥＨＴ ＴＢ ＰＰＤＵのＵ－ＳＩＧのＵ－ＳＩＧ－１パートは、バージョン識別子（Ｂ０～Ｂ２）、ＢＷ（Ｂ３～Ｂ５）、ＵＬ／ＤＬ（Ｂ６）、ＢＳＳカラー（Ｂ７～Ｂ１２）、ＴＸＯＰ（Ｂ１３～Ｂ１９）、及び無視（ｄｉｓｒｅｇａｒｄ）（Ｂ２０～Ｂ２５）を含んでよく、Ｕ－ＳＩＧ－２パートは、ＰＰＤＵタイプ及び圧縮モード（Ｂ０～Ｂ１）、有効化（ｖａｌｉｄａｔｅ）（Ｂ２）、空間再使用１（ｓｐａｔｉａｌ ｒｅｕｓｅ１）（Ｂ３～Ｂ６）、空間再使用２（Ｂ７～Ｂ１０）、無視（Ｂ１１～Ｂ１５）、ＣＲＣ（Ｂ１６～Ｂ１９）、及びテール（Ｂ２０～Ｂ２５）を含んでよい。
【0191】
前述したように、ＥＨＴ ＭＵ ＰＰＤＵのＵ－ＳＩＧフィールドは、５－ビットパンクチャリングされたチャネル情報を含むが、ＥＨＴ ＴＢ ＰＰＤＵにはパンクチャリングされたチャネル情報が含まれない。これは、ＥＨＴ ＴＢ ＰＰＤＵは、トリガーフレーム又はＴＲＳ制御情報によって指示されるリソース割り当てに従って構成されることを仮定し、よって、ＳＴＡがＥＨＴ ＴＢ ＰＰＤＵのリソース情報をＡＰに知らせる必要がなかったためである。
【0192】
また、前述したようなトリガーフレーム又はＴＲＳ制御情報を受信しても、ＳＴＡが、ＨＥ ＴＢ ＰＰＤＵで応答しなくてもよい。例えば、ｎｏｎ－ＡＰ ＳＴＡは、トリガーフレームに含まれる共通情報フィールド又は当該ｎｏｎ－ＡＰ ＳＴＡに対してアドレスされるか又は当該ｎｏｎ－ＡＰ ＳＴＡによって選択されたユーザフィールドの１つ以上のサブフィールドが認識（ｒｅｃｏｇｎｉｚｅ）、支援、又は充足（ｓａｔｉｓｆｙ）されない値を有する場合に、該当ｎｏｎ－ＡＰ ＳＴＡはトリガーフレームに応答しないことを選択できる。これと類似に、ｎｏｎ－ＡＰ ＳＴＡは、該当ｎｏｎ－ＡＰ ＳＴＡにアドレスされるフレームに含まれるＴＲＳ制御サブフィールドが該当ｎｏｎ－ＡＰ ＳＴＡによって認識、支援、又は充足されない値を有する場合に、当該ｎｏｎ－ＡＰ ＳＴＡはＴＲＳ制御サブフィールドに応答しないことを選択できる。
【0193】
ターゲットウエイクタイム（ｔａｒｇｅｔ ｗａｋｅ ｔｉｍｅ，ＴＷＴ）
【0194】
ＴＷＴは、ＡＰとｎｏｎ－ＡＰ ＳＴＡ間のサービス期間（Ｓｅｒｖｉｃｅ Ｐｅｒｉｏｄ，ＳＰ）を定義し、ＳＰに関する情報を互いに共有し、媒体の競合（ｃｏｎｔｅｎｔｉｏｎ）を減らすことにより、ｎｏｎ－ＡＰ ＳＴＡのエネルギー効率を改善できるＰＳ（Ｐｏｗｅｒ Ｓａｖｉｎｇ）技術である。
【0195】
ＴＷＴセットアップ（Ｓｅｔｕｐ）段階で要請／提案／要求（Ｒｅｑｕｅｓｔ／Ｓｕｇｇｅｓｔ／Ｄｅｍａｎｄ）などを行うＳＴＡを、ＴＷＴ要請（Ｒｅｑｕｅｓｔｉｎｇ）ＳＴＡと呼ぶことができる。また、当該要請に対する受諾／拒絶（Ａｃｃｅｐｔ／Ｒｅｊｅｃｔ）などの応答をするＡＰを、ＴＷＴ応答（Ｒｅｓｐｏｎｄｉｎｇ）ＳＴＡと呼ぶことができる。
【0196】
セットアップ（Ｓｅｔｕｐ）段階は、ＳＴＡのＡＰに対するＴＷＴ要請、行われるＴＷＴ動作のタイプ、送受信するフレーム（ｆｒａｍｅ）タイプを決定／定義する過程を含んでよい。ＴＷＴ動作は、個別（ｉｎｄｉｖｉｄｕａｌ）ＴＷＴとブロードキャスト（ｂｒｏａｄｃａｓｔ）ＴＷＴとに区分できる。
【0197】
図１４は、本開示の適用が可能な個別ＴＷＴ動作の一例を説明するための図である。
【0198】
個別ＴＷＴは、ＡＰとｎｏｎ－ＡＰ ＳＴＡがＴＷＴ要請／応答（Ｒｅｑｕｅｓｔ／Ｒｅｓｐｏｎｓｅ）フレームの送受信によってｎｏｎ－ＡＰ ＳＴＡの活性化／睡眠状態（ａｗａｋｅ／ｄｏｚｅ ｓｔａｔｕｓ）に対する交渉（ｎｅｇｏｔｉａｔｉｏｎ）を行った後、データ交換を行うメカニズムである。
【0199】
図１４の例示において、ＡＰとＳＴＡ１は、ＴＷＴ要請フレーム及びＴＷＴ応答フレームによってトリガー－イネーブルされたＴＷＴ合意（Ｔｒｉｇｇｅｒ－ｅｎａｂｌｅｄ ＴＷＴ ａｇｒｅｅｍｅｎｔ）を形成することができる。
【0200】
ここで、ＳＴＡ１が利用した方式は要請型（ｓｏｌｉｃｉｔｅｄ）ＴＷＴ方式で、ＳＴＡ１がＴＷＴ要請フレームをＡＰに送信すれば、ＳＴＡ１がＡＰからＴＷＴ動作のための情報をＴＷＴ応答フレームを用いて受信する方式である。
【0201】
一方、非要請型（ｕｎｓｏｌｉｃｉｔｅｄ）ＴＷＴ方式を行うＳＴＡ２は、ＡＰからトリガー－イネーブルされたＴＷＴ合意（ｔｒｉｇｇｅｒ－ｅｎａｂｌｅｄ ＴＷＴ ａｇｒｅｅｍｅｎｔ）設定に関する情報を、非要請型ＴＷＴ応答（ｕｎｓｏｌｉｃｉｔｅｄ ＴＷＴ ｒｅｓｐｏｎｓｅ）を用いて受信することができる。
【0202】
具体的には、ＳＴＡ２は、現在ＴＷＴ値から特定数を足して、次のＴＷＴを計算することができる。トリガー－イネーブルされた（ｔｒｉｇｇｅｒ－ｅｎａｂｌｅｄ）ＴＷＴ ＳＰにおいて、ＡＰはＳＴＡにトリガーフレームを送信できる。前記トリガーフレームは、ＡＰにバッファされたデータ（ｂｕｆｆｅｒｅｄ ｄａｔａ）があることを、ＳＴＡに知らせることができる。これに対して、ＳＴＡ１は、ＰＳ－Ｐｏｌｌフレームを送信することにより、自分の活性化された（ａｗａｋｅ）状態をＡＰに知らせることができる。また、ＳＴＡ２は、ＱｏＳ Ｎｕｌｌフレームを送信することにより、自分の活性化された状態をＡＰに知らせることができる。ここで、ＳＴＡ１及びＳＴＡ２が送信するデータフレームは、ＴＢ ＰＰＤＵ形式のフレームであってよい。ＳＴＡ１及びＳＴＡ２の状態を確認したＡＰは、活性化されたＳＴＡにＤＬ ＭＵ ＰＰＤＵを送信することができる。当該ＴＷＴ ＳＰが満了すると、ＳＴＡ１及びＳＴＡ２は睡眠（ｄｏｚｅ）状態に切り換わってよい。
【0203】
図１５は、本開示の適用が可能なブロードキャストＴＷＴ動作の一例を説明するための図である。
【0204】
ブロードキャストＴＷＴは、ｎｏｎ－ＡＰ ＳＴＡ（又は、ＴＷＴ ｓｃｈｅｄｕｌｉｎｇ ＳＴＡ）がＡＰ（又は、ＴＷＴ ｓｃｈｅｄｕｌｅｄ ＳＴＡ）とＴＷＴ要請／応答フレームを送受信することにより、ＴＢＴＴ（ｔａｒｇｅｔ ｂｅａｃｏｎ ｔｒａｎｓｍｉｓｓｉｏｎ ｔｉｍｅ）及び聴取間隔（ｌｉｓｔｅｎ ｉｎｔｅｒｖａｌ）などに関する情報を取得する方式のＴＷＴである。ここで、ＴＢＴＴに対する交渉（ｎｅｇｏｔｉａｔｉｏｎ）動作が行われてもよい。これに基づいて、ＡＰは、ビーコン（ｂｅａｃｏｎ）フレームを用いて、ＴＷＴのスケジューリング情報を含むフレームを定義することができる。
【0205】
図１５で、ＳＴＡ１は要請型ＴＷＴ動作を行い、ＳＴＡ２は非要請型ＴＷＴ動作を行う。ＡＰは、自分が送信したトリガーを用いてＳＴＡの活性化（ａｗａｋｅ）状態を確認した後、ＤＬ ＭＵ ＰＰＤＵを送信できる。これは個別ＴＷＴの過程と同一であってよい。ブロードキャストＴＷＴにおいて、ビーコンフレームを含むトリガー－イネーブルされたＴＷＴ ＳＰは一定の周期で複数回反復されてよい。
【0206】
ＴＷＴ情報の伝達は、ＴＷＴ情報フレーム（ＴＷＴ ｉｎｆｏｒｍａｔｉｏｎ ｆｒａｍｅ）及びＴＷＴ情報要素（ＴＷＴ ｉｎｆｏｒｍａｔｉｏｎ ｅｌｅｍｅｎｔ）によってなされてよい。ＴＷＴ情報フレームは、ＴＷＴ合意（ＴＷＴ ａｇｒｅｅｍｅｎｔ）に関する情報を要請又は伝達するためにＳＴＡによって送信され、既存ＴＷＴ合意のＳＴＡのうちの１つによって送信される。ＴＷＴ情報フレームのアクションフィールド（ａｃｔｉｏｎ ｆｉｅｌｄ）は、ＴＷＴ情報フィールド（ＴＷＴ ｉｎｆｏｒｍａｔｉｏｎ ｆｉｅｌｄ）を含む。ＴＷＴ情報フィールドは、３ビットのＴＷＴフロー識別子（ＴＷＴ ｆｌｏｗ ｉｄｅｎｔｉｆｉｅｒ）サブフィールド、１ビットの応答要請（ｒｅｓｐｏｎｓｅ ｒｅｑｕｅｓｔｅｄ）サブフィールド、１ビットの次のＴＷＴ要請（ｎｅｘｔ ＴＷＴ ｒｅｑｕｅｓｔ）サブフィールド、２ビットの次のＴＷＴサブフィールドサイズ（ｎｅｘｔ ＴＷＴ ｓｕｂｆｉｅｌｄ ｓｉｚｅ）サブフィールド、１ビットの全てのＴＷＴ（ａｌｌ ＴＷＴ）サブフィールド、及び０／３２／４８／６４ビットの次のＴＷＴ（ｎｅｘｔ ＴＷＴ）サブフィールドを含んでよい。
【0207】
図１６は、ＴＷＴ情報要素フォーマットの一例を説明するための図である。
【0208】
ＴＷＴ要素は、ビーコン、プローブ応答、（再）結合応答フレームなどに含まれて送受信されてよい。ＴＷＴ要素は、要素識別子（ｅｌｅｍｅｎｔ ＩＤ）フィールド、長さ（ｌｅｎｇｔｈ）フィールド、制御（ｃｏｎｔｒｏｌ）フィールド、及びＴＷＴパラメータ情報（ＴＷＴ ｐａｒａｍｅｔｅｒ ｉｎｆｏｒｍａｔｉｏｎ）フィールドを含んでよい。
【0209】
ＴＷＴ要素の制御フィールドは、個別ＴＷＴとブロードキャストＴＷＴに関係なく同一のフォーマットを有する。
【0210】
ＮＤＰページング指示（ＮＤＰ ｐａｇｉｎｇ ｉｎｄｉｃａｔｉｏｎ）サブフィールドは、ＮＤＰページングフィールドが存在すれば１値を有し、ＮＤＰページングフィールドが存在しなければ０値を有してよい。
【0211】
応答者ＰＭモード（ｒｅｓｐｏｎｄｅｒ ＰＭ ｍｏｄｅ）サブフィールドは、電力管理（Ｐｏｗｅｒ Ｍａｎａｇｅｍｅｎｔ，ＰＭ）モードを示すことができる。
【0212】
交渉タイプ（ｎｅｇｏｔｉａｔｉｏｎ ｔｙｐｅ）サブフィールドは、ＴＷＴ要素に含まれた情報が、ブロードキャストＴＷＴ又は個別ＴＷＴ（ｓ）のパラメータの交渉に対するものか、又はウエイクＴＢＴＴ間隔（ｗａｋｅ ＴＢＴＴ ｉｎｔｅｒｖａｌ）に対するものかを示すことができる。
【0213】
例えば、ｎｅｇｏｔｉａｔｉｏｎ ｔｙｐｅサブフィールドの値が０である場合に、ＴＷＴサブフィールドは、将来の個別ＴＷＴ ＳＰ開始時間に関するものであり、ＴＷＴ要素は１つの個別ＴＷＴパラメータセットを含む。これは、ＴＷＴ要請ＳＴＡとＴＷＴ応答ＳＴＡ間の個別ＴＷＴ交渉に該当するか、又はＴＷＴ応答者による個別ＴＷＴ公知（ａｎｎｏｕｎｃｅｍｅｎｔ）に該当し得る。
【0214】
例えば、ｎｅｇｏｔｉａｔｉｏｎ ｔｙｐｅサブフィールドの値が１である場合に、ＴＷＴサブフィールドは、次のＴＢＴＴ時間に関するものであり、ＴＷＴ要素は、１つの個別ＴＷＴパラメータセットを含む。これは、ＴＷＴスケジュールされる（ｓｃｈｅｄｕｌｅｄ）ＳＴＡとＴＷＴスケジュールする（ｓｃｈｅｄｕｌｉｎｇ）ＡＰ間のウエイクＴＢＴＴ及びウエイク間隔交渉に該当し得る。
【0215】
例えば、ｎｅｇｏｔｉａｔｉｏｎ ｔｙｐｅサブフィールドの値が２である場合に、ＴＷＴサブフィールドは、将来のブロードキャストＴＷＴ ＳＰ開始時間に関するものであり、ＴＷＴ要素は、１つ以上のブロードキャストＴＷＴパラメータセットを含む。これは、ＴＷＴスケジューリングＡＰによって送信されるブロードキャスト管理フレームにＴＷＴ要素を含めることにより、ＴＷＴスケジュールされるＳＴＡにブロードキャストＴＷＴスケジュールを提供することに該当し得る。
【0216】
例えば、ｎｅｇｏｔｉａｔｉｏｎ ｔｙｐｅサブフィールドの値が３である場合に、ＴＷＴサブフィールドは、将来のブロードキャストＴＷＴ ＳＰ開始時間に関するものであり、ＴＷＴ要素は、１つ以上のブロードキャストＴＷＴパラメータセットを含む。これは、ＴＷＴスケジュールされるＳＴＡ又はＴＷＴスケジュールするＡＰのいずれか一方によって送信される個別アドレスされる管理フレームにＴＷＴ要素を含めることにより、ブロードキャストＴＷＴスケジュールのメンバーシップを管理することに該当し得る。
【0217】
ＴＷＴ情報フレームディセーブル（ＴＷＴ ｉｎｆｏｒｍａｔｉｏｎ ｆｒａｍｅ ｄｉｓａｂｌｅｄ）サブフィールドが１に設定されると、ＳＴＡによるＴＷＴ情報フレームの受信がディセーブルされることを示し、そうでなければ、０に設定されてよい。
【0218】
ウエイクデュレーション単位（ｗａｋｅ ｄｕｒａｔｉｏｎ ｕｎｉｔ）サブフィールドは、公称最小ＴＷＴウエイクデュレーション（ｎｏｍｉｎａｌ ｍｉｎｉｍｕｍ ＴＷＴ ｗａｋｅ ｄｕｒａｔｉｏｎ）フィールドの単位を示す。ウエイクデュレーション単位サブフィールドは、単位が２５６ｕｓである場合に０に設定され、単位がＴＵである場合に１に設定されてよい。ＨＥ／ＥＨＴ ＳＴＡでない場合に、ウエイクデュレーション単位サブフィールドは０に設定されてよい。
【0219】
交渉タイプフィールドのＭＳＢ（ｍｏｓｔ ｓｉｇｎｉｆｉｃａｎｔ ｂｉｔ）は、ブロードキャストフィールドに該当し得る。前記ブロードキャストフィールドが１であれば、ＴＷＴ要素に１つ以上のブロードキャストＴＷＴパラメータセットが含まれてよい。前記ブロードキャストフィールドが０であれば、１つの個別ＴＷＴパラメータセットのみがＴＷＴ要素に含まれてよい。前記ブロードキャストフィールドが１に設定されたＴＷＴ要素を、ブロードキャストＴＷＴ要素と称することができる。
【0220】
そして、図１６には、留保フィールド（ｒｅｓｅｒｖｅｄ ｆｉｅｌｄ）が２ビットで構成された場合を示しているが、これは一実施例に過ぎない。例えば、ＴＷＴ要素は、（例えば、１ビットである）リンク（Ｌｉｎｋ）ＩＤビットマップ（ｂｉｔｍａｐ）存在（ｐｒｅｓｅｎｔ）フィールドを含み、（例えば、１ビットである）留保フィールドを含んでよい。
【0221】
例えば、リンクＩＤビットマップ存在フィールドが１に設定される場合に、後述する個別ＴＷＴパラメータセットフィールドフォーマットにリンクＩＤビットマップサブフィールドが存在するように設定され、リンクＩＤビットマップ存在フィールドが０に設定される場合に、個別ＴＷＴパラメータセットフィールドフォーマットにリンクＩＤビットマップサブフィールドが存在しないように設定されてよい。
【0222】
【0223】
図１６のＴＷＴ ｅｌｅｍｅｎｔに含まれるＴＷＴパラメータ情報（ＴＷＴ ｐａｒａｍｅｔｅｒ ｉｎｆｏｒｍａｔｉｏｎ）フィールドは、個別ＴＷＴ又はブロードキャストＴＷＴによって異なる構成を有してよい。
【0224】
個別ＴＷＴである場合に、ＴＷＴ要素内のＴＷＴパラメータ情報フィールドは、単一個別ＴＷＴパラメータセットフィールドを含む。
【0225】
ブロードキャストＴＷＴである場合に、ＴＷＴ要素内のＴＷＴパラメータ情報フィールドは、１つ以上のブロードキャストＴＷＴパラメータセットフィールドを含む。それぞれのブロードキャストＴＷＴパラメータセットは、１つのブロードキャストＴＷＴに関する具体的な情報を含んでよい。
【0226】
【0227】
要請タイプ（ｒｅｑｕｅｓｔ ｔｙｐｅ）サブフィールドは、個別ＴＷＴパラメータセットフィールドとブロードキャストＴＷＴパラメータセットフィールドにおいて、サイズは同一であるが、細部構成は互いに異なるように構成されてよい。これについては後述する。
【0228】
ターゲットウエイク時間（ｔａｒｇｅｔ ｗａｋｅ ｔｉｍｅ）サブフィールドは、後に予定されている個別／ブロードキャストＴＷＴ ＳＰの開始時間を示す。
【0229】
公称最小ＴＷＴウエイクデュレーション（ｎｏｍｉｎａｌ ｍａｘｉｍｕｍ ＴＷＴ ｗａｋｅ ｄｕｒａｔｉｏｎ）サブフィールドは、ＴＷＴ要請ＳＴＡがＴＷＴウエイク間隔デュレーションにおいてＴＷＴフロー識別子に関連したフレーム交換を完了するために目覚めさせなければならないと予想する最小単位を示す。ここで、ＴＷＴウエイク間隔は、ＴＷＴ要請ＳＴＡが予想する連続するＴＷＴ ＳＰ同士の平均時間を意味できる。
【0230】
ＴＷＴウエイク間隔仮数（ＴＷＴ Ｗａｋｅ Ｉｎｔｅｒｖａｌ Ｍａｎｔｉｓｓａ）サブフィールドは、ＴＷＴウエイク間隔値の二進数値であり、マイクロ秒（ｍｉｃｒｏｓｅｃｏｎｄ）で表示できる。
【0231】
図１７を参照すると、ＴＷＴグループ割り当て（ｇｒｏｕｐ ａｓｓｉｇｎｍｅｎｔ）サブフィールド、ＴＷＴチャネル（ｃｈａｎｎｅｌ）、及びＮＤＰページング（ｐａｇｉｎｇ）サブフィールドは、個別ＴＷＴパラメータセットフィールドにのみ含まれる。
【0232】
ＴＷＴグループ割り当てサブフィールドは、ＳＴＡが割り当てられたＴＷＴグループに関する情報をＴＷＴ要請ＳＴＡに提供する。当該情報を用いてＴＷＴグループ内のＴＷＴ値を計算することができる。ＳＴＡのＴＷＴ値は、ゼロオフセット（ｚｅｒｏ ｏｆｆｓｅｔ）の値とＴＷＴオフセットの値にＴＷＴユニットの値をかけた値と同一であってよい。
【0233】
ＴＷＴチャネルサブフィールドは、許容されるチャネルを示すビットマップを示す。ＴＷＴ要請ＳＴＡによって送信される場合に、ＴＷＴチャネルサブフィールドは、ＴＷＴ ＳＰにおいてＳＴＡが臨時基本チャネルとして使用するように要請するチャネルを示すビットマップを含んでよい。ＴＷＴ応答ＳＴＡによって送信される場合に、ＴＷＴチャネルサブフィールドは、ＴＷＴ要請が許容されるチャネルを示すビットマップを含んでよい。
【0234】
ＮＤＰページングサブフィールドは選択的（ｏｐｔｉｏｎａｌ）であり、ページングされるＳＴＡの識別子、ＮＤＰページングフレーム同士間の最大ＴＷＴウエイクインターバル個数に関する情報などを含んでよい。
【0235】
図１８を参照すると、ブロードキャストＴＷＴ情報（ｂｒｏａｄｃａｓｔ ＴＷＴ ｉｎｆｏ）サブフィールドは、ブロードキャストＴＷＴパラメータセットフィールドにのみ含まれる。ブロードキャストＴＷＴ情報サブフィールドは、３ビットの留保ビット、５ビットのブロードキャストＴＷＴ識別子（ＩＤ）サブフィールド、及び８ビットのブロードキャストＴＷＴ持続（ｐｅｒｓｉｓｔｅｎｃｅ）サブフィールドを含んでよい。ブロードキャストＴＷＴ識別子サブフィールドは、ＴＷＴ要素のＴＷＴセットアップコマンド（ｓｅｔｕｐ ｃｏｍｍａｎｄ）サブフィールドの値によって、ＳＴＡが参加を要請する、又は、ＴＷＴパラメータを提供する特定ブロードキャストＴＷＴのブロードキャストＩＤを示す。ブロードキャストＴＷＴ持続サブフィールドは、ブロードキャストＴＷＴのスケジュール上で計画されたＴＢＴＴ個数を示す。
【0236】
次に、要請タイプ（ｒｅｑｕｅｓｔ ｔｙｐｅ）サブフィールドの細部的な構成について説明する。
【0237】
まず、図１７を参照して、個別ＴＷＴパラメータセットフィールドの要請タイプサブフィールドのフォーマットについて説明する。
【0238】
ＴＷＴ要請（ｒｅｑｕｅｓｔ）サブフィールドは、要請ＳＴＡであるか、又は応答ＳＴＡであるかを示すことができる。その値が１であれば、ＴＷＴ要請ＳＴＡ又はスケジュールされるＳＴＡであることを示し、０であれば、ＴＷＴ応答ＳＴＡ又はスケジュールするＡＰであることを示すことができる。
【0239】
ＴＷＴセットアップコマンド（ｓｅｔｕｐ ｃｏｍｍａｎｄ）サブフィールドは、要請、提案、要求、受容、変更、命令、拒絶（Ｒｅｑｕｅｓｔ、Ｓｕｇｇｅｓｔ、Ｄｅｍａｎｄ、Ａｃｃｅｐｔ、Ａｌｔｅｒｎａｔｅ、Ｄｉｃｔａｔｅ、Ｒｅｊｅｃｔ）などのコマンドを示すことができる。
【0240】
トリガー（ｔｒｉｇｇｅｒ）サブフィールドは、ＴＷＴ ＳＰにおいてトリガーフレームを使用するか否かを示す。その値が１であれば、トリガーを使用し、０であれば、トリガーを使用しなくてよい。
【0241】
黙示的（ｉｍｐｌｉｃｉｔ）サブフィールドは、黙示的ＴＷＴであるか又は明示的（ｅｘｐｌｉｃｉｔ）ＴＷＴであるかを示すことができる。その値が１であれば、黙示的ＴＷＴを示し、０であれば、明示的ＴＷＴを示すことができる。
【0242】
フロータイプ（ｆｌｏｗ ｔｙｐｅ）サブフィールドは、ＴＷＴ要請ＳＴＡ（又は、ＴＷＴスケジュールされるＳＴＡ）とＴＷＴ応答ＳＴＡ（又は、ＴＷＴスケジュールするＡＰ）との相互作用類型を示すことができる。その値が１であれば、トリガーフレーム以外のフレームがＡＰからＳＴＡに送信される前に、ＳＴＡがＰＳ－Ｐｏｌｌ又はＡＰＳＤ（ａｕｔｏｍａｔｉｃ ｐｏｗｅｒ ｓａｖｅ ｄｅｌｉｖｅｒｙ）トリガーフレームを送信し、ＡＰにウエイクアップ信号を送る公知型（ａｎｎｏｕｎｃｅｄ）ＴＷＴを意味できる。その値が０であれば、非公知型ＴＷＴを意味できる。
【0243】
ＴＷＴフロー識別子（ｆｌｏｗ ｉｄｅｎｔｉｆｉｅｒ）サブフィールドは、同じＴＷＴ要請ＳＴＡとＴＷＴ応答ＳＴＡ対の間になされた他の要請から、当該ＴＷＴ要請に対する特定情報を固有に識別する３ビット値を含んでよい。
【0244】
ＴＷＴウエイク間隔指数（ｗａｋｅ ｉｎｔｅｒｖａｌ ｅｘｐｏｎｅｎｔ）サブフィールドは、ＴＷＴウエイク間隔値を二進数マイクロ秒（ｍｉｃｒｏｓｅｃｏｎｄ）単位で設定できる。個別ＴＷＴの場合には、個別ＴＷＴ ＳＰ同士間の間隔を意味できる。要請ＳＴＡのＴＷＴウエイク間隔は、［ＴＷＴ Ｗａｋｅ Ｉｎｔｅｒｖａｌ Ｍａｎｔｉｓｓａ＊２＊ＴＷＴ Ｗａｋｅ Ｉｎｔｅｒｖａｌ Ｅｘｐｏｎｅｎｔ］のように定義されてよい。
【0245】
ＴＷＴ保護（ｐｒｏｔｅｃｔｉｏｎ）サブフィールドは、ＴＷＴ保護メカニズムを使用するか否かを示すことができる。その値が１であれば、ＴＷＴ ＳＰ内のＴＸＯＰは、（ＭＵ）ＲＴＳ／ＣＴＳ又はＣＴＳ－ｔｏ－ｓｅｌｆフレームのようなＮＡＶ保護メカニズムで開始されてよく、０であれば、ＮＡＶ保護メカニズムを適用しなくてよい。
【0246】
図１８を参照すると、ブロードキャストＴＷＴパラメータセットフィールドの要請タイプサブフィールドの下位フィールドのち一部は、個別ＴＷＴパラメータセットフィールドの要請タイプサブフィールドの下位フィールドと共通するので、それに関する説明は省略する。ブロードキャストＴＷＴパラメータセットにのみ含まれるサブフィールドについて以下に説明する。
【0247】
最後のブロードキャストパラメータセット（Ｌａｓｔ Ｂｒｏａｄｃａｓｔ Ｐａｒａｍｅｔｅｒ Ｓｅｔ）サブフィールドは、最後のブロードキャストＴＷＴパラメータセットであるか否かを示す。その値が１であれば、最後のブロードキャストＴＷＴパラメータセットであることを示し、０であれば、次のブロードキャストＴＷＴパラメータセットが存在することを示すことができる。
【0248】
ブロードキャストＴＷＴ推薦（ｒｅｃｏｍｍｅｎｄａｔｉｏｎ）サブフィールドは、ブロードキャストＴＷＴ ＳＰにおいてＡＰによって送信されるフレームタイプに対する推奨事項を１～７の値で示すことができる。
【0249】
ブロードキャストＴＷＴパラメータセットフィールドの要請タイプサブフィールドの最後の１ビットは、留保（ｒｅｓｅｒｖｅｄ）されてよい。
【0250】
以下では、レイテンシーに敏感なトラフィックを支援するための本開示に係る低いレイテンシー送信方案について説明する。
【0251】
近年、有／無線トラフィックが急増しながら、レイテンシーに敏感なトラフィックも大幅に増加した。レイテンシーに敏感なトラフィックは、実時間オーディオ／ビデオ送信を含み、マルチメディア機器の拡散に伴って無線環境においてもこれを支援するための必要性が増大した。しかしながら、有線環境に比べて無線環境では、レイテンシーに敏感なトラフィックを支援する上では考慮すべき事項が多い。無線環境は有線環境に比べて送信速度が低く、周辺からの干渉問題も考慮しなければならないためである。特に、無線ＬＡＮシステムでは、ＩＳＭ（Ｉｎｄｕｓｔｒｙ－Ｓｃｉｅｎｃｅ－Ｍｅｄｉｃａｌ）帯域で媒体占有のために多数のＳＴＡが平等に競合しなければならないため、中央基地局による無線リソーススケジューリングに基づくセルラー通信ネットワークに比べて、レイテンシーに敏感なトラフィックを支援することが相対的に難しい。本開示では、無線ＬＡＮシステムにおいてレイテンシーに敏感なトラフィックを支援するための新しい方案について説明する。
【0252】
本開示において、レイテンシーは、ＩＥＥＥ ８０２．１１系列標準で定義するレイテンシーを意味できる。例えば、送信ＳＴＡのＭＡＣ層のキュー（ｑｕｅｕｅ）に、送信するフレームが入ってきた後、ＰＨＹ層で送信ＳＴＡの送信が成功裏に終わり、送信ＳＴＡが受信ＳＴＡからＡＣＫ／ブロック（ｂｌｏｃｋ）ＡＣＫなどを受信し、送信ＳＴＡのＭＡＣ層キュー（ｑｕｅｕｅ）において当該フレームが削除されるまでの時間を意味できる。
【0253】
また、本開示において、レイテンシー敏感データ（ｌａｔｅｎｃｙ ｓｅｎｓｉｔｉｖｅ ｄａｔａ）の送信を支援するｎｏｎ－ＡＰ ＳＴＡを、低いレイテンシー（Ｌｏｗ Ｌａｔｅｎｃｙ）ＳＴＡと呼ぶことができる。そして、レイテンシー敏感データ以外のデータは、一般データ（ｒｅｇｕｌａｒ ｄａｔａ）と呼ぶことができる。
【0254】
以下では、図１９を参照して、制限された（ｒｅｓｔｒｉｃｔｅｄ）ＴＷＴについて説明する。
【0255】
制限されたＴＷＴ（ｒ－ＴＷＴ）は、レイテンシー敏感データを送信する低いレイテンシーＳＴＡのためにＡＰが特別なブロードキャストＴＷＴを設定することにより、低いレイテンシーＳＴＡのためのデータ送信可能性を他のＳＴＡに比べて優先的に確保することを支援できる。ＳＴＡは、ＡＰに対して１つ以上のｒ－ＴＷＴスケジュールに対するメンバーシップを確立（ｅｓｔａｂｌｉｓｈ）することができる。
【0256】
ここで、ｒ－ＴＷＴ合意は、ブロードキャストＴＷＴ合意と同じ過程によって確立されてよく、そのために、ブロードキャストＴＷＴ要素は、ｒ－ＴＷＴパラメータセットフィールドを含むように定義されてよい。例えば、ｒ－ＴＷＴパラメータセットは、他のブロードキャストＴＷＴパラメータセットフィールドと区別される特定ブロードキャストＴＷＴパラメータセットフィールドを称することができる。すなわち、ｒ－ＴＷＴパラメータセットフィールドは、ブロードキャストＴＷＴパラメータセットフィールドの特別なケースに該当し得る。また、ＡＰは、ｒ－ＴＷＴ ＳＰを公知（ａｎｎｏｕｎｃｅ）することができる。
【0257】
本開示では、前述したように、レイテンシー敏感データの送信を支援するｎｏｎ－ＡＰ ＳＴＡを、低いレイテンシーＳＴＡと称し、レイテンシー敏感データでないデータを、一般データ（ｒｅｇｕｌａｒ ｄａｔａ）と称することができる。
【0258】
追加又は代案として、特定ｒ－ＴＷＴに関連した低いレイテンシーＳＴＡを、メンバーｒ－ＴＷＴ ｓｃｈｅｄｕｌｅｄ ＳＴＡと称し、その他のＳＴＡを、非メンバーＳＴＡと称する。非メンバーＳＴＡは、ｒ－ＴＷＴ動作／ＴＷＴ動作（例えば、個別ＴＷＴ及び／又はブロードキャストＴＷＴ）を支援するキャパビリティを有しているが、如何なるｒ－ＴＷＴのメンバーでもないか、ｒ－ＴＷＴ動作／ＴＷＴ動作を支援しながら他のｒ－ＴＷＴのメンバーであるか、又はｒ－ＴＷＴ動作／ＴＷＴ動作を支援するキャパビリティを保有していないＳＴＡであってもよい。
【0259】
ブロードキャストＴＷＴの制限されたＳＰ（又は、ｒ－ＴＷＴ ＳＰ）動作を支援するＳＴＡ（例えば、低いレイテンシーＳＴＡ）は、ｒ－ＴＷＴ動作に基づいてレイテンシー敏感データを送信しなければならないことをＡＰに知らせることができる。仮にＡＰがｒ－ＴＷＴ動作／モードを支援する場合には、ＡＰは、低いレイテンシーＳＴＡと他のＳＴＡに、各ＳＴＡが要請したＴＷＴのスケジューリング情報を含むフレームを送信することができる。例えば、ｒ－ＴＷＴに対する動作を行うために、ｎｏｎ－ＡＰ ＳＴＡは、ビーコンフレーム、プローブ応答フレーム、（再）結合応答フレーム、又はその他の未定義されているフォーマットのフレーム（例えば、ブロードキャスト、アドバタイズメント、公知用途のフレーム）を用いて、ｒ－ＴＷＴ関連情報をＡＰから取得することができる。
【0260】
ｒ－ＴＷＴ動作によれば、（ＭＵ）ＲＴＳ／ＣＴＳ又はＣＴＳ－ｔｏ－ｓｅｌｆのようなＮＡＶ、又は沈黙インターバル（ｑｕｉｅｔ ｉｎｔｅｒｖａｌ）などを用いて、ｒ－ＴＷＴ ＳＰ内で別のＴＸＯＰ（すなわち、他のＳＴＡのアクセスが制限される）が確保（又は、実行）されてよい。特定ｒ－ＴＷＴ ＳＰが開始される前に、前記特定ｒ－ＴＷＴスケジュールに対するメンバーシップを有するＳＴＡ以外の他のＳＴＡ（すなわち、非メンバーＳＴＡ）のＴＸＯＰが存在する場合にはそれを止めなければならない。そして、前記他のＳＴＡ（すなわち、非メンバーＳＴＡ）のＴＸＯＰは、前記特定ｒ－ＴＷＴ ＳＰが終わった後にさらに行われてよい。これを、非メンバーＳＴＡのｒ－ＴＷＴ ＳＰに対するＴＸＯＰ規則（ｒｕｌｅ）ベース動作と称することができる。このようなｒ－ＴＷＴのＴＸＯＰ規則により、レイテンシー敏感データに対してより予測可能な低遅延サービスを提供することができる。
【0261】
ｒ－ＴＷＴの条件付き実行方式
【0262】
上述したｒ－ＴＷＴのＴＸＯＰ規則によれば、公知されたｒ－ＴＷＴ ＳＰを支援すると同時に、当該ｒ－ＴＷＴ ＳＰを公知したＡＰに結合（ａｓｓｏｃｉａｔｉｏｎ）されたＥＨＴ ｎｏｎ－ＡＰは、当該ｒ－ＴＷＴ ＳＰの開始前に自分のＴＸＯＰを終了しなければならない。
【0263】
本開示は、上述したｒ－ＴＷＴ ＳＰのＴＸＯＰ規則に対して追加された実行条件について説明する。これにより、上述したｒ－ＴＷＴ ＳＰのＴＸＯＰ規則が、目的とする予測可能な低遅延サービスを提供でき、既存のデータ送受信の流れを防止しない方式により、遅延敏感データ／トラフィック送信の効率性を高めることができる。
【0264】
図２０は、本開示の一例に係る第１ＳＴＡの制限されたＴＷＴ動作を説明するための図である。図２０及び図２１で、第１ＳＴＡは、（ＡＰに結合された）ＥＨＴ ｎｏｎ－ＡＰ ＳＴＡであり、第２ＳＴＡはＡＰであるが、これに限定されるものではない。
【0265】
第１ＳＴＡは、制限されたターゲットウエイクタイム（ｒｅｓｔｒｉｃｔｅｄ ｔａｒｇｅｔ ｗａｋｅ ｔｉｍｅ，ｒ－ＴＷＴ）メンバーシップセットアップ手順を第２ＳＴＡと行うことができる（Ｓ２０１０）。
【0266】
ｒ－ＴＷＴメンバーシップセットアップ手順は、ブロードキャストＴＷＴメンバーシップ手順と同一に確立（ｅｓｔａｂｌｉｓｈ）されてよい。ただし、ｒ－ＴＷＴメンバーシップセットアップ手順において、ＴＷＴセットアップフレーム上で送信されるブロードキャストＴＷＴ要素は、１つ以上のｒ－ＴＷＴパラメータセットフィールドが含まれてよい。
【0267】
第２ＳＴＡ（例えば、ｒ－ＴＷＴスケジューリングＡＰ）と第１ＳＴＡ（例えば、Ｒ－ＴＷＴスケジュールされたＳＴＡ）は、セットアップされたｒ－ＴＷＴメンバーシップに対してＤＬ及びＵＬで遅延敏感トラフィックを伝達するＴＩＤを識別するためにｒ－ＴＷＴトラフィック情報フィールドを設定することができる。すなわち、第１ＳＴＡ及び第２ＳＴＡによって少なくとも１つのｒ－ＴＷＴ ＤＬ ＴＩＤ又は少なくとも１つのｒ－ＴＷＴ ＵＬ ＴＩＤが設定されてよい。
【0268】
ｒ－ＴＷＴトラフィック情報フィールドにおいてＤＬ及びＵＬで遅延敏感トラフィックと指示されたＴＩＤは、ｒ－ＴＷＴ ＴＩＤと総称できる。ｒ－ＴＷＴトラフィック情報フィールドにおいてＤＬ及びＵＬで遅延敏感トラフィックと指示されたＴＩＤは、それぞれ、ＤＬ及びＵＬにマップされたＴＩＤ集合内にあってよい。
【0269】
以下では、受諾（Ａｃｃｅｐｔ）ＴＷＴを示すＴＷＴ応答フレームのＴＷＴ要素のｒ－ＴＷＴトラフィック情報フィールドに指定されたＴＩＤを、Ｒ－ＴＷＴ ＤＬ ＴＩＤ（ｓ）又はＲ－ＴＷＴ ＵＬ ＴＩＤ（ｓ）と称する。
【0270】
第１ＳＴＡは、ブロードキャストＴＷＴ要素に含まれたｒ－ＴＷＴスケジュール情報を、第２ＳＴＡから受信することができる（Ｓ２０２０）。
【0271】
具体的には、設定されたｒ－ＴＷＴメンバーシップが存在する場合に、第２ＳＴＡは、送信された管理フレームに含まれたブロードキャストＴＷＴ要素にｒ－ＴＷＴパラメータセットフィールドを含めることにより、ｒ－ＴＷＴスケジュール情報を公知することができる。
【0272】
一例として、第１情報は、ビーコンフレーム及び／又はプローブ応答フレームでｒ－ＴＷＴスケジュール情報を受信することができる。
【0273】
本開示の一例として、ｒ－ＴＷＴスケジュール情報によって公知されたｒ－ＴＷＴ ＳＰ内の第１ＴＸＯＰの特定部分が、少なくとも１つのｒ－ＴＷＴ下りリンク（ｄｏｗｎｌｉｎｋ，ＤＬ）ＴＩＤに対応するＤＬフレームの伝達（ｄｅｌｉｖｅｒｙ）又は少なくとも１つのｒ－ＴＷＴ上りリンク（ｕｐｌｉｎｋ，ＵＬ）ＴＩＤに対応するＵＬフレームの要請（ｓｏｌｉｃｉｔ）に用いられないことに基づいて、第１ＴＸＯＰはｒ－ＴＷＴ ＳＰの開始時間前に終了してよい。
【0274】
具体的には、ｒ－ＴＷＴ ＳＰを公知した第２ＳＴＡが第１ＴＸＯＰのホルダー（ｈｏｌｄｅｒ）であるとき、第１ＴＸＯＰの特定部分が、少なくとも１つのｒ－ＴＷＴ ＤＬ ＴＩＤに対応するＤＬフレームの伝達（ｄｅｌｉｖｅｒｙ）又は少なくとも１つのｒ－ＴＷＴ ＵＬ ＴＩＤに対応するＵＬフレームの要請（ｓｏｌｉｃｉｔ）に用いられない場合に、第２ＳＴＡは、第１ＴＸＯＰがｒ－ＴＷＴ ＳＰの開始時間前に終了するように保証（ｅｎｓｕｒｅ）できる。
【0275】
すなわち、第１ＴＸＯＰの特定部分が少なくとも１つのｒ－ＴＷＴ ＤＬ ＴＩＤ又は少なくとも１つのｒ－ＴＷＴ ＵＬ ＴＩＤに対応するフレーム送受信に用いられない場合に、第２ＳＴＡは、第１ＴＸＯＰがｒ－ＴＷＴ ＳＰの開始時間前に終了するように保証（ｅｎｓｕｒｅ）できる。
【0276】
さらに他の例として、第１ＴＸＯＰの特定部分が少なくとも１つのｒ－ＴＷＴ ＤＬ ＴＩＤに対応するＤＬフレームの伝達又は少なくとも１つのｒ－ＴＷＴ ＵＬ ＴＩＤに対応するＵＬフレームの要請に用いられることに基づいて、第１ＴＸＯＰはｒ－ＴＷＴ ＳＰの開始時間後にも終了しなくてよい。
【0277】
第１ＴＸＯＰがｒ－ＴＷＴ ＳＰの開始時間後に終了しないことに基づいて、ｒ－ＴＷＴ ＳＰの終了時間が延期されてよい。一例として、第１ＴＸＯＰがｒ－ＴＷＴ ＳＰの開始時間後に終了しないことにより、遅延されたｒ－ＴＷＴ ＳＰの時間だけｒ－ＴＷＴ ＳＰの終了時間が延期されてよい。
【0278】
追加又は代案として、ｒ－ＴＷＴ ＳＰの終了時間が延期され得る最大時間は、遅延されたｒ－ＴＷＴ ＳＰの（開始）時間値と設定／指示／定義されてよい。
【0279】
本開示のさらに他の例として、第１ＳＴＡが第２ＴＸＯＰのホルダーであることに基づいて、第２ＴＸＯＰは、第２ＳＴＡによって公知されたｒ－ＴＷＰ ＳＰの開始前に終了してよい。すなわち、第１ＳＴＡは、第２ＴＸＯＰが第２ＳＴＡによって公知されたｒ－ＴＷＴ ＳＰの開始時点前に終了するように保証できる。
【0280】
図２１は、本開示の一例に係る第２ＳＴＡの制限されたＴＷＴ動作を説明するための図である。
【0281】
第２ＳＴＡは、制限されたターゲットウエイクタイム（ｒｅｓｔｒｉｃｔｅｄ ｔａｒｇｅｔ ｗａｋｅ ｔｉｍｅ，ｒ－ＴＷＴ）メンバーシップセットアップ手順を第１ＳＴＡと行うことができる（Ｓ２１１０）。
【0282】
一例として、第２ＳＴＡは、送信するｒ－ＴＷＴパラメータセットフィールドにおいてトリガーフィールド値を１に設定できる。
【0283】
第２ＳＴＡは、ブロードキャストＴＷＴ要素に含まれたｒ－ＴＷＴスケジュール情報を第１ＳＴＡに送信できる（Ｓ２１２０）。
【0284】
具体的には、設定されたｒ－ＴＷＴメンバーシップが存在する場合に、第２ＳＴＡは、ブロードキャストＴＷＴ要素にｒ－ＴＷＴパラメータセットフィールドを含めることにより、ｒ－ＴＷＴスケジュール情報を公知することができる。
【0285】
Ｓ２１１０及びＳ２１２０に関連した動作及びパラメータは、Ｓ２０１０及びＳ２０２０に関連した動作及びパラメータに対応し得るところ、重複する説明は省略する。
【0286】
以下では、本開示に係るｒ－ＴＷＴの条件付き実行方式について具体的に説明する。すなわち、上述したｒ－ＴＷＴ ＳＰのＴＸＯＰ規則に対して追加の条件が反映されたｒ－ＴＷＴ ＴＷＴ ＳＰの条件付きＴＸＯＰ規則について説明する。１つ以上のＳＴＡは、後述する実施例のうち１つ又はそれ以上の実施例による動作を行うことができる。
【0287】
実施例１
【0288】
実施例１は、データの重要度（ｄａｔａ ｐｒｉｏｒｉｔｙ）によってｒ－ＴＷＴ ＳＰの条件付きＴＸＯＰ規則を実行する方法に関する。
【0289】
ＡＰから公知されたｒ－ＴＷＴ ＳＰを支援すると同時に、ｒ－ＴＷＴ ＳＰを公知した当該ＡＰに結合（ａｓｓｏｃｉａｔｉｏｎ）されたＥＨＴ ｎｏｎ－ＡＰ ＳＴＡは、当該ｒ－ＴＷＴ ＳＰの開始前に自分のＴＸＯＰを終了すべき規則が定義されてよい。ただし、前記規則は、当該ＳＴＡ（例えば、前記ＥＨＴ ｎｏｎ－ＡＰ ＳＴＡ又は／及びＡＰ）が当該ＴＸＯＰにおいて送信するデータが遅延敏感データよりも緊急に送信されるべきデータでない場合に限って実行／適用されてよい。
【0290】
すなわち、当該ＳＴＡ（例えば、前記ＥＨＴ ｎｏｎ－ＡＰ ＳＴＡ又は／及びＡＰ）が当該ＴＸＯＰにおいて送信するデータが、遅延敏感データよりも緊急に送信されるべきデータである場合に、前記規則が適用／実行されてよい。
【0291】
具体的には、特定条件を満たす場合にのみ前記規則が適用／実行されてよく、特定条件は、後述したオプションのうち１つとして設定／定義されてよい。
【0292】
オプション１
【0293】
ＴＸＯＰで送信するデータが遅延トラフィック（ｌａｔｅｎｃｙ ｔｒａｆｆｉｃ）に分類されたＴＩＤのうち１つに対するデータでない場合に、上述したＴＸＯＰ規則が適用／実行されてよい。
【0294】
すなわち、ＴＸＯＰで送信するデータが遅延トラフィックに分類されたＴＩＤのうち１つに対するデータでない場合に、当該ＳＴＡ（例えば、前記ＥＨＴ ｎｏｎ－ＡＰ ＳＴＡ又は／及びＡＰ）は、ｒ－ＴＷＴ ＳＰが始まると当該ＴＸＯＰを終了し得る。
【0295】
そして、ＴＸＯＰで送信するデータが遅延トラフィックに分類されたＴＩＤのうち１つに対するデータである場合に、当該ＳＴＡ（例えば、前記ＥＨＴ ｎｏｎ－ＡＰ ＳＴＡ又は／及びＡＰ）は、（ｒ－ＴＷＴ ＳＰの開始時点が経過しても）当該ＴＸＯＰを終了しないで当該データを送信し続けることができる。
【0296】
オプション２
【0297】
ＴＸＯＰで送信するデータが、ｒ－ＴＷＴ ＳＰで指定された遅延トラフィックよりも低い優先順位を有するトラフィックである場合（すなわち、ＴＸＯＰで送信するデータが遅延敏感データよりも緊急に送信されるべきデータでない場合）に、上述したＴＸＯＰ規則が適用／実行されてよい。
【0298】
すなわち、ＴＸＯＰで送信するデータが、ｒ－ＴＷＴ ＳＰで指定された遅延トラフィックよりも低い優先順位を有するトラフィックである場合に、当該ＳＴＡ（例えば、前記ＥＨＴ ｎｏｎ－ＡＰ ＳＴＡ又は／及びＡＰ）は、ｒ－ＴＷＴ ＳＰが始まると当該ＴＸＯＰを終了してよい。
【0299】
そして、ＴＸＯＰで送信するデータが、ｒ－ＴＷＴ ＳＰで指定された遅延トラフィックよりも高い優先順位を有するか又は同一優先順位を有するトラフィックである場合に、当該ＳＴＡ（例えば、前記ＥＨＴ ｎｏｎ－ＡＰ ＳＴＡ又は／及びＡＰ）は、（ｒ－ＴＷＴ ＳＰの開始時点が経過しても）当該ＴＸＯＰを終了しないで当該データを送信し続けることができる。
【0300】
オプション３
【0301】
ＴＸＯＰで送信するデータが特定ＡＣに属している場合に、上述したＴＸＯＰ規則が適用／実行されてよい。
【0302】
すなわち、ＴＸＯＰで送信するデータが特定ＡＣである場合に、当該ＳＴＡ（例えば、前記ＥＨＴ ｎｏｎ－ＡＰ ＳＴＡ又は／及びＡＰ）は、ｒ－ＴＷＴ ＳＰが始まると当該ＴＸＯＰを終了してよい。そして、ＴＸＯＰで送信するデータが特定ＡＣでない他のＡＣである場合（例えば、ＡＣ＿ＶＯ又はＡＣ＿ＶＩである場合）に、当該ＳＴＡ（例えば、前記ＥＨＴ ｎｏｎ－ＡＰ ＳＴＡ又は／及びＡＰ）は、（ｒ－ＴＷＴ ＳＰの開始時点が経過しても）、当該ＴＸＯＰを終了しないで当該データを送信し続けることができる。
【0303】
ここで、特定ＡＣは、ＡＣ＿ＢＥ又はＡＣ＿ＢＫであってよいが、これに限定されるものではない。例えば、ＴＸＯＰで送信するデータがＡＣ＿ＶＩである場合にも、上述したＴＸＯＰ規則が適用／実行されてよい。
【0304】
実施例２
【0305】
実施例２は、ｒ－ＴＷＴ ＳＰを交渉（ｎｅｇｏｔｉａｔｉｏｎ）したＳＴＡが送受信するデータの重要度によってｒ－ＴＷＴ ＳＰの条件付きＴＸＯＰ規則を実行する方法に関する。
【0306】
ＡＰから公知されたｒ－ＴＷＴ ＳＰを支援すると同時に、当該ｒ－ＴＷＴ ＳＰを公知した当該ＡＰに結合されたＥＨＴ ｎｏｎ－ＡＰ ＳＴＡが、ｒ－ＴＷＴ ＳＰの開始前に当該ＴＸＯＰを終了するようにＴＸＯＰ規則が定義されてよい。
【0307】
ただし、ｒ－ＴＷＴセットアップ時に、当該ＴＸＯＰに送信されるデータが当該ＳＴＡ（例えば、ＥＨＴ ｎｏｎ－ＡＰ ＳＴＡ及び／又はＡＰ）が交渉したＵＬ／ＤＬ ＴＩＤによって遅延敏感データ／トラフィックとして指示されたデータでない場合に限って当該ＴＸＯＰ規則が適用／実行されてよい。
【0308】
すなわち、当該ＴＸＯＰに送信されるデータが当該ＳＴＡ（例えば、ＥＨＴ ｎｏｎ－ＡＰ ＳＴＡ及び／又はＡＰ）が交渉したＵＬ／ＤＬ ＴＩＤによって遅延敏感データ／トラフィックとして指示されたデータである場合に、当該ＳＴＡは、ｒ－ＴＷＴ ＳＰの開始時点後にも当該ＴＸＯＰを終了しなくてよい。
【0309】
具体的には、ｒ－ＴＷＴを支援しながら、互いに同一の値のブロードキャストＴＷＴ ＩＤを有するＳＴＡは、ＡＰからｒ－ＴＷＴ ＳＰの情報を公知されてよい。ＡＰ、及びｒ－ＴＷＴ ＳＰを割り当てられるためにｒ－ＴＷＴセットアップを進行するＳＴＡは、ＵＬ／ＤＬ ＴＩＤを用いて遅延敏感データ／トラフィックに対して交渉することができる。
【0310】
これにより、ＡＰ、及びｒ－ＴＷＴ ＳＰを割り当てられたＳＴＡは、当該ｒ－ＴＷＴ ＳＰで遅延敏感データ／トラフィックであることを暗示／指示するＴＩＤ情報を共有することができる。上述した条件によって、当該ＳＴＡが、（スケジュールされたｒ－ＴＷＴ ＳＰによって）遅延敏感データ／トラフィックとして暗示／指示されたＴＩＤを有するデータを送信する場合に、ｒ－ＴＷＴ ＳＰ開始時点前に自分のＴＸＯＰを中止する必要がない。
【0311】
【0312】
ＲＳＰ ＳＴＡ（ｒ－ＴＷＴ ＳＰを支援するＳＴＡ）であるＲＳＰ ＳＴＡ １、ＲＳＰ ＳＴＡ ２、及びＲＳＰ ＳＴＡ ３はいずれも、ＴＷＴセットアップ過程を行うことができる。ただし、図２２及び図２３では、ＲＳＰ ＳＴＡ ２がＴＷＴセットアップ手順を行う過程、及びＡＰとＲＳＰ ＳＴＡ ２とがメンバーシップを設定する過程を例示する。
【0313】
すなわち、図２２及び図２３は、ＡＰがＴＷＴ情報をビーコンフレームで１つ以上のＲＳＰ ＳＴＡに公知すれば、当該ＴＷＴ情報を受信したＲＳＰ ＳＴＡが、所望のＴＷＴに相応するブロードキャストＴＷＴ ＩＤに基づいてＴＷＴ要請を送る動作を例示する。
【0314】
これにより、ＲＳＰ ＳＴＡ １、ＲＳＰ ＳＴＡ ２、及びＲＳＰ ＳＴＡ３はいずれも同一のブロードキャストＴＷＴ ＩＤを有し得る。ＲＳＰ ＳＴＡ １は、ＴＩＤ ０、１、及び２に該当するデータを、遅延敏感データ／トラフィックに分類できる。ＲＳＰ ＳＴＡ ２及びＲＳＰ ＳＴＡ ３は、ＴＩＤ ０、４、及び５に該当するデータを遅延敏感データ／トラフィックに分類できる。
【0315】
ＡＰの送信したビーコンフレームに、ＲＳＰ ＳＴＡ３に割り当てられたｒ－ＴＷＴ ＳＰの情報を含んでいる場合に、当該ｒ－ＴＷＴ ＳＰで遅延敏感データ／トラフィックに分類された（ＤＬ／ＵＬ）データは、ＴＩＤが０、４及び５に対応するデータであってよい。当該ｒ－ＴＷＴ ＳＰ開始前にＲＳＰ ＳＴＡ ２がＴＩＤ ０、４及び５に該当するデータを送信する場合に、ＲＳＰ ＳＴＡ ２は、ｒ－ＴＷＴ ＳＰ前に自分のＴＸＯＰを中止しないで、ＴＩＤ ０、４及び５に該当するデータの送受信を完了することができる。
【0316】
ここで、ｒ－ＴＷＴ ＳＰの開始時点からＴＸＯＰが完了した時点までの時区間だけｒ－ＴＷＴ ＳＰが拡張されてよい。すなわち、ＴＸＯＰが完了する時点からｒ－ＴＷＴ ＳＰが始まってよく、当該ｒ－ＴＷＴ ＳＰは前記時区間だけ拡張され得る。追加又は代案として、ｒ－ＴＷＴ ＳＰの終了時間が延期され得る最大時間は、遅延されたｒ－ＴＷＴ ＳＰの（開始）時間値と設定／指示／定義されてよい。
【0317】
実施例３
【0318】
実施例３は、ＴＸＯＰホルダー（ｈｏｌｄｅｒ）によって条件付きで上述のＴＸＯＰ規則を実行／適用する方式に関する。
【0319】
ＡＰから公知されたｒ－ＴＷＴ ＳＰを支援すると同時に、当該ｒ－ＴＷＴ ＳＰを公知した当該ＡＰに結合されたＥＨＴ ｎｏｎ－ＡＰ ＳＴＡは、ｒ－ＴＷＴ ＳＰの開始前に自分のＴＸＯＰを終了しなければならない。ただし、当該ＥＨＴ ｎｏｎ－ＡＰ ＳＴＡが、ＡＰから公知されたｒ－ＴＷＴ ＳＰを割り当てられたＥＨＴ ｎｏｎ－ＡＰ ＳＴＡである場合には、自分のＴＸＯＰを中止／終了する必要がない。
【0320】
既存のｒ－ＴＷＴのＴＸＯＰ規則は、ｒ－ＴＷＴ ＳＰ前に進行中であるＴＸＯＰを、ｒ－ＴＷＴ ＳＰが始まると無条件で止める動作を定義しており、これは、ｒ－ＴＷＴ ＳＰ内で遅延敏感データ／トラフィックの送受信動作が安全に完了するためである。
【0321】
ただし、ｒ－ＴＷＴ ＳＰ前に進行中であったＴＸＯＰのホルダーと、当該ｒ－ＴＷＴ ＳＰを割り当てられたＳＴＡとが同一である場合に、当該ＳＴＡは、ｒ－ＴＷＴ ＳＰ開始時点前に自分のＴＸＯＰを中断する必要がない。すなわち、当該ＳＴＡは、自分のＴＸＯＰをそのまま維持しながら、ｒ－ＴＷＴ ＳＰ内で効率的に遅延敏感データ／トラフィックの送受信を完了することができる。
【0322】
【0323】
図２４及び図２５には、ＡＰとＲＳＰ ＳＴＡ ２がメンバーシップを設定する過程を例示している。ＡＰがＴＷＴ情報をビーコンフレームで公知すると、当該ＴＷＴ情報を受信したＳＴＡは、所望のＴＷＴに相応するブロードキャストＴＷＴ ＩＤに基づいてＴＷＴ要請をＡＰに送信できる。
【0324】
ＡＰの送信したビーコンフレームに、ＲＳＰ ＳＴＡ ２に割り当てたｒ－ＴＷＴ ＳＰ（ＲＳＰ）の情報を含んでいる場合に、ＲＳＰ ＳＴＡ ２は、スケジュールされたｒ－ＴＷＴ ＳＰ前に自分のＴＸＯＰでデータを送信するＴＸＯＰホルダーに該当し得る。
【0325】
このとき、実施例３に係る条件付きＴＸＯＰ規則が適用される場合に、スケジュールされたｒ－ＴＷＴ ＳＰが、ＲＳＰ ＳＴＡ ２に割り当てられたｒ－ＴＷＴ ＳＰであるので、ＲＳＰ ＳＴＡ ２は、自分のＴＸＯＰを中止しないで、ｒ－ＴＷＴ ＳＰ内で（ＵＬ／ＤＬ）遅延敏感トラフィックを送受信することができる。
【0326】
実施例４
【0327】
ｒ－ＴＷＴ ＳＰのＴＸＯＰ規則に対して上述した実施例１、実施例２、又は実施例３のうち少なくとも１つが適用されてよい。実施例４は、ＡＰが上述の実施例が適用されたｒ－ＴＷＴ ＳＰのＴＸＯＰ規則を他のＳＴＡに知らせ得る方法に関する。
【0328】
非要請型（ｕｎｓｏｌｉｃｉｔｅｄ）方法による場合に、ＡＰは、ビーコンフレーム、（ブロードキャスト）プローブ応答フレーム、他の（又は／及び新しい）公知（又は／及びブロードキャスト）フレームを用いて、上述の実施例に関する情報を他のＳＴＡに知らせることができる。
【0329】
【0330】
具体的には、図２６は、一般（ｒｅｇｕｌａｒ）データが遅延敏感データよりも緊急な場合（又は／及び、一般データが遅延敏感データよりも高い優先順位を有する場合）のｒ－ＴＷＴ動作実行の例示である。図２７は、遅延敏感データが一般データよりも緊急な場合（又は／及び、遅延敏感データが一般データよりも高い優先順位を有する場合）のｒ－ＴＷＴ動作を例示する。
【0331】
追加又は代案として、図２８に示すように、端末及びＡＰは、交渉手順（例えば、プローブ要請手順、プローブ応答手順、結合要請手順、結合応答手順、新しい要請（Ｎｅｗ Ｒｅｑｕｅｓｔ）手順、及び新しい応答手順など）によって当該実施例に関する情報を交換することができる。ここで、プローブ／結合／新しい要請／応答手順は、プローブ／結合／新しい要請／応答フレームを送受信する手順を意味できる。
【0332】
交渉手順において、遅延トラフィックに関する情報（例えば、実時間ゲーミング（Ｒｅａｌ－ｔｉｍｅ ｇａｍｉｎｇ）、クラウドゲーミング（Ｃｌｏｕｄ ｇａｍｉｎｇ）、実時間ビデオ（Ｒｅａｌ－ｔｉｍｅ ｖｉｄｅｏ）、ロボット及び産業自動化（Ｒｏｂｏｔｉｃ ａｎｄ ｉｎｄｕｓｔｒｉａｌ ａｕｔｏｍａｔｉｏｎ）など）、各ＡＰ／ＳＴＡのｒ－ＴＷＴ ＳＰの支援の有無などに関する情報が交換されてよい。
【0333】
これにより、ＡＰ及び低遅延ＳＴＡは、送信される遅延敏感トラフィックのための最適の環境を設定することができる。一例として、後述する方式のうち少なくとも１つの方式により、上述した情報の送受信が行われてよい。
【0334】
方式１：ＡＰと低遅延ＳＴＡは、交渉手順において１回の要請及び応答手順によって上述の情報を交換できる。
【0335】
方式２：ＡＰと低遅延ＳＴＡは、上述の情報を、ｉ）プローブ要請手順及びプローブ応答手順、及びｉｉ）結合要請手順及び結合応答手順にわたって（又は、分けて）送信できる。
【0336】
方式３：低遅延ＳＴＡに関する情報を送信するための別の新規要請手順及び新規応答手順によって上述の情報が交換されてよい。
【0337】
以上で説明された実施例は、本開示の構成要素及び特徴が所定の形態で結合したものである。各構成要素又は特徴は、特に明示的言及がない限り、選択的なものとして考慮されるべきである。各構成要素又は特徴は、他の構成要素又は特徴と結合しない形態で実施されてもよい。また、一部の構成要素及び／又は特徴を結合させて本開示の実施例を構成することも可能である。本開示の実施例において説明される動作の順序は変更されてよい。ある実施例の一部の構成又は特徴は他の実施例に含まれてもよく、或いは他の実施例の対応する構成又は特徴に取り替えられてもよい。特許請求の範囲において明示的な引用関係を有しない請求項を結合させて実施例を構成するか、或いは出願後の補正によって新しい請求項として含めることができることは明らかである。
【0338】
本開示は、本開示の必須特徴を外れない範囲で他の特定の形態として具体化できることは当業者に自明である。したがって、上述した詳細な説明はいかなる面においても制限的に解釈されてはならず、例示的なものとして考慮されるべきである。本開示の範囲は、添付する請求項の合理的解釈によって決定されるべきであり、本開示の等価的範囲内における変更はいずれも本開示の範囲に含まれる。
【0339】
本開示の範囲は、様々な実施例の方法による動作を装置又はコンピュータ上で実行させるソフトウェア又はマシン実行可能な命令（例えば、運営体制、アプリケーション、ファームウェア（ｆｉｒｍｗａｒｅ）、プログラムなど）、及びこのようなソフトウェア又は命令などが記憶されて装置又はコンピュータ上で実行可能な非一時的コンピュータ可読媒体（ｎｏｎ－ｔｒａｎｓｉｔｏｒｙ ｃｏｍｐｕｔｅｒ－ｒｅａｄａｂｌｅ ｍｅｄｉｕｍ）を含む。本開示で説明する特徴を実行するプロセシングシステムをプログラミングするために利用可能な命令は、記憶媒体又はコンピュータ可読記憶媒体上に／内に記憶されてよく、このような記憶媒体を含むコンピュータプログラム製品を用いて、本開示に説明の特徴が具現されてよい。記憶媒体は、ＤＲＡＭ、ＳＲＡＭ、ＤＤＲ ＲＡＭ又は他のランダムアクセスソリッドステートメモリデバイスのような高速ランダムアクセスメモリを含むことができるが、それに制限されず、１つ以上の磁気ディスク記憶デバイス、光ディスク記憶装置、フラッシュメモリデバイス又は他の非揮発性ソリッドステート記憶デバイスのような非揮発性メモリを含むことができる。メモリは選択的に、プロセッサから遠隔に位置している１つ以上の記憶デバイスを含む。メモリ又は代案としてメモリ内の非揮発性メモリデバイスは、非一時的コンピュータ可読記憶媒体を含む。本開示に説明の特徴は、マシン可読媒体の任意の一つに記憶され、プロセシングシステムのハードウェアを制御でき、プロセシングシステムが本開示の実施例に係る結果を活用する他のメカニズムと相互作用するようにするソフトウェア及び／又はファームウェアに統合されてよい。このようなソフトウェア又はファームウェアは、アプリケーションコード、デバイスドライバー、運営体制及び実行環境／コンテナを含むことができるが、これに限定されない。
【産業上の利用可能性】
【0340】
本開示で提案する方法は、ＩＥＥＥ ８０２．１１ベースシステムに適用される例を中心に説明したが、ＩＥＥＥ ８０２．１１ベースシステムの他にも様々な無線ＬＡＮ又は無線通信システムに適用することが可能である。
【図1】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
【図11】
【図12】
【図13】
【図14】
【図15】
【図16】
【図17】
【図18】
【図19】
【図20】
【図21】
【図22】
【図23】
【図24】
【図25】
【図26】
【図27】
【図28】
【手続補正書】
【提出日】2024-05-29
【手続補正1】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項1】
無線ＬＡＮシステムにおいて第１ステーション（ＳＴＡ）によって通信を行う方法であって、制限されたターゲットウエイクタイム（ｒｅｓｔｒｉｃｔｅｄ ｔａｒｇｅｔ ｗａｋｅ ｔｉｍｅ，ｒ－ＴＷＴ）メンバーシップセットアップ手順を第２ＳＴＡと行う段階と、
ブロードキャスト（ｂｒｏａｄｃａｓｔ）ＴＷＴ要素（ｅｌｅｍｅｎｔ）に含まれたｒ－ＴＷＴスケジュール情報を前記第２ＳＴＡから受信する段階と、を含み、
前記ｒ－ＴＷＴスケジュール情報によって公知されたｒ－ＴＷＴ ＳＰ（ｓｅｒｖｉｃｅ ｐｅｒｉｏｄ）内の第１ＴＸＯＰ（ｔｒａｎｓｍｉｓｓｉｏｎ ｏｐｐｏｒｔｕｎｉｔｙ）の特定部分が、少なくとも１つのｒ－ＴＷＴ下りリンク（ｄｏｗｎｌｉｎｋ，ＤＬ）トラフィック識別（ｔｒａｆｆｉｃ ｉｄｅｎｔｉｆｉｅｒ，ＴＩＤ）に対応するＤＬフレームの伝達又は少なくとも１つのｒ－ＴＷＴ上りリンク（ｕｐｌｉｎｋ，ＵＬ）ＴＩＤに対応するＵＬフレームの要請に用いられないことに基づいて、前記第１ＴＸＯＰは前記ｒ－ＴＷＴ ＳＰの開始時間前に終了する、方法。
【請求項2】
前記第１ＴＸＯＰの特定部分が前記少なくとも１つのｒ－ＴＷＴ ＤＬ ＴＩＤに対応するＤＬフレームの伝達又は前記少なくとも１つのｒ－ＴＷＴ ＵＬ ＴＩＤに対応するＵＬフレームの要請に用いられることに基づいて、前記第１ＴＸＯＰは前記ｒ－ＴＷＴ ＳＰの開始時間後にも終了しない、請求項１に記載の方法。
【請求項3】
前記少なくとも１つのｒ－ＴＷＴ ＤＬ ＴＩＤ又は前記少なくとも１つのｒ－ＴＷＴ ＵＬ ＴＩＤが、前記第１ＳＴＡ及び前記第２ＳＴＡによって設定される、請求項１に記載の方法。
【請求項4】
前記第２ＳＴＡは、前記第１ＴＸＯＰのホルダー（ｈｏｌｄｅｒ）である、請求項１に記載の方法。
【請求項5】
前記第１ＳＴＡが第２ＴＸＯＰのホルダーであることに基づいて、前記第２ＴＸＯＰは前記ｒ－ＴＷＴ ＳＰの開始時間前に終了する、請求項１に記載の方法。
【請求項6】
前記ｒ－ＴＷＴスケジュール情報は、ビーコンフレーム又はプローブ（ｐｒｏｂｅ）応答フレームで前記第２ＳＴＡから受信される、請求項１に記載の方法。
【請求項7】
前記第１ＴＸＯＰが前記ｒ－ＴＷＴ ＳＰの開始時間後に終了しないことに基づいて、前記ｒ－ＴＷＴ ＳＰの終了時間が延期される、請求項２に記載の方法。
【請求項8】
前記第１ＳＴＡは非（ｎｏｎ）－ＡＰ（ａｃｃｅｓｓ ｐｏｉｎｔ）ＥＨＴ（ｅｘｔｒｅｍｅｌｙ ｈｉｇｈ ｔｈｒｏｕｇｈｐｕｔ）ＳＴＡであり、前記第２ＳＴＡはＡＰである、請求項１に記載の方法。
【請求項9】
無線ＬＡＮシステムにおいて通信を行う第１ステーション（ＳＴＡ）であって、前記ＳＴＡは、少なくとも一つの送受信機と、
前記少なくとも一つの送受信機と連結された少なくとも一つのプロセッサと、を含み、
前記少なくとも一つのプロセッサは、
制限されたターゲットウエイクタイム（ｒｅｓｔｒｉｃｔｅｄ ｔａｒｇｅｔ ｗａｋｅ ｔｉｍｅ，ｒ－ＴＷＴ）メンバーシップセットアップ手順を第２ＳＴＡと行い、
ブロードキャスト（ｂｒｏａｄｃａｓｔ）ＴＷＴ要素（ｅｌｅｍｅｎｔ）に含まれたｒ－ＴＷＴスケジュール情報を前記第２ＳＴＡから前記少なくとも一つの送受信機を介して受信する、ように設定され、
前記ｒ－ＴＷＴスケジュール情報によって公知されたｒ－ＴＷＴ ＳＰ（ｓｅｒｖｉｃｅ ｐｅｒｉｏｄ）内の第１ＴＸＯＰ（ｔｒａｎｓｍｉｓｓｉｏｎ ｏｐｐｏｒｔｕｎｉｔｙ）の特定部分が、少なくとも１つのｒ－ＴＷＴ下りリンク（ｄｏｗｎｌｉｎｋ，ＤＬ）トラフィック識別（ｔｒａｆｆｉｃ ｉｄｅｎｔｉｆｉｅｒ，ＴＩＤ）に対応するＤＬフレームの伝達又は少なくとも１つのｒ－ＴＷＴ上りリンク（ｕｐｌｉｎｋ，ＵＬ）ＴＩＤに対応するＵＬフレームの要請に用いられないことに基づいて、前記第１ＴＸＯＰは前記ｒ－ＴＷＴ ＳＰの開始時間前に終了する、第１ＳＴＡ。
【請求項10】
無線ＬＡＮシステムにおいて通信を行う第２ステーション（ＳＴＡ）であって、前記第２ＳＴＡは、少なくとも一つの送受信機と、
前記少なくとも一つの送受信機と連結された少なくとも一つのプロセッサと、を含み、
前記少なくとも一つのプロセッサは、
制限されたターゲットウエイクタイム（ｒｅｓｔｒｉｃｔｅｄ ｔａｒｇｅｔ ｗａｋｅ ｔｉｍｅ，ｒ－ＴＷＴ）メンバーシップセットアップ手順を第１ＳＴＡと行い、
ブロードキャスト（ｂｒｏａｄｃａｓｔ）ＴＷＴ要素（ｅｌｅｍｅｎｔ）に含まれたｒ－ＴＷＴスケジュール情報を第１ＳＴＡに前記少なくとも一つの送受信機を介して送信する、ように設定され、
前記ｒ－ＴＷＴスケジュール情報によって公知されたｒ－ＴＷＴ ＳＰ（ｓｅｒｖｉｃｅ ｐｅｒｉｏｄ）内の第１ＴＸＯＰ（ｔｒａｎｓｍｉｓｓｉｏｎ ｏｐｐｏｒｔｕｎｉｔｙ）の特定部分が、少なくとも１つのｒ－ＴＷＴ下りリンク（ｄｏｗｎｌｉｎｋ，ＤＬ）トラフィック識別（ｔｒａｆｆｉｃ ｉｄｅｎｔｉｆｉｅｒ，ＴＩＤ）に対応するＤＬフレームの伝達又は少なくとも１つのｒ－ＴＷＴ上りリンク（ｕｐｌｉｎｋ，ＵＬ）ＴＩＤに対応するＵＬフレームの要請に用いられないことに基づいて、前記第１ＴＸＯＰは前記ｒ－ＴＷＴ ＳＰの開始時間前に終了する、第２ＳＴＡ。
【国際調査報告】