JP2022522720A - Ｗｕｒ走査のための方法及びｗｔｒｕ - Google Patents

Abstract

無線送信／受信ユニット（ＷＴＲＵ）で使用するための方法が開示される。この方法は、ステーション管理エンティティ（ＳＭＥ）が、１つ又は複数のアクセスポイント（ＡＰ）によって伝送されるウェイクアップ無線（ＷＵＲ）ディスカバリフレームのためのＷＵＲ走査プロセスを可能にする要求プリミティブを生成することであって、要求プリミティブは、複数の第１のパラメータを含む、生成すること、複数の第１のパラメータに基づいて、ＷＵＲを使用してＷＵＲ走査プロセスを実行すること、ＭＡＣ層において、ＷＵＲ走査プロセスの結果及び複数の第１のパラメータの少なくとも一部に基づいて少なくとも１つの確認プリミティブを生成すること、及びＭＡＣ層からＳＭＥに少なくとも１つの確認プリミティブを通信することを含む。

Description

関連出願の相互参照
[0001] 本願は、参照によりその内容が本明細書に援用される、２０１９年２月２８日に出願された米国仮特許出願第６２／８１１，９６７号の利益を主張する。

背景
[0002] ローカルエリアネットワーク（ＬＡＮ）のための固定又は低移動度の無線通信は、一般に、WiFiとも呼ばれる米国電気電子学会（ＩＥＥＥ）802.11a、802.11b、802.11g、802.11n、802.11ac、802.11ax、802.11be又は概して802.11x等の技術を利用する。これらの技術は、少なくとも２つの地点間の無線ＬＡＮ（ＷＬＡＮ）を作り出すためのメディアアクセス制御（ＭＡＣ）及び物理層（ＰＨＹ）の仕様に関係する。ＷＬＡＮの普及に伴い、所望の性能及びスペクトル効率を実現するために、幾つかの種類のＷＬＡＮインタフェースについて同じ伝送において信号を伝送することが望ましい場合がある。

概要
[0003] 無線送信／受信ユニット（ＷＴＲＵ）で使用する方法が開示される。この方法は、ステーション管理エンティティ（ＳＭＥ）が、１つ又は複数のアクセスポイント（ＡＰ）によって伝送されるウェイクアップ無線（ＷＵＲ）ディスカバリフレームのためのＷＵＲ走査プロセスを可能にする要求プリミティブを生成することであって、要求プリミティブは、複数の第１のパラメータを含む、生成すること、複数の第１のパラメータに基づいてＷＵＲ走査プロセスを実行すること、ＭＡＣ層において、ＷＵＲ走査プロセスの結果及び複数の第１のパラメータの少なくとも一部に基づいて少なくとも１つの確認プリミティブを生成すること、及びＭＡＣ層からＳＭＥに少なくとも１つの確認プリミティブを通信することを含む。

[0004] 無線送信／受信ユニット（ＷＴＲＵ）が開示される。ＷＴＲＵは、１つ又は複数のアクセスポイント（ＡＰ）によって伝送されるＷＵＲディスカバリフレームのためのＷＲＵ走査プロセスを可能にする要求プリミティブを生成することであって、要求プリミティブは、複数の第１のパラメータを含む、生成すること、複数の第１のパラメータに基づいてＷＵＲ走査プロセスを実行すること、ＭＡＣ層において、ＷＵＲ走査プロセスの結果及び複数の第１のパラメータの少なくとも一部に基づいて少なくとも１つの確認プリミティブを生成すること、及びＭＡＣ層からステーション管理エンティティ（ＳＭＥ）に少なくとも１つの確認プリミティブを通信することを行うように構成されるプロセッサを含む。

図面の簡単な説明
[0005] 添付図面に関連して例として示す以下の説明からより詳細な理解を得ることができ、図中の同様の参照番号は、同様の要素を示す。

[0006]１つ又は複数の開示する実施形態を実装することができる通信システムの一例を示すシステム図である。 [0007]一実施形態による、図１Ａに示す通信システムで使用することができる無線送信／受信ユニット（ＷＴＲＵ）の一例を示すシステム図である。 [0008]一実施形態による、図１Ａに示す通信システムで使用することができる無線アクセスネットワーク（ＲＡＮ）の一例及びコアネットワーク（ＣＮ）の一例を示すシステム図である。 [0009]一実施形態による、図１Ａに示す通信システムで使用することができるＲＡＮの更なる例及びＣＮの更なる例を示すシステム図である。 [0010]本願の一実施形態による方法を示すフローチャートである。 [0011]本願の別の実施形態による方法を示すフローチャートである。 [0012]ダウンリンク（ＤＬ）ブロードキャスト要素の設計例を示す。 [0013]アップリンク（ＵＬ）ブロードキャスト要素の設計例を示す。 [0014]連続的に増加する増分を伴うＬＤＰＣフレーム間符号化の一例を示す。 [0015]非連続的に増加する増分を伴うＬＤＰＣフレーム間符号化の一例を示す。 [0016]ＢＣＣフレーム間符号化の一例を示す。 [0017]固定インデックスを伴うフレーム間符号化／部分的ＨＡＲＱの一例を示す。 [0018]スライディングウィンドウを伴うフレーム間符号化／部分的ＨＡＲＱの一例を示す。 [0019]フィードバック及び動的増分サブフレーム選択を伴うフレーム間符号化／部分的ＨＡＲＱの一例を示す。 [0020]ＢＣＳの反復間のｘＩＦＳフレーム間間隔を伴う省力化手順の一例を示す。 [0021]反復間の特定のタイミング差を伴う省力化手順の一例を示す。 [0022]フィードバックを伴う反復伝送の一例を示す。 [0023]ＣＳＤを伴うマルチＡＰブロードキャストの一例を示す。 [0024]タイミング分離を伴うマルチＡＰブロードキャストの一例を示す。 [0025]空間伝送ダイバーシティ方式を伴うマルチＡＰブロードキャストの一例を示す。 [0026]ＵＬ ＷＴＲＵ（例えば、ＳＴＡ）が受信機の状態を認識していないネットワークアーキテクチャの一例を示す。 [0027]ダウンリンク（ＤＬ）フィードバックをＡＰが与えるための手順の一例を示す。 [0028]ロストデータの一部を識別するダウンリンク（ＤＬ）フィードバックをＡＰが与えるための手順の一例を示す。

詳細な説明
[0029] 図１Ａは、１つ又は複数の開示する実施形態を実装することができる通信システム１００の一例を示す図である。通信システム１００は、複数の無線ユーザに音声、データ、ビデオ、メッセージング、ブロードキャスト等のコンテンツを提供する多元接続システムであり得る。通信システム１００は、無線帯域幅を含むシステムリソースを共用することによって複数の無線ユーザがかかるコンテンツにアクセスすることを可能にし得る。例えば、通信システム１００は、符号分割多元接続（ＣＤＭＡ）、時分割多元接続（ＴＤＭＡ）、周波数分割多元接続（ＦＤＭＡ）、直交ＦＤＭＡ（ＯＦＤＭＡ）、単一キャリアＦＤＭＡ（ＳＣ－ＦＤＭＡ）、ゼロテールユニークワード離散フーリエ変換拡散ＯＦＤＭ（ＺＴ－ＵＷ－ＤＦＴ－Ｓ－ＯＦＤＭ）、ユニークワードＯＦＤＭ（ＵＷ－ＯＦＤＭ）、リソースブロックフィルタ処理済みＯＦＤＭ、フィルタバンクマルチキャリア（ＦＢＭＣ）等の１つ又は複数のチャネルアクセス方法を使用することができる。

[0030] 図１Ａに示すように、通信システム１００は、無線送信／受信ユニット（ＷＴＲＵ）１０２ａ、１０２ｂ、１０２ｃ、１０２ｄ、無線アクセスネットワーク（ＲＡＮ）１０４、コアネットワーク（ＣＮ）１０６、公衆交換電話網（ＰＳＴＮ）１０８、インターネット１１０及び他のネットワーク１１２を含み得るが、開示する実施形態は、任意の数のＷＴＲＵ、基地局、ネットワーク及び／又はネットワーク要素を予期することが理解されるであろう。ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄのそれぞれは、無線環境内で動作及び／又は通信するように構成される任意の種類の装置であり得る。例として、その何れもステーション（ＳＴＡ）と呼ぶことができるＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄは、無線信号を伝送及び／又は受信するように構成することができ、ユーザ機器（ＵＥ）、移動局、固定又は移動加入者ユニット、加入ごとのユニット、ページャ、携帯電話、携帯情報端末（ＰＤＡ）、スマートフォン、ラップトップ、ネットブック、パーソナルコンピュータ、無線センサ、ホットスポット又はMi-Fi装置、モノのインターネット（ＩｏＴ）装置、時計又は他の着用物、ヘッドマウントディスプレイ（ＨＭＤ）、車両、ドローン、医療装置及び医学的応用（例えば、遠隔手術）、工業装置及び工業的応用（例えば、工業及び／又は自動化プロセスチェーンに関連して動作するロボット及び／又は他の無線装置）、家庭用電子装置、商用及び／又は工業用無線ネットワーク上で動作する装置等を含み得る。ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ及び１０２ｄの何れもＵＥと区別なく呼ぶ場合がある。本願では、別段の定めがない限り、「ＷＴＲＵ」及び「ＳＴＡ」という用語は、区別なく使用され得ることに留意すべきである。

[0031] 通信システム１００は、基地局１１４ａ及び／又は基地局１１４ｂも含み得る。基地局１１４ａ、１１４ｂのそれぞれは、ＣＮ１０６、インターネット１１０及び／又は他のネットワーク１１２等の１つ又は複数の通信ネットワークへのアクセスを促進するためにＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄの少なくとも１つと無線でインタフェースするように構成される任意の種類の装置であり得る。例として、基地局１１４ａ、１１４ｂは、ベーストランシーバ局（ＢＴＳ）、NodeB、eNode B（eNB）、Home Node B、Home eNode B、gNodeB（gNB）等の次世代NodeB、new radio（NR）NodeB、サイトコントローラ、アクセスポイント（ＡＰ）、無線ルータ等であり得る。基地局１１４ａ、１１４ｂを単一の要素としてそれぞれ示すが、基地局１１４ａ、１１４ｂは、相互接続された任意の数の基地局及び／又はネットワーク要素を含み得ることが理解されるであろう。

[0032] 基地局１１４ａは、ＲＡＮ１０４の一部であり得、ＲＡＮ１０４は、基地局コントローラ（ＢＳＣ）、無線ネットワークコントローラ（ＲＮＣ）、中継ノード等の他の基地局及び／又はネットワーク要素（不図示）も含み得る。基地局１１４ａ及び／又は基地局１１４ｂは、セル（不図示）と呼ばれ得る１つ又は複数のキャリア周波数上で無線信号を伝送及び／又は受信するように構成され得る。これらの周波数は、ライセンススペクトル、非ライセンススペクトル又はライセンススペクトルと非ライセンススペクトルとの組み合わせにおけるものであり得る。セルは、相対的に固定され得るか又は時間と共に変化し得る特定の地理的領域に無線サービスのカバレッジを提供することができる。セルは、セルセクタに更に分割され得る。例えば、基地局１１４ａに関連するセルは、３つのセクタに分割することができる。従って、一実施形態では、基地局１１４ａは、３つの、即ちセルのセクタごとに１つのトランシーバを含み得る。一実施形態では、基地局１１４ａが多重入出力（ＭＩＭＯ）技術を使用することができ、セルのセクタごとに複数のトランシーバを利用し得る。例えば、所望の空間方向に信号を伝送及び／又は受信するためにビームフォーミングを使用することができる。

[0033] 基地局１１４ａ、１１４ｂは、任意の適切な無線通信リンク（例えば、無線周波数（ＲＦ）、マイクロ波、センチメートル波、マイクロメートル波、赤外（ＩＲ）、紫外（ＵＶ）、可視光等）であり得るエアインタフェース１１６上でＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄの１つ又は複数と通信し得る。エアインタフェース１１６は、任意の適切な無線アクセス技術（ＲＡＴ）を使用して確立され得る。

[0034] より具体的には、上記で述べたように、通信システム１００は、多元接続システムであり得、ＣＤＭＡ、ＴＤＭＡ、ＦＤＭＡ、ＯＦＤＭＡ、ＳＣ－ＦＤＭＡ等の１つ又は複数のチャネルアクセス方式を使用することができる。例えば、ＲＡＮ１０４内の基地局１１４ａ及びＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃは、広帯域ＣＤＭＡ（ＷＣＤＭＡ）を使用してエアインタフェース１１６を確立し得るUniversal Mobile Telecommunications System（ＵＭＴＳ）Terrestrial Radio Access（ＵＴＲＡ）等の無線技術を実装することができる。ＷＣＤＭＡは、高速パケットアクセス（ＨＳＰＡ）及び／又はEvolved HSPA（ＨＳＰＡ＋）等の通信プロトコルを含み得る。ＨＳＰＡは、高速ダウンリンク（ＤＬ）パケットアクセス（ＨＳＤＰＡ）及び／又は高速アップリンク（ＵＬ）パケットアクセス（ＨＳＵＰＡ）を含み得る。

[0035] 一実施形態では、基地局１１４ａ及びＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃが、Long Term Evolution（LTE）及び／又はLTE-Advanced（LTE-A）及び／又はLTE-Advanced Pro（LTE-A Pro）を使用してエアインタフェース１１６を確立し得るEvolved UMTS Terrestrial Radio Access（E-UTRA）等の無線技術を実装することができる。

[0036] 一実施形態では、基地局１１４ａ及びＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃは、NRを使用してエアインタフェース１１６を確立し得るNR無線アクセス等の無線技術を実装することができる。

[0037] 一実施形態では、基地局１１４ａ及びＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃは、複数の無線アクセス技術を実装することができる。例えば、基地局１１４ａ及びＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃは、例えば、デュアルコネクティビティ（ＤＣ）の原理を使用してLTE無線アクセス及びNR無線アクセスを一緒に実装することができる。従って、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃによって利用されるエアインタフェースは、複数の種類の無線アクセス技術及び／又は複数の種類の基地局（例えば、eNB及びgNB）との間で送信される伝送によって特徴付けることができる。

[0038] 他の実施形態では、基地局１１４ａ及びＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃは、IEEE 802.11（即ちWireless Fidelity（WiFi）、IEEE 802.16（即ちWorldwide Interoperability for Microwave Access（WiMAX））、CDMA2000、CDMA2000 1X、CDMA2000 EV-DO、Interim Standard 2000（IS-2000）、Interim Standard 95（IS-95）Interim Standard 856（IS-856）、Global System for Mobile communications（GSM）、Enhanced Data rates for GSM Evolution（EDGE）、GSM EDGE（GERAN）等の無線技術を実装することができる。

[0039] 図１Ａの基地局１１４ｂは、例えば、無線ルータ、Home Node B、Home eNode B又はアクセスポイントであり得、事業所、自宅、車両、キャンパス、工業施設、（例えば、ドローンによる使用のための）空中回廊、道路等の局所的領域内の無線接続性を促進するために任意の適切なＲＡＴを利用することができる。一実施形態では、基地局１１４ｂ及びＷＴＲＵ１０２ｃ、１０２ｄは、IEEE 802.11等の無線技術を実装して無線ローカルエリアネットワーク（ＷＬＡＮ）を確立することができる。一実施形態では、基地局１１４ｂ及びＷＴＲＵ１０２ｃ、１０２ｄは、IEEE 802.15等の無線技術を実装して無線パーソナルエリアネットワーク（ＷＰＡＮ）を確立することができる。更に別の実施形態では、基地局１１４ｂ及びＷＴＲＵ１０２ｃ、１０２ｄは、セルラベースのＲＡＴ（例えば、WCDMA、CDMA2000、GSM、LTE、LTE-A、LTE-A Pro、NR等）を利用してピコセル又はフェムトセルを確立することができる。図１Ａに示すように、基地局１１４ｂは、インターネット１１０への直接接続を有し得る。従って、基地局１１４ｂは、ＣＮ１０６を介してインターネット１１０にアクセスする必要がない場合がある。

[0040] ＲＡＮ１０４は、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄの１つ又は複数に音声、データ、アプリケーション及び／又はボイスオーバインターネットプロトコル（ＶｏＩＰ）サービスを提供するように構成される任意の種類のネットワークであり得るＣＮ１０６と通信し得る。データは、異なるスループット要件、遅延要件、エラー許容範囲要件、信頼性要件、データスループット要件、モビリティ要件等、種々のサービス品質（ＱｏＳ）要件を有し得る。ＣＮ１０６は、呼制御、課金サービス、モバイルロケーションベースサービス、プリペイド通話、インターネット接続、ビデオ配信等を提供することができ、及び／又はユーザ認証等の高レベルセキュリティ機能を実行することができる。図１Ａには不図示であるが、ＲＡＮ１０４及び／又はＣＮ１０６は、ＲＡＮ１０４と同じＲＡＴ又は異なるＲＡＴを使用する他のＲＡＮと直接的又は間接的に通信し得ることが理解されるであろう。例えば、NR無線技術を利用し得るＲＡＮ１０４に接続されることに加え、ＣＮ１０６は、GSM、UMTS、CDMA2000、WiMAX、E-UTRA又はWiFi無線技術を使用する別のＲＡＮ（不図示）と通信することもできる。

[0041] ＣＮ１０６は、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄがＰＳＴＮ１０８、インターネット１１０及び／又は他のネットワーク１１２にアクセスするためのゲートウェイとしての役割を果たすこともできる。ＰＳＴＮ１０８は、単純旧式電話サービス（ＰＯＴＳ）を提供する回線交換電話網を含み得る。インターネット１１０は、ＴＣＰ／ＩＰインターネットプロトコルスイート内の伝送制御プロトコル（ＴＣＰ）、ユーザデータグラムプロトコル（ＵＤＰ）及び／又はインターネットプロトコル（ＩＰ）等の共通の通信プロトコルを使用する、相互接続されたコンピュータネットワーク及び装置の世界的なシステムを含み得る。ネットワーク１１２は、他のサービスプロバイダによって所有及び／又は運営される有線及び／又は無線通信ネットワークを含み得る。例えば、ネットワーク１１２は、ＲＡＮ１０４と同じＲＡＴ又は異なるＲＡＴを使用し得る１つ又は複数のＲＡＮに接続される別のＣＮを含み得る。

[0042] 通信システム１００内のＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄの一部又は全てがマルチモード機能を含み得る（例えば、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄは様々な無線リンク上で様々な無線ネットワークと通信するための複数のトランシーバを含み得る）。例えば、図１Ａに示すＷＴＲＵ１０２ｃは、セルラベースの無線技術を使用し得る基地局１１４ａ及びIEEE 802無線技術を使用し得る基地局１１４ｂと通信するように構成され得る。

