特許 7633275 サイドリンク無線送信／受信ユニット（ＷＴＲＵ）間連携のための方法及び装置

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

(12)【公報種別】特許公報(B2)

(11)【特許番号】

(24)【登録日】2025-02-10

(45)【発行日】2025-02-19

(54)【発明の名称】サイドリンク無線送信／受信ユニット（ＷＴＲＵ）間連携のための方法及び装置

(51)【国際特許分類】

   H04W 72/25 20230101AFI20250212BHJP

   H04W 72/563 20230101ALI20250212BHJP

   H04W 72/54 20230101ALI20250212BHJP

【ＦＩ】

H04W72/25

H04W72/563

H04W72/54 110

【請求項の数】 4

(21)【出願番号】P 2022561385

(86)(22)【出願日】2021-04-08

(65)【公表番号】

(43)【公表日】2023-05-31

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

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

(87)【国際公開日】2021-10-14

【審査請求日】2024-04-08

(31)【優先権主張番号】63/007,003

(32)【優先日】2020-04-08

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

(31)【優先権主張番号】63/061,457

(32)【優先日】2020-08-05

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

(31)【優先権主張番号】63/091,459

(32)【優先日】2020-10-14

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

【早期審査対象出願】

(73)【特許権者】

【識別番号】510030995

【氏名又は名称】インターデイジタル パテント ホールディングス インコーポレイテッド

(74)【代理人】

【識別番号】110001243

【氏名又は名称】弁理士法人谷・阿部特許事務所

(72)【発明者】

【氏名】テン、タオ

(72)【発明者】

【氏名】ホアン、トゥオン

(72)【発明者】

【氏名】フリーダ、マルティーノ

(72)【発明者】

【氏名】イ、ムンイル

【審査官】桑原 聡一

(56)【参考文献】

【文献】国際公開第２０２０／０６０３３２（ＷＯ，Ａ１）

【文献】国際公開第２０２０／０３３０８８（ＷＯ，Ａ１）

【文献】LG Electronics，Discussion on resource allocation mechanism for NR V2X，3GPP TSG RAN WG1 adhoc_NR_AH_1901 R1-1900650，2019年01月21日，Internet<URL:http://www.3gpp.org/ftp/tsg_ran/WG1_RL1/TSGR1_AH/NR_AH_1901/Docs/R1-1900650.zip>

【文献】Intel Corporation，Sidelink Resource Allocation Mode-2 Design for NR V2X Communication，3GPP TSG RAN WG1 #97 R1-1906796，2019年05月13日，Internet<URL:https://www.3gpp.org/ftp/tsg_ran/WG1_RL1/TSGR1_97/Docs/R1-1906796.zip>

【文献】Fujitsu，Considerations on Inter-UE Coordination for Mode 2 Enhancements，3GPP TSG RAN WG1 #103-e R1-2007788，2020年10月26日，Internet<URL:https://www.3gpp.org/ftp/tsg_ran/WG1_RL1/TSGR1_103-e/Docs/R1-2007788.zip>

(58)【調査した分野】(Int.Cl.，ＤＢ名)

Ｈ０４Ｂ ７／２４－７／２６

Ｈ０４Ｗ ４／００－９９／００

３ＧＰＰ ＴＳＧ ＲＡＮ ＷＧ１－４

ＳＡ ＷＧ１－４

ＣＴ ＷＧ１、４

(57)【特許請求の範囲】

【請求項1】

プロセッサ及びメモリを備える第１の無線送受信ユニット（ＷＴＲＵ）であって、
前記プロセッサ及びメモリは、
第２のＷＴＲＵからリソース情報要求を受信することであって、前記リソース情報要求は、前記第２のＷＴＲＵによって実行される送信に関連付けられる優先度のインジケーション、前記第２のＷＴＲＵによって実行される前記送信に関連付けられる時間窓の開始及び終了のインジケーション、並びに前記第２のＷＴＲＵによって実行される前記送信に関連付けられるサブチャネルの数のインジケーションを含む、ことと、
示された前記優先度、前記時間窓の開始時及び終了時、並びに前記サブチャネルの数に基づいて１つ以上のリソースのセットを判定することであって、前記１つ以上のリソースのセットは、第１のＷＴＲＵが前記第２のＷＴＲＵによって実行される前記送信のために前記第２のＷＴＲＵによって使用可能であると判断した１つ以上のリソースを含む、ことと、
前記第２のＷＴＲＵに支援情報を送信するための支援情報リソースを判定することであって、前記支援情報は、前記１つ以上のリソースのセットのインジケーションを含む、ことと、
前記支援情報リソースを使用して、前記支援情報を含む媒体アクセス制御（ＭＡＣ）制御要素（ＣＥ）またはサイドリンク制御情報（ＳＣＩ）を前記第２のＷＴＲＵに送信することと、
候補リソースのセットを感知することに基づいて前記１つ以上のリソースのセットの１つ以上のリソースが前記第２のＷＴＲＵによって使用可能であると判定することであって、前記感知することは、前記候補リソースのセットの１つ以上の候補リソースについてのＲＳＲＰ（reference signal received power）測定を判定することを含む、ことと、
前記リソース情報要求に含まれる前記優先度のインジケーションに基づいて閾値を判定することであって、
前記リソース情報要求に含まれる前記優先度のインジケーションは、前記第２のＷＴＲＵによって実行される前記送信に関連付けられるレイヤ１（Ｌ１）優先度を示し、
前記Ｌ１優先度は、最高優先度に設定される、
ことと、
を実行するように構成され、
前記プロセッサ及びメモリは、（１）前記Ｌ１優先度に基づいて重み付け係数を判定することと、（２）前記重み付け係数をＲＳＲＰ値に適用することと、（３）前記重み付け係数に基づいて前記閾値を判定することと、をさらに実行するように構成される、
第１のＷＴＲＵ。

【請求項2】

前記感知することは、前記ＲＳＲＰ測定を前記閾値と比較することを含む、請求項１の第１のＷＴＲＵ。

【請求項3】

前記支援情報は、リソースタイプのインジケーションを含む、請求項１の第１のＷＴＲＵ。

【請求項4】

前記リソースタイプは、前記１つ以上のリソースのセットの１つ以上のリソースが好ましいリソースであることを示す、請求項３の第１のＷＴＲＵ。

【発明の詳細な説明】

【背景技術】

【0001】

本発明は、通信の分野に関し、より具体的には、新無線及び／又は新無線（ＮＲ）アクセス技術並びに通信システムを使用して実行される通信を含む、高度又は次世代無線通信システムにおける通信のための方法、装置、システム、アーキテクチャ、及びインターフェースに関する。ＮＲアクセス技術及び通信システムは、例えば、車道上の自動車、インフラストラクチャ、歩行者、及び／又はネットワークのうちのいずれかの間の通信のための車両通信（Ｖ２Ｘ）を含むことができ（例えば、そのために使用することができ）、無線送信／受信ユニット（ＷＴＲＵ）が互いに（例えば、直接）通信し得る。

【0002】

Ｖ２Ｘシナリオは、（１）ＷＴＲＵが車両通信メッセージの送受信を開始するためにネットワークから支援を受け取ることができるカバレッジ内シナリオと、（２）ＷＴＲＵが事前に構成されたパラメータを使用して、車両通信メッセージの送受信を開始し得るカバレッジ外シナリオとを含む。Ｖ２Ｘサービスは、以下を含む：（１）車両対車両（Ｖ２Ｖ）：車両ＷＴＲＵが互いに直接通信し得る；（２）車両対インフラストラクチャ（Ｖ２Ｉ）：車両ＷＴＲＵは、道路側ユニット（ＲＳＵ）、又は進化型ＮｏｄｅＢｓ（ｅＮＢｓ）若しくは他のアクセスポイントなどの基地局（ＢＳ）のいずれかと通信し得る；（３）車両対ネットワーク（Ｖ２Ｎ）：車両ＷＴＲＵは、コアネットワークと通信し得る、及び（４）車両対歩行者（Ｖ２Ｐ）：車両ＷＴＲＵは、特定の及び／又は特別な条件下で、例えば、低バッテリ容量下で歩行者に関連付けられたＵＥと通信し得る。更に、Ｖ２Ｘ使用事例は、進化型モバイルブロードバンド（ｅＭＢＢ）、大規模マシンタイプ通信（ｍＭＴＣ）、及び超信頼低遅延通信（ＵＲＬＬＣ）を含み得る。異なる使用事例は、より高いデータ速度、より高いスペクトル効率、低電力、及びより高いエネルギー効率、より短い遅延、及びより高い信頼性などの異なる要件に焦点を当ててもよい。

【図面の簡単な説明】

【0003】

より詳細な理解は、添付の図面と併せて例として与えられる以下の説明から得られ得、図中の同様の参照番号は、同様の要素を示す。

【図1A】１つ以上の開示された実施形態が実装され得る、例示的な通信システムを示すシステム図である。

【図1B】一実施形態による、図１Ａに示される通信システム内で使用され得る、例示的な無線送信／受信ユニット（wireless transmit/receive unit、ＷＴＲＵ）を示すシステム図である。

【図1C】一実施形態による、図１Ａに示される通信システム内で使用され得る、例示的な無線アクセスネットワーク（radio access network、ＲＡＮ）及び例示的なコアネットワーク（core network、ＣＮ）を示すシステム図である。

【図1D】一実施形態による、図１Ａに示される通信システム内で使用され得る、更なる例示的なＲＡＮ及び更なる例示的なＣＮを示すシステム図である。

【図2】実施形態による、明示的な要求によってトリガされた支援情報送信を示す図である。

【図3】実施形態による、半永続的（ＳＰ）ベースのリソース予約によってトリガされる支援情報送信を示す図である。

【図4】実施形態による、ＨＡＲＱＡＣＫ／ＮＡＣＫ送信及びＨＡＲＱ再送信のいずれかによってトリガされる支援送信を示す図である。

【図5】実施形態による、リソースセット情報を提供する支援送信を示す図である。

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

【0004】

実施形態を実施するための例示的なネットワーク
図１Ａは、１つ以上の開示された実施形態が実装され得る、例示的な通信システム１００を示す図である。通信システム１００は、音声、データ、ビデオ、メッセージ伝達、ブロードキャストなどのコンテンツを、複数の無線ユーザに提供する、多重アクセスシステムであり得る。通信システム１００は、複数の無線ユーザが、無線帯域幅を含むシステムリソースの共有を通じて、上記のようなコンテンツにアクセスすることを可能にし得る。例えば、通信システム１００は、符号分割多重アクセス（code division multiple access、ＣＤＭＡ）、時分割多重アクセス（time division multiple access、ＴＤＭＡ）、周波数分割多重アクセス（frequency division multiple access、ＦＤＭＡ）、直交ＦＤＭＡ（orthogonal FDMA、ＯＦＤＭＡ）、シングルキャリアＦＤＭＡ（single-carrier FDMA、ＳＣ－ＦＤＭＡ）、ゼロテールユニークワードＤＦＴ－Ｓｐｒｅａｄ ＯＦＤＭ（zero-tail unique-word DFT-Spread OFDM、ＺＴ ＵＷ ＤＴＳ－ｓ ＯＦＤＭ）、ユニークワードＯＦＤＭ（unique word OFDM、ＵＷ－ＯＦＤＭ）、リソースブロックフィルタ処理ＯＦＤＭ、フィルタバンクマルチキャリア（filter bank multicarrier、ＦＢＭＣ）などの、１つ以上のチャネルアクセス方法を採用し得る。

