特表 2024-540906 新無線（ＮＲ）車両対車両（Ｖ２Ｘ）－未認可スペクトルにおいてサイドリンクをスケジューリングするための方法

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

(12)【公報種別】公表特許公報(A)

(11)【公表番号】

(43)【公表日】2024-11-06

(54)【発明の名称】新無線（ＮＲ）車両対車両（Ｖ２Ｘ）－未認可スペクトルにおいてサイドリンクをスケジューリングするための方法

(51)【国際特許分類】

   H04W 76/14 20180101AFI20241029BHJP

   H04W 92/18 20090101ALI20241029BHJP

   H04W 72/54 20230101ALI20241029BHJP

   H04W 76/40 20180101ALI20241029BHJP

   H04W 72/56 20230101ALI20241029BHJP

   H04W 72/25 20230101ALI20241029BHJP

   H04W 72/40 20230101ALI20241029BHJP

   H04W 4/40 20180101ALN20241029BHJP

【ＦＩ】

H04W76/14

H04W92/18

H04W72/54 110

H04W76/40

H04W72/56

H04W72/25

H04W72/40

H04W4/40

【審査請求】有

【予備審査請求】未請求

(21)【出願番号】P 2024523433

(86)(22)【出願日】2022-10-19

(85)【翻訳文提出日】2024-06-06

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

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

(87)【国際公開日】2023-04-27

(31)【優先権主張番号】63/257,381

(32)【優先日】2021-10-19

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

(31)【優先権主張番号】63/326,401

(32)【優先日】2022-04-01

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

(31)【優先権主張番号】63/353,939

(32)【優先日】2022-06-21

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

(81)【指定国・地域】

【公序良俗違反の表示】

（特許庁注：以下のものは登録商標）

１．ＷＣＤＭＡ

２．３ＧＰＰ

(71)【出願人】

【識別番号】510030995

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

(74)【代理人】

【識別番号】110001243

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

(74)【代理人】

【識別番号】110002848

【氏名又は名称】弁理士法人ＮＩＰ＆ＳＢＰＪ国際特許事務所

(72)【発明者】

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

(72)【発明者】

【氏名】トゥーハー、パトリック

(72)【発明者】

【氏名】アルファルハン、ファリス

(72)【発明者】

【氏名】デン、タオ

(72)【発明者】

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

(72)【発明者】

【氏名】リー、ムーン アイエル

【テーマコード（参考）】

5K067

【Ｆターム（参考）】

5K067AA21

5K067EE02

5K067EE10

5K067EE25

(57)【要約】

未認可スペクトルにおけるサイドリンク通信をスケジューリングするための方法及び装置が開示される。第１の無線送信／受信ユニット（ＷＴＲＵ）によって実行される方法は、サイドリンク（ＳＬ）上での送信のための許可を取得すること、第２のＷＴＲＵ又は追加のＷＴＲＵから、第１のチャネル占有時間（ＣＯＴ）情報を含む送信を受信すること、許可が、第２のＷＴＲＵ又は追加のＷＴＲＵに関連付けられたＣＯＴ中にＳＬ上で送信するためのものであるという条件で、第２のＷＴＲＵ、追加のＷＴＲＵ、又は第２のＷＴＲＵと追加のＷＴＲＵの両方から受信された送信から、キャスト情報を決定すること、第２のＷＴＲＵ又は追加のＷＴＲＵから受信された情報に関連付けられたパラメータのセットを使用してリッスンビフォアトーク（ＬＢＴ）手順を実行すること、及びＬＢＴ手順が成功したという条件で、決定されたキャスト情報に基づいて、第２のＣＯＴ情報を含むデータを送信することを含み得る。

【特許請求の範囲】

【請求項1】

第１の無線送信／受信ユニット（ＷＴＲＵ）によって実行される方法であって、前記方法は、
サイドリンク（ＳＬ）上での送信のための許可を取得すること、
第２のＷＴＲＵ又は追加のＷＴＲＵから、第１のチャネル占有時間（ＣＯＴ）情報を含む送信を受信すること、
前記許可が、前記第２のＷＴＲＵ又は追加のＷＴＲＵに関連付けられたＣＯＴ中に前記ＳＬ上で送信するためのものであるという条件で、前記第２のＷＴＲＵ、前記追加のＷＴＲＵ、又は前記第２のＷＴＲＵと前記追加のＷＴＲＵの両方から受信された送信から、キャスト情報を決定すること、
前記第２のＷＴＲＵ又は追加のＷＴＲＵから受信された情報に関連付けられたパラメータのセットを使用して、リッスンビフォアトーク（ＬＢＴ）手順を実行すること、及び
前記ＬＢＴ手順が成功したという条件で、前記決定されたキャスト情報に基づいて、第２のＣＯＴ情報を含むデータを送信することを含む、方法。

【請求項2】

前記許可が基地局から取得される、請求項１に記載の方法。

【請求項3】

前記許可は、前記第１のＷＴＲＵが許可を選択することを介して取得される、請求項１に記載の方法。

【請求項4】

前記キャスト情報がユニキャストキャストタイプを示す、請求項１に記載の方法。

【請求項5】

前記キャスト情報がグループキャストキャストタイプを示す、請求項１に記載の方法。

【請求項6】

前記受信された情報が前記第１のＣＯＴ情報である、請求項１に記載の方法。

【請求項7】

前記受信された情報が前記キャスト情報である、請求項１に記載の方法。

【請求項8】

前記第２のＷＴＲＵ又は第３のＷＴＲＵから受信された情報に関連付けられた、パラメータのセットは送信の優先度を含む、請求項１に記載の方法。

【請求項9】

前記第２のＷＴＲＵ又は第３のＷＴＲＵから受信された情報に関連付けられた、パラメータのセットは間接番号を含む、請求項１に記載の方法。

【請求項10】

前記間接番号は、サイドリンク制御情報（ＳＣＩ）送信を介して前記第２のＷＴＲＵ又は追加のＷＴＲＵから受信される、請求項９に記載の方法。

【請求項11】

第１の無線送信／受信ユニット（ＷＴＲＵ）であって、
受信機、送信機、及びプロセッサを備え、
前記受信機及びプロセッサが、サイドライン（ＳＬ）上で許可を取得するように構成され、
前記受信機が、第２のＷＴＲＵ又は追加のＷＴＲＵから、第１のチャネル占有時間（ＣＯＴ）情報を含む送信を受信するように構成され、
前記プロセッサは、
前記許可が、前記第２のＷＴＲＵ又は追加のＷＴＲＵに関連付けられたＣＯＴ中に前記ＳＬ上で送信するためのものであるという条件で、前記第２のＷＴＲＵ、前記追加のＷＴＲＵ、又は前記第２のＷＴＲＵと前記追加のＷＴＲＵの両方から受信された送信から、キャスト情報を決定すること、及び
前記第２のＷＴＲＵ又は追加のＷＴＲＵから受信された情報に関連付けられたパラメータのセットを使用して、リッスンビフォアトーク（ＬＢＴ）手順を実行するように構成され、
前記送信機は、前記ＬＢＴ手順が成功したという条件で、前記決定されたキャスト情報に基づいて、第２のＣＯＴ情報を含むデータを送信するように構成された、第１の無線送信／受信ユニット（ＷＴＲＵ）。

【請求項12】

前記許可が基地局から取得される、請求項１１に記載の第１のＷＴＲＵ。

【請求項13】

前記許可は、前記第１のＷＴＲＵが許可を選択することを介して取得される、請求項１１に記載の第１のＷＴＲＵ。

【請求項14】

前記キャスト情報がユニキャストキャストタイプを示す、請求項１１に記載の第１のＷＴＲＵ。

【請求項15】

前記キャスト情報がグループキャストキャストタイプを示す、請求項１１に記載の第１のＷＴＲＵ。

【請求項16】

前記受信された情報が前記第１のＣＯＴ情報である、請求項１１に記載の第１のＷＴＲＵ。

【請求項17】

前記受信された情報が前記キャスト情報である、請求項１１に記載の第１のＷＴＲＵ。

【請求項18】

前記第２のＷＴＲＵ又は第３のＷＴＲＵから受信された前記情報に関連付けられた、パラメータのセットは送信の優先度のうちの少なくとも１つを含む、請求項１１に記載の第１のＷＴＲＵ。

【請求項19】

前記第２のＷＴＲＵ又は第３のＷＴＲＵから受信された前記情報に関連付けられた、パラメータのセットは間接番号を含む、請求項１１に記載の第１のＷＴＲＵ。

【請求項20】

前記間接番号は、サイドリンク制御情報（ＳＣＩ）送信を介して前記第２のＷＴＲＵ又は追加のＷＴＲＵから受信される、請求項１９に記載の第１のＷＴＲＵ。

【発明の詳細な説明】

【技術分野】

【0001】

（関連出願の相互参照）
本出願は、２０２１年１０月１９日に出願された米国特許仮出願第６３／２５７，３８１号、２０２２年４月１日に出願された米国特許仮出願第６３／３２６，４０１号、及び２０２２年６月２１日に出願された米国特許仮出願第６３／３５３，９３９号の利益を主張するものであり、これらの出願の内容は参照により本明細書に組み込まれる。

【背景技術】

【0002】

車両通信は、車両が互いに直接通信してもよい通信のモードである。車両対あらゆるモノ（Vehicle to everything、Ｖ２Ｘ）動作の一シナリオは、カバレッジ内のシナリオであり、ＷＴＲＵは、ネットワークから支援を受信して、Ｖ２Ｘメッセージの送信及び受信を開始してもよい。Ｖ２Ｘ動作の別のシナリオは、カバレッジ外シナリオであり、ＷＴＲＵは、事前に構成された１つ以上のパラメータを使用して、Ｖ２Ｘメッセージの送信及び受信を開始してもよい。

【0003】

Ｖ２Ｘ通信は、ＬＴＥにおいてサポートされ、デバイスツーデバイス（Ｄ２Ｄ）通信に関する以前の研究から示唆された。Ｖ２Ｘ通信サービスは、以下を含む様々なタイプから構成されてもよい、すなわち、車両ＷＴＲＵが、互いに直接的に通信してもよい、車両間（vehicle to vehicle、Ｖ２Ｖ）、車両ＷＴＲＵが、ＲＳＵ／ｅＮＢと通信してもよい、車両対インフラストラクチャ（Ｖ２Ｉ）、車両ＷＴＲＵが、コアネットワークと通信してもよい、車両対ネットワーク（Ｖ２Ｎ）、及び車両ＷＴＲＵが、特別な条件（例えば、低バッテリ容量）でＷＴＲＵと通信してもよい、車両対歩行者（Ｖ２Ｐ）である。

【発明の概要】

【0004】

未認可スペクトルにおけるサイドリンク通信をスケジューリングするための方法及び装置が開示される。第１の無線送信／受信ユニット（ＷＴＲＵ）によって実行される方法は、サイドリンク（ＳＬ）上での送信のための許可を取得すること、第２のＷＴＲＵ又は追加のＷＴＲＵから、第１のチャネル占有時間（ＣＯＴ）情報を含む送信を受信すること、許可が、第２のＷＴＲＵ又は追加のＷＴＲＵに関連付けられたＣＯＴ中にＳＬ上で送信するためのものであるという条件で、第２のＷＴＲＵ、追加のＷＴＲＵ、又は第２のＷＴＲＵと追加のＷＴＲＵの両方から受信された送信から、キャスト情報を決定すること、第２のＷＴＲＵ又は追加のＷＴＲＵから受信された情報に関連付けられたパラメータのセットを使用してリッスンビフォアトーク（ＬＢＴ）手順を実行すること、及びＬＢＴ手順が成功したという条件で、決定されたキャスト情報に基づいて、第２のＣＯＴ情報を含むデータを送信することを含み得る。

【0005】

許可は、基地局から取得されてもよい。許可は、第１のＷＴＲＵが許可を選択することを介して取得されてもよい。キャスト情報は、ユニキャストキャストタイプ又はグループキャストキャストタイプを示してもよい。受信される情報は、第１のＣＯＴ情報又はキャスト情報であってもよい。パラメータのセットは、送信の優先度を含む、第２のＷＴＲＵ又は第３のＷＴＲＵから受信された情報に関連付けられてもよい。パラメータのセットは、間接番号を含む、第２のＷＴＲＵ又は第３のＷＴＲＵから受信された情報に関連付けられてもよい。間接番号は、サイドリンク制御情報（ＳＣＩ）送信を介して第２のＷＴＲＵ又は追加のＷＴＲＵから受信されてもよい。

【図面の簡単な説明】

【0006】

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

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

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

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

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

【図2】ユニキャストＣＯＴ共有の一例を示す図である。

【図3】グループキャスト／ブロードキャストＣＯＴ共有の一例を示す図である。

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

【0007】

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

【0008】

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

【0009】

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

【0010】

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

【0011】

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

【0012】

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

【0013】

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

【0014】

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

【0015】

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

【0016】

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

【0017】

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

【0018】

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

【0019】

ＣＮ１０６はまた、ＰＳＴＮ１０８、インターネット１１０、及び／又は他のネットワーク１１２にアクセスするために、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄのゲートウェイとして機能し得る。ＰＳＴＮ１０８は、従来型電話サービス（Plain Old Telephone Service、ＰＯＴＳ）を提供する回線交換電話網を、含み得る。インターネット１１０は、相互接続されたコンピュータネットワーク及びデバイスのグローバルシステムを含み得るが、これらのネットワーク及びデバイスは、送信制御プロトコル（Transmission Control Protocol、ＴＣＰ）、ユーザ・データグラム・プロトコル（User Datagram Protocol、ＵＤＰ）、及び／又はＴＣＰ／ＩＰインターネット・プロトコル群のインターネット・プロトコル（Internet Protocol、ＩＰ）などの、共通通信プロトコルを使用する。ネットワーク１１２は、その他のサービスプロバイダによって所有及び／又は運営される、有線通信ネットワーク及び／又は無線通信ネットワークを含み得る。例えば、ネットワーク１１２は、ＲＡＮ１０４と同じＲＡＴ又は異なるＲＡＴを用い得る１つ以上のＲＡＮに接続された別のＣＮを含み得る。

【0020】

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

【0021】

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

【0022】

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

【0023】

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

【0024】

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

【0025】

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

【0026】

ＷＴＲＵ１０２のプロセッサ１１８は、スピーカ／マイクロフォン１２４、キーパッド１２６、及び／又はディスプレイ／タッチパッド１２８（例えば、液晶ディスプレイ（Liquid Crystal Display、ＬＣＤ）表示ユニット若しくは有機発光ダイオード（Organic Light-Emitting Diode、ＯＬＥＤ）表示ユニット）に連結され得るが、これらから、ユーザが入力したデータを受信し得る。プロセッサ１１８はまた、ユーザデータを、スピーカ／マイクロフォン１２４、キーパッド１２６、及び／又はディスプレイ／タッチパッド１２８に出力し得る。なお、プロセッサ１１８は、非リムーバブルメモリ１３０及び／又はリムーバブルメモリ１３２などの任意のタイプの好適なメモリから情報にアクセスし、かつ当該メモリにデータを記憶し得る。非リムーバブルメモリ１３０は、ランダムアクセスメモリ（Random-Access Memory、ＲＡＭ）、読み取り専用メモリ（Read-Only Memory、ＲＯＭ）、ハードディスク、又は任意のその他のタイプのメモリ記憶デバイスを含み得る。リムーバブルメモリ１３２は、加入者識別モジュール（Subscriber Identity Module、ＳＩＭ）カード、メモリスティック、セキュアデジタル（Secure Digital、ＳＤ）メモリカード等を含んでもよい。その他の実施形態では、プロセッサ１１８は、サーバ又はホームコンピュータ（図示せず）上など、ＷＴＲＵ１０２上に物理的に配置されていないメモリから情報にアクセスし、かつ当該メモリにデータを記憶し得る。

【0027】

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

【0028】

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

【0029】

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

【0030】

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

【0031】

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

【0032】

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

【0033】

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

【0034】

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

【0035】

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

【0036】

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

【0037】

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

【0038】

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

【0039】

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

【0040】

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

【0041】

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

【0042】

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

【0043】

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

【0044】

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

【0045】

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

【0046】

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

【0047】

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

【0048】

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

【0049】

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

【0050】

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

【0051】

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

【0052】

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

【0053】

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

【0054】

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

【0055】

ＳＭＦ１８３ａ、１８３ｂは、Ｎ１１インターフェースを介して、ＣＮ１０６中のＡＭＦ１８２ａ、１８２ｂに接続され得る。ＳＭＦ１８３ａ、１８３ｂはまた、Ｎ４インターフェースを介して、ＣＮ１０６中のＵＰＦ１８４ａ、１８４ｂに接続され得る。ＳＭＦ１８３ａ、１８３ｂは、ＵＰＦ１８４ａ、１８４ｂを選択及び制御し、ＵＰＦ１８４ａ、１８４ｂを通るトラフィックの経路指定を、構成し得る。ＳＭＦ１８３ａ、１８３ｂは、ＵＥ ＩＰアドレスを管理及び割り当てる機能、ＰＤＵセッションを管理する機能、ポリシー実施及びＱｏＳを制御する機能、ＤＬデータ通知を提供する機能などのような、他の機能を実施し得る。ＰＤＵセッションタイプは、ＩＰベース、非ＩＰベース、イーサネットベースなどであり得る。

【0056】

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

【0057】

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

【0058】

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

【0059】

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

【0060】

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

【0061】

以下の略語及び頭字語が参照され得る。

【0062】

【表1】

【0063】

ＬＴＥは、Ｖ２Ｘ通信における２つの動作モード、すなわちモード３及びモード４を定義する。モード３において、ネットワークは、Ｖ２Ｘサイドリンク送信に関する割り当てをスケジューリングとともにＷＴＲＵを提供してもよい。モード４において、ＷＴＲＵは、構成／事前構成リソースプールからリソースを自律的に選択してもよい。Ｖ２Ｘ ＬＴＥにおいて定義されるリソースプールの２つのカテゴリ、すなわち、（１）Ｖ２Ｘ送信を受信するために監視され得る、受信プール、及び（２）モード４で送信リソースを選択するために、ＷＴＲＵによって使用され得る、送信プールがある。送信プールは、モード３で構成されたＷＴＲＵによって使用されない。

【0064】

ＬＴＥにおいて、リソースプールは、無線リソース制御（ＲＲＣ）シグナリングを介して、半静的にＷＴＲＵにシグナリングされてもよい。モード４において、ＷＴＲＵは、ＲＲＣ構成された送信プールからリソースを選択する前に、感知を使用してもよい。ＬＴＥ Ｖ２Ｘは、動的リソースプール再構成をサポートしない。プール構成は、ＳＩＢ及び／又は専用ＲＲＣシグナリングを介して搬送のみされてもよい。

【0065】

５Ｇ ＮＲは、ＬＴＥからリソース割り当ての２つのモードを継承した。モード１リソース割当ては、基地局（すなわち、ｇＮＢ）スケジュールされたリソース割当てに対応する。モード２リソース割り当ては、ＷＴＲＵ自律リソース割り当てに対応する。モード２リソース割り当てのためのリソースプール及び感知の概念も、ＬＴＥから継承された。

【0066】

３ ＧＰＰでは、ＬＡＡ（License Assisted Access）において、未認可帯域へのアクセスが指定されている。より具体的には、ダウンリンク（ＤＬ）動作、アップリンク（ＵＬ）動作及び自律ＵＬ並びに他の拡張が指定される。ＬＡＡは、未認可動作が常に認可帯域においてＰＣｅｌｌに固定されていたという前提を利用する。ＳＣｅｌｌにおける未認可帯域へのアクセスは、ＷＴＲＵ／ｇＮＢによるＬＢＴ動作を必要とした。

【0067】

新無線では、未認可スペクトル（ＮＲ－Ｕ）が指定される。ＮＲ－Ｕは、異なるモードで動作するために、共有スペクトルチャネルアクセスで動作するＮＲ無線アクセスをサポートし、ここで、ＰＣｅｌｌ、ＰＳＣｅｌｌ、又はＳＣｅｌｌのいずれかは、共有スペクトル中にあり得、ＳＣｅｌｌは、ＵＬで構成されてもされなくてもよい。

【0068】

ＮＲ－Ｕをサポートするために、ＰＨＹ層信号及びチャネルに対して以下の修正が行われた、すなわち、（１）ＤＣＩ ２＿０は、時間及び周波数領域チャネル占有時間（ＣＯＴ）構造を提供するように拡張される、（２）探索スペースグループ切り替え特徴が導入され、それによって、ＷＴＲＵは、探索スペースセットの２つのグループのうちの１つを使用してＰＤＣＣＨ監視を実行するように動的に制御されてもよい、（３）追加のＰＤＳＣＨマッピングタイプＢの長さが導入されて、ＣＯＴが開始されるとすぐにＣＯＴの先頭での送信を可能にする、（４）探索スペースは、複数のＬＢＴ帯域にわたるＰＤＣＣＨ監視を可能にするために、周波数領域において複数の監視位置で構成されてもよい、（５）インターレース構造がＰＵＣＣＨ及びＰＵＳＣＨに導入され、ＰＵＣＣＨフォーマットがＰＲＢインターレース波形に拡張されるが、１つのＲＢセット内に含まれる、（６）ＳＲＳ送信は、スロットの任意のシンボル上でもよく、（７）ｇＮＢは、単一のＤＣＩフォーマットによって複数の連続するＰＵＳＣＨをスケジュールしてもよい。

【0069】

共有スペクトルにおいて動作しているＷＴＲＵは、チャネルにアクセスするためにＬＢＴを実行してもよい。ＮＲ－Ｕは、動的チャネルアクセス（ＬＢＥ）及び半静的チャネルアクセス（ＦＢＥ）をサポートする。いくつかの実施形態では、ＦＢＥの場合、ｇＮＢのみが、その固定フレーム期間（ＦＦＰ）構成によって通知された特定の時間にＣＯＴを開始してもよい。ＷＴＲＵは、ｇＮＢ ＤＬ送信が同じＦＦＰのより早い部分で検出される場合、半静的チャネルを共有してもよい。他の実施形態では、ＷＴＲＵは、ＷＴＲＵ－ＦＦＰを用いて構成されてもよく、そのＷＴＲＵ－ＦＦＰ構成から決定される特定の時間にＣＯＴを開始してよい。

【0070】

２０ＭＨｚ単位でＣＣＡ（Clear Channel Assessment）が行われてもよい。以下のタイプのＬＢＴが指定される、すなわち、（１）ＣＡＴ４ ＬＢＴ－タイプ１、（２）ＣＡＴ２ ＬＢＴ－タイプ２Ａ、（３）ＣＡＴ２ ＬＢＴ－タイプ２Ｂ、及び（４）ＣＡＴ１ ＬＢＴ－タイプ２Ｃである。

【0071】

ＣＯＴは、ＣＡＴ４ ＬＢＴを使用して開始されてもよい。ＣＯＴは、切り替えポイントにおける送信間のギャップサイズに依存して、ＣＡＴ１ ＬＢＴ又はＣＡＴ２ ＬＢＴのいずれかを使用して、ＣＯＴ開始ノードから送信を受信したノードによって共有されてもよい。

【0072】

ＬＢＴパラメータは、チャネルアクセス優先度クラス（ＣＡＰＣ）によって決定されてもよい。無線ベアラ及びＭＡＣ ＣＥのＣＡＰＣは、固定又は構成可能のいずれかである、すなわち、（１）パディングＢＳＲ及び推奨ビットレートＭＡＣ ＣＥに対して最低優先度に固定される、（２）ＳＲＢ０、ＳＲＢ１、ＳＲＢ３及び他のＭＡＣ ＣＥに対して最高優先度に固定される、及び／又は（３）ＳＲＢ２及びＤＲＢに対してｇＮＢによって構成される。

【0073】

ＤＲＢのＣＡＰＣを選択するとき、ｇＮＢは、異なるトラフィックタイプと送信との間の公平性を考慮しながら、そのＤＲＢにおいて多重化される全てのＱｏＳフローの５つのＱＩを考慮してもよい。以下の表１は、どの標準化５ＱＩのためにどのＣＡＰＣが使用されるべきか（すなわち、所与のＱｏＳフローのためにどのＣＡＰＣが使用されるか）を示す。非標準化５ＱＩ（すなわち、事業者固有５ＱＩ）に対応するＱｏＳフローは、非標準化５ＱＩのＱｏＳ特性に最もよく一致する標準化５ＱＩのＣＡＰＣを使用すべきである。

【0074】

【表2】

【0075】

ＣＡＰＣがＤＣＩで示されず、ＷＴＲＵがアップリンクＴＢの送信のためにタイプ１ ＬＢＴ手順を実行するとき、ＷＴＲＵは、以下のようにＣＡＰＣを選択してもよい、すなわち、（１）ＭＡＣ ＣＥのみがＴＢに含まれる場合、それらのＭＡＣ ＣＥのうちの最高優先度ＣＡＰＣが使用される、又は（２）ＴＢにＣＣＣＨ ＳＤＵが含まれている場合、最高優先度ＣＡＰＣが使用される、又は（３）ＴＢにＤＣＣＨ ＳＤＵが含まれる場合、ＤＣＣＨのうち最高優先度ＣＡＰＣが使用される、又は（４）ＴＢにおいて多重化されたＭＡＣ ＳＤＵを伴う論理チャネルの最低優先度ＣＡＰＣが、そうでなければ使用される。

【0076】

ＮＲ－Ｕにおいて、チャネルへのアクセスは、従来のＵｕアーキテクチャを仮定する。具体的には、ｇＮＢは、そのカバレッジ内の複数のＷＴＲＵをスケジュールし、ｇＮＢは、位置が固定されていると仮定される。チャネルがアクセスされるとｇＮＢによってスケジュールされるＷＴＲＵによる送信は、ｇＮＢを対象とする。しかしながら、共有スペクトルにおけるＳＬ動作の場合、これらの仮定はもはや有効ではないことがある。

【0077】

発生する１つの問題は、モード１スケジューリング問題である。モード１ ＳＬにおいて、ｇＮＢは、ＷＴＲＵへのＳＬリソースをスケジュールする。スケジューリングＤＣＩは、共有スペクトル（場合によっては、ＷＴＲＵ送信と同じ共有スペクトル）中にあってもよい。しかしながら、ＷＴＲＵの送信は、ｇＮＢではなく別のＷＴＲＵを対象としてもよい。このため、ｇＮＢは、ＤＣＩに続いてＷＴＲＵがチャネルを取得したかどうかを認識しない可能性がある。更に、ｇＮＢが、ＷＴＲＵが送信することになるチャネル（例えば、ＤＣＩが送信されるキャリアとは異なるキャリアにおけるＷＴＲＵによるＳＬ送信）へのアクセスのためのＬＢＴ手順を実行しなくてもよいシナリオもあってもよい。具体的には、ＷＴＲＵは、ｇＮＢによって開始されるＣＯＴを共有することができない可能性がある。しかしながら、ＷＴＲＵは、ＷＴＲＵによって開始されるＣＯＴを共有してもよい。

【0078】

第２の問題は、ＳＬアーキテクチャが、ＬＢＴパラメータを決定するための新しい方法を必要とし得ることである。チャネル幅（ＣＷ）サイズ、最大ＣＯＴ長、及び許可されたＣＷサイズなどのＬＢＴパラメータは、送信されるべきデータのＱｏＳに主に依存する。これは、Ｕｕインフラストラクチャ／アーキテクチャには適切であり得るが、Ｖ２Ｘに典型的な分散アーキテクチャには適切でないことがある。具体的には、Ｖ２Ｘは、ユニキャスト、グループキャスト、及びブロードキャストをサポートしてもよい。更に、いくつかの送信（例えば、ブロードキャスト）は、無関係なＷＴＲＵに典型的であり、他の送信（例えば、ユニキャスト）は、一緒に移動するＷＴＲＵに典型的である。これらの要因は、そのような送信のために必要とされるＬＢＴパラメータに影響を与え得る。それらはまた、ＷＴＲＵが別のＷＴＲＵによって開始されたＣＯＴを共有してもよいかどうかなど、ＣＯＴ使用ルールに影響を及ぼす可能性がある。