[0043] 図１Ｂは、ＷＴＲＵ１０２の一例を示すシステム図である。図１Ｂに示すように、ＷＴＲＵ１０２は、とりわけ、プロセッサ１１８、トランシーバ１２０、送信／受信要素１２２、スピーカ／マイクロフォン１２４、キーパッド１２６、ディスプレイ／タッチパッド１２８、脱着不能メモリ１３０、脱着可能メモリ１３２、電源１３４、全地球測位システム（ＧＰＳ）チップセット１３６及び／又は他の周辺装置１３８を含み得る。ＷＴＲＵ１０２は、実施形態と合致したままで上記の要素の任意のサブコンビネーションを含み得ることが理解されるであろう。

[0044] プロセッサ１１８は、汎用プロセッサ、専用プロセッサ、従来のプロセッサ、デジタル信号プロセッサ（ＤＳＰ）、複数のマイクロプロセッサ、ＤＳＰコアに関連する１つ又は複数のマイクロプロセッサ、コントローラ、マイクロコントローラ、特定用途向け集積回路（ＡＳＩＣ）、書換可能ゲートアレイ（ＦＰＧＡ）、他の任意の種類の集積回路（ＩＣ）、状態機械等であり得る。プロセッサ１１８は、信号符号化、データ処理、出力制御、入力／出力処理及び／又はＷＴＲＵ１０２が無線環境内で動作することを可能にする他の任意の機能を実行することができる。プロセッサ１１８は、送信／受信要素１２２に結合され得るトランシーバ１２０に結合され得る。図１Ｂは、プロセッサ１１８及びトランシーバ１２０を別個のコンポーネントとして示すが、プロセッサ１１８及びトランシーバ１２０は、電子パッケージ又はチップ内に統合され得ることが理解されるであろう。

[0045] 送信／受信要素１２２は、エアインタフェース１１６上で基地局（例えば、基地局１１４ａ）との間で信号を伝送又は受信するように構成され得る。例えば、一実施形態では、送信／受信要素１２２は、ＲＦ信号を伝送及び／又は受信するように構成されるアンテナであり得る。一実施形態では、送信／受信要素１２２は、例えば、ＩＲ、ＵＶ又は可視光信号を伝送及び／又は受信するように構成されるエミッタ／検出器であり得る。更に別の実施形態では、送信／受信要素１２２は、ＲＦ信号及び光信号の両方を伝送及び／又は受信するように構成され得る。送信／受信要素１２２は、無線信号の任意の組み合わせを伝送及び／又は受信するように構成され得ることが理解されるであろう。

[0046] 図１Ｂでは、送信／受信要素１２２を単一の要素として示すが、ＷＴＲＵ１０２は、任意の数の送信／受信要素１２２を含むことができる。より具体的には、ＷＴＲＵ１０２は、ＭＩＭＯ技術を使用することができる。従って、一実施形態では、ＷＴＲＵ１０２は、エアインタフェース１１６上で無線信号を伝送し、受信するための２つ以上の送信／受信要素１２２（例えば、複数のアンテナ）を含み得る。

[0047] トランシーバ１２０は、送信／受信要素１２２によって伝送される信号を変調するように、及び送信／受信要素１２２によって受信される信号を復調するように構成され得る。上記で述べたように、ＷＴＲＵ１０２は、マルチモード機能を有することができる。従って、トランシーバ１２０は、ＷＴＲＵ１０２が例えばNR及びIEEE 802.11等の複数のＲＡＴによって通信することを可能にするための複数のトランシーバを含み得る。

[0048] ＷＴＲＵ１０２のプロセッサ１１８は、スピーカ／マイクロフォン１２４、キーパッド１２６及び／又はディスプレイ／タッチパッド１２８（例えば、液晶ディスプレイ（ＬＣＤ）ディスプレイユニット又は有機発光ダイオード（ＯＬＥＤ）ディスプレイユニット）に結合され得、それからユーザ入力データを受信し得る。プロセッサ１１８は、スピーカ／マイクロフォン１２４、キーパッド１２６及び／又はディスプレイ／タッチパッド１２８にユーザデータを出力することもできる。加えて、プロセッサ１１８は、脱着不能メモリ１３０及び／又は脱着可能メモリ１３２等の任意の種類の適切なメモリの情報にアクセスし、かかるメモリ内にデータを記憶することができる。脱着不能メモリ１３０は、ランダムアクセスメモリ（ＲＡＭ）、読取専用メモリ（ＲＯＭ）、ハードディスク又は他の任意の種類のメモリ記憶装置を含み得る。脱着可能メモリ１３２は、加入者識別モジュール（ＳＩＭ）カード、メモリスティック、セキュアデジタル（ＳＤ）メモリカード等を含み得る。他の実施形態では、プロセッサ１１８は、サーバ上又はホームコンピュータ上（不図示）等、ＷＴＲＵ１０２上に物理的に位置しないメモリの情報にアクセスし、かかるメモリ内にデータを記憶することができる。

[0049] プロセッサ１１８は、電源１３４から電力を得ることができ、ＷＴＲＵ１０２内の他のコンポーネントへの電力を分配及び／又は制御するように構成され得る。電源１３４は、ＷＴＲＵ１０２に給電するための任意の適切な装置であり得る。例えば、電源１３４は、１つ又は複数の乾電池（例えば、ニッケルカドミウム（ＮｉＣｄ）、ニッケル亜鉛（ＮｉＺｎ）、ニッケル水素（ＮｉＭＨ）、リチウムイオン（Ｌｉイオン）等）、太陽電池、燃料電池等を含み得る。

[0050] プロセッサ１１８は、ＷＴＲＵ１０２の現在位置に関する位置情報（例えば、経度及び緯度）を提供するように構成され得るＧＰＳチップセット１３６にも結合され得る。ＧＰＳチップセット１３６からの情報に加えて又はその代わりに、ＷＴＲＵ１０２は、基地局（例えば、基地局１１４ａ、１１４ｂ）からエアインタフェース１１６上で位置情報を受信することができ、及び／又は２つ以上の近くの基地局から受信される信号のタイミングに基づいて自らの位置を突き止めることができる。ＷＴＲＵ１０２は、実施形態と合致したままで任意の適切な位置決定方法によって位置情報を取得できることが理解されるであろう。

[0051] プロセッサ１１８は、追加の特徴、機能及び／又は有線若しくは無線接続を提供する１つ又は複数のソフトウェア及び／又はハードウェアモジュールを含み得る他の周辺装置１３８に更に結合され得る。例えば、周辺装置１３８は、加速度計、ｅコンパス、衛星トランシーバ、（写真及び／又はビデオのための）デジタルカメラ、ユニバーサルシリアルバス（ＵＳＢ）ポート、振動装置、テレビ受信機、ハンズフリーヘッドセット、Bluetooth（登録商標）モジュール、周波数変調（ＦＭ）無線ユニット、デジタル音楽プレーヤ、メディアプレーヤ、ビデオゲームプレーヤモジュール、インターネットブラウザ、仮想現実及び／又は拡張現実（ＶＲ／ＡＲ）装置、活動トラッカ等を含み得る。周辺装置１３８は、１つ又は複数のセンサを含むことができる。センサは、ジャイロスコープ、加速度計、ホール効果センサ、磁気計、方位センサ、近接センサ、温度センサ、時間センサ、地理位置センサ、高度計、光センサ、タッチセンサ、磁気計、気圧計、ジェスチャセンサ、バイオメトリクセンサ及び湿度センサ等の１つ又は複数であり得る。

[0052] ＷＴＲＵ１０２は、（例えば、（例えば、伝送のための）ＵＬ及び（例えば、受信のための）ＤＬの両方の特定のサブフレームに関連する信号の一部又は全ての伝送及び受信が並行及び／又は同時であり得る全二重無線を含み得る。全二重無線は、ハードウェアによる自己干渉（例えば、チョーク）又はプロセッサによる（例えば、別個のプロセッサ（不図示）又はプロセッサ１１８による）信号処理による自己干渉を減らし及び又はほぼなくすための干渉管理ユニットを含み得る。一実施形態では、ＷＴＲＵ１０２は、信号の一部又は全ての伝送及び受信（例えば、（例えば、伝送のための）ＵＬ又は（例えば、受信のための）ＤＬのいずれかのための特定のサブフレームに関連する）のための半二重無線を含むことができる。

[0053] 図１Ｃは、一実施形態によるＲＡＮ１０４及びＣＮ１０６を示すシステム図である。上記で述べたように、ＲＡＮ１０４は、エアインタフェース１１６上でＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃと通信するためにE-UTRA無線技術を使用することができる。ＲＡＮ１０４は、ＣＮ１０６と通信することもできる。

[0054] ＲＡＮ１０４は、eNode-B１６０ａ、１６０ｂ、１６０ｃを含み得るが、ＲＡＮ１０４は、実施形態と合致したままで任意の数のeNode-Bを含み得ることが理解されるであろう。eNode-B１６０ａ、１６０ｂ、１６０ｃは、エアインタフェース１１６上でＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃと通信するための１つ又は複数のトランシーバをそれぞれ含み得る。一実施形態では、eNode-B１６０ａ、１６０ｂ、１６０ｃがＭＩＭＯ技術を実装することができる。従って、例えば、eNode-B１６０ａは、複数のアンテナを使用してＷＴＲＵ１０２ａとの間で無線信号を伝送及び／又は受信することができる。

[0055] eNode-B１６０ａ、１６０ｂ、１６０ｃのそれぞれは、特定のセル（不図示）に関連することができ、無線リソース管理の判断、ハンドオーバの判断、ＵＬ及び／又はＤＬ内のユーザのスケジューリング等を処理するように構成され得る。図１Ｃに示すように、eNode-B１６０ａ、１６０ｂ、１６０ｃは、Ｘ２インタフェース上で互いに通信することができる。

[0056] 図１Ｃに示すＣＮ１０６は、モビリティ管理エンティティ（ＭＭＥ）１６２、サービングゲートウェイ（ＳＧＷ）１６４及びパケットデータネットワーク（ＰＤＮ）ゲートウェイ（ＰＧＷ）１６６を含み得る。上記の要素をＣＮ１０６の一部として示すが、これらの要素の何れもＣＮオペレータ以外のエンティティによって所有及び／又は運営され得ることが理解されるであろう。

[0057] ＭＭＥ１６２は、Ｓ１インタフェースによってＲＡＮ１０４内のeNode-B１６２ａ、１６２ｂ、１６２ｃのそれぞれに接続することができ、制御ノードとしての役割を果たし得る。例えば、ＭＭＥ１６２は、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃのユーザの認証、ベアラのアクティブ化／非アクティブ化、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃの初期接続中に特定のサービングゲートウェイを選択すること等を担うことができる。ＭＭＥ１６２は、ＲＡＮ１０４とＧＳＭ及び／又はＷＣＤＭＡ等の他の無線技術を使用する他のＲＡＮ（不図示）とを切り替えるための制御プレーン機能を提供し得る。

[0058] ＳＧＷ１６４は、Ｓ１インタフェースによってＲＡＮ１０４内のeNode B１６０ａ、１６０ｂ、１６０ｃのそれぞれに接続され得る。ＳＧＷ１６４は、概して、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃとの間のユーザデータパケットをルートし転送することができる。ＳＧＷ１６４は、eNode B間のハンドオーバ中のユーザプレーンのアンカリング、ＤＬデータがＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃにとって入手可能な場合のページングのトリガ、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃのコンテキストの管理及び記憶等の他の機能を実行し得る。

[0059] ＳＧＷ１６４は、ＰＧＷ１６６に接続することができ、ＰＧＷ１６６は、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃにインターネット１１０等のパケット交換ネットワークへのアクセスを与えて、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃとＩＰ対応装置との間の通信を促進することができる。

[0060] ＣＮ１０６は、他のネットワークとの通信を促進することができる。例えば、ＣＮ１０６は、ＰＳＴＮ１０８等の回線交換網へのアクセスをＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃに与えて、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃと従来の陸線通信装置との間の通信を促進することができる。例えば、ＣＮ１０６は、ＣＮ１０６とＰＳＴＮ１０８との間のインタフェースとしての役割を果たすＩＰゲートウェイ（例えば、ＩＰマルチメディアサブシステム（ＩＭＳ）サーバ）を含むことができるか、又はかかるＩＰゲートウェイと通信し得る。加えて、ＣＮ１０６は、他のサービスプロバイダによって所有及び／又は運営される他の有線及び／又は無線ネットワークを含み得る他のネットワーク１１２へのアクセスをＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃに与えることができる。

[0061] 図１Ａ～図１Ｄでは、ＷＴＲＵを無線端末として示すが、特定の代表的な実施形態では、かかる端末が通信ネットワークとの有線通信インタフェースを（例えば、一時的に又は永続的に）使用できることが企図される。

[0062] 代表的な実施形態では、他のネットワーク１１２がＷＬＡＮであり得る。

[0063] インフラストラクチャ基本サービスセット（ＢＳＳ）モード内のＷＬＡＮは、ＢＳＳのためのアクセスポイント（ＡＰ）及びＡＰに関連付けられた１つ又は複数のステーション（ＳＴＡ）を有し得る。ＡＰは、ＢＳＳ内外にトラフィックを運ぶ分配システム（ＤＳ）又は別の種類の有線／無線ネットワークへのアクセス又はインタフェースを有し得る。ＢＳＳの外部から生じるＳＴＡへのトラフィックは、ＡＰを介して到着することができ、ＳＴＡに届けられ得る。ＢＳＳの外部の宛先へのＳＴＡから生じるトラフィックは、それぞれの宛先に届けられるようにＡＰに送信され得る。ＢＳＳ内のＳＴＡ間のトラフィックは、ＡＰを介して送信することができ、例えば、ソースＳＴＡは、ＡＰにトラフィックを送信することができ、ＡＰは、そのトラフィックを宛先ＳＴＡに届けることができる。ＢＳＳ内のＳＴＡ間のトラフィックは、ピアツーピアトラフィックと見なし及び／又は呼ぶことができる。ピアツーピアトラフィックは、ダイレクトリンクセットアップ（ＤＬＳ）を用いてソースＳＴＡと宛先ＳＴＡとの間で（例えば、直接）送信され得る。特定の代表的な実施形態では、ＤＬＳが802.11e ＤＬＳ又は802.11zトンネル化ＤＬＳ（ＴＤＬＳ）を使用することができる。独立ＢＳＳ（ＩＢＳＳ）モードを使用するＷＬＡＮは、ＡＰを有さない場合があり、ＩＢＳＳ内の又はＩＢＳＳを使用するＳＴＡ（例えば、ＳＴＡの全て）が互いに直接通信することができる。ＩＢＳＳモードの通信は、本明細書では「アドホック」モードの通信と呼ぶ場合もあり得る。

[0064] 802.11acインフラストラクチャモードの動作又は同様のモードの動作を使用する場合、ＡＰは、一次チャネル等の固定チャネル上でビーコンを伝送することができる。一次チャネルは、固定幅（例えば、２０ＭＨｚ幅の帯域）又は動的に設定された幅であり得る。一次チャネルは、ＢＳＳの動作チャネルであり得、ＡＰとの接続を確立するためにＳＴＡによって使用され得る。特定の代表的な実施形態では、例えば、802.11システム内でCarrier Sense Multiple Access with Collision Avoidance（ＣＳＭＡ／ＣＡ）が実装され得る。ＣＳＭＡ／ＣＡでは、ＡＰを含むＳＴＡ（例えば、全てのＳＴＡ）が一次チャネルを検知することができる。一次チャネルが使用中であると特定のＳＴＡによって検知／検出及び／又は判定される場合、特定のＳＴＡは、バックオフすることができる。所与のＢＳＳ内で１つのＳＴＡ（例えば、１つのステーションのみ）が任意の所与の時点において伝送することができる。

[0065] 例えば、４０ＭＨｚ幅のチャネルを形成するための一次２０ＭＨｚチャネルと隣接する又は隣接しない２０ＭＨｚチャネルとの組み合わせにより、高スループット（ＨＴ）ＳＴＡは、４０ＭＨｚ幅のチャネルを通信に使用することができる。

[0066] 超高スループット（ＶＨＴ）ＳＴＡは、２０ＭＨｚ、４０ＭＨｚ、８０ＭＨｚ及び／又は１６０ＭＨｚ幅のチャネルをサポートし得る。４０ＭＨｚ及び／又は８０ＭＨｚのチャネルは、連続した２０ＭＨｚチャネルを組み合わせることによって形成することができる。１６０ＭＨｚのチャネルは、連続した８つの２０ＭＨｚチャネルを組み合わせることにより、又は８０＋８０構成と呼ばれ得る２つの不連続８０ＭＨｚチャネルを組み合わせることにより形成することができる。８０＋８０構成では、データを２つのストリームに分割し得るセグメントパーサにチャネル符号化後のデータを通すことができる。逆高速フーリエ変換（ＩＦＦＴ）処理及び時間領域処理を各ストリームに対して別々に行うことができる。ストリームは、２つの８０ＭＨｚチャネル上にマップすることができ、伝送側ＳＴＡによってデータが伝送され得る。受信側ＳＴＡの受信機において、上記の８０＋８０構成の動作を逆にすることができ、複合データが媒体アクセス制御（ＭＡＣ）に送信され得る。

[0067] サブ１ＧＨｚモードの動作が802.11af及び802.11ahによってサポートされている。802.11n及び802.11acで使用されているものと比べて、802.11af及び802.11ahではチャネル動作帯域幅及びキャリアが低減される。802.11afは、ＴＶホワイトスペース（ＴＶＷＳ）スペクトル内の５ＭＨｚ、１０ＭＨｚ及び２０ＭＨｚ帯域幅をサポートし、802.11ahは、非ＴＶＷＳスペクトルを使用する１ＭＨｚ、２ＭＨｚ、４ＭＨｚ、８ＭＨｚ及び１６ＭＨｚ帯域幅をサポートする。代表的な実施形態によれば、802.11ahは、マクロカバレッジエリア内のＭＴＣ装置等のメータタイプ制御／マシンタイプ通信（ＭＴＣ）をサポートすることができる。ＭＴＣ装置は、特定の機能、例えば特定の及び／又は限られた帯域幅へのサポート（例えば、それらのみのサポート）を含む限られた機能を有し得る。ＭＴＣ装置は、（例えば、非常に長い電池寿命を保つための）閾値を上回る電池寿命を有する電池を含み得る。