【0005】

図１Ａに示されるように、通信システム１００は、無線送信／受信ユニット（ＷＴＲＵ）１０２ａ、１０２ｂ、１０２ｃ、１０２ｄと、ＲＡＮ１０４／１１３と、ＣＮ１０６／１１５と、公衆交換電話網（public switched telephone network、ＰＳＴＮ）１０８と、インターネット１１０と、他のネットワーク１１２とを含み得るが、開示される実施形態は、任意の数のＷＴＲＵ、基地局、ネットワーク、及び／又はネットワーク要素を企図していることが理解されよう。ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄの各々は、無線環境において動作し、かつ／又は通信するように構成された、任意のタイプのデバイスであり得る。例として、それらのいずれも「局」及び／又は「ＳＴＡ」と称され得るＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄは、無線信号を送信及び／又は受信するように構成され得、ユーザ機器（user equipment、ＵＥ）、移動局、固定又は移動加入者ユニット、加入ベースのユニット、ページャ、セルラ電話、携帯情報端末（personal digital assistant、ＰＤＡ）、スマートフォン、ラップトップ、ネットブック、パーソナルコンピュータ、無線センサ、ホットスポット又はＭｉ－Ｆｉデバイス、モノのインターネット（Internet of Things、ＩｏＴ）デバイス、ウォッチ又は他のウェアラブル、ヘッドマウントディスプレイ（head-mounted display、ＨＭＤ）、車両、ドローン、医療デバイス及びアプリケーション（例えば、遠隔手術）、工業用デバイス及びアプリケーション（例えば、工業用及び／又は自動処理チェーンコンテキストで動作するロボット及び／又は他の無線デバイス）、家電デバイス、商業用及び／又は工業用無線ネットワークで動作するデバイスなどを含み得る。ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、及び１０２ｄのいずれも、互換的にＵＥと称され得る。

【0006】

通信システム１００はまた、基地局１１４ａ及び／又は基地局１１４ｂを含み得る。基地局１１４ａ、１１４ｂの各々は、ＣＮ１０６／１１５、インターネット１１０、及び／又は他のネットワーク１１２など、１つ以上の通信ネットワークへのアクセスを容易にするために、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄのうちの少なくとも１つと無線でインターフェース接続するように構成された、任意のタイプのデバイスであり得る。例として、基地局１１４ａ、１１４ｂは、基地局トランシーバ（base transceiver station、ＢＴＳ）、ノードＢ、ｅＮｏｄｅＢ、ホームノードＢ、ホームｅＮｏｄｅＢ、ｇＮＢ、ＮＲ ＮｏｄｅＢ、サイトコントローラ、アクセスポイント（access point、ＡＰ）、無線ルータなどであり得る。基地局１１４ａ、１１４ｂは各々単一の要素として示されているが、基地局１１４ａ、１１４ｂは、任意の数の相互接続された基地局及び／又はネットワーク要素を含み得ることが理解されるであろう。

【0007】

基地局１１４ａは、基地局コントローラ（base station controller、ＢＳＣ）、無線ネットワークコントローラ（radio network controller、ＲＮＣ）、リレーノードなど、他の基地局及び／又はネットワーク要素（図示せず）も含み得る、ＲＡＮ１０４／１１３の一部であり得る。基地局１１４ａ及び／又は基地局１１４ｂは、セル（図示せず）と称され得る、１つ以上のキャリア周波数で無線信号を送信及び／又は受信するように構成され得る。これらの周波数は、認可スペクトル、未認可スペクトル、又はライセンス及び未認可スペクトルの組合せであり得る。セルは、比較的固定され得るか又は経時的に変化し得る特定の地理的エリアに、無線サービスのカバレッジを提供し得る。セルは更にセルセクタに分割され得る。例えば、基地局１１４ａと関連付けられたセルは、３つのセクタに分割され得る。したがって、一実施形態では、基地局１１４ａは、３つのトランシーバを、すなわち、セルのセクタごとに１つのトランシーバを含み得る。一実施形態では、基地局１１４ａは、多重入力多重出力（multiple-input multiple output、ＭＩＭＯ）技術を用い得、セルのセクタごとに複数のトランシーバを利用し得る。例えば、ビームフォーミングを使用して、所望の空間方向に信号を送信及び／又は受信し得る。

【0008】

基地局１１４ａ、１１４ｂは、エアインターフェース１１６を介して、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄのうちの１つ以上と通信し得るが、このエアインターフェース１１６は、任意の好適な無線通信リンク（例えば、無線周波数（radio frequency、ＲＦ）、マイクロ波、センチメートル波、マイクロメートル波、赤外線（infrared、ＩＲ）、紫外線（ultraviolet、ＵＶ）、可視光など）であり得る。エアインターフェース１１６は、任意の好適な無線アクセス技術（radio access technology、ＲＡＴ）を使用して確立され得る。

【0009】

より具体的には、上記のように、通信システム１００は、多重アクセスシステムであり得、例えば、ＣＤＭＡ、ＴＤＭＡ、ＦＤＭＡ、ＯＦＤＭＡ、ＳＣ－ＦＤＭＡなどの、１つ以上のチャネルアクセススキームを用い得る。例えば、ＲＡＮ１０４／１１３内の基地局１１４ａ、及びＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃは、ユニバーサル移動体通信システム（Universal Mobile Telecommunications System、ＵＭＴＳ）地上無線アクセス（UMTS Terrestrial Radio Access、ＵＴＲＡ）などの無線技術を実装し得、これは広帯域ＣＤＭＡ（wideband CDMA、ＷＣＤＭＡ）を使用してエアインターフェース１１５／１１６／１１７を確立し得る。ＷＣＤＭＡは、高速パケットアクセス（High-Speed Packet Access、ＨＳＰＡ）及び／又は進化型ＨＳＰＡ（ＨＳＰＡ＋）などの通信プロトコルを含み得る。ＨＳＰＡは、高速ダウンリンク（Downlink、ＤＬ）パケットアクセス（High-Speed Downlink Packet Access、ＨＳＤＰＡ）及び／又は高速アップリンクパケットアクセス（High-Speed UL Packet Access、ＨＳＵＰＡ）を含み得る。

【0010】

一実施形態では、基地局１１４ａ及びＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃは、進化型ＵＭＴＳ地上無線アクセス（Evolved UMTS Terrestrial Radio Access、Ｅ－ＵＴＲＡ）などの無線技術を実装し得るが、これは、ロングタームエボリューション（ＬＴＥ）及び／又はＬＴＥ－Ａｄｖａｎｃｅｄ（ＬＴＥ－Ａ）及び／又はＬＴＥ－Ａｄｖａｎｃｅｄ Ｐｒｏ（ＬＴＥ－Ａ Ｐｒｏ）を使用してエアインターフェース１１６を確立し得る。

【0011】

一実施形態では、基地局１１４ａ及びＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃは、ＮＲ無線アクセスなどの無線技術を実装することができ、この技術は、Ｎｅｗ Ｒａｄｉｏ（ＮＲ）を使用してエアインターフェース１１６を確立することができる。

【0012】

一実施形態では、基地局１１４ａ及びＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃは、複数の無線アクセス技術を実装し得る。例えば、基地局１１４ａ及びＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃは、例えば、デュアルコネクティビティ（dual connectivity、ＤＣ）原理を使用して、ＬＴＥ無線アクセス及びＮＲ無線アクセスを一緒に実装し得る。したがって、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃによって利用されるエアインターフェースは、複数のタイプの無線アクセス技術、及び／又は複数のタイプの基地局（例えば、ｅＮＢ及びｇＮＢ）に送信される／そこから送信される送信によって特徴付けられ得る。

【0013】

他の実施形態では、基地局１１４ａ及びＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃは、ＩＥＥＥ８０２．１１（すなわち、無線フィデリティ（Wireless Fidelity、ＷｉＦｉ）、ＩＥＥＥ８０２．１６（すなわち、ワイマックス（Worldwide Interoperability for Microwave Access、ＷｉＭＡＸ）、ＣＤＭＡ２０００、ＣＤＭＡ２０００ １Ｘ、ＣＤＭＡ２０００ ＥＶ－ＤＯ、暫定規格２０００（ＩＳ－２０００）、暫定規格９５（ＩＳ－９５）、暫定規格８５６（ＩＳ－８５６）、汎欧州デジタル移動電話方式（Global System for Mobile communications、ＧＳＭ）、ＧＳＭ進化型高速データレート（Enhanced Data rates for GSM Evolution、ＥＤＧＥ）、ＧＳＭ ＥＤＧＥ（ＧＥＲＡＮ）などの無線技術を実装し得る。

【0014】

図１Ａの基地局１１４ｂは、例えば、無線ルータ、ホームノードＢ、ホームｅＮｏｄｅ Ｂ又はアクセスポイントであり得、事業所、家庭、車両、キャンパス、工業施設、（例えば、ドローンによる使用のための）空中回廊、道路などの場所などの局所的エリアにおける無線接続を容易にするために、任意の好適なＲＡＴを利用し得る。一実施形態では、基地局１１４ｂ及びＷＴＲＵ１０２ｃ、１０２ｄは、ＩＥＥＥ８０２．１１などの無線技術を実装して、無線ローカルエリアネットワーク（wireless local area network、ＷＬＡＮ）を確立し得る。一実施形態では、基地局１１４ｂ及びＷＴＲＵ１０２ｃ、１０２ｄは、ＩＥＥＥ８０２．１５などの無線技術を実装して、無線パーソナルエリアネットワーク（wireless personal area network、ＷＰＡＮ）を確立し得る。更に別の一実施形態では、基地局１１４ｂ及びＷＴＲＵ１０２ｃ、１０２ｄは、セルラベースのＲＡＴ（例えば、ＷＣＤＭＡ、ＣＤＭＡ２０００、ＧＳＭ、ＬＴＥ、ＬＴＥ－Ａ、ＬＴＥ－Ａ Ｐｒｏ、ＮＲなど）を利用して、ピコセル又はフェムトセルを確立し得る。図１Ａに示すように、基地局１１４ｂは、インターネット１１０への直接接続を有し得る。したがって、基地局１１４ｂは、ＣＮ１０６／１１５を介してインターネット１１０にアクセスする必要がない場合がある。

【0015】