【0079】

本明細書では、「ＣＯＴを開始すること」という用語は、完全なＬＢＴ（例えば、タイプ１ ＬＢＴ）を実行することを指してもよい。同様に、「ＣＯＴを共有すること」は、低減されたＬＢＴ（例えば、タイプ２ ＬＢＴ）を実行することを指してもよい。ＷＴＲＵは、タイプ１ ＬＢＴ許可又はタイプ２ ＬＢＴ許可として許可を識別し得る。許可において送信を実行するかどうか、及びＷＴＲＵが許可を開始又は共有しているかどうかに基づくどのタイプの送信かの決定は、本明細書で論じるように、その許可に対して実行されるべきＬＢＴタイプの識別に基づいて導出されてもよい。

【0080】

本明細書では、ＣＯＴを開始したＷＴＲＵへの参照は、新しいＣＯＴを作成したＳＬ送信を実行したＷＴＲＵを指してもよい。代替的に、ＣＯＴを開始したＷＴＲＵは、ＣＯＴ内で送信され、その送信が当該ＷＴＲＵによって検出される別のＷＴＲＵを指してもよい。代替的に、ＣＯＴを開始したＷＴＲＵはまた、既存のＣＯＴを共有することを決定したときにＣＯＴ情報を送信又は転送する別のＷＴＲＵを指してもよい。

【0081】

本明細書で説明する実施形態では、ＬＢＴ挙動は、共有スペクトル中のチャネルにアクセスするための方法（例えば、ＬＢＴ）に関連する任意の態様を指してもよい。

【0082】

ＬＢＴ挙動は、ＣＡＰＣ、又はＬＢＴパラメータのセットを決定する同様のアクセスクラス／分類を含んでもよい。例えば、ＬＢＴ挙動は、ＷＴＲＵが、（本明細書で説明されるように）所与のデータ又は送信タイプのためのチャネルアクセス優先度クラスを選択することを含んでもよい。例えば、ＬＢＴ挙動は、ＷＴＲＵが、ＬＢＴのためにＵＬ ＣＡＰＣテーブルを使用するか、又はＬＢＴのためにＤＬ ＣＡＰＣテーブルを使用するかを決定することを含んでもよい。例えば、本明細書におけるＬＢＴ挙動は、ＷＴＲＵが、ＵＬ／ＤＬ ＣＡＰＣテーブルのうちの１つのみを使用することができるかどうか、又はいずれかのテーブルが使用されることができるかどうかを決定することを含んでもよい。例えば、ＬＢＴ挙動は、ＷＴＲＵが、送信のために任意のアクセス優先度クラスを選択することができるかどうか、又は送信のために特定のアクセス優先度クラスのみを選択することができるかどうかを決定することを含んでもよい。

【0083】

ＬＢＴ挙動は、ＷＴＲＵが、（例えば、第１のテーブル又は第１のマッピングを使用して）第１のメカニズムにおいてＣＡＰＣを決定するかどうか、又は（例えば、第２のテーブル又は第２のマッピングを使用して）第２のメカニズムにおいてＣＡＰＣを決定するかどうかを決定することを含んでもよい。第１又は第２のマッピングは、本明細書の任意のプロパティをＣＡＰＣにマッピングすることからなってもよい。例えば、第１のマッピングは、ＰＱＩ（ＱｏＳプロファイルインジケータ）とＣＡＰＣとの間のマッピングからなってもよく、第２のマッピングは、論理優先度とＣＡＰＣとの間のマッピングからなってもよい。

【0084】

ＬＢＴ挙動は、各々がそれら自体のＣＡＰＣを伴う複数の要素を含んでいる送信からＣＡＰＣを取得するための第１のルール（例えば、送信中に含まれるＣＡＰＣの最高優先度を使用する）と、そのような送信からＣＡＰＣを取得するための第２のルール（例えば、送信中に含まれるＣＡＰＣの最低優先度を使用する）との間で決定することを含んでもよい。例えば、ＷＴＲＵは、１つのタイプの送信（例えば、モード１送信）に対してＣＡＰＣの最低優先度を使用してもよく、別のタイプの送信（例えば、モード２送信）に対してＣＡＰＣの最高優先度を使用してもよい。送信のタイプは、（ＰＤＵに含まれるデータ／制御のいずれかの）優先度、ＣＢＲなど、必ずしもモードに限定されない、本明細書で定義されるＳＬ特性のいずれかから更に構成されてもよい。

【0085】

異なるＣＡＰＣを伴うデータ／制御が同じＰＤＵに多重化されるとき、ＰＤＵのＣＡＰＣを取得するためのルールの決定は、次のいずれかからなり得る、すなわち、（１）最高優先度を選択するか、又は最低優先度を選択するかを決定すること、（２）固定マッピングからＣＡＰＣを取得するか、構成可能マッピングからＣＡＰＣを取得するかを決定すること、（３）ＭＡＣ ＣＥ及び／又はＳＲＢの優先度からＣＡＰＣを取得するかどうかを決定すること、（４）ＤＲＢの優先度からＣＡＰＣを取得するかどうかを決定すること、（５）ＣＡＰＣを決定するときに適用されるルールの順序を決定すること（例えば、ＭＡＣ ＣＥを最初に考慮する、ＤＲＢを最初に考慮する、ＳＲＢを最初に考慮するなど）、（６）ＭＡＣ ＣＥ、ＳＲＢ、ＤＲＢのいずれかの優先度を決定に考慮するかどうかを決定することである。

【0086】

ＬＢＴ挙動は、競合ウィンドウサイズ（ＣＷＳ）、最大ＣＯＴ長、許容可能なＣＷサイズ、ＣＷ調整手順、ＣＣＡの数、ＣＣＡ持続時間、延期期間、及び／又はＳＬに適用されるＦＦＰパラメータなど、任意の既存のＬＢＴパラメータを含んでもよい。例えば、ＬＢＴ挙動は、ＷＴＲＵが、１つの特定の最大ＣＯＴ長を別のものよりも選択することを含んでもよい。例えば、ＬＢＴ挙動は、ＷＴＲＵが、パラメータ（延期期間など）をＬＢＴの一部として使用／考慮するかどうかを決定することを含んでもよい。例えば、ＬＢＴ挙動は、ＷＴＲＵが構成された値のセットのうちの１つからＣＷＳを選択すること、ＷＴＲＵが送信ごとにＣＷＳを特定の量だけ増加させることなどを含んでもよい。例えば、ＬＢＴ挙動は、第１のＣＷ調整手順（又は手順のパラメータのセット）を使用するかどうか、又は第２のＣＷ調整手順（又は手順のパラメータの別のセット）を使用するかどうかを決定することを含んでもよい。例えば、ＬＢＴパラメータを選択することは、複数の（事前に）構成された値のうちの１つを選択すること、又はＰＤＢ、ＨＡＲＱ ＲＴＴ、異なるＳＬチャネル間の分離など、時間に関連付けられたＳＬ特性からパラメータ自体の値を直接決定することのいずれかを含んでもよい。

【0087】

ＬＢＴ挙動はまた、ＬＢＴタイプ又はカテゴリを含んでもよい。例えば、ＬＢＴ挙動は、ＷＴＲＵが、１つのＬＢＴタイプ若しくは別のＬＢＴタイプ及び／又は１つのＬＢＴカテゴリを使用するかどうかを決定することを含んでもよい。

【0088】

ＬＢＴ挙動はまた、ＬＢＴビーム、ビーム幅、又はビーム方向（無指向性を含む）を含んでもよい。例えば、ＬＢＴ挙動は、ＷＴＲＵがＬＢＴビーム幅、チャネルへのアクセスを得るためにＬＢＴが実行されるチャネル／サブチャネルの数などを選択することを含んでもよい。

【0089】

ＬＢＴ挙動はまた、チャネルのアクセスのためのイベント間の任意の許容可能／最小／最大遅延などのチャネルアクセス挙動を決定する、ＳＬに固有の任意の新しいＬＢＴパラメータを含んでもよく、そのようなイベントは、エネルギーの測定、又はサイドリンクチャネル（例えば、ＳＣＩ、ＰＳＣＣＨ、ＰＳＦＣＨなど）の受信／送信、制御情報、若しくはＨＡＲＱフィードバックなどのサイドリンク固有イベントの発生に関連してもよい。

【0090】

ＬＢＴ挙動はまた、チャネルの占有の決定のためのエネルギー閾値を含んでもよい。ＬＢＴ挙動はまた、チャネルの占有の決定のために使用されるタイムスロット又は同等物の数を含んでもよい。

【0091】

ＬＢＴ挙動はまた、ＬＢＴ、又はＬＢＴの一部など、チャネルアクセスに関連する手順の適用のインスタンスの数を含んでもよい（ここで、ＬＢＴは、ＳＬチャネルに固有のアクセス手順、又はＵｕにおいて使用される同じアクセス手順であってもよい）。例えば、ＬＢＴ挙動は、（本明細書で潜在的に言及される）第２のアクションが開始されることができる前にＬＢＴが試みられることができる回数を決定することを含んでもよい。

【0092】

ＬＢＴ挙動はまた、チャネル上でのＬＢＴの実行の間の任意の時間インスタンスを含んでもよい。ＬＢＴ挙動はまた、ＷＴＲＵがＣＯＴを再使用することができる前の最後の送信からの最小／最大時間、及び／又はこの最小／最大時間の場合に実行されるべきＬＢＴのタイプ（例えば、ＬＢＴなし、ワンショットＬＢＴ、完全なＬＢＴなど）を含んでもよい。

【0093】

ＬＢＴ挙動はまた、ＷＴＲＵが、基地局（例えば、ｇＮＢ）及び／又は別のＷＴＲＵによって開始されるＣＯＴを共有することを許可されるかどうかを含んでもよい。例えば、ＬＢＴ挙動は、ＷＴＲＵが、別のＷＴＲＵによって開始されたＣＯＴを共有できるかどうかを決定することを含んでもよい。例えば、ＬＢＴ挙動は、送信のために新しいＣＯＴを開始する必要があるかどうかをＷＴＲＵが決定することを含んでもよい。

【0094】

ＬＢＴ挙動はまた、（例えば、別のＷＴＲＵ又は基地局（例えば、ｇＮＢ）からの）以前の送信と、チャネルにアクセスするために１つ又は別のタイプのＬＢＴを必要とするＷＴＲＵ自体の送信との間の最小／最大時間を含んでもよい。

【0095】

ＬＢＴ挙動はまた、ＣＯＴを開始するＷＴＲＵによって決定され、場合によってはＣＯＴ構造情報において送信されるＣＯＴ長を含んでもよい。例えば、ＬＢＴ挙動は、ＷＴＲＵが、別のＣＯＴ長よりも１つのＣＯＴ長を選択すること（例えば、その両方が構成されてもよい）を含んでもよい。例えば、ＬＢＴ挙動は、ＷＴＲＵが、選択されたＣＯＴ長を特定の値に制限するかどうかを含んでもよい。

【0096】

ＬＢＴ挙動はまた、ＣＯＴを開始するＷＴＲＵが他のＷＴＲＵとＣＯＴを共有できるかどうか、及びそれがＣＯＴ構造情報においてこの共有能力を示すかどうかを含んでもよい。例えば、ＬＢＴ挙動は、開始ＷＴＲＵが、ＣＯＴが共有されることができるかどうかを示すかどうかを決定することを含んでもよい。例えば、ＬＢＴ挙動は、開始ＷＴＲＵが、どのＷＴＲＵがＣＯＴを共有することができるかを決定すること、及びＣＯＴ情報においてそれを潜在的に示すことを含んでもよい。

【0097】

一実施形態では、ＷＴＲＵは、複数の独立したＬＢＴ挙動及び／又は手順を有してもよい。ＬＢＴ手順（例えば、ＣＷ調整）は、パラメータ（例えば、所与のアクセス優先度のために適用されるＣＷ）が１つ以上のステップに続いて更新される複数のステップを伴ってもよい。ＳＬ ＬＢＴを実行するＷＴＲＵは、その手順内でパラメータを独立して更新する複数の独立／同時ＬＢＴ手順を維持してもよい。各独立／同時ＬＢＴ手順は、次などのＳＬ要因に関連付けられてもよい、すなわち、（１）キャストタイプ（例えば、ユニキャストのための１つの手順、及びグループキャスト／ブロードキャストのための１つの手順）、（２）Ｌ２ソース／宛先ＩＤ（例えば、各宛先Ｌ２ ＩＤに対して１つの手順）、（３）ユニキャストリンク（例えば、ソース／宛先ＩＤの各ペアに対して１つの手順）、（４）ＱｏＳフロー、（５）リソースプール、及び／又は（６）ＨＡＲＱ有効化及びＨＡＲＱ無効化送信である。

【0098】

上記で説明されたＬＢＴ挙動に関連するＬＢＴ手順のいずれも、ＬＢＴ手順の複数の独立／同時インスタンスを有してもよい。次いで、特定の要因を用いて送信のためのＬＢＴを実行するＷＴＲＵは、手順のそのインスタンスに関連付けられたパラメータを使用してもよい。

【0099】

ＷＴＲＵは、ＨＡＲＱ有効化／無効化送信に対して異なるＣＷ調整を有してもよい。一実施形態では、ＷＴＲＵは、送信がＨＡＲＱ有効化送信に関連付けられているか、又はＨＡＲＱ無効化送信に関連付けられているかに基づいて、ＣＷ調整を異なって実行してもよい。例えば、ＷＴＲＵは、有効化されたＨＡＲＱフィードバック対無効化されたＨＡＲＱフィードバックを含む送信に続いて、異なる調整パラメータ／値を使用してもよい。別の例では、ＷＴＲＵは、ＨＡＲＱフィードバックが無効化された状態での送信に続いて、ＣＷをデフォルト値又は構成値に設定してもよい。別の例では、ＷＴＲＵは、ＨＡＲＱフィードバックが無効化された状態での送信のために、デフォルト／構成された量だけＣＷを増加／減少させてもよい。別の例では、ＷＴＲＵは、ＣＷ更新の決定において無効にされたＨＡＲＱフィードバックを伴う全ての送信を無視してもよい。別の例では、ＷＴＲＵは、ＨＡＲＱフィードバックが無効化された状態での送信に続いて、ＣＷを初期値に設定してもよい。別の例では、ＷＴＲＵは、時間ウィンドウ中のＨＡＲＱ無効化送信の数に応じて、又は最後のＨＡＲＱ有効化送信以降に、ある量だけＣＷ調整を減少させてもよい。別の例では、ＷＴＲＵは、ＨＡＲＱフィードバックが無効化された状態での送信に続いて、ＣＷをデフォルト／初期値にリセットしてもよい。別の例では、ＷＴＲＵは、ＮＡＣＫに対してＣＷを増加させるように構成されてもよい。更に、ＨＡＲＱフィードバックが無効にされる場合、ＣＷの増加は、関数（例えば、半分、２倍など）に関連付けられてもよい。関数は、静的ではないＷＴＲＵにおける他の要因にも依存してもよい。別の例では、ＨＡＲＱフィードバック無効化送信に続いてＷＴＲＵがＣＷを第１の量だけ増加させるか第２の量だけ増加させるかに関する決定は、以前の送信がＡＣＫをもたらしたかＮＡＣＫをもたらしたかに依存してもよい。

【0100】

ＷＴＲＵは、ＣＷの値、その値の最後のリセット以降にＣＷが増加された回数、値が（事前に）構成された閾値を上回るかどうかなどのいずれかからなってもよいＣＷ調整状態に基づいて、ＨＡＲＱフィードバックが有効化又は無効化された状態で送信を実行するかどうかを決定してもよい。例えば、ＣＷの値が閾値を上回っているとき、ＷＴＲＵはＨＡＲＱフィードバックが有効にされた状態で送信を実行してもよい。例えば、ＷＴＲＵは、最後のリセット以降のＣＷにおける連続的な増加の数が閾値を上回るとき、ＨＡＲＱフィードバックが有効にされた状態で送信を実行してもよい。

【0101】

ＳＬのためのモード１スケジューリングは、チャネル利用可能性情報（例えば、ＳＬ ３ＧＰＰシステムによって取得されるＣＯＴについての情報）へのアクセスを有する基地局（例えば、ｇＮＢ）の能力に依存してもよい。一実施形態では、ＷＴＲＵは、基地局（例えば、ｇＮＢ）からのＳＬスケジューリングＤＣＩ又は他のメッセージにおける暗黙的／明示的指示に基づいて、ＳＬ上でＬＢＴ手順を実行するかどうか、及びＬＢＴ挙動（例えば、ＬＢＴタイプ）を決定してもよい。

【0102】

例えば、ＷＴＲＵは、ＬＢＴ手順が必要とされる／必要とされないという指示、及び／又はＳＬ許可をスケジューリングするＤＣＩにおいて必要とされるＬＢＴのタイプを受信してもよい。ＷＴＲＵは、スケジューリングＤＣＩの受信とスケジューリングされているＳＬリソースとの間の時間差に基づいて、ＬＢＴが必要とされる／必要とされないかどうか、又はＬＢＴのタイプを決定してもよい。ここで、例えば、ＷＴＲＵは、スケジューリングＤＣＩとＳＬリソースとの間の時間差へのＬＢＴタイプのマッピングを用いて（事前）構成されてもよく、実行するＬＢＴタイプを決定するためにその時間差を使用してもよい。例えば、ＷＴＲＵは、スケジューリングＤＣＩとＳＬリソースとの間の時間が閾値を下回る場合、ＬＢＴが必要とされない、又は短いＬＢＴが必要とされると仮定してもよい。

【0103】

ＷＴＲＵは、ＬＢＴ手順が必要とされる／必要とされないという明示的な指示、及び／又は別個のＤＣＩにおいて必要とされるＬＢＴのタイプを受信してもよい。ＷＴＲＵは、ＳＬ構成された許可を用いて構成されてもよく、ＬＢＴ手順が必要とされる／必要とされないかどうか、及びＬＢＴのタイプを示すために、その構成された許可の任意のインスタンスの前にスケジューリングＤＣＩを受信してもよい。

【0104】

更に、上記の例の組み合わせも可能である。例えば、ＷＴＲＵは、タイプ１ ＬＢＴを実行するかどうか、又はスケジューリングＤＣＩとＳＬ許可タイミングとの間の時間差によって決定されるＬＢＴタイプを実行するかどうかの明示的な指示を受信してもよい。そのような明示的な指示は、ＤＣＩ中にあってもよい。そのような明示的な指示は、ＲＲＣ構成の一部としてＷＴＲＵに提供されてもよい。

【0105】

上記の条件は、ＤＣＩが受信されるキャリア／ＢＷが、ＳＬがスケジュールされるキャリアと同じであるかどうかに更に依存してもよい。具体的には、ＷＴＲＵは、スケジューリングＤＣＩとＳＬリソースとの間の時間が閾値未満である場合（同じキャリアの場合のみ）、ＬＢＴ手順が必要とされない、又は短いＬＢＴ手順が必要とされると仮定してもよい。

【0106】

別の実施形態では、ＷＴＲＵは、ネットワークから受信されたＤＣＩ中の情報と、別のＷＴＲＵから受信されたＳＣＩとの組み合わせに基づいて、使用するＬＢＴパラメータを決定してもよい。例えば、ＤＣＩがＬＢＴタイプを明示的に示さない場合、ＷＴＲＵは、その許可がＳＣＩにおいて示されるＣＯＴ内にある場合、第１のＬＢＴを使用してもよい。ＤＣＩがＬＢＴタイプを明示的に示す場合、ＷＴＲＵは、ＤＣＩ指示に従ってもよい。

【0107】

別の実施形態では、ＷＴＲＵは、受信されたＳＣＩのソースに応じてＬＢＴパラメータを決定してもよい。具体的には、ＷＴＲＵは、ＬＢＴタイプ又はパラメータを、次の組み合わせとして決定してもよい、すなわち、（１）ＤＣＩ及び／又はＳＣＩ中のＣＡＰＣ又は同様の情報、（２）閾値と比較される、ＳＬ上で検出されたＳＣＩ送信間の時間ギャップ（そのような閾値は、本明細書で説明する他のＳＬ固有情報に加えて、ＤＣＩ中の情報によって決定又は導出されてもよい）、及び／又は（３）ＤＣＩとＳＬ許可との間の時間ギャップである。ＷＴＲＵは、ＤＣＩ中の情報、又はＲＲＣシグナリングで提供される同様の情報に基づいて、そのような情報をどのように組み合わせるかを決定してもよい。

【0108】

別の実施形態では、ＷＴＲＵは、ＤＣＩ及びＳＬ送信が同じ（未認可）キャリア上にあるかどうかに基づいて、ＬＢＴパラメータを決定してもよい。具体的には、ＳＬ送信と同じ未認可キャリア上でＤＣＩを受信するＷＴＲＵは、基地局（例えば、ｇＮＢ）によるＣＯＴの開始としてＤＣＩの受信を解釈してもよい。代替的に、ＤＣＩがＳＬキャリアとは異なるキャリア上で受信される場合、ＷＴＲＵは、ＣＯＴを開始するためにＳＬ送信に依存するか、又はＣＯＴが別のＷＴＲＵによって開始されるかどうかを決定してもよい。

【0109】

ＬＢＴタイプ又はパラメータは次のうちの少なくとも１つを含んでもよい、すなわち、（１）ＬＢＴカテゴリ（例えば、ＬＢＴ ＣＡＴ１、ＬＢＴ ＣＡＴ２、ＬＢＴ ＣＡＴ３、又はＬＢＴ ＣＡＴ４）、（２）ＣＣＡ持続時間、（３）ＣＷサイズ（これは、最大ＣＷサイズ又は現在使用されているＣＷサイズを含んでもよい）、（４）ＬＢＴビーム方向又はビーム幅（例えば、ＬＢＴは無指向性であってもよい）、（５）ＣＯＴ持続時間（これは最大ＣＯＴ持続時間を含んでもよい）、（６）延期期間持続時間、及び／又は（７）ＦＦＰ構成である。

【0110】

例えば、ＷＴＲＵがＣＡＰＣ又は同様の情報をＤＣＩで受信する場合、それは、ＤＣＩとＳＣＩとの間の時間差に基づいて、使用されるべきＬＢＴタイプを決定してもよい。この場合は、基地局（例えば、ｇＮＢ）がそれ自体でＤＣＩを送信するためにＬＢＴを実行したシナリオに対応してもよい。ＷＴＲＵがＤＣＩにおいてＣＡＰＣを受信しない場合、ＷＴＲＵは、ＳＣＩ送信に基づいて実行するＬＢＴタイプを決定してもよい。具体的には、ＷＴＲＵが、共有する別のＷＴＲＵによって開始されたＣＯＴを見つけない場合、ＷＴＲＵは、タイプ１ ＬＢＴを実行してもよい。そうではなく、ＣＯＴを共有する場合、ＷＴＲＵ許可と別のＷＴＲＵによる最後のＳＣＩ／送信との間の時間ギャップに基づいてタイプが決定されてもよいＬＢＴを実行してもよい。上記と同様に、ＷＴＲＵはまた、同様のルールに基づいてデータのタイプ（例えば、優先度、キャストなど）を決定してもよい。

【0111】

ＷＴＲＵによるＣＯＴ情報（例えば、ＣＧ－ＵＣＩと同様の形式で）は、ＳＣＩにおいてＷＴＲＵによって送信されてもよい。ＷＴＲＵは、各ＳＣＩでそのようなＣＯＴ情報を送信してもよい。代替的に、ＷＴＲＵは、周期的に、ｘ送信ごとに、ｘ時間期間ごとに、ＣＯＴを開始するＳＣＩ送信において、ＣＯＴを開始するＳＣＩの受信時に、又は特定のＣＯＴ情報が含まれる場合など、ＳＣＩ送信のサブセットにおいて情報を送信してもよい。

【0112】

ＷＴＲＵは、他のＰＨＹチャネル（例えば、ＰＳＣＣＨ以外）でＣＯＴ情報を送信してもよい。代替的に、ＷＴＲＵは、ＳＬ ＭＡＣ ＣＥ、ＳＬ ＲＲＣメッセージ、ＷＴＲＵ間リソース調整メッセージ、又は同様のメッセージで、ＣＯＴ情報を送信してもよい。ＷＴＲＵは、それがＣＯＴをいつ開始するかを決定するＣＯＴ情報を送信してもよい。

【0113】

代替的に、又は併せて、ＷＴＲＵは、基地局（例えば、ｇＮＢ）及び／又は他のＷＴＲＵ（例えば、ＣＯＴを共有することを決定したとき）から受信するＣＯＴ情報を送信してもよい。例えば、ＷＴＲＵは、基地局（例えば、ｇＮＢ）から受信、ｇＮＢ）から受信されたＣＯＴ情報を送信してもよく、又は基地局（例えば、ｇＮＢ）から受信された情報から、ＳＬにおいて送信するための関連するＣＯＴ情報を導出してもよい。ＣＯＴ情報は、本明細書で説明される任意のＣＯＴ情報を含んでもよい。例えば、ＷＴＲＵは、基地局（例えば、ｇＮＢ）から残りのＣＯＴ長を受信してもよい。ＷＴＲＵは、（例えば、受信された残りのＣＯＴ長からＤＣＩ受信間の時間ギャップを減算することによって）そのＳＣＩ送信後の残りのＣＯＴ長を計算し、この情報をそれ自体のＳＣＩ送信又はそれ自体の送信とともに送信されるＳＬ ＭＡＣ ＣＥに含めてもよい。代替的に、ＷＴＲＵは、別のＷＴＲＵからＣＯＴ情報を送信することを決定してもよい。場合によっては、ＷＴＲＵは、問題のＣＯＴを共有しない場合であっても、別のＷＴＲＵからＣＯＴ情報を送信することを決定してもよい。

【0114】

一実施形態では、ＷＴＲＵは、別のＷＴＲＵから受信された、又は別のＷＴＲＵからの受信に基づいてＷＴＲＵによって決定されたＣＯＴ情報を、基地局（例えば、ｇＮＢ）に報告してもよい。例えば、そのような報告は、ＨＡＲＱフィードバック、ＣＧ－ＵＣＩ、ＭＡＣ ＣＥ、又はＲＲＣメッセージの形態で、ＰＵＣＣＨ、ＳＲにおいて送られ得る。ＣＯＴ情報は、次のいずれかを含んでもよい、すなわち、（１）ＣＯＴ構造（例えば、ＣＯＴに関連付けられた時間／周波数リソース）、（２）残りのＣＯＴ持続時間、（３）ＣＯＴに関連付けられた（又はＣＯＴを開始するために使用される）ＣＡＰＣ、（４）ＷＴＲＵによって収集されるＬＢＴ統計（例えば、ＣＷ内の占有された／利用可能なリソースの数）、（５）Ｌ２ ＩＤ、ＷＴＲＵタイプ（例えば、感知／非感知ＷＴＲＵ、ＤＲＸ ＷＴＲＵ、ＷＴＲＵのリリース又はプロファイル）、ＩＣ／ＯＯＣ ＷＴＲＵ、及び／又はＩＣ ＷＴＲＵに関連付けられたセルＩＤ（モード１で動作している可能性がある）など、ＣＯＴを開始した又はＣＯＴ情報を送信したＷＴＲＵ又は送信のＣＯＴタイプ（本明細書の定義による）又はＣＯＴの使用可能性プロパティを決定するＣＯＴの特性、（６）チャネル／キャリア／ＬＢＴ帯域幅のＲＳＳＩ測定、（７）チャネル占有、（８）ＣＣＡ結果、（９）ＣＯＴを開始するために使用されるエネルギー検出閾値、（１０）ＣＯＴを開始するために使用されるＬＢＴタイプ又はパラメータ、（１１）ＦＦＰパラメータ、（１２）ＣＯＴに関連付けられたＬＢＴ ＢＷのセット（これは、ＬＢＴが実行されたＢＷのセット、ＬＢＴが成功したと見なされたＢＷのセット、又はＬＢＴが失敗したと見なされたＢＷのセットを含んでもよい）、（１３）ＣＯＴ内に配置された（感知に基づく）占有／利用可能リソース、（１４）ＣＯＴを開始した送信に関連付けられたＱｏＳ情報（例えば、優先度）、（１５）２つのサイドリンク送信間の予想されるギャップ、又は２つのサイドリンク送信間のギャップの存在、（１６）ＣＯＴを開始した送信が初期送信であるか再送であるか、（１７）ＣＯＴを開始したノードの識別、（１８）ＣＯＴがＷＴＲＵによって共有されているかどうか、及び／又は（１９）ＣＯＴが基地局（例えば、ｇＮＢ）又は別のＷＴＲＵによって共有されてもよいかどうかである。