[0068] 802.11n、802.11ac、802.11af及び802.11ah等の複数のチャネル及びチャネル帯域幅をサポートし得るＷＬＡＮシステムは、一次チャネルとして指定され得るチャネルを含むことができる。一次チャネルは、ＢＳＳ内の全てのＳＴＡによってサポートされる最大共通動作帯域幅に等しい帯域幅を有し得る。一次チャネルの帯域幅は、最小帯域幅動作モードをサポートすることができる、ＢＳＳ内で動作する全てのＳＴＡのうちのＳＴＡによって設定及び／又は限定され得る。802.11ahの例において、たとえＡＰ及びＢＳＳ内の他のＳＴＡが２ＭＨｚ、４ＭＨｚ、８ＭＨｚ、１６ＭＨｚ及び／又は他のチャネル帯域幅の動作モードをサポートしても、１ＭＨｚモードをサポートする（例えば、それのみをサポートする）ＳＴＡ（例えば、ＭＴＣ型装置）では、一次チャネルは、１ＭＨｚ幅であり得る。キャリア検知及び／又はネットワーク割り当てベクトル（ＮＡＶ）の設定は、一次チャネルの状態に依存し得る。例えば、（１ＭＨｚの動作モードのみをサポートする）ＳＴＡがＡＰに伝送することによって一次チャネルが使用中である場合、利用可能な周波数帯域の大部分が使用されていないままであるとしても、全ての利用可能な周波数帯域が使用中と見なされ得る。

[0069] 米国では、802.11ahによって使用され得る利用可能な周波数帯域は、９０２ＭＨｚ～９２８ＭＨｚである。韓国では、利用可能な周波数帯域は、９１７．５ＭＨｚ～９２３．５ＭＨｚである。日本では、利用可能な周波数帯域は、９１６．５ＭＨｚ～９２７．５ＭＨｚである。国コードにもよるが、802.11ahに利用可能な総帯域幅は、６ＭＨｚ～２６ＭＨｚである。

[0070] 図１Ｄは、一実施形態によるＲＡＮ１０４及びＣＮ１０６を示すシステム図である。上記で述べたように、ＲＡＮ１０４は、NR無線技術を使用してエアインタフェース１１６上でＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃと通信することができる。ＲＡＮ１０４は、ＣＮ１０６と通信することもできる。

[0071] ＲＡＮ１０４は、gNB１８０ａ、１８０ｂ、１８０ｃを含み得るが、ＲＡＮ１０４は、実施形態と合致したままで任意の数のgNBを含み得ることが理解されるであろう。gNB１８０ａ、１８０ｂ、１８０ｃは、エアインタフェース１１６上でＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃと通信するための１つ又は複数のトランシーバをそれぞれ含み得る。一実施形態では、gNB１８０ａ、１８０ｂ、１８０ｃは、ＭＩＭＯ技術を実装することができる。例えば、gNB１８０ａ、１８０ｂは、ビームフォーミングを利用して、gNB１８０ａ、１８０ｂ、１８０ｃとの間で信号を伝送及び／又は受信することができる。従って、例えば、gNB１８０ａは、複数のアンテナを使用してＷＴＲＵ１０２ａとの間で無線信号を伝送及び／又は受信することができる。一実施形態では、gNB１８０ａ、１８０ｂ、１８０ｃは、キャリアアグリゲーション技術を実装することができる。例えば、gNB１８０ａは、ＷＴＲＵ１０２ａに複数のコンポーネントキャリア（不図示）を伝送することができる。これらのコンポーネントキャリアのサブセットは非ライセンススペクトル上にあり得る一方、残りのコンポーネントキャリアは、ライセンススペクトル上にあり得る。一実施形態では、gNB１８０ａ、１８０ｂ、１８０ｃは、多地点協調（ＣｏＭＰ）技術を実装することができる。例えば、ＷＴＲＵ１０２ａは、gNB１８０ａ及びgNB１８０ｂ（及び／又はgNB１８０ｃ）から協調伝送を受信することができる。

[0072] ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃは、スケーラブルな数秘学に関連する伝送を使用してgNB１８０ａ、１８０ｂ、１８０ｃと通信することができる。例えば、ＯＦＤＭシンボル間隔及び／又はＯＦＤＭサブキャリア間隔は、様々な伝送、様々なセル及び／又は無線伝送スペクトルの様々な部分ごとに異なり得る。ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃは、（例えば、異なる数のＯＦＤＭシンボルを含み、及び／又は可変長の絶対時間にわたって継続する）様々な長さの又はスケーラブルな長さのサブフレーム又は伝送時間間隔（ＴＴＩ）を使用してgNB１８０ａ、１８０ｂ、１８０ｃと通信することができる。

[0073] gNB１８０ａ、１８０ｂ、１８０ｃは、独立型の構成及び／又は非独立型の構成でＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃと通信するように構成され得る。独立型の構成では、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃは、他のＲＡＮ（例えば、eNode-B１６０ａ、１６０ｂ、１６０ｃ等）にもアクセスすることなしにgNB１８０ａ、１８０ｂ、１８０ｃと通信することができる。独立型の構成では、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃは、モビリティアンカポイントとしてgNB１８０ａ、１８０ｂ、１８０ｃの１つ又は複数を利用することができる。独立型の構成では、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃは、非ライセンス帯域内の信号を使用してgNB１８０ａ、１８０ｂ、１８０ｃと通信することができる。非独立型の構成では、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃは、eNode-B１６０ａ、１６０ｂ、１６０ｃ等の別のＲＡＮとも通信しながら／それらにも接続しながら、gNB１８０ａ、１８０ｂ、１８０ｃと通信する／それらに接続することができる。例えば、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃは、ＤＣの原理を実装して、１つ又は複数のgNB１８０ａ、１８０ｂ、１８０ｃ及び１つ又は複数のeNode-B１６０ａ、１６０ｂ、１６０ｃとほぼ同時に通信することができる。非独立型の構成では、eNode-B１６０ａ、１６０ｂ、１６０ｃは、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃのためのモビリティアンカの役割を果たすことができ、gNB１８０ａ、１８０ｂ、１８０ｃは、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃにサービス提供するための追加のカバレッジ及び／又はスループットを提供することができる。

[0074] gNB１８０ａ、１８０ｂ、１８０ｃのそれぞれは、特定のセル（不図示）に関連することができ、無線リソース管理の判断、ハンドオーバの判断、ＵＬ及び／又はＤＬ内のユーザのスケジューリング、ネットワークスライシングのサポート、ＤＣ、NRとE-UTRAとの間の網間接続、ユーザプレーン（ＵＰＦ）１８４ａ、１８４ｂに対するユーザプレーンデータのルーティング、アクセス及びモビリティ管理機能（ＡＭＦ）１８２ａ、１８２ｂに対する制御プレーン情報のルーティング等を処理するように構成され得る。図１Ｄに示すように、gNB１８０ａ、１８０ｂ、１８０ｃは、Ｘｎインタフェース上で互いに通信することができる。

[0075] 図１Ｄに示すＣＮ１０６は、少なくとも１つのＡＭＦ１８２ａ、１８２ｂ、少なくとも１つのＵＰＦ１８４ａ、１８４ｂ、少なくとも１つのセッション管理機能（ＳＭＦ）１８３ａ、１８３ｂ及び場合によりデータネットワーク（ＤＮ）１８５ａ、１８５ｂを含み得る。上記の要素をＣＮ１０６の一部として示すが、これらの要素の何れもＣＮオペレータ以外のエンティティによって所有及び／又は運営され得ることが理解されるであろう。

[0076] ＡＭＦ１８２ａ、１８２ｂは、Ｎ２インタフェースによってＲＡＮ１０４内のgNB１８０ａ、１８０ｂ、１８０ｃの１つ又は複数に接続することができ、制御ノードとしての役割を果たし得る。例えば、ＡＭＦ１８２ａ、１８２ｂは、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃのユーザの認証、ネットワークスライシングのサポート（例えば、様々な要件を有する様々なプロトコルデータユニット（ＰＤＵ）セッションの処理）、特定のＳＭＦ１８３ａ、１８３ｂの選択、登録エリアの管理、非アクセス層（ＮＡＳ）シグナリングの終了、モビリティ管理等を担うことができる。ネットワークスライシングは、利用されているサービスの種類に基づいてＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃのＣＮサポートをカスタマイズするためにＡＭＦ１８２ａ、１８２ｂによって使用され得る、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ。例えば、超高信頼低遅延（ＵＲＬＬＣ）アクセスに依拠するサービス、拡張大規模モバイルブロードバンド（ｅＭＢＢ）アクセスに依拠するサービス及びＭＴＣアクセスのためのサービス等、様々な使用事例ごとに様々なネットワークスライスを確立することができる。ＡＭＦ１８２ａ、１８２ｂは、ＲＡＮ１０４と、LTE、LTE-A、LTE-A Pro及び／又はWiFi等の非３GPPアクセス技術等の他の無線技術を使用する他のＲＡＮ（不図示）とを切り替えるための制御プレーン機能を提供し得る。

[0077] ＳＭＦ１８３ａ、１８３ｂは、Ｎ１１インタフェースによってＣＮ１０６内のＡＭＦ１８２ａ、１８２ｂに接続され得る。ＳＭＦ１８３ａ、１８３ｂは、Ｎ４インタフェースによってＣＮ１０６内のＵＰＦ１８４ａ、１８４ｂにも接続され得る。ＳＭＦ１８３ａ、１８３ｂは、ＵＰＦ１８４ａ、１８４ｂを選択し制御し、ＵＰＦ１８４ａ、１８４ｂを通るトラフィックのルーティングを構成することができる。ＳＭＦ１８３ａ、１８３ｂは、ＵＥのＩＰアドレスの管理及び割り当て、ＰＤＵセッションの管理、ポリシ実施及びＱｏＳの制御、ＤＬデータ通知の提供等の他の機能を実行することができる。ＰＤＵセッションの種類は、ＩＰベース、非ＩＰベース、イーサネットベース等であり得る。

[0078] ＵＰＦ１８４ａ、１８４ｂは、Ｎ３インタフェースによってＲＡＮ１０４内のgNB１８０ａ、１８０ｂ、１８０ｃの１つ又は複数に接続することができ、gNBは、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃにインターネット１１０等のパケット交換ネットワークへのアクセスを与えて、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃとＩＰ対応装置との間の通信を促進することができる。ＵＰＦ１８４、１８４ｂは、パケットのルーティング及び転送、ユーザプレーンポリシの実施、マルチホームＰＤＵセッションのサポート、ユーザプレーンＱｏＳの対処、ＤＬパケットのバッファリング、モビリティアンカリングの提供等の他の機能を実行することができる。

[0079] ＣＮ１０６は、他のネットワークとの通信を促進することができる。例えば、ＣＮ１０６は、ＣＮ１０６とＰＳＴＮ１０８との間のインタフェースとしての役割を果たすＩＰゲートウェイ（例えば、ＩＰマルチメディアサブシステム（ＩＭＳ）サーバ）を含むことができるか、又はかかるＩＰゲートウェイと通信し得る。加えて、ＣＮ１０６は、他のサービスプロバイダによって所有及び／又は運営される他の有線及び／又は無線ネットワークを含み得る他のネットワーク１１２へのアクセスをＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃに与えることができる。一実施形態では、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃは、ＵＰＦ１８４ａ、１８４ｂへのＮ３インタフェース並びにＵＰＦ１８４ａ、１８４ｂとＤＮ１８５ａ、１８５ｂとの間のＮ６インタフェースを介してＵＰＦ１８４ａ、１８４ｂ経由でローカルＤＮ１８５ａ、１８５ｂに接続され得る。

[0080] 図１Ａ～図１Ｄ及び図１Ａ～図１Ｄの対応する説明に鑑みて、ＷＴＲＵ１０２ａ～ｄ、基地局１１４ａ～ｂ、eNode-B１６０ａ～ｃ、ＭＭＥ１６２、ＳＧＷ１６４、ＰＧＷ１６６、gNB１８０ａ～ｃ、ＡＭＦ１８２ａ～ｂ、ＵＰＦ１８４ａ～ｂ、ＳＭＦ１８３ａ～ｂ、ＤＮ１８５ａ～ｂ及び／又は本明細書に記載の他の任意の装置の１つ又は複数に関して本明細書に記載する機能の１つ若しくは複数又は全てが１つ又は複数のエミュレーション装置（不図示）によって実行され得る。エミュレーション装置は、本明細書に記載する機能の１つ若しくは複数又は全てをエミュレートするように構成される１つ又は複数の装置であり得る。例えば、エミュレーション装置は、他の装置をテストするために及び／又はネットワーク及び／又はＷＴＲＵの機能をシミュレートするために使用することができる。

[0081] エミュレーション装置は、実験室環境内及び／又はオペレータネットワーク環境内で他の装置の１つ又は複数のテストを実施するように設計され得る。例えば、１つ又は複数のエミュレーション装置は、通信ネットワーク内の他の装置をテストするために有線及び／又は無線通信ネットワークの一部として完全に又は部分的に実装及び／又は導入されながら１つ若しくは複数又は全ての機能を実行することができる。１つ又は複数のエミュレーション装置は、有線及び／又は無線通信ネットワークの一部として一時的に実装／導入されながら１つ若しくは複数又は全ての機能を実行することができる。エミュレーション装置は、テストのために別の装置に直接結合することができ、及び／又は無線による通信を使用してテストを行うことができる。

[0082] １つ又は複数のエミュレーション装置は、有線及び／又は無線通信ネットワークの一部として実装／導入されなくても、全てを含む１つ又は複数の機能を実行することができる。例えば、エミュレーション装置は、１つ又は複数のコンポーネントのテストを実施するために、テスト実験室及び／又は非導入（例えば、テスト）有線及び／又は無線通信ネットワーク内のテストシナリオにおいて利用することができる。１つ又は複数のエミュレーション装置は、テスト機器であり得る。データを伝送及び／又は受信するために、（例えば、１つ又は複数のアンテナを含み得る）ＲＦ回路による直接のＲＦ結合及び／又は無線通信がエミュレーション装置によって使用され得る。

[0083] ２．４ＧＨｚ、５ＧＨｚ及び６ＧＨｚ帯域の高密度シナリオを含む多くの使用シナリオにおいて、広範囲の無線ユーザの全てのユーザが経験するサービス品質を向上させるためのあり得る将来の修正の範囲及び目的を考察するために、IEEE.802.11の高効率ＷＬＡＮ（ＨＥＷ）研究グループ（ＳＧ）が作られた。ＡＰ及びＳＴＡの高密度の展開並びに関連する無線リソース管理（ＲＲＭ）技術をサポートする新たな使用事例がＨＥＷ ＳＧによって検討されている。ＨＥＷの潜在的応用は、スタジアムでのイベントのためのデータ配信等の新興の使用シナリオ、列車の駅又は企業／小売り環境等のユーザ密度が高いシナリオ及び医学的応用のためのビデオ配信及び無線サービスに対する依存度の高まりを含む。ＩＥＥＥ規格の委員会は、ＨＥＷ ＳＧ内で策定された結果に基づいてIEEE 802.11axタスクグループ（ＴＧ）を承認した。

[0084] TGax規格の会議では、様々な応用に関する測定トラフィックがショートパケットの高い可能性を有することと、ショートパケットを同様に生成し得るネットワーク応用があることとを幾つかの寄稿が示した。それらの応用は、仮想オフィス、ＴＰＣ ＡＣＫ、ビデオストリーミングＡＣＫ、装置／コントローラ（例えば、マウス、キーボード、ゲームコントロール等）、アクセス（例えば、プローブ要求／回答）、ネットワーク選択（例えば、プローブ要求、アクセスネットワーククエリプロトコル（ＡＮＱＰ））及び／又はネットワーク管理／制御フレームを含む。802.11axにおける寄稿は、アップリンク（ＵＬ）及びダウンリンク（ＤＬ）ＯＦＤＭＡ並びにＵＬ及びＤＬ ＭＵ－ＭＩＭＯを含むマルチユーザ（ＭＵ）機能の導入を提案した。様々な目的のためにＵＬランダムアクセスを多重化するためのメカニズムを設計及び規定することは、802.11ax及び他のプロトコルで使用され得る。

[0085] ６ＧＨｚ帯における媒体アクセス問題に関するTGaxへの提案は、６ＧＨｚ帯のみでトリガ又はスケジュール媒体アクセスを使用すること、及び／又は６ＧＨｚ帯内で能動的走査を制限し、拡張分散チャネルアクセス（ＥＤＣＡ）媒体アクセスをスケジューリングすることを含む。

[0086] IEEE 802.11ba TGは、物理（ＰＨＹ）及び媒体アクセス制御（ＭＡＣ）の修正を定めて、802.11装置の高度な低出力動作を可能にするために作成された。ＭＡＣ及びＰＨＹの修正は、ウェイクアップ無線（ＷＵＲ）の動作を可能にし得る。ＷＵＲの期待動作帯は、２．４ＧＨｚ、５ＧＨｚを含み、サブ１ＧＨｚに拡張することができる。ＷＵＲ装置は、通常の802.11パケットを伝送するために使用される一次接続無線（ＰＣＲ）へのコンパニオン無線として動作することができる。ＰＣＲは、主無線と呼ぶこともできる。ＷＵＲは、制御情報（のみ）を運ぶパケットを伝送することができ、アクティブ状態にある受信機の１ミリワット（ｍＷ）未満の消費電力を有し得る。ＷＵＲによるウェイクアップパケットの受信は、一次接続無線（ＰＣＲ）をスリープから起動させ得る。一例では、ＷＵＲは、少なくとも２０ＭＨｚのペイロード帯域幅上で動作する一次接続無線の範囲と少なくとも同じである範囲を有し得る。

[0087] ＡＰ及び非ＡＰ ＳＴＡの両方がＷＵＲをコンパニオン無線として有することができる。ＷＵＲの使用事例の例は、ＩｏＴ装置、スマートフォン向けの低出力動作、迅速なメッセージ／着呼の通知シナリオ、迅速な状態クエリ／報告、構成変更シナリオ及び／又は迅速な緊急／重大事態の報告シナリオを含む。