ＲＡＮ１０４／１１３は、ＣＮ１０６／１１５と通信し得、これは、音声、データ、アプリケーション、及び／又はボイスオーバインターネットプロトコル（voice over internet protocol、ＶｏＩＰ）サービスをＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄのうちの１つ以上に提供するように構成された、任意のタイプのネットワークであり得る。データは、例えば、異なるスループット要件、待ち時間要件、エラー許容要件、信頼性要件、データスループット要件、モビリティ要件などの、様々なサービス品質（quality of service、ＱｏＳ）要件を有し得る。ＣＮ１０６／１１５は、呼制御、支払い請求サービス、移動体位置ベースのサービス、プリペイド呼、インターネット接続性、ビデオ配信などを提供し、かつ／又はユーザ認証などの高レベルセキュリティ機能を実行し得る。図１Ａには示されていないが、ＲＡＮ１０４／１１３及び／又はＣＮ１０６／１１５は、ＲＡＮ１０４／１１３と同じＲＡＴ又は異なるＲＡＴを採用する他のＲＡＮと、直接又は間接的に通信し得ることが理解されよう。例えば、ＮＲ無線技術を利用し得るＲＡＮ１０４／１１３に接続されていることに加えて、ＣＮ１０６／１１５はまた、ＧＳＭ、ＵＭＴＳ、ＣＤＭＡ２０００、ＷｉＭＡＸ、Ｅ－ＵＴＲＡ、又はＷｉＦｉ無線技術を採用して別のＲＡＮ（図示せず）と通信し得る。

【0016】

ＣＮ１０６／１１５はまた、ＰＳＴＮ１０８、インターネット１１０、及び／又は他のネットワーク１１２にアクセスするために、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄのためのゲートウェイとしての機能を果たし得る。ＰＳＴＮ１０８は、基本電話サービス（plain old telephone service、ＰＯＴＳ）を提供する公衆交換電話網を含み得る。インターネット１１０は、相互接続されたコンピュータネットワーク及びデバイスのグローバルシステムを含み得るが、これらのネットワーク及びデバイスは、送信制御プロトコル（transmission control protocol、ＴＣＰ）、ユーザデータグラムプロトコル（user datagram protocol、ＵＤＰ）、及び／又はＴＣＰ／ＩＰインターネットプロトコルスイートのインターネットプロトコル（internet protocol、ＩＰ）などの、共通通信プロトコルを使用する。ネットワーク１１２は、他のサービスプロバイダによって所有及び／又は運営される、有線及び／又は無線通信ネットワークを含み得る。例えば、ネットワーク１１２は、ＲＡＮ１０４／１１３と同じＲＡＴ又は異なるＲＡＴを採用し得る、１つ以上のＲＡＮに接続された別のＣＮを含み得る。

【0017】

通信システム１００におけるＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄのいくつか又は全ては、マルチモード能力を含み得る（例えば、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄは、異なる無線リンクを介して異なる無線ネットワークと通信するための複数のトランシーバを含み得る）。例えば、図１Ａに示されるＷＴＲＵ１０２ｃは、セルラベースの無線技術を用い得る基地局１１４ａ、及びＩＥＥＥ８０２無線技術を用い得る基地局１１４ｂと通信するように構成され得る。

【0018】

図１Ｂは、例示的なＷＴＲＵ１０２を示すシステム図である。図１Ｂに示すように、ＷＴＲＵ１０２は、とりわけ、プロセッサ１１８、トランシーバ１２０、送信／受信要素１２２、スピーカ／マイクロフォン１２４、キーパッド１２６、ディスプレイ／タッチパッド１２８、非リムーバブルメモリ１３０、リムーバブルメモリ１３２、電源１３４、全地球測位システム（global positioning system、ＧＰＳ）チップセット１３６、及び／又は他の周辺機器１３８を含み得る。ＷＴＲＵ１０２は、一実施形態との一貫性を有したまま、前述の要素の任意の部分的組合せを含み得ることが理解されよう。

【0019】

プロセッサ１１８は、汎用プロセッサ、専用プロセッサ、従来のプロセッサ、デジタル信号プロセッサ（digital signal processor、ＤＳＰ）、複数のマイクロプロセッサ、ＤＳＰコアと関連付けられた１つ以上のマイクロプロセッサ、コントローラ、マイクロコントローラ、特定用途向け集積回路（Application Specific Integrated Circuit、ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（Field Programmable Gate Array、ＦＰＧＡ）回路、任意の他のタイプの集積回路（integrated circuit、ＩＣ）、状態機械などであり得る。プロセッサ１１８は、信号コーディング、データ処理、電力制御、入力／出力処理、及び／又はＷＴＲＵ１０２が無線環境で動作することを可能にする任意の他の機能性を実行し得る。プロセッサ１１８は、送信／受信要素１２２に結合され得るトランシーバ１２０に結合され得る。図１Ｂは、プロセッサ１１８及びトランシーバ１２０を別個のコンポーネントとして示すが、プロセッサ１１８及びトランシーバ１２０は、電子パッケージ又はチップにおいて一緒に統合され得るということが理解されよう。

【0020】

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

【0021】

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

【0022】

トランシーバ１２０は、送信／受信要素１２２によって送信される信号を変調し、送信／受信要素１２２によって受信される信号を復調するように構成され得る。上記のように、ＷＴＲＵ１０２は、マルチモード能力を有し得る。したがって、トランシーバ１２０は、例えばＮＲ及びＩＥＥＥ８０２．１１などの複数のＲＡＴを介してＷＴＲＵ１０２が通信することを可能にするための複数のトランシーバを含み得る。

【0023】

ＷＴＲＵ１０２のプロセッサ１１８は、スピーカ／マイクロフォン１２４、キーパッド１２６、及び／又はディスプレイ／タッチパッド１２８（例えば、液晶ディスプレイ（liquid crystal display、ＬＣＤ）表示ユニット若しくは有機発光ダイオード（organic light-emitting diode、ＯＬＥＤ）表示ユニット）に結合され得、これらからユーザが入力したデータを受信し得る。プロセッサ１１８はまた、ユーザデータをスピーカ／マイクロフォン１２４、キーパッド１２６、及び／又はディスプレイ／タッチパッド１２８に出力し得る。更に、プロセッサ１１８は、非リムーバブルメモリ１３０及び／又はリムーバブルメモリ１３２などの任意のタイプの好適なメモリから情報にアクセスし、当該メモリにデータを記憶し得る。非リムーバブルメモリ１３０は、ランダムアクセスメモリ（random-access memory、ＲＡＭ）、読み取り専用メモリ（read-only memory、ＲＯＭ）、ハードディスク又は任意の他のタイプのメモリ記憶デバイスを含み得る。リムーバブルメモリ１３２は、加入者識別モジュール（subscriber identity module、ＳＩＭ）カード、メモリスティック、セキュアデジタル（secure digital、ＳＤ）メモリカードなどを含み得る。他の実施形態では、プロセッサ１１８は、サーバ又はホームコンピュータ（図示せず）上など、ＷＴＲＵ１０２上に物理的に配置されていないメモリの情報にアクセスし、かつ当該メモリにデータを記憶し得る。

【0024】

プロセッサ１１８は、電源１３４から電力を受信し得るが、ＷＴＲＵ１０２における他の構成要素に電力を分配し、かつ／又は制御するように構成され得る。電源１３４は、ＷＴＲＵ１０２に電力を供給するための任意の好適なデバイスであり得る。例えば、電源１３４は、１つ以上の乾電池（例えば、ニッケルカドミウム（nickel-cadmium、ＮｉＣｄ）、ニッケル亜鉛（nickel-zinc、ＮｉＺｎ）、ニッケル金属水素化物（nickel metal hydride、ＮｉＭＨ）、リチウムイオン（lithium-ion、Ｌｉ－ｉｏｎ）など）、太陽電池、燃料電池などを含み得る。

【0025】

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

【0026】

プロセッサ１１８は、他の周辺機器１３８に更に結合され得、他の周辺機器１３８には、追加の特徴、機能、及び／又は有線若しくは無線接続を提供する１つ以上のソフトウェア及び／又はハードウェアモジュールが含まれ得る。例えば、周辺機器１３８には、加速度計、電子コンパス、衛星トランシーバ、（写真及び／又はビデオのための）デジタルカメラ、ユニバーサルシリアルバス（universal serial bus、ＵＳＢ）ポート、振動デバイス、テレビジョントランシーバ、ハンズフリーヘッドセット、Ｂｌｕｅｔｏｏｔｈ（登録商標）モジュール、周波数変調（frequency modulated、ＦＭ）無線ユニット、デジタル音楽プレーヤ、メディアプレーヤ、ビデオゲームプレーヤモジュール、インターネットブラウザ、仮想現実及び／又は拡張現実（Virtual Reality/Augmented Reality、ＶＲ／ＡＲ）デバイス、アクティビティトラッカなどが含まれ得る。周辺機器１３８は、１つ以上のセンサを含み得、センサは、ジャイロスコープ、加速度計、ホール効果センサ、磁力計、方位センサ、近接センサ、温度センサ、時間センサ、ジオロケーションセンサ、高度計、光センサ、タッチセンサ、磁力計、気圧計、ジェスチャセンサ、生体認証センサ、及び／又は湿度センサのうちの１つ以上であり得る。

【0027】

ＷＴＲＵ１０２は、（例えば、ＵＬ（例えば、送信用）及びダウンリンク（例えば、受信用）の両方のための特定のサブフレームと関連付けられた）信号のいくつか又はすべての送信及び受信が並列及び／又は同時であり得る、全二重無線機を含み得る。全二重無線機は、ハードウェア（例えば、チョーク）又はプロセッサを介した信号処理（例えば、別個のプロセッサ（図示せず）又はプロセッサ１１８を介して）を介して自己干渉を低減し、かつ又は実質的に排除するための干渉管理ユニットを含み得る。一実施形態では、ＷＲＴＵ１０２は、（例えば、ＵＬ（例えば、送信用）又はダウンリンク（例えば、受信用）のいずれかのための特定のサブフレームと関連付けられた）信号のうちのいくつか又は全てのうちのどれかの送信及び受信のための半二重無線機を含み得る。

【0028】

図１Ｃは、一実施形態によるＲＡＮ１０４及びＣＮ１０６を図示するシステム図である。上記のように、ＲＡＮ１０４は、Ｅ－ＵＴＲＡ無線技術を用いて、エアインターフェース１１６を介してＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃと通信し得る。ＲＡＮ１０４はまた、ＣＮ１０６と通信し得る。

【0029】

ＲＡＮ１０４は、ｅＮｏｄｅ－Ｂ１６０ａ、１６０ｂ、１６０ｃを含み得るが、ＲＡＮ１０４は、一実施形態との一貫性を有しながら、任意の数のｅＮｏｄｅ－Ｂを含み得るということが理解されよう。ｅＮｏｄｅ－Ｂ１６０ａ、１６０ｂ、１６０ｃは各々、エアインターフェース１１６を介してＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃと通信するための１つ以上のトランシーバを含み得る。一実施形態では、ｅＮｏｄｅ－Ｂ１６０ａ、１６０ｂ、１６０ｃは、ＭＩＭＯ技術を実装し得る。したがって、ｅＮｏｄｅ－Ｂ１６０ａは、例えば、複数のアンテナを使用して、ＷＴＲＵ１０２ａに無線信号を送信し、かつ／又はＷＴＲＵ１０２ａから無線信号を受信し得る。

【0030】