【0115】

ＣＯＴ情報はまた、ＣＯＴ内の、１つ以上の他のＷＴＲＵ又は当該ＷＴＲＵによる送信がいつ終了されるか（すなわち、時間位置）についての情報を含んでもよい（例えば、ＷＴＲＵは、そのＳＣＩの送信によるＣＯＴの開始を示すＳＣＩの受信に基づいて、ＷＴＲＵによって開始されたＣＯＴの存在を決定してもよい。ＳＣＩは、ＣＯＴの持続時間を更に含んでもよい。当該ＷＴＲＵによって受信される１つ以上のＳＣＩは、１つ以上の他のＷＴＲＵによるＣＯＴ内のリソースの意図された使用に関連付けられた情報を更に含んでもよい。例えば、ＷＴＲＵは、ＣＯＴ内のＳＬリソースが利用可能になるＣＯＴ内のタイムスロットを（例えば、ＳＣＩ送信又はＳＣＩ中の情報に基づいて）決定してもよく、このタイミング情報を基地局（例えば、ｇＮＢ）に送信してもよい）。

【0116】

ＣＯＴ情報は、周期的に報告されてもよい。例えば、ＷＴＲＵは、進行中のＣＯＴ及びＣＯＴに関連付けられた任意のＣＯＴ情報があるかどうかを送信するための周期的なリソースを有してもよい。

【0117】

ＷＴＲＵは、ＣＯＴ情報を基地局（例えば、ｇＮＢ）に報告するようにトリガされてもよい。トリガは、次のうちの少なくとも１つを含んでもよい、すなわち、（１）ＤＣＩの受信、（２）ＤＣＩの内容（例えば、ＤＣＩ中のフィールドがＣＯＴ情報の報告をトリガしてもよい）、（３）ＳＣＩの受信、（４）ＳＣＩの内容（例えば、ＳＣＩ中のフィールドがＣＯＴ情報の報告をトリガしてもよい）、（５）ＣＯＴを使用するためのＳＲの送信、（６）ＬＢＴの結果に基づく。例えば、ＷＴＲＵは、ＣＯＴを共有若しくは開始するためのＬＢＴに成功若しくは失敗した場合、ＣＯＴ情報を報告してもよい、及び／又は（７）異なるＣＯＴを開始するための要求に基づく、である。ＷＴＲＵは、１つ以上の他のＷＴＲＵからの送信の受信に基づいて、１つ以上のＣＯＴ情報を報告してもよい。

【0118】

一実施形態では、ＷＴＲＵは、場合によってはネットワークによって提供されるＳＬ許可に関連付けられた、ＳＬ上でＷＴＲＵ自体によって開始／使用されたＣＯＴに関連付けられたＵＬリソース上でＣＯＴ情報を報告してもよい。そのような報告は、例えば、ＨＡＲＱフィードバック、ＣＧ－ＵＣＩ、ＭＡＣ ＣＥ、又はＲＲＣメッセージの形態で、ＰＵＣＣＨ、ＳＲにおいて送られてもよい。そのような情報は、前述の実施形態における情報（例えば、ピアＷＴＲＵから受信されたＷＴＲＵ報告情報）と同様の情報のいずれかを含んでもよい。加えて、ＷＴＲＵは更に、次を報告してもよい、すなわち、（１）ＣＯＴが開始された／終了すべき時間インスタンス、（２）ＷＴＲＵによって収集されるＬＢＴ統計（例えば、ＣＷ内の占有された／利用可能なリソースの数）、（３）ＣＯＴを開始した送信のＨＡＲＱプロセスＩＤ、（４）ＷＴＲＵがＣＯＴを開始するのに成功／不成功であったかどうか（成功しなかった場合、理由は、例えば、エラー理由、又は失敗したＬＢＴに関連付けられた何らかの統計、例えば、ＲＳＳＩ、ＣＷ中の利用可能なリソースの数などであってもよい）、（５）ＷＴＲＵが共有ＣＯＴでの送信に成功した／失敗したかどうか、（６）ＷＴＲＵが、それ自体のＣＯＴを開始したのでチャネルを取得したか、又は別のＷＴＲＵとＣＯＴを共有したか、（７）（ＷＴＲＵが共有することができた）ＣＯＴ内に残っている時間の量、又はそのような時間が閾値を上回る／下回るかどうか（そのような閾値は、ＷＴＲＵによって送信されるデータのプロパティ（例えば、優先度）に依存してもよい）、（８）場合によっては特定の時間にわたって、場合によっては特定のＣＡＰＣ又はＬＢＴ挙動に関連付けられた、ＷＴＲＵがＣＯＴを開始することに成功した／失敗した回数、（９）及び／又はＣＯＴを開始又は共有した送信に関連付けられたＬ２ ＩＤである。

【0119】

ＷＴＲＵは、ＣＯＴ情報を周期的に又は非周期的に報告してもよい。周期又は非周期的報告は、ピアから受信されたＣＯＴ情報の報告のために、本明細書で説明される方法を再利用してもよい。

【0120】

一例示的な実施形態では、ＷＴＲＵは、ＬＢＴが成功したかどうかを示すための（場合によってはＳＬ許可に関連付けられた）１つのＰＵＣＣＨリソースと、ＨＡＲＱ ＡＣＫ／ＮＡＣＫを基地局（例えば、ｇＮＢ）に報告するための（場合によっては同じＳＬ許可に関連付けられた）別のＰＵＣＣＨリソースとで構成されてもよい。具体的には、ＷＴＲＵが、許可においてＳＬチャネルを取得することができる場合、それは、第１のＰＵＣＣＨリソースにおいてＡＣＫを送信してもよく、次いで、ＲＸ ＷＴＲＵからのＳＬ ＨＡＲＱフィードバックに基づいて、第２のＰＵＣＣＨリソース上でＡＣＫ／ＮＡＣＫを送信してもよい。代替的に、第１のＰＵＣＣＨリソース上で提供される情報は、（１）許可上でのＷＴＲＵによる送信が、（例えば、第１のコードポイントを使用して示される）既存のＣＯＴを共有することによって、若しくは（第２のコードポイントを使用して示される）新しいＣＯＴを開始することによって達成されたか、又は（第３のコードポイントを使用して示される）チャネルが許可のために取得されなかったか、又は（２）ＷＴＲＵが、閾値よりも大きい（第１のコードポイントを使用して）若しくは小さい（第２のコードポイントを使用して）残りのＣＯＴ長を伴うＣＯＴを取得したことを示してもよく、ここで、その閾値は、ＰＤＵに含まれる、若しくはＢＳＲで報告されるバッファ中のデータの優先度に基づいてもよい。ＷＴＲＵはまた、それが許可のためのチャネルを取得しなかったことを（第３のコードポイントを使用して）示してもよい。

【0121】

別の方法では、ＷＴＲＵは、単一のＰＵＣＣＨリソース上でフィードバックを送信してもよい。フィードバックは、３つの状態、ＡＣＫ、ＮＡＣＫ、又はＤＴＸのうちの１つを示してもよく、ここで、ＤＴＸは、失敗したＬＢＴに起因して送信が実行されなかったことを示してもよい。

【0122】

一例示的な実施形態では、ＷＴＲＵは、モード１ ＳＬ許可について、その許可のためのチャネルを取得することができるかどうか、及び既存のＣＯＴを使用するか、又は新しいＣＯＴを開始するかを決定してもよい。そのような決定は、本明細書で更に説明される。そのような決定に続いて、ＷＴＲＵは、（例えば、ＵＣＩの形態で）許可に続いて基地局（例えば、ｇＮＢ）に提供されるべき情報を決定してもよい。ＷＴＲＵが既存のＣＯＴを共有する場合、ＷＴＲＵは、（例えば、そのＣＯＴ内で送信されるＳＣＩにおいて）別のＷＴＲＵからＣＯＴ構造情報を受信し、ＵＣＩにおいてＣＯＴ構造（例えば、残りのＣＯＴ長、ＣＡＰＣなど）を基地局（例えば、ｇＮＢ）に送信してもよい。

【0123】

ＷＴＲＵがそれ自体のＣＯＴを開始する場合、ＷＴＲＵは、チャネルを取得するために使用される送信及び／又はＬＢＴパラメータに含まれるデータのＣＡＰＣに基づいてＣＯＴ構造を示すＵＣＩを作成し、作成されたＵＣＩを基地局（例えば、ｇＮＢ）に送信してもよい。ＷＴＲＵがチャネルを取得することができない場合、ＷＴＲＵは、そのようなことをＵＣＩにおいて示してもよく、次などのアクセスに失敗した理由に関する追加の情報を含めてもよい、すなわち、（１）新しいＣＯＴを取得しようとするときのＬＢＴ失敗、及び失敗に関連付けられた潜在的なＬＢＴ統計、（２）別のＷＴＲＵによって開始された既存のＣＯＴを取得しようとするときのＬＢＴ失敗、及び失敗に関連付けられた潜在的なＬＢＴ統計（例えば、送信間のギャップ及びＷＴＲＵが実行することを要求されたＬＢＴのタイプ）、（３）許可の時点における既存のＣＯＴの残りのＣＯＴ長は、必要とされるよりも短く、したがって、ＷＴＲＵによって取得されない、及び／又は（４）ＣＯＴを開始した送信に関連付けられたＬ２ ＩＤである。

【0124】

一例では、ＷＴＲＵは、ＳＬチャネルを取得することの失敗を示すために、ＳＲリソースで構成されてもよい。ＷＴＲＵは、ＬＢＴが失敗した許可上で送信されるべきであったＰＤＵ中で多重化されたデータの優先度に応じて、異なるＳＲ構成で更に構成されてもよい。

【0125】

ＷＴＲＵは、上記で説明された実施形態において説明されるＣＯＴ情報の報告をトリガ／送信してもよい。ＷＴＲＵは、ＷＴＲＵが、場合によっては１つ以上のＳＬ許可又は構成されたＳＬ許可に関連付けられたチャネルを取得することができないとき、ＣＯＴ情報の報告をトリガ／送信してもよい。例えば、ＷＴＲＵは、ＳＬ許可に関連付けられたリソース上でＬＢＴ手順を実行することに成功できない場合、ＨＡＲＱ ＮＡＣＫ、ＳＲ、又は同様のＵＬ送信を送ってもよい。例えば、ＷＴＲＵは、許可ＬＢＴ手順に関連付けられた最初／最後のリソース（例えば、許可のための最初／最後の再送信リソース）が失敗するとき、ＵＬ送信を実行してもよい。例えば、ＷＴＲＵは、ネットワークによるＳＬ許可に関連付けられた少なくともｘ個のリソースを取得することができないときに、ＵＬ送信を実行してもよく、ここで、ｘは、（事前に）構成されもてよく、本明細書で説明される１つ以上の他の要因に依存してよい。

【0126】

ＷＴＲＵは、（それ自体のチャネルアクセスに基づいて）開始することができた、又は（別のＷＴＲＵからの受信に基づいて）検出することができた新しい可能なＣＯＴに関する情報をＷＴＲＵが受信したときに、ＣＯＴ情報の報告をトリガ／送信してもよい。一例では、ＷＴＲＵは、（例えば、別のＷＴＲＵからのＳＣＩ受信に基づいて）別のＷＴＲＵによって開始されたＣＯＴの決定時に、（例えば、ＭＡＣ ＣＥにおいて）ＣＯＴ情報を基地局に送信してもよい。

【0127】

別の例では、ＷＴＲＵは、以前に基地局に報告されたＣＯＴ情報の変化時に、（例えば、ＭＡＣ ＣＥにおいて）ＣＯＴ情報を基地局（例えば、ｇＮＢ）に送信してもよい。例えば、ＣＯＴ情報の変化は、（事前に）構成された閾値よりも大きいＣＯＴ内のギャップの（例えば、ＳＬ送信の欠如による）発生であってもよい。ＣＯＴ情報の変化は、（場合によっては第１のＷＴＲＵによって）同じＣＯＴに対して最初に示されたＣＯＴ長よりも短い予想されるＣＯＴ長を示すメッセージの（例えば、第２のＷＴＲＵからの）受信であってもよい。

【0128】

ＷＴＲＵは、他のＷＴＲＵから受信された、又はＷＴＲＵによって決定されたＣＯＴ情報を報告するかどうかに関する条件で（例えば、ＲＲＣ構成を介して、又はＭＡＣ ＣＥを介して）ＷＴＲＵが構成されるとき、ＣＯＴ情報の報告をトリガ／送信してもよい。例えば、条件は、次を含んでもよい、すなわち、（１）残りのＣＯＴ長が閾値よりも小さい／大きい限り、（例えば、新たに検出されたＣＯＴについての）ＣＯＴ情報を報告する、（２）ＣＡＰＣが閾値より上／下である限り、ＣＯＴ情報を報告する、（３）ＣＯＴ内の（潜在的に計画された）送信における最大時間ギャップが閾値を上回る／下回る限り、ＣＯＴ情報を報告する、及び／又は、（４）以前の報告と比較して、（潜在的に同じ）ＣＯＴの情報は、場合によっては特定の量だけ変化している（例えば、ＣＯＴ長は、ある量だけ変化する）場合、ＣＯＴ情報を報告する、である。

【0129】

上記の条件に対する閾値は、優先度、残りのＰＤＢ、又はＣＢＲなどのチャネルの測定値など、ＷＴＲＵによる送信に利用可能なデータに依存してもよい。例えば、ＷＴＲＵは、ＷＴＲＵにおける送信のために保留中のデータの優先度に基づいて、閾値ＣＯＴ長を決定してもよい。ＷＴＲＵが、そのＣＯＴ長が決定された閾値より大きいＣＯＴを（別のＷＴＲＵからの情報の受信に基づいて）検出した場合、ＷＴＲＵは、ＣＯＴ情報を基地局に報告してもよい。

【0130】

ＷＴＲＵは、複数のＣＯＴを維持してもよい。例えば、ＷＴＲＵは、第１のノード（例えば、基地局）に関連付けられた第１のＣＯＴ、及び第２のノード（例えば、別のＷＴＲＵ）に関連付けられた第２のＣＯＴを維持してもよい。ＷＴＲＵは、各ＣＯＴに対して異なるＣＯＴパラメータを維持してもよい。例えば、ＷＴＲＵは、第１のＣＯＴを共有してもよく、第２のＣＯＴを開始してもよい。ＷＴＲＵは、例えば、基地局（例えば、ｇＮＢ）への送信のために、基地局（例えば、ｇＮＢ）に関連付けられたＣＯＴのみを使用してもよい。ＷＴＲＵは、別のＷＴＲＵへの送信のために基地局（例えば、ｇＮＢ）に関連付けられたＣＯＴを共有してもよい。ＷＴＲＵは、基地局（例えば、ｇＮＢ）への送信においてＣＯＴ情報のセットを示してもよい。基地局（例えば、ｇＮＢ）に送信されるＣＯＴ情報のうちの１つは、基地局（例えば、ｇＮＢ）に関連付けられたＣＯＴに関連付けられてもよい。

【0131】

一実施形態では、ＷＴＲＵは、送信されるべきＳＬデータを有することをネットワークに指示すると、ＳＬ上でＬＢＴ手順を開始してもよい。例えば、ＷＴＲＵは、ＬＢＴを開始するＳＬ ＳＲ／ＢＳＲの送信に続く時間インスタンスで（事前）構成されてもよい。そのような時間インスタンスは、ＱｏＳ、キャスト、又はＢＳＲにおいて提供される情報（例えば、ＬＣＧ、宛先インデックスなど）など、送信されるべきデータのプロパティに依存してもよい。

【0132】

別の実施形態では、ＷＴＲＵは、ＤＣＩにおける許可の受信時に、又はＤＣＩの受信に続く何らかの時間期間に、ＳＬ上でＬＢＴ手順を開始してもよい。時間期間は、（事前）構成され、ＤＣＩにおいて示され、及び／又は送信のＳＬ及び／又はＱｏＳの測定に依存してもよい。

【0133】

別の実施形態では、ＷＴＲＵは、複数のＳＬ許可を（場合によっては単一のＤＣＩを、場合によってはＤＣＩ及びＲＲＣ又はＭＡＣ ＣＥによって構成されたパターンを）提供されてもよい。複数のＳＬ許可は、ＤＣＩ内で明示的に示されてもよい。代替的に、複数のＳＬ許可は、事前定義された時間／頻度パターンに従ってもよい。許可の目的は、ＷＴＲＵがＳＬ上でＬＢＴ手順を複数回試みることを可能にすることであってもよい。具体的には、ＷＴＲＵは、第１の許可においてＬＢＴを試みてもよい。ＬＢＴが失敗した場合、それは、第２の許可上でＬＢＴを試みてもよく、以下同様である。

【0134】

ＷＴＲＵは、（例えば、本明細書で説明されるＵＣＩ又はＣＯＴ情報を使用して）ＬＢＴを用いてチャネルにアクセスすることに成功したかどうかをネットワークに更に通知してもよい。ＷＴＲＵは更に、前の許可でのチャネル取得に続く任意の後続の許可をキャンセルしてもよい。代替的に、ＷＴＲＵは、次に基づいて後続の許可を保持するかキャンセルするかを決定するように構成されてもよい、すなわち、（１）バッファ中のデータ量（例えば、ＷＴＲＵが、場合によっては特定の優先度に関連付けられた送信に利用可能なデータを有する場合、それは後続の許可のうちの１つ以上を維持してもよい）、（２）チャネルの輻輳（例えば、ＣＢＲが閾値を上回る場合、ＷＴＲＵは後続の許可をキャンセルしてもよく、そうでない場合、それらを保持してもよい）、（３）残りの後続の許可の数（例えば、ＷＴＲＵは、それが維持することができる後続の許可の最大数で構成されてもよく、残りをドロップしてもよい、（４）バッファ中のデータの優先度、（５）上記の（１）から（４）の任意の組み合わせ、及び／又は（６）本明細書で説明される任意の他の条件（例えば、本明細書で説明されるマルチＬＢＴオケージョンに関連付けられる）である。

【0135】

ＷＴＲＵは、複数のＳＬ許可の同じセット中の前の許可の前にＬＢＴが成功したかどうか、及び直近の成功したＬＢＴからの持続時間、並びに次の許可の前にギャップがあるかどうかに応じて、複数のＳＬ許可のセット中の次の許可のリソースの前にＬＢＴが必要とされるかどうかを決定してもよい。

【0136】

複数のＳＬ許可を用いてスケジュールされたＷＴＲＵは、複数のＳＬ許可のセット中の１つ以上のＳＬ許可のパラメータに基づいて、既存のＣＯＴを共有するか、又は新しいＣＯＴを開始するかを選択してもよい。例えば、ＷＴＲＵは、ＣＯＴ内で送信されてもよい複数のＳＬ許可のセットにおける許可の量に応じて、既存のＣＯＴを共有するかどうかを決定してもよい。例えば、ＷＴＲＵが、ＳＬ許可のセット中にｎ個のＳＬ許可を有し、進行中のＣＯＴが、ｍ個のＳＬ許可の送信のために十分なリソースを有する場合、ＷＴＲＵは、ｍ及びｎに応じて、進行中のＣＯＴを共有するか、又は新しいＣＯＴを開始するかを決定してもよい。ＷＴＲＵは、複数のＳＬ許可のセットのうちの１つ以上における送信の優先度に応じて、進行中のＣＯＴを共有するか、又は新しいＣＯＴを開始するかを決定してもよい。

【0137】

ＳＬ上でのＣＯＴ情報の送信は、ＷＴＲＵがＣＯＴを開始するか、又は共有するかに依存してもよい。

【0138】

送信ＳＬ ＷＴＲＵは、それ自体の送信とともに、ＳＬ上でＣＯＴ情報（例えば、ＣＯＴ構造）を送信してもよい。例えば、ＷＴＲＵは、ＳＣＩ、ＳＬ ＭＡＣ ＣＥ、専用ＰＨＹチャネル、ＳＬ ＲＲＣ、ＵＣＩ、ＣＧ－ＵＣＩ、ＳＬ－ＵＣＩ、又はそれらの組み合わせにＣＯＴ情報を含めてもよい。ＣＯＴ情報は、本明細書で説明される情報、又は従来技術におけるＣＯＴ情報、又はそれらの組み合わせを含んでもよい。

【0139】

一実施形態では、ＷＴＲＵは、ＷＴＲＵがＣＯＴを開始するか、又は別のＷＴＲＵ若しくは基地局によって開始されたＣＯＴを共有するかに基づいて、送信のためにそれ自体のＣＯＴ情報を作成するか、又は別のＷＴＲＵ若しくは基地局から受信されたＣＯＴ情報を転送／送信するかを決定してもよい。具体的には、ＷＴＲＵの許可又は潜在的な許可が既存のＣＯＴに入らない場合、ＷＴＲＵは、それ自体のＣＯＴを開始してもよく、それ自体の送信内でＣＯＴを作成するために使用されたＬＢＴに基づいてＣＯＴ情報（ＣＯＴ構造）を作成してもよい。

【0140】

ＷＴＲＵの許可又は潜在的な許可が、基地局又は別のＷＴＲＵによって開始されるＣＯＴ内に入る場合、ＷＴＲＵは、他のＷＴＲＵ又は基地局の送信において受信されたＣＯＴ情報（すなわち、他のＷＴＲＵによって示されたＣＯＴ構造）を送信してもよい。ＷＴＲＵは、既存のＣＯＴのための別のＷＴＲＵからのＣＯＴ情報において受信された情報に応じて、既存のＣＯＴを共有するか、又は新しいＣＯＴを開始するかを決定してもよく、ここで、ＣＯＴ情報において受信された情報は、本明細書において説明される。

【0141】

ＷＴＲＵは、それ自体の送信、及び／又はそれ自体の受信（例えば、別のＷＴＲＵによって開始されたＣＯＴを共有するとき）に関連付けられた要因の１つ又は組み合わせに基づいて、そのＬＢＴ挙動を決定してもよい。ここで、組み合わせという用語は、ＬＢＴ挙動を決定する際に２つ以上の要因を使用することを指してもよい。組み合わせは、１つの要因の存在に起因して１つの挙動を除外し、他の要因に基づいて残りの挙動から選択することを指してもよい。組み合わせは、第１の要因に基づいて１つのＬＢＴ挙動を決定し、第２の要因に基づいて別のＬＢＴ挙動を決定することを指してもよい。組み合わせは、要因に基づいて決定するＬＢＴ挙動の数又はタイプを決定すること、同時に、別の要因に基づいて挙動を選択することを指してもよい。

【0142】

例えば、以下の要因のいずれかが、ＣＯＴを開始するときにＬＢＴ挙動（例えば、ＬＢＴパラメータ）を決定するために使用されてもよい。加えて、以下の要因のいずれかを使用して、ＷＴＲＵが既存のＣＯＴを共有できるかどうか、及び／又はＣＯＴを共有するためにチャネルにアクセスするときにどのＬＢＴ挙動（例えば、ＬＢＴパラメータ）を使用すべきかを決定してもよい。更に、ＣＯＴを共有するときに使用されるべきＬＢＴ挙動は、ＣＯＴを開始した送信及び／又はＣＯＴを共有することになるＷＴＲＵによって計画される送信に関連付けられる以下の要因に依存してもよい。例えば、Ｌ２ ＩＤの場合、それは、ＣＯＴを開始するために使用されるＬ２ ＩＤ及び／又はＣＯＴを共有する送信のＬ２ ＩＤであり得る）。

【0143】

ＣＯＴを開始するときにＬＢＴ挙動（例えば、ＬＢＴパラメータ）を決定するための要因は、次を含んでもよい、すなわち、（１）キャストタイプ、（２）サイドリンク送信のソース／宛先、（３）ＨＡＲＱ挙動、（４）送信／受信のＱｏＳ、（５）（最小通信範囲（ＭＣＲ）関連量、（６）ゾーン関連量、（７）ＣＢＲ関連量、（８）２つのＷＴＲＵ間の距離、（９）グループ関連量、（１０）メッセージタイプ、（１１）ＳＬチャネル又はチャネルタイプ、（１２）送信又は再送信タイプ、残りのＰＤＢ又は時間レイテンシ要件、（１３）送信に関連付けられたＳＣＩに含まれる任意の内容に基づく、（１４）感知メカニズム及び／又は感知結果に関連する任意のパラメータ、（１５）リソースプールに関連付けられる、（１６）割り当てモード、（１７）以前の送信とＷＴＲＵ自体の送信との間の時間、（１８）グループキャストにおけるメンバＩＤ、（１９）Ｌ２ソース／宛先ＩＤ、及び／又は（２０）、ＷＴＲＵ又は他のＷＴＲＵによるリソースの予約に関連する、である。

【0144】

キャストタイプは、計画又は実行された送信がユニキャスト、グループキャスト、又はブロードキャストに対応するかどうかを指してもよい。キャストタイプは、受信された送信がユニキャストに対応するか、グループキャストに対応するか、ブロードキャストに対応するかを指してもよい。キャストタイプは、ＷＴＲＵが、送信に利用可能な特定のキャストタイプのデータを有するかどうかを指してもよい。キャストタイプは、ＷＴＲＵが確立された特定のユニキャストリンクを有するかどうかを指してもよい。キャストタイプは、ＷＴＲＵが特定のキャストタイプに関連付けられたサービスに関心があるかどうかを指してもよい。例えば、ＷＴＲＵは、送信／受信がユニキャストであるとき、占有を決定するために第１のＬＢＴタイプ若しくはカテゴリ、又はタイムスロットの数を使用してもよく、送信／受信がブロードキャスト／グループキャストであるとき、占有を決定するために第２のＬＢＴタイプ若しくはカテゴリ、又はタイムスロットの数を使用してもよい。例えば、ＷＴＲＵは、ユニキャスト送信のためにＤＬ ＣＡＰＣテーブルを使用してもよく、グループキャスト／ブロードキャスト送信のためにＵＬ ＣＡＰＣテーブルを使用してもよい。例えば、ユニキャストリンクを伴う２つのＷＴＲＵは、ＷＴＲＵのうちのどちらがＤＬ ＣＡＰＣテーブルを使用し、どちらがＵＬ ＣＡＰＣテーブルを使用するかを（場合によってはＰＣ５－ＲＲＣシグナリングを使用して）ネゴシエートしてもよい。例えば、ＷＴＲＵは、ユニキャスト送信のためのＣＯＴ開始のために使用するための１つ以上のＣＯＴ長（場合によっては、優先度などの他の要因に関連付けられている）、及びグループキャスト／ブロードキャスト送信のためのＣＯＴ開始のために使用するための別の１つ以上のＣＯＴ長で構成されてもよい。

【0145】