[0088] IEEE 802.11bc TGは、802.11装置のための拡張ブロードキャストサービス（ｅＢＣＳ）に対するＭＡＣの修正を定めるために作成された。IEEE 802.11bcの修正は、IEEE 802.11のＰＨＹの仕様に影響を及ぼさない場合がある。ｅＢＣＳサービスは、ＡＰから非ＡＰ ＳＴＡへのＤＬ方向であり得るか、又はセンサ非ＡＰ ＳＴＡからのＵＬ方向であり得る。ｅＢＣＳは、特定のＡＰに関連付けられた又は関連付けられていないＳＴＡに提供され得る。１つのＡＰは、ｅＢＣＳサービスを有する最大３０００の非ＡＰ ＳＴＡをサポートすることが予期され得る。加えて、ｅＢＣＳサービスを消費し、ＡＰに直接伝送できない可能性がある低コストの非ＡＰ ＳＴＡがあり得る。ｅＢＣＳの使用事例の例は、スタジアムのビデオブロードキャスト、自動車のブロードキャスト、アップリンクセンサデータのブロードキャスト、美術館の情報及び多言語のブロードキャスト及び／又はイベントプロデューサの情報及びコンテンツのブロードキャストを含み得る。

[0089] ブロードキャスト又は他のチャネルのためのフレーム内符号化では、伝送フレームのコンテンツを符号化ビットの単一の組から導出することができる。フレーム間符号化では、伝送フレームのコンテンツを符号化ビットの複数の組から導出することができ、かかる符号化ビットの複数の組は、通常、別々のフレーム内で伝送されるが、復号を支援するために伝送され得る新たなサブフレームを形成するために（例えば、追加の増分に対して線形符号化を使用して）生成される。これは、コードレートの滑らかな変動を可能にするレートマッチングの革新的な形式により、信頼性を高めながら、全ての受信ＷＴＲＵ（ＳＴＡ）にブロードキャスト信号が伝送されることを可能にする。使用される符号器は、典型的には、可変レートコードであり、任意の２つのコードレートＲ＞Ｒ’について、レートＲ’のフレームは、レートＲのフレームと追加の冗長ビットとの連結である。

[0090] ＷＵＲ走査が802.11ba装置について合意されている。ＷＵＲ走査では、ＡＰは、自らに関する及び自らのＢＳＳに関する情報を提供するＷＵＲディスカバリフレームを送出することができる。ＷＵＲ対応のＷＴＲＵは、アソシエーションに適したＡＰ及びＢＳＳを発見するためにＷＵＲディスカバリフレームを走査することができる。しかし、ＷＴＲＵは、ＷＵＲ走査を開始するために、及び／又は受信されるＷＵＲディスカバリフレームに関する収集済みの情報を上位層に与えるために、ＭＡＣ層管理エンティティ（ＭＬＭＥ）プリミティブを定める必要があり得る。ＷＴＲＵがＷＵＲ走査プロセスを制御することができるように、且つＷＵＲ走査プロセス中に収集される受信ＷＵＲディスカバリフレームに関する情報を上位層に与えることができるように、適切なＭＬＭＥプリミティブを定めることができる。別段の定めがない限り、ＷＵＲ走査及びＷＵＲ走査プロセスという用語は、区別なく使用され得ることに留意すべきである。

[0091] 上記の問題に対処するために、本願による方法及びＷＴＲＵを下記の通り説明する。

[0092] 本願の一実施形態による方法２００を図２Ａに関して以下で説明する。図２Ａは、方法２００のフローチャートを示す。図２Ａに示すように、方法２００は、２０１において、ステーション管理エンティティ（ＳＭＥ）により、１つ又は複数のアクセスポイント（ＡＰ）によって伝送されるウェイクアップ無線（ＷＵＲ）ディスカバリフレームのためのＷＵＲ走査プロセスを可能にする要求プリミティブを生成することであって、要求プリミティブは、複数の第１のパラメータを含む、生成すること、２０２において、複数の第１のパラメータに基づいてＷＵＲ走査プロセスを実行すること、２０３において、メディアアクセス制御（ＭＡＣ）層において、ＷＵＲ走査プロセスの結果及び複数の第１のパラメータの少なくとも一部に基づいて少なくとも１つの確認プリミティブを生成すること、及び２０４において、ＭＡＣ層からＳＭＥに少なくとも１つの確認プリミティブを通信することを含み得る。

[0093] 従って、本願の一実施形態によるＷＴＲＵは、１つ又は複数のアクセスポイント（ＡＰ）によって伝送されるウェイクアップ無線（ＷＵＲ）ディスカバリフレームのためのＷＵＲ走査プロセスを可能にする要求プリミティブを生成することであって、要求プリミティブは、複数の第１のパラメータを含む、生成すること、複数の第１のパラメータに基づいてＷＵＲ走査プロセスを実行すること、ＭＡＣ層において、ＷＵＲ走査プロセスの結果及び複数の第１のパラメータの少なくとも一部に基づいて少なくとも１つの確認プリミティブを生成すること、及びＭＡＣ層からＳＭＥに少なくとも１つの確認プリミティブを通信することを行うように構成されるプロセッサを含み得る。

[0094] 以下の説明は、２０１におけるプロセスを詳細に説明する。

[0095] 要求プリミティブは、ＷＵＲ走査のために定められ、使用され得るＭＬＭＥプリミティブであり得る。一実施形態では、要求プリミティブは、MLME-WURSCAN.Requestプリミティブであり得る。例えば、MLME-WURSCAN.Requestプリミティブ等のＭＬＭＥプリミティブによってＷＵＲ走査が開始され得る。このＭＬＭＥプリミティブは、ＷＵＲディスカバリフレームにより、ＷＴＲＵが参加を試みるために後に選択可能な潜在的なＢＳＳの調査を要求し得る。本願では、別段の定めがない限り、「MLME-WURSCAN.Requestプリミティブ」、「MLME-WURSCAN.Request」及び「要求プリミティブ」という用語は、区別なく使用され得ることに留意すべきである。要求プリミティブ（例えば、MLME-WURSCAN.Requestプリミティブ）内のパラメータを詳細な実施形態に関して以下で説明する。

[0096] 別の実施形態では、要求プリミティブは、MLME-SCAN.Requestプリミティブ又はMLME-SCAN.Requestプリミティブの一部であり得る。MLME-SCAN.Requestプリミティブ内のパラメータは、MLME-WURSCAN.Requestプリミティブ内のパラメータと同様であり得、MLME-SCAN.Requestプリミティブ内のパラメータについては、以下で更に説明する。本願では、別段の定めがない限り、「MLME-SCAN.Requestプリミティブ」、「MLME-SCAN.Request」及び「要求プリミティブ」という用語は、区別なく使用され得る。要求プリミティブ（例えば、MLME-WURSCAN.Requestプリミティブ）内のパラメータを詳細な実施形態に関して以下で説明する。

[0097] 一実施形態では、要求プリミティブは、ステーション管理エンティティ（ＳＭＥ）によって生成され得る。例えば、ＷＴＲＵが、そのＷＵＲ又は低出力ＷＵＲモードを使用してＷＵＲディスカバリフレームを走査して、自らが参加可能な他のＢＳＳがあるかどうかを判定するために、MLME-WURSCAN.requestプリミティブがＳＭＥによって生成され得る。一実施形態では、要求プリミティブは、プロセッサによって生成され得る。

[0098] １つ又は複数のＡＰによって伝送されるウェイクアップ無線（ＷＵＲ）ディスカバリフレームのためのＷＵＲ走査プロセスは、アソシエーションに適したＡＰ及びＢＳＳをＷＴＲＵが走査し、従って発見するための走査プロセスである。ＷＴＲＵは、ＡＰから伝送されるＷＵＲディスカバリフレームを走査及び発見する。ＷＵＲディスカバリフレームは、ＳＳＩＤ、圧縮ＳＳＩＤ、圧縮ＢＳＳＩＤ、チャネル情報等の様々なフィールドを含み得る。

[0099] 要求プリミティブは、複数の第１のパラメータを含み得る。複数の第１のパラメータは、基本サービスセット識別情報（ＢＳＳＩＤ）、BSSIDList、サービスセット識別情報（ＳＳＩＤ）、SSIDList、CompressedBSSID、CompressedSSID、CompressedBSSIDList、CompressedSSIDList、DiscoveryChannel、DiscoveryChannelList、MinDiscoveryChannelTime、MaxDiscoveryChannelTime、ReceivedPowerThreshod、MaxScanningTime、WURScanningReportingPeriod（又はWURScanningReportingTime）、WURScanningMode、WURScanningReportingOption又はRequestWURresultの少なくとも１つを含み得る。以下の部分で上述のパラメータを１つずつ説明する。

[0100] ＢＳＳＩＤは、所望のＡＰ又は所望のＢＳＳのＢＳＳＩＤを示すことができる。一実施形態では、ＢＳＳＩＤは、４８ビットラベルでありMAC-48の規定に従う基本サービスセットを識別することができる。ＢＳＳＩＤは、ワイルドカードＢＳＳＩＤ（例えば、ff:ff:ff:ff:ff:ff）であり得る。一実施形態では、要求プリミティブ内にＢＳＳＩＤが１つのみある場合がある。別の実施形態では、要求プリミティブ内に複数のＢＳＳＩＤがあり得る。ＢＳＳＩＤは、BSSIDList内に含まれ得る。換言すれば、BSSIDListは、１つ又は複数のＢＳＳＩＤの情報を含み得る。例えば、BSSIDListは、そのそれぞれが所望のＢＳＳ又はＡＰを示し得る複数のＢＳＳＩＤを含むリストであり得る。ＢＳＳＩＤ及びBSSIDListの一部の例を上記で説明したが、それらは、排他的であること又は本願に対する限定であることを意図しない。本願の原理の実現を促進する可能性がある限り、ＢＳＳＩＤ及びBSSIDListの上記の実施形態の任意の改変形態が本願によるこの方法及びＷＴＲＵに適用され得る。

[0101] ＳＳＩＤは、所望のＡＰ又はＢＳＳ又はＳＳのサービスセット識別子であり得る。即ち、ＳＳＩＤは、ＷＴＲＵが接続を望む可能性があるサービスセットを示し得る。ＳＳＩＤは、ワイルドカードＳＳＩＤであり得る。一実施形態では、要求プリミティブ内にＳＳＩＤが１つのみある場合がある。別の実施形態では、要求プリミティブ内に複数のＳＳＩＤがあり得る。ＳＳＩＤは、SSIDList内に含まれ得る。換言すれば、SSIDListは、所望のＡＰ又はＢＳＳの１つ又は複数のＳＳＩＤの情報を含み得る。例えば、SSIDListは、そのそれぞれがＡＰ又はＢＳＳの所望のサービスセットを示し得る複数のＳＳＩＤを含むリストであり得る。ＳＳＩＤ及びSSIDListの一部の例を上記で説明したが、それらは、排他的であること又は本願に対する限定であることを意図しない。本願の原理の実現を促進する可能性がある限り、ＳＳＩＤ及びSSIDListの上記の実施形態の任意の改変形態が本願によるこの方法及びＷＴＲＵに適用され得る。

[0102] CompressedBSSIDは、ＷＴＲＵが関連付けられることを望む可能性がある所望のＡＰ又は所望のＢＳＳの圧縮ＢＳＳＩＤを示し得る。一実施形態では、CompressedBSSIDは、部分的なＢＳＳＩＤであり得る。CompressedBSSIDは、ワイルドカードＢＳＳＩＤに関連付けられ得る。関連付けられるCompressedBSSIDは、提供されるＢＳＳＩＤに基づいて計算され得る。一実施形態では、要求プリミティブ内にCompressedBSSIDが１つのみある場合がある。別の実施形態では、要求プリミティブ内に複数のCompressedBSSIDがあり得る。CompressedBSSIDは、CompressedBSSIDList内に含まれ得る。換言すれば、CompressedBSSIDListは、所望のＡＰ又はＢＳＳの１つ又は複数の圧縮ＢＳＳＩＤを含み得る。例えば、CompressedBSSIDListは、そのそれぞれが所望のＢＳＳ又はＡＰを示し得る複数の圧縮ＢＳＳＩＤを含むリストであり得る。CompressedBSSID及びCompressedBSSIDListの一部の例を上記で説明したが、それらは、排他的であること又は本願に対する限定であることを意図しない。本願の原理の実現を促進する可能性がある限り、CompressedBSSID及びCompressedBSSIDListの上記の実施形態の任意の改変形態が本願によるこの方法及びＷＴＲＵに適用され得る。

[0103] DiscoveryChannelは、ＷＲＵ走査プロセス内でディスカバリフレーム（例えば、ＷＵＲディスカバリフレーム）を走査することができるチャネル又はＷＵＲチャネルを示し得る。一実施形態では、要求プリミティブ内にDiscoveryChannelが１つのみある場合がある。即ち、このDiscoveryChannelによって示される特定のチャネル上でディスカバリフレームが走査され得る。別の実施形態では、要求プリミティブ内に複数のDiscoveryChannelがあり得る。即ち、これらのDiscoveryChannelによって示される複数のチャネル上でディスカバリフレームが走査され得る。DiscoveryChannelは、DiscoveryChannelList内に含まれ得る。換言すれば、DiscoveryChannelListは、１つ又は複数のDiscoveryChannelの情報を含み得る。例えば、DiscoveryChannelListは、そのそれぞれが所望のＡＰ又はＢＳＳを発見するためにディスカバリフレーム（例えば、ＷＵＲディスカバリフレーム）を走査することができるチャネル又はＷＵＲチャネルを示し得る複数のDiscoveryChannelを含むリストであり得る。MLME-WURSCAN.requestプリミティブが１つ又は複数のWURDiscoveryChannel又はWURDiscoveryChannelListを含む場合、ＷＴＲＵは、ＷＵＲディスカバリフレームを走査するためにそれらのＷＵＲディスカバリチャネルにのみ調整することができる。DiscoveryChannel及びDiscoveryChannelListの一部の例を上記で説明したが、それらは、排他的であること又は本願に対する限定であることを意図しない。本願の原理の実現を促進する可能性がある限り、DiscoveryChannel及びDiscoveryChannelListの上記の実施形態の任意の改変形態が本願によるこの方法及びＷＴＲＵに適用され得る。別段の定めがない限り、チャネル、ＷＵＲチャネル及びディスカバリチャネルは、区別なく使用され得ることに留意すべきである。

[0104] MinDiscoveryChannelTimeは、DiscoveryChannelList内のDiscoveryChannelによって示されるチャネルのそれぞれでＷＴＲＵがＷＵＲ走査を行うための、時間単位（ＴＵ）又は他の単位における最小時間を示し得る。MinDiscoveryChannelTimeは、所望のＡＰ又はＢＳＳ又はＳＳのＷＵＲディスカバリ期間に基づいて決定され得る。ＷＵＲディスカバリ期間は、予め取得された知識であり得るか、又は１つ若しくは複数のＡＰから無線で受信され得る。MinDiscoveryChannelTime及びその好ましい実施形態について上記で説明したが、それらは、排他的であること又は本願に対する限定であることを意図しない。本願の原理の実現を促進する可能性がある限り、MinDiscoveryChannelTimeの利用可能な任意の値が本願によるこの方法及びＷＴＲＵに適用され得る。

[0105] MaxDiscoveryChannelTimeは、DiscoveryChannelList内のDiscoveryChannelによって示されるチャネルのそれぞれでＷＴＲＵがＷＵＲ走査を行うための、ＴＵ又は他の単位における最大時間を示し得る。MaxDiscoveryChannelTimeは、所望のＡＰ又はＢＳＳ又はＳＳのＷＵＲディスカバリ期間に基づいて決定され得る。ＷＵＲディスカバリ期間は、予め取得された知識であり得るか、又は１つ若しくは複数のＡＰから無線で受信され得る。MaxDiscoveryChannelTime及びその好ましい実施形態について上記で説明したが、それらは、排他的であること又は本願に対する限定であることを意図しない。本願の原理の実現を促進する可能性がある限り、MaxDiscoveryChannelTimeの利用可能な任意の値が本願によるこの方法及びＷＴＲＵに適用され得る。

[0106] ReceivedPowerThresholdは、それを上回るとディスカバリフレーム（例えば、ＷＵＲディスカバリフレーム）が処理される受信出力の閾値を示し得る。即ち、その受信出力がReceivedPowerThresholdを上回るディスカバリフレームのみがＷＵＲ走査プロセス内で処理され得る。その受信出力がReceivedPowerThresholdを下回るディスカバリフレームは、ＷＵＲ走査プロセス内で無視することができる。一実施形態では、ReceivedPowerThresholdを受信チャネル出力インジケータ（ＲＣＰＩ）、受信信号強度インジケーション（ＲＳＳＩ）、信号対雑音比（ＳＮＲ）及び／又は信号対干渉雑音比（ＳＩＮＲ）に関して定めることができる。ReceivedPowerThreshold及びその好ましい実施形態について上記で説明したが、それらは、排他的であること又は本願に対する限定であることを意図しない。本願の原理の実現を促進する可能性がある限り、ReceivedPowerThresholdの利用可能な任意の値が本願によるこの方法及びＷＴＲＵに適用され得る。

[0107] MaxWURScanningTimeは、ＷＴＲＵがＷＵＲ走査プロセスを行うための、ＴＵ又は他の単位における最大時間を示し得る。MaxWURScanningTime及びその好ましい実施形態について上記で説明したが、それらは、排他的であること又は本願に対する限定であることを意図しない。本願の原理の実現を促進する可能性がある限り、MaxWURScanningTimeの利用可能な任意の値が本願によるこの方法及びＷＴＲＵに適用され得る。

[0108] WURScanningReportingPeriod（又はWURScanningReportingTime）は、ＷＵＲ走査プロセスの結果を（例えば、MLME-WURScanning.confirmプリミティブによって）報告することができる時点又は期間を示すことができる。WURScanningReportingPeriod及びその好ましい実施形態について上記で説明したが、それらは、排他的であること又は本願に対する限定であることを意図しない。本願の原理の実現を促進する可能性がある限り、WURScanningReportingPeriodの利用可能な任意の値が本願によるこの方法及びＷＴＲＵに適用され得る。

[0109] WURScanningModeは、ＷＵＲ走査のモードを示すことができる。例えば、WURScanningModeの値は、「バックグラウンド」、「通常の走査と同時」、「ＷＵＲ走査のみ」等であり得る。換言すれば、WURScanningModeによって示されるＷＵＲ走査のモードは、「バックグラウンド」、「通常の走査と同時」、「ＷＵＲ走査のみ」等であり得る。上記で述べたＷＵＲ走査のモードを詳細な実施形態に関して以下で更に説明する。WURScanningMode及びその例示的な値について上記で説明したが、それらは、排他的であること又は本願に対する限定であることを意図しない。本願の原理の実現を促進する可能性がある限り、WURScanningModeの利用可能な任意の値が本願によるこの方法及びＷＴＲＵに適用され得る。