ｅＮｏｄｅ－Ｂ１６０ａ、１６０ｂ、１６０ｃの各々は、特定のセル（図示せず）と関連付けられ得、ＵＬ及び／又はＤＬにおいて、無線リソース管理決定、ハンドオーバ決定、ユーザのスケジューリングなどを処理するように構成され得る。図１Ｃに示すように、ｅＮｏｄｅ－Ｂ１６０ａ、１６０ｂ、１６０ｃは、Ｘ２インターフェースを介して互いに通信し得る。

【0031】

図１Ｃに示されるＣＮ１０６は、モビリティ管理エンティティ（mobility management entity、ＭＭＥ）１６２、サービングゲートウェイ（serving gateway、ＳＧＷ）１６４、及びパケットデータネットワーク（packet data network、ＰＤＮ）ゲートウェイ（又はＰＧＷ）１６６を含み得る。前述の要素の各々は、ＣＮ１０６の一部として示されているが、これらの要素のいずれも、ＣＮオペレータ以外のエンティティによって所有及び／又は操作され得ることが理解されよう。

【0032】

ＭＭＥ１６２は、Ｓ１インターフェースを介して、ＲＡＮ１０４内のｅＮｏｄｅ－Ｂ１６０ａ、１６０ｂ、及び１６０ｃの各々に接続され得、制御ノードとして機能し得る。例えば、ＭＭＥ１６２は、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃのユーザを認証すること、ベアラのアクティブ化／非アクティブ化、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃの初期アタッチ中に特定のサービス中のゲートウェイを選択すること、などの役割を果たし得る。ＭＭＥ１６２は、ＲＡＮ１０４と、ＧＳＭ及び／又はＷＣＤＭＡなどの他の無線技術を採用する他のＲＡＮ（図示せず）との間で切り替えるための制御プレーン機能を提供し得る。

【0033】

ＳＧＷ１６４は、Ｓ１インターフェースを介してＲＡＮ１０４におけるｅＮｏｄｅ－Ｂ１６０ａ、１６０ｂ、１６０ｃの各々に接続され得る。ＳＧＷ１６４は、概して、ユーザデータパケットをＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃに／からルーティングし、転送し得る。ＳＧＷ１６４は、ｅＮｏｄｅ－Ｂ間ハンドオーバ中にユーザプレーンをアンカする機能、ＤＬデータがＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃに利用可能であるときにページングをトリガする機能、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃのコンテキストを管理及び記憶する機能などの、他の機能を実行し得る。

【0034】

ＳＧＷ１６４は、ＰＧＷ１６６に接続され得、ＰＧＷ１６６は、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃとＩＰ対応デバイスとの間の通信を容易にするために、インターネット１１０などのパケット交換ネットワークへのアクセスをＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃに提供し得る。

【0035】

ＣＮ１０６は、他のネットワークとの通信を容易にし得る。例えば、ＣＮ１０６は、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃと従来の地上回線通信デバイスとの間の通信を容易にするために、ＰＳＴＮ１０８などの回路交換ネットワークへのアクセスをＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃに提供し得る。例えば、ＣＮ１０６は、ＣＮ１０６とＰＳＴＮ１０８との間のインターフェースとして機能するＩＰゲートウェイ（例えば、ＩＰマルチメディアサブシステム（ＩＭＳ）サーバ）を含むか、又はそれと通信し得る。更に、ＣＮ１０６は、他のサービスプロバイダによって所有及び／又は運営される他の有線及び／又は無線ネットワークを含み得る他のネットワーク１１２へのアクセスをＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃに提供し得る。

【0036】

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

【0037】

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

【0038】

インフラストラクチャ基本サービスセット（Basic Service Set、ＢＳＳ）モードのＷＬＡＮは、ＢＳＳのアクセスポイント（ＡＰ）及びＡＰと関連付けられた１つ以上のステーション（station、ＳＴＡ）を有し得る。ＡＰは、配信システム（Distribution System、ＤＳ）若しくはＢＳＳに入る、かつ／又はＢＳＳから出るトラフィックを搬送する別のタイプの有線／無線ネットワークへのアクセス又はインターフェースを有し得る。ＢＳＳ外から生じる、ＳＴＡへのトラフィックは、ＡＰを通って到達し得、ＳＴＡに配信され得る。ＳＴＡからＢＳＳ外の宛先への生じるトラフィックは、ＡＰに送信されて、それぞれの宛先に送信され得る。ＢＳＳ内のＳＴＡどうしの間のトラフィックは、例えば、ＡＰを介して送信され得、ソースＳＴＡは、ＡＰにトラフィックを送信し得、ＡＰは、トラフィックを宛先ＳＴＡに配信し得。ＢＳＳ内のＳＴＡ間のトラフィックは、ピアツーピアトラフィックとしてみなされ、かつ／又は参照され得る。ピアツーピアトラフィックは、ソースＳＴＡと宛先ＳＴＡとの間で（例えば、それらの間で直接的に）、直接リンクセットアップ（direct link setup、ＤＬＳ）で送信され得る。特定の代表的な実施形態では、ＤＬＳは、８０２．１１ｅ ＤＬＳ又は８０２．１１ｚトンネル化ＤＬＳ（tunneled DLS、ＴＤＬＳ）を使用し得る。独立ＢＳＳ（Independent BSS、ＩＢＳＳ）モードを使用するＷＬＡＮは、ＡＰを有さない場合があり、ＩＢＳＳ内又はそれを使用するＳＴＡどうし（例えば、ＳＴＡの全部）は互いに直接通信し得る。通信のＩＢＳＳモードは、本明細書では、「アドホック」通信モードと称され得る。

【0039】

８０２．１１ａｃインフラストラクチャ動作モード又は同様の動作モードを使用するときに、ＡＰは、プライマリチャネルなどの固定チャネル上にビーコンを送信し得る。一次チャネルは、固定幅（例えば、２０ＭＨｚ幅の帯域幅）又はシグナリングを介して動的に設定される幅であり得る。プライマリチャネルは、ＢＳＳの動作チャネルであり得、ＡＰとの接続を確立するためにＳＴＡによって使用され得る。いくつかの代表的な実施形態では、例えば、８０２．１１システムにおいて、衝突回避を備えたキャリア感知多重アクセス（Carrier Sense Multiple Access/Collision Avoidance、ＣＳＭＡ／ＣＡ）が実装され得る。ＣＳＭＡ／ＣＡの場合、ＡＰを含むＳＴＡ（例えば、全てのＳＴＡ）は、プライマリチャネルを感知し得る。プライマリチャネルが特定のＳＴＡによってビジーであると感知され／検出され、かつ／又は判定される場合、特定のＳＴＡはバックオフされ得る。１つのＳＴＡ（例えば、１つのステーションのみ）は、所与のＢＳＳにおいて、任意の所与の時間に送信し得る。

【0040】

高スループット（High Throughput、ＨＴ）ＳＴＡは、通信のための４０ＭＨｚ幅のチャネルを使用し得るが、この４０ＭＨｚ幅のチャネルは、例えば、プライマリ２０ＭＨｚチャネルと、隣接又は非隣接の２０ＭＨｚチャネルとの組合せを介して形成され得る。

【0041】

非常に高いスループット（Very High Throughput、ＶＨＴ）のＳＴＡは、２０ＭＨｚ、４０ＭＨｚ、８０ＭＨｚ、及び／又は１６０ＭＨｚ幅のチャネルをサポートし得る。上記の４０ＭＨｚ及び／又は８０ＭＨｚ幅のチャネルは、連続する２０ＭＨｚチャネルどうしを組み合わせることによって形成され得る。１６０ＭＨｚチャネルは、８つの連続する２０ＭＨｚチャネルを組み合わせることによって、又は８０＋８０構成と称され得る２つの連続していない８０ＭＨｚチャネルを組み合わせることによって、形成され得る。８０＋８０構成の場合、チャネル符号化後、データは、データを２つのストリームに分割し得るセグメントパーサを通過し得る。逆高速フーリエ変換（Inverse Fast Fourier Transform、ＩＦＦＴ）処理及び時間ドメイン処理は、各ストリームで別々に行われ得る。ストリームは、２つの８０ＭＨｚチャネルにマッピングされ得、データは、送信ＳＴＡによって送信され得る。受信ＳＴＡの受信機では、８０＋８０構成に対する上記で説明される動作を逆にされ得、組み合わされたデータを媒体アクセス制御（Medium Access Control、ＭＡＣ）に送信し得る。

【0042】

サブ１ＧＨｚの動作モードは、８０２．１１ａｆ及び８０２．１１ａｈによってサポートされる。チャネル動作帯域幅及びキャリアは、８０２．１１ｎ及び８０２．１１ａｃで使用されるものと比較して、８０２．１１ａｆ及び８０２．１１ａｈでは低減される。８０２．１１ａｆは、ＴＶホワイトスペース（TV White Space、ＴＶＷＳ）スペクトルにおいて、５ＭＨｚ、１０ＭＨｚ及び２０ＭＨｚ帯域幅をサポートし、８０２．１１ａｈは、非ＴＶＷＳスペクトルを使用して、１ＭＨｚ、２ＭＨｚ、４ＭＨｚ、８ＭＨｚ、及び１６ＭＨｚ帯域幅をサポートする。代表的な実施形態によれば、８０２．１１ａｈは、マクロカバレッジエリア内のＭＴＣデバイスなど、メータタイプの制御／マシンタイプ通信をサポートし得る。ＭＴＣデバイスは、例えば、特定の、かつ／又は限定された帯域幅のためのサポート（例えば、そのためのみのサポート）を含む、限定された能力を有し得る。ＭＴＣデバイスは、（例えば、非常に長いバッテリ寿命を維持するために）閾値を超えるバッテリ寿命を有するバッテリを含み得る。

【0043】

複数のチャネル、並びに８０２．１１ｎ、８０２．１１ａｃ、８０２．１１ａｆ、及び８０２．１１ａｈなどのチャネル帯域幅をサポートし得るＷＬＡＮシステムは、プライマリチャネルとして指定され得るチャネルを含む。プライマリチャネルは、ＢＳＳにおける全てのＳＴＡによってサポートされる最大共通動作帯域幅に等しい帯域幅を有し得る。プライマリチャネルの帯域幅は、最小帯域幅動作モードをサポートするＢＳＳで動作する全てのＳＴＡの中から、ＳＴＡによって設定され、かつ／又は制限され得る。８０２．１１ａｈの例では、プライマリチャネルは、ＡＰ及びＢＳＳにおける他のＳＴＡが２ＭＨｚ、４ＭＨｚ、８ＭＨｚ、１６ＭＨｚ、及び／又は他のチャネル帯域幅動作モードをサポートする場合であっても、１ＭＨｚモードをサポートする（例えば、それのみをサポートする）ＳＴＡ（例えば、ＭＴＣタイプデバイス）に対して１ＭＨｚ幅であり得る。キャリア感知及び／又はネットワーク配分ベクトル（Network Allocation Vector、ＮＡＶ）設定は、プライマリチャネルの状態に依存し得る。例えば、ＡＰに送信する（１ＭＨｚ動作モードのみをサポートする）ＳＴＡに起因して一次チャネルがビジーである場合、周波数帯域の大部分がアイドルのままであり、利用可能であり得るとしても、利用可能な周波数帯域全体がビジーであるとみなされ得る。