（Ｌ２ ＩＤなどの）サイドリンク送信のソース／宛先は、Ｌ２ ＩＤが、特定のＬＢＴ挙動が必要とされるいくつかの（事前に）構成されたＬ２ ＩＤ又はＩＤのセットと一致するかどうかを指してもよい。サイドリンク送信のソース／宛先は、受信が１つ又は任意のＬ２ ＩＤを含むか、又はそれに関連付けられているかどうかを指してもよい。例えば、ＷＴＲＵは、Ｌ２ ＩＤが、そのＬ２ ＩＤ送信のために適用されるべきＣＯＴ共有及び／又はＬＢＴ挙動及び／又は間接番号（又は同様のもの）を可能にすることができるかどうかの指示を（ネットワークから又は上位層から）受信してもよく、そのＬ２ ＩＤを対象とするＰＤＵの送信／受信に続くＬＢＴ挙動を決定してもよい。例えば、ＷＴＲＵは、ＣＯＴが、ＷＴＲＵがＬ２ ＩＤを受信することに関心があるＬ２ ＩＤへのピアＷＴＲＵによる送信によって開始された場合、ピアＷＴＲＵとＣＯＴを共有してもよい。例えば、ＷＴＲＵは、送信に関連付けられたＬ２ ＩＤが受信Ｌ２ ＩＤと同じである場合（例えば、送信が同じユニキャストリンクに対して実行される、送信が同じグループキャストＬ２ ＩＤに対して実行されるなど）、ＳＬ上での受信に続いて低減されたＬＢＴ要件（すなわち、ＣＯＴを共有するために必要とされるＬＢＴ）を用いて送信することを許可されてもよい。

【0146】

ＷＴＲＵは、複数のピアＵＥからＣＯＴ情報を受信してもよく、それらのうちの１つ以上に基づいて、それ自体のＬＢＴ挙動、及び／又はＣＯＴを開始／共有するかどうかを決定してもよい。一例では、ＷＴＲＵは、最長／最短の示されたＣＯＴ長、最高／最低の示された優先度、送信ＷＴＲＵ自体のデータ優先度に関連付けられた条件に一致する優先度、（ピアＷＴＲＵとＣＯＴ情報を受信する送信ＷＴＲＵとの間の距離に関して）最も近いピアＷＴＲＵなどに関連付けられたピアＷＴＲＵから受信されたＣＯＴ情報を使用してもよい。

【0147】

別の例では、ＷＴＲＵは、ＷＴＲＵ自体の送信の優先度など、本明細書の他の要因に基づいて、１つのルール（例えば、最小又は最大、最高／最低優先度、などに関連付けられたＣＯＴ情報）を使用するか、別を使用するかを決定してもよい。例えば、高優先度送信の場合、ＷＴＲＵは、最長のＣＯＴ長のＣＯＴ情報を使用してもよく、低優先度送信の場合、ＷＴＲＵは、最短のＣＯＴ長のＣＯＴ情報を使用してもよい。

【0148】

ＨＡＲＱ挙動は、送信／受信がＨＡＲＱ有効化又はＨＡＲＱ無効化に関連付けられているかどうかを指してもよい。ＨＡＲＱ挙動は、（事前に）構成されたＨＡＲＱ遅延又はサイドリンク上のＲＴＴを指してもよい。ＨＡＲＱ挙動は、ＨＡＲＱ固有チャネル（ＰＳＦＣＨ又はＰＵＣＣＨ）が構成されているかどうかを指してもよい。ＨＡＲＱ挙動は、場合によっては送信又は受信される特定のタイプ（ＡＣＫ／ＮＡＣＫ／ＤＴＸ）の、いくつかの潜在的に連続したＨＡＲＱフィードバックを指してもよい。ＨＡＲＱ挙動は、１つ以上のＨＡＲＱフィードバックを送るために必要な時間を指してもよい。ＨＡＲＱ挙動は、使用されているグループキャストＨＡＲＱのタイプ（例えば、ＡＣＫ／ＮＡＣＫ又はＮＡＣＫのみ）を指してもよい。ＨＡＲＱ挙動は、ＷＴＲＵがＨＡＲＱ ＡＣＫを送信するかＨＡＲＱ ＮＡＣＫを送信するかを指してもよい。

【0149】

送信／受信のＱｏＳは、送信の優先度を指してもよい。送信／受信のＱｏＳは、ＳＬＲＢに関連付けられた（事前に）構成されたパラメータを指してもよい。送信／受信のＱｏＳは、ＰＱＩ、又はＱｏＳフローに関連した同様のＱｏＳパラメータを指してもよい。送信／受信のＱｏＳは、送信がＳＬ ＳＲＢ上であるか、又はＳＬ ＤＲＢ上であるかを指してもよい。例えば、ＷＴＲＵは、送信が第１の優先度に関連付けられているときにチャネルを取得するためにＬＢＴパラメータの第１のセットを仮定し、送信が第２の優先度に関連付けられているときにチャネルを取得するためにＬＢＴパラメータの第２のセットを仮定してもよい。例えば、ＷＴＲＵは、受信された優先度が第１の優先度である場合、ＣＯＴ長、又は別のＷＴＲＵの受信に続いて完全なＬＢＴを実行しない時間が第１の値であると仮定してもよく、受信された優先度が第２の優先度である場合、第２の値を仮定してもよい。

【0150】

ＭＣＲ最小通信範囲（ＭＣＲ）関連量は、ＷＴＲＵによって送信／受信されるＭＣＲの値を指してもよい。ＭＣＲ関連量は、ＭＣＲが送信されるかどうかを指してもよい。ＭＣＲ関連量は、ＷＴＲＵが、送信のＭＣＲ内にあると決定するかどうかを指してもよい。ＭＣＲ関連量は、ＷＴＲＵがＭＣＲの外側／内側である前に残っている距離を指してもよい。ＭＣＲ関連量は、送信機と受信機との間の計算された距離を指してもよい。ＷＴＲＵは、そのＷＴＲＵとそれ自体との間の計算された距離に基づいて、別のＷＴＲＵからの受信に続く送信のためのそのＬＢＴパラメータを決定又は修正してもよい。ＷＴＲＵは、距離が閾値を上回る限り、常にタイプ１のＬＢＴを実行してもよい。

【0151】

ＷＴＲＵは、送信のＭＣＲに基づいて、そのＬＢＴパラメータを決定してもよい。具体的には、ＷＴＲＵは、ＭＣＲ又はＭＣＲの範囲についてのＣＷ長（又はそのＬＢＴに影響を及ぼす他のパラメータ）で構成されてもよい。ＭＣＲに関連付けられたＴＢの場合、ＷＴＲＵは、適切なＣＷ長を選択してもよい。ＷＴＲＵは、特定のベースライン値からのＭＣＲの各増加に対して適用されるオフセット（例えば、ＣＷ長の増加）で構成されてもよい。ＷＴＲＵは、送信がＭＣＲ及び／又はＭＣＲの値を有するかどうか（例えば、閾値を上回る又は下回る）に基づいて、ＵＬ ＣＡＰＣテーブルを使用するか、又はＤＬ ＣＡＰＣテーブルを使用するかを決定してもよい。ＷＴＲＵは、（上位層によって決定される）グループであるＷＴＲＵの数に基づいて、作成するＣＯＴの長さを決定してもよい。

【0152】

ゾーン関連量は、ＷＴＲＵが位置する特定のゾーン、及びそのようなゾーンが１つ以上の（事前に）構成されたゾーン（の、例えば、リストの一部）に関連付けられているかどうかを指してもよい。ゾーン関連量は、ＷＴＲＵが別のＷＴＲＵと同じゾーンに位置するかどうかを指してもよい。ゾーン関連量は、構成されたゾーンサイズを指してもよい。

【0153】

ＣＢＲ関連量は、ＷＴＲＵにおいて測定されたＣＢＲを指してもよい。ＣＢＲ関連量は、ＣＢＲが閾値を下回るか上回るかを指してもよい。ＣＢＲ関連量はまた、ＣＢＲが測定されることができるかどうかを指してもよい。ＣＢＲ関連量はまた、ＣＢＲが測定される時間期間を指してもよい。

【0154】

２つのＷＴＲＵ間の距離は、２つのＷＴＲＵ（例えば、ＣＯＴを開始するＷＴＲＵ及びＣＯＴを共有するＷＴＲＵ）間の決定された距離を指してもよく、これは、例えば、ＳＣＩにおいて送信されたゾーン指示によって計算されてもよい。

【0155】

グループ関連量は、グループ内のＷＴＲＵの数を指してもよい。例えば、グループ関連量は、上位層によって構成されるグループＩＤを指してもよい。グループ関連量はまた、グループキャストＨＡＲＱフィードバックタイプ（ＡＣＫ／ＮＡＣＫ又はＡＣＫのみ）を指してもよい。例えば、ＷＴＲＵは、（上位層によって示される）グループサイズに基づいて、作成するＣＯＴの長さを決定してもよい。具体的には、ＷＴＲＵは、１つ又はグループのセットサイズに対して異なるＣＯＴ長で構成されてもよく、この構成に基づいてＣＯＴ長を選択してもよい。例えば、ＷＴＲＵは、ピアＷＴＲＵの送信がＬ２ ＩＤに対して実行されたかどうかに基づいて、ピアＷＴＲＵによって開始されたＣＯＴを共有するかどうかを決定してもよい。ＷＴＲＵは、ＣＯＴが、ＷＴＲＵが関心のあるＬ２ ＩＤによって開始された場合、ピアＷＴＲＵによって開始されたＣＯＴを共有してもよい。更に、ＷＴＲＵは、ＷＴＲＵが関心を持つＬ２ ＩＤによってＣＯＴが開始された場合、及び／又はＷＴＲＵがそのＬ２ ＩＤのためのグループ番号を割り当てられている場合、そのＬＢＴ挙動を異なるように決定してもよい。例えば、ＷＴＲＵ開始ＣＯＴは、送信内にグループメンバＩＤを含んでもよい。第２のＷＴＲＵは、それが開始ＷＴＲＵとＣＯＴを共有することができるかどうかを決定してもよく、及び／又は開始ＷＴＲＵのグループメンバＩＤと比較したそれ自体のグループメンバＩＤに基づいて送信のために必要とされるＬＢＴ挙動を決定してもよい（例えば、差が閾値より小さい）。

【0156】

メッセージタイプは、送信／受信が、直接通信要求（ＤＣＲ）若しくはユニキャストリンク確立に関連付けられた他のメッセージなど、サイドリンクに関連付けられた特定のメッセージからなるか、又はＣＳＩ報告若しくはＷＴＲＵ間協調メッセージなど、特定のＭＡＣ ＣＥを含むかを指してもよい。例えば、ＷＴＲＵは、ＤＣＲメッセージの受信／送信時に、ＤＣＲメッセージが開始されたユニキャストリンクの確立まで、ＬＢＴが必要とされないか、又は特定のＬＢＴのみが必要とされると仮定してもよい

【0157】

ＳＬチャネル又はチャネルタイプは、特定のＳＬチャネル、例えば、ＳＬ－ＳＳＢ、ＰＳＣＣＨ、ＰＳＳＣＨ、ＰＳＦＣＨなどで送信／受信構成が実行されるかどうかを指してもよい。

【0158】

送信又は再送信タイプは、送信／受信が初期送信からなるか、又は再送信からなるかを指してもよい。例えば、これは、再送信に関連した再送信数を指してもよい。

【0159】

残りのＰＤＢ又は時間レイテンシ要件は、ＬＢＴの時間における送信に関連付けられた残りのＰＤＢを指してもよく、Ｔ２（又は任意の感知ベースのウィンドウ若しくは時間フレーム）に対する時間の量を指してもよい。残りのＰＤＢ又は時間レイテンシ要件は、ＣＳＩフィードバックレイテンシ限界、又は送信時におけるそのレイテンシ限界中の残りの時間を指してもよい。残りのＰＤＢ又は時間レイテンシ要件は、残りのＰＤＢ（又は優先度などの同等のメトリック）と共有されるべきＣＯＴの持続時間との間の関係を指してもよい。

【0160】

送信に関連付けられたＳＣＩに含まれるコンテンツは、ＳＣＩにおける任意の値の不在の存在を指してもよい。例えば、これは、ＳＣＩ中の任意のフィールドの値を指してもよい。送信に関連付けられたＳＣＩに含まれるコンテンツは、ＣＳＩ報告をトリガするためにＳＣＩが使用されるかどうかを指してもよい。送信に関連付けられたＳＣＩに含まれるコンテンツは、ＳＣＩが任意の将来のリソースを予約しているかどうかを指してもよい。送信に関連付けられたＳＣＩに含まれるコンテンツは、現在の送信と将来の予約されたリソースとの間の時間（例えば、それが特定の値を上回るか下回るか）を指してもよい。

【0161】

感知メカニズム及び／又は感知結果に関連する任意のパラメータは、最終的な送信のためのリソースを決定するために使用される特定の感知メカニズム（例えば、完全感知、部分感知、ランダム選択などを使用するかどうか）を指してもよい。感知メカニズムは、非同期感知が実行されているかどうかを指してもよい。感知メカニズムは、プリエンプション／再評価のために感知が実行されているかどうかを指してもよい。感知メカニズムは、利用可能なリソースのパーセンテージ、選択されたリソースの数、選択されたリソース間のタイミング、再送信リソースが選択されたかどうか、十分な数のリソースが利用可能であるかどうか（利用可能性決定の任意の所与のインスタンスにおいて）などのいずれかなどの特定の感知結果を指してもよい。感知メカニズムは、ＣＯＴを表してもよい特定の時間内に利用可能であると見なされるリソースの量、及び／又はＷＴＲＵにおける保留中の送信の必要なレイテンシを指してもよい。

【0162】

リソースプールに関連付けられるとは、特定のリソースプール、又はリソースプールに関連付けられた構成を指してもよく、送信／受信がこのプールに関連付けられたリソース上で行われるときに適用されてもよい。

【0163】

割り当てモードは、送信／受信がモード１であるかモード２であるかを指してもよい。ＷＴＲＵは、ＣＯＴを開始した送信のモード及び／又はそれ自体の送信のモードに基づいて、それがＣＯＴを共有する（例えば、タイプ２ ＬＢＴを実行する）ことができるかどうかを決定してもよい。ＷＴＲＵは、ＣＯＴを共有しようとしているＷＴＲＵが、ＣＯＴを開始したＷＴＲＵと同じ送信モード（モード１又はモード２）を使用している場合、ＣＯＴを共有してもよい。モード２を使用して送信するＷＴＲＵは、モード１及び／又はモード２を使用してＣＯＴを開始したＷＴＲＵとＣＯＴを共有してもよい／共有しなくてもよい。

【0164】

別の要因は、以前の送信とＷＴＲＵ自体の送信との間の時間であってもよい。ＷＴＲＵは、スロットＮ－１において実行される別のＷＴＲＵの送信（以前の送信）を検出した場合、ＣＯＴを共有していると仮定して、スロットＮにおいて送信を実行してもよい。加えて、スロットＮ－１における以前の送信は、本明細書における別の条件（例えば、Ｌ２ ＩＤ／同じユニキャストリンクなど）も満たす必要があってもよい。

【0165】

別の要因は、グループキャストにおけるメンバＩＤであってもよい。具体的には、ＷＴＲＵは、メンバＩＤが第１の値を有するとき、第１のＬＢＴ挙動を仮定してもよく、メンバＩＤが第２の値を有するとき、第２のＬＢＴ挙動を仮定してもよい。例えば、メンバＩＤ＝０を伴うＷＴＲＵは、ＬＢＴのためにＤＬ ＣＡＰＣテーブルを使用してもよく、任意の他のメンバＩＤを伴うＷＴＲＵは、ＬＢＴのためにＵＬ ＣＡＰＣテーブルを使用してもよい。

【0166】

別の要因は、Ｌ２ソース／宛先ＩＤであってもよい。具体的には、ＷＴＲＵは、所与のＬ２ ＩＤ又はＬ２ ＩＤペアに対して適用されるべきＬＢＴ挙動を用いて（例えば、ＰＣ５－ＲＲＣによって、Ｕｕ ＲＲＣによって、上位層によってなど）構成されてもよい。

【0167】

別の要因は、ＷＴＲＵ又は他のＷＴＲＵによるリソースの予約に関連してもよい。例えば、ＷＴＲＵ又は他のＷＴＲＵによるリソースの予約は、（新しいＴＢのために、又は再送信のために）ＷＴＲＵによって以前に予約されたリソース上で送信が実行されるかどうかを指してもよい。具体的には、ＷＴＲＵは、以前に予約されなかった送信のための第１のＬＢＴ挙動、及びそれが以前に予約した送信のための第２のＬＢＴ挙動を仮定してもよい。ＷＴＲＵ又は他のＷＴＲＵによるリソースの予約は、送信が、リソース上で実行されるか、後に続くか、又は別のＷＴＲＵによって予約されたリソース後のある量の時間に実行されるかを指してもよい。例えば、ＷＴＲＵは、別のＷＴＲＵによって予約されたスロットに続くスロットにおいて第１のＬＢＴ挙動（例えば、短いＬＢＴ）を使用してもよく、別のＷＴＲＵによって予約されたスロットに続かないスロットにおいて第２のＬＢＴ挙動（例えば、通常のＬＢＴ）を使用してもよい。同様の手法を使用して、未認可のＶ２Ｘに関するブロッキング問題が解決されてもよい。

【0168】

具体的には、ＷＴＲＵが、スロットｎ上での送信のためにスロットｎ－１上でＬＢＴに失敗し、スロットｎ－１が、別のＳＬ ＷＴＲＵが送信を実行したことを感知結果が示すスロットに関連付けられている場合、ＷＴＲＵは、スロットｎの始めのみで短い感知を実行してもよい。そうでない場合、ＷＴＲＵは、ＬＢＴ失敗に続いて通常のＬＢＴ手順を実行してもよい。

【0169】

ＷＴＲＵによって復号／受信される送信に関連付けられた、又は示された上記の要因のいずれかで、そのような送信は、ＷＴＲＵが共有することを望むＣＯＴ内に含まれていたか、又はＣＯＴを開始した送信に関連付けられるかのいずれかである。本明細書では、ＣＯＴを開始した送信の特性、ＣＯＴ内で最後に検出された送信の特性、又はＣＯＴ内で発生する任意の所与の送信の特性は、交換可能に使用されてもよい。

【0170】

以下の実施形態において明示的に言及されていないが、特定のＬＢＴ挙動と上記に列挙された特定のサイドリンク要因との任意の組み合わせが、当業者によって想定されることができる。

【0171】

一実施形態では、ＷＴＲＵは、上記のサイドリンク係数のうちの１つ以上に基づいてＣＡＰＣを決定してもよい。具体的には、ＷＴＲＵは、送信されているデータから、その送信に関連付けられた１つ以上のデータを決定してもよく、それに応じてＣＡＰＣを選択してもよい。ＷＴＲＵは更に、場合によってはＷＴＲＵがＣＯＴを開始するときに（ＷＴＲＵが既存のＣＯＴを共有するときとは対照的に）、そのようなＣＡＰＣをそれ自体の送信において示してもよい。

【0172】

ＷＴＲＵは、キャストタイプとＬＣＨ構成との組み合わせに基づいてＣＡＰＣを選択するように構成されてもよい。具体的には、ＷＴＲＵは、所与の論理チャネル優先度、及びユニキャスト、グループキャスト、又はブロードキャストの各々に対して使用するために、ＣＡＰＣを用いて構成されてもよい。例えば、送信がユニキャストに関連付けられる場合、ＷＴＲＵは、ユニキャストのためのＬＣＨの優先度に構成されたＣＡＰＣを選択してもよい。そのような場合、ＷＴＲＵは、優先度とキャストタイプの両方のＣＡＰＣへのマッピングを用いて構成されてもよい。

【0173】

ＷＴＲＵは、送信の決定されたＭＣＲに基づいてＣＡＰＣを決定してもよい。例えば、ＷＴＲＵは、優先度とＭＣＲとの組み合わせのために使用されるべきＣＡＰＣを用いて構成されてもよく、ＭＣＲは、ＭＣＲの範囲を含んでもよく、又は送信がＭＣＲを用いて／用いずに構成されるかどうかを含んでもよい。

【0174】

ＷＴＲＵは、ＨＡＲＱが送信に対して有効化されるか無効化されるかに基づいて、ＣＡＰＣを決定してもよい。例えば、ＷＴＲＵは、ＨＡＲＱ有効化送信のために（例えば、ＬＣＨごとに、又は優先度ごとに）使用するＣＡＰＣの第１のセットと、ＨＡＲＱ無効化送信のために使用するＣＡＰＣの第２のセットとを用いて構成されてもよい。

【0175】

ＷＴＲＵは、サイドリンクリソースの測定されたＣＢＲに基づいてＣＡＰＣを決定してもよい。そのようなＣＢＲは、レガシーＳＬ測定ＣＢＲと同様であってもよいか、又は共有スペクトルシナリオに適応されてもよい。例えば、ＷＴＲＵは、ＣＢＲの第１の範囲のために使用するためにＣＡＰＣの第１のセット（例えば、優先度ごとに、又はＬＣＨごとに）を用いて構成されてもよく、ＣＢＲの第２の範囲のために使用するためにＣＡＰＣの第２のセットを用いて構成されてよい、などである。

【0176】

ＷＴＲＵは、特定のサイドリンク送信、又はＳＬ送信が特定のメッセージを含むかどうかのために、固定された、事前定義された、又は（事前）構成されたＣＡＰＣを使用してもよい。例えば、ＤＣＲメッセージは、固定ＣＡＰＣを使用してもよい。例えば、ＳＬ ＭＡＣ ＣＥは、固定ＣＡＰＣを使用してもよい。代替的に、ＷＴＲＵは、特定のＳＬ送信又は特定のメッセージ（例えば、ＤＣＲ）を含む送信のために、任意のＣＡＰＣを使用してもよい。

【0177】

ＷＴＲＵは、ＳＬ ＭＡＣ ＣＥを含む送信に使用するために、特定のＣＡＰＣを用いて構成されてもよい。

【0178】

ＷＴＲＵは、ＳＬ ＣＳＩ ＭＡＣ ＣＥを含む送信のために使用するためにＣＡＰＣの異なる値で構成されてもよく、各ＣＡＰＣ値は、ピアＷＴＲＵへのＣＳＩ報告の送信のために、構成されたレイテンシ限界又はレイテンシ限界中の残り時間のうちの１つ又は範囲に対応してもよい。

【0179】

ＷＴＲＵは、モード１送信のために第１のＣＡＰＣ値又は値のセットを使用してもよく、モード２送信のために第２のＣＡＰＣ値又は値のセットを使用してもよい。

【0180】

ＷＴＲＵは、ＨＡＲＱフィードバックリソースタイミングに基づいて、使用するＣＡＰＣを決定してもよい。ＷＴＲＵは、選択されたリソースと送信に関連付けられたＰＳＦＣＨリソースのタイミングとの間の時間差に関連付けられた（事前に）構成されたＣＡＰＣから選択してもよい。

【0181】

ＷＴＲＵは、送信に関連付けられたＬ２宛先ＩＤに基づいて、使用するＣＡＰＣを決定してもよい。例えば、ＷＴＲＵは、ソース／宛先Ｌ２ ＩＤに関連付けられたＣＡＰＣを用いて構成されてもよく、そのソース／宛先Ｌ２ ＩＤへの全ての（後続の）送信のためにそのＣＡＰＣを使用してもよい。例えば、ＷＴＲＵは、宛先Ｌ２ ＩＤとともに上位層によって提供される上位層情報（例えば、ＴＸプロファイル、ＤＲＸオン／オフ、明示的情報）に基づいてＣＡＰＣを決定してもよい。例えば、ＷＴＲＵは、ＳＬイベント（例えば、ＨＡＲＱ、ＬＢＴ失敗など）に基づいて、Ｌ２ ＩＤに関連付けられたＣＡＰＣを維持／変更してもよく、次のイベントによって変更されるまで、そのＬ２ ＩＤに対してＣＡＰＣを適用してもよい。

【0182】

ＷＴＲＵは、Ｌ２ ＩＤにおける特定の送信のためにアクティブな／構成されたＱｏＳフローに基づいて、使用されるべきＣＡＰＣを決定してもよい。具体的には、ＷＴＲＵは、所与のＬ２ ＩＤ送信に対するＣＡＰＣを、そのＬ２ ＩＤに対してアクティブな１つ以上のＱｏＳフローに関連付けられたＰＱＩ情報に基づいて決定してもよい。ＷＴＲＵは、パラメータ（例えば、優先度）の最高値を伴うフローを選択し、そのパラメータに基づいてＬ２ ＩＤのためのＣＡＰＣを決定してもよい。

【0183】

ＷＴＲＵは、本明細書で説明されるＳＬ固有の要因又は特性に応じてＣＡＰＣを決定するために、異なるルール、マッピングテーブル、又は基準を使用してもよい。例えば、ＷＴＲＵは、ＣＡＰＣへのＰＱＩのマッピングを使用して、モード１送信のためのＣＡＰＣを決定してもよく、ＣＡＰＣへのＬ１優先度又はＬＣＨ優先度のマッピングを使用して、モード２送信のためのＣＡＰＣを決定してもよい。例えば、ＷＴＲＵは、ＣＢＲが閾値を上回るときに第１のマッピングテーブルを使用してもよく、ＣＢＲが閾値を下回るときに第２のマッピングテーブルを使用してもよい。

【0184】

ＷＴＲＵは、ＣＡＰＣを決定するために最初に使用されているＱｏＳパラメータ又はその他の実際の値に応じて、異なるルール、マッピングテーブル、及び／又は基準（又は同様のもの）を使用してＣＡＰＣを決定してもよい。例えば、ＷＴＲＵは、ＰＱＩからＣＡＰＣへのマッピングテーブルを使用して、あるＱｏＳフローのためのデータを含む送信のためのＣＡＰＣを決定してもよい。

【0185】

しかしながら、非標準化ＰＱＩ値の場合、ＷＴＲＵは、次などの異なる手法を使用してもよい、すなわち、（１）固定ＣＡＰＣ値を使用すること、（２）ＰＱＩをＣＡＰＣにマッピングする代わりに、優先度をＣＡＰＣにマッピングするテーブルを使用すること、（３）そのＣＡＰＣに関連付けられた標準化されたＰＱＩのＰＱＩパラメータに最も近いＱｏＳパラメータを有するＰＱＩに関連付けられたＣＡＰＣ値を使用すること、（４）関連付けられた、場合によっては同じＱｏＳ若しくは同様の優先度／ＱｏＳに関連付けられた最後の送信のために、ネットワークによって（例えば、ＤＣＩにおいて）割り当てられたＣＡＰＣ値を使用すること、及び／又は（５）ＳＬ送信においてピアＷＴＲＵによって示された、若しくはＰＣ５－ＲＲＣにおいてピアＷＴＲＵによって構成されたＣＡＰＣ値を（例えば、使用されるべきデフォルトＣＡＰＣ値として）使用することである。

【0186】

ＷＴＲＵは、別のＷＴＲＵ及び／又は基地局（例えば、ｇＮＢ）によって開始されるＣＯＴとのＣＯＴ共有に関連付けられたルールを決定するために、ＳＬに固有の任意の要因又はルールを使用してもよい。そのような要因は、次のいずれかを含んでもよい（ただし、これらに限定されない）（１）ＣＯＴにおける最後の送信と、当該ＷＴＲＵがＬＢＴを実行することなくＣＯＴにおいて送信してもよい時間との間の最大時間、及び／又は各時間量に対して実行されるＬＢＴのタイプ、あるいは（２）ＷＴＲＵが別のＷＴＲＵ及び／若しくは基地局（例えば、ｇＮＢ）によって開始されたＣＯＴを共有することを許可されるかどうか、又はＷＴＲＵがそれ自体のＣＯＴを開始する（すなわち、完全なＬＢＴを実行する）必要があるかどうか、である。許可は、ＷＴＲＵによって開始されるＣＯＴと、基地局（例えば、ｇＮＢ）によって開始されるＣＯＴとで異なっていてもよい。そのような要因はまた、すでに開始されたＣＯＴを共有するための要因（例えば、ＬＢＴ挙動を決定してもよい上記で説明された任意の要因など）を説明する、本明細書で言及される他のＬＢＴプロパティを含んでもよい。