[0110] WURScanningReportingOptionは、ＷＵＲ走査プロセスの結果をどのように報告できるかを示し得る。即ち、ＷＵＲ走査プロセスの結果を報告する選択肢がWURScanningReportingOptionによって示され得る。WURScanningReportingOptionの値は、「Immediate」、「Periodic」、「At_Pre-determined_Time」、「ChannelSpecific」、「At_Request」、「At_End」等であり得る。例えば、WURScanningReportingOptionのパラメータが「Periodic」又は「At_Specified_Time」の値を有する場合、ＷＵＲ走査プロセスの結果を提供又は報告することができる時点又は周期性を示すために、上記のWURScanningReportingPeriod又はWURScanningReportingTimeが同じプリミティブ（即ち要求プリミティブ）内に含まれ得る。上記で述べたＷＵＲ走査プロセスの結果を報告する選択肢を詳細な実施形態に関して以下で更に説明する。WURScanningReportingOption及びその例示的な値について上記で説明したが、それらは、排他的であること又は本願に対する限定であることを意図しない。本願の原理の実現を促進する可能性がある限り、WURScanningReportingOptionの利用可能な任意の値が本願によるこの方法及びＷＴＲＵに適用され得る。

[0111] RequestResultsは、ＷＵＲ走査プロセスの現在の結果が要求されており、確認プリミティブ（即ちMLME-WURSCAN.confirmプリミティブ）を発行することによって提供されるべきであることを示し得る。

[0112] 要求プリミティブ内に含まれ得る様々な第１のパラメータをこれまで説明してきた。上記で述べた第１のパラメータは、例として示したに過ぎず、排他的であること又は本願に対する限定であることを意図しないことに留意すべきである。本願の原理の実現を促進する可能性がある限り、利用可能な任意のパラメータが要求プリミティブ内に含まれ得る。

[0113] 以下の部分は、２０２におけるプロセスを詳細に説明する。上記で説明したように、方法２００は、２０２において、複数の第１のパラメータに基づいて、ＷＵＲを使用してＷＵＲ走査プロセスを実行することを含み得る。

[0114] 一実施形態では、上記で説明したように、ＳＭＥ又はプロセッサが要求プリミティブ（例えば、MLME-WURSCAN.requestプリミティブ）を生成した後、プロセッサは、ＷＵＲ走査プロセスを即座に又は現在のフレーム交換シーケンスの完了後に開始するようにＷＴＲＵを制御することができる。次いで、ＷＴＲＵは、要求プリミティブ内の複数の第１のパラメータに基づいてＷＵＲ走査プロセスを実行することができる。

[0115] WURScanningModeパラメータに応じて、例えばその値が「バックグラウンド」である場合、本願によるＷＵＲ走査プロセスをバックグラウンド走査として開始することができる。その場合、ＷＴＲＵは、他の種類の動作を行うことができる。

[0116] WURScanningModeパラメータの値が「ＷＵＲ走査のみ」である場合、ＷＵＲ走査プロセスをＷＵＲ走査のみとして開始することができる。その場合、例えば、ＷＴＲＵは、自らの主無線をオフにすることができ、及び／又は低出力ＷＵＲモードにある間のみＷＵＲ走査を行うことができ、その間、ＷＴＲＵは、他のいかなる種類の動作も行うことができない。

[0117] WURScanningModeパラメータの値が「通常の走査と同時」、「受動走査／能動走査と同時」である場合、ＷＵＲ走査プロセスを、WURScanningModeパラメータによって示され得る通常の走査、能動走査／受動走査と共に同時のディスカバリプロセスとして行うことができる。例えば、ＷＴＲＵは、自らのＷＵＲを使用して、低出力ＷＵＲモード内でＷＵＲディスカバリフレームを走査し、その間、例えばＰＣＲ又は主無線を使用して受動走査又は能動走査を行うことができる。

[0118] 上記で説明したように、WURScanningModeパラメータに基づいて様々なＷＵＲ走査モードを選択することができる。ＷＵＲ走査プロセスは、所与の期間内でＷＴＲＵによって実行される唯一の走査プロセスでない可能性があることに留意すべきである。即ち、非ＷＵＲ走査プロセス（例えば、能動走査プロセス、受動走査プロセス等）及びＷＵＲ走査プロセスの両方がＷＴＲＵによって同時に実行され得る。

[0119] 別の実施形態では、要求プリミティブは、MLME-SCAN.Requestプリミティブ又はMLME-SCAN.Requestプリミティブの一部であり得る。一例として、ＷＵＲ走査プロセスは、１つ又は複数のＷＵＲ走査パラメータを含み得るMLME-SCAN.requestプリミティブによって開始され得る。例えば、以下のパラメータ：BSSIDList、SSIDList、CompressedBSSID、CompressedSSID、CompressedBSSIDList、CompressedSSIDList、DiscoveryChannel、DiscoveryChannelList、MinDiscoveryChannelTime、MaxDiscoveryChannelTime、MaxScanningTime、ReceivedPowerThreshold、WURScanningMode、WURScanningReportingOption、RequestWURResultの何れもMLME-SCAN.requestプリミティブ内に追加することができる。これらのパラメータは、本明細書に記載の通りであり得、ＷＵＲ走査を開始するための手順は、本明細書に記載するのと同様であり得る。これらのパラメータの詳細な説明は、MLME-WURSCAN.requestプリミティブに関して上記で説明したのと同様であるか又は同じであり得る。従って、これらのパラメータの詳細な説明を省く。MLME-WURSCAN及びMLME-SCANという用語は、（例えば、MLME-SCAN.request、MLME-SCAN.confirm、MLME-WURSCANSTOP.request及び／又はMLME-WURSCANSTOP.confirm等のプリミティブの名称において）区別なく使用され得る。

[0120] 以下の説明部分は、２０３におけるプロセスを説明する。上記で説明したように、方法２００は、２０３において、ＷＵＲ走査プロセスの結果及び複数の第１のパラメータの少なくとも一部に基づいて少なくとも１つの確認プリミティブを生成することを含み得る。

[0121] 少なくとも１つの確認プリミティブは、１つ又は複数のMLME-WURSCAN.confirmプリミティブ、１つ又は複数のMLME-SCAN.confirmプリミティブ又はMLME-WURSCAN.confirmプリミティブとMLME-SCAN.confirmプリミティブとの組み合わせを含み得る。例えば、少なくとも１つの確認プリミティブは、１つのMLME-WURSCAN.confirmプリミティブ及び１つのMLME-SCAN.confirmプリミティブを含み得る。別の例では、少なくとも１つの確認プリミティブは、複数のMLME-WURSCAN.confirmプリミティブを含み、MLME-SCAN.confirmプリミティブを含まなくてもよい。上記では、少なくとも１つの確認プリミティブの一部の例を説明したが、それらは、排他的であること又は本願に対する限定であることを意図しない。一部の実施形態では、「MLME-SCAN.confirmプリミティブ」、「MLME-WURSCAN.confirmプリミティブ」、「確認プリミティブ」という用語は、区別なく使用され得る。

[0122] 少なくとも１つの確認プリミティブは、（１）２０２のプロセスの結果、及び（２）複数の第１のパラメータの一部の両方に基づいて生成され得る。即ち、一方では、２０２のプロセスの結果、即ちＷＵＲ走査プロセスの結果に基づいて少なくとも１つの確認プリミティブを生成することができる。他方では、複数の第１のパラメータの一部に基づいて少なくとも１つの確認プリミティブを生成することができる。複数の第１のパラメータの一部は、WURScanningReportingOption、ReceivedPowerThreshold、CompressedBSSID、CompressedSSID、CompressedBSSIDList、CompressedSSIDList又はその組み合わせの少なくとも１つを含み得る。以下の説明部分は、確認プリミティブを決定するために使用される複数の第１のパラメータの一部を詳細に説明する。以下の説明では、別段の定めがない限り、確認プリミティブ及びMLME-WURSCAN.confirmプリミティブは、区別なく使用され得る。

[0123] 一実施形態では、複数の第１のパラメータの一部は、WURScanningReportingOptionパラメータを含み得る。即ち、WURScanningReportingOptionの値に基づいてMLME-WURSCAN.confirmプリミティブが生成され得る。WURScanningReportingOptionは、MLME-WURSCAN.confirmプリミティブを生成するためのタイミングを決定するために使用され得る。以下の説明は、MLME-WURSCAN.confirmプリミティブとWURScanningReportingOptionとの間の関係、即ちWURScanningReportingOptionの値に基づいてMLME-WURSCAN.confirmプリミティブをどのように生成するかについて記載する。

[0124] 例えば、WURScanningReportingOptionの値が「Immediate」である場合、ＷＵＲディスカバリフレームが正しく受信又は検出されるたびに、MLME-WURSCAN.confirmプリミティブが生成され得る。

[0125] WURScanningReportingOptionの値が「Channel_Specific」である場合、MLME-WURSCAN.confirmプリミティブは、ＷＵＲディスカバリフレームについて特定のＷＵＲディスカバリチャネルが走査された後に生成され得、MLME_WURSCAN.rquest内で示される一致する圧縮ＳＳＩＤ又は圧縮ＢＳＳＩＤを有する場合も有さない場合もある。この事例では、ＷＵＲディスカバリチャネルは、MLME_WURSCAN.request内で示される１つ又は複数のＷＵＲディスカバリチャネルであり得る。

[0126] WURScanningReportingOptionの値が「At_Request」である場合、現在のＷＵＲ走査手順の結果を与えるために、RequestResultsパラメータと共に又はその値が１に設定されたRequestResultsパラメータと共にMLME-WURSCAN.requestが生成されている場合にMLME-WURSCAN.confirmプリミティブが生成され得る。

[0127] WURScanningReportingOptionの値が「At_End」である場合、MLME-WURSCAN.confirmプリミティブは、MLME-WURSCAN.requestプリミティブ内で示され得る１つ又は複数のＷＵＲディスカバリチャネル上でＷＵＲ走査が完了した後、現在のＷＵＲ走査手順の終了時に発行され得る。

[0128] WURScanningReportingOptionの値が「Periodic」又は「At_Time」である場合、MLME-WURSCAN.confirmプリミティブは、MLME-WURSCAN.requestプリミティブ内で示され得る期間ごとに又は一定の時点において生成され得る。

[0129] 一実施形態では、複数の第１のパラメータの一部は、ＳＳＩＤ、SSIDList、ＢＳＳＩＤ、BSSIDList、CompressedSSID、CompressedSSDList、CompressedBSSID又はCompressedBSSIDListの少なくとも１つのパラメータを含み得る。即ち、MLME-WURSCAN.confirmプリミティブは、ＳＳＩＤ、SSIDList、ＢＳＳＩＤ、BSSIDList、CompressedSSID、CompressedSSDList、CompressedBSSID又はCompressedBSSIDListの少なくとも１つのパラメータの値に基づいて生成され得る。以下の説明は、MLME-WURSCAN.confirmプリミティブと上述のパラメータとの間の関係、即ち上述の少なくとも１つのパラメータの値に基づいてMLME-WURSCAN.confirmプリミティブをどのように生成するかについて記載する。

[0130] 例えば、MLME-WURSCAN.confirmプリミティブは、一致するＳＳＩＤ、ＢＳＳＩＤ、圧縮ＳＳＩＤ又は圧縮ＢＳＳＩＤを有するＷＵＲディスカバリフレームが受信されている場合に生成され得る。別の例では、１つ又は複数のCompressedBSSID又はCompressedSSIDが要求プリミティブ（例えば、MLME-WURSCAN.requestプリミティブ）内で与えられている場合、一致する圧縮ＳＳＩＤ又は一致する圧縮ＢＳＳＩＤを有するＷＵＲディスカバリフレームが受信されている場合にMLME-WURSCAN.confirmプリミティブが生成され得る。例えば、受信されるＷＵＲディスカバリフレームにおいて、ＩＤフィールド内に含まれる送信機ＩＤが所望の圧縮ＢＳＳＩＤの１２個の最下位ビット（ＬＳＢ）と一致し、タイプ依存フィールドが所望の圧縮ＢＳＳＩＤの１２ＭＳＢを含む場合、一致する圧縮ＢＳＳＩＤがある可能性があり、その場合、MLME-WURSCAN.confirmプリミティブが生成され得る。MLME-WURSCAN.requestがCompressedBSSID、CompressedSSID、CompressedBSSIDList、CompressedSSIDListの１つ又は複数を含む場合、一致するCompressedBSSID又はCompressedSSID（又はその一部）を有するＢＳＳのみが報告され得る。

[0131] 一実施形態では、複数の第１のパラメータの一部は、ReceivedPowerThresholdパラメータを含み得る。即ち、ReceivedPowerThresholdの値に基づいてMLME-WURSCAN.confirmプリミティブが生成され得る。例えば、MLME-WURSCAN.requestプリミティブがReceivedPowerThresholdを含む場合、そのＷＵＲディスカバリフレームが所与のReceivedPowerThresholdを上回る受信出力でＷＴＲＵによって受信されているＢＳＳについてのみ、MLME-WURSCAN.confirmプリミティブが生成され得る。即ち、ＷＵＲディスカバリフレームの受信出力が所与のReceivedPowerThresholdを上回る場合、ＷＵＲディスカバリフレームを伝送しているＢＳＳがMLME-WURSCAN.confirmプリミティブによって報告され得る。

[0132] 以下の説明は、本願による確認プリミティブの内容を記載する。確認プリミティブ（例えば、MLME-WURSCAN.confirmプリミティブ）は、（例えば、１つ又は複数のＷＵＲディスカバリフレームを受信することによって）ＷＵＲ走査プロセスによって検出されるＢＳＳの組の記述を返すために使用され得る。一実施形態では、WURReportingOptionの値が「Channel_Specific」、「At_Request」又は「Periodic」若しくは「At_Specified_Time」である場合、複数のMLME-WURSCAN.confirmプリミティブが生成され得る。別の実施形態では、単一のMLME-WURSCAN.confirmプリミティブが生成され得る。

[0133] 一実施形態では、少なくとも１つの確認プリミティブが生成され得、少なくとも１つの確認プリミティブのそれぞれが複数の第２のパラメータを含み得る。複数の第２のパラメータは、BSSDescriptionFromWURDFSet、ResultCode、ScannedWURDiscoveryChannelList又はVendorSpecificInfoの少なくとも１つのパラメータを含み得る。BSSDescriptionFromWURDFSetパラメータは、dot11WUROptionImplemented又はdot11WURActivatedが真である場合に存在し得る。以下の説明は、確認プリミティブ内の上述の第２のパラメータを詳細に記載する。

[0134] 一実施形態では、確認プリミティブ内に１つ又は複数のBSSDescriptionFromWURDFSetがあり得る。各BSSDescriptionFromWURDFSetは、表１に示すパラメータの例のような１つ又は複数のパラメータで構成され得る。

[0135] ResultCodeは、以下の値の例：SUCCESS、INTERMEDIATE_SCAN_RESULT、NOT_SUPPORTED、PARTIAL_WURSCAN、PERIODIC_SCAN_RESULT、REQUESTED_SCAN_RESULTSの少なくとも１つを有し得る。これらの全ての値の例において、結果がＷＵＲ走査の結果であることを明確にするために「SCAN」を「WURSCAN」で置換することができる。ResultCodeの値は、MLME-WURSCAN.confirmプリミティブが発行されている理由に依存し得る。以下の説明は、上記のResultCodeの値の例を詳細に記載する。

[0136] ＷＵＲ走査プロセスが成功裏に行われている場合、SUCCESSを使用することができる。MLME-WURSCAN.requestプリミティブ内のWURReportingOptionパラメータがChannel_Specific又はImmediateである場合、INTERMEDIATE_SCAN_RESULTを使用することができる。全てのＷＵＲディスカバリチャネルが走査されない場合、ResultCodeの値をPARTIAL_SCANに設定することができる。MLME-WURSCAN.requestプリミティブ内のWURReportingOptionパラメータがPeriodic又はAt_Requested_Timeである場合、ResultCodeの値をPERIODIC_SCAN_RESULTに設定することができる。MLME-WURSCAN.requestプリミティブ内のWURReportingOptionパラメータがAt_Requestであり、MLME-WURSCAN.requestプリミティブがRequestWURResultと共に受信されている場合、ResultCodeの値をREQUESTED_SCAN_RESULTSに設定することができる。

[0137] 上述のResultCodeの値の例は、例として示したに過ぎず、排他的であること又は本願に対する限定であることを意図しないことに留意すべきである。本願の原理の実現を促進する可能性がある限り、ResultCodeの利用可能な任意の値が本願による方法及びＷＴＲＵに適用され得る。

[0138] ScannedWURDiscoveryChannelListは、走査されているＷＵＲディスカバリチャネルのリストを含み得る。

[0139] 一実施形態では、ＷＵＲの走査結果は、MLME-SCAN.confirmプリミティブによって又はMLME-SCAN.confirmプリミティブの一部として報告され得る。即ち、MLME-SCAN.confirmプリミティブは、（例えば、１つ又は複数のＷＵＲディスカバリフレームを受信することによって）ＷＵＲ走査プロセスによって検出されるＢＳＳ又はＡＰの組の記述を返すために使用され得る。WURReportingOptionの値が「Channel_Specific」、「At_Request」、「Periodic」又は「At_Specified_Time」である場合、複数のMLME-SCAN.confirmプリミティブを発行することができる。その他の場合、単一のMLME-SCAN.confirmプリミティブが発行され得る。MLME-SCAN.confirmプリミティブは、以下のパラメータの例：BSSDescriptionFromWURDFSet、ResultCode、ScannedWURDiscoveryChannelList又はVendorSpecificInfoの何れか１つを含み得る。パラメータの例は、MLME-WURSCAN.confirmプリミティブに関して記載したパラメータと同じ又は同様であり得る。従って、MLME-SCAN.confirmプリミティブ内のパラメータの例の詳細な説明を省く。本願では、別段の定めがない限り、MLME-WURSCAN及びMLME-SCANという用語は、区別なく使用され得る。従って、別段の定めがない限り、MLME-SCAN.request及びMLME-WURSCAN.requestという用語は、区別なく使用され得、MLME-SCAN.confirm及びMLME-WURSCAN.confirmという用語は、区別なく使用され得、「MLME-WURSCAN-STOP.Request」、「MLME-WURSCAN-STOP.Requestプリミティブ」、「MLME-SCAN-STOP.Request」、「MLME-SCAN-STOP.Requestプリミティブ」及び「停止要求プリミティブ」という用語は、区別なく使用され得、「MLME-WURSCAN-STOP.confirm」、「MLME-WURSCAN-STOP. confirmプリミティブ」、「MLME-SCAN-STOP.confirm」、「MLME-SCAN-STOP.confirmプリミティブ」及び「停止確認プリミティブ」という用語は、区別なく使用され得る。