【0044】

米国では、８０２．１１ａｈにより使用され得る利用可能な周波数帯域は、９０２ＭＨｚ～９２８ＭＨｚである。韓国では、利用可能な周波数帯域は９１７．５ＭＨｚ～９２３．５ＭＨｚである。日本では、利用可能な周波数帯域は９１６．５ＭＨｚ～９２７．５ＭＨｚである。８０２．１１ａｈに利用可能な総帯域幅は、国のコードに応じて６ＭＨｚ～２６ＭＨｚである。

【0045】

図１Ｄは、一実施形態によるＲＡＮ１１３及びＣＮ１１５を示すシステム図である。上記のように、ＲＡＮ１１３は、ＮＲ無線技術を用いて、エアインターフェース１１６を介してＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃと通信し得る。ＲＡＮ１１３はまた、ＣＮ１１５と通信し得る。

【0046】

ＲＡＮ１１３は、ｇＮＢ１８０ａ、１８０ｂ、１８０ｃを含み得るが、ＲＡＮ１１３は、一実施形態との一貫性を有しながら、任意の数のｇＮＢを含み得ることが理解されよう。ｇＮＢ１８０ａ、１８０ｂ、１８０ｃは各々、エアインターフェース１１６を介してＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃと通信するための１つ以上のトランシーバを含み得る。一実施形態では、ｇＮＢ１８０ａ、１８０ｂ、１８０ｃは、ＭＩＭＯ技術を実装し得る。例えば、ｇＮＢ１８０ａ、１０８ｂは、ビームフォーミングを利用して、ｇＮＢ１８０ａ、１８０ｂ、１８０ｃに信号を送信及び／又は受信し得る。したがって、ｇＮＢ１８０ａは、例えば、複数のアンテナを使用して、ＷＴＲＵ１０２ａに無線信号を送信し、かつ／又はＷＴＲＵ１０２ａから無線信号を受信し得る。一実施形態では、ｇＮＢ１８０ａ、１８０ｂ、１８０ｃは、キャリアアグリゲーション技術を実装し得る。例えば、ｇＮＢ１８０ａは、複数のコンポーネントキャリアをＷＴＲＵ１０２ａ（図示せず）に送信し得る。これらのコンポーネントキャリアのサブセットは、未認可スペクトル上にあり得、残りのコンポーネントキャリアは、認可スペクトル上にあり得る。一実施形態では、ｇＮＢ１８０ａ、１８０ｂ、１８０ｃは、多地点協調（Coordinated Multi-Point、ＣｏＭＰ）技術を実装し得る。例えば、ＷＴＲＵ１０２ａは、ｇＮＢ１８０ａ及びｇＮＢ１８０ｂ（及び／又はｇＮＢ１８０ｃ）からの協調送信を受信し得る。

【0047】

ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃは、拡張可能なヌメロロジと関連付けられた送信を使用して、ｇＮＢ１８０ａ、１８０ｂ、１８０ｃと通信し得る。例えば、ＯＦＤＭシンボル間隔及び／又はＯＦＤＭサブキャリア間隔は、無線送信スペクトルの異なる送信、異なるセル、及び／又は異なる部分に対して変化し得る。ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃは、（例えば、様々な数のＯＦＤＭシンボルを含む、かつ／又は様々な長さの絶対時間が持続する）様々な又はスケーラブルな長さのサブフレーム又は送信時間間隔（transmission time interval、ＴＴＩ）を使用して、ｇＮＢ１８０ａ、１８０ｂ、１８０ｃと通信し得る。

【0048】

ｇＮＢ１８０ａ、１８０ｂ、１８０ｃは、スタンドアロン構成及び／又は非スタンドアロン構成でＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃと通信するように構成され得る。スタンドアロン構成では、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃは、他のＲＡＮ（例えば、ｅＮｏｄｅ－Ｂ１６０ａ、１６０ｂ、１６０ｃなど）にアクセスすることなく、ｇＮＢ１８０ａ、１８０ｂ、１８０ｃと通信し得る。スタンドアロン構成では、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃは、モビリティアンカポイントとしてｇＮＢ１８０ａ、１８０ｂ、１８０ｃのうちの１つ以上を利用し得る。スタンドアロン構成では、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃは、未認可バンドにおける信号を使用して、ｇＮＢ１８０ａ、１８０ｂ、１８０ｃと通信し得る。非スタンドアロン構成では、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃは、ｇＮＢ１８０ａ、１８０ｂ、１８０ｃと通信し、これらに接続する一方で、ｅＮｏｄｅ－Ｂ１６０ａ、１６０ｂ、１６０ｃなどの別のＲＡＮとも通信し、これらに接続し得る。例えば、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃは、１つ以上のｇＮＢ１８０ａ、１８０ｂ、１８０ｃ及び１つ以上のｅＮｏｄｅ－Ｂ１６０ａ、１６０ｂ、１６０ｃと実質的に同時に通信するためのＤＣ原理を実装し得る。非スタンドアロン構成では、ｅＮｏｄｅ－Ｂ１６０ａ、１６０ｂ、１６０ｃは、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃのモビリティアンカとして機能し得るが、ｇＮＢ１８０ａ、１８０ｂ、１８０ｃは、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃをサービスするための追加のカバレッジ及び／又はスループットを提供し得る。

【0049】

ｇＮＢ１８０ａ、１８０ｂ、１８０ｃの各々は、特定のセル（図示せず）と関連付けられ得、無線リソース管理決定、ハンドオーバ決定、ＵＬ及び／又はＤＬにおけるユーザのスケジューリング、ネットワークスライシングのサポート、デュアルコネクティビティ、ＮＲとＥ－ＵＴＲＡとの間のインターワーキング、ユーザプレーン機能（User Plane Function、ＵＰＦ）１８４ａ、１８４ｂへのユーザプレーンデータのルーティング、アクセス及びモビリティ管理機能（Access and Mobility Management Function、ＡＭＦ）１８２ａ、１８２ｂへの制御プレーン情報のルーティングなどを処理するように構成され得る。図１Ｄに示すように、ｇＮＢ１８０ａ、１８０ｂ、１８０ｃは、Ｘｎインターフェースを介して互いに通信し得る。

【0050】

図１Ｄに示されるＣＮ１１５は、少なくとも１つのＡＭＦ１８２ａ、１８２ｂ、少なくとも１つのＵＰＦ１８４ａ、１８４ｂ、少なくとも１つのセッション管理機能（Session Management Function、ＳＭＦ）１８３ａ、１８３ｂ及び場合によってはデータネットワーク（Data Network、ＤＮ）１８５ａ、１８５ｂを含み得る。前述の要素の各々は、ＣＮ１１５の一部として示されているが、これらの要素のいずれも、ＣＮオペレータ以外のエンティティによって所有及び／又は操作され得ることが理解されよう。

【0051】

ＡＭＦ１８２ａ、１８２ｂは、Ｎ２インターフェースを介してＲＡＮ１１３におけるｇＮＢ１８０ａ、１８０ｂ、１８０ｃのうちの１つ以上に接続され得、制御ノードとして機能し得る。例えば、ＡＭＦ１８２ａ、１８２ｂは、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃのユーザの認証、ネットワークスライシングのサポート（例えば、異なる要件を有する異なるＰＤＵセッションの処理）、特定のＳＭＦ１８３ａ、１８３ｂの選択、登録エリアの管理、ＮＡＳシグナリングの終了、モビリティ管理などの役割を果たすことができる。ネットワークスライスは、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃを利用しているサービスのタイプに基づいて、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃのＣＮサポートをカスタマイズするために、ＡＭＦ１８２ａ、１８２ｂによって使用され得る。例えば、異なるネットワークスライスは、高信頼低遅延（ultra-reliable low latency、ＵＲＬＬＣ）アクセスに依存するサービス、高速大容量（enhanced massive mobile broadband、ｅＭＢＢ）アクセスに依存するサービス、マシンタイプ通信（machine type communication、ＭＴＣ）アクセスのためのサービス、及び／又は同様のものなどの異なる使用事例のために確立され得る。ＡＭＦ１６２は、ＲＡＮ１１３と、ＬＴＥ、ＬＴＥ－Ａ、ＬＴＥ－Ａ Ｐｒｏ、及び／又はＷｉＦｉなどの非３ＧＰＰアクセス技術などの他の無線技術を採用する他のＲＡＮ（図示せず）との間で切り替えるための制御プレーン機能を提供し得る。

【0052】

ＳＭＦ１８３ａ、１８３ｂは、Ｎ１１インターフェースを介して、ＣＮ１１５におけるＡＭＦ１８２ａ、１８２ｂに接続され得る。ＳＭＦ１８３ａ、１８３ｂはまた、Ｎ４インターフェースを介して、ＣＮ１１５におけるＵＰＦ１８４ａ、１８４ｂに接続され得る。ＳＭＦ１８３ａ、１８３ｂは、ＵＰＦ１８４ａ、１８４ｂを選択及び制御し、ＵＰＦ１８４ａ、１８４ｂを通るトラフィックのルーティングを構成し得る。ＳＭＦ１８３ａ、１８３ｂは、ＷＴＲＵ ＩＰアドレスを管理して割り当てること、ＰＤＵセッションを管理すること、ポリシー執行及びＱｏＳを制御すること、ダウンリンクデータ通知を提供することなど、他の機能を実施し得る。ＰＤＵセッションタイプは、ＩＰベース、非ＩＰベース、イーサネットベースなどであり得る。

【0053】

ＵＰＦ１８４ａ、１８４ｂは、Ｎ３インターフェースを介して、ＲＡＮ１１３におけるｇＮＢ１８０ａ、１８０ｂ、１８０ｃのうちの１つ以上に接続され得、これは、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃとＩＰ対応デバイスとの間の通信を容易にするために、インターネット１１０などのパケット交換ネットワークへのアクセスをＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃに提供し得る。ＵＰＦ１８４、１８４ｂは、パケットをルーティングして転送すること、ユーザプレーンポリシーを執行すること、マルチホームＰＤＵセッションをサポートすること、ユーザプレーンＱｏＳを処理すること、ダウンリンクパケットをバッファすること、モビリティアンカリングを提供することなど、他の機能を実施し得る。

【0054】

ＣＮ１１５は、他のネットワークとの通信を容易にし得る。例えば、ＣＮ１１５は、ＣＮ１１５とＰＳＴＮ１０８との間のインターフェースとして機能するＩＰゲートウェイ（例えば、ＩＰマルチメディアサブシステム（ＩＭＳ）サーバ）を含むか、又はそれと通信し得る。更に、ＣＮ１１５は、他のサービスプロバイダによって所有及び／又は運営される他の有線及び／又は無線ネットワークを含み得る他のネットワーク１１２へのアクセスをＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃに提供し得る。一実施形態では、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃは、ＵＰＦ１８４ａ、１８４ｂへのＮ３インターフェース、及びＵＰＦ１８４ａ、１８４ｂとＤＮ１８５ａ、１８５ｂとの間のＮ６インターフェースを介して、ＵＰＦ１８４ａ、１８４ｂを通じてローカルデータネットワーク（local Data Network、ＤＮ）１８５ａ、１８５ｂに接続され得る。