【0187】

例えば、ＷＴＲＵは、他のＷＴＲＵによって送信されたゾーンＩＤ及びＷＴＲＵ自体のゾーンＩＤに基づいて、ＣＯＴ共有ルールを決定してもよい。ゾーンＩＤは、ＣＯＴを開始するＷＴＲＵと、他のＷＴＲＵによって開始されたＣＯＴを共有するかどうかを決定するＷＴＲＵとの間の距離を表してもよい。ＷＴＲＵは、距離が閾値よりも小さい場合、ＣＯＴを共有できると決定してもよい。

【0188】

ＷＴＲＵは、ＣＯＴを開始した送信のＬ２ ＩＤ（例えば、宛先Ｌ２ ＩＤ）に基づいて、ＣＯＴ共有ルールを決定してもよい。例えば、ＷＴＲＵは、ＣＯＴを開始した送信のＬ２宛先ＩＤが、ＣＯＴを共有するＷＴＲＵによって行われる送信のＬ２宛先ＩＤ（又は関連するＬ２宛先ＩＤのセット中）と同じである場合、別のＷＴＲＵによって開始されたＣＯＴを共有してもよい。更に、ＷＴＲＵは、共有ＣＯＴ内の許可のためのＬＣＰ制限を用いて構成されてもよく、それによって、そのような制限は、そのような許可のために選択することができる許容可能な（場合によっては宛先）Ｌ２ ＩＤに適用してもよい。ＷＴＲＵは、別のＷＴＲＵによって開始されたＣＯＴ内で発生する許可において送信を実行するために、別のＷＴＲＵによって開始されたＣＯＴを共有することが許可されるＬ２宛先ＩＤのみを選択してもよい。

【0189】

ＷＴＲＵは、ＣＯＴを開始した送信に関連付けられたＭＣＲ、及び／又はＷＴＲＵがその送信のＭＣＲ内にあるかどうかに基づいて、ＣＯＴ共有ルールを決定してもよい。例えば、ＣＯＴがＭＣＲを含む送信で開始された場合、及びＷＴＲＵがＭＣＲ内にある場合、ＷＴＲＵは、同じ／関連するＬ２宛先ＩＤを伴う送信のためにＣＯＴを共有してもよい。ＷＴＲＵがＭＣＲの外側にある場合、ＷＴＲＵは、同じ／関連するＬ２ ＩＤを伴う送信のためのＣＯＴを共有しなくてもよい。

【0190】

ＷＴＲＵは、送信のキャストタイプに基づいてＣＯＴ共有ルールを決定してもよい。例えば、ＷＴＲＵは、ユニキャストのための送信間に第１の最大ギャップを適用し、グループキャスト／ブロードキャストのための送信間に第２の最大ギャップを適用することなどをしてもよい。

【0191】

ＷＴＲＵは、ＣＯＴの持続時間内に決定されることができる利用可能なリソースの数に基づいて（例えば、感知に基づいて）、ＣＯＴを共有するかどうかを決定してもよい。具体的には、ＣＯＴの持続時間内及び／又は必要とされるレイテンシ内で利用可能なリソースの数が閾値を上回る場合、ＷＴＲＵは、ＣＯＴを共有することを決定してもよく、そうでない場合、ＷＴＲＵは、新しいＣＯＴを開始することを決定してもよい。

【0192】

ＷＴＲＵは、ＣＯＴの残りの期間及び保留中の送信の優先度／ＰＤＢに基づいて、ＣＯＴを共有するかどうか、又は新しいＣＯＴを開始するかどうかを決定してもよい。具体的には、ＷＴＲＵは、優先度／ＬＣＨとＣＯＴの必要な残りの持続時間との間の関連付けを用いて構成されてもよい。ＣＯＴの残りの持続時間は、送信のＰＤＢ内にあるＣＯＴにおける残りの持続時間内の時間を更に表してもよい。残りの持続時間が、その優先度／ＬＣＨのために必要とされる残りの持続時間を下回る場合、ＷＴＲＵは、ＣＯＴを共有しなくてもよく、新しいＣＯＴを開始してもよい。

【0193】

ＷＴＲＵは、特定のネットワークスケジューリングノード（例えば、基地局（ｇＮＢ）、セルなど）に基づいて、そのＬＢＴ挙動を決定してもよい。

【0194】

第１のＷＴＲＵは、場合によってはＣＯＴ情報の一部として、サイドリンク上でのその送信においてネットワークノードＩＤ（例えば、セルＩＤ、基地局（ｇＮＢ）ＩＤなど）を送信してもよい。ＷＴＲＵは、それがモード１でスケジュールされているとき、ネットワークノードを含んでもよい。代替的に、モード２のＷＴＲＵは、特定のネットワークノードのカバレッジ中及び／又は特定のネットワークノードにＲＲＣ＿ＣＯＮＮＥＣＴＥＤである間にモード２送信を実行するとき、ネットワークノードＩＤを送信してもよい。

【0195】

第２のＷＴＲＵは、次のいずれか又は組み合わせに基づいてそのＬＢＴ挙動を決定してもよい、すなわち、第１のＷＴＲＵの送信から受信したネットワークノード、第２のＷＴＲＵ自体のスケジューリングに関連付けられたネットワークノード（例えば、モード１にある場合、ＷＴＲＵをスケジューリングするセルＩＤ、モード２にある場合、ＷＴＲＵがＲＲＣ＿ＣＯＮＮＥＣＴＥＤであり、ＲＲＣ＿ＩＤＬＥ／ＲＲＣ＿ＩＮＡＣＴＩＶＥにキャンプされているセルＩＤ）、第２のＷＴＲＵが、場合によっては同じノードのカバレッジ内にあるか、又はカバレッジ外にあるか、第２のＷＴＲＵの送信の送信モード（モード１又はモード２）、本明細書に記載されるＬＢＴ挙動に影響を及ぼす他の要因、である

【0196】

モード１のＷＴＲＵは、他のＷＴＲＵもモード１にあり、同じセルＩＤによってスケジュールされている場合、別のＷＴＲＵによって開始されたＣＯＴを共有することを許可されてもよい。モード２のＷＴＲＵは、別のＷＴＲＵからのＣＯＴ情報に含まれるセルＩＤが、当該ＷＴＲＵが接続／キャンプされているセルのセルＩＤと一致する場合、別のＷＴＲＵによって開始されたＣＯＴを共有することを許可されてもよい。例えば、ＷＴＲＵは、ＷＴＲＵ自体のセルＩＤが、ＣＯＴ情報とともに受信されたセルＩＤと一致する場合、パラメータの第１のセットを使用してＬＢＴを実行してもよく、ＷＴＲＵ自体のセルＩＤが、ＣＯＴ情報とともに受信されたセルＩＤと一致しない場合、パラメータの第２のセットを使用してＬＢＴを実行してもよい。

【0197】

ＬＢＴ挙動は、ＷＴＲＵに提供される関連する／関心のあるＬ２ ＩＤのリストに基づいて決定されてもよい。

【0198】

一実施形態では、ＬＢＴ挙動（例えば、ＷＴＲＵがＣＯＴを共有することができるかどうか）は、ＷＴＲＵ自体の宛先Ｌ２ ＩＤと、別のＷＴＲＵ又は基地局（例えば、ｇＮＢ）のいずれかからＷＴＲＵによって受信されたＬ２ ＩＤのリストとの組み合わせに基づいて決定されてもよい。具体的には、ＷＴＲＵは、ＬＢＴに関連付けられた送信のＬ２ ＩＤが、受信されたリストに含まれる任意のＬ２ ＩＤと一致するかどうかに基づいて、そのＬＢＴ挙動を決定してもよい。ＷＴＲＵによって受信されたＬ２ ＩＤのリストは、別のＷＴＲＵに関連付けられた関心のあるＬ２ ＩＤを表してもよく、場合によっては、そのようなＷＴＲＵがＣＯＴを開始していてもよい。これは、サイドリンクシステムが、ＣＯＴを開始したＷＴＲＵがＣＯＴを共有している送信の意図された受信者であるべき送信にＣＯＴ共有を制限することを可能にするためである。

【0199】

一実施形態では、第１のＷＴＲＵは、その関心のあるＬ２ ＩＤ（例えば、任意の関心のあるグループキャスト／ブロードキャストサービスのＬ２ ＩＤ、及び／又は任意の進行中のユニキャストリンクのソース／宛先ＩＤペア）を１つ以上の他のＷＴＲＵに送信してもよい。例えば、第１のＷＴＲＵは、場合によっては第２のＷＴＲＵとのユニキャストリンク確立に関連付けられたそのような情報を、ＰＣ５－ＲＲＣシグナリングで送信してもよい。例えば、第１のＷＴＲＵは、そのような情報の任意の変更（すなわち、上位層による関心のある宛先Ｌ２ ＩＤシグナリングの変更、ＷＴＲＵがそれ自体を関連付けたユニキャストリンクの追加／除去など）の際に、更新された情報を送信してもよい。代替的に、第１のＷＴＲＵは、ＣＯＴ自体において送信とともにリストを送信してもよい。例えば、第１のＷＴＲＵは、そのＳＬ送信に含まれるＭＡＣ ＣＥにおいてリストを送信してもよい。

【0200】

第２のＷＴＲＵは、第１のＷＴＲＵからＬ２ ＩＤのリストを受信してもよく、第１のＷＴＲＵによって開始されたＣＯＴを共有するかどうかを決定するためにその情報を使用してもよい。例えば、第２のＷＴＲＵは、第１のＷＴＲＵからのＬ２ ＩＤのリストを、第１のＷＴＲＵとのユニキャストリンクのソース／宛先Ｌ２ ＩＤに関連付けてもよい。第１のＷＴＲＵは、それが第１のＷＴＲＵによって開始されたＣＯＴを共有することができるかどうかを決定するとき、第２のＷＴＲＵの送信の宛先Ｌ２ ＩＤが、第１のＷＴＲＵから受信されたリスト中の任意のＬ２ ＩＤと一致するかどうかを決定してもよい。送信のソース／宛先Ｌ２ ＩＤが、受信されたリスト中のソース／宛先Ｌ２ ＩＤのうちの１つである場合、第２のＷＴＲＵは、第１のＷＴＲＵとＣＯＴを共有することができ、そうでない場合、第２のＷＴＲＵは、第１のＷＴＲＵとＣＯＴを共有しなくてもよい。

【0201】

別の実施形態では、第２のＷＴＲＵは、基地局（例えば、ｇＮＢ）からリスト／関係を受信してもよい。例えば、第２のＷＴＲＵは、ユニキャストでピアＷＴＲＵを表す各ソース／宛先Ｌ２ ＩＤに関連付けられた関心のあるＬ２ ＩＤのリストを受信してもよい。第２のＷＴＲＵは、基地局（例えば、ｇＮＢ）からリストとともに提供されるソース／宛先Ｌ２ ＩＤに基づいて、第１のＷＴＲＵの送信にリストを適用することを決定してもよい。別の例では、第２のＷＴＲＵは、基地局（例えば、ｇＮＢ）から関連するＬ２宛先ＩＤのリストを受信してもよい。関連する宛先Ｌ２ ＩＤのそのようなリストは、ＣＯＴを共有してもよいグループキャスト送信を表してもよい。例えば、第１のＷＴＲＵ送信のＬ２宛先ＩＤ、及び第２のＷＴＲＵの送信の宛先Ｌ２ ＩＤが同じリスト中で発生する場合、第２のＷＴＲＵは、ＣＯＴを第１のＷＴＲＵと共有してもよい。

【0202】

リストの使用及びＣＯＴを共有するかどうかをどのように決定するかは、第１のＷＴＲＵからの送信のキャストタイプ及び／又は第２のＷＴＲＵからの送信のキャストタイプに依存してもよい。例えば、第２のＷＴＲＵは、第１のＷＴＲＵによって開始されたＣＯＴを共有するかどうかに関する以下の決定のいずれか又は組み合わせを使用してもよい。これらの決定はまた、リストの使用を仮定しない一実施形態にも、より一般的に適用してもよい。

【0203】

１つの決定において、第１のＷＴＲＵ送信が第２のＷＴＲＵへのユニキャストである場合、第２のＷＴＲＵは、第２のＷＴＲＵが同じユニキャストリンクへのユニキャスト送信を実行している限り、ＣＯＴを共有してもよい。

【0204】

別の決定において、第１のＷＴＲＵ送信が第２のＷＴＲＵへのユニキャストである場合、第２のＷＴＲＵは、第１のＷＴＲＵから／のために受信されたリスト中の宛先／ソースＬ２ ＩＤに一致するソース／宛先Ｌ２ ＩＤのペアに関連付けられたユニキャスト送信を第２のＷＴＲＵが実行している限り、ＣＯＴを共有してもよい。

【0205】

別の決定において、第１のＷＴＲＵ送信がグループキャスト／ブロードキャストである場合、第２のＷＴＲＵは、第１のＷＴＲＵから受信されたリスト中の宛先Ｌ２ ＩＤに一致する宛先Ｌ２ ＩＤに関連付けられたグループキャスト／ブロードキャスト送信を第２のＷＴＲＵが実行している限り、ＣＯＴを共有してもよい。代替的に、第１のＷＴＲＵ送信がグループキャスト／ブロードキャストである場合、第２のＷＴＲＵは、第２のＷＴＲＵが第１のＷＴＲＵの送信と同じ宛先Ｌ２ ＩＤへのグループキャスト／ブロードキャスト送信を実行している限り、ＣＯＴを共有してもよい。更に、第２のＷＴＲＵは、第２のＷＴＲＵが第１のＷＴＲＵに関連付けられたリストを有しない場合にのみ、この最新の条件を使用してもよい。

【0206】

上記で説明した実施形態は、本明細書で説明するように、第２のＷＴＲＵのためのチャネルにアクセスするためのＬＢＴに関連付けられた任意の挙動に一般化されてもよい。具体的には、第２のＷＴＲＵは、リストを使用して、第１のタイプ又は第２のタイプのＬＢＴを実行するかどうかを決定してもよい。例えば、第２のＷＴＲＵは、リストを使用して、第１のＣＷ又は第２のＣＷを使用するかどうかを決定してもよい。

【0207】

ＷＴＲＵは、異なる要因が満たされることに関連付けられた複数の条件、又は異なる要因が満たされることに関連付けられた少なくとも１つの条件に基づいて、ＣＯＴを共有するかどうかを決定してもよい。例えば、ＷＴＲＵは、以前の送信とＷＴＲＵの計画された送信との間の時間が閾値より小さく、ＷＴＲＵの送信のＬ２宛先が、ＣＯＴを開始した送信のＬ２ ＩＤと一致する場合、ＣＯＴを共有してもよい。ＷＴＲＵは、その送信のＬ２宛先ＩＤが、ＣＯＴを開始した送信のＬ２宛先ＩＤと一致する場合、又はＷＴＲＵが、ＣＯＴを開始した送信からある距離未満である場合、ＣＯＴを共有してもよい。

【0208】

ＷＴＲＵは、別の条件／要因が満たされる／テストされるかどうかに基づいて、ＣＯＴを共有するかどうかを決定するために、異なる条件／要因を使用してもよい。例えば、以前の送信とＷＴＲＵ自体の送信との間の時間が第１の範囲内にある場合、ＷＴＲＵは、Ｌ２ ＩＤが一致している限りＣＯＴを共有してもよく、以前の送信とＷＴＲＵ自体の送信との間の時間が第２の範囲内にある場合、ＷＴＲＵは、ＷＴＲＵ間の距離が閾値未満である限りＣＯＴを共有してもよい。

【0209】

図２は、ユニキャストＣＯＴ共有の一例を示す図である。図２に示されるように、第１のＷＴＲＵ２０２の送信と同じユニキャストリンクに関連付けられた送信のためにＣＯＴが第２のＷＴＲＵ２０４によって開始される場合、第１のＷＴＲＵ２０２は、ＣＯＴを共有してもよい。第１のＷＴＲＵ２０２は、リンクを開始したＳＣＩに含まれるＬ２ソース／宛先ＩＤに基づいて、この決定を行ってもよい。具体的には、第１のＷＴＲＵ２０２の送信のＬ２ソースＩＤが第２のＷＴＲＵ２０４のＬ２宛先ＩＤと同じであり、第１のＷＴＲＵ２０２の送信のＬ２宛先ＩＤが第２のＷＴＲＵ２０４のＬ２ソースＩＤと同じである場合、第１のＷＴＲＵ２０２は、ＣＯＴを共有してもよい。そうでない場合、第１のＷＴＲＵ２０２はＣＯＴを共有しなくてもよい。

【0210】

代替的に、第１のＷＴＲＵ２０２がユニキャストリンクを有する第２のＷＴＲＵ２０４によってＣＯＴが開始される場合、第１のＷＴＲＵ２０２は、第１のＷＴＲＵ２０２の送信の宛先にかかわらず、ＣＯＴを共有してもよい。具体的には、ＣＯＴが、第１のＷＴＲＵ２０２においてアクティブであるユニキャストリンクに対応するソース／宛先Ｌ２ ＩＤペアを伴う送信によって開始される場合、第１のＷＴＲＵ２０２は、任意の送信のためにＣＯＴを共有してもよい。

【0211】

代替では、上記で説明した条件のいずれかを使用して、ＣＯＴを共有するかどうかを決定してもよいが、問題の第２のＷＴＲＵ２０４からの送信は、ＣＯＴ内で行われる送信であってもよく、必ずしもＣＯＴを開始する送信でなくてもよい。具体的には、上記で説明したように、ＷＴＲＵは、同じユニキャストリンクに関連付けられた他のＷＴＲＵが、共有されるべき同じＣＯＴ内で送信を実行した場合、ユニキャストリンクに関連付けられた送信のためにＣＯＴを共有してもよい。

【0212】

ＷＴＲＵが上記の代替案のいずれかを実行することを許可されるかどうか（１つの代替案対別の代替案）は、本明細書の他のＳＬ要因（例えば、送信の優先度）に更に依存してもよい。例えば、図２に示されるように、第２のＷＴＲＵ２０４は、ＷＴＲＵ２０２及びＷＴＲＵ２０４がユニキャストリンクを共有するので、第１のＷＴＲＵ２０２によって開始されたＣＯＴで送信してもよい。しかしながら、ＷＴＲＵ２０２及びＷＴＲＵ２０６はユニキャストリンクを共有しないので、第３のＷＴＲＵ２０６は、第１のＷＴＲＵ２０２によって開始されたＣＯＴで送信することができない。

【0213】

ＣＯＴは、特定のタイプに関連付けられるか、又は特定のタイプであるように識別されてもよく、そのようなタイプは、１つ以上のサイドリンク要因によって決定されてもよい。例えば、ＣＯＴは、それがモード１送信によって開始されたか、モード２送信によって開始されたかに依存して、モード１ ＣＯＴ又はモード２ ＣＯＴであってもよい。代替的に、ＣＯＴは、モードに依存しなくてもよい（又は、いずれのモードにも固有でなくてもよい）。例えば、ＣＯＴは、ユニキャストＣＯＴ、グループキャストＣＯＴ、又はブロードキャストＣＯＴであってもよい。代替的に、ＣＯＴは、キャストタイプに依存しなくてもよい。例えば、ＣＯＴは、感知ベースのＣＯＴ、ランダム選択ＣＯＴなどであってもよく。ＣＯＴは、ＨＡＲＱフィードバックベースのＣＯＴ又は非ＨＡＲＱフィードバックベースのＣＯＴであってもよい。

【0214】

特定のタイプのＣＯＴを開始するＷＴＲＵは、その送信内でＣＯＴタイプを示してもよい。そのようなＣＯＴタイプ指示は、例えば、ＳＣＩ、専用ＰＨＹチャネル、ＭＡＣ ＣＥ、ＣＧ－ＵＣＩ、ＳＬ ＲＲＣメッセージなどにおいて搬送されてもよい。代替的に、ＣＯＴタイプは、送信を開始するＷＴＲＵ、又はＣＯＴ内で送信する他のＷＴＲＵによるサイドリンク送信に含まれる他の情報に基づいて暗黙的に決定されてもよい。

【0215】

特定のタイプのＣＯＴを開始するＷＴＲＵは、そのようなＣＯＴ（例えば、ＣＷサイズ、最大許容可能ＣＯＴ長など）を開始するときに使用される（本明細書で定義されるような）ＬＢＴ挙動を用いて構成されてもよい。

【0216】

ＷＴＲＵは、ＣＯＴタイプ、及びＣＯＴ内で実行されるべきそれ自体の送信に関連付けられた可能性があるサイドリンク要因のいずれかに基づいて、（本明細書で定義されるような）そのＣＯＴ共有ルールを決定してもよい。ＷＴＲＵは、ユニキャスト送信のために特定のタイプのＣＯＴを共有することを許可されてもよいが、ブロードキャスト送信のためには許可されない。ＷＴＲＵは、モード１送信のために特定のタイプのＣＯＴを共有することを許可されてもよいが、モード２送信のためには許可されない。ＷＴＲＵは、ＨＡＲＱフィードバック有効化／無効化された送信のみのために特定のタイプのＣＯＴを共有することを許可されてもよい。ＷＴＲＵは、ＣＯＴタイプが、ＷＴＲＵによって送信されているデータのタイプと一致する場合、ＣＯＴを共有することを許可されてもよい。ＷＴＲＵは、送信がＣＯＴタイプに関連付けられているかどうかに応じて、異なるＣＯＴ共有ルール、又は異なるＬＢＴパラメータを用いて構成されてもよい。ＷＴＲＵは、ＰＳＦＣＨ送信のみのために特定のタイプのＣＯＴを共有することを許可されてもよい。ＷＴＲＵは、送信が特定の優先度に関連付けられるか、又は閾値よりも大きい／小さい優先度を有する場合、特定のタイプのＣＯＴを共有することを許可されてもよい。ＷＴＲＵは、ＬＣＨがＣＯＴタイプに関連付けられた許可を使用するかどうかを可能にするために、ＬＣＰ制限を用いて構成されてもよい。ＣＯＴは、「ユニバーサル」ＣＯＴ（すなわち、全ての他のＷＴＲＵ／送信によって使用可能）又は特定のタイプのＣＯＴ（単一のＷＴＲＵ又はＷＴＲＵペア又はＷＴＲＵ基地局ペア又は特定のタイプの送信によってのみ使用可能）と見なされてもよい。

【0217】

ＷＴＲＵは、以下のうちの１つ又は組み合わせに基づいて、特定のタイプのＣＯＴを開始するかどうかを決定してもよい、すなわち、（１）本明細書で言及され、送信されるべきデータに関連付けられたサイドリンク固有要因（例えば、キャスト、ＨＡＲＱイネーブル、モードなど）、（２）測定されたＣＢＲ、（３）場合によってはＷｉＦｉに関連付けられた、測定されたチャネル占有（これは、ＬＢＴ統計、ＲＳＳＩ測定、チャネル占有又は干渉レベルなどに基づいて決定されてもよい）、及び／又は（４）エリア中のＷＴＲＵの数に関連付けられた、場合によっては上位層からの、又はリソースを共有しようと試みる可能性のある指示、である。例えば、上記の要因の１つ又は組み合わせに基づいて、ＷＴＲＵは、ユニバーサルＣＯＴ、又は特定のタイプのＣＯＴを開始することを決定してもよい。

【0218】

一実施形態では、ＷＴＲＵは、ＣＯＴを開始した特定のＷＴＲＵをＷＴＲＵが聞くことができるかどうか、及び／又はＣＯＴを開始するそのようなＷＴＲＵへの間接のレベルに基づいて、ＣＯＴ共有ルール（例えば、ＣＯＴを共有してもよいか、ＣＯＴを共有してもよい送信後の最大時間、及び／又は特定のタイプのＬＢＴを適用することができる最大時間）を決定してもよい。例えば、ＣＯＴを開始したＷＴＲＵは、その送信を実行する前にタイプ１ ＬＢＴ（又は完全なＬＢＴ）を実行したＷＴＲＵであってもよい。

【0219】

例えば、ＣＯＴを開始するＴＸ ＷＴＲＵは、それがＣＯＴを開始したＷＴＲＵであるという指示（例えば、０の値）を（例えば、ＳＣＩにおいて）送信してもよい。ＣＯＴを共有するＴＸ ＷＴＲＵは、ＣＯＴを開始したＷＴＲＵに関連付けられた間接レベルに関連付けられた指示を（例えば、ＳＣＩにおいて）送信してもよい。具体的には、第１のＷＴＲＵが、第２のＷＴＲＵによって開始されたＣＯＴを共有する場合、第１のＷＴＲＵは、第１のレベルの間接性（例えば、１の値）を表す指示を送信してもよい。別のＷＴＲＵによって開始されたＣＯＴを共有するＷＴＲＵは、例えば、そのＣＯＴに関連付けられた任意のＳＣＩにおいて受信された最小値から１だけ、ＳＣＩにおいて送信する間接レベルを常にインクリメントしてもよい。以下同様である。別のＷＴＲＵによって開始されたＣＯＴを共有することを望むＷＴＲＵは、（場合によっては最後の送信からの時間、及び／又はキャストタイプ若しくはモードなどの本明細書における他の要因に加えて）そのような指示を使用して、ＣＯＴを共有してもよいかどうか、及び／又はＣＯＴを共有するためにどのタイプのＬＢＴを実行するかを決定してもよい。

【0220】

例えば、ＷＴＲＵは、他のＷＴＲＵがＣＯＴを開始したと決定した場合、別のＷＴＲＵによって開始されたＣＯＴを共有してもよい。ＷＴＲＵは、ＣＯＴ内の送信（場合によっては最後の送信、又は任意の送信）から受信された間接のレベルが閾値未満であると決定した場合、別のＷＴＲＵによって開始されたＣＯＴを共有してもよい。そのような閾値は、本明細書で言及される任意のサイドリンク固有の要因（例えば、優先度）に更に依存してもよい。

【0221】

例えば、ＷＴＲＵは、間接レベルと送信間の時間ギャップとの組み合わせに基づいて、ピアＷＴＲＵとＣＯＴを共有するために実行するＬＢＴのタイプを決定してもよい。具体的には、ＣＯＴにおける最後の送信からの特定の時間ギャップの間、ＷＴＲＵは、第１の間接レベルに対して第１のＬＢＴタイプを使用し、第２の間接レベルに対して第２のＬＢＴタイプを使用してもよい、などである。

【0222】

図３は、グループキャスト／ブロードキャストＣＯＴ共有の一例を示す図である。図３に示されるように、ＷＴＲＵ３０２は、ＬＢＴパラメータの第１のセット（すなわち、ＬＢＴ（０））を使用して、ＣＯＴを開始してもよい。ＷＴＲＵ３０２は、ＣＯＴを開始したので、ＣＯＴ内のＳＣＩ送信３２０において０の間接値を送信してもよい。

【0223】

ＷＴＲＵ３０４は、ＷＴＲＵ３０２からＣＯＴ情報を受信し、ＣＯＴをＷＴＲＵ３０６と共有することを決定してもよい。ＷＴＲＵ３０４は、１の間接レベルを表すので、ＬＢＴパラメータの第２のセット（すなわち、ＬＢＴ（１））を使用してＬＢＴ手順を実行してもよい。ＷＴＲＵ３０４はまた、ＳＣＩ送信３２２において１の間接値を送信してもよい。

【0224】

ＷＴＲＵ３０６の挙動は、ＷＴＲＵ３０４の挙動と同様である。ＷＴＲＵ３０６は、ＷＴＲＵ０４からＣＯＴ情報を受信し、ＣＯＴをＷＴＲＵ３０８と共有することを決定してもよい。ＷＴＲＵ３０６は、２の間接レベルを表すので、ＬＢＴパラメータの第３のセット（すなわち、ＬＢＴ（２））を使用してＬＢＴ手順を実行してもよい。ＷＴＲＵ３０６はまた、ＳＣＩ送信３２４において２の間接値を送信してもよい。