[0140] ２０３でのプロセス後、方法２００は、２０４のプロセス、即ちＭＡＣ層からＳＭＥに少なくとも１つの確認プリミティブを通信することに進む。

[0141] 本願の第２の実施形態による方法及びＷＴＲＵを図２Ｂに関して以下で説明する。図２Ｂに示すように、２０１～２０４のプロセスは、図２Ｂに関して上記で説明したプロセスと同様又は同じである。第１の実施形態と第２の実施形態との違いは、図２Ｂに示す方法２００が２０５～２０７のプロセスを含むことである。より詳細には、方法２００は、２０５において、ＷＵＲ走査プロセスを停止するために停止要求プリミティブが生成されているかどうかを検出することを更に含み、停止要求プリミティブが生成されていることを条件として、方法２００は、２０６でＷＵＲ走査プロセスを停止すること、及び２０７で停止確認プリミティブを生成することを更に含む。停止プリミティブは、第１の確認プリミティブが生成される前に生成され得る。

[0142] 以下の説明は、２０５及び２０７におけるプロセスを記載する。一実施形態では、停止要求プリミティブは、進行中の任意のＷＵＲ走査プロセスを終了することができるMLME-WURSCAN-STOP.requestプリミティブであり得る。例えば、WURScanningModeパラメータに基づいてＷＴＲＵがＷＵＲ走査プロセスを何れの走査モードで実行していようと、MLME-WURSCAN-STOP.requestプリミティブは、かかるＷＵＲ走査プロセスを終了することができる。ＷＴＲＵによって実行されている進行中の全てのＷＵＲ走査プロセスを停止するために、MLME-WURSCAN-STOP.requestプリミティブというプリミティブがＳＭＥによって生成され得る。

[0143] 別の実施形態では、停止要求プリミティブは、WUR-SCAN-STOP.requestプリミティブ又はWUR-SCAN-STOP.requestプリミティブの一部であり得る。WUR-SCAN-STOP.requestプリミティブは、進行中の任意のＷＵＲ走査プロセスを終了するために使用され得る。WUR-SCAN-STOP.requestプリミティブは、ScanType等の１つ又は複数のパラメータを含み得る。上記で説明したように、複数の走査プロセス（例えば、ＷＵＲ走査プロセス及び非ＷＵＲ走査プロセスの両方）がＷＴＲＵによって同時に実行され得る。ScanTypeパラメータは、プリミティブが終了することができる走査の種類を示し得る。ScanTypeパラメータは、以下の値：WUR_Scan、Non-WUR_Scan及びAll_Scanの何れか１つを有し得る。ScanTypeがWUR_Scanである場合、進行中の全てのＷＵＲ走査プロセスを終了することができる。ScanTypeがNon_WUR_Scanである場合、受動走査プロセス及び能動走査プロセスを含む非ＷＵＲ走査プロセスを終了することができる。ScanTypeがAll_Scanである場合、ＷＵＲ走査及び非ＷＵＲ走査（例えば、能動走査及び受動走査）を含む進行中の全ての走査プロセスを終了することができる。

[0144] 停止要求プリミティブが生成されている場合、２０６において、停止要求プリミティブに基づいて対応する走査プロセスを終了することができる。即ち、ＷＴＲＵ又はそのプロセッサが停止要求プリミティブを受信する場合、停止要求プリミティブによって識別される対応する走査プロセスを終了することができる。

[0145] 以下の説明は、２０７におけるプロセスを記載する。上記で説明したように、方法２００は、２０７で停止確認プリミティブを生成することを含み得る。

[0146] 第１の実施形態では、停止確認プリミティブは、ＷＵＲ走査プロセス及び／又は非ＷＵＲ走査プロセス等の走査プロセスの成功裏の終了を示すために使用され得るMLME-WURSCAN-STOP.confirmプリミティブであり得る。第２の実施形態では、停止確認プリミティブは、MLME-SCAN-STOP.confirmプリミティブ又はMLME-SCAN-STOP.confirmプリミティブの一部であり得る。MLME-SCAN-STOP.confirmプリミティブは、MLME-WURSCAN-STOP.Confirmと同様に使用することができる。第３の実施形態では、停止確認プリミティブは、上記のMLME-WURSCAN.confirmプリミティブ又はMLME-SCAN.confirmプリミティブであり得る。即ち、MLME-WURSCAN.confirmプリミティブ又はMLME-SCAN.confirmプリミティブは、MLME-WURSCAN-STOP.confirmの同じ目的で使用することができる。

[0147] 以下の説明は、本願によるｅＢＣＳサービスのサポートについて記載する。

[0148] 関連付けられていないＷＴＲＵのためのブロードキャストサービスをサポートする必要がある。加えて、現在のＷＬＡＮ規格におけるアップリンクブロードキャストサービスが必要である。関連付けられていないＷＴＲＵ又は受信限定であり、伝送することができないＷＴＲＵのためのダウンリンクブロードキャストサービスをサポートするための設計が必要である。加えて、ＷＴＲＵによる１つ又は複数のＡＰへのアップリンクブロードキャストのための設計が必要である。ＷＴＲＵのアソシエーション状態に関係なくＷＴＲＵをサポートするために、且つ非ＡＰ ＷＴＲＵによる１つ又は複数のＡＰへのアップリンクブロードキャストサービスをサポートするために、ブロードキャストサービスプロトコル及びシグナリングを設計することができる。

[0149] 本願によるブロードキャストサービスサポートのメカニズムを本明細書に記載する。dot11eBCSImplemented及び／又はdot11eBCSActivatedを有するＷＴＲＵ（例えば、ＡＰ又は非ＡＰ ＳＴＡ）は、自らのビーコン内又はＷＴＲＵが伝送するプローブ要求／回答及び／（再）アソシエーション要求／回答フレーム内にｅＢＣＳ要素を含め得る。一例では、ｅＢＣＳ要素は、アップリンク（ＵＬ）及び／又はダウンリンク（ＤＬ）ブロードキャスト情報内に含めることができる。別の例では、ＵＬブロードキャスト情報内にＵＬ ｅＢＣＳ要素を含めることができ、及び／又はＤＬブロードキャスト情報内にＤＬ ｅＢＣＳ要素を含めることができる。本願では、別段の定めがない限り、ＤＬブロードキャスト要素、ＤＬ ｅＢＣＳ要素及びＤＬブロードキャスト機能要素という用語は、区別なく使用され得ることに留意すべきである。

[0150] ＤＬブロードキャスト要素又はＤＬ ｅＢＣＳ要素の設計例を図３に示す。ＤＬブロードキャスト要素は、以下のフィールドの例：要素ＩＤ、長さ、要素ＩＤエクステンション及び／又はＮ個のｅＢＣＳフィールドを含むＤＬブロードキャスト機能の何れか１つ又は複数を含み得る。要素ＩＤと要素ＩＤエクステンションとの組み合わせは、ＤＬブロードキャスト要素又はＤＬ ｅＢＣＳ要素として現在の要素を識別し得る。長さフィールドは、ＤＬブロードキャスト要素の長さを示し得る。

[0151] ＤＬブロードキャスト機能は、Ｎ個（即ちｅＢＣＳ１～ｅＢＣＳ Ｎ）のフィールドを含むことができ、それにより、各フィールドは、伝送側ＷＴＲＵ（例えば、伝送側ＡＰ）によって提供される特定のブロードキャストサービスを指定するために使用され得る。各ｅＢＣＳフィールドは、以下のサブフィールドの例：ブロードキャストサービスＩＤ、ｅＢＣＳタイプ、アソシエーション要求、ＵＬ伝送要求、ブロードキャストレート、ブロードキャスト周波数、ブロードキャスト符号化、ブロードキャスト制御、ブロードキャストパラメータ及び／又はブロードキャスト状態の何れか１つ又は複数を含み得る。上述のサブフィールドを下記の通り更に説明する。

[0152] ブロードキャストサービスＩＤサブフィールドは、ブロードキャストサービスのＩＤを示すことができる。ｅＢＣＳタイプサブフィールドは、ブロードキャストサービスの種類（例えば、ｅＢＣＳがＵＬであるか若しくはＤＬであるか、又はブロードキャストサービスが自動車、道案内、緊急、サポート、情報提供及び／又はイベントサポートのカテゴリのものであるかどうか）を含み得る。一例では、伝送側ＷＴＲＵによって何れの種類のブロードキャストサービスが提供されるかを示すために、ＤＬブロードキャスト要素内にビットマップを含めることができる。種類は、マルチＡＰブロードキャストであり得る。別の例では、Organizationally Unique Identifier（ＯＵＩ）によってブロードキャストの種類が識別され得る。アソシエーション要求サブフィールドは、１つ又は複数のブロードキャストサービス（例えば、ブロードキャストサービスＩＤによって識別されるブロードキャストサービス）を消費するためにアソシエーションが必要であるかどうかを示し得る。

[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] 図５及び図６は、連続的に増加する増分を伴うＬＤＰＣフレーム間符号化の例を示す。図５に示すように、ＬＤＰＣフレーム間符号化手順は、ＬＤＰＣ符号化手順内で短縮ビットを破棄し、長さNmaxを有するパケットをもたらすことによってデータビット及びパリティビットが構築された後に開始され得る。図５に示すレートＲＨフレームは、Ｎビット含むことができ、Ｄの（不）均等増分は、Δ１～ΔＤのＤ個の増分サブフレームを含み得る。

[0180] Nmaxは、送信されるパケットの長さ（Ｎ）、増分サブフレームの数（Ｄ）及びその対応する長さ（Δ_ｉ）に基づいて決定され得る。

が成立するように、各増分サブフレームは、異なる長さに設定することができる。各増分サブフレームの長さが同一である場合、Nmax＝Ｎ＋ＤΔ_ｉが成立する。各フレームの元の伝送は、（図５に示すように）Ｎビットであるのに対して、増分サブフレーム（例えば、Δ１～ΔＤ）は、追加の（非パンクチャード）パリティビットで構成され得る。図６に示す例では、増分のインデックスは、ランダムであり得、且つ順に増加しなくてもよい。

[0181] 図７は、ＢＣＣフレーム間符号化の一例を示す。ＢＣＣフレーム間符号化の場合、ＢＣＣ伝送に関して、各フレームの元の伝送は、Ｎの非パンクチャードビット（例えば、図７に示すＮビット）を有し、増分サブフレーム（例えば、図７に示すΔ１及びΔ２）は、他のパンクチャードビットで構成され得る。図７に示すように、ソースデータは、ｘ０、ｘ１、ｘ２、ｘ３及びｘ４を含むことができ、符号化データは、Ａ０～Ａ４及びＢ０～Ｂ４を含むことができ、ＢＣＣのための不均等な増分を有する１つのレートＲＬフレームは、（Ａ０、Ｂ０、Ａ１、Ｂ２、Ａ３、Ｂ４を含む）Ｎビット、（Ｂ１、Ａ２及びＢ３を含む）Δ１及びΔ２（Ａ４及びＡ０）を含み得る。

[0182] フレーム間ＢＣＣ／ＬＤＰＣ伝送及びＢＣＣ／ＬＤＰＣコードのための部分的なパケットのＨＡＲＱに関する手順を定めることができる。図８は、固定インデックスを伴うフレーム間符号化及び部分的ＨＡＲＱの一例を示す。ＡＰは、ＮＴ＋Ｄフレーム（即ちＮＴフレーム及びＤフレーム）の伝送を定めることができる。最初のＮＴ伝送（即ち１－ＮＴ）は、各フレームのＮビットで構成されるフレーム内符号化フレームである。図８に示すように、フレーム内符号化は、１フレーム～ＮＴフレームのＮＴ個のフレームを含む。最後のＤの伝送は、各フレームからのＤの増分の組み合わせで構成されるフレーム間符号化サブフレームである。

[0183] 一実施形態では、各フレームのＤのサブフレームの増分を連結し、その後、伝送することができる。それにより、部分的なＨＡＲＱの伝送が可能になる。別の実施形態では、各フレームのＤの増分は、特定の符号化方式を使用して線形符号化され得る。

[0184] 伝送されるフレームごとに、以下の情報：フレーム内又はフレーム間符号化、フレーム内符号化フレームのインデックス、フレーム間符号化フレームのインデックス（以下の例では、これは、デルタ（ａ，ｂ）内のインデックスａであり得、及び／又は全伝送の開始後にフレームインデックスに基づいて明示的にシグナリングすることができるか若しくは暗黙的に識別することができる）又は増分サブフレーム内に符号化されるフレームのインデックス（以下の例では、これは、デルタ（ａ，ｂ）内のインデックスｂであり得、及び／又は伝送におけるフレーム数に基づいて明示的にシグナリングすることができるか若しくは暗黙的に識別することができる）の１つ又は複数を（例えば、ＰＬＣＰヘッダ内で）シグナリングすることができる。インデックスのサイズが異なり得る事例では、増分サブフレーム内の各フレームからの増分のサイズをシグナリングすることができる。

[0185] 図９は、スライディングウィンドウを伴うフレーム間符号化及び部分的ＨＡＲＱの一例を示す。図９に示すように、増分サブフレームは、伝送フレーム上に（例えば、集約ＰＰＤＵとして）集約することができる。例えば、各フレームは、自らの前のフレームから増分サブフレームの最大数まで増分サブフレームを集約することができる。図９に示すように、フレーム２は、フレーム１からの第１の増分サブフレーム（即ちΔ１，１）を集約する。フレーム３は、フレーム２からの第１の増分（Δ１，２）と共にフレーム１からの第２の増分（即ちΔ２，１）を集約する。フレーム４は、フレーム１、２及び３からの増分を集約する。Ｄの値（増分数）が３であるため、フレーム５は、フレーム２、３及び４からの増分を集約する。

[0186] 図１０に示すように、伝送される増分は、動的に選択することができる。例えば、この手法は、不完全に受信されているフレームに対してＷＴＲＵからフィードバックがあり得る場合に使用することができる。ブロードキャストＡＰは、増分情報を伝送するために特定のフレームを動的に選択することができる。必要とされるブロードキャスト信号の品質に基づき、ブロードキャストＡＰは、送信される増分のサイズを動的に選択することができる（一部のフレームは、他のフレームよりも保護を必要とし得る）。一例では、特定のフレームが非常に不完全に受信されたことをＷＴＲＵフィードバックが示す。例えば、フレームが不完全に受信されたことを（選ばれた）ＷＴＲＵの殆どが示す場合、そのＷＴＲＵは、更に多くの情報を必要とし得る。別の例では、前に送信されている可能性があるフレームがより速く復号されることを確実にするために、ＷＴＲＵは、それらのフレームに関する更に多くの情報を送信して、全体的なレイテンシを減らすことができる。

[0187] ＷＴＲＵの手順は、フレーム間符号化の一部として定めることができる。ＷＴＲＵ手順の一例の一部として、ＡＰ及びＷＴＲＵは、フレーム間符号化を受信する能力に関する機能情報を交換することができる。機能情報は、同時に復号することができる最大フレーム数を含み得る。ＡＰは、この機能情報を使用して、ブロードキャストチャネルのためのフレーム間符号化パラメータを決定することができる。例えば、ＡＰは、同時フレーム数を、全ての受信側ＷＴＲＵによって示される最小値（例えば、離散所定値の組及び／又はＷＴＲＵ固有）に設定することができる。ＷＴＲＵは、フレームを受信し、受信したＰＬＣＰヘッダを復号することができる。ＷＴＲＵは、受信フレームがフレーム間符号化されていることを識別することができる。ＷＴＲＵは、パケットがフレーム内、フレーム間又はその両方の何れであるかを識別することができる。パケットがフレーム内符号化されている場合、ＷＴＲＵは、フレームを復号することができる。復号に成功した場合、ＷＴＲＵは、要求に応じてＡＰにＡＣＫを送信し、及び／又はそのフレームの復号手順を終了することができる。復号に失敗した場合、ＷＴＲＵは、フレームをバッファ内に記憶することができる。

[0188] パケットがフレーム間符号化されている場合、ＷＴＲＵは、フレーム内の増分サブフレームを復号／インタリーブ解除／集約解除することができる。ＷＴＲＵは、明示的又は暗黙的なシグナリングに基づいて増分サブフレームを識別することができる。ＷＴＲＵは、成功裏に復号されている全てのフレームの増分サブフレームを破棄することができる。ＷＴＲＵは、受信した増分サブフレームの情報を既存のフレームバッファに追加し、結果を復号することにより、復号されていない全てのフレームの増分サブフレームを処理することができる。復号に成功した場合、ＷＴＲＵは、要求に応じてＡＰにＡＣＫを送信し、及び／又はそのフレームの復号手順を終了することができる。復号に失敗した場合、ＷＴＲＵは、フレームをバッファ内に記憶することができる。ＷＴＲＵは、ＡＰにＮＡＫを送信するか、又はＮＡＫを送信する前に増分サブフレームの総数が受信されるまで待つことができる。チャネルがブロードキャストチャネルであるため、ＡＣＫ／ＮＡＫ伝送は、伝送先の全てのＷＴＲＵではなく、特定のＷＴＲＵに対するＡＰによる要求に基づき得る。一例では、ＷＴＲＵは、特定の（サブ）チャネル上でＡＣＫ／ＮＡＫを送信することができ、成功／失敗があることをサブチャネル上の信号の存在がＡＰに知らせ得る。

[0189] フレーム内符号化及びフレーム間符号化の両方がパケットに行われている場合、ＷＴＲＵは、フレーム内パケットをフレーム間パケットと分け、上記の手法を使用してそれぞれを別々に処理することができる。

[0190] ＨＡＲＱブロードキャストでは、ブロードキャストフレームは、複数回又は反復的に伝送され得る。手順の一例では、受信機が受信を容易に組み合わせることができるように、反復される伝送が元の伝送と同じであり得る。受信側ＷＴＲＵが受信フレームを組み合わせることを可能にするためにシグナリングを使用することができる。以下の情報（フィールド）：ＩＤ、ブロードキャスト、反復伝送、反復インデックス、次の反復フレーム又は次の反復ビーコンの１つ又は複数を例えばＰＬＣＰヘッダ、ＭＡＣヘッダ、ＭＡＣ本体及び／又はビーコンフレーム内に含めることができる。上述のフィールドを下記の通り更に説明する。