【0055】

図１Ａ～図１Ｄ、及び図１Ａ～図１Ｄの対応する説明から見て、ＷＴＲＵ１０２ａ～ｄ、基地局１１４ａ～ｂ、ｅＮｏｄｅ－Ｂ１６０ａ～ｃ、ＭＭＥ１６２、ＳＧＷ１６４、ＰＧＷ１６６、ｇＮＢ１８０ａ～ｃ、ＡＭＦ１８２ａ～ｂ、ＵＰＦ１８４ａ～ｂ、ＳＭＦ１８３ａ～ｂ、ＤＮ１８５ａ～ｂ、及び／又は本明細書に記載される任意の他のデバイスのうちの１つ以上に関する、本明細書に記載される機能のうちの１つ以上又は全ては、１つ以上のエミュレーションデバイス（図示せず）によって実施され得る。エミュレーションデバイスは、本明細書に説明される機能の１つ以上又は全てをエミュレートするように構成された１つ以上のデバイスであり得る。例えば、エミュレーションデバイスを使用して、他のデバイスを試験し、かつ／又はネットワーク及び／若しくはＷＴＲＵ機能をシミュレートし得る。

【0056】

エミュレーションデバイスは、ラボ環境及び／又はオペレータネットワーク環境における他のデバイスの１つ以上の試験を実装するように設計され得る。例えば、１つ以上のエミュレーションデバイスは、通信ネットワーク内の他のデバイスを試験するために、有線及び／又は無線通信ネットワークの一部として完全に若しくは部分的に実装され、かつ／又は展開されている間、１つ以上若しくは全ての機能を実行し得る。１つ以上のエミュレーションデバイスは、有線及び／又は無線通信ネットワークの一部として一時的に実装／展開されている間、１つ以上若しくは全ての機能を実行し得る。エミュレーションデバイスは、試験を目的として別のデバイスに直接結合され得、かつ／又は地上波無線通信を使用して試験を実行し得る。

【0057】

１つ以上のエミュレーションデバイスは、有線及び／又は無線通信ネットワークの一部として実装／展開されていない間、全てを含む１つ以上の機能を実行し得る。例えば、エミュレーションデバイスは、１つ以上のコンポーネントの試験を実装するために、試験実験室での試験シナリオ、並びに／又は展開されていない（例えば、試験用の）有線及び／若しくは無線通信ネットワークにおいて利用され得る。１つ以上のエミュレーションデバイスは、試験機器であり得る。ＲＦ回路（例えば、１つ以上のアンテナを含み得る）を介した直接ＲＦ結合及び／又は無線通信は、データを送信及び／又は受信するように、エミュレーションデバイスによって使用され得る。

【0058】

（詳細な説明）
車両通信（Ｖ２Ｘ）の場合、例えば、（例えば、ＬＴＥ）リリース１４（Ｒ１４）モード３及び４、及びリリース１６（Ｒ１６）モード２などの様々な動作モードが存在し得る。モード２の動作の場合、Ｒ１６ Ｖ２Ｘ ＷＴＲＵは、例えば、いかなる中央スケジューリング及びＷＴＲＵ間連携なしで、感知に基づいて、リソース（再）選択を実行する。そのような場合、感知機構は、（例えば、特に輻輳したシナリオで）利用可能なリソースが限定されたときに、例えば、ＲＳＲＰ閾値の増加に起因して（例えば、潜在的な）衝突をもたらす可能性がある。更に、そのような場合、（例えば、そのような）衝突が半永続的なリソース予約に対して発生する場合、衝突は永続的になり、連続したパケット損失を引き起こす可能性がある。結果として、Ｒ１６ ＮＲサイドリンク（ＳＬ）は、例えば、チャネルがビジー状態であるときの条件（例えば、輻輳シナリオなど）下で、高信頼低遅延を確保しない（例えば、確保することができない）。

【0059】

リリース１７（Ｒ１７）は、（例えば、高度）動作シナリオにおける超高信頼低遅延通信（ＵＲＬＬＣ）タイプＳＬ使用事例をサポートする。（例えば、上述のように）特定の送信に対して制限されたサポートを提供するＲ１６を考慮して、モード２の動作におけるＷＴＲＵ間連携が、例えば、Ｒ１７について考慮されている。すなわち、Ｒ１７について、ＳＬ送信の信頼性及び遅延を改善するためのＵＥ間連携が考慮される。そのような連携の１つの形態は、別のＷＴＲＵに支援情報を提供するＷＴＲＵである。支援情報は、ＷＴＲＵによって判定されたリソースのセットとすることができる。例えば、ＷＴＲＵ間連携は、モード２でリソースのセットを判定し、第２のＷＴＲＵにそれらを送信する第１のＷＴＲＵを含み、その結果、第２のＷＴＲＵは、自身の送信のためのリソース選択においてこれを考慮に入れることができる。

【0060】

しかしながら、モード２の場合、（例えば、従来、関連技術分野で、Ｒ１７でなど）、ＷＴＲＵ間の連携の不足があり（例えば、連携がなく）、例えば、あるＷＴＲＵは、例えば、別のＷＴＲＵが送信のためのトラフィックを有するかどうか、又はいつ有するかを知らず、更には、あるＷＴＲＵは、別のＷＴＲＵがどのタイプのリソースを使用するかを知らない。そのような連携の欠如は、過剰な数の必要な送信をもたらし得る。したがって、過剰な数の必要な送信を回避しながら、ＷＴＲＵ間連携特徴を可能にする必要がある。少なくとも上述の問題（例えば、ＷＴＲＵ間連携の欠如）を考慮に入れて、以下の問題／疑問のうちのいずれかの解決策を提供する（例えば、対応する、解決するなど）必要がある：（１）ＷＴＲＵ（複数可）が支援情報を提供するか。（２）どのＷＴＲＵ（複数可）が支援情報を要求及び／又は受信するか、（３）そのような連携のトリガ条件は何か、（４）ＷＴＲＵ（複数可）が、例えば、別のＷＴＲＵ（複数可）のリソース選択に有用な支援情報をどのように取得するか、（５）支援情報が何を含むか、（６）支援情報がどのように送信されるか、（７）別のＷＴＲＵ（複数可）がそのリソース選択においてどのように支援情報を使用するか。

【0061】

実施形態によれば、ＷＴＲＵは、支援情報を、例えば、他のＷＴＲＵ、又は任意の他の類似及び／又は適切なネットワークノードに送信し得る（例えば、支援送信を実行し得る）。実施形態によれば、ＷＴＲＵは、例えば、他のＷＴＲＵによる送信のためのＳＬリソース選択を支援する支援送信を実行し得る。実施形態によれば、支援送信は、ＳＬリソースのセットを含む情報を搬送し得る（例えば、支援を含む）。実施形態によれば、ＷＴＲＵは、支援ＷＴＲＵ（例えば、支援側ＷＴＲＵ）であり得る。すなわち、本明細書で論じられる及び／又は言及されるように、ＷＴＲＵは、例えば、支援送信を実行する場合に、支援側ＷＴＲＵと称されることがある。実施形態によれば、ＷＴＲＵ（複数可）は、支援送信をトリガするか、又は受信するかのいずれかを行い得る。実施形態によれば、支援送信をトリガする及び／又は受信するＷＴＲＵ（複数可）は、被支援側ＷＴＲＵと称されることがある。実施形態によれば、本明細書では、支援側ＷＴＲＵ及び被支援側ＷＴＲＵは、（例えば、特定の）支援情報送信に関してそのように称されることがある。

【0062】

支援送信のトリガのＷＴＲＵの判定
実施形態によれば、ＷＴＲＵは、支援送信を実行するか、及び支援側ＷＴＲＵになるかのいずれかを判定し得る。実施形態によれば、ＷＴＲＵは、任意の数の条件（例えば、トリガ）に従って（例えば、基づいて）、支援送信を実行する、及び／又は支援側ＷＴＲＵとなると判定し得る。実施形態によれば、（例えば、支援送信を実行する、及び／又は支援側ＷＴＲＵになるのいずれかを判定するために使用される）そのようなトリガ及び／又は条件には、以下が挙げられ得る：（１）ＷＴＲＵが、例えば、被支援側ＷＴＲＵからの支援送信の明示的な要求を受信する；（２）ＷＴＲＵが、被支援側ＷＴＲＵによって半永続的リソース予約を受信する；（３）ＷＴＲＵが、被支援側ＷＴＲＵからＣＳＩ要求を受信する；（４）ＷＴＲＵが、例えば、被支援側ＷＴＲＵによる／との、セミ永続的リソース予約に適用可能な（例えば、いくつかの）衝突を検出する；（５）ＷＴＲＵが、被支援側ＷＴＲＵからのいくつかのＰＳＳＣＨを復号化することができず、例えば、対応するＨＡＲＱ ＮＡＣＫ送信を送信する；（６）ＷＴＲＵが、被支援側ＷＴＲＵからのリソース予約に対応するいくつかのＰＳＳＣＨを復号することができない；（７）ＷＴＲＵが、被支援側ＷＴＲＵから、（本明細書で言及されるように、構成された、事前に構成された、及び（事前に）構成されたという文言は、互換可能に使用される）閾値を下回る（例えば、超えて延びる）範囲に位置する；（８）ＷＴＲＵが、（事前に）構成された閾値よりも高い輻輳メトリック（例えば、チャネルビジー比（ＣＢＲ））を測定（例えば、検出、判定など）する；（９）ＷＴＲＵが、被支援側ＷＴＲＵに適用可能なＳＬリンク確立（例えば、手順）シグナリング中（例えば、間）の支援送信のための構成を受信する、（１０）ＷＴＲＵが、（例えば、（事前に）構成された、特定の、などの）タイプ（例えば、車両ＷＴＲＵ、歩行者ユーザ、交通弱者（ＶＲＵ）、第一対応者など）である。実施形態によれば、ＷＴＲＵは、例えば、被支援側ＷＴＲＵに関連付けられたデータが（例えば、送信のために）利用可能である場合、支援送信をトリガし得る（例えば、実施、実行、送信などを判定し得る）。実施形態によれば、ＷＴＲＵは、例えば、Ｖ２Ｘアプリケーション、データグループ、ＷＴＲＵグループ、アプリケーショングループなどのいずれかについて、例えば、周期的支援送信を実行するように（例えば、事前に）構成され得る。

【0063】

図２は、実施形態による、明示的な要求によってトリガされた支援情報送信を示す図である。

【0064】

実施形態によれば、支援情報の送信（例えば、ＷＴＲＵ支援送信）は、（例えば、明示的な、信号で伝達された、判定された、などの）要求によってトリガされ得る。実施形態によれば、支援送信の（例えば、そのような、明示的な、信号で伝達された、判定された、などの）要求（例えば、支援送信要求）の送信は、例えば、（例えば、特定の）条件に従って実行（例えば、トリガ、判定など）され得る。実施形態によれば、ＷＴＲＵは、例えば、送信ブロック（ＴＢ）のリソース（再）選択がより上位の層によってトリガされる場合に、明示的な支援送信要求を送信するか、被支援側ＷＴＲＵになるかのいずれかを判定し得る。