【0225】

ＷＴＲＵ３０８は、ＷＴＲＵ３０２及びＷＴＲＵ３０６の両方から同じＣＯＴについてのＣＯＴ情報を検出するが、競合する間接番号を伴う。ＷＴＲＵ３０８は、ＳＣＩ送信２２４を介してＷＴＲＵ３０６から２の間接値を受信し、ＳＣＩ送信３２６を介してＷＴＲＵ３０２から０の間接値を受信する。ＷＴＲＵは、ＷＴＲＵ３０２から０の最小間接番号に従うことを決定し、第１の間接レベル内のＷＴＲＵとして振る舞ってもよい。更に、ＷＴＲＵ３０８は、任意のＳＣＩ送信３２８において１の間接値を追加のＷＴＲＵに送信してもよい。

【0226】

分散ＣＯＴ共有に伴って生じる可能性のある潜在的な問題は、隠れノード問題によって引き起こされる。具体的には、第１のＷＴＲＵは、ＣＯＴを開始し、ＣＯＴ情報を送信してもよい。（隠れノード問題のために）第１のＷＴＲＵからＣＯＴ情報を受信しない第２のＷＴＲＵも、それ自体のＣＯＴを開始してもよい。第２のＷＴＲＵは、ＣＯＴウェルを第１のＷＴＲＵのＣＯＴへと開始してもよい。これは、サイドリンクＷＴＲＵが公平性要件よりも長くチャネルを占有することになる可能性がある。

【0227】

一実施形態では、ＷＴＲＵは、別のＷＴＲＵからの競合するＣＯＴ構造の受信に続いて、その仮定されたＣＯＴ構造を修正してもよい。競合するＣＯＴ構造は、ＣＯＴに関連付けられた異なる仮定されたＬＢＴ挙動（例えば、異なるＣＡＰＣ、異なる必要とされるＬＢＴタイプなど）を包含してもよい。例えば、受信されたＣＡＰＣが仮定されたＣＡＰＣよりも低い／高い場合、ＷＴＲＵは、これを競合と見なしてもよい。競合するＣＯＴ構造はまた、異なるＣＯＴ長を包含してもよい。例えば、より短いＣＯＴ長（又は、別のＷＴＲＵによって示され、当該ＷＴＲＵによって仮定されたＣＯＴよりも早く終了するＣＯＴ）は、競合と見なされてもよい。

【0228】

ＷＴＲＵは、競合の場合に他のＷＴＲＵから受信されたＣＯＴ情報を採用してもよい。ＷＴＲＵは更に、競合の場合に、新しい情報に従うために、送信するＣＯＴ情報を修正してもよい。ＷＴＲＵは、競合するＣＯＴ構造情報を受信したとき、場合によっては受信されたＣＯＴ構造が送信を許可しない場合、計画された送信をキャンセルしてもよい。ＷＴＲＵは、競合するＣＯＴ構造の受信時にネットワークに通知してもよい。

【0229】

別の実施形態では、未認可スペクトル上のＳＬ送信を用いてモード１で構成されたＳＬ ＷＴＲＵは、基地局からＳＬ許可を受信し、他のＷＴＲＵのＳＣＩ送信から受信されたＣＯＴ構造情報に基づいて、ＳＬ許可が別のＷＴＲＵによって開始されたＣＯＴ内に入るかどうかを決定してもよい。ＳＬ許可が、別のＷＴＲＵによって開始されるＣＯＴ内に入る場合、ＷＴＲＵは、第１のＬＢＴタイプを実行して、ＣＯＴを共有しようと試みてもよい。ＳＬ許可が別のＷＴＲＵによって開始されるＣＯＴ内に含まれない場合、ＷＴＲＵは、第２のＬＢＴタイプを実行して、それ自体のＣＯＴを開始しようと試みてもよい。ＬＢＴが許可に対して失敗した場合、ＷＴＲＵは、失敗したＬＢＴをＵＣＩにおいて基地局に報告してもよい。

【0230】

ＬＢＴが成功した場合、ＷＴＲＵは、ＣＯＴ長を決定し、（どの方法が使用されたかに応じて）ＵＣＩにおける残りのＣＯＴ長を基地局（例えば、ｇＮＢ）に報告し、第１のＷＴＲＵがそれ自体のＣＯＴを開始したか、又は別のＷＴＲＵのＣＯＴを共有しているかを基地局（例えば、ｇＮＢ）に報告してもよい。ＷＴＲＵによって開始されるＣＯＴの場合、ＷＴＲＵは、ＳＬ許可において多重化されたデータに基づいてＣＯＴ長を決定してもよい。共有ＣＯＴの場合、ＷＴＲＵは、別のＷＴＲＵのＳＣＩにおいて受信されたＣＯＴ長からＣＯＴ長を決定してもよい。

【0231】

モード１で構成されたＳＬ ＷＴＲＵは、ＣＯＴの開始又は共有の成功／失敗、及びＣＯＴに残っている時間（ＣＯＴが共有されるか開始されるかに依存して異なって決定される）を基地局に報告してもよい。ＳＬ ＷＴＲＵは、送信の優先度と別のＷＴＲＵから受信された間接番号との組み合わせに基づいて、別のＷＴＲＵによって開始されたＣＯＴを共有することができるかどうかを決定してもよい。

【0232】

一実施形態では、ＳＬ ＷＴＲＵは、別のＷＴＲＵによって開始されたＣＯＴと、そのＣＯＴに関連付けられた間接番号を含むＣＯＴ情報を１つ以上の他のＷＴＲＵから受信することによってそのＣＯＴで送信するために使用するＬＢＴパラメータとを共有できるかどうかを決定し、そのＣＯＴに関連付けられたＷＴＲＵによって受信された最小間接番号が、送信されるデータの優先度に基づいて構成された閾値未満である場合、ＣＯＴを共有できると決定し、間接番号及び優先度によって決定されるパラメータを使用してＬＢＴを実行してもよい。ＷＴＲＵは、チャネルを取得する場合、受信された間接番号よりも１大きい間接番号を送信してもよい。そうでない場合、ＷＴＲＵは、他のＷＴＲＵによって開始されたＣＯＴを共有することができないと決定してもよく、それ自体のＣＯＴを開始してもよい。

【0233】

別の実施形態では、モード２で動作するＷＴＲＵは、ＳＬ上の既存の又は予想されるＣＯＴの存在及び／又は構造に基づいてリソース選択を実行してもよい。ＣＯＴは、他のＷＴＲＵによって開始される（及びそれらのＷＴＲＵによってＳＣＩにおいて示される）ＣＯＴ、又はリソース選択を実行する当該ＷＴＲＵによって開始されるＣＯＴを含んでもよい。本明細書では、既存のＣＯＴは、場合によっては完全なＬＢＴ手順に続いて、ＳＣＩの送信を通じてＷＴＲＵ又は別のＷＴＲＵによって開始されたＣＯＴである。予想されるＣＯＴは、ＳＣＩにおいて告知されるＷＴＲＵによる将来の送信の結果としてＣＯＴの一部であると予想される可能性のあるリソース又はリソースのセットを含んでもよい。ＣＯＴの存在に依存する本明細書におけるリソース選択のための方法は、既存のＣＯＴ又は予想されるＣＯＴのいずれかに、場合によっては同じ／異なるルールで適用されてもよい。

【0234】

モード２リソース選択を実行するＷＴＲＵは、リソース選択をＣＯＴ内のリソースに制限又は優先順位付けすることを含む、ＣＯＴ内のリソース又はＣＯＴに関連するリソースを選択することによって、既存の又は予想されるＣＯＴの存在及び／又は構造を考慮してもよい。リソース選択のコンテキストでは、ＣＯＴ内のリソースに優先順位付けすることは、次を含んでもよいが、これに限定されない、すなわち、（１）ＣＯＴ外のリソースを選択することよりも高い優先度を伴うＣＯＴ内のリソースを選択すること、（２）ＣＯＴ外よりもＣＯＴ内でより多くのリソースを選択すること、（３）ＣＯＴ外のリソースを選択するよりも多い回数ＣＯＴ内のリソースを選択すること、（４）リソース上の送信持続時間がＣＯＴにおける残りの時間内に収まる場合、ＣＯＴ内のリソースを選択すること、（５）送信リソースフィットの開始時間がＣＯＴの終わりから所定の閾値以下である場合、ＣＯＴ内のリソースを選択すること、（６）利用可能なリソースの数のより大きいパーセンテージがＣＯＴの外側よりもＣＯＴの内側に存在するように、リソース選択のために利用可能なリソースを（ＭＡＣ層に）提供すること、及び（７）ＣＯＴの内側の利用可能なリソースの量又は比率が（ＣＯＴの内側のリソース選択の優先順位付けが実行されない場合と比較して）より大きくなるように、リソース選択のために利用可能なリソースを（ＭＡＣ層に）提供することである。リソースの選択は、選択されたリソースの開始がＣＯＴ内にあることを確実にすることを含んでもよい。リソースの選択はまた、リソースの開始が当該ＣＯＴの開始に続く最大時間に生じることを確実にし、したがって、少なくとも初期送信リソースがＣＯＴ内にあることを確実にすることを含んでもよい。

【0235】

モード２リソース選択を実行するＷＴＲＵは、特定のタイプのＣＯＴに関連付けられたリソースを選択することによって、既存の又は予想されるＣＯＴの存在及び／又は構造を考慮してもよい。ＣＯＴのタイプは、本明細書で説明される１つ以上の要因に関連付けられたＣＯＴであってもよい（例えば、間接番号が基準を満たす、キャストタイプが特定の基準に関連付けられる、Ｌ２ ＩＤが基準を満たす、など）。ＣＯＴのタイプは、選択された（ＷＴＲＵによって開始された場合）又は指示された（別のＷＴＲＵによって開始された場合）ＣＯＴであってもよいＣＡＰＣは、特定の値であるか、又は閾値を下回る／上回る。リソースは、ＦＢＥリソース又はＬＢＥリソースに関連付けられてもよい。ＣＯＴのタイプは、別のＷＴＲＵによって開始されるＣＯＴ（すなわち、共有ＣＯＴ）又はＷＴＲＵ自体によって開始されるＣＯＴ（例えば、要求されるＬＢＴタイプ－タイプ１、２、若しくは４に関連する－又は輻輳期間若しくはバックオフなどの関連するＬＢＴ構成パラメータに関連する）であってもよい

【0236】

モード２リソース選択を実行するＷＴＲＵは、ＣＯＴの存在及び／又は構造に応じてリソース選択に関連付けられたパラメータを決定することによってリソースを選択することによって、既存の又は予想されるＣＯＴの存在及び／又は構造を考慮してもよい。決定は、選択がＣＯＴ又はＣＯＴタイプ内で実行されるときにパラメータの第１のセットを使用すること、及び選択がＣＯＴ外又は別のＣＯＴタイプ中で実行されるときにパラメータの第２のセットを使用することを含んでもよい。リソース上で行われた最後の送信と、同じリソースを使用するＷＴＲＵによって意図された次のＳＬ送信の開始との間の時間ギャップ。ＳＬデータリソース上の送信持続時間、及びそれがＣＯＴ中の残りの時間内に収まるかどうか。決定は、ＣＯＴの開始／終了に対するリソースのタイミングに依存して、リソース選択のパラメータを適応させることを含んでもよい。

【0237】

ＷＴＲＵは、リソース選択に関連付けられたパラメータを決定してもよく、これは、以下のうちのいずれかを含むことができる（が、これらに限定されない）、すなわち、再送信リソースの数、ＷＴＲＵが選択すべき連続リソースの数、送信／再送信間の最小／最大時間、選択される時間／周波数連続リソースの数などのリソースのパターン、ＲＢの最大／最小数、所与の送信／再送信リソースの持続時間、場合によってはＣＯＴ／ＣＯＴタイプに関連付けられた、選択されることができるリソースの総数、周期的リソース選択、又はワンショットリソース選択が実行／許可されるである。

【0238】

ＷＴＲＵは、１つ以上の条件に基づいてＣＯＴを考慮することによってリソースを選択してもよい。例えば、ＷＴＲＵは、条件が満たされる場合にＣＯＴを考慮することによってリソースを選択するかどうかを決定してもよく（そうでない場合にはそのようにしなくてもよい）。ＷＴＲＵは、条件が満たされる場合、ＣＯＴを考慮するときに特定の挙動を決定してもよく、条件が満たされない場合、ＣＯＴを考慮するときに別の挙動を使用してもよい。例えば、ＷＴＲＵは、第１の条件が満たされるときにＣＯＴを考慮してリソースを選択するときにパラメータの第１のセットを使用してもよく、そうでない場合にはパラメータの異なるセットを使用してもよい。例えば、ＷＴＲＵは、第１の条件下で第１のタイプのＣＯＴに関連付けられたリソースを選択する一方で、第２の条件下で第２のタイプのＣＯＴに関連付けられたリソースを選択してもよい。

【0239】

条件は、送信に利用可能なデータのタイプ（例えば、ＱｏＳ、ＬＣＨ、ＭＡＣ ＣＥ対データ、ＳＲＢ対ＤＲＢなど）に関連してもよい。条件は、特定の優先度を有する送信に利用可能なデータの存在であってもよい。条件は、利用可能なデータがＭＡＣ ＣＥのみからなるかどうか、又は利用可能なデータがＭＡＣ ＣＥ及びデータ又はデータのみを含むかどうかであってもよい。例えば、条件は、利用可能なデータがＳＲＢビットのみからなるかどうか、又は利用可能なデータがＳＲＢデータを含むかどうかであってもよい。条件は、場合によっては特定の優先度を有する、送信に利用可能な制御情報の存在であってもよい。制御情報は、データリソース上で多重化されたＳＣＩ又は制御リソース上で送信されるＳＣＩであってもよい。

【0240】

条件は、データに関連付けられた構成された条件に関連してもよい。例えば、１つ以上のＬＣＨは、ＣＯＴに関連付けられたリソース選択に関して本明細書で説明される特定の挙動を有するように構成されてもよい。ＬＣＨは、ＬＢＥ／ＦＢＥリソースからのリソース選択をトリガしてもよい。例えば、構成された条件に関連付けられた特定のＬＣＨに対してデータが利用可能である場合、ＷＴＲＵは、ＣＯＴ情報／構造を考慮することによってリソースを選択してもよい。そうでない場合、ＷＴＲＵは、リソース選択中にＣＯＴ構造を考慮しなくてもよい。例えば、条件は、ＬＣＨがＨＡＲＱ有効化又はＨＡＲＱ無効化で構成されているかどうかであってもよい。条件は、ＬＣＨがＭＣＲで構成されているかどうか、及び／又はＭＣＲの値に関する条件であってもよい。

【0241】

条件は、ＣＢＲ、ＳＬ ＲＳＲＰ、ＳＬ ＣＳＩなど、ＳＬの測定値に関連してもよい。例えば、条件は、ユニキャストリンクに関連付けられたＳＬ ＣＢＲ又はＳＬ ＲＳＲＰが閾値を上回る／下回ることであってもよい

【0242】

条件は、送信のために利用可能なデータのキャストタイプに関連してもよい。例えば、条件は、リソース選択をトリガする送信のために利用可能なデータが特定のキャストタイプに関連付けられることであってもよい

【0243】

条件は、リソース選択を実行するＷＴＲＵによって開始されるＣＯＴの存在に関連してもよい。例えば、条件は、ＷＴＲＵが、リソース選択時に開始したアクティブなＣＯＴを有することであってもよい。

【0244】

条件は、ＣＯＴ内に入る利用可能なリソースの存在、比率、量に関連してもよい。例えば、条件は、ＣＯＴ内に入る利用可能なリソースのパーセンテージが閾値を上回ることであってもよい

【0245】

条件は、ＷＴＲＵによって現在開始されているＣＯＴの数に関連してもよい。

【0246】

条件は、ＴＢが再送信であるかどうかに関連してもよい。例えば、ＷＴＲＵは、ＴＢが再送信である場合（場合によっては、いくつかの再送信又はＬＢＴ失敗の後）、あるリソースを選択してもよい。再送信は、前のＬＢＴ失敗に起因するか、ＮＡＣＫを受信／決定することに起因するか、又はすでに送信されたＴＢのためのＨＡＲＱフィードバックを受信しないことに起因してもよい。一例において、ＷＴＲＵは、ＮＡＣＫを受信した場合、ＬＢＴが失敗した場合、及び／又はＨＡＲＱフィードバックを受信していない場合、異なるリソース又はリソースプールを使用してＴＢを再送信してもよい。ＷＴＲＵは、ＨＡＲＱフィードバックがＴＢ送信に続く予想時間に受信されなかった場合、異なるリソース又はリソースプール上でＨＡＲＱフィードバックを監視してもよい。

【0247】

条件は、第１のタイプのＣＯＴに関連付けられたリソース上で一貫したＬＢＴ失敗が検出されるかどうかに関連してもよい。

【0248】

条件は、最近の時間の期間にわたってＷＴＲＵによって開始されたＣＯＴの数に関連してもよい。例えば、条件は、ＷＴＲＵが、（事前に）構成された過去の時間の期間にわたって少なくともＮ個のＣＯＴを開始したことであってもよい

【0249】

一実施形態では、ＷＴＲＵは、リソース（例えば、タイムスロット、タイムスロットのセット、サブチャネル、サブチャネルのセットなど）を、ＣＯＴに関連付けられた１つ以上のプロパティに関連付けてもよい。

【0250】

一実施形態では、リソースは、ＣＯＴの内部にある、又はＣＯＴの外部にある、又はＣＯＴと部分的に重複する（すなわち、リソースの一部がＣＯＴの内部にあり、リソースの一部がＣＯＴの外部にある）と考えられてもよい。例えば、リソースがＣＯＴ中の残り時間内に終了する場合、リソースはＣＯＴの内部にあってもよい。別の実施形態では、リソースは、本明細書で説明されるように、所与の間接番号又はその範囲のＣＯＴ中にあると見なされてもよい。又は

【0251】

更に別の実施形態では、リソースは、ＦＢＥ（フレームベースの機器）又はＬＢＥ（負荷ベースの機器）であると見なされてもよい。具体的には、リソースは、ＦＢＥルールを使用したチャネルアクセス又はＬＢＥルールを使用したチャネルアクセスを可能にするリソースとしてタグ付けされてもよい。ＷＴＲＵは、上位層からの構成（例えば、ＲＲＣ又はＳＩＢ構成）に基づいて、又はＬＣＨ構成（例えば、いくつかのＬＣＨがＦＢＥリソース上で送信されてもよい）に基づいて、このアクセスタイプを決定してもよい。

【0252】

ＷＴＲＵは、ＣＯＴが他のＷＴＲＵと（再）共有されることができる回数で（事前に）構成されるか、又は事前に決定されてもよい。上位層からの構成は、ＣＯＴがｘ回以下で共有されることができることを構成してもよい。ＷＴＲＵは、ＳＣＩ又はＣＯＴ共有ＭＡＣ ＣＥ中に、このＣＯＴが共有された回数を、ＣＯＴ内の残り時間とともに含めてもよい。ＷＴＲＵがｘ回目にＣＯＴを取得する場合、ＷＴＲＵは、他のＷＴＲＵへのＣＯＴ共有に関連付けられたＳＣＩ又はＭＡＣ ＣＥを省略してもよい。あるいは、ＷＴＲＵは、このＣＯＴがもはや共有されることができないことを示す指示を（例えば、ＳＣＩ又はＭＡＣ ＣＥに）含めてもよい。ＷＴＲＵは、それが取得されたｘ回目の送信の終了時にＣＯＴの使用を停止してもよく、又はＭＣＯＴが行われるまでＣＯＴを占有してもよい。

【0253】

一実施形態では、ＷＴＲＵは、特定のタイミングで使用することができるサイドリンクデータリソースのサブセットで構成されてもよい。ＷＴＲＵは、リソースに関連付けられたいくつかのタイミングオフセットにおいてのみチャネルを取得しようと試みてもよい。ＷＴＲＵは、適用可能なオフセットに対応する、無線フレーム境界からの所与のスロットオフセット内で開始するリソースに対してのみＬＢＴを選択及び実行するように構成されてもよい。ＷＴＲＵは、無線フレーム内又はスロット内の可能なオフセットのサブセットを用いて構成されてもよい。ＬＢＴ手順が失敗した場合、ＷＴＲＵは、次の可能なオフセットでチャネルを取得しようと試みてもよい。

【0254】

ＷＴＲＵは、構成値から、又は次の利用可能なリソースまでの時間として、オフセットを半静的に決定してもよい。代替的に、ＷＴＲＵは、オフセットを動的に決定してもよい。動的な決定は、次に依存してもよい、すなわち、（１）ＴＢに関連付けられたデータの優先度、（２）データが、高い優先度インデックスで構成された１つ以上のＬＣＨから多重化されるかどうか、（３）データが、構成されたＬＣＨ又はＤＲＢのサブセットから多重化されるかどうか、（４）ＷＴＲＵのサブスクリプションタイプ、又は（５）ＴＢのために選択されたＨＡＲＱプロセスＩＤである。失敗したＬＢＴの試みの後、ＷＴＲＵは、オフセットをインクリメントするか、又は異なる開始オフセットを伴う異なるリソースを使用してもよい。

【0255】

ＷＴＲＵは、ＬＢＴに失敗したＴＢを（再）送信しようと試みると、再送信時間期間を測定するために再送信タイマを開始してもよい。ＷＴＲＵは、値ＮＡＣＫを伴うＨＡＲＱ－ＡＣＫがＨＡＲＱプロセスに対して決定された場合にのみ、再送信タイマを開始してもよい。ＷＴＲＵは、再送信時間期間中にチャネルを取得しようと試みなくてもよい。タイマ又は時間期間の値は、上位層によって構成されてもよいか、又はチャネルを取得するために使用される前のＬＢＴの試み又は選択されたタイミングオフセットに基づいて動的に変更されてもよい。

【0256】

ＷＴＲＵは、リソースプールごと、ＳＬキャリアごと、ＬＢＴ帯域幅／サブ帯域ごと、又はＭＡＣエンティティごとに再送信タイマを維持し、再送信タイマを用いて構成されてもよい。一例では、ＷＴＲＵは、所与のリソースプール上でのＬＢＴ失敗後にタイマを開始してもよい。あるリソースプールに関連付けられたタイマが動作している間、ＷＴＲＵは、そのリソースプール上でＴＢを再送信又は送信するためのリソースを選択しなくてもよい。ＷＴＲＵは、場合によっては、プールに関連付けられたタイマが動作していない場合、及び／又はＨＡＲＱプロセスＩＤがリソースプールのために構成されている場合、及び／又はＴＢサイズがサポートされている場合、最後に選択されたリソースプールとは異なるリソースプール上でＴＢを（再）送信してもよい。

【0257】

ＷＴＲＵは、ＣＯＴ内で、又はＣＯＴの時間位置に対してリソースを優先順位付け／選択してもよい。ＷＴＲＵは、利用可能なリソースのセットを決定してもよく、リソースのサブセットは、ＣＯＴ内のリソースを含んでもよく、他のリソースは、ＣＯＴ内になくてもよい。ＷＴＲＵは、場合によっては本明細書のいくつかの条件下で、ＣＯＴ内のリソースを選択又は優先順位付けしてもよい。例えば、送信に利用可能なデータが閾値優先度を上回る場合、ＷＴＲＵは、ＣＯＴ内のリソースからのみ選択してもよい。そうでない場合、ＷＴＲＵは、ＣＯＴ内からリソースを選択することを許可されてもよく、又はＣＯＴ内からリソースを選択しなくてもよい。例えば、測定されたＣＢＲが閾値を上回る場合、ＷＴＲＵは、ＣＯＴ内のリソースからのみ選択してもよく、又はＣＯＴ内のリソースの選択を優先してもよい。

【0258】

ＷＴＲＵは、送信又は再送信から選択して実行するために複数のリソースが利用可能であると決定してもよい。

【0259】

ＷＴＲＵは、ＣＯＴ中の残り時間に基づいて、リソースの選択に優先順位付けしてもよい。ＷＴＲＵは、残りのＣＯＴ時間の降順でリソースの選択に優先順位付けしてもよい。ＷＴＲＵは、リソースの開始時間及び／又は同じＣＯＴにおける以前の送信のタイミングから示された（例えば、ＳＣＩ若しくはシグナリングされた制御情報において）又は決定されたＣＯＴにおける残り時間に基づいて、ＣＯＴにおける最大の残り時間を伴うリソースを選択してもよい。

【0260】

ＷＴＲＵはまた、ＴＢ送信を実行するために必要とされる時間に基づいてリソースの選択に優先順位付けしてもよい。ＷＴＲＵは、残りの時間が、所望のバッファリングされたビット、パケット当たりのビット数、又はＴＢ中のビット数の送信をサポートすることができる場合にのみ、リソースを選択してもよい。ＷＴＲＵは、許可のＴＢがＴＢサイズをサポートする場合にのみリソースを選択してもよい。ＴＢ送信基準を実行するために必要とされる時間を満たす複数のリソースの中で、ＷＴＲＵは、最小の持続時間を伴うリソースを選択してもよい。

【0261】

ＷＴＲＵはまた、送信レイテンシに基づいてリソースの選択に優先順位付けしてもよい。ＷＴＲＵは、（送信されるべきデータ、又はＴＢにおいて多重化されるデータに関連付けられたＱｏＳ要件から決定されてもよい）送信レイテンシを満たすリソースを選択してもよい。例えば、ＷＴＲＵは、データに関連付けられたレイテンシバジェットの前に終了するＣＯＴを有するリソース、及び／又は短いＬＢＴ期間の直後に開始するデータリソースを含むリソースを選択してもよい。

【0262】

ＷＴＲＵはまた、ＲＳＳＩに基づいてリソースの選択に優先順位付けしてもよい。ＷＴＲＵは、構成された、又は所定のＲＳＳＩ又はＣＢＲ閾値を満たすリソースを選択してもよい。ＷＴＲＵは、ＲＳＳＩの降順によってリソースの選択に優先順位付けしてもよい。

【0263】

ＷＴＲＵはまた、リソースに関連付けられた必要なＬＢＴタイプ又は構成に基づいて、リソースの選択に優先順位付けしてもよい。例えば、ＷＴＲＵは、ＬＢＴタイプ１、タイプ２、次いでタイプ４をその順序で必要とするリソースの選択に優先順位付けしてもよい。ＷＴＲＵは、最小のＣＡＰＣを伴う、すなわち、ＣＣＡに対してより短い輻輳ウィンドウサイズを必要とするリソースの選択を優先してもよい。

【0264】

一実施形態では、ＷＴＲＵは、利用可能なリソースのセットを決定してもよい。ＷＴＲＵは、ＣＯＴの開始又は終了から閾値数のスロット以下で生じるリソースを選択又は優先順位付けしてもよい。代替として、ＷＴＲＵは、チャネルを取得するために１つ以上のＬＢＴタイプを必要とするリソースを選択又は優先順位付けしてもよく、チャネルを取得するために１つ以上の異なるＬＢＴタイプを必要とするリソースを選択／優先順位付けしなくてもよい。ＷＴＲＵは、現在のＷＴＲＵ若しくは別のＷＴＲＵの送信（ＳＣＩにおいて検出されるような）、又は計画された送信（ＳＣＩにおけるフォワードルッキング情報に基づいて決定されるような）からのスロットの閾値数以下で発生するリソースを選択又は優先順位付けしてもよい。ＷＴＲＵは、例えば、測定されたＣＢＲが閾値を上回る場合、送信に利用可能なデータが閾値優先度を上回る場合など、本明細書で言及される任意の条件に基づいて、現在のＷＴＲＵ又は別のＷＴＲＵの送信からスロット数以下の間隔で離間されたリソースを選択又は優先度付けしてもよい。