[0191] ＩＤフィールドは、宛先ＩＤ、ソースＩＤ、送信機ＩＤ、受信機ＩＤ、ブロードキャストＩＤ、ブロードキャストチャネルＩＤ及び／又はコンテンツＩＤの何れかを示し得る。ブロードキャストフィールドは、それがブロードキャストフレームであるか、マルチキャストフレームであるか及び／又はユニキャストフレームであるかを示すために使用され得る。反復伝送フィールドは、そのフレームが反復的な方法で伝送されるかどうかを示すために使用され得る。反復伝送フィールドは、使用されている反復の種類（例えば、単純な反復又はフレーム間符号化）も示すことができる。

[0192] 反復インデックスフィールドは、現在の伝送の反復の数を示し得る。例えば、反復インデックスフィールドは、増加する方法で伝送することができる。別の例では、続いて起こる可能性がある反復伝送の数を受信側ＷＴＲＵが知ることができるように、反復インデックスフィールドは、減少する方法で伝送することができる。次の反復フレームフィールドは、フレームの次の反復の期待時間を示すことができる。次の反復フレームフィールドは、その時点において送信される反復フレームの種類も示すことができる。次の反復ビーコンフィールドは、次の反復ビーコンの期待時間を示すことができる。一例では、期待時間は、持続時間であり得る。

[0193] 一実施形態では、幾らかのダイバーシティ方式を用いて、ブロードキャストフレームを複数回又は反復方法内で伝送することができる。例えば、反復伝送は、元の伝送と同じでなくてもよい。この場合、以下の手法の１つ又は複数を使用することができる。

[0194] 第１の手法では、異なる反復に異なるビットインタリーバを使用することができる。ビットインタリーバは、ＢＣＣ符号器とコンステレーションマッパとの間で使用することができる。一例では、複数のビットインタリーバを定めることができる。例えば、ビットインタリーバの数は、許容された最大反復回数と同じであり得る。この場合、１回の反復に１つのインタリーバを使用することができる。別の例では、固定数のインタリーバを定めることができる。反復に対するインタリーバインデックス間のマッピングは、関数によって定めることができる。例えば、モジュラー関数を使用することができる。ｋ番目の反復に使用されるインタリーバインデックスをInterleaver_ID=mod(k,N)として定めることができ、但し、Ｎは、定められるインタリーバの最大数である。ビットインタリーバは、ＬＤＰＣコードに使用してもしなくてもよい。手法の一例では、反復伝送のためにビットインタリーバを定めることができる。

[0195] 第２の手法では、異なる反復に異なるシンボルインタリーバを使用することができる。例えば、コンステレーションマッパの直後にシンボルレベルインタリーバを使用することができる。シンボルレベルインタリーバを使用することは、ＯＦＤＭシンボル間で変調シンボルを分散させるためであり得る。一例では、固定数のシンボルインタリーバを定めることができる。反復に対するインタリーバインデックス間のマッピングは、関数によって定めることができる。例えば、モジュラー関数を使用することができる。ｋ番目の反復に使用されるシンボルインタリーバインデックスをInterleaver_ID=mod(k,N)として定めることができ、但し、Ｎは、定められるシンボルレベルインタリーバの最大数である。

[0196] 第３の手法では、異なる伝送に異なる冗長バージョン（ＲＶ）を使用することができる。異なるＲＶは、異なるコード化ビットのサブセットに対応し得る。反復に対するＲＶインデックス間のマッピングは、関数によって定めることができる。例えば、モジュラー関数を使用することができる。ｋ番目の反復に使用されるＲＶインデックスをRV_ID=mod(k,N)として定めることができ、但し、Ｎは、定められるＲＶの最大数である。

[0197] ダイバーシティブロードキャスト伝送は、ＰＬＣＰヘッダ若しくはＭＡＣヘッダ又はＭＡＣ本体内でシグナリングすることができ、以下のフィールドの例：ＩＤ、ブロードキャスト、反復伝送、最大反復回数、反復インデックス、伝送インデックス又は次の反復ビーコン／タイミングの１つ又は複数を含み得る。上述のフィールドの例を下記の通り更に説明する。

[0198] ＩＤフィールドは、宛先ＩＤ、ソースＩＤ、送信機ＩＤ及び／又は受信機ＩＤを示し得る。ブロードキャストフィールドは、それがブロードキャストフレームであるか、マルチキャストフレームであるか及び／又はユニキャストフレームであるかを示すために使用され得る。反復伝送フィールドは、そのフレームが反復的な方法で伝送されるかどうかを示すために使用され得る。最大反復回数フィールドは、期待される最大反復回数を示し得る。反復インデックスフィールドは、現在の伝送の反復伝送の数を示し得る。一例では、反復インデックスフィールドは、カウントアップ式に伝送することができる。別の例では、従う反復伝送の数を受信側ＷＴＲＵが知ることができるように、反復インデックスフィールドは、カウントダウン式に伝送することができる。

[0199] 伝送インデックスフィールドは、次の伝送において使用されるビットレベルインタリーバインデックス、シンボルレベルインタリーバインデックス及び／又はＲＶインデックスをシグナリングするために使用することができる。次の反復ビーコン／タイミングフィールドは、次の反復ビーコン／タイミングの期待時間を示すことができる。一例では、期待時間は、持続時間であり得る。この持続時間は、各ＷＴＲＵが各伝送を独立に復号できるようにするためのＷＴＲＵの機能の関数であり得る。別の例では、期待時間は、即座であり得、これは、現在の伝送が完結してからフレーム間間隔（ｘＩＦＳ）の持続時間が経過した後に次の反復が行われることを示す。

[0200] ブロードキャストサービス（ＢＣＳ）の受信を伴う省力化のための手順を使用することができる。ＷＴＲＵは、反復ＩＤと共にＰＬＣＰヘッダを受信することができる。一例では、ＰＬＣＰヘッダは、総反復回数及び反復インデックスを含み得る。ＷＴＲＵは、全ての反復を保存し、最後の受信後に復号することができる。ＷＴＲＵは、各反復後に復号することができる。ＡＰとＷＴＲＵとは、各反復後のパケットの復号を可能にするための反復間の最小持続時間をネゴシエートすることができる。

[0201] ＷＴＲＵがパケットを復号した場合、伝送の持続時間にわたり、ＷＴＲＵは、スリープに入ることができる。図１１は、ＢＣＳに使用することができる、反復間のｘＩＦＳフレーム間間隔を伴う省力化手順の一例を示す。例えば、図１１に示すように、ＷＴＲＵ１は、Ｔｘ１中にパケットを復号し、Ｔｘ４までスリープすることができる。

[0202] ＷＴＲＵがパケットを復号し、反復間の持続時間が即座である場合、ＷＴＲＵは、特定の反復の持続時間にわたってスリープに入ることができる。図１２は、ＢＣＳに使用することができる、反復間の特定のタイミング差を伴う省力化手順の一例を示す。例えば、図１２に示すように、ＷＴＲＵ１は、Ｔｘ１中にパケットを復号し、Ｔｘ２、Ｔｘ３及びＴｘ４中にスリープすることができる。

[0203] 一実施形態では、フィードバックに基づく反復伝送を使用することができる。反復伝送の最大数は、予め定めることができるか、又は（再）決定され得る。反復伝送の最大数は、ビーコンフレーム、（再）アソシエートフレーム、プローブ要求／回答フレーム又は他の任意の種類の管理／制御フレーム内で運ばれ、シグナリングされ得る。ＷＴＲＵ（例えば、ＡＰ ＷＴＲＵ又は非ＡＰ ＷＴＲＵ）は、反復伝送の最大数に常に達しなくてもよい。ＷＴＲＵは、フィードバックに基づいて反復伝送を終了することができる。例えば、ＷＴＲＵがＷＴＲＵから離れている可能性がある別のＷＴＲＵから肯定応答（ＡＣＫ）を受信する場合、ＷＴＲＵは、反復を停止することができる。

[0204] 一実施形態では、反復伝送を少なくとも既定のフレーム間間隔ｘＩＦＳによって隔てることができる。ある方法では、ｘＩＦＳは、短フレーム間間隔（ＳＩＦＳ）又は分散フレーム間間隔（ＤＩＦＳ）よりも大きいことができる。一実施形態では、各再伝送間のフレーム間間隔は、動的及び構成可能であり得る。受信側ＷＴＲＵは、反復ブロードキャスト伝送を成功裏に受信した場合、ある条件下で肯定応答を返すことができる。ブロードキャスト側ＷＴＲＵが次の反復を伝送する前に応答を受信することができるように、応答は、次の反復よりも前に伝送することができる。ブロードキャスト側ＷＴＲＵは、反復伝送を終了し得るかどうかを判定することができる。一実施形態では、ＷＴＲＵ群が応答を伝送することを許可され得る。例えば、ブロードキャスト側ＷＴＲＵは、自らから遠く離れている可能性があるＷＴＲＵ群を決定することができる。ブロードキャスト側ＷＴＲＵは、そのＷＴＲＵ群が反復ブロードキャスト伝送間に肯定応答を伝送することを許可され得ることを管理フレーム又は制御フレーム内で示すことができる。受信機側で整列させることができ、受信機が復号可能であり得るように、ＷＴＲＵ群は、全く同じ応答を同時に応えて伝送することができる。

[0205] 一実施形態では、反復伝送前又は後にポーリングフレーム又はＭＵ－ＢＡＲフレームを伝送することができる。代わりに、ＮＤＰトリガフレームをブロードキャストフレームと集約することができる。ポーリングフレーム、ＭＵ－ＢＡＲフレーム又はＮＤＰトリガフレームは、１つ又は複数のＷＴＲＵからの応答伝送をトリガし得る。ポーリング又はトリガされ得る受信側ＷＴＲＵは、反復ブロードキャスト伝送を成功裏に受信した場合に肯定応答を返すことができる。ブロードキャスト側ＷＴＲＵは、肯定応答を受信し、反復伝送を終了し得るかどうかを判定することができる。

[0206] ブロードキャスト側ＷＴＲＵは、反復を終了し得るかどうかを判定することができる。又は、ブロードキャスト側ＷＴＲＵが反復を終了し得るかどうかをブロードキャスト側ＷＴＲＵ又はＡＰが構成することができる。一実施形態では、関連付けられたＷＴＲＵ又は関連付けられていないＷＴＲＵをブロードキャストフレームが標的とし得るかどうかに構成が基づき得る。フレームが関連付けられていないＷＴＲＵに伝送され得る場合又はそれらの関連付けられていないＷＴＲＵに部分的に伝送され得る場合、ブロードキャスト側ＷＴＲＵは、反復伝送を早期に終了しなくてもよい。

[0207] 最大反復回数は、ＡＰによって決定され得るか、又は他の方法で指定され得る。ＡＰは、自らのビーコン、アソシエーション要求／回答、プローブ要求／回答フレーム又は他の種類の制御／管理フレーム内で最大反復回数をブロードキャストすることができる。一実施形態では、ＢＳＳのカバレッジ範囲が広い可能性がある場合又は多くのセル端ＷＴＲＵをＡＰが知っている可能性がある場合、ＡＰは、より大きい最大反復回数を使用することを決めることができる。その他の場合、ＡＰは、より小さい最大反復回数を使用することができる。図１３は、フィードバックを伴う反復伝送の一例を示す。図１３に示すように、ＷＴＲＵ１は、Ｔｘ１中にＡＰから伝送を受信しているが、ＷＴＲＵ２及びＷＴＲＵ３は、伝送を受信していない。従って、ＷＴＲＵ２及びＷＴＲＵ３は、ＡＰにＮＡＫを送信することができる。次いで、Ｔｘ２中に伝送の反復を行うことができる。その後、ＷＴＲＵ２は、伝送を成功裏に受信している。しかし、ＷＴＲＵ３は、受信していない。その後、Ｔｘ３中に伝送の反復を行うことができる。その後、ＷＴＲＵ３は、伝送を成功裏に受信する。

[0208] 一実施形態では、信頼性を得るためにマルチＡＰブロードキャスト伝送を使用することができる。ＷＴＲＵは、単一又は複数のＡＰと関連付けることができる（関連付けられたＷＴＲＵ）。ＡＰは、ブロードキャストのためにＡＰの組に送出することができる（関連付けられたＷＴＲＵ及び関連付けられていないＷＴＲＵ）。ＡＰは、ブロードキャスト資源を識別することができる（例えば、全帯域、定められたＲＵ）。ＡＰは、ブロードキャストチャネル（ＢＣ）伝送方式を送出することができる。例えば、ＡＰは、ＡＰのＩＤ、対応するシフト及び／又は循環プレフィックス（ＣＰ）のインジケーションと共に循環シフトダイバーシティ（ＣＳＤ）を送信することができる。ＡＰは、同じシフト及びＣＰと共にＣＳＤを送信することができる。ＡＰは、時間スロットに基づく伝送を送信することができる（例えば、タイミングインデックスを伴う時間シフト）。ＡＰは、「ＪＴ」法を使用することができる（例えば、サフィックスツリークラスタリング（ＳＴＣ）の方法及びインデックス）。図１４は、ＣＳＤを伴うマルチＡＰブロードキャストの一例を示す。図１５は、タイミング分離を伴うマルチＡＰブロードキャストの一例を示す。図１６は、空間伝送ダイバーシティ方式（例えば、空間時間ブロックコード（ＳＴＢＣ））を伴うマルチＡＰブロードキャストの一例を示す。

[0209] 一実施形態では、ブロードキャスト／マルチキャストフレームに反復伝送を使用することができる。例えば、ブロードキャスト／マルチキャストフレームのための反復伝送は、様々な自己復号可能ＲＶ、様々なビットレベルインタリーバ、様々なシンボルレベルインタリーバ（サブキャリアマッピングの変更と等価）と共に、及び／又はブロードキャスト、ＰＡＩＤ（例えば、アソシエーションＩＤ）、ＲＶ、ＨＡＲＱ、インタリーバＩＤ及び／又は次のタイミングを示すＳＩＧと共に使用することができる。

[0210] 一実施形態では、フィードバックに基づく反復伝送を使用することができる。例えば、反復伝送は、少なくとも固定された持続時間（例えば、ｘＩＦＳ）によって隔てることができる。ｘＩＦＳは、ＳＩＦＳ又はＤＩＦＳよりも大きいことができる。フィードバックに基づく反復は、ポーリング／マルチユーザブロックＡＣＫ要求（ＭＵ－ＢＡＲ）を使用することを含み得る。伝送が成功裏に復号される場合、一部のＷＴＲＵは、次の反復前に応答を伝送して返すことを許可され得る。一実施形態では、予め選択された遠く離れたＷＴＲＵが（例えば、802.11ayにおける近遠手順を使用して）応答を伝送し得る。一部の事例では、応答を成功裏に受信するＡＰは、伝送を終了することができる。ＡＰは、関連付けられていないＷＴＲＵに対して完全な反復を周期的に完了することができる。（関連付けられたＷＴＲＵのための）ＢＣＳ伝送パラメータは、汎用化することができ、及び／又は関連付けられていない／非伝送ＷＴＲＵに関してＴＣＰ／ＩＰをプローブ要求によって構成することができる。ＡＣＫは、ＷＴＲＵ、ＷＴＲＵ群、ヌルデータパケット（ＮＤＰ）フィードバックレポート及び／又はランダムアクセスＭＵを指定することができる。

[0211] 送信されているフレームについて自動反復（ＡＲ）が構成された状態又は構成されていない状態で、ＡＰのサブネットが複数のＡＰから同じブロードキャスト情報を送信するように構成される場合、それらの伝送フレームを受信するＷＴＲＵは、同じブロードキャストデータを含むフレーム又はブロードキャストデータの増分冗長性バージョンを識別できなければならない。その場合、ＷＴＲＵは、適切な場合、フレームを組み合わせることによって又は既に受信しているデータを含む冗長フレームを無視することによってブロードキャストデータの自らの受信を改善することができる。ＡＲが単純な反復（複数のＡＰから同じフレームの冗長バージョンを送信すること）である場合、ＷＴＲＵは、冗長フレームを無視するために、データを既に受信しているかどうか又はデータを受信していないかどうかを知る手段を有さなければならない。データを受信することができる可能性を高めるために、ＷＴＲＵは、フレームをどのように組み合わせるかを知るべきである。ＡＲが増分冗長性（ＩＲ）フレームを有する事例では、ＷＴＲＵは、増分冗長フレームをどのように組み合わせるべきか、同一データを有するフレームをどのように組み合わせるべきか、及び既に受信しているデータを含むフレームをどのように無視すべきかを知る手段を有さなければならない。現在、様々なＡＰによって送信されているフレームが同じブロードキャストデータ又はＷＴＲＵが受信しようとしているデータのＩＲバージョンを含むことをＷＴＲＵに知らせる方法はない。

[0212] 以下の説明は、上記で論じた問題に対処するためのサブネットスケジューリングについて記載する。

[0213] 複数のＡＰから同じ情報をブロードキャストするようにＡＰのサブネットを構成することができる。かかるサブネットは、複数のＡＰからのブロードキャストがブロードキャストデータを含むことをＷＴＲＵに知らせる方法を使用することができる。各ＡＰは、固有の伝送源であるため、複数の方法が用いられ得る。ブロードキャストデータをＷＴＲＵに知らせる方法の一例では、ＡＰのサブネットが協調して同じブロードキャストＩＤ情報を使用することができる。ＡＰは、ブロードキャストＩＤ情報を提供するために、（例えば、ＰＬＣＰヘッダ、ＭＡＣヘッダ、ＭＡＣ本体及び／又はビーコンフレーム内の）以下の情報フィールド：マルチＡＰインジケータ、サブジェクトＩＤ、ＩＤ、ブロードキャスト、反復伝送、反復インデックス、次の反復フレーム又は次の反復ビーコンの１つ又は複数を使用することができる。上述のフィールドを下記の通り更に説明する。

[0214] マルチＡＰインジケータフィールドは、フレーム及びその関連ＩＤが複数のＡＰによってブロードキャストされていることを示し得る。サブネットＩＤフィールドは、サブネットの一意ＩＤを与えることができ、サブネット内の全てのＡＰは、同じ識別子を使用することができる。重複するサービス領域を有する異なるサブネットが一意のサブネットＩＤを有することを確実にするために、サブネットは、協調することができる。一例では、サブネットＩＤは、サブネット内のＡＰの１つのＭＡＣアドレスに基づき得る。別の例では、ＳＳＩＤのハッシュ、ＡＰの位置に基づくハッシュ、ネットワーク／サブネット管理者によって割り当てられる一意のサブネットＩＤ又は他の任意の一意ＩＤが使用され得る。