【0065】

実施形態によれば、ＷＴＲＵは、以下の条件（例えば、トリガ）のいずれかに従って（例えば、基づいて、満たしてなど）、（例えば、上位層によってトリガされるＴＢのリソース（再）選択に加えて、及び／又はその代わりに）明示的な支援送信要求を送信する、及び被支援側ＷＴＲＵになるのいずれかを判定する：（１）（例えば、残りの）パケット遅延バジェットが（事前に）構成された閾値を超える（例えば、残りのパケット遅延バジェットは、支援送信要求及び支援送信に関連付けられた（例えば、それらによって生じた）往復伝搬及びＷＴＲＵ処理時間を可能にする；（２）信頼性が、（事前に）構成された閾値を超える（例えば、支援送信が、１Ｅ－５で／のＢＬＥＲなどの高信頼ＴＢの送信によってトリガされる）；（３）優先度が、（事前に）構成された閾値を超える（例えば、ＷＴＲＵ間支援手順が、高優先度のＴＢの送信によってトリガされ得る）；（４）輸送パケットのサイズが、（事前に）構成された閾値を超える（例えば、支援送信が、多数のサブチャネルを必要とする大きなＴＢの送信によってトリガされ得る）；（５）支援送信要求が送信されるＷＴＲＵまでの距離（例えば、意図される）ＷＴＲＵまでの距離が、（事前に）構成された閾値を下回る。

【0066】

実施形態によれば、支援送信要求の内容は、様々な情報を示し得る。実施形態によれば、被支援側ＷＴＲＵは、例えば、支援送信要求において、以下の（例えば、リソース（再）選択）情報のいずれかを含み得る：（１）例えば、ＰＳＳＣＨリソースがそこから報告され得るリソースプール；（２）例えば、被支援側ＷＴＲＵによる送信のために使用されるＴＢのＬ１優先度；（３）例えば、被支援側ＷＴＲＵによる送信のために使用されるＴＢの残りのパケット遅延バジェット（ＰＤＢ）（すなわち、スロット内）；（４）Ｔ１＿ＴＢ、例えば、ＴＢが送信され得る送信窓の開始；（５）Ｔ２＿ＴＢ、例えば、送信窓の終了、（６）例えば、ＴＢのＰＳＳＣＨ送信に使用されるためのサブチャネルの数；及び（７）（ｉ）リソースセットで要求されたリソースの数、及び（ｉｉ）送信窓内の候補リソースの総数の比など、リソースセット内で必要な（要求される）リソースの数。

【0067】

実施形態によれば、（例えば、被支援側）ＷＴＲＵは、送信に使用されるＴＢの残りのＰＤＢ、支援送信要求のために予約された時間リソースのうちのいずれかに従って（例えば、基づいて）、例えば、支援送信要求に含まれる（例えば、残りの）ＰＤＢを判定し得る。実施形態によれば、ＷＴＲＵは、以下の式［１］に示されるように、支援送信要求に含まれる残りのＰＤＢを計算し得る：

【0068】

【数1】

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

結論
特徴及び要素は、特定の組合せにおいて上で説明されているが、当業者は、各特徴又は要素が単独で又は他の特徴及び要素との任意の組合せで使用され得ることを理解されよう。更に、本明細書に説明される方法は、コンピュータ又はプロセッサによる実行のためにコンピュータ可読媒体に組み込まれたコンピュータプログラム、ソフトウェア又はファームウェアに実装され得る。非一時的なコンピュータ可読記憶媒体の例としては、読み取り専用メモリ（ＲＯＭ）、ランダムアクセスメモリ（ＲＡＭ）、レジスタ、キャッシュメモリ、半導体メモリデバイス、内部ハードディスク及びリムーバブルディスクなどの磁気媒体、磁気光学媒体及びＣＤ－ＲＯＭディスク及びデジタル多用途ディスク（digital versatile disk、ＤＶＤ）などの光学媒体が挙げられるが、これらに限定されない。ソフトウェアと関連付けられたプロセッサを使用して、ＵＥ、ＷＴＲＵ、端末、基地局、ＲＮＣ又は任意のホストコンピュータにおいて使用するための無線周波数トランシーバを実装し得る。

【0173】

更に、上記の実施形態では、処理プラットフォーム、コンピューティングシステム、コントローラ、並びに制約サーバ及びプロセッサを含む集合点／サーバを含む他のデバイスが記載されている。これらのデバイスは、少なくとも１つの中央処理装置（「ＣＰＵ」）及びメモリを含み得る。コンピュータプログラミングの技術分野における当業者の慣例によれば、動作、及び演算又は命令の記号表現の言及は、様々なＣＰＵ及びメモリによって実行され得る。そのような動作及び演算又は命令は、「実行」、「コンピュータ実行」、又は「ＣＰＵ実行」されることと呼ばれ得る。

【0174】

当該技術分野における通常の技術を有する者には、動作及び記号的に表現された演算又は命令が、ＣＰＵによる電気信号の操作を含むことが理解されるであろう。電気システムは、電気信号の結果的な変換又は減少を引き起こすことができるデータビットを表し、メモリシステムのメモリ位置にデータビットを維持し、それによってＣＰＵの動作及び他の信号の処理を再構成又は別の方法で変更する。データビットが維持されるメモリ位置は、データビットに対応する、又はデータビットを表す特定の電気的特性、磁気的特性、光学的特性、又は有機的特性を有する物理的位置である。例示的な実施形態は、上述したプラットフォーム又はＣＰＵに限定されず、他のプラットフォーム及びＣＰＵが、提供される方法をサポートし得ることを理解されたい。

【0175】

データビットはまた、磁気ディスク、光学ディスク、及び任意の他の揮発性（例えば、ランダムアクセスメモリ（「ＲＡＭ」））又はＣＰＵによって読み取り可能な不揮発性（例えば、読み取り専用メモリ（「ＲＯＭ」））大容量記憶システムを含む、コンピュータ可読媒体上に維持され得る。コンピュータ可読媒体は、処理システム上に排他的に存在するか、又は処理システムに対してローカル又はリモートであり得る複数の相互接続された処理システム間で分散された、協調的又は相互接続されたコンピュータ可読媒体を含んでもよい。代表的な実施形態は、上述のメモリに限定されず、他のプラットフォーム及びメモリが、記載された方法をサポートし得るということが理解される。

【0176】

例示的な実施形態において、本明細書に記載されている動作、プロセスなどのいずれも、コンピュータ可読媒体に格納されたコンピュータ可読命令として実装されてもよい。コンピュータ可読命令は、移動体、ネットワーク要素、及び／又は任意の他のコンピューティングデバイスのプロセッサによって実行され得る。

【0177】

システムの態様のハードウェア実装とソフトウェア実装の間には、ほとんど区別がない。ハードウェア又はソフトウェアの使用は、一般に（常にではないが、特定の状況では、ハードウェアとソフトウェアとの間の選択が大きな意味を持ち得る）、コスト対効率のトレードオフを意味する設計上の選択事項である。本明細書に記載されているプロセス及び／又はシステム及び／又は他の技術が効果的であり得る様々なビークル（例えばハードウェア、ソフトウェア、及び／又はファームウェア）が存在し得、好ましいビークルは、プロセス及び／又はシステム及び／又は他の技術が配備される状況によって変化し得る。例えば、実装者が、速度及び正確性が最重要であると判断した場合、実装者は、主にハードウェア及び／又はファームウェアのビークルを選択することができる。柔軟性が最重要である場合、実装者は、主にソフトウェア実装を選択することができる。あるいは、実装者は、ハードウェア、ソフトウェア、及び／又はファームウェアの何らかの組合せを選択してもよい。

【0178】

前述の詳細な説明では、ブロック図、フローチャート、及び／又は例の使用を通じて、デバイス及び／又はプロセスの様々な実施形態を示した。そのようなブロック図、フローチャート、及び／又は例が１つ以上の機能及び／又は動作を含む限り、そのようなブロック図、フローチャート、又は例の中の各機能及び／又は各動作は、広範なハードウェア、ソフトウェア、ファームウェア、又はそれらの実質的に任意の組合せによって、個別にかつ／又は集合的に実装されてよいことが当業者には理解されるであろう。好適なプロセッサとしては、例として、汎用プロセッサ、専用プロセッサ、従来型プロセッサ、デジタル信号プロセッサ（ＤＳＰ）、複数のマイクロプロセッサ、ＤＳＰコアと関連する１つ以上のマイクロプロセッサ、コントローラ、マイクロコントローラ、特定用途向け集積回路（ＡＳＩＣ）、アプリケーション特定用途向け標準製品（ＡＳＳＰ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）回路、任意のその他のタイプの集積回路ＩＣ）、及び／又は状態機械が挙げられる。

【0179】

上記では特徴及び要素が特定の組合せにおいて提供されているが、当該技術分野の通常の技術を有する者には、各特徴若しくは各要素を単独で使用する、又は他の特徴及び要素との任意の組合せにおいて使用できることが理解されるであろう。本開示は、本出願に記載されている特定の実施形態の観点において限定されるものではなく、これらの実施形態は、様々な態様の例示として意図されるものである。当業者には明らかなように、本発明の趣旨及び範囲から逸脱することなく、多くの修正及び変形を行うことができる。本出願の説明において使用されているいかなる要素、動作、又は指示も、そのように明示的に提示されていない限り、本発明にとって重要又は本質的であると解釈されるべきではない。本明細書に列挙したものに加えて、本開示の範囲内の機能的に等価な方法及び装置が、上述した説明から、当業者には明らかであろう。そのような修正及び変形は、添付の請求項の範囲に入ることが意図されている。本開示は、添付の請求項の条項によってのみ限定されるものであり、かかる請求項が権利を有する等価物の完全な範囲と共に、限定されるものである。本開示は、特定の方法又はシステムに限定されないことを理解されたい。

【0180】

また、本明細書で使用されている用語は、特定の実施形態（例えば、のみ）を説明することを目的としており、本発明を制限することを意図していないことを理解されたい。本明細書で使用される場合、本明細書で言及される場合、「ユーザ機器」、及びその略語「ＵＥ」は、（１）記載されたインフラストラクチャなどの無線送信及び／又は受信ユニット（ＷＴＲＵ）、（２）記載されたインフラストラクチャのような、ＷＴＲＵのいくつかの実施形態の任意のもの、（３）例示されるようなＷＴＲＵ（例えば記載されたインフラストラクチャなど）の一部又は全ての構造及び機能を有して構成された無線可能及び／又は有線可能な（例えば、テザー可能な）デバイス、（４）記載されるようなＷＴＲＵ（例えば記載されたインフラストラクチャなど）の、全てよりも少ない構造及び機能を有して構成された無線可能及び／又は有線可能デバイス、又は（５）同様のものを意味し得る。本明細書に列挙される任意のＷＴＲＵを表すことができる例示的なＷＴＲＵの詳細。

【0181】