【0265】

一実施形態では、ＷＴＲＵは、利用可能なリソースのセットを決定してもよい。ＷＴＲＵは、ＷＴＲＵがすでにＣＯＴを開始している場合、及び／又はリソース選択ウィンドウがＣＯＴと重複する場合、ＣＯＴ内のリソースの送信を選択又は優先してもよい。ＷＴＲＵは、測定されたＣＢＲが閾値を上回る、及び／又は送信に利用可能なデータの優先度が閾値を上回るなど、本明細書の条件に基づいてそのようなことを実行してもよい。

【0266】

上記の実施形態では、ルールは、リソース選択を実行するＷＴＲＵによって開始されるＣＯＴにのみ適用してもよい。代替的に、ルールは、任意の他のＷＴＲＵによって開始されたＣＯＴに適用されてもよい。代替的に、ルールは、関連するＷＴＲＵ（例えば、同じＬ２宛先ＩＤに送信するＷＴＲＵ、リソース選択を実行するＷＴＲＵとのユニキャストリンクを有するＷＴＲＵ、リソース選択を実行するＷＴＲＵと同じグループの一部であるＷＴＲＵなど）、又はある数の間接レベル内のＷＴＲＵによって開始されるＣＯＴに適用してもよい。

【0267】

一実施形態では、ＷＴＲＵは、特定のＣＯＴタイプに関連付けられたリソースを選択又は優先順位付けしてもよい。一例では、ＷＴＲＵは、送信に利用可能なデータがグループキャストに、場合によっては同じＬ２ ＩＤに関連付けられているときにリソース選択を実行するために、グループキャストＣＯＴに関連付けられたリソースを選択又は優先順位付けしてもよい。例えば、ＷＴＲＵは、場合によっては、送信に利用可能なデータがそのユニキャストリンクへの送信に関連付けられているときにリソース選択が開始されるときに、ユニキャストリンク中の任意のＷＴＲＵによって開始されたＣＯＴに関連付けられたリソースを選択してもよい。

【0268】

別の例では、ＷＴＲＵは、場合によっては本明細書で説明する特定の条件下で、間接の数が閾値を下回るリソースを選択又は優先順位付けしてもよい。別の例では、ＷＴＲＵは、１つの条件下でＦＢＥであるリソースを選択又は優先順位付けしてもよく、そうでない場合、ＬＢＥであるリソースを選択又は優先順位付けしてもよい（又はその逆も同じ）。そのような条件は、測定されたＣＢＲに基づいてもよい。そのような条件は、データの優先度に基づいてもよい。そのような条件はまた、利用可能なデータとともに最高の優先度を有するＬＣＨの特性に基づいてもよい。

【0269】

一実施形態では、ＷＴＲＵは、ＣＯＴ情報に基づいてリソース選択のためのパラメータを決定してもよく、パラメータは、本明細書で説明される任意のパラメータを含んでもよい。ＣＯＴ情報は、リソースがＣＯＴ内にあるかどうか、リソースが関連付けられているＣＯＴのタイプ、ＷＴＲＵ又は別のＷＴＲＵによるＣＯＴの開始からの時間、ＷＴＲＵ又は別のＷＴＲＵの最後の送信からの時間など、リソースに関連付けられてもよい。

【0270】

ＷＴＲＵは、リソースがＣＯＴ内で選択されるとき、ＲＢの第１の最大数を選択してもよく、リソースがＣＯＴ外で選択されるとき、ＲＢの第２の最大数を選択してもよい。ＷＴＲＵは、そのようなリソースがＦＢＥに関連付けられているときにのみ、周期的送信のためのリソースを選択してもよい。そうではない場合、リソース選択がワンショット送信のためにトリガされる場合、ＷＴＲＵは、ＬＢＥに関連付けられたリソースからのみリソースを選択してもよく、又はＦＢＥ若しくはＬＢＥに関連付けられたリソースからリソースを選択してもよい。

【0271】

ＷＴＲＵは、リソースがＬＢＥに関連付けられるとき、送信のために利用可能ないくつかの連続するスロットを有する要求されたものを使用してリソースを選択してもよく、リソースがＦＢＥに関連付けられるとき、そのような要求を使用してもよい。ＷＴＲＵは、構成及び／又は決定された利用可能なＦＢＥリソースに基づいて、マルチショットリソース選択のためのリソース選択の許容可能な周期性を決定してもよい。

【0272】

ＷＴＲＵは、ＣＯＴ持続時間に基づいて、（例えば、場合によっては単一のＳＣＩにおいて示される）ＴＢに対する再送信数の許容可能な数を決定してもよい。

【0273】

ＷＴＲＵは、ＣＯＴ又はＣＯＴ構造に関連付けられた情報（例えば、ＣＡＰＣ、間接番号など）に基づいて、送信／再送信／選択されたリソース間の最大時間を決定してもよい。例えば、ＷＴＲＵは、ＣＯＴ内で実行される再送信間の許容可能な時間で構成されてもよく、そのような許容可能な時間は、ＣＯＴのためのＣＡＰＣに関連付けられる（別のＷＴＲＵによって開始されるＣＯＴの一部として示されるか、又はＣＯＴを開始するときにＷＴＲＵ自体によって決定されるかのいずれかである）。ＷＴＲＵは、ＣＯＴ内での送信のためのリソースを選択するときに、特定のＣＡＰＣについての再送信間の最大許容時間が守られることを保証してもよい。

【0274】

ＷＴＲＵは、ＷＴＲＵにおいてＣＯＴを開始するリソース選択を実行するときに、リソース選択時に送信に利用可能なデータの優先度／ＣＡＰＣに基づいて、送信／再送信／選択されたリソース間の最大時間を決定してもよい。具体的には、ＷＴＲＵは、第１の優先度／ＣＡＰＣのための第１の許容可能な時間、第２の優先度／ＣＡＰＣのための第２の許容可能な時間などで構成されてもよい。

【0275】

ＷＴＲＵは、ＷＴＲＵがそれ自体のＣＯＴを開始しているとき、連続した時間リソースを選択してもよい。一方、ＷＴＲＵは、すでに開始された（それ自体によって、又は別のＷＴＲＵによってのいずれかで）ＣＯＴ内で送信しているとき、連続する時間リソースを選択することを要求されなくてもよい。（例えば、許可された、必要とされた）連続するリソースの数は、本明細書で説明する条件（例えば、ＣＢＲ、ＣＡＰＣ、リソース選択をトリガしたデータの優先度、キャスト、ＳＬ測定など）に更に依存してもよい。

【0276】

ＷＴＲＵは、選択されたリソースと、ＷＴＲＵ自体又は別のＷＴＲＵによる任意の実行／告知／計画された送信との間の時間差に基づいて、ＷＴＲＵがＣＯＴを共有しているとき、又はＷＴＲＵがすでに開始しているＣＯＴ内で送信しているとき、連続する時間リソースを選択してもよい。具体的には、連続送信の許容可能な数は、リソースとＷＴＲＵによる最後の送信（場合によっては同じＣＯＴ内の、又は場合によってはリソースが選択されるＣＯＴではないＣＯＴに関連付けられた）との間の時間／ギャップの関数としてもよい。

【0277】

上記の実施形態の１つの利点は、ＷＴＲＵが、未認可スペクトル上での送信のために必要とされるＬＢＴルールに基づいて選択されるリソースを使用して、未認可スペクトル上で送信を実行することを可能にすることである。例えば、ＷＴＲＵが送信の前にＣＡＴ４ ＬＢＴを実行する必要がある可能性があるので、ＣＯＴの開始のために連続リソースが必要とされてもよい。具体的には、ＬＢＴが第１のスロット上で失敗した場合、ＷＴＲＵは、リソース選択中にも後続のスロットを選択しているので、依然として後続のスロットにおいて送信してもよい。ＣＯＴを共有するために、ＷＴＲＵは、短いＬＢＴを実行してもよく、選択される必要がある（場合によっては連続する）リソースの数は、より小さくなる可能性がある。

【0278】

ＷＴＲＵは、本明細書で言及される他の条件と組み合わせて、ＷＴＲＵにおけるＣＯＴ構造、ＣＯＴ開始、ＬＢＴに関連付けられた条件に基づいて、リソース再選択をトリガしてもよい。具体的には、ＷＴＲＵは、以下で説明されるイベント又は条件のいずれか又は組み合わせに基づいてリソース再選択をトリガしてもよい。

【0279】

１つの条件は、ＷＴＲＵがＬＢＴに、場合によっては連続した回数、又は場合によっては選択された（場合によっては連続した）リソースの数だけ失敗することであってもよい。別の条件は、ＷＴＲＵが送信の目的で新しいＣＯＴの開始に失敗することであってもよい。別の条件は、ＷＴＲＵが別のＷＴＲＵによって開始されたＣＯＴを共有することに失敗する（すなわち、ＷＴＲＵが既存のＣＯＴ内の短いＬＢＴに失敗する）ことであってもよい。

【0280】

別の条件は、ＷＴＲＵが、別のＷＴＲＵによるＣＯＴの開始を示すＳＣＩを受信することであってもよく、場合によっては、そのようなＣＯＴが、ＷＴＲＵによってすでに選択されているリソースと重複する場合、場合によっては、そのようなＣＯＴが、当該ＷＴＲＵによってすでに選択されているリソースの前に発生する場合、場合によっては、当該ＷＴＲＵが、それ自体のＣＯＴ開始を実行することを必要とする選択されたリソースを有する場合である。ＷＴＲＵは、ＣＯＴの開始に合わせて調整されたリソースを選択してもよい。ＣＯＴが別のＷＴＲＵによって開始されたことを示すＳＣＩを受信すると、ＷＴＲＵは、これらのリソースの再選択をトリガして、すでに開始されたＣＯＴにおける送信のための新しいリソースを選択してもよい。ＷＴＲＵは、将来の送信のために選択されたいくつかのリソースを有してもよい。次いで、ＷＴＲＵは、当該リソースと重複する別のＷＴＲＵによるＣＯＴの開始を示すＳＣＩを受信してもよい。当該ＷＴＲＵに関与しないＷＴＲＵのグループによってＣＯＴが使用される場合、当該ＷＴＲＵは、プリエンプション／リソース再選択を実行して、その将来の予約済みリソースがＣＯＴと重複しないことを確保してもよい。

【0281】

別の条件は、ＷＴＲＵが、任意の既存の／開始されたＣＯＴよりも高い／低い優先度のＣＡＰＣを伴う、送信のために利用可能なデータを有することであってもよい。別の条件は、送信に利用可能なデータが少なくとも特定の優先度であることであってもよい。例えば、リソース再選択は、データ優先度が閾値を上回る場合にのみ、上記の結果としてトリガされてもよい。別の条件は、測定されたＣＢＲが閾値未満であることであってもよい。例えば、リソース再選択は、ＣＢＲが閾値を下回る場合のみ、上記の結果としてトリガされてもよい。

【0282】

一実施形態では、ＷＴＲＵは、リソースが送信のために利用可能であるかどうかを決定するとき、フォワードブッキング信号において示されたリソース（すなわち、予約ＳＣＩの後のブッキング期間に生じる）並びにフォワードブッキングされたリソースの前及び／又は後に生じる他のリソース（複数可）の両方を、送信のために利用不可能であると見なしてもよい。そのような実施形態は、第１のＴＸ ＷＴＲＵが、ＬＢＴが成功するまで（又はリソースの最大数に達するまで）、（以前のＳＣＩにおいて告知されたリソースに関連した）複数の可能な連続リソース上でＬＢＴを試みることを可能にするが、第２のＴＸ ＷＴＲＵは、成功したＬＢＴに続いて第１のＴＸ ＷＴＲＵによって使用されてもよい任意のリソースをそれ自体の送信のために選択することを回避してもよいという点で有利である可能性がある。

【0283】

一例では、第１のＴＸ ＷＴＲＵは、前のＳＣＩによって直接示される将来の告知されたリソース上でＬＢＴを開始してもよい。第１のＴＸ ＷＴＲＵは、成功した第１の送信の前の失敗したＬＢＴの数にかかわらず、（第１の送信と比較して）将来の告知されたリソースのための計画された周期性を維持してもよい。代替的に、第１のＴＸ ＷＴＲＵは、第１の送信を実行するための失敗したＬＢＴの数に依存する量だけ、第１の送信と第２の送信との間の計画されたギャップを変更してもよい。具体的には、第１のＴＸ ＷＴＲＵは、第２の送信に対する計画されたギャップを、場合によっては第１の送信についてＬＢＴが失敗したスロットの数に等しいスロットの数だけ低減してもよい。第２のＴＸ ＷＴＲＵ（利用可能なリソースを決定するために感知を実行するＴＸ ＷＴＲＵ）として、第２のＴＸ ＷＴＲＵは、前のＳＣＩによって示されたリソース、並びにリソース選択を実行するときに利用不可能であると見なされるいくつかの後続の（場合によっては連続する）スロットを仮定してもよい。

【0284】

別の例では、第１のＴＸ ＷＴＲＵは、それが第１の送信のためにＬＢＴを最初に開始したスロットから常に期間Ｔ（すなわち、選択された周期性）の値である将来の（第２の）リソース上でＬＢＴを開始してもよい。そのような例では、第１のＴＸ ＷＴＲＵは、ＳＣＩ中に、将来のリソースにおける送信のためにＬＢＴを開始してもよい、示された将来の（第２の）リソースの前のスロットの数の指示を含んでもよい。第２のＴＸ ＷＴＲＵは、示されたリソース、並びに示されたリソースより前のいくつかのリソース（そのようなリソースの数がＳＣＩにおいて示される場合）が占有されていると見なされると仮定してもよい。加えて、第２のＴＸ ＷＴＲＵは、示されたリソースの後に占有されるべき時間リソース又はスロットの数を仮定してもよく、そのような数は、連続するスロットにおける可能なＬＢＴの試みの総数から、受信されたＳＣＩにおいて示されたスロット（すなわち、示されたリソースの前のスロット）の数を引いたものによって決定される。

【0285】

ＷＴＲＵは、（場合によっては別のＷＴＲＵから受信された）ＣＯＴ情報及び／又はＷＴＲＵ自体におけるＬＢＴ状態に関連付けられたトリガに基づいて、プリエンプション／再評価をトリガしてもよい。一例では、ＷＴＲＵは、選択された及び／又は示されたリソースの前に（ＬＢＴを使用して）チャネルを取得することに失敗した場合、プリエンプション／再評価をトリガしてもよい。ＷＴＲＵは、再評価を実行し、結果として送信のための新しいリソースを選択してもよい。

【0286】

別の例では、ＷＴＲＵは、ＣＯＴが別のＷＴＲＵによって開始されたことを示すＳＣＩをＷＴＲＵが受信し、ＣＯＴが当該ＷＴＲＵにおいて選択されたリソースと重複する場合、プリエンプション／再評価をトリガしてもよい。ＷＴＲＵは更に、ＣＯＴに関連付けられたＣＡＰＣが、その（重複する）リソースを選択するために当該ＷＴＲＵによって仮定されるＣＡＰＣとは異なる（例えば、より高い優先度、より低い優先度）場合、プリエンプション／再評価をトリガしてもよい。

【0287】

別の例では、ＷＴＲＵは、ＣＯＴが別のＷＴＲＵによって開始されたことを示すＳＣＩをＷＴＲＵが受信した場合、プリエンプション／再評価をトリガしてもよく、ＣＯＴは、選択されたリソースよりも早く発生してもよい。そのようなプリエンプション／再評価は更に、当該ＷＴＲＵによって選択／予約されたリソースがＣＯＴの開始を必要とする場合に（場合によっては、他方のＷＴＲＵによって開始されたＣＯＴが当該ＷＴＲＵによって共有されることができる間に）トリガされてもよい。そのような場合、ＷＴＲＵは、受信されたＳＣＩにおいて示されたＣＯＴ内のリソースのみを再選択してもよい。

【0288】

そのような実施形態の利点は、ＣＯＴが（場合によっては別のＷＴＲＵによって）開始されたとＷＴＲＵが決定し、当該ＷＴＲＵが（それ自体のＣＯＴ開始を実行するのではなく）送信のためにそのＣＯＴを使用することができるときに、ＷＴＲＵにおいて再選択を実行することであってもよい。

【0289】

ＷＴＲＵは、マルチオケージョンサイドリンクデータ送信リソースを（例えば、モード１で）受信してもよく、（例えば、モード２で）選択してもよく、又はそれを用いて構成されてもよい。マルチオケージョンリソースは、ＬＢＴオケージョンが可能である、２つ以上の場合によっては連続するデータ送信オケージョンからなり、それによって、ＷＴＲＵは、ＬＢＴが成功するまで、各オケージョンにおいてＬＢＴを試みてもよい。ＬＢＴが成功すると、ＷＴＲＵは、ＬＢＴを再び実行することなく、リソース中の残りのオケージョンに送信してもよい。各データ送信オケージョンに対して、ＷＴＲＵは、ＬＢＴに失敗した同じＴＢを送信すること、又は異なるＴＢを送信することを試みてもよい。

【0290】

一実施形態では、ＣＯＴを共有するＷＴＲＵは、１つのＷＴＲＵ又は２つ以上のＷＴＲＵと共有されるマルチオケージョンリソースを示してもよく、それによって、共有ＷＴＲＵは、リソースが開始及び／又は使用されることができる開始オケージョンを各共有ＷＴＲＵにシグナリングする。そのような指示は、ＳＣＩ又はＭＡＣ ＣＥによって受信されてもよい。そのようなＳＣＩ又はＭＡＣ ＣＥを受信すると、共有ＷＴＲＵは、共有ＷＴＲＵに対して示されたオケージョンに送信を開始する前に短いＬＢＴ（例えば、タイプ１又は２）を実行してもよく、又は共有ＷＴＲＵの送信と共有ＷＴＲＵ開始時間との間のギャップが事前構成された閾値（例えば、タイプ１ ＬＢＴのギャップ）未満である場合、単にＬＢＴなしで送信してもよい。共有ＷＴＲＵは、ＣＯＴにおける可能な残りの開始オケージョンを示してもよく、共有ＷＴＲＵは、示されたオケージョンの中から、チャネルを取得するオケージョンをランダムに選択してもよい。

【0291】

ＷＴＲＵは、モード１タイプスケジューリングによって基地局（例えば、ｇＮＢ）からマルチオケージョンリソースを受信してもよい。基地局は、１つ以上のＷＴＲＵからのマルチオケージョンリソースをスケジュールしてもよい。基地局（例えば、ｇＮＢ）は、適用可能な開始オケージョンを各ＷＴＲＵに示してもよい。ＷＴＲＵは、指示の開始オケージョンの前に、ＬＢＴなしで、又は短いＬＢＴを用いて送信してもよい。

【0292】

モード２リソースプールは、マルチオケージョンリソースのためのいくつかのオケージョン及び開始時間で構成されてもよい。ＷＴＲＵは、マルチオケージョンバンドル内の第１のオケージョンのタイミングからＨＡＲＱプロセスを決定してもよい。ＷＴＲＵは、ＬＢＴが成功するまで、同じＨＡＲＱプロセスを使用し続けてもよい。ＬＢＴが成功すると、ＷＴＲＵは、ＨＡＲＱプロセスをインクリメント又は変更してもよい（例えば、ＷＴＲＵが送信する更なるデータを有する場合）。

【0293】

一実施形態では、マルチオケージョンリソースは、複数のリソースプールを含んでもよく、それによって、各オケージョンは、１つ以上のリソースプールに関連付けられてもよい。ＷＴＲＵは、ＬＢＴがあるオケージョンに失敗した場合、ＷＴＲＵが次のオケージョンにＬＢＴを試みるように、リソースホッピングパターンで構成されてもよく、これは、異なるリソースプールに関連付けられてよい。

【0294】

モード２においてマルチＬＢＴオケージョンを選択するＷＴＲＵは、それ自体の送信のために複数のリソースを選択してもよい。マルチＬＢＴオケージョンリソースは、連続又は非連続スロット中に同じ周波数リソースを含んでもよい。代替的に、マルチＬＢＴオケージョンリソースは、同じ又は異なるスロット中に異なる周波数リソースを含んでもよい。

【0295】

ＷＴＲＵは、その最初の送信のために複数のリソースを選択し、その後、その再送信のためにリソースの単一のセットのみを選択してもよい。代替的に、ＷＴＲＵは、初期送信のために複数のリソースを選択し、並びに、その初期送信の各リソースに対して、各再送信に対し複数のリソースを選択してもよい。ＷＴＲＵが各初期送信リソースに対して単一の再送信リソース（セット）を選択するか、又は複数のそのようなものを選択するかは、ＷＴＲＵがマルチＬＢＴオケージョン選択を使用するかどうかに対して以下で説明する同じ条件に依存してもよい。例えば、ＷＴＲＵが各初期送信リソースに対して単一の再送信リソース（セット）を選択するかどうかは、送信と再送信リソースとの間の時間、再送信リソースのために必要とされるＬＢＴタイプ、又は選択されたリソースがＣＯＴ内で発生するかどうかに依存してもよい。

【0296】

別の実施形態では、ＷＴＲＵは、マルチＬＢＴオケージョンリソースのいずれかにおいて初期送信又は再送信を実行してもよい。具体的には、マルチＬＢＴオケージョンＳＬリソース上でのＬＢＴが成功すると、ＷＴＲＵは、初期送信を実行し、その後、マルチＬＢＴ送信リソースの残りのリソースにおいて再送信を実行してもよい。ＷＴＲＵは、成功したＬＢＴの後に残りのリソース上での送信のためにＬＢＴが必要とされない（又は異なるＬＢＴタイプが必要とされる）と更に仮定してもよい。

【0297】

モード２ ＷＴＲＵは、ある特定の条件に基づいてマルチＬＢＴオケージョンＳＬリソースの選択を実行してもよい。具体的には、モード２ ＷＴＲＵは、以下のいずれか又は組み合わせが満たされることに基づいて、各初期送信リソースに対してマルチＬＢＴオケージョン及び／又は再送信リソースの数の選択を実行することを決定してもよい。

【0298】

モード２ ＷＴＲＵは、リソース選択が未認可動作に関連付けられたリソースプール上で実行されることに基づいて、各初期送信リソースに対してマルチＬＢＴオケージョン及び／又は再送信リソースの数の選択を実行することを決定してもよい。例えば、ＷＴＲＵは、ＳＬ未認可に関連付けられたリソースのプール上で選択が実行される場合、マルチＬＢＴオケージョンＳＬリソースを選択してもよく、リソースのプールが非共有スペクトル（非未認可スペクトル）上にあるとき、そのような選択を実行しなくてもよい。

【0299】

モード２ ＷＴＲＵは、選択されたリソースがＣＯＴ中で発生するかどうかに基づいて、各初期送信リソースに対してマルチＬＢＴオケージョン及び／又は再送信リソースの数の選択を実行することを決定してもよい。例えば、ＷＴＲＵは、選択されたリソース（例えば、第１の選択されたリソース）がＣＯＴ外で発生する場合、マルチＬＢＴオケージョンＳＬリソースを選択してもよく、そうでない場合、ＷＴＲＵは、マルチＬＢＴオケージョンＳＬリソースを選択しなくてもよい（すなわち、選択されたリソースがＣＯＴ中で発生する場合）。例えば、選択された再送信リソースが、初期送信リソースのいずれかによって開始されるＣＯＴ内で発生する場合、ＷＴＲＵは、初期送信リソースに対して単一の（セットの）再送信リソースを選択してもよい。そうでない場合、ＷＴＲＵは、各再送信に対して複数の（例えば、マルチＬＢＲＴオケージョン）ＳＬリソースを選択してもよい。

【0300】

モード２ ＷＴＲＵは、送信を実行するために必要とされるＬＢＴのタイプに基づいて、各初期送信リソースに対してマルチＬＢＴオケージョン及び／又は再送信リソースの数の選択を実行することを決定してもよい。例えば、ＷＴＲＵは、送信が特定のＬＢＴタイプ（例えば、タイプ１ ＬＢＴ、タイプ２ ＬＢＴ）を必要とする場合、マルチＬＢＴオケージョンＳＬリソースの選択を実行してもよく、そうでない場合、レガシーリソース選択を実行してもよい。

【0301】

モード２ ＷＴＲＵは、送信されるべきデータの優先度に基づいて、各初期送信リソースに対してマルチＬＢＴオケージョン及び／又は再送信リソースの数の選択を実行することを決定してもよい。例えば、ＷＴＲＵは、送信に利用可能なデータの優先度が閾値を上回る場合、マルチＬＢＴオケージョンＳＬリソースの選択を実行してもよく、そうでない場合、レガシーリソース選択を実行してもよい。

【0302】

モード２ ＷＴＲＵは、送信と再送信との間の時間に基づいて、各初期送信リソースに対してマルチＬＢＴオケージョン及び／又は再送信リソースの数の選択を実行することを決定してもよい。例えば、選択された送信と再送信との間の時間が閾値を下回る場合、ＷＴＲＵは、マルチＬＢＴオケージョンに関連付けられた初期送信リソースの全てについて単一の（セットの）再送信リソースのみを選択してもよい。

【0303】

モード２ ＷＴＲＵは、測定されたＣＢＲ、又はＳＬの任意の輻輳メトリックに基づいて、各初期送信リソースに対してマルチＬＢＴオケージョン及び／又は再送信リソースの数の選択を実行することを決定してもよい。例えば、ＷＴＲＵは、測定されたＣＢＲが閾値を下回る場合、マルチＬＢＴオケージョンＳＬリソースの選択を実行してもよく、そうでない場合、レガシーリソース選択を実行してもよい。

【0304】

ＷＴＲＵは更に、マルチＬＢＴオケージョンにおけるリソースの数及び／又はパターンを決定するためのルール及び／又はパラメータを用いて構成されてもよい。ＷＴＲＵは、マルチＬＢＴオケージョンのために選択されてもよい最大数のリソース（すなわち、単一スロットリソース）で構成されてもよい。ＷＴＲＵはまた、マルチＬＢＴオケージョンの各／任意の単一のスロットリソース間の最小／最大数のスロットで構成されてもよい。ＷＴＲＵはまた、リソース選択ウィンドウの開始／終了、又はマルチＬＢＴオケージョンの開始が生じる可能性のある、リソース選択の瞬間からの最大時間を用いて構成されてもよい。ＷＴＲＵはまた、マルチＬＢＴオケージョンの一部であることができる最小／最大数の周波数リソースで構成されてもよい。ＷＴＲＵは、以下の組み合わせに基づいて、上記のルール及び／又はパラメータのいずれかを決定してもよい。

【0305】

ＷＴＲＵは、感知結果に基づいて、マルチＬＢＴオケージョンにおけるリソースの数及び／又はパターンを決定してもよい。例えば、ＷＴＲＵは、本明細書の他の要因に基づいて、いくつかのリソース（例えば、最大まで）を選択してもよい。しかしながら、感知結果が、そのような数のリソースが感知結果に基づいて利用可能でないことを示す場合、ＷＴＲＵは、より少ない数のリソースを選択してもよい。具体的には、ＷＴＲＵは、感知結果によって提供される利用可能性情報に基づいて、許可された場合、最大数までのリソースを選択してもよい。

【0306】

ＷＴＲＵは、優先度／ＱｏＳに基づいて、マルチＬＢＴオケージョンにおけるリソースの数及び／又はパターンを決定してもよい。例えば、ＷＴＲＵは、送信に利用可能なデータの優先度／ＱｏＳに依存するいくつかのリソースを選択してもよい。

【0307】

ＷＴＲＵは、ＣＯＴ情報に基づいて、マルチＬＢＴオケージョンにおけるリソースの数及び／又はパターンを決定してもよい。例えば、ＷＴＲＵは、リソースがＣＯＴ（例えば、別のＷＴＲＵによって開始される）内にあるかどうか、及び／又はＣＯＴ情報（例えば、ＣＡＰＣ）に基づいて、マルチＬＢＴリソースのリソース間の許容可能な時間を決定してもよい。