[0215] ＩＤフィールドは、宛先ＩＤ、ソースＩＤ、送信機ＩＤ、受信機ＩＤ、ブロードキャストＩＤ、ブロードキャストチャネルＩＤ及び／又はコンテンツＩＤを示し得る。ブロードキャストフィールドは、それがブロードキャストフレームであるか、マルチキャストフレームであるか及び／又はユニキャストフレームであるかを示すために使用され得る。反復伝送フィールドは、そのフレームが反復的な方法で伝送されるかどうかを示すために使用され得る。反復伝送フィールドは、使用されている反復の種類（例えば、単純な反復又はフレーム間符号化）も示すことができる。

[0216] 反復インデックスフィールドは、現在の伝送の反復伝送の数を示し得る。一実施形態では、反復インデックスフィールドは、カウントアップ式に伝送することができる。別の例では、従う反復伝送の数を受信側ＷＴＲＵが知ることができるように、反復インデックスフィールドは、カウントダウン式に伝送することができる。次の反復フレームフィールドは、フレームの次の反復の期待時間を示すことができる。次の反復フレームフィールドは、その時点において送信される反復フレームの種類も示すことができる。次の反復ビーコンフィールドは、次の反復ビーコンの期待時間を示すことができる。一例では、期待時間は、持続時間であり得る。

[0217] ＡＰは、協調し、サブネット内のＡＰの全てがブロードキャスト（例えば、特定のブロードキャスト又は特定のブロードキャストの組）に使用する仮想ＳＳＩＤ及び／又はＭＡＣアドレスを選択することができる。サブネット内のＡＰは、全て同じＳＳＩＤ情報（例えば、仮想ＳＳＩＤ及び／又はＭＡＣアドレス）を伝送することができる。同じＳＳＩＤ情報を伝送することにより、サブネット内のＡＰによって送信されるブロードキャストフレームを受信する何れのＷＴＲＵにも、それらのＡＰが単一のブロードキャストＡＰのように見える。仮想ＳＳＩＤ及び／又はＭＡＣアドレスを使用するＡＰは、ブロードキャストＩＤ情報を提供するために（例えば、ＰＬＣＰヘッダ、ＭＡＣヘッダ、ＭＡＣ本体及び／又はビーコンフレーム内の）以下の情報フィールド：仮想ＳＳＩＤインジケータ、仮想ＭＡＣアドレス、ＩＤ、ブロードキャスト、反復伝送、反復インデックス、次の反復フレーム及び／又は次の反復ビーコンの１つ又は複数を使用することができる。上述のフィールドを下記の通り更に説明する。

[0218] 仮想ＳＳＩＤインジケータフィールドは、ＳＳＩＤが仮想ＳＳＩＤであることを示す単一ビットであり得るか、又は示されている仮想ＳＳＩＤの種類に関する情報を提供する複数のビットであり得る。仮想ＭＡＣアドレスフィールドは、ＡＰのＭＡＣアドレスが仮想ＭＡＣアドレスであることを示す単一ビットであり得るか、又は示されている仮想ＭＡＣアドレスの種類の情報を提供する複数のビットであり得る。

[0219] ＩＤフィールドは、宛先ＩＤ、ソースＩＤ、送信機ＩＤ、受信機ＩＤ、ブロードキャストＩＤ、ブロードキャストチャネルＩＤ及び／又はコンテンツＩＤを示し得る。ブロードキャストフィールドは、それがブロードキャストフレームであるか、マルチキャストフレームであるか及び／又はユニキャストフレームであるかを示すために使用され得る。反復伝送フィールドは、そのフレームが反復的な方法で伝送されるかどうかを示すために使用され得る。反復伝送フィールドは、使用されている反復の種類（例えば、単純な反復又はフレーム間符号化）も示すことができる。

[0220] 反復インデックスフィールドは、現在の伝送の反復伝送の数を示し得る。一実施形態では、反復インデックスフィールドは、カウントアップ式に伝送することができる。別の例では、従う反復伝送の数を受信側ＷＴＲＵが知ることができるように、反復インデックスフィールドは、カウントダウン式に伝送することができる。次の反復フレームフィールドは、フレームの次の反復の期待時間を示すことができる。次の反復フレームフィールドは、その時点において送信される反復フレームの種類も示すことができる。次の反復ビーコンフィールドは、次の反復ビーコンの期待時間を示すことができる。一実施形態では、期待時間は、持続時間であり得る。

[0221] ＵＬブロードキャストの信頼性を得るための手順を使用することができる。ＤＬブロードキャストでは、複数の送信機及び受信機がある場合があり、各受信機は、非ＡＰ ＷＴＲＵ内に位置するブロードキャストサービスエンドポイントを表し得る。これは、ブロードキャストデータのためのＭＡＣ層のＣＳＭＡ／ＡＲＱプロトコルを複雑にする可能性があり、なぜなら、異なる送信機－受信機の対は、異なる成功／失敗状態を有し得るからである。例えば、ＡＰは、ＵＬ方向のフィードバック資源を割り当てるために、（関連付けられていない）ブロードキャスト受信機の識別情報を知る必要があり得る。更に、ＡＰは、再伝送を試行する前に少なくとも１つのＷＴＲＵについて何れのＭＡＣ ＰＤＵ（ＭＰＤＵ）／データブロックが欠落しているかを知るためにそれらのＡＰ間で協調する必要があり得る。

[0222] ＵＬブロードキャストの信頼性も問題になり得る。図１７に示すように、ＵＬ ＷＴＲＵ１７０１は、受信機の状態（又はある持続時間にわたる受信済みの物理層収束手順（ＰＬＣＰ）プロトコルデータ単位（ＰＰＤＵ）の統計）を認識しておらず、それは、「ＷＴＲＵが、上位の入力なしにＰＰＤＵが成功しているかどうかの情報を有するか？」として示されている。伝送データに関する要件の一例は、ロストデータが許容不能であり、ロストデータについて再伝送が必要であることであり得る。この場合、再伝送をトリガするためのユニキャストデータ接続を有するために、802.11プロトコル層における知識なしに、ＵＬ ＷＴＲＵ１７０１は、ＢＳＳとのアソシエーション（又は別のアクセスへの接続）を有さなければならない場合がある。伝送データに関する要件の別の例は、ロストデータが許容可能であるが、不所望であることであり得る。この場合、将来伝送されるＰＰＤＵの品質を受信機からのフィードバックが改善し得る。

[0223] ＵＬブロードキャストでは、ＵＬブロードキャストパケットの異なる受信機が単一のブロードキャストエンドポイントを表し、送信機は、１のみある（即ち単一の送信機が作用する単一の（結合）受信機状態がある）。これは、ＵＬ内でＭＡＣ層ＣＳＭＡ／ＡＲＱプロトコルの可能性を高める。それにより、無線エラーが防がれるか又は後に伝送される（再伝送又は新規）データのロバスト性の改善が促され、非ＡＰ ＷＴＲＵは、ロバスト性をもたらすために、上位層によるブロードキャストシンクノードへのユニキャスト接続のみに依拠する必要がない。

[0224] ＵＬブロードキャスト伝送の手順の例は、ＰＰＤＵごとに適用されてもされなくてもよい（例えば、ＵＬブロードキャスト伝送後のある持続時間のフィードバック及び場合により反復される必要がある情報を、802.11ＭＡＣのＵＬ送信機が保持する持続時間のフィードバックに適用可能であり得る）。ＵＬ ＷＴＲＵは、ロストデータの再伝送を行うことなしに、フィードバック後に送信されるＰＰＤＵのロバスト性を調節するためにＵＬブロードキャスト伝送をフィードバックに基づかせることができる。ＵＬブロードキャスト伝送の手順の例は、マルチＡＰセットアップ内でＵＬ方向に送信される非ブロードキャストＰＰＤＵに適用可能であり得、マルチＡＰセットアップでは、１つのＡＰは、アンカ又はマスタＡＰであり、他のＡＰは、アンカＡＰのための補助受信機又はスレーブＡＰである。

[0225] 図１８は、ロバスト性を改善するためのフィードバックを与える手段としての結合フィードバックを取得する送信機の一例を示す。伝送側ＷＴＲＵ１８０１は、フィードバックを要請するＵＬブロードキャストパケット内において、要請されるＤＬフィードバックで使用されるＭＣＳ、スクランブラ開始及び／又はより長いガードインターバル（ＧＩ）を示すことができる。一実施形態では、ＤＬ内のフィードバックＰＰＤＵに所定のＭＣＳ／ＧＩを使用することができ、及び／又は要請ＵＬブロードキャストＰＰＤＵにあるのと同じ値にフィードバックＰＰＤＵスクランブラ開始を設定することができる。

[0226] 一実施形態では、フィードバック信号の遅延拡散を制限するために、ＵＬブロードキャストＰＰＤＵは、フィードバックを行うことを許可された１つ又は複数のＡＰを示し得る。伝送側ＷＴＲＵがフィードバックを一切受信しない場合、伝送側ＷＴＲＵは、全てのＡＰが使用中／妨害されていると推論することができ、遅延（再）伝送を行うことができる。ＷＴＲＵが再伝送を行うためにフィードバック手順を使用しない場合（即ちブロードキャストＰＰＤＵの再伝送がない）、ＷＴＲＵは、自らの伝送をフィードバックに基づかせて、将来送信されるＰＰＤＵのロバスト性（例えば、出力、ＭＣＳ）を調節することができる。複数のＡＰがＵＬブロードキャストＰＰＤＵを成功裏に受信した場合、それらのＡＰのフィードバックフレームを無線上で組み合わせ、非ＡＰ ＷＴＲＵにおいて単一のＰＰＤＵとして復号することができる。

[0227] 図１９は、（例えば、ＵＬ内で伝送される１つ又は複数の集約ＭＰＤＵ（ＡＭＰＤＵ）内のＭＰＤＵ／データブロックごとに）送信機が結合フィードバックを取得することができるように、ＡＰがＤＬフィードバックを与えるための手順の別の例を示す。フィードバックの取り決めをセットアップするために事前にやり取りする必要なしに、ＡＭＰＤＵの伝送を可能にするメカニズムを使用することができる。そのような非要請型のフィードバックの取り決めをＵＬブロードキャストで使用することができる。合意のパラメータ（例えば、バッファサイズ、タイムアウト値）は、ＵＬブロードキャストをサポートする全てのＷＴＲＵについて所定値に設定することができる。

[0228] データブロック／ＭＰＤＵに対応する単一の結合フィードバックビットマップを受信するために、例えば正のフィードバックに基づくオンオフキーイングと共にＮＤＰフィードバック手法を使用することができる。０の状態を示すトーンセットは、伝送しなくてもよい一方、１の状態を示すトーンセットは、ＡＰによって伝送することができる。ＮＤＰロングトレーニングフィールド（ＬＴＦ）は、様々なＡＰから発信元／送信機、即ち非ＡＰ ＷＴＲＵ１９０１への伝搬遅延の差をカバーするためにより長いＧＩを含むことができる。

[0229] ＵＬブロードキャストＰＰＤＵは、開始シーケンス番号を示し得る。各トーンセット上のＡＣＫ信号は、開始シーケンス番号に対してオフセットされたシーケンス番号を有するＭＰＤＵ／データブロックのためのフィードバックビットを表し得る。トーンセットのエネルギに基づき、発信元／送信機（即ち非ＡＰ ＷＴＲＵ）は、対応するトーンセットインデックスに基づいてＭＰＤＵ／データブロックシーケンス番号の受信状態を導出することができる。

[0230] ＮＤＰフィードバックは、正のフィードバックに基づくオンオフキーイングであり得るため、ＵＬブロードキャストＰＰＤＵによってトリガされるフィードバックＮＤＰは、発信元によって単一のＮＤＰとして認められ得る。発信元がＮＤＰを検出すると、対応する欠落ＭＰＤＵ／データブロックが再伝送され得る。ＮＤＰが検出されない場合、発信元は、全ての受信機（例えば、ＡＰ）が妨害されている／使用中であると推論することができ、遅延（再）伝送を行うことができる。ＵＬ ＷＴＲＵが再伝送を行うためにフィードバック手順を使用しない場合（即ちブロードキャストＰＰＤＵの再伝送がない）、ＷＴＲＵは、フィードバックに基づいて伝送して、将来送信されるＰＰＤＵのロバスト性（例えば、出力、ＭＣＳ）を調節することができる。

[0231] 上記では特徴及び要素を特定の組み合わせで記載したが、各特徴及び要素は、単独で又は他の特徴及び要素との任意の組み合わせで使用できることを当業者であれば理解するであろう。加えて、本明細書に記載した方法は、コンピュータ又はプロセッサによる実行のためにコンピュータ可読媒体に組み込まれるコンピュータプログラム、ソフトウェア又はファームウェアによって実装することができる。コンピュータ可読媒体の例は、（有線又は無線接続上で伝送される）電子信号及びコンピュータ可読記憶媒体を含む。コンピュータ可読記憶媒体の例は、これのみに限定されないが、読取専用メモリ（ＲＯＭ）、ランダムアクセスメモリ（ＲＡＭ）、レジスタ、キャッシュメモリ、半導体メモリ装置、内蔵ハードディスク及び脱着可能ディスク等の磁気媒体、光磁気媒体並びにＣＤ－ＲＯＭディスク及びデジタル多用途ディスク（ＤＶＤ）等の光媒体を含む。ＷＴＲＵ、ＵＥ、端末、基地局、ＲＮＣ又は任意のホストコンピュータで使用するための無線周波数トランシーバを実装するために、ソフトウェアに関連するプロセッサを使用することができる。

Claims (20)

1. 無線送信／受信ユニット（ＷＴＲＵ）で使用する方法であって、
   ステーション管理エンティティ（ＳＭＥ）が、１つ又は複数のアクセスポイント（ＡＰ）によって伝送されるウェイクアップ無線（ＷＵＲ）ディスカバリフレームのためのＷＵＲ走査プロセスを可能にする要求プリミティブを生成することであって、前記要求プリミティブは、複数の第１のパラメータを含む、生成することと、
   前記複数の前記第１のパラメータに基づいて前記ＷＵＲ走査プロセスを実行することと、
   ＭＡＣ層において、前記ＷＵＲ走査プロセスの結果及び前記複数の第１のパラメータの少なくとも一部に基づいて少なくとも１つの確認プリミティブを生成することと、
   前記ＭＡＣ層から前記ＳＭＥに前記少なくとも１つの確認プリミティブを通信することと
   を含む方法。
2. 前記複数の第１のパラメータは、ＢＳＳＩＤ、BSSIDList、ＳＳＩＤ、SSIDList、CompressedBSSID、compressedSSID、CompressedBSSIDList、CompressedSSIDList、DiscoveryChannel、DiscoveryChannelList、MinDiscoveryChannelTime、MaxDiscoveryChannelTime、MasScanningTime、ReceivedPowerThreshod、WURScanningMode、WURScanningReportingOption又はRequestWURresultの少なくとも１つを含む、請求項１に記載の方法。
3. 前記WURScanningModeは、ＷＵＲ走査モードを示す、請求項２に記載の方法。
4. 前記少なくとも１つの確認プリミティブのそれぞれは、複数の第２のパラメータを含む、請求項１に記載の方法。
5. 前記複数の第２のパラメータは、BSSDescriptionFromWURDFSet、ResultCode、ScannedWURDiscoveryChannelList又はVendorSpecificInfoの少なくとも１つを含む、請求項４に記載の方法。
6. 前記要求プリミティブは、MLME-WURSCAN.Requestプリミティブである、請求項１に記載の方法。
7. 前記要求プリミティブは、ステーション管理エンティティ（ＳＭＥ）によって生成される、請求項１に記載の方法。
8. 前記要求プリミティブは、MLME-SCAN.Requestプリミティブである、請求項１に記載の方法。
9. 前記ＷＵＲ走査プロセスを停止するための停止要求プリミティブを生成することを更に含む、請求項１に記載の方法。
10. 停止確認プリミティブを生成することを更に含む、請求項１に記載の方法。
11. 無線送信／受信ユニット（ＷＴＲＵ）であって、
    １つ又は複数のアクセスポイント（ＡＰ）によって伝送されるウェイクアップ無線（ＷＵＲ）ディスカバリフレームのためのＷＵＲ走査プロセスを可能にする要求プリミティブを生成することであって、前記要求プリミティブは、複数の第１のパラメータを含む、生成すること、
    前記複数の前記第１のパラメータに基づいて前記ＷＵＲ走査プロセスを実行すること、
    ＭＡＣ層において、前記ＷＵＲ走査プロセスの結果及び前記複数の第１のパラメータの少なくとも一部に基づいて少なくとも１つの確認プリミティブを生成すること、及び
    前記ＭＡＣ層からステーション管理エンティティ（ＳＭＥ）に前記少なくとも１つの確認プリミティブを通信すること
    を行うように構成されているプロセッサ
    を含む無線送信／受信ユニット。
12. 前記複数の第１のパラメータは、ＢＳＳＩＤ、BSSIDList、ＳＳＩＤ、SSIDList、CompressedBSSID、compressedSSID、CompressedBSSIDList、CompressedSSIDList、DiscoveryChannel、DiscoveryChannelList、MinDiscoveryChannelTime、MaxDiscoveryChannelTime、MasScanningTime、ReceivedPowerThreshod、WURScanningMode、WURScanningReportingOption又はRequestWURresultの少なくとも１つを含む、請求項１１に記載のＷＴＲＵ。
13. 前記WURScanningModeは、ＷＵＲ走査モードを示す、請求項１２に記載のＷＴＲＵ。
14. 前記少なくとも１つの確認プリミティブのそれぞれは、複数の第２のパラメータを含む、請求項１１に記載のＷＴＲＵ。
15. 前記複数の第２のパラメータは、BSSDescriptionFromWURDFSet、ResultCode、ScannedWURDiscoveryChannelList又はVendorSpecificInfoの少なくとも１つを含む、請求項１４に記載のＷＴＲＵ。
16. 前記要求プリミティブは、MLME-WURSCAN.Requestプリミティブである、請求項１１に記載のＷＴＲＵ。
17. 前記要求プリミティブは、ステーション管理エンティティ（ＳＭＥ）によって生成される、請求項１１に記載のＷＴＲＵ。
18. 前記要求プリミティブは、MLME-SCAN.Requestプリミティブである、請求項１１に記載のＷＴＲＵ。
19. 前記プロセッサは、前記ＷＵＲ走査プロセスを停止するための停止要求プリミティブを生成するように更に構成されている、請求項１１に記載のＷＴＲＵ。
20. 前記プロセッサは、停止確認プリミティブを生成するように更に構成されている、請求項１１に記載のＷＴＲＵ。

Images