特定の代表的な実施形態では、本明細書に記載の主題のいくつかの部分は、特定用途用集積回路（ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）、デジタル信号プロセッサ（ＤＳＰ）、及び／又は他の統合フォーマットを介して実装され得る。しかしながら、本明細書に開示されている実施形態のいくつかの態様は、その全体又は一部が、１つ以上のコンピュータ上で動作する１つ以上のコンピュータプログラムとして（例えば１つ以上のコンピュータシステム上で動作する１つ以上のプログラムとして）、１つ以上のプロセッサ上で動作する１つ以上のプログラムとして（例えば１つ以上のマイクロプロセッサ上で動作する１つ以上のプログラムとして）、ファームウェアとして、又はこれらの実質的に任意の組合せとして、集積回路において等価的に実施され得ること、並びに、回路を設計すること、及び／又は、ソフトウェア及び／若しくはファームウェアのコードを書くことが、この開示に照らして当業者の技術の範囲内であることが、当業者には認識されるであろう。更に、本明細書に記載されている主題のメカニズムが、様々な形態のプログラム製品として配布され得ること、及び、本明細書に記載されている主題の例示的な実施形態が、配布を実際に行うために使用される特定のタイプの信号担持媒体にかかわらず適用されることが、当業者には理解されるであろう。信号担持媒体の例としては、フロッピーディスク、ハードディスクドライブ、ＣＤ、ＤＶＤ、デジタルテープ、コンピュータメモリなどの記録可能型媒体、並びに、デジタル及び／又はアナログ通信媒体（例えば光ファイバケーブル、導波管、有線通信リンク、無線通信リンクなど）などの伝送型媒体が挙げられ、ただしこれらに限定されない。

【0182】

本明細書に記載されている主題は、場合によっては、異なる他の構成要素内に含まれるか、又は、異なる他の構成要素に接続されている、異なる構成要素を示していることがある。そのような図示されたアーキテクチャは単なる例であり、実際には、同じ機能を達成する他の多くのアーキテクチャが実施され得ることを理解されたい。概念的には、同じ機能を達成するための構成要素の任意の配置は、所望の機能が達成され得るように、効果的に「関連付けられる」。したがって、特定の機能を達成するために本明細書において組み合わされた、任意の２つの構成要素は、アーキテクチャ又は中間構成要素に関係なく、所望の機能が達成されるように、互いに「関連付けられた」として見ることができる。同様に、そのように関連付けられた任意の２つの構成要素は、所望の機能を達成するために互いに「動作可能に接続されている」、又は「動作可能に結合されている」とみなすこともでき、そのように関連付けることができる任意の２つの構成要素は、所望の機能を達成するために互いに「動作可能に結合可能」であるとみなすこともできる。動作可能に結合可能の具体例としては、物理的に嵌合可能かつ／若しくは物理的に相互作用する構成要素、及び／又は、無線で相互作用可能かつ／若しくは無線で相互作用する構成要素、及び／又は、論理的に相互作用するかつ／若しくは論理的に相互作用可能な構成要素が挙げられ、ただしこれらに限定されない。

【0183】

本明細書における実質的に任意の複数形及び／又は単数形の用語の使用に関して、当業者は、文脈及び／又は用途に適切であるように、複数形から単数形に、かつ／又は単数形から複数形に変換することができる。本明細書では、明瞭にする目的で、様々な単数形／複数形の並べ換えが明示的に記載され得る。

【0184】

一般に、本明細書、特に添付の請求項（例えば添付の請求項の本体）において使用されている用語は、一般に「非限定」用語として意図されることが当業者には理解されるであろう（例えば、用語「含んでいる」は、「含んでいるがそれらに限定されない」と解釈するべきであり、用語「有する」は、「を少なくとも有する」と解釈するべきであり、用語「含む」は、「含むがそれらに限定されない」と解釈するべきである）。更に、導入された請求項の特定の数の記載が意図される場合、そのような意図は請求項に明示的に記載されており、そのような記載がない場合、そのような意図は存在しないことが、当業者には理解されるであろう。例えば、１つの項目のみが意図される場合、「単一」という用語又は類似する言葉が使用され得る。理解を助けるために、以下の添付の請求項及び／又は本明細書の説明は、請求項の記載を導入するために「少なくとも１つの」及び「１つ以上の」という導入句の使用を含み得る。しかしながら、このような句の使用は、不定冠詞「ａ」又は「ａｎ」による請求項の記載の導入が、そのような導入された請求項の記載を含む任意の特定の請求項を、１つのそのような記載のみを含む実施形態に制限することを意味するものと解釈すべきではなく、たとえ同じ請求項に、導入句「１つ以上の」又は「少なくとも１つの」及び「ａ」又は「ａｎ」などの不定冠詞が含まれていても同様である（例えば「ａ」及び／又は「ａｎ」は「少なくとも１つの」又は「１つ以上」を意味するものと解釈すべきである）。請求項の記載を導入するために使用される定冠詞の使用も同様である。更に、導入された請求項の特定の数の記載が明示的に記載されている場合でも、かかる記載は少なくとも記載された数を意味するものと解釈されるべきであることが、当業者には認識されるであろう（例えば、他の修飾語なしの「２つの記載」という単純な記載は、少なくとも２つの記載、又は２つ以上の記載を意味する）。更に、「Ａ、Ｂ、及びＣのうちの少なくとも１つ」に類似する表記が使用される場合、一般に、そのような構造は、当業者がその表記を理解するであろう意味として意図される（例えば、「Ａ、Ｂ、及びＣのうちの少なくとも１つを有するシステム」は、Ａのみ、Ｂのみ、Ｃのみ、Ａ及びＢを一緒に、Ａ及びＣを一緒に、Ｂ及びＣを一緒に、並びに／又は、Ａ、Ｂ、及びＣを一緒に、有するシステムを含み、ただしこれらに限定されない）。「Ａ、Ｂ、又はＣのうちの少なくとも１つ」に類似する表記が使用される場合、一般に、そのような構造は、当業者がその表記を理解するであろう意味として意図される（例えば、「Ａ、Ｂ、又はＣのうちの少なくとも１つを有するシステム」は、Ａのみ、Ｂのみ、Ｃのみ、Ａ及びＢを一緒に、Ａ及びＣを一緒に、Ｂ及びＣを一緒に、並びに／又は、Ａ、Ｂ、及びＣを一緒に、有するシステムを含み、ただしこれらに限定されない）。説明、請求項、又は図面のいずれにおいても、２つ以上の代替的な用語を提示する実質的に任意の離接的な語及び／又は句は、用語の一方、用語のいずれか、又は両方の用語を含む可能性を企図するものと理解されるべきであることが、当業者には更に理解されるであろう。例えば、「Ａ又はＢ」という句は、「Ａ」若しくは「Ｂ」又は「Ａ及びＢ」の可能性を含むものと理解されたい。更に、本明細書で使用される、複数の項目のリスト及び／又は複数の項目のカテゴリのリストが後ろに続く用語「～のいずれか」は、項目及び／又は項目のカテゴリの、「のいずれか」、「の任意の組合せ」、「の任意の複数」、及び／又は「の任意の複数の組合せ」を、個別に、又は他の項目及び／又は他の項目のカテゴリとの組合せにおいて、含むことを意図している。更に、本明細書で使用される場合、「セット／組」又は「グループ／群」という用語は、ゼロを含む任意の数のアイテムを含むことが意図される。更に、本明細書で使用される、用語「数」は、ゼロを含む任意の数を含むことを意図している。

【0185】

更に、本開示の特徴又は態様がＭａｒｋｕｓｈ群の観点から説明されている場合、当業者には、本開示がそれによってＭａｒｋｕｓｈ群の任意の個々のメンバー又はメンバーのサブグループの観点からも説明されることが認識されるであろう。

【0186】

当業者には理解されるように、書面による説明を提供するという観点など、あらゆる目的のために、本明細書に開示されるすべての範囲は、その任意の可能な部分範囲及び部分範囲の組合せも包含している。任意の列挙された範囲は、同じ範囲が、少なくとも等しい２分の１、３分の１、４分の１、５分の１、１０分の１などに分解されることを十分に説明して可能にするものとして、容易に認識することができる。非限定的な例として、本明細書に記載されている各範囲は、下位３分の１、中央の３分の１、及び上位３分の１などに容易に分解され得る。また、当業者には理解されるように、「まで」、「少なくとも」、「より大きい」、「より小さい」等のすべての言葉は、言及された数を含み、かつ、上述したように更に部分範囲に分解され得る範囲を意味する。最後に、当業者には理解されるように、範囲は個々の要素を含む。したがって、例えば、１～３個のセルを有するグループは、１個、２個、又は３個のセルを有するグループを指す。同様に、１～５個のセルを有するグループは、１個、２個、３個、４個、又は５個のセルを有するグループを指し、以下同様である。

【0187】

更に、請求項は、特にそのように記載されない限り、提供された順序又は提供された要素に限定されるものとして読まれるべきではない。更に、いかなる請求項においても、「ための手段」という用語の使用は、米国特許法第１１２条、第６項、又はミーンズプラスファンクションの請求項形式に訴えることを意図しており、「ための手段」という用語を有さないいかなる請求項もそのようには意図されていない。

【0188】

ソフトウェアに関連するプロセッサを使用して、無線送受信ユニット（ＷＴＲＵ）、ユーザ機器（ＵＥ）、端末、基地局、モビリティ管理エンティティ（ＭＭＥ）若しくは進化型パケットコア（ＥＰＣ）、又は任意のホストコンピュータで使用するための、無線周波数トランシーバを実装し得る。ＷＴＲＵは、例えば、ソフトウェア無線（ＳＤＲ）などのハードウェア及び／又はソフトウェアに実装されたモジュールと併せて使用されてもよく、また、カメラ、ビデオカメラモジュール、テレビ電話、スピーカ電話、振動デバイス、スピーカ、マイクロフォン、テレビジョントランシーバ、ハンズフリー式ヘッドセット、キーボード、ブルートゥース（登録商標）モジュール、周波数変調（ＦＭ）ラジオユニット、近距離無線通信（ＮＦＣ）モジュール、ＬＣＤディスプレイユニット、有機発光ダイオード（ＯＬＥＤ）ディスプレイユニット、デジタル音楽プレーヤ、メディアプレーヤ、ビデオゲームプレーヤモジュール、インターネットブラウザ、及び／又は無線ローカルエリアネットワーク（ＷＬＡＮ）又は超広帯域（ＵＷＢ）モジュールなどの他のコンポーネントに実装されてもよい。

【0189】

本発明は、通信システムに関して説明されてきたが、システムは、マイクロプロセッサ／汎用コンピュータ（図示せず）上のソフトウェアに実装され得ることが企図される。特定の実施形態では、様々な構成要素の機能のうちの１つ以上は、汎用コンピュータを制御するソフトウェアに実装され得る。

【0190】

更に、本発明は、特定の実施形態を参照して本明細書に例示及び説明されるが、本発明は、示された詳細に限定されることを意図していない。むしろ、請求項の範囲及びその等価物の範囲内にいて、しかも本発明から逸脱することなく、詳細に様々な修正を行うことができる。

【図1A】

【図1B】

【図1C】

【図1D】

【図2】

【図3】

【図4】

【図5】