【0308】

ＷＴＲＵは、ＣＢＲに基づいて、マルチＬＢＴオケージョンにおけるリソースの数及び／又はパターンを決定してもよい。例えば、ＷＴＲＵは、所与の測定されたＣＢＲのためのマルチＬＢＴオケージョンに関連付けられた最大数のリソースで構成されてもよい。

【0309】

ＷＴＲＵは、マルチＬＢＴオケージョンリソースの１つ以上の単一のリソース上でＬＢＴに失敗する可能性がある。そのような場合、ＷＴＲＵは、マルチＬＢＴオケージョンリソースの次のリソース上でＬＢＴを開始又は継続してもよい。リモートＷＴＲＵは、ＬＢＴが成功するまで、又はＷＴＲＵがマルチＬＢＴオケージョンリソース中のリソースの各々に対するＬＢＴの試みを使い果たすまで、マルチＬＢＴオケージョンリソースの各後続のリソースに対してＬＢＴを実行してもよい。

【0310】

ＷＴＲＵは、マルチＬＢＴオケージョンリソースのリソースのうちの１つでＬＢＴが成功すると、以下のいずれか又は組み合わせを実行してもよい。

【0311】

ＷＴＲＵは、マルチＬＢＴオケージョンリソースのリソースのうちの１つ上でＬＢＴが成功すると、成功したＬＢＴに関連付けられたリソース上で送信を実行してもよい。具体的には、ＷＴＲＵは、成功したＬＢＴに続いて、リソース上で初期送信を実行してもよい。ＷＴＲＵは、本明細書で説明される条件に基づいて、成功したＬＢＴに続いてリソース上で初期送信を実行することができるかどうか、又は後続のリソース（必ずしも成功したＬＢＴの直後のリソースである必要はない）を選択すべきかどうかを更に決定してもよい。具体的には、ＷＴＲＵは、保留中のデータ送信の優先度が閾値を上回る場合、ＣＢＲが閾値を下回る場合、リソースが利用可能であることを感知結果が示す場合、又はそれらの任意の組み合わせの場合、又は本明細書で説明される他の要因とともに、成功したＬＢＴに続いて第１のリソースにおいて送信を実行するかどうかを決定してもよい。

【0312】

ＷＴＲＵは、マルチＬＢＴオケージョンリソースのリソースのうちの１つ上でＬＢＴが成功すると、成功したＬＢＴに関連付けられた後続のリソース上で送信を実行してもよい。具体的には、ＷＴＲＵは、送信を開始するマルチＬＢＴオケージョンリソースに関連付けられた残りのリソースのうちの１つを選択してもよく、選択されたリソース上で送信を開始してもよい。ＷＴＲＵは、次に基づいてリソースを選択してもよい。

【0313】

ＷＴＲＵは、優先度に基づいてリソースを選択してもよい。例えば、ＷＴＲＵは、送信を開始するための成功したＬＢＴに続いて、優先度／ＱｏＳとリソースとの間のマッピングを用いて（事前に）構成されてもよい。具体的には、より高い優先度の送信を伴うＷＴＲＵは、マルチＬＢＴリソースの残りのリソースにおいて直ちに（又はより早く）送信を開始してもよく、より低い優先度の送信を伴うＷＴＲＵは、成功したＬＢＴに続いてより遅く送信を開始してもよい。

【0314】

ＷＴＲＵは、残りのＰＤＢに基づいてリソースを選択してもよい。ＷＴＲＵは、残りのＰＤＢに基づいて、成功したＬＢＴに続いて残りのリソースにおいてどのリソースで送信を開始するかを決定してもよい。例えば、残りのＰＢＤが小さいほど、ＷＴＲＵはより早く送信を開始してもよい。ＷＴＲＵは、成功したＬＢＴに続く送信の開始のためのリソースを（ランダムに、又は本明細書の他のルールに基づいて）選択してもよく、これは、送信及び場合によっては後続の再送信が、ＰＢＤが満了する前に実行されることを確保する。

【0315】

ＷＴＲＵは、ランダムルール又は確率的ルールに基づいてリソースを選択してもよい。例えば、ＷＴＲＵは、マルチＬＢＴオケージョンの残りのリソースのうちの１つからランダムに選択してもよく、それは、送信を開始するための他の基準のいずれかを更に満たす可能性がある。ＷＴＲＵは、マルチＬＢＴオケージョンの残りのリソースのいずれかで送信を開始する確率（本明細書の他の要因に依存するか、又はそれによって決定されてもよい）で構成されてもよい。

【0316】

ＷＴＲＵは、ＨＡＲＱフィードバックタイムラインに基づいてリソースを選択してもよい。例えば、ＷＴＲＵは、送信及び再送信のためのリソースの選択中にＷＴＲＵによって選択されたＨＡＲＱタイムラインを守る送信を開始するための成功したＬＢＴに続いて、残りのリソース中のリソースを選択してもよい。

【0317】

ＷＴＲＵは、感知結果に基づいてリソースを選択してもよい。例えば、ＷＴＲＵは、ＷＴＲＵが他のＳＬ ＷＴＲＵ送信を（すなわち、ＳＣＩにおいて）検出するかどうかに基づいて、マルチＬＢＴオケージョンリソースのリソースのうちの１つにおいて送信するかどうかを決定してもよい。ＷＴＲＵは、ＬＢＴの開始時に、又はＬＢＴの成功時に、連続的な部分的な感知動作を開始してもよい。ＷＴＲＵは、リソースが利用可能であることを連続的な部分的な感知が示すマルチＬＢＴリソースの第１のリソースにおいてのみ送信を開始してもよい。

【0318】

ＷＴＲＵは、成功したＬＢＴに続いて、マルチＬＢＴリソースの複数のリソース上で送信を実行してもよい。例えば、ＷＴＲＵは、成功したＬＢＴから開始して、マルチＬＢＴリソースの複数の（場合によっては時間的に連続する）リソース上で送信を実行することを決定してもよい。ＷＴＲＵは、以下のいずれか又は組み合わせに基づいて、複数の送信を実行するかどうか、及び後続の再送信の数を決定してもよい。

【0319】

ＷＴＲＵは、送信の優先度／ＱｏＳに基づいて、複数の送信を実行するかどうか、及び後続の再送信の数を決定してもよい。例えば、ＷＴＲＵは、ＴＢの優先度が閾値を上回る場合、送信及び再送信のための成功したＬＢＴの後に残りのリソースのうちの複数を使用することを許可されてもよい。

【0320】

ＷＴＲＵは、後続のデータの優先度／ＱｏＳに基づいて、複数の送信を実行するかどうか、及び後続の再送信の数を決定してもよい。例えば、ＷＴＲＵが、閾値を上回る優先度、又は第１の送信に対する何らかの優先度（例えば、少なくとも第１の送信と同じ優先度、第１の送信よりも低いある優先度以下）を伴う送信のための追加のデータを有する場合、ＷＴＲＵは、成功したＬＢＴ後の第１の送信に続いて、後続のリソースを使用することを許可されてもよい。

【0321】

ＷＴＲＵは、ＣＢＲに基づいて、複数の送信を実行するかどうか、及び後続の再送信の数を決定してもよい。例えば、ＷＴＲＵは、ＣＢＲが閾値未満である限り、マルチＬＢＴリソースの後続のリソースを使用することを許可されてもよい。使用されることができるマルチＬＢＴリソースの後続のリソースの数は、測定されたＣＢＲに依存してもよい。

【0322】

ＷＴＲＵは、複数の送信を実行すべきかどうか、及び計画された／許可された再送信の数に基づいて後続の再送信の数を決定してもよく、例えば、ＷＴＲＵは、成功したＬＢＴに続いてマルチＬＢＴリソースにおいて最初に送信されたＴＢに関連付けられている可能性がある再送信を計画している場合、後続のリソースを使用してもよい。

【0323】

ＷＴＲＵは、それがリソースを維持してもよいこと、又は次のリソース上で送信を実行してもよいことを（例えば、ＳＣＩにおいて）示してもよい。ＷＴＲＵは、初期送信若しくは再送信のために次のリソースを使用することを決定するかどうか、及び／又はそのような（再）送信の優先度を更に示してもよい。

【0324】

ＷＴＲＵは、ＬＢＴの実行を継続するか、又はより短いＬＢＴを実行してもよい。例えば、マルチＬＢＴオケージョンにおける成功したＬＢＴに続いて、ＷＴＲＵが、（本明細書における条件に基づいて決定されるように）成功したＬＢＴの後のいくつかのスロットで送信を実行することを決定した場合、ＷＴＲＵは、ＬＢＴを実行し続けてもよく、又は、マルチＬＢＴオケージョンのための第１の成功したＬＢＴに続く実際の送信のために選択されたリソースの前に短いＬＢＴを実行してもよい。例えば、ＬＢＴのタイプは、第１の成功したＬＢＴと、マルチＬＢＴオケージョン内の送信の選択されたリソースとの間の時間に更に依存してもよい。具体的には、ＷＴＲＵが、第１の成功したＬＢＴの直後に、又は第１の成功したＬＢＴの後に最大Ｎ個のスロットを送信することを決定する場合、ＷＴＲＵは、短いＬＢＴなしで送信してもよい。

【0325】

ＷＴＲＵは、マルチＬＢＴオケージョンにおいて選択されたリソースを取得することに関連付けられた失敗時に回復手順を実行するように構成されてもよい。ＷＴＲＵは、一般にＬＢＴに関連する任意の失敗時に（例えば、１つ又はいくつかの失敗したＳＬ ＬＢＴの後に）回復手順を実行するように構成されてもよい。このような回復手順は、以下のいずれであってもよい。

【0326】

回復手順は、リソース及び／又はキャリア再選択を実行することであってもよい。回復手順はまた、ＵＬ送信を実行し、場合によっては基地局（例えば、ｇＮＢ）に失敗を通知してもよい。回復手順はまた、ＳＬ ＲＬＦを宣言することであってもよい。回復手順はまた、ＦＢＥリソース上で送信を開始することであってもよい。回復手順はまた、ＲＲＣ接続を開始することであってもよい。

【0327】

回復手順を実行するためのトリガは、マルチＬＢＴリソースの特性に関連付けられてもよい。ＷＴＲＵは、マルチＬＢＴオケージョンのための利用可能なリソースの適切なセットを選択するために、リソース選択の失敗時に（場合によっては、連続した回数、又は時間ウィンドウ内の回数）、回復手順をトリガしてもよい。適切な数の利用可能なリソースは、リソース選択ウィンドウ内で少なくともＮ個の連続する単一スロットリソースを見つけることを含んでもよい。

【0328】

ＷＴＲＵは、マルチＬＢＴオケージョンに関連付けられたリソースの全てに対するＬＢＴ失敗時に、回復手順、場合によっては連続した回数、又はウィンドウ内の回数をトリガしてもよい。

【0329】

ＷＴＲＵは、マルチＬＢＴオケージョン中にチャネルを取得するのに失敗したこと、又はマルチＬＢＴオケージョン中にチャネルを成功裏に取得したが、次を有することに関連付けられた１つ又は複数のイベント（例えば、連続した数のイベント、又は構成された時間ウィンドウ内で発生するいくつかのイベント）の際に、回復手順をトリガしてもよい、すなわち、（１）閾値を下回ったオケージョン内に残っているリソースの数、（２）リソースが利用不可能であることを示す感知結果に起因して、送信若しくはいくつかの再送信を実行しないこと、並びに／又は（３）成功したイベントに関連付けられた構成された量若しくは所望の量を下回る、マルチＬＢＴオケージョン内の送信及び／若しくはいくつかの再送信を実行することである。

【0330】

ＷＴＲＵは、許可に関連付けられる可能性のある、ＣＯＴ情報に固有のルール／制限（例えば、ＬＣＰ制限）を使用して、ＳＬ上での送信のためにデータ多重化を実行してもよい。そのような制限は、ＣＯＴ又はＣＯＴ関連情報に結び付けられる、本明細書における任意のプロパティに関連してもよい。ＷＴＲＵは、別のＷＴＲＵからの明示的な送信からＣＯＴに関する情報（すなわち、ピアＷＴＲＵによって提供されるＣＯＴに関する情報要素）を決定してもよい。ＷＴＲＵは、代替的又は追加的に、送信自体からＣＯＴに関する情報（例えば、キャストタイプ、Ｌ２ ＩＤ、ＭＣＲ、又はサイドリンク送信に含まれる任意の他の情報など）を決定してもよい。例えば、ＷＴＲＵは、ＣＯＴの存在を識別してもよく、１つの（例えば、第１の）又はＣＯＴで発生する任意の送信に関連付けられたこれらのパラメータのいずれかを決定することによって、キャストタイプ、Ｌ２ ＩＤ、ＭＣＲなどをＣＯＴに関連付けてもよい。

【0331】

具体的には、ＬＣＰ制限は、Ｌ２宛先ＩＤの選択及び／又はサイドリンク上での送信のための論理チャネルの選択中に、ＷＴＲＵによって実行されてもよい。そのＬＣＰ制限は、許可に関連付けられた以下のプロパティのいずれかに関連してもよい、すなわち、

【0332】

ＬＣＰ制限は、許可が既存のＣＯＴ内にあるかどうか（すなわち、ＷＴＲＵによるＣＯＴの作成に関連付けられているかどうか）に関連してもよい

【0333】

ＬＣＰ制限は、許可がＣＯＴ内にあるかどうか、ＣＯＴがＷＴＲＵ自体によって開始されたか、又は別のＷＴＲＵによって開始されたかどうかに関連してもよい。

【0334】

ＬＣＰ制限は、許可がＣＯＴ内にあるかどうか、ＣＯＴがユニキャスト／グループキャスト／ブロードキャスト送信によって開始されたかどうかに関連してもよい。

【0335】

ＬＣＰ制限は、許可がＣＯＴ内にあるかどうか、送信がＣＯＴを開始したＷＴＲＵのソース／宛先Ｌ２ ＩＤに関連してもよい。

【0336】

ＬＣＰ制限は、許可がモード１許可であるか又はモード２許可であるかに関連してもよい。

【0337】

ＬＣＰ制限は、許可がＣＯＴ内にあるかどうか、ＣＯＴ長さ、残りのＣＯＴ長さ、又はＣＯＴと許可自体との間の任意の時間関係に関連してもよい。

【0338】

ＬＣＰ制限は、許可がＣＯＴ内にあるかどうか、ＣＯＴ内ですでに実行されたＳＬ送信の数、他のＷＴＲＵ又はＷＴＲＵ自体の送信に基づいてＣＯＴ内で測定されたチャネルの占有率（ＣＲ、ＣＢＲ、又は予約／使用されたサブチャネルの数）に関連してもよい。

【0339】

ＬＣＰ制限は、その内に許可が存在するＣＯＴのＣＡＰＣに関連付けられてもよい。例えば、ＷＴＲＵは、そのデータのＣＡＰＣが、ＷＴＲＵが共有しようとしているＣＯＴに関連付けられたＣＡＰＣよりも高い優先度である限り、あるＬＣＨのデータを多重化することを許可されてもよい。

【0340】

例えば、ＷＴＲＵは、別のＷＴＲＵによって開始されたＣＯＴ内でＣＡＰＣを受信してもよい。ＷＴＲＵは、許可に多重化される可能性のあるＬＣＨの選択を、ＣＡＰＣに関連する優先度を有するＬＣＨに制限してもよく、例えば、ＣＡＰＣに関連付けられた許可された優先度のリスト、ＣＡＰＣに基づいて決定される閾値を上回る優先度、及び／又は優先度が、ＣＡＰＣの優先度に対して何らかの関係（例えば、よりも低いある数のレベル以上である、それよりも小さくない）を有する。

【0341】

ＬＣＰ制限は、ＷＴＲＵによって開始されるＣＯＴにおける許可に関連付けられてもよく、又は別のＷＴＲＵと共有されてもよい。例えば、ＷＴＲＵは、ある優先度又は優先度範囲のデータを、ＣＯＴを開始するために使用される許可、ＷＴＲＵがＣＯＴを共有する許可、及びＷＴＲＵがすでに開始したＣＯＴ上でＷＴＲＵが送信する許可に多重化することを許可されてもよく／許可されなくてもよい。更に、３つの場合の各々の組み合わせが可能である。例えば、ＷＴＲＵは、ＷＴＲＵがそれ自体のＣＯＴを開始する及び／又は開始した許可において、閾値よりも高い／低い優先度を伴うデータを多重化することを許可されてもよい。

【0342】

例えば、ＷＴＲＵは、別のＷＴＲＵによって開始されるＣＯＴ内の許可のための第１の優先度制限ルール、及びそのＷＴＲＵ自体によって開始されるＣＯＴのための第２の優先度制限ルールを用いて構成されてもよい。例えば、許可が別のＷＴＲＵによって開始されたＣＯＴ内に入る場合、送信ＷＴＲＵは、ＣＯＴ情報において示された優先度／ＣＡＰＣと少なくとも同じ高さの優先度を伴うＬＣＨのみを選択してもよい。許可が、ＷＴＲＵ自体によって開始されるべきＣＯＴ内に入る場合、ＷＴＲＵは、ＣＯＴに多重化するために任意のＬＣＨ優先度を選択してもよい。

【0343】

別の例では、ＷＴＲＵは、そのＷＴＲＵによってすでに開始されたＣＯＴ内にある許可に対する、ＣＯＴの開始をもたらすＣＯＴ内の許可に対する第１の優先度制限ルールを用いて構成されてもよい。例えば、許可が、ＷＴＲＵ自体によって以前に開始されたＣＯＴに入る場合、ＷＴＲＵは、ＬＣＨを制限してもよい／しなくてもよい、又はＣＯＴを開始するために使用した許可に関連付けられた制限とは異なる優先度制限を使用してもよい。

【0344】

ＬＣＰ制限は、ＣＯＴに結び付けられたプロパティに関連付けられてもよく、及び／又はＣＯＴを開始した許可において送信されるデータに関連付けられてもよく、そのようなプロパティは、キャストタイプ、宛先ＩＤ、優先度、ＷＴＲＵグループ、遅延、ＰＤＢ、又は本明細書で説明される任意の他のＳＬプロパティであってもよい。例えば、ＷＴＲＵは、ＣＯＴ内で発生する許可において特定のキャストタイプのデータを多重化することを許可されてもよく、そのようなケースタイプは、ＣＯＴに関連付けられたキャストタイプ（例えば、ＣＯＴにおける情報に含まれる）又はＣＯＴを開始した許可において使用されたキャストタイプによって決定される。具体的には、ＣＯＴが特定のキャストタイプのために使用されると、ＣＯＴはそのキャストタイプのために使用され続ける必要がある。更に、制限は、キャストタイプ自体に依存してもよい。例えば、ユニキャスト送信によって開始されたＣＯＴを共有しているＷＴＲＵは、ＣＯＴを開始したＷＴＲＵのＬ２ソースＩＤと同じであるＬ２宛先ＩＤのみを選択してもよい。例えば、ブロードキャスト送信によって開始されたＣＯＴを共有しているＷＴＲＵは、（場合によっては、ＣＯＴを開始した同じＬ２ ＩＤの）グループキャスト又は任意のユニキャスト送信のいずれかに関連付けられたＬ２ ＩＤを選択してもよい。例えば、ブロードキャスト送信によって開始されるＣＯＴを共有しているＷＴＲＵは、ＣＯＴを共有する送信のために任意のＬ２ ＩＤを選択してもよい。

【0345】

例えば、ＷＴＲＵは、ＣＯＴ内で発生する許可において特定のＬ２ ＩＤのデータを多重化することを許可されてもよく、そのようなケースタイプは、ＣＯＴに関連付けられたＬ２ ＩＤ（例えば、ＣＯＴにおける情報に含まれる）又はＣＯＴを開始した許可において使用されたＬ２ ＩＤによって決定される。具体的には、ＣＯＴが特定のＬ２ ＩＤのために使用されると、ＣＯＴはそのＬ２ ＩＤのために使用され続ける必要がある。具体的には、グループキャスト／ブロードキャスト送信によって開始されたＣＯＴ内で発生する保留中の許可を伴うＷＴＲＵは、ＣＯＴを開始した送信のＬ２ ＩＤと同じである、その許可上での送信のためのＬ２ ＩＤを選択してもよい。

【0346】

ＬＣＰ制限は、本明細書で説明されるように、ＣＯＴに関連付けられた間接番号に関連付けられてもよい。例えば、ＷＴＲＵは、ある間接番号又は間接番号のセットのＣＯＴ内で発生する許可に多重化することができる／できないＬＣＨのセットを用いて構成されてもよい。例えば、ＷＴＲＵは、ある間接番号又は間接番号のセットのＣＯＴ内で発生する許可に多重化することができる／できない１つ以上のキャストタイプを用いて構成されてもよい。

【0347】

ＬＣＰ制限は、送信のモード（すなわち、モード１対モード２）に関連付けられてもよい。例えば、ＣＯＴは、ＣＯＴを開始するときにＷＴＲＵによって使用されたリソース選択モードを表す可能性のある、モード（すなわち、モード１又はモード２）に関連付けてもよい。ＷＴＲＵは、送信自体の中の情報から、ＣＯＴを開始するために使用された送信のモードを決定してもよい。ＣＯＴを開始するＷＴＲＵは、ＣＯＴを開始するために使用される動作モード（モード１又はモード２）を含んでもよい。ＷＴＲＵは、モード１及び／又はモード２に関連付けられたＣＯＴにおいて多重化することができる／できないＬＣＨのセットで構成してもよい。

【0348】

ＬＣＰ制限は、送信のために利用可能なデータ及び／又はＣＯＴを開始した送信のＭＣＲに関連付けられてもよい。例えば、ＷＴＲＵは、ＣＯＴがＭＣＲを伴う／伴わない送信によって開始されたかどうかに基づいて、許可において多重化される論理チャネルに対する許容可能なＬ２宛先ＩＤ、ＬＣＨ優先度、又は他の制限を決定してもよい。例えば、送信によって開始されたＣＯＴをＭＣＲと共有するＷＴＲＵは、ＣＯＴを開始した送信のＬ２ ＩＤに一致するＬ２ ＩＤのみを選択してもよい。そうではなく、ＣＯＴがＭＣＲなしの送信で開始された場合、ＷＴＲＵは、任意のＬ２ ＩＤを選択してもよい。

【0349】

別の例では、ＷＴＲＵは、許可を使用するＷＴＲＵが、ＣＯＴを開始した送信のＭＣＲの内側／外側に位置するかどうかに基づいて、許可において多重化される論理チャネルに対する許容可能なＬ２宛先ＩＤ、ＬＣＨ優先度、又は他の制限を決定してもよい。例えば、ＷＴＲＵが、ＣＯＴを開始した送信に関連付けられたＭＣＲの内部に位置する場合、ＷＴＲＵは、ＣＯＴを共有している許可のための任意のＬ２ ＩＤ及び／又はＬＣＨ優先度を選択してもよい。そうではなく、ＷＴＲＵが、ＣＯＴを開始した送信に関連付けられたＭＣＲの外側に位置する場合、ＷＴＲＵは、同じＬ２ ＩＤの選択、及び／又は許可に多重化されることができるＬＣＨ優先度の制限（例えば、ＣＯＴに関連付けられたＣＡＰＣ以上の優先度を伴うＬＣＨのみ）に制限されてもよい。

【0350】

別の例では、ＷＴＲＵは、ＣＯＴを開始した送信のＭＣＲが閾値を上回る／下回るかどうかに基づいて、許可において多重化される論理チャネルに対する許容可能なＬ２宛先ＩＤ、ＬＣＨ優先度、又は他の制限を決定してもよい。例えば、ＷＴＲＵは、閾値ＭＣＲを構成してもよく、又は（例えば、本明細書で説明される他の要因に基づいて）閾値ＭＣＲを決定してもよい。ＰＤＵのＭＣＲが閾値を上回る場合、ＷＴＲＵは、任意の優先度を伴う論理チャネルを含むことを許可してもよい。ＭＣＲが閾値未満である場合、ＷＴＲＵは、ＣＡＰＣに等しい優先度、又はＣＡＰＣを決定する優先度を伴う論理チャネルのみを含んでもよい。

【0351】

更に、ＷＴＲＵは、上述の３つの組み合わせのいずれかに基づいて、許可において多重化される論理チャネルに対する許容可能なＬ２宛先ＩＤ、ＬＣＨ優先度、又は他の制限を決定してもよい。

【0352】

ＬＣＰ制限は、ＣＯＴ内のＳＬリソースの占有に基づいてもよい。例えば、ＷＴＲＵは、ＣＯＴ内のＳＬリソースの測定された占有率に基づいて、許容可能な宛先Ｌ２ ＩＤ、ＬＣＨ優先度、又は他の制限を決定してもよい。例えば、場合によってはＣＯＴ内のチャネルの占有率が低い（例えば、閾値未満である）と決定された場合、ＷＴＲＵは、ＣＯＴを共有するときに、より低い優先度（例えば、閾値未満、ＣＯＴのＣＡＰＣ未満など）を伴うＬＣＨを含んでもよい。代替的に、場合によってはＣＯＴ内のチャネルの占有率が高い（例えば、閾値を上回る）と決定された場合、ＷＴＲＵは、高い優先度（例えば、閾値を上回る、ＣＯＴのＣＡＰＣを下回るなど）を伴うＬＣＨのみに制限されてもよい。

【0353】

ＣＯＴを開始したノードに関連付けられたＬＣＰ制限。例えば、ＷＴＲＵは、基地局（例えば、ｇＮＢ）によって、又は別のＷＴＲＵによって開始されるＣＯＴにおいて生じる許可に多重化することができる／できないＬＣＨのセットを用いて構成されてもよい。例えば、ＷＴＲＵは、別のＷＴＲＵによって開始されるＣＯＴに対して第１のＬＣＰ制限ルールを使用してもよく、基地局（例えば、ｇＮＢ）によって開始されるＣＯＴに対して第２のＬＣＰ制限ルールを使用してもよい。

【0354】

ＷＴＲＵは、同等の優先度、同等のデータ／制御タイプ、又は同様のもののみに関連するデータを含むようにＬＣＰ制限を適用することを決定してもよい。そのような実施形態は、ＰＤＵが高優先度データを含むときに、ＷＴＲＵが低優先度ＣＡＰＣを（低優先度データがＰＤＵに含まれることに起因して）選択する場合を回避するために使用してもよい。一例では、ＷＴＲＵは、最小優先度と最大優先度との間の差を閾値未満に制限してもよい。一例では、ＷＴＲＵが、閾値よりも大きい優先度を伴うデータ又は制御を含む場合、ＷＴＲＵは、閾値よりも小さい優先度を伴う任意のデータ又は制御を含むことができない。一例では、ＷＴＲＵは、ＰＤＵに一緒に含めることができる優先度の組み合わせのセットで（事前）構成されてもよい。一例では、ＷＴＲＵは、ＰＤＵがＭＡＣ ＣＥ又はＤＲＢを含むとき、ＬＣＰ制限を適用してもよい。本明細書のそのような実施形態では、優先度は、ＬＣＨ優先度、Ｌ１優先度、又は直接ＣＡＰＣを指すことができる。

【0355】

ＷＴＲＵは、本明細書で識別されるように、ＳＬ係数又は送信のタイプに基づいて、ＬＣＰ制限（例えば、上記のＬＣＰ制限のいずれか）を適用するかどうかを決定してもよい。例えば、ＷＴＲＵは、第１のリソース割り当てモード（例えば、モード１）に対してＬＣＰ制限を適用し、第２のリソース割り当てモード（例えば、モード２）に対してＬＣＰ制限を適用しなくてもよい。

【0356】

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

【図1A】

【図1B】

【図1C】

【図1D】

【図2】

【図3】

【国際調査報告】