▶ アイディーエーシー ホールディングス インコーポレイテッドの特許一覧
特許7142148ニューラジオ（ＮＲ）における物理サイドリンク制御チャネル（ＰＳＣＣＨ）設計に対する方法および装置
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】
(24)【登録日】2022-09-14
(45)【発行日】2022-09-26
(54)【発明の名称】ニューラジオ（ＮＲ）における物理サイドリンク制御チャネル（ＰＳＣＣＨ）設計に対する方法および装置
(51)【国際特許分類】
H04W 92/18 20090101AFI20220915BHJP
H04W 4/46 20180101ALI20220915BHJP
H04W 72/04 20090101ALI20220915BHJP
H04W 76/14 20180101ALI20220915BHJP
H04W 28/04 20090101ALI20220915BHJP
【ＦＩ】
H04W92/18
H04W4/46
H04W72/04 136
H04W72/04 137
H04W76/14
H04W28/04 110
【請求項の数】
20
(21)【出願番号】P 2021506526
(86)(22)【出願日】2019-08-08
(65)【公表番号】
(43)【公表日】2021-12-02
(86)【国際出願番号】 US2019045747
(87)【国際公開番号】W WO2020033719
(87)【国際公開日】2020-02-13
【審査請求日】2021-04-02
(31)【優先権主張番号】62/716,089
(32)【優先日】2018-08-08
(33)【優先権主張国・地域又は機関】US
(31)【優先権主張番号】62/804,992
(32)【優先日】2019-02-13
(33)【優先権主張国・地域又は機関】US
(73)【特許権者】
【識別番号】316012245
【氏名又は名称】アイディーエーシー ホールディングス インコーポレイテッド
(74)【代理人】
【識別番号】110001243
【氏名又は名称】弁理士法人谷・阿部特許事務所
(72)【発明者】
【氏名】イ、ムンイル
(72)【発明者】
【氏名】タヘルザデ ブルージョニ、マームード
(72)【発明者】
【氏名】ナイェブ ナザール、シャーロック
(72)【発明者】
【氏名】ステルンブロコビッチ、ジャネット エー．
【審査官】松野 吉宏
(56)【参考文献】
【文献】米国特許出願公開第２０１７／０１８８３９１（ＵＳ，Ａ１）
【文献】Guangdong OPPO Mobile Telecom，Transmit diversity scheme in eV2X，3GPP TSG RAN WG1 #90 R1-1713249，フランス，3GPP，2017年08月11日
【文献】WILUS Inc.，Discussion on HARQ Combining for UL transmission without grant，3GPP TSG RAN WG1 #90 R1-1714393，フランス，3GPP，2017年08月12日
(58)【調査した分野】(Int.Cl.，ＤＢ名)
Ｈ０４Ｂ ７／２４ － ７／２６
Ｈ０４Ｗ ４／００ － ９９／００
３ＧＰＰ ＴＳＧ ＲＡＮ ＷＧ１－４
ＳＡ ＷＧ１－４
ＣＴ ＷＧ１、４
(57)【特許請求の範囲】
【請求項1】
サイドリンク通信に対する無線送信／受信ユニット（ＷＴＲＵ）における使用のための方法であって、リソースプールアイデンティティ（ＩＤ）を受信するステップと、
物理サイドリンク共有チャネル（ＰＳＳＣＨ）送信に対する復調基準信号（ＤＭ－ＲＳ）密度に関連する情報をサイドリンク制御情報（ＳＣＩ）に含めるという判定に基づいて、ＤＭ－ＲＳ密度に関連する前記情報を含む前記ＳＣＩを送信するステップであって、前記判定は、前記リソースプールＩＤに基づいており、前記ＳＣＩは、ＰＳＳＣＨと関連付けられている、ステップと、
ＤＭ－ＲＳ密度に関連する前記情報に基づいて、第１のＤＭ－ＲＳ密度において前記ＰＳＳＣＨ上で１つまたは複数のＤＭ－ＲＳを有するＰＳＳＣＨ送信を送信するステップと
を備える方法。
【請求項2】
ＤＭ－ＲＳ密度に関連する前記情報は、前記１つまたは複数のＤＭ－ＲＳに対して使用されるシンボルの数を示す、請求項１の方法。
【請求項3】
ＤＭ－ＲＳ密度に関連する前記情報は、ＤＭ－ＲＳ密度インジケータフィールドを含む、請求項１の方法。
【請求項4】
前記ＷＴＲＵは、送信元ＷＴＲＵである、請求項１の方法。
【請求項5】
前記ＳＣＩは、無線リソース制御（ＲＲＣ）メッセージを介して送信される、請求項１の方法。
【請求項6】
ＤＭ－ＲＳ密度に関連する前記情報は、ＤＭ－ＲＳ時間密度に関連する情報を含む、請求項１の方法。
【請求項7】
ＤＭ－ＲＳ密度に関連する前記情報は、予め定められている、請求項１の方法。
【請求項8】
ハイブリッド自動再送要求（ＨＡＲＱ）が有効にされることを条件に、第２のＤＭ－ＲＳ密度を判定するステップをさらに備える、請求項１の方法。
【請求項9】
前記第２のＤＭ－ＲＳ密度は、ＨＡＲＱパラメータと関連付けられ、前記ＨＡＲＱパラメータは、冗長性バージョン番号、新たなデータインジケータ（ＮＤＩ）ビットトグル状態、ＨＡＲＱ再送信回数、またはＨＡＲＱプロセス番号、のうちの１つまたは複数を含む、請求項８の方法。
【請求項10】
前記第２のＤＭ－ＲＳ密度において１つまたは複数のＤＭ－ＲＳを有するＨＡＲＱ情報を送信するステップをさらに備え、前記ＨＡＲＱパラメータは、関連するＳＣＩにおいて受信される、請求項９の方法。
【請求項11】
サイドリンク通信に対する無線送信／受信ユニット（ＷＴＲＵ）であって、送受信機と、
前記送受信機に動作可能に結合されたプロセッサと、を備え、
前記送受信機は、リソースプールアイデンティティ（ＩＤ）を受信するように構成され、
物理サイドリンク共有チャネル（ＰＳＳＣＨ）送信に対する復調基準信号（ＤＭ－ＲＳ）密度に関連する情報をサイドリンク制御情報（ＳＣＩ）に含めるという判定に基づいて、前記プロセッサおよび前記送受信機は、ＤＭ－ＲＳ密度に関連する前記情報を含む前記ＳＣＩを送信するように構成され、前記判定は、前記リソースプールＩＤに基づいており、前記ＳＣＩは、ＰＳＳＣＨと関連付けられており、
前記プロセッサおよび前記送受信機は、ＤＭ－ＲＳ密度に関連する前記情報に基づいて、第１のＤＭ－ＲＳ密度において前記ＰＳＳＣＨ上で１つまたは複数のＤＭ－ＲＳを有するＰＳＳＣＨ送信を送信するように構成されている、
ＷＴＲＵ。
【請求項12】
ＤＭ－ＲＳ密度に関連する前記情報は、前記１つまたは複数のＤＭ－ＲＳに対して使用されるシンボルの数を示す、請求項１１のＷＴＲＵ。
【請求項13】
ＤＭ－ＲＳ密度に関連する前記情報は、ＤＭ－ＲＳ密度インジケータフィールドを含む、請求項１１のＷＴＲＵ。
【請求項14】
前記ＷＴＲＵは、送信元ＷＴＲＵである、請求項１１のＷＴＲＵ。
【請求項15】
前記ＳＣＩは、無線リソース制御（ＲＲＣ）メッセージを介して送信される、請求項１１のＷＴＲＵ。
【請求項16】
ＤＭ－ＲＳ密度に関連する前記情報は、ＤＭ－ＲＳ時間密度に関連する情報を含む、請求項１１のＷＴＲＵ。
【請求項17】
ＤＭ－ＲＳ密度に関連する前記情報は、予め定められている、請求項１１のＷＴＲＵ。
【請求項18】
ハイブリッド自動再送要求（ＨＡＲＱ）が有効にされることを条件に、前記プロセッサは、第２のＤＭ－ＲＳ密度を判定するようにさらに構成されている、請求項１１のＷＴＲＵ。
【請求項19】
前記第２のＤＭ－ＲＳ密度は、ＨＡＲＱパラメータと関連付けられ、前記ＨＡＲＱパラメータは、冗長性バージョン番号、新たなデータインジケータ（ＮＤＩ）ビットトグル状態、ＨＡＲＱ再送信回数、またはＨＡＲＱプロセス番号、のうちの１つまたは複数を含む、請求項１８のＷＴＲＵ。
【請求項20】
前記プロセッサおよび前記送受信機は、前記第２のＤＭ－ＲＳ密度において１つまたは複数のＤＭ－ＲＳを有するＨＡＲＱ情報を送信するようにさらに構成されており、前記ＨＡＲＱパラメータは、関連するＳＣＩにおいて受信される、請求項１９のＷＴＲＵ。
【発明の詳細な説明】
【技術分野】
【0001】
関連出願の相互参照
本出願は、参照によってその内容が本明細書に組み込まれる、２０１８年８月８日に出願された米国仮特許出願第６２／７１６，０８９号、および２０１９年２月１３日に出願された米国仮特許出願第６２／８０４，９９２号の利益を主張する。
本出願は、参照によってその内容が本明細書に組み込まれる、２０１８年８月８日に出願された米国仮特許出願第６２／７１６，０８９号、および２０１９年２月１３日に出願された米国仮特許出願第６２／８０４，９９２号の利益を主張する。
【背景技術】
【0002】
第３世代パートナシッププロジェクト（３ＧＰＰ）ニューラジオ（ＮＲ）無線通信では、Ｕｕインタフェースは、ｇＮｏｄｅＢ（ｇＮＢ）などの次世代ＮｏｄｅＢと１つまたは複数のユーザ機器（ＵＥ）または無線送信／受信ユニット（ＷＴＲＵ）との間の通信をサポートするように設計されることがある。ＮＲの設計は、ｇＮＢと１つまたは複数のＷＴＲＵとの間のデータ送信に基づいたいくつかのサービスをサポートすることができる。
【0003】
発展型パケットコア（ＥＰＣ）を使用するものを含む無線通信システムに対して、ビークルツーエブリシング（Ｖ２Ｘ）通信アーキテクチャが開発されてきた。Ｖ２Ｘ通信は、ビークルツービークル（Ｖ２Ｖ）通信、ビークルツーペデストリアン（Ｖ２Ｐ）通信、ビークルツーインフラストラクチャ（Ｖ２Ｉ）通信、およびビークルツーネットワーク（Ｖ２Ｎ）通信を含むことがある。
【0004】
しかしながら、デバイスツーデバイス（Ｄ２Ｄ）またはＶ２Ｘ通信に対して、ＰＣ５インタフェースを通じた通信などのＷＴＲＵツーＷＴＲＵ通信設計はＮＲにおいてサポートされてこなかった。３ＧＰＰロングタームエボリューション（ＬＴＥ）が公共の安全性のユースケース、Ｖ２Ｘのユースケース、またはその両方のユースケースに対してＷＴＲＵツーＷＴＲＵ通信をサポートしてきたが、ＬＴＥに基づくソリューションは、ＮＲネットワークにおいて互換性を有さないことがある。更に、車両隊列走行、拡張型センサ、進化型運転、および遠隔運転などのユースケースが導入されることがある。
【発明の概要】
【0005】
ニューラジオ（ＮＲ）における物理サイドリンク制御チャネル（ＰＳＣＣＨ）設計に対するデバイスおよび方法が開示される。実施例では、サイドリンク通信に対する送信元（source）無線送信／受信ユニット（ＷＴＲＵ）は、ハイブリッド自動再送要求（ＨＡＲＱ）フィードバックが有効にされるかどうかを判定してもよい。ＨＡＲＱフィードバックが有効にされることを条件に、送信元ＷＴＲＵは、ＨＡＲＱパラメータおよび関連付け情報に基づいて、サイドリンク送信に対する復調基準信号（ＤＭ－ＲＳ）密度を判定してもよい。更に、関連付け情報は、構成されたＤＭ－ＲＳ時間密度とＨＡＲＱパラメータとの間の関連付けに関する情報を含んでもよい。したがって、送信元ＷＴＲＵは、判定されたＤＭ－ＲＳ密度において、１つまたは複数のＤＭ－ＲＳを有するサイドリンク送信を送信してもよい。
【0006】
更なる実施例では、ＨＡＲＱフィードバックが無効にされることを条件に、送信元ＷＴＲＵは、ＤＭ－ＲＳ密度インジケータフィールドに基づいて、ＤＭ－ＲＳ密度を判定してもよい。その上、ＤＭ－ＲＳ密度インジケータフィールドは、関連するサイドリンク制御情報（ＳＣＩ）において送信元ＷＴＲＵによって受信されてもよい。
【0007】
別の実施例では、関連付け情報は、送信元ＷＴＲＵによって受信されてもよい。更に、関連付け情報は、無線リソース制御（ＲＲＣ）メッセージを介して受信されてもよい。加えて、関連付け情報は、関連するＳＣＩにおいて受信されてもよい。更なる実施例では、関連付け情報は、予め定められてもよい。
【0008】
追加の実施例では、ＨＡＲＱパラメータは、冗長性バージョン番号、新たなデータインジケータ（ＮＤＩ）ビットトグル状態（bit toggle status）、ＨＡＲＱ再送信回数、またはＨＡＲＱプロセス番号のうちの１つまたは複数を含んでもよい。ＨＡＲＱパラメータは、関連するＳＣＩにおいて受信されてもよい。
【0009】
図面内の同一の参照符号が同一の要素を示す、添付図面を例として併用された、以下の説明から取り詳細な理解を得ることができる。
【図面の簡単な説明】
【0010】
【図1A】１つまたは複数の開示される実施形態を実装することができる、例示的な通信システムを示すシステム図である。
【図2】範囲ごとの物理サイドリンク共有チャネル（ＰＳＣＣＨ）リソースプールおよびＰＳＣＣＨリソースを判定する手順を示す図である。
【図3】サイドリンクタイプに基づいた制御リソースセット（ＣＯＲＥＳＥＴ）構成の実施例を示す図である。
【図4】ＰＳＣＣＨブラインド復号に対する複数のＰＳＣＣＨリソースユニット（ＰＲＵ）セットの例を示す図である。
【図5】リソースプール構成に基づいてＰＳＣＣＨを送信するＷＴＲＵ手順の実施例を示すフローチャートである。
【図6】復調基準信号（ＤＭ－ＲＳ）タイプおよび密度の実施例を示す図である。
【図7】冗長性バージョン番号に基づいたＤＭ－ＲＳ密度判定の実施例を示す図である。
【図8】１つまたは複数のハイブリッド自動再送要求（ＨＡＲＱ）パラメータに基づいたＤＭ－ＲＳ密度判定の実施例を示すフローチャートである。
【図9】ＤＭ－ＲＳ密度インジケータフィールドに基づいたＤＭ－ＲＳ密度判定の実施例を示す図である。
【発明を実施するための形態】
【0011】
図１Ａは、１つまたは複数の開示される実施形態を実装することができる、例示的な通信システム１００を示す図である。通信システム１００は、音声、データ、ビデオ、メッセージング、放送などのコンテンツを複数の無線ユーザに提供する、多元接続システムであってもよい。通信システム１００は、複数の無線ユーザが、無線帯域幅を含むシステムリソースの共用を通じて、そのようなコンテンツにアクセスすることを可能にすることができる。例えば、通信システム１００は、符号分割多元接続（ＣＤＭＡ）、時分割多元接続（ＴＤＭＡ）、周波数分割多元接続（ＦＤＭＡ）、直交ＦＤＭＡ（ＯＦＤＭＡ）、シングルキャリアＦＤＭＡ（ＳＣ－ＦＤＭＡ）、ゼロテールユニークワード離散フーリエ変換拡散ＯＦＤＭ（ＺＴ ＵＷ ＤＴＳ－Ｓ－ＯＦＤＭ）、ユニークワードＯＦＤＭ（ＵＷ－ＯＦＤＭ）、リソースブロックフィルタードＯＦＤＭ、およびフィルタバンクマルチキャリア（ＦＢＭＣ）など、１つまたは複数のチャネルアクセス方法を利用してもよい。
【0012】
図１Ａに示されるように、通信システム１００は、無線送信／受信ユニット（ＷＴＲＵ）１０２ａ、１０２ｂ、１０２ｃ、１０２ｄと、ＲＡＮ１０４／１１３と、ＣＮ１０６と、公衆交換電話網（ＰＳＴＮ）１０８と、インターネット１１０と、他のネットワーク１１２とを含んでもよいが、開示される実施形態は、いずれかの数のＷＴＲＵ、基地局、ネットワーク、および／またはネットワーク要素を考慮していることが認識されよう。ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄの各々は、無線環境において動作および／または通信するように構成されたいずれかのタイプのデバイスであってもよい。例として、そのいずれかが、「局」および／または「ＳＴＡ」と称されてもよい、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄは、無線信号を送信および／または受信するように構成されてもよく、ユーザ機器（ＵＥ）、移動局、固定または移動加入者ユニット、サブスクリクションベースのユニット、ページャ、セルラ電話、パーソナルデジタルアシスタント（ＰＤＡ）、スマートフォン、ラップトップ、ネットブック、パーソナルコンピュータ、無線センサ、ホットスポットまたはＭｉ－Ｆｉデバイス、モノのインターネット（ＩｏＴ）デバイス、ウォッチまたは他のウェアラブル、ヘッドマウントディスプレイ（ＨＭＤ）、車両、ドローン、医療用デバイスおよびアプリケーション（例えば、遠隔手術）、工業用デバイスおよびアプリケーション（例えば、工業用および／または自動化された処理チェーン状況において動作するロボットおよび／または他の無線デバイス）、家電デバイス、ならびに商業用および／または工業用無線ネットワーク上において動作するデバイスなどを含んでもよい。ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄのいずれも、交換可能にＵＥと称されてもよい。
【0013】
通信システム１００はまた、基地局１１４ａおよび／または基地局１１４ｂを含んでもよい。基地局１１４ａ、１１４ｂの各々は、ＣＮ１０６、インターネット１１０、および／または他のネットワーク１１２など、１つまたは複数の通信ネットワークへのアクセスを容易にするために、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄのうちの少なくとも１つと無線でインタフェースをとるように構成されたいずれかのタイプのデバイスであってもよい。例として、基地局１１４ａ、１１４ｂは、基地送受信機局（ＢＴＳ）、ＮｏｄｅＢ、ｅＮｏｄｅＢ、ホームＮｏｄｅＢ、ホームｅＮｏｄｅＢ、ｇＮＢ、ＮＲ ＮｏｄｅＢ、サイトコントローラ、アクセスポイント（ＡＰ）、および無線ルータなどであってもよい。基地局１１４ａ、１１４ｂは、各々が、単一の要素として表されているが、基地局１１４ａ、１１４ｂは、任意の数の相互接続された基地局および／またはネットワーク要素を含んでもよいことが理解されよう。
【0014】
基地局１１４ａは、ＲＡＮ１０４／１１３の一部であってもよく、ＲＡＮ１０４／１１３は、他の基地局、および／または基地局コントローラ（ＢＳＣ）、無線ネットワークコントローラ（ＲＮＣ）、中継ノードなどのネットワーク要素（図示されず）も含んでもよい。基地局１１４ａおよび／または基地局１１４ｂは、セル（図示されず）と称されてもよい、１つまたは複数のキャリア周波数上において、無線信号を送信および／または受信するように構成されてもよい。これらの周波数は、認可スペクトル、非認可スペクトル、または認可スペクトルと非認可スペクトルとの組み合わせの中にあってもよい。セルは、相対的に固定であってもよくまたは時間とともに変化してもよい特定の地理的エリアに、無線サービス用のカバレージを提供してもよい。セルは、更に、セルセクタに分割されてもよい。例えば、基地局１１４ａと関連付けられたセルは、３個のセクタに分割されてもよい。したがって、一実施形態では、基地局１１４ａは、送受信機を３個、すなわち、セルの各セクタに対して１つずつ含んでよい。実施形態では、基地局１１４ａは、多入力多出力（ＭＩＭＯ）技術を利用してもよく、セルの各セクタに対して複数の送受信機を利用してもよい。例えば、所望の空間的方向において信号を送信および／または受信するために、ビームフォーミングが使用されてもよい。
【0015】
基地局１１４ａ、１１４ｂは、エアインタフェース１１６上において、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄのうちの１つまたは複数と通信してもよく、エアインタフェース１１６は、いずれかの適切な無線通信リンク（例えば、無線周波（ＲＦ）、マイクロ波、センチメートル波、マイクロメートル波、赤外線（ＩＲ）、紫外線（ＵＶ）、可視光など）であってもよい。エアインタフェース１１６は、任意の適切な無線アクセス技術（ＲＡＴ）を使用して確立されてもよい。
【0016】
より具体的には、上述されたように、通信システム１００は、多元接続システムであってもよく、ＣＤＭＡ、ＴＤＭＡ、ＦＤＭＡ、ＯＦＤＭＡ、およびＳＣ－ＦＤＭＡなど、１つまたは複数のチャネルアクセス方式を採用してもよい。例えば、ＲＡＮ１０４／１１３内の基地局１１４ａと、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃとは、広帯域ＣＤＭＡ（ＷＣＤＭＡ）を使用して、エアインタフェース１１６を確立してもよい、ユニバーサル移動体通信システム（ＵＭＴＳ）地上無線アクセス（ＵＴＲＡ）などの無線技術を実装してもよい。ＷＣＤＭＡは、高速パケットアクセス（ＨＳＰＡ）および／または進化型ＨＳＰＡ（ＨＳＰＡ＋）などの通信プロトコルを含んでよい。ＨＳＰＡは、高速ダウンリンク（ＤＬ）パケットアクセス（ＨＳＤＰＡ）、および／または高速アップリンク（ＵＬ）パケットアクセス（ＨＳＵＰＡ）を含んでもよい。
【0017】
実施形態では、基地局１１４ａ、およびＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃは、ロングタームエボリューション（ＬＴＥ）、および／またはＬＴＥアドバンスト（ＬＴＥ－Ａ）、および／またはＬＴＥアドバンストプロ（ＬＴＥ－Ａ Ｐｒｏ）を使用して、エアインタフェース１１６を確立してもよい、進化型ＵＭＴＳ地上無線アクセス（Ｅ－ＵＴＲＡ）などの無線技術を実装してもよい。
【0018】
実施形態では、基地局１１４ａ、およびＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃは、ＮＲを使用して、エアインタフェース１１６を確立してもよい、ＮＲ無線アクセスなどの無線技術を実装してもよい。
【0019】
実施形態では、基地局１１４ａ、およびＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃは、複数の無線アクセス技術を実装してもよい。例えば、基地局１１４ａ、およびＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃは、例えば、デュアルコネクティビティ（ＤＣ）原理を使用して、ＬＴＥ無線アクセスおよびＮＲ無線アクセスを共に実装してもよい。したがって、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃによって利用されるエアインタフェースは、複数のタイプの無線アクセス技術、ならびに／または複数のタイプの基地局（例えば、ｅＮＢおよびｇＮＢ）に送信される／そこから送信される送信
【0020】
他の実施形態では、基地局１１４ａ、およびＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃは、ＩＥＥＥ８０２．１１（すなわち、ワイヤレスフィデリティ（ＷｉＦｉ））、ＩＥＥＥ８０２．１６（すなわち、Ｗｏｒｌｄｗｉｄｅ Ｉｎｔｅｒｏｐｅｒａｂｉｌｉｔｙ ｆｏｒ Ｍｉｃｒｏｗａｖｅ Ａｃｃｅｓｓ（ＷｉＭＡＸ））、ＣＤＭＡ２０００、ＣＤＭＡ２０００ １Ｘ、ＣＤＭＡ２０００ ＥＶ－ＤＯ、暫定標準２０００（ＩＳ－２０００）、暫定標準９５（ＩＳ－９５）、暫定標準８５６（ＩＳ－８５６）、移動体通信用グローバルシステム（ＧＳＭ）、ＧＳＭエボリューション用高速データレート（ＥＤＧＥ）、およびＧＳＭ ＥＤＧＥ（ＧＥＲＡＮ）などの無線技術を実装してもよい。
【0021】
図１Ａにおける基地局１１４ｂは、例えば、無線ルータ、ホームＮｏｄｅＢ、ホームｅＮｏｄｅＢ、またはアクセスポイントであってもよく、事業所、自宅、車両、キャンパス、産業用施設、（例えば、ドローンによって使用される）エアコリド、および車道など、局所化されたエリアにおける無線接続性を容易にするために、任意の適切なＲＡＴを利用してもよい。一実施形態では、基地局１１４ｂと、ＷＴＲＵ１０２ｃ、１０２ｄとは、ＩＥＥＥ８０２．１１などの無線技術を実装して、無線ローカルエリアネットワーク（ＷＬＡＮ）を確立してもよい。実施形態では、基地局１１４ｂと、ＷＴＲＵ１０２ｃ、１０２ｄとは、ＩＥＥＥ８０２．１５などの無線技術を実装して、無線パーソナルエリアネットワーク（ＷＰＡＮ）を確立してもよい。また別の実施形態では、基地局１１４ｂと、ＷＴＲＵ１０２ｃ、１０２ｄとは、セルラベースのＲＡＴ（例えば、ＷＣＤＭＡ、ＣＤＭＡ２０００、ＧＳＭ、ＬＴＥ、ＬＴＥ－Ａ、ＬＴＥ－Ａ Ｐｒｏ、ＮＲなど）を利用して、ピコセルまたはフェムトセルを確立してもよい。図１Ａに示されるように、基地局１１４ｂは、インターネット１１０への直接的な接続を有してもよい。したがって、基地局１１４ｂは、ＣＮ１０６を介してインターネット１１０にアクセスする必要がないことがある。
【0022】
ＲＡＮ１０４／１１３は、ＣＮ１０６／１１５と通信してもよく、ＣＮ１０６／１１５は、音声、データ、アプリケーション、および／またはボイスオーバインターネットプロトコル（ＶｏＩＰ）サービスを、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄのうちの１つまたは複数に提供するように構成された任意のタイプのネットワークであってもよい。データは、異なるスループット要件、遅延要件、エラー耐性要件、信頼性要件、データスループット要件、およびモビリティ要件など、様々なサービス品質（ＱｏＳ）要件を有してもよい。ＣＮ１０６／１１５は、呼制御、ビリングサービス、モバイルロケーションベースのサービス、プリペイド発呼、インターネット接続性、ビデオ配信などを提供してもよく、および／またはユーザ認証など、高レベルセキュリティ機能を実行してもよい。図１Ａには示されていないが、ＲＡＮ１０４／１１３および／またはＣＮ１０６／１１５は、ＲＡＮ１０４／１１３と同じＲＡＴまたは異なるＲＡＴを利用する他のＲＡＮと直接的または間接的通信を行ってもよいことが理解されよう。例えば、ＮＲ無線技術を利用していることがあるＲＡＮ１０４／１１３に接続されていることに加えて、ＣＮ１０６／１１５は、ＧＳＭ、ＵＭＴＳ、ＣＤＭＡ２０００、ＷｉＭＡＸ、Ｅ－ＵＴＲＡ、またはＷｉＦｉ無線技術を利用する別のＲＡＮ（図示されず）とも通信してもよい。
【0023】
ＣＮ１０６／１１５は、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄが、ＰＳＴＮ１０８、インターネット１１０、および／または他のネットワーク１１２にアクセスするためのゲートウェイとしての役割も果たしてもよい。ＰＳＴＮ１０８は、基本電話サービス（ＰＯＴＳ）を提供する、回線交換電話網を含んでよい。インターネット１１０は、ＴＣＰ／ＩＰインターネットプロトコルスイート内の送信制御プロトコル（ＴＣＰ）、ユーザデータグラムプロトコル（ＵＤＰ）、および／またはインターネットプロトコル（ＩＰ）など、共通の通信プロトコルを使用する、相互接続されたコンピュータネットワークおよびデバイスからなる地球規模のシステムを含んでよい。ネットワーク１１２は、他のサービスプロバイダによって所有および／または運営される、有線および／または無線通信ネットワークを含んでもよい。例えば、ネットワーク１１２は、ＲＡＮ１０４／１１３と同じＲＡＴまたは異なるＲＡＴを利用してもよい１つまたは複数のＲＡＮに接続された、別のＣＮを含んでもよい。
【0024】
通信システム１００内のＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄのうちのいくつかまたは全ては、マルチモード機能を含んでよい（例えば、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃ、１０２ｄは、異なる無線リンク上において、異なる無線ネットワークと通信するための、複数の送受信機を含んでよい）。例えば、図１Ａに示されるＷＴＲＵ１０２ｃは、セルラベースの無線技術を採用してもよい基地局１１４ａと通信するように、またＩＥＥＥ８０２無線技術を利用してもよい基地局１１４ｂと通信するように構成されてもよい。
【0025】
図１Ｂは、例示的なＷＴＲＵ１０２を示すシステム図である。図１Ｂに示されるように、ＷＴＲＵ１０２は、とりわけ、プロセッサ１１８、送受信機１２０、送信／受信要素１２２、スピーカ／マイクロフォン１２４、キーパッド１２６、ディスプレイ／タッチパッド１２８、非リムーバブルメモリ１３０、リムーバブルメモリ１３２、電源１３４、全地球測位システム（ＧＰＳ）チップセット１３６、および／または他の周辺機器１３８を含んでよい。ＷＴＲＵ１０２は、実施形態との整合性を維持しながら、上記の要素の任意のサブコンビネーションを含んでよいことが理解されよう。
【0026】
プロセッサ１１８は、汎用プロセッサ、専用プロセッサ、従来型プロセッサ、デジタル信号プロセッサ（ＤＳＰ）、複数のマイクロプロセッサ、ＤＳＰコアと連携する１つまたは複数のマイクロプロセッサ、コントローラ、マイクロコントローラ、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）回路、他の任意のタイプの集積回路（ＩＣ）、および状態機械などであってもよい。プロセッサ１１８は、信号コーディング、データ処理、電力制御、入力／出力処理、および／またはＷＴＲＵ１０２が無線環境において動作することを可能にする他の任意の機能性を実行してもよい。プロセッサ１１８は、送受信機１２０に結合されてもよく、送受信機１２０は、送信／受信要素１２２に結合されてもよい。図１Ｂは、プロセッサ１１８と送受信機１２０を別個の構成要素として表しているが、プロセッサ１１８と送受信機１２０は、電子パッケージまたはチップ内に一緒に統合されてもよいことが理解されよう。
【0027】
送信／受信要素１２２は、エアインタフェース１１６上において、基地局（例えば、基地局１１４ａ）に信号を送信し、または基地局から信号を受信するように構成されてもよい。例えば、一実施形態では、送信／受信要素１２２は、ＲＦ信号を送信および／または受信するように構成されたアンテナであってもよい。実施形態では、送信／受信要素１２２は、例えば、ＩＲ、ＵＶ、または可視光信号を送信および／または受信するように構成された放射器／検出器であってもよい。また別の実施形態では、送信／受信要素１２２は、ＲＦ信号および光信号の両方を送信および／または受信するように構成されてもよい。送信／受信要素１２２は、無線信号の任意の組み合わせを送信および／または受信するように構成されてもよいことが理解されよう。
【0028】
図１Ｂにおいては、送信／受信要素１２２は、単一の要素として表されているが、ＷＴＲＵ１０２は、任意の数の送信／受信要素１２２を含んでよい。より具体的には、ＷＴＲＵ１０２は、ＭＩＭＯ技術を利用してもよい。したがって、一実施形態では、ＷＴＲＵ１０２は、エアインタフェース１１６上において無線信号を送信および受信するための２つ以上の送信／受信要素１２２（例えば、複数のアンテナ）を含んでよい。
【0029】
送受信機１２０は、送信／受信要素１２２によって送信されることになる信号を変調し、送信／受信要素１２２によって受信された信号を復調するように構成されてもよい。上で言及されたように、ＷＴＲＵ１０２は、マルチモード機能を有してもよい。したがって、送受信機１２０は、ＷＴＲＵ１０２が、例えば、ＮＲおよびＩＥＥＥ８０２．１１など、複数のＲＡＴを介して通信することを可能にするための、複数の送受信機を含んでよい。
【0030】
ＷＴＲＵ１０２のプロセッサ１１８は、スピーカ／マイクロフォン１２４、キーパッド１２６、および／またはディスプレイ／タッチパッド１２８（例えば、液晶表示（ＬＣＤ）ディスプレイユニットもしくは有機発光ダイオード（ＯＬＥＤ）ディスプレイユニット）に結合されてもよく、それらからユーザ入力データを受信してもよい。プロセッサ１１８は、スピーカ／マイクロフォン１２４、キーパッド１２６、および／またはディスプレイ／タッチパッド１２８にユーザデータを出力してもよい。加えて、プロセッサ１１８は、非リムーバブルメモリ１３０および／またはリムーバブルメモリ１３２など、任意のタイプの適切なメモリから情報を入手してもよく、それらにデータを記憶してもよい。非リムーバブルメモリ１３０は、ランダムアクセスメモリ（ＲＡＭ）、リードオンリメモリ（ＲＯＭ）、ハードディスク、または他の任意のタイプのメモリ記憶デバイスを含んでよい。リムーバブルメモリ１３２は、加入者識別モジュール（ＳＩＭ）カード、メモリスティック、およびセキュアデジタル（ＳＤ）メモリカードなどを含んでよい。他の実施形態では、プロセッサ１１８は、サーバまたはホームコンピュータ（図示されず）上などに配置された、ＷＴＲＵ１０２上に物理的に位置していないメモリから情報にアクセスしてもよく、それらにデータを記憶してもよい。
【0031】
プロセッサ１１８は、電源１３４から電力を受信してもよく、ＷＴＲＵ１０２内の他の構成要素に電力を分配するように、および／またはそれらへの電力を制御するように構成されてもよい。電源１３４は、ＷＴＲＵ１０２に給電するための任意の適切なデバイスであってもよい。例えば、電源１３４は、１つまたは複数の乾電池（例えば、ニッケル－カドミウム（ＮｉＣｄ）、ニッケル－亜鉛（ＮｉＺｎ）、ニッケル水素（ＮｉＭＨ）、リチウム－イオン（Ｌｉ－ｉｏｎ）など）、太陽電池、および燃料電池などを含んでよい。
【0032】
プロセッサ１１８は、ＧＰＳチップセット１３６にも結合されてもよく、ＧＰＳチップセット１３６は、ＷＴＲＵ１０２の現在の位置に関する位置情報（例えば、経度および緯度）を提供するように構成されてもよい。ＧＰＳチップセット１３６からの情報に加えて、またはそれの代わりに、ＷＴＲＵ１０２は、基地局（例えば、基地局１１４ａ、１１４ｂ）からエアインタフェース１１６上において位置情報を受信してもよく、および／または２つ以上の近くの基地局から受信されている信号のタイミングに基づいて、自身の位置を決定してもよい。ＷＴＲＵ１０２は、実施形態との整合性を維持しながら、任意の適切な位置決定方法を用いて、位置情報を取得してもよいことが理解されよう。
【0033】
プロセッサ１１８は、更に他の周辺機器１３８に結合されてもよく、他の周辺機器１３８は、追加の特徴、機能性、および／または有線もしくは無線接続性を提供する、１つまたは複数のソフトウェアモジュールおよび／またはハードウェアモジュールを含んでよい。例えば、周辺機器１３８は、加速度計、ｅコンパス、衛星送受信機、（写真および／またはビデオ用の）デジタルカメラ、ユニバーサルシリアルバス（ＵＳＢ）ポート、バイブレーションデバイス、テレビ送受信機、ハンズフリーヘッドセット、Ｂｌｕｅｔｏｏｔｈ（登録商標）モジュール、周波数変調（ＦＭ）ラジオユニット、デジタル音楽プレーヤ、メディアプレーヤ、ビデオゲームプレーヤモジュール、インターネットブラウザ、仮想現実および／または拡張現実（ＶＲ／ＡＲ）デバイス、ならびにアクティビティトラッカなどを含んでよい。周辺機器１３８は、１つまたは複数のセンサを含んでよく、センサは、ジャイロスコープ、加速度計、ホール効果センサ、磁力計、方位センサ、近接センサ、温度センサ、時間センサ、ジオロケーションセンサ、高度計、光センサ、タッチセンサ、磁力計、気圧計、ジェスチャセンサ、バイオメトリックセンサ、および／または湿度センサのうちの１つまたは複数であってもよい。
【0034】
ＷＴＲＵ１０２は、（例えば、（例えば、送信用の）ＵＬと（例えば、受信用の））ダウンリンクの両方のための特定のサブフレームと関連付けられた信号のいくつかまたは全ての送信および受信が、並列および／または同時であってもよい、全二重無線機を含んでよい。全二重無線機は、ハードウェア（例えば、チョーク）を介して、またはプロセッサ（例えば、別個のプロセッサ（図示されず）もしくはプロセッサ１１８）を介する信号処理を介して、自己干渉を低減させ、および／または実質的に除去するために、干渉管理ユニット１３９を含んでよい。実施形態では、ＷＴＲＵ１０２は、（例えば、（例えば、送信用の）ＵＬまたは（例えば、受信用の）ダウンリンクのどちらかのための特定のサブフレームと関連付けられた）信号のいくつかまたは全ての送信および受信のための、半二重無線を含んでよい。
【0035】
図１Ｃは、実施形態に従った、ＲＡＮ１０４およびＣＮ１０６を例示するシステム図である。上述されたように、ＲＡＮ１０４は、エアインタフェース１１６を通じてＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃと通信するためにＥ－ＵＴＲＡ無線技術を採用してもよい。ＲＡＮ１０４は、ＣＮ１０６とも通信してもよい。
【0036】
ＲＡＮ１０４は、ｅＮｏｄｅＢ１６０ａ、１６０ｂ、１６０ｃを含んでよいが、ＲＡＮ１０４は、実施形態との整合性を維持しながら、任意の数のｅＮｏｄｅＢを含んでよいことが理解されよう。ｅＮｏｄｅＢ１６０ａ、１６０ｂ、１６０ｃは、各々が、エアインタフェース１１６上においてＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃと通信するための、１つまたは複数の送受信機を含んでよい。一実施形態では、ｅＮｏｄｅＢ１６０ａ、１６０ｂ、１６０ｃは、ＭＩＭＯ技術を実装してもよい。したがって、ｅＮｏｄｅＢ１６０ａは、例えば、複数のアンテナを使用して、ＷＴＲＵ１０２ａに無線信号を送信し、および／またはＷＴＲＵ１０２ａから無線信号を受信してもよい。
【0037】
ｅＮｏｄｅＢ１６０ａ、１６０ｂ、１６０ｃの各々は、特定のセル（図示されず）と関連付けられてもよく、無線リソース管理決定、ハンドオーバ決定、ならびにＵＬおよび／またはＤＬにおけるユーザのスケジューリングなどを処理するように構成されてもよい。図１Ｃに示されるように、ｅＮｏｄｅＢ１６０ａ、１６０ｂ、１６０ｃは、Ｘ２インタフェース上において、相互に通信してもよい。
【0038】
図１Ｃに示されるＣＮ１０６は、モビリティ管理エンティティ（ＭＭＥ）１６２と、サービングゲートウェイ（ＳＧＷ）１６４と、パケットデータネットワーク（ＰＤＮ）ゲートウェイ（またはＰＧＷ）１６６とを含んでよい。上記の要素の各々は、ＣＮ１０６の部分として描かれているが、これらの要素のうちのいずれも、ＣＮオペレータとは異なるエンティティによって所有および／または運営されてもよいことが理解されよう。
【0039】
ＭＭＥ１６２は、Ｓ１インタフェースを介して、ＲＡＮ１０４内のｅＮｏｄｅＢ１６０ａ、１６０ｂ、１６０ｃの各々に接続されてもよく、制御ノードとしての役割を果たしてもよい。例えば、ＭＭＥ１６２は、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃのユーザを認証すること、ベアラアクティブ化／非アクティブ化、およびＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃの初期アタッチ中に特定のサービングゲートウェイを選択することなどを担ってもよい。ＭＭＥ１６２は、ＲＡＮ１０４と、ＧＳＭおよび／またはＷＣＤＭＡなどの他の無線技術を利用する他のＲＡＮ（図示されず）との間における交換のためのコントロールプレーン機能を提供してもよい。
【0040】
ＳＧＷ１６４は、Ｓ１インタフェースを介して、ＲＡＮ１０４内のｅＮｏｄｅＢ１６０ａ、１６０ｂ、１６０ｃの各々に接続されてもよい。ＳＧＷ１６４は、一般に、ユーザデータパケットを、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃに／ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃからルーティングおよび転送してもよい。ＳＧＷ１６４は、ｅＮｏｄｅＢ間ハンドオーバ中にユーザプレーンをアンカリングすること、ＤＬデータがＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃに利用可能なときにページングをトリガすること、ならびにＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃのコンテキストを管理および記憶することなど、他の機能を実行してもよい。
【0041】
ＳＧＷ１６４は、ＰＧＷ１６６に接続されてもよく、ＰＧＷ１６６は、インターネット１１０など、パケット交換ネットワークへのアクセスをＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃに提供して、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃとＩＰ対応デバイスとの間の通信を容易にしてもよい。
【0042】
ＣＮ１０６は、他のネットワークとの通信を容易にすることができる。例えば、ＣＮ１０６は、ＰＳＴＮ１０８など、回線交換ネットワークへのアクセスをＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃに提供して、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃと従来の固定電話回線通信デバイスとの間の通信を容易にしてもよい。例えば、ＣＮ１０６は、ＣＮ１０６とＰＳＴＮ１０８との間のインタフェースとしての役割を果たすＩＰゲートウェイ（例えば、ＩＰマルチメディアサブシステム（ＩＭＳ）サーバ）を含んでよく、またはそれと通信してもよい。加えて、ＣＮ１０６は、他のネットワーク１１２へのアクセスをＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃに提供してもよく、他のネットワーク１１２は、他のサービスプロバイダによって所有および／または運営される他の有線および／または無線ネットワークを含んでもよい。
【0043】
図１Ａ乃至１Ｄにおいては、ＷＴＲＵは、無線端末として説明されるが、ある代表的な実施形態では、そのような端末は、通信ネットワークとの有線通信インタフェースを（例えば、一時的または永続的に）使用することができることが企図されている。
【0044】
代表的な実施形態では、他のネットワーク１１２は、ＷＬＡＮであってもよい。
【0045】
インフラストラクチャ基本サービスセット（ＢＳＳ）モードにあるＷＬＡＮは、ＢＳＳのためのアクセスポイント（ＡＰ）と、ＡＰと関連付けられた１つまたは複数の局（ＳＴＡ）とを有してもよい。ＡＰは、トラフィックをＢＳＳ内および／またはＢＳＳ外に搬送する、ディストリビューションシステム（ＤＳ）または別のタイプの有線／無線ネットワークへのアクセスまたはインタフェースを有してもよい。ＢＳＳ外部から発信されたＳＴＡへのトラフィックは、ＡＰを通じて到着してもよく、ＳＴＡに配送されてもよい。ＳＴＡからＢＳＳ外部の送信先に発信されたトラフィックは、それぞれの送信先に配送するために、ＡＰに送信されてもよい。ＢＳＳ内のＳＴＡ間のトラフィックは、ＡＰを通じて送信されてもよく、例えば、送信元ＳＴＡは、トラフィックをＡＰに送信してもよく、ＡＰは、トラフィックを送信先ＳＴＡに配送してもよい。ＢＳＳ内のＳＴＡ間のトラフィックは、ピアツーピアトラフィックと見なされてもよく、および／またはピアツーピアトラフィックと呼ばれてもよい。ピアツーピアトラフィックは、直接リンクセットアップ（ＤＬＳ）を用いて、送信元ＳＴＡと送信先ＳＴＡとの間で（例えば、直接的に）送信されてもよい。ある代表的な実施形態では、ＤＬＳは、８０２．１１ｅ ＤＬＳまたは８０２．１１ｚトンネルＤＬＳ（ＴＤＬＳ）を使用してもよい。独立ＢＳＳ（ＩＢＳＳ）モードを使用するＷＬＡＮは、ＡＰを有さなくてもよく、ＩＢＳＳ内の、またはＩＢＳＳを使用するＳＴＡ（例えば、ＳＴＡの全て）は、相互に直接的に通信してもよい。ＩＢＳＳモードの通信は、本明細書においては、ときに「アドホック」モードの通信と称されてもよい。
【0046】
８０２．１１ａｃインフラストラクチャモードの動作または類似したモードの動作を使用するとき、ＡＰは、プライマリチャネルなどの固定されたチャネル上において、ビーコンを送信してもよい。プライマリチャネルは、固定された幅（例えば、２０メガヘルツ幅帯域幅）、またはシグナリングを介して動的に設定された幅であってもよい。プライマリチャネルは、ＢＳＳの動作チャネルであってもよく、ＡＰとの接続を確立するために、ＳＴＡによって使用されてもよい。ある代表的な実施形態では、例えば、８０２．１１システムにおいては、キャリアセンス多重アクセス／衝突回避（ＣＳＭＡ／ＣＡ）が、実装されてもよい。ＣＳＭＡ／ＣＡの場合、ＡＰを含むＳＴＡ（例えば、あらゆるＳＴＡ）は、プライマリチャネルをセンスしてもよい。プライマリチャネルが、センス／検出され、および／または特定のＳＴＡによってビジーであると決定された場合、特定のＳＴＡは、バックオフしてもよい。与えられたＢＳＳ内においては、いずれかの所与の時間に、１つのＳＴＡ（例えば、ただ１つの局）が、送信してもよい。
【0047】
高スループット（ＨＴ）ＳＴＡは、例えば、プライマリ２０メガヘルツチャネルを隣接または非隣接２０メガヘルツチャネルと組み合わせて、４０メガヘルツ幅のチャネルを形成することを介して、通信のために４０メガヘルツ幅チャネルを使用してもよい。
【0048】
超高スループット（ＶＨＴ）ＳＴＡは、２０メガヘルツ、４０メガヘルツ、８０メガヘルツ、および／または１６０メガヘルツ幅のチャネルをサポートすることができる。４０メガヘルツおよび／または８０メガヘルツチャネルは、連続する２０メガヘルツチャネルを組み合わせることによって形成されてもよい。１６０メガヘルツチャネルは、８つの連続する２０メガヘルツチャネルを組み合わせることによって形成されてもよく、または２つの非連続な８０メガヘルツチャネルを組み合わせることによって形成されてもよく、これは、８０＋８０構成と呼ばれてもよい。８０＋８０構成の場合、データは、チャネルエンコーディングの後、データを２つのストリームに分割し得るセグメントパーサを通過させられてもよい。各ストリームに対して別々に、逆高速フーリエ変換（ＩＦＦＴ）処理、および時間領域処理が、行われてもよい。ストリームは、２つの８０メガヘルツチャネル上にマッピングされてもよく、データは、送信ＳＴＡによって送信されてもよい。受信ＳＴＡの受信機においては、８０＋８０構成のための上で説明された動作が、逆転されてもよく、組み合わされたデータは、媒体アクセス制御（ＭＡＣ）に送信されてもよい。
【0049】
１ギガヘルツ未満モードの動作は、８０２．１１ａｆおよび８０２．１１ａｈによってサポートされる。チャネル動作帯域幅およびキャリアは、８０２．１１ｎおよび８０２．１１ａｃにおいて使用されるそれらと比べて、８０２．１１ａｆおよび８０２．１１ａｈにおいては低減させられる。８０２．１１ａｆは、ＴＶホワイトスペース（ＴＶＷＳ）スペクトルにおいて、５メガヘルツ、１０メガヘルツ、および２０メガヘルツ帯域幅をサポートし、８０２．１１ａｈは、非ＴＶＷＳスペクトルを使用して、１メガヘルツ、２メガヘルツ、４メガヘルツ、８メガヘルツ、および１６メガヘルツ帯域幅をサポートする。代表的な実施形態に従うと、８０２．１１ａｈは、マクロカバレージエリアにおけるＭＴＣデバイスなど、メータタイプ制御／マシンタイプコミュニケーションをサポートしてもよい。ＭＴＣデバイスは、一定の機能を、例えば、一定の帯域幅および／または限られた帯域幅のサポート（例えば、それらのサポートだけ）を含む限られた機能を有してもよい。ＭＴＣデバイスは、（例えば、非常に長いバッテリ寿命を維持するために）閾値を上回るバッテリ寿命を有するバッテリを含んでよい。
【0050】
８０２．１１ｎ、８０２．１１ａｃ、８０２．１１ａｆ、および８０２．１１ａｈなど、複数のチャネルおよびチャネル帯域幅をサポートすることができるＷＬＡＮシステムは、プライマリチャネルとして指定されてもよいチャネルを含む。プライマリチャネルは、ＢＳＳ内の全てのＳＴＡによってサポートされる最大の共通動作帯域幅に等しい帯域幅を有してもよい。プライマリチャネルの帯域幅は、ＢＳＳ内において動作する全てのＳＴＡの中の、最小帯域幅動作モードをサポートするＳＴＡによって設定および／または制限されてもよい。８０２．１１ａｈの例においては、ＢＳＳ内のＡＰおよび他のＳＴＡが、２メガヘルツ、４メガヘルツ、８メガヘルツ、１６メガヘルツ、および／または他のチャネル帯域幅動作モードをサポートする場合であっても、１メガヘルツモードをサポートする（例えば、それだけをサポートする）ＳＴＡ（例えば、ＭＴＣタイプデバイス）のために、プライマリチャネルは、１メガヘルツ幅であってもよい。キャリアセンシングおよび／またはネットワークアロケーションベクトル（ＮＡＶ）設定は、プライマリチャネルのステータスに依存してもよい。例えば、（１メガヘルツ動作モードだけをサポートする）ＳＴＡが、ＡＰに送信しているせいで、プライマリチャネルが、ビジーである場合、周波数バンドの大部分が、アイドルのままであり、利用可能であり得るとしても、利用可能な周波数バンド全体が、ビジーと見なされてもよい。
【0051】
米国では、８０２．１１ａｈによって使用されてもよい利用可能な周波数バンドは、９０２メガヘルツから９２８メガヘルツである。韓国においては、利用可能な周波数バンドは、９１７．５メガヘルツから９２３．５メガヘルツである。日本においては、利用可能な周波数バンドは、９１６．５メガヘルツから９２７．５メガヘルツである。８０２．１１ａｈのために利用可能な合計帯域幅は、国の規則に応じて、６メガヘルツから２６メガヘルツである。
【0052】
図１Ｄは、実施形態に従った、ＲＡＮ１０４およびＣＮ１０６を例示するシステム図である。上述されたように、ＲＡＮ１０４は、ＮＲ無線技術を利用して、エアインタフェース１１６上において、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃと通信してもよい。ＲＡＮ１０４は、ＣＮ１０６とも通信してもよい。
【0053】
ＲＡＮ１０４は、ｇＮＢ１８０ａ、１８０ｂ、１８０ｃを含んでよいが、ＲＡＮ１０４は、実施形態との整合性を維持しながら、任意の数のｇＮＢを含んでよいことが理解されよう。ｇＮＢ１８０ａ、１８０ｂ、１８０ｃは、各々が、エアインタフェース１１６上においてＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃと通信するための、１つまたは複数の送受信機を含んでよい。一実施形態では、ｇＮＢ１８０ａ、１８０ｂ、１８０ｃは、ＭＩＭＯ技術を実装してもよい。例えば、ｇＮＢ１８０ａ、１０８ｂは、ビームフォーミングを利用して、ｇＮＢ１８０ａ、１８０ｂ、１８０ｃに信号を送信し、および／またはｇＮＢ１８０ａ、１８０ｂ、１８０ｃから信号を受信してもよい。したがって、ｇＮＢ１８０ａは、例えば、複数のアンテナを使用して、ＷＴＲＵ１０２ａに無線信号を送信し、および／またはＷＴＲＵ１０２ａから無線信号を受信してもよい。実施形態では、ｇＮＢ１８０ａ、１８０ｂ、１８０ｃは、キャリアアグリゲーション技術を実装してもよい。例えば、ｇＮＢ１８０ａは、ＷＴＲＵ１０２ａに複数のコンポーネントキャリアを送信してもよい（図示されず）。これらのコンポーネントキャリアのサブセットは、免許不要スペクトル上にあってもよいが、残りのコンポーネントキャリアは、免許要スペクトル上にあってもよい。実施形態では、ｇＮＢ１８０ａ、１８０ｂ、１８０ｃは、多地点協調（ＣｏＭＰ）技術を実装してもよい。例えば、ＷＴＲＵ１０２ａは、ｇＮＢ１８０ａとｇＮＢ１８０ｂ（および／またはｇＮＢ１８０ｃ）とから調整された送信を受信してもよい。
【0054】
ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃは、スケーラブルなヌメロロジ（ｎｕｍｅｒｏｌｏｇｙ）と関連付けられた送信を使用して、ｇＮＢ１８０ａ、１８０ｂ、１８０ｃと通信してもよい。例えば、ＯＦＤＭシンボル間隔、および／またはＯＦＤＭサブキャリア間隔は、異なる送信、異なるセル、および／または無線送信スペクトルの異なる部分ごとに様々であってもよい。ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃは、（例えば、様々な数のＯＦＤＭシンボルを含む、および／または様々な長さの絶対時間だけ持続する）様々なまたはスケーラブルな長さのサブフレームまたは送信時間間隔（ＴＴＩ）を使用して、ｇＮＢ１８０ａ、１８０ｂ、１８０ｃと通信してもよい。
【0055】
ｇＮＢ１８０ａ、１８０ｂ、１８０ｃは、スタンドアロン構成および／または非スタンドアロン構成で、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃと通信するように構成されてもよい。スタンドアロン構成においては、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃは、（例えば、ｅＮｏｄｅＢ１６０ａ、１６０ｂ、１６０ｃなどの）他のＲＡＮにアクセスすることもなしに、ｇＮＢ１８０ａ、１８０ｂ、１８０ｃと通信してもよい。スタンドアロン構成においては、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃは、ｇＮＢ１８０ａ、１８０ｂ、１８０ｃのうちの１つまたは複数を、モビリティアンカポイントとして利用してもよい。スタンドアロン構成においては、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃは、免許不要バンド内において信号を使用して、ｇＮＢ１８０ａ、１８０ｂ、１８０ｃと通信してもよい。非スタンドアロン構成においては、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃは、ｅＮｏｄｅＢ１６０ａ、１６０ｂ、１６０ｃなどの別のＲＡＮとも通信し／別のＲＡＮにも接続しながら、ｇＮＢ１８０ａ、１８０ｂ、１８０ｃと通信し／ｇＮＢ１８０ａ、１８０ｂ、１８０ｃに接続してもよい。例えば、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃは、ＤＣ原理を実装して、１つまたは複数のｇＮＢ１８０ａ、１８０ｂ、１８０ｃ、および１つまたは複数のｅＮｏｄｅＢ１６０ａ、１６０ｂ、１６０ｃと実質的に同時に通信してもよい。非スタンドアロン構成においては、ｅＮｏｄｅＢ１６０ａ、１６０ｂ、１６０ｃは、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃのためのモビリティアンカとしての役割を果たしてもよく、ｇＮＢ１８０ａ、１８０ｂ、１８０ｃは、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃにサービスするための追加のカバレージおよび／またはスループットを提供することができる。
【0056】
ｇＮＢ１８０ａ、１８０ｂ、１８０ｃの各々は、特定のセル（図示されず）と関連付けられてもよく、無線リソース管理決定、ハンドオーバ決定、ＵＬおよび／またはＤＬにおけるユーザのスケジューリング、ネットワークスライシングのサポート、デュアルコネクティビティ、ＮＲとＥ－ＵＴＲＡとの間のインターワーキング、ユーザプレーンデータのユーザプレーン機能（ＵＰＦ）１８４ａ、１８４ｂへのルーティング、ならびにコントロールプレーン情報のアクセスおよびモビリティ管理機能（ＡＭＦ）１８２ａ、１８２ｂへのルーティングなどを処理するように構成されてもよい。図１Ｄに示されるように、ｇＮＢ１８０ａ、１８０ｂ、１８０ｃは、Ｘｎインタフェース上において、互いに通信してもよい。
【0057】
図１Ｄに示されるＣＮ１０６は、少なくとも１つのＡＭＦ１８２ａ、１８２ｂと、少なくとも１つのＵＰＦ１８４ａ、１８４ｂと、少なくとも１つのセッション管理機能（ＳＭＦ）１８３ａ、１８３ｂと、おそらくは、データネットワーク（ＤＮ）１８５ａ、１８５ｂとを含んでよい。上記の要素の各々は、ＣＮ１０６の部分として描かれているが、これらの要素のうちのいずれも、ＣＮオペレータとは異なるエンティティによって所有および／または運営されてもよいことが理解されよう。
【0058】
ＡＭＦ１８２ａ、１８２ｂは、Ｎ２インタフェースを介して、ＲＡＮ１０４内のｇＮＢ１８０ａ、１８０ｂ、１８０ｃのうちの１つまたは複数に接続されてもよく、制御ノードとしての役割を果たしてもよい。例えば、ＡＭＦ１８２ａ、１８２ｂは、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃのユーザを認証すること、ネットワークスライシングのサポート（例えば、異なる要件を有する異なるＰＤＵセッションの処理）、特定のＳＭＦ１８３ａ、１８３ｂを選択すること、レジストレーションエリアの管理、ＮＡＳシグナリングの終了、およびモビリティ管理などを担ってもよい。ネットワークスライシングは、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃによって利用されるサービスのタイプに基づいて、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃに対するＣＮサポートをカスタマイズするために、ＡＭＦ１８２ａ、１８２ｂによって使用されてもよい。例えば、超高信頼低遅延（ＵＲＬＬＣ）アクセスに依存するサービス、高速大容量モバイルブロードバンド（ｅＭＢＢ）アクセスに依存するサービス、および／またはマシンタイプコミュニケーション（ＭＴＣ）アクセスのためのサービスなど、異なる使用事例のために、異なるネットワークスライスが、確立されてもよい。ＡＭＦ１６２は、ＲＡＮ１０４と、ＬＴＥ、ＬＴＥ－Ａ、ＬＴＥ－Ａ Ｐｒｏ、および／またはＷｉＦｉなどの非３ＧＰＰアクセス技術など、他の無線技術を利用する他のＲＡＮ（図示されず）との間の交換のためのコントロールプレーン機能を提供してもよい。
【0059】
ＳＭＦ１８３ａ、１８３ｂは、Ｎ１１インタフェースを介して、ＣＮ１０６内のＡＭＦ１８２ａ、１８２ｂに接続されてもよい。ＳＭＦ１８３ａ、１８３ｂは、Ｎ４インタフェースを介して、ＣＮ１０６内のＵＰＦ１８４ａ、１８４ｂにも接続されてもよい。ＳＭＦ１８３ａ、１８３ｂは、ＵＰＦ１８４ａ、１８４ｂを選択および制御し、ＵＰＦ１８４ａ、１８４ｂを通じたトラフィックのルーティングを構成してもよい。ＳＭＦ１８３ａ、１８３ｂは、ＵＥ ＩＰアドレスの管理および割り当てを行うこと、ＰＤＵセッションを管理すること、ポリシ実施およびＱｏＳを制御すること、ならびにダウンリンクデータ通知を提供することなど、他の機能を実行してもよい。ＰＤＵセッションタイプは、ＩＰベース、非ＩＰベース、およびイーサネットベースなどであってもよい。
【0060】
ＵＰＦ１８４ａ、１８４ｂは、Ｎ３インタフェースを介して、ＲＡＮ１０４内のｇＮＢ１８０ａ、１８０ｂ、１８０ｃのうちの１つまたは複数に接続されてもよく、それらは、インターネット１１０など、パケット交換ネットワークへのアクセスをＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃに提供して、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃとＩＰ対応デバイスとの間の通信を容易にしてもよい。ＵＰＦ１８４ａ、１８４ｂは、パケットをルーティングおよび転送すること、ユーザプレーンポリシを実施すること、マルチホーミングＰＤＵセッションをサポートすること、ユーザプレーンＱｏＳを処理すること、ダウンリンクパケットをバッファすること、ならびにモビリティアンカリングを提供することなど、他の機能を実行してもよい。
【0061】
ＣＮ１０６は、他のネットワークとの通信を容易にすることができる。例えば、ＣＮ１０６は、ＣＮ１０６とＰＳＴＮ１０８との間のインタフェースとしての役割を果たすＩＰゲートウェイ（例えば、ＩＰマルチメディアサブシステム（ＩＭＳ）サーバ）を含んでよく、またはそれと通信してもよい。加えて、ＣＮ１０６は、他のネットワーク１１２へのアクセスをＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃに提供してもよく、他のネットワーク１１２は、他のサービスプロバイダによって所有および／または運営される他の有線および／または無線ネットワークを含んでよい。一実施形態では、ＷＴＲＵ１０２ａ、１０２ｂ、１０２ｃは、ＵＰＦ１８４ａ、１８４ｂへのＮ３インタフェース、およびＵＰＦ１８４ａ、１８４ｂとＤＮ１８５ａ、１８５ｂとの間のＮ６インタフェースを介して、ＵＰＦ１８４ａ、１８４ｂを通じて、ローカルデータネットワーク（ＤＮ）１８５ａ、１８５ｂに接続されてもよい。
【0062】
図１Ａ乃至図１Ｄ、および図１Ａ乃至図１Ｄについての対応する説明に鑑みて、ＷＴＲＵ１０２ａ乃至ｄ、基地局１１４ａ乃至ｂ、ｅＮｏｄｅＢ１６０ａ乃至ｃ、ＭＭＥ１６２、ＳＧＷ１６４、ＰＧＷ１６６、ｇＮＢ１８０ａ乃至ｃ、ＡＭＦ１８２ａ乃至ｂ、ＵＰＦ１８４ａ乃至ｂ、ＳＭＦ１８３ａ乃至ｂ、ＤＮ１８５ａ乃至ｂ、および／または本明細書において説明される他の任意のデバイスのうちの１つまたは複数に関する、本明細書において説明される機能の１つもしくは複数または全ては、１つまたは複数のエミュレーションデバイス（図示されず）によって実行されてもよい。エミュレーションデバイスは、本明細書において説明される機能の１つもしくは複数または全てをエミュレートするように構成された、１つまたは複数のデバイスであってもよい。例えば、エミュレーションデバイスは、他のデバイスをテストするために、ならびに／またはネットワークおよび／もしくはＷＴＲＵ機能をシミュレートするために、使用されてもよい。
【0063】
エミュレーションデバイスは、実験室環境において、および／またはオペレータネットワーク環境において、他のデバイスの１つまたは複数のテストを実施するように設計されてもよい。例えば、１つまたは複数のエミュレーションデバイスは、通信ネットワーク内の他のデバイスをテストするために、有線および／または無線通信ネットワークの一部として、完全または部分的に実施および／または展開されながら、１つもしくは複数または全ての機能を実行してもよい。１つまたは複数のエミュレーションデバイスは、有線および／または無線通信ネットワークの一部として、一時的に実施／展開されながら、１つもしくは複数または全ての機能を実行してもよい。エミュレーションデバイスは、テストの目的で、別のデバイスに直接的に結合されてもよく、および／またはオーバザエア無線通信を使用して、テストを実行してもよい。
【0064】
１つまたは複数のエミュレーションデバイスは、有線および／または無線通信ネットワークの一部として実施／展開されずに、全ての機能を含む、１つまたは複数の機能を実行してもよい。例えば、エミュレーションデバイスは、１つまたは複数の構成要素のテストを実施するために、テスト実験室、ならびに／または展開されていない（例えば、テスト）有線および／もしくは無線通信ネットワークにおける、テストシナリオにおいて利用されてもよい。１つまたは複数のエミュレーションデバイスは、テスト機器であってもよい。データを送信および／または受信するために、直接ＲＦ結合、および／または（例えば、１つもしくは複数のアンテナを含んでよい）ＲＦ回路を介した無線通信が、エミュレーションデバイスによって使用されてもよい。
【0065】
３ＧＰＰ ＮＲ無線通信では、ｇＮＢと１つまたは複数のＷＴＲＵとの間の通信をサポートするためにＵｕインタフェースが設計されることがある。ＮＲの設計は、ｇＮＢと１つまたは複数のＷＴＲＵとの間のデータ送信に基づいたいくつかのサービスをサポートすることができる。例えば、ＮＲにおけるリリース１５は、そのようなサービスをサポートすることができる。しかしながら、デバイスツーデバイス（Ｄ２Ｄ）通信またはビークルツーエブリシング（Ｖ２Ｘ）通信に対して、ＰＣ５インタフェースを通じた通信などのＷＴＲＵツーＷＴＲＵ通信がＮＲにおいてサポートされてこなかった。
【0066】
３ＧＰＰ ＬＴＥが公共の安全性のユースケース、Ｖ２Ｘのユースケース、またはその両方のユースケースに対してＷＴＲＵツーＷＴＲＵ通信をサポートしてきたが、ＬＴＥに基づくソリューションは、ＮＲネットワークにおいて互換性を有さないことがある。したがって、ＮＲフレーム構造およびチャネルに基づいたＰＣ５インタフェースが必要とされることがある。更に、車両隊列走行、拡張型センサ、進化型運転、および遠隔運転などのユースケースが導入されることがあり、Ｖ２Ｘ通信に対する追加の要件を伴うことがある。
【0067】
Ｄ２ＤおよびＶ２Ｘに対してＬＴＥサイドリンク通信をサポートすることができる。サイドリンク通信に対して使用される物理チャネルは、サイドリンクプライマリ同期信号（ＳＰＳＳ）、サイドリンクセカンダリ同期信号（ＳＳＳＳ）、物理サイドリンクブロードキャスティングチャネル（ＰＳＢＣＨ）、物理サイドリンク制御チャネル（ＰＳＣＣＨ）、物理サイドリンク共有チャネル（ＰＳＳＣＨ）、および物理サイドリンクディスカバリチャネル（ＰＳＤＣＨ）を含んでもよい。
【0068】
実施例では、サイドリンク通信は、最大で４個のモードをサポートすることができる。例えば、サイドリンク通信は、モード１乃至モード４を使用してもよい。実施例では、モード１およびモード２は、Ｄ２Ｄ通信に対して設計されてもよく、Ｄ２Ｄ通信は、遅延耐性を有し、相互のサイドリンク通信におけるデバイスの低移動性を伴うと共に、電力効率がよく、かつ信頼できる送信を必要とすることがある。モード１は、サイドリンク送信に対するｅＮＢのスケジューリングに基づいてもよく、サイドリンク送信に対するリソースは、ダウンリンク制御情報（ＤＣＩ）メッセージを介してｅＮＢによってスケジュールされてもよい。モード２は、リソースプール内でのＷＴＲＵの自律的なリソース選択に基づいてもよい。ＷＴＲＵがｅＮＢから制御信号を受信することが可能であることができるように、サイドリンク送信に対してＷＴＲＵがｅＮＢのカバレッジの下に位置するときにモード１が使用されてもよい。実施例では、サイドリンク送信に対して１つまたは複数のＷＴＲＵがｅＮＢのカバレッジ外にあるケースに対してモード２が使用されてもよく、カバレッジ内にあるケースに対してもモード２が使用されてもよい。
【0069】
モード１およびモード２と比較して、デバイスの高移動性と共に低待ち時間をサポートするために、Ｖ２Ｘ通信に対してモード３および４が導入されてもよい。実施例に従って、モード１および３では、サイドリンクＷＴＲＵは、サイドリンク送信に対してリソースグラントを受信してもよく、リソースグラントは、Ｕｕインタフェースに対して構成されたサーチスペース内で監視されてもよい。
【0070】
５Ｇ無線システムに対するＮＲでは、物理ダウンリンク制御チャネル（ＰＤＣＣＨ）と共に物理ダウンリンク共有チャネル（ＰＤＳＣＨ）に対して、新たな構造および設計が適合されてもよい。加えて、スロットに基づく送信およびスロットに基づかない送信、ならびにＰＤＣＣＨを監視する異なるレートが定義されてもよい。
【0071】
５Ｇ ＮＲでは、リソース要素グループ（ＲＥＧ）は、ＰＤＣＣＨに対する最小構築ブロック（building block）であってもよい。各々のＲＥＧは、時間において１つのＯＦＤＭシンボルに対して１２個のリソース要素（ＲＥ）、および周波数において１つのリソースブロック（ＲＢ）から構成されてもよい。各々のＲＥＧでは、９個のＲＥが制御情報に対して使用されてもよく、３個のＲＥが１つまたは複数の復調基準信号（ＤＭ－ＲＳ）に対して使用されてもよい。時間または周波数において隣接する複数のＲＥＧ（２、３、または６）は、同一のプリコーダにより使用することができるＲＥＧバンドル（bundle）を形成し、それらのＤＭ－ＲＳは、チャネル推定に対して共に使用されてもよい。６個のＲＥＧ（１、２、または３個のバンドルのフォーマットにある）は、ＰＤＣＣＨに対する最小のとり得るサイズである１つの制御チャネル要素（ＣＣＥ）を形成してもよい。各々のＰＤＣＣＨは、１つまたは複数のＣＣＥ、例えば、１、２、４、８、または１６個のＣＣＥを含んでもよく、ＰＤＣＣＨに対するＣＣＥの数は、その集約レベル（ＡＬ：aggregation level）と称されてもよい。
【0072】
ＲＥＧバンドル（REG bundle）のマッピングは、インタリーブするモードおよびインタリーブしないモードの２つの異なるモードを有してもよい。インタリーブしないマッピングでは、周波数において隣接する連続したＲＥＧバンドルは、ＣＣＥを形成してもよく、周波数において隣接するＣＣＥは、ＰＤＣＣＨを形成してもよい。インタリーブするマッピングでは、ＣＣＥにマッピングされる前に、ＲＥＧがインタリーブされてもよく、または置き換えられてもよく、全体的に１つのＣＣＥにおける隣接しないＲＥＧバンドルおよび１つのＰＤＣＣＨにおける隣接しないＣＣＥをもたらす。
【0073】
制御リソースセット（ＣＯＲＥＳＥＴ）は、例えば、それがインタリーブしているかまたはインタリーブしていないかに関わらず、６個のＲＢのチャンク（chunk）のようであってもよいその周波数割り当て、１乃至３個のＯＦＤＭシンボルあってもよい時間における長さ、ＲＥＧバンドルのタイプ、およびＲＥＧバンドルからＣＣＥへのマッピングのタイプによって構成されてもよい。各々の帯域幅部分（ＢＷＰ：bandwidth part）では、最大で３個のＣＯＲＥＳＥＴが存在してもよい。実施例では、全ての４個のとり得る帯域幅部分において１２個のＣＯＲＥＳＥＴが存在してもよい。
【0074】
各々のＷＴＲＵは、複数の集約レベルに対して、サーチスペースまたはサーチスペースのセットと称されることがある、ＰＤＣＣＨのブラインド検出の間に監視されることになるＰＤＣＣＨ候補のセットにより割り当てられてもよい。各々のサーチスペースのセットは、その関連付けられたＣＯＲＥＳＥＴ、各々の集約レベルを有する候補の数、および監視機会（monitoring occasion）によって構成されてもよい。監視機会は、スロットの単位にあってもよい監視周期、監視オフセット、および監視パターンによって判定されてもよい。例えば、監視パターンは、スロット内部のシンボルの全てのとり得るパターンに対応する１４ビットを含んでもよい。
【0075】
スロットフォーマットインジケータ（ＳＦＩ）は、例えば、スロットまたはスロットのセット内の１つまたは複数のシンボルの方向のインジケーション、例えば、動的インジケーションをもたらすことができる。方向は、ＵＬ、ＤＬ、または適応可能（flexible）な方向のうちの少なくとも１つであってもよい。ＳＦＩは、ＰＤＣＣＨにおいて設けられてもよい。例えば、スロットにおけるシンボル方向は、上位レイヤシグナリングによって構成されてもよい。ＳＦＩにおいて示される方向は、上位レイヤシグナリングによって構成された方向に優先してもよい（override）。
【0076】
ダウンリンクＵｕおよびサイドリンクの両方に対して、制御チャネルの信頼性の態様は、遮断する（blocking）の確率が低いことである。遮断することは、ＰＤＣＣＨまたはＰＳＣＣＨをスケジューリングするために構成されたリソースが利用可能でないときに発生することがある。リソースのプールを増大させることは、この遮断する確率を低減させることを支援することができる。しかしながら、Ｕｕトラフィックおよびサイドリンクトラフィックの両方に対して、トラフィックの確率論的な性質（stochastic nature）を理由に、それらの２つの用途の各々に対して即時に必要とされるリソースにおいて大きな変動が存在することがある。したがって、例えば、非常に低いの平均リソースの利用を理由に、各々の用途に対して別個のリソースを割り当てること、および各々の用途の最悪のケースのトラフィックに対してシステムを設計することは、システムのリソース効率を低減させる。実施例では、サイドリンクトラフィックは、最悪のケースのトラフィックシナリオに対して非常に十分なレベルのリソースが割り当てられた低い平均のリソース利用を有することがある。同様に、Ｕｕトラフィックは、高レベルのリソースが割り当てられた低い平均のリソース利用を有することがある。また、いくつかのケースでは、様々なユースケースの下に各々のチャネルに対する最悪のケースのトラフィックに対して、このタイプの別個の設計を有するために、十分に利用可能なリソースが存在しないことがある。
【0077】
いくつかのシナリオでは、制限されたＰＳＣＣＨリンク適合は、システムのリソース効率を低減させることがある。ＬＴＥ Ｖ２Ｘでは、リソースプールにおけるＰＳＣＣＨリソースは、サブフレームにおける２個のＲＢに固定されることがある。加えて、その変調次数も四位相偏移変調（ＱＰＳＫ）に固定されることがある。ＰＳＣＣＨ送信の範囲は、ＰＳＣＣＨ送信に対して割り当てられたＲＢの数、および使用される変調・コーディングスキーム（ＭＣＳ）レベルに基づいて判定されることがある。ＮＲ Ｖ２ＸがいくつかのＶ２Ｘのユースケースに対してＬＴＥにおいて使用されるよりも広い範囲、例えば、７５０メートルを必要とすることがあることを考えると、現在のＬＴＥの固定されたＰＳＣＣＨリンク適合は、ＮＲ Ｖ２Ｘに対して適切でないことがある。
【0078】
加えて、ＬＴＥ Ｖ２Ｘは、ブロードキャスト送信またはグループキャスト送信に対して設計されることがあり、したがって、最悪のケースのシナリオを目標とする固定されたリソース割り当てが合理的であることがある。しかしながら、ユニキャスト送信もサポートされる必要があることがあるので、ＮＲ Ｖ２Ｘに対してＰＳＣＣＨのリンク適合が必要とされることがある。
【0079】
いくつかのシナリオでは、サイドリンク通信に対する制限されたリソースは、システムのリソース効率を低減させることがある。ＮＲ Ｖ２Ｘでは、サイドリンク制御チャネルは、制御情報を搬送することが予測されることがあり、それは、広範囲の拡張型Ｖ２Ｘサービスをサポートすることにおけるペイロード、信頼性、待ち時間、および通信範囲の観点で大いに変動する。加えて、述べられたように、サイドリンク制御情報は、ブロードキャストおよびグループキャストに制限されることがあるＬＴＥ Ｖ２Ｘと比較して、ユニキャスト、マルチキャスト、およびブロードキャストとして送信されることが予測されることがある。ユニキャストのケースでは、送信を開始するＷＴＲＵは、高信頼性、リソース効率、またはその両方を達成するために、受信ＷＴＲＵ（receiving WTRU）からのフィードバックを必要とすることがある。したがって、１つまたは複数のサイドリンク制御チャネルを１つまたは複数のＵｕ制御チャネルと効率的に多重化する方法が望ましいことがある。サイドリンク通信におけるいずれかの方向において送信されるサイドリンク制御チャネルを効率的に多重化する技術も必要とされることがある。
【0080】
本明細書で開示される実施例に従って、ＰＳＣＣＨリンク適合は、サイドリンクに対するカバレッジレベルと関連付けられてもよい。カバレッジレベルは、Ｖ２Ｘ動作モード、無線リソース制御（ＲＲＣ）接続状態、および／もしくはダウンリンク測定レベルのうちの少なくとも１つに対応してもよく、またはそれらに基づいて判定されてもよい。実施例では、Ｖ２Ｘ動作モードは、被スケジュールモード（scheduled mode）または自律モードであってもよい。更に、動作モードは、ＷＴＲＵの動作モードであってもよい。実施例では、ＲＲＣ接続状態は、ＷＴＲＵの接続状態であってもよい。
【0081】
Ｖ２Ｘ動作モードでは、被スケジュールモードは、ＰＳＣＣＨ送信、ＰＳＳＣＨ送信、またはその両方に対してｇＮＢが１つまたは複数のリソースをスケジュールすることができる動作モードであってもよい。本明細書に記載されるように、被スケジュールモードは、本明細書で提供される、モード－１、ｇＮＢ被スケジュールモード、および／またはｇＮＢが２つのＷＴＲＵの間のサイドリンク送信に対してサイドリンクリソースをスケジュールすることができるモードと交換可能に使用されてもよく、それらとなおも一貫してもよい。自律モードは、ＰＳＣＣＨ送信、ＰＳＳＣＨ送信、またはその両方に対してＷＴＲＵが候補リソース内の１つまたは複数のリソースを自律的に判定することができる動作モードであってもよい。候補リソースが予め構成されてもよい。本明細書に記載されるように、自律モードは、本明細書で提供される、モード－２、ＷＴＲＵ被スケジュールモード、および／またはＷＴＲＵ（例えば、送信機ＷＴＲＵ（sender WTRU）、送信元ＷＴＲＵ、および送信元ＩＤを有するＷＴＲＵなど）が別のＷＴＲＵ（例えば、ａ受信機ＷＴＲＵ（receiver WTRU）、送信先ＷＴＲＵ（destination WTRU）、および送信先ＩＤを有するＷＴＲＵなど）にサイドリンク送信に対するサイドリンクリソースをスケジュールすることができるモードと交換可能に使用されてもよく、それらとなおも一貫してもよい。
【0082】
ＲＲＣ接続状態の実施例では、ＲＲＣ接続済み（RRC connected）、ＲＲＣ非活性（RRC inactive）、およびＲＲＣアイドル（RRC idle）は、第１のカバレッジとして考えられてもよく、非ＲＲＣ状態は、第２のカバレッジとして考えられてもよい。実施例では、第１のカバレッジは、ネットワーク内カバレッジであってもよく、第２のカバレッジは、ネットワーク外カバレッジであってもよい。
【0083】
実施例では、ダウンリンク測定レベルは、測定基準信号の基準信号受信電力（ＲＳＲＰ）測定レベルであってもよい。ダウンリンク測定レベルに対し、測定基準信号は、同期信号ブロック（ＳＳＢ）、チャネル状態情報基準信号（ＣＳＩ－ＲＳ）、トラッキング基準信号（ＴＲＳ）、またはＤＭ－ＲＳのうちの１つまたは複数を含んでもよい。
【0084】
用語「カバレッジレベル」、「カバレッジ」、「近接性」、「近接レベル」、「距離」、「距離レベル」、「範囲」、「範囲レベル」、および「測定品質」は、本明細書で交換可能に使用されてもよく、提供される実施例および実施形態となおも一貫してもよい。
【0085】
ＰＳＣＣＨ送信に対して１つまたは複数のＰＳＣＣＨリソースユニット（ＰＲＵ）が使用されてもよい。本明細書で提供される実施例では、ＰＳＣＣＨリンク適合は、１つまたは複数のＰＲＵに基づいてもよい。ＰＲＵは、ＰＤＣＣＨ、ＰＵＣＣＨリソース、スロット、および／またはサブフレームもしくは無線フレームに対して使用することができる、ＲＢ、シンボルの数、ＣＣＥ、ＲＥＧ、および／またはＲＥＧバンドルのうちの少なくとも１つであってもよく、それらのうちの少なくとも１つから構成されてもよく、ならびに／あるいはそれらのうちの少なくとも１つに基づいて定義されてもよく、判定されてもよく、または識別されてもよい。
【0086】
実施例では、ＲＢは、サブキャリアのセットを含んでもよい。実施例では、セットは、１２個のサブキャリアを含んでもよい。更に、サブキャリアは、連続または隣接してもよい。その上、サブキャリアのセットは、スロット、サブフレーム、または無線フレームなどの時間期間または時間単位内にあることができるシンボルの数を含んでもよい。
【0087】
シンボルの数は、アップリンクシンボルの数、ダウンリンクシンボルの数、ならびにスロットなどの時間期間または時間単位において構成され、判定され、および／または示される適応可能なシンボルの数のうちの少なくとも１つに基づいて判定されてもよい。シンボルの数は、例えば、１４に固定されてもよく、上位レイヤシグナリングを介して構成されてもよく、および／またはミニスロットがサイドリンク送信に対して使用される場合にミニスロットに対してシンボルの数と同一であってもよい。更に、用語「ミニスロット」は、サブスロット、非スロット、およびｘ－シンボルスロットなどと交換可能に使用されてもよく、本明細書で提供される実施例となおも一貫してもよい。
【0088】
ＣＣＥ、ＲＥＧ、またはＲＥＧバンドルは、例えば、サイドリンク送信に対してＰＤＣＣＨリソースのサブセットを使用することができるように、ＰＤＣＣＨに対して使用されてもよい。実施例では、ＰＤＣＣＨリソースのサブセットは、ＣＣＥ、ＲＥＧ、および／またはＲＥＧバンドルを含んでもよい。更に、実施例では、サイドリンク送信は、ＰＳＣＣＨ上にあってもよい。
【0089】
ＰＵＣＣＨリソースに対し、ＰＵＣＣＨリソースに対して使用されるＲＢの数は、上位レイヤシグナリングを介して構成されてもよく、またはカバレッジレベルに基づいて判定されてもよい。
【0090】
ＰＳＣＣＨ送信に対して１つまたは複数のリンク適合モードが使用されてもよい。リンク適合モードは、トラフィックタイプに基づいて判定されてもよい。１つまたは複数のトラフィックタイプが使用されてもよい。例えば、３個のトラフィックタイプが使用されてもよい。１つの実施例では、ブロードキャスト、グループキャスト、およびユニキャストトラフィックタイプが使用されてもよい。更に、ＷＴＲＵは、どのトラフィックタイプが使用されるかに基づいて、リンク適合モードを判定してもよい。
【0091】
固定リンク適合モードまたは準静的リンク適合モードが使用されてもよく、そのモードでは、ＰＲＵの数は、ｇＮＢによって予め定義されてもよく、構成されてもよく、または示されてもよい。実施例では、固定リンク適合モードまたは準静的リンク適合モードは、固定数もしくは準静的な数のＰＲＵ、および／または固定されたＭＣＳを伴ってもよい。トラフィックタイプに対して固定リンク適合モードまたは準静的リンク適合モードが使用されてもよい。実施例では、第１のトラフィックタイプに対してリンク適合モードが使用されてもよい。実施例では、第１のトラフィックタイプは、ブロードキャストトラフィックタイプであってもよい。
【0092】
適応可能なリンク適合モードが使用されてもよく、そのモードでは、ＰＲＵ集約レベルのセットは、例えば、ｇＮＢによって構成されてもよく、判定されてもよく、または示されてもよく、ＷＴＲＵは、例えば、ＰＳＣＣＨ送信に対してそのセットからＰＲＵ集約レベルを選択してもよい。トラフィックタイプに対して適応可能なリンク適合モードが使用されてもよい。実施例では、第２のトラフィックタイプに対してリンク適合モードが使用されてもよい。第２のトラフィックタイプは、ユニキャストトラフィックタイプおよび／またはグループキャストトラフィックタイプであってもよい。第１のＰＲＵ集約レベルは、第１の数のＰＲＵに対応してもよく、第２のＰＲＵ集約レベルは、第２の数のＰＲＵに対応してもよい、などである。第１の数のＰＲＵおよび第２の数のＰＲＵは、相互に異なってもよく、ＰＲＵ集約レベルの１つまたは複数のセットが使用されてもよい。
【0093】
実施例では、ＰＳＣＣＨ／ＰＳＳＣＨ送信に対するＰＲＵ集約レベルのサブセットは、ＰＳＳＣＨにおいて送信されることになるパケットのＱｏＳ、チャネルビジー比率（ＣＢＲ：channel busy ratio）範囲、サブチャネルごとのＲＢの数、ＰＳＣＣＨ／ＰＳＳＣＨ送信に対して選択されたサブチャネルの数、および最小の必要とされる通信範囲（minimum required communication range）のうちの少なくとも１つに基づいて判定されてもよい。更に、ＷＴＲＵは、判定されたサブセットからＰＲＵ集約レベルを選択してもよい。
【0094】
１つのまたは各々のトラフィックタイプは、ＰＳＣＣＨ送信に対してサイドリンク制御情報（ＳＣＩ）と関連付けられてもよい。第１のＳＣＩ、例えば、ＳＣＩフォーマットは、ブロードキャストトラフィックタイプおよび／またはグループキャストトラフィックタイプに対して使用されてもよく、第１のＳＣＩは、グループ送信先ＩＤ（group destination ID）を含んでもよい。第２のＳＣＩは、ユニキャストトラフィックタイプに対して使用されてもよく、第２のＳＣＩは、送信機ＷＴＲＵ－ＩＤまたは受信機ＷＴＲＵ－ＩＤであってもよいＷＴＲＵ－ＩＤを含んでもよい。
【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】
代わりにまたは加えて、ＷＴＲＵは、基準タイミング（reference timing）と送信先ＷＴＲＵが送信機ＷＴＲＵから信号を受信したタイミングとの間の時間差に基づいて、そのカバレッジレベルまたは距離レベルを報告してもよい。基準タイミングは、ｇＮＢからのＵｕ信号に基づいてもよい。例えば、カバレッジ内ＷＴＲＵは、ｇＮＢからの、Ｕｕ同期信号、例えば、ＳＳ／ＰＢＣＨブロック、またはＣＳＩ－ＲＳ、例えば、トラッキング基準信号に基づいて、基準タイミングを判定してもよい。代わりにまたは加えて、基準タイミングは、ＧＮＳＳに基づいてもよい。代わりにまたは加えて、基準タイミングは、ローカルマネージャから送信されたサイドリンク同期信号に基づいてもよく、ローカルマネージャは、他のＷＴＲＵとの間のサイドリンク送信に対してサイドリンクリソースをスケジュールすることができるＷＴＲＵであってもよい。
【0121】
ＰＳＣＣＨ送信に対して、１つまたは複数のＣＯＲＥＳＥＴ、および１つまたは複数のＣＯＲＥＳＥＴの関連するサーチスペース（複数可）が使用されてもよい。実施例では、ＰＳＣＣＨ送信に対して、１つまたは複数のＣＯＲＥＳＥＴの各々に対する関連するサーチスペースが使用されてもよい。
【0122】
実施例に従って、サイドリンクに対する１つの構成されたＣＯＲＥＳＥＴまたは各々の構成されたＣＯＲＥＳＥＴは、活性ＢＷＰ内の物理リソースブロック（ＰＲＢ）のサブセットと関連付けられてもよい。ＰＲＢのサブセットは、ＰＳＣＣＨ送信および／またはＰＳＳＣＨスケジューリングに対して使用されてもよい。例えば、ＷＴＲＵは、ＣＯＲＥＳＥＴと関連付けられてもよいＰＳＳＣＨをスケジュールするよう、ＣＯＲＥＳＥＴにおいてＳＣＩを送信してもよい。用語「ＰＲＢ」および「ＲＢ」は、交換可能に使用されてもよく、本明細書で提供される実施例および実施形態となおも一貫してもよい。
【0123】
ＰＳＣＣＨ送信に対する１つまたは複数のＣＯＲＥＳＥＴは、例えば、ＳＦＩによって、および／または上位レイヤシグナリングによって、アップリンクとして構成されたリソースにおいて送信または監視されてもよい。代わりにまたは加えて、ＰＲＢのサブセットは、ＣＯＲＥＳＥＴ構成の一部であってもよい。
【0124】
代わりにまたは加えて、ＰＲＢのサブセットは、黙示的に判定されてもよい。例えば、リソース利用を改善し、複数のＣＯＲＥＳＥＴからの衝突を回避するために、ＰＳＣＣＨに対するＣＯＲＥＳＥＴに対して構成されたＰＲＢの同一のセットが使用されてもよい。ＣＯＲＥＳＥＴおよびＰＳＳＣＨは、ＰＲＢの同一のセット内の時間ドメイン、例えば、同一のスロットまたは異なるスロットにおいて多重化されてもよい。ＰＲＢのサブセットは、ＰＳＣＣＨに対する関連するＣＯＲＥＳＥＴに対してＰＲＢ構成の関数であってもよい。例えば、ＰＳＳＣＨ送信に対して、ＣＯＲＥＳＥＴに対するＰＲＢおよびその隣接するＮ個のＰＲＢが使用されてもよい。
【0125】
代わりにまたは加えて、ＰＲＢのサブセットは、例えば、ＰＳＣＣＨ送信のスロット番号、サブフレーム番号、およびフレーム番号のうちの少なくとも１つに基づいて判定されてもよい。
【0126】
代わりにまたは加えて、ＰＲＢのサブセットは、スロットフォーマットに基づいて、例えば、ＰＳＣＣＨが送信されるスロットのスロットフォーマットに基づいて判定されてもよい。スロットフォーマットは、例えば、ダウンリンクシンボルの数、アップリンクシンボルの数、および適応可能なシンボルの数を含んでもよい。
【0127】
代わりにまたは加えて、ＰＲＢのサブセットは、例えば、ＰＳＣＣＨが送信されるスロットまたはシンボル内の、サイドリンクに対する利用可能なＲＥの数に基づいて判定されてもよい。特定の方向、例えば、ＤＬに対して割り当てられたＲＥは、利用可能なＲＥとしてカウントされなくてもよい。ＰＤＳＣＨミューティングもしくは物理アップリンク共有チャネル（ＰＵＳＣＨ）ミューティング、またはＰＤＳＣＨレートマッチングもしくはＰＵＳＣＨレートマッチングに対するＲＥは、利用可能なＲＥとしてカウントされなくてもよい。ブロードキャスト送信、例えば、ＳＳＢ、ＣＯＲＥＳＥＴ＃０に対するＲＥは、利用可能なＲＥとしてカウントされなくてもよく、および／または周期的送信、例えば、周期的ＣＳＩ－ＲＳ、ＴＲＳに対するＲＥは、利用可能なＲＥとしてカウントされなくてもよい。
【0128】
図３は、サイドリンクタイプに基づいたＣＯＲＥＳＥＴ構成の実施例を示す図である。実施例に従って、図３００に示す実施例にあるように、サイドリンクに対して構成された１つのＣＯＲＥＳＥＴまたは各々のＣＯＲＥＳＥＴは、サイドリンクタイプ、例えば、第１のサイドリンクタイプ、第２のサイドリンクタイプ、または第３のサイドリンクタイプに対して使用されてもよく、構成されてもよく、またはそれらと関連付けられてもよい。更なるサイドリンクタイプも構成されてもよい。実施例では、第１のサイドリンクタイプは、タイプ１サイドリンクであってもよく、このサイドリンクタイプに対するＣＯＲＥＳＥＴは、２つのＲＢ３１０と関連してもよい。更に、第２のサイドリンクタイプは、タイプ２サイドリンクであってもよく、このサイドリンクタイプに対するＣＯＲＥＳＥＴは、１つのＲＢ３２０と関連してもよい。その上、第３のサイドリンクタイプは、タイプ３サイドリンクであってもよく、このサイドリンクタイプに対するＣＯＲＥＳＥＴは、４個のＲＢ３３０と関連してもよい。
【0129】
サイドリンクタイプは、カバレッジレベル、相対速度、またはＤＭ－ＲＳ構成のうちの１つまたは複数に基づいて判定されてもよい。実施例では、カバレッジレベルは、範囲、近接性、距離、および測定レベルなどのうちの１つまたは複数を含んでもよい。更に、相対速度は、ドップラ周波数と関連付けられてもよい。また、ＤＭ－ＲＳ構成は、ＰＳＳＣＨ送信に対するＤＭ－ＲＳ構成であってもよい。実施例では、ＤＭ－ＲＳ構成は、１つのシンボルの前方にロードされたＤＭ－ＲＳ（1 symbol front-loaded DM-RS）およびＮ個の追加のＤＭ－ＲＳ（複数可）であってもよい。別の実施例では、ＤＭ－ＲＳ構成は、２つのシンボルの前方にロードされたＤＭ－ＲＳおよびＭ個の追加のＤＭ－ＲＳ（複数可）であってもよい。更なる実施例では、ＤＭ－ＲＳ構成は、スロット内のＤＭ－ＲＳ位置であってもよい。
【0130】
代わりにまたは加えて、サイドリンクタイプは、例えば、グループキャストもしくはブロードキャストに対して送信先ＩＤがグループＩＤであるかどうか、または例えば、ユニキャストに対して送信先ＩＤがＷＴＲＵ－ＩＤであるかどうかに基づいて判定することができるユースケースに基づいて判定されてもよい。
【0131】
代わりにまたは加えて、サイドリンクタイプは、検知スキーム（sensing scheme）に基づいて判定されてもよい。例えば、１つまたは複数の検知スキームが使用されてもよい。第１の検知スキームは、第１の時間ウインドウに基づいてもよく、第１の時間ウインドウの間、ＷＴＲＵは、ＣＯＲＥＳＥＴ内のＰＳＣＣＨリソースを判定するよう検知を実行する必要があることがある。別の実施例では、第２の検知スキームは、第２の時間ウインドウに基づいてもよく、第１の時間ウインドウおよび第２の時間ウインドウは、ｇＮＢによって、予め定義されてもよく、予め定められてもよく、または構成されてもよい。
【0132】
代わりにまたは加えて、サイドリンクタイプは、サイドリンク動作モードに基づいて判定されてもよい。更に、実施例では、サイドリンク動作モードは、被スケジュールモードまたは自律モードであってもよい。
【0133】
１つのＣＯＲＥＳＥＴまたは各々のＣＯＲＥＳＥＴは、ＰＳＳＣＨ送信に対するＰＲＢのセットもしくはサブセットと関連付けられてもよく、またはＰＳＳＣＨ送信に対するＰＲＢのセットもしくはサブセットに対して構成されてもよく、ＰＲＢのセットまたはサブセットは、ＣＯＲＥＳＥＴと関連付けられたサイドリンクタイプに基づいて判定されてもよい。例えば、ＰＳＣＣＨに対するＣＯＲＥＳＥＴに対して構成されたＰＲＢの同一のセットは、関連するＰＳＳＣＨ送信に対して使用されてもよく、第１のサイドリンクタイプに対して時間ドメインにおいて多重化されてもよく、ＰＲＢの構成されたセットは、第２のサイドリンクタイプに対する関連するＰＳＳＣＨ送信に対して使用されてもよい。実施例では、ＰＲＢは、スロット内のシンボルの異なるセットまたは異なるスロットにおいて時間ドメインにおいて多重化されてもよい。更に、実施例では、構成されたセットは、別個に構成されたセットであってもよい。
【0134】
１つまたは複数のＣＯＲＥＳＥＴは、サイドリンク送信に対して構成されてもよく、１つのＣＯＲＥＳＥＴまたは各々のＣＯＲＥＳＥＴは、ＣＯＲＥＳＥＴの最後のシンボルとＰＳＳＣＨの最初のシンボルとの間の時間オフセットにより構成されてもよい。実施例では、ＣＯＲＥＳＥＴ構成は、ＷＴＲＵに提供されてもよい。別の実施例では、ＣＯＲＥＳＥＴ構成は、ＷＴＲＵに既知であってもよい。ＷＴＲＵ、例えば、送信ＷＴＲＵ（transmitting WTRU）は、例えば、ＰＳＳＣＨ送信に対する関連する時間オフセットを別のＷＴＲＵ、例えば、受信ＷＴＲＵに示すために、構成されたＣＯＲＥＳＥＴの１つを判定および／または使用してもよい。
【0135】
実施例として、第１のＣＯＲＥＳＥＴは、ｎ＋ｋ１の時間オフセットにより構成されてもよく、第２のＣＯＲＥＳＥＴは、ｎ＋ｋ２の時間オフセットにより構成されてもよい。構成は、第１のＷＴＲＵおよび第２のＷＴＲＵに提供されてもよく、ならびに／または第１のＷＴＲＵおよび第２のＷＴＲＵに既知であってもよい。第１のＷＴＲＵ、例えば、送信ＷＴＲＵは、第１のＣＯＲＥＳＥＴにおいてＰＳＣＣＨを送信してもよい。第２のＷＴＲＵ、例えば、受信ＷＴＲＵは、ｎ＋ｋ１のタイミングによりＰＳＳＣＨを受信してもよい。ＳＣＩが時間オフセットインジケーションを含むとき、上位レイヤにより構成された時間オフセットは、ＳＣＩからの示された時間オフセットによって無効にされてもよい。
【0136】
代わりに、実施例に従って、ＰＳＳＣＨ送信／受信に対する時間オフセット値を判定するために、ＳＣＩタイプが使用されてもよい。例えば、１つまたは複数のＳＣＩタイプが使用されてもよく、判定されてもよく、または定義されてもよく、次いで、送信／受信されてもよい。次いで、送信／受信された１つまたは複数のＳＣＩタイプに基づいて、ＰＳＳＣＨに対する時間オフセットが判定されてもよい。
【0137】
ＳＣＩタイプは、サイドリンク動作モードに対するＳＣＩフォーマットに基づいて判定されてもよい。第１のＳＣＩフォーマット、例えば、ＳＣＩフォーマット０は、第１のサイドリンク動作モード、例えば、ｇＮＢ被スケジュールモードに対して使用されてもよい。更に、第２のＳＣＩフォーマット、例えば、ＳＣＩフォーマット１は、第２のサイドリンク動作モード、例えば、ＷＴＲＵ自律リソース選択に対して使用されてもよい。
【0138】
ＳＣＩタイプは、特定のＵｕリソースに対して使用されるＳＣＩフォーマットに基づいて判定されてもよい。例えば、第１のＳＣＩフォーマット、例えば、ＳＣＩフォーマット０は、Ｕｕインタフェースに対して構成された、アップリンクリソースおよび／または適応可能なリソースにおけるＰＳＣＣＨ送信および／またはＰＳＳＣＨ送信に対して使用されてもよい。更に、第２のＳＣＩフォーマット、例えば、ＳＣＩフォーマット１は、Ｕｕインタフェースに対して構成された、ダウンリンクリソースにおけるＰＳＣＣＨ送信および／またはＰＳＳＣＨ送信に対して使用されてもよい。
【0139】
ＳＣＩタイプは、関連するＰＳＣＣＨのトラフィックタイプに基づいて判定されてもよい。例えば、第１のＳＣＩタイプは、ブロードキャスト送信および／またはグループキャスト送信に対して使用されてもよく、第２のＳＣＩタイプは、ユニキャスト送信に対して使用されてもよく、その結果、ＳＣＩがブロードキャストまたはグループキャストに対して使用される場合、ＳＣＩは、グループ－送信先ＩＤを含むことができる。代わりにまたは加えて、ＳＣＩがユニキャストに対して使用される場合、ＳＣＩは、ＷＴＲＵ－ＩＤ、例えば、送信ＷＴＲＵアイデンティティおよび／または受信ＷＴＲＵアイデンティティを含むことができる。
【0140】
用語「ＳＣＩタイプ」および「サイドリンクタイプ」は、相互に交換可能に使用されてもよく、本明細書で提供される実施例および実施形態となおも一貫してもよい。
【0141】
実施例に従って、ｇＮＢは、サイドリンクに対して構成された１つまたは複数のＣＯＲＥＳＥＴを活性化／非活性化してもよい。例えば、第１のサイドリンクタイプ（例えば、ｇＮＢ被スケジュールモード）に対するＣＯＲＥＳＥＴに対し、ｇＮＢは、関連するＣＯＲＥＳＥＴを活性化してもよい。活性化情報は、サイドリンク送信に対してリソースグラント内にあってもよい。実施例では、第１のサイドリンクタイプは、２つのＲＢ３１０と関連付けられたＣＯＲＥＳＥＴに対するものであってもよい。
【0142】
サイドリンク送信に対するリソースグラントは、少なくともグループ共通ＰＤＣＣＨ、グループ共通サーチスペース、および／またはＷＴＲＵ特有サーチスペースにおいて監視されてもよい。
【0143】
１つまたは複数のグループ共通サーチスペースは、サイドリンク送信のグラントに対して構成されてもよい。各々のグループ共通サーチスペースは、サイドリンクタイプと関連付けられてもよい。グループ共通サーチスペースは、サーチスペース＃０であってもよい。グループ共通サーチスペースは、ＳＬ－ＲＮＴＩによりＤＣＩに対して構成されたサーチスペースであってもよい。
【0144】
ＷＴＲＵ特有サーチスペースに関して、ＷＴＲＵがサイドリンクリソースグラントに対してＤＣＩを監視するとき、サイドリンク送信がブロードキャストトラフィックまたはグループキャストトラフィックに対するものである場合、ＷＴＲＵは、グループ共通サーチスペースを監視してもよい。サイドリンク送信がユニキャストトラフィックに対するものである場合、ＷＴＲＵは、ＷＴＲＵ特有サーチスペースを監視してもよい。Ｃ－ＲＮＴＩまたは構成されたスケジューリング－ＲＮＴＩ（ＣＳ－ＲＮＴＩ）による専用のＷＴＲＵ特有サーチスペースは、サイドリンクリソースグラントに対して構成されてもよい。
【0145】
サイドリンクに対する１つまたは複数のＣＯＲＥＳＥＴまたはサーチスペースに対するｇＮＢの活性化信号の受信と、ＣＯＲＥＳＥＴまたはサーチスペースに対する活性ウインドウの開始時間との間で時間間隔が（time gap）使用されてもよい。時間間隔は、サイドリンクタイプ、サイドリンク送信に対して使用される波形、サブキャリア間隔、またはＷＴＲＵの能力のうちの少なくとも１つに基づいて判定されてもよい。
【0146】
活性化されたＣＯＲＥＳＥＴまたはサーチスペースは、ＷＴＲＵが非活性化信号を受信するまで活性のままであってもよい。ＷＴＲＵは、それらが活性であり、または活性化される間、ＣＯＲＥＳＥＴまたはサーチスペースを監視してもよい。
【0147】
サイドリンクに対する活性化されたＣＯＲＥＳＥＴまたはサーチスペースは、送信するサイドリンクデータが存在しないときに自律的に非活性化されてもよい。したがって、ＷＴＲＵは、サイドリンクデータ（例えば、全てのサイドリンクデータ）を受信することを終了するとき、活性ＣＯＲＥＳＥＴまたはサーチスペースを監視しなくてもよい。
【0148】
第１のＷＴＲＵは、第２のＷＴＲＵに、第１のＷＴＲＵの送信が完了したこと、および／または第２のＷＴＲＵが、少なくともある時間の間にサイドリンクに対して、活性化されたＣＯＲＥＳＥＴもしくはサーチスペースを監視する必要がないことがあることのインジケーションをシグナリングしてもよい。実施例では、第１のＷＴＲＵは、送信機ＷＴＲＵであってもよく、第２のＷＴＲＵは、受信機ＷＴＲＵであってもよい。
【0149】
更に、サイドリンク通信に対して、１つまたは複数のＣＯＲＥＳＥＴまたはサーチスペースを監視するための活性化信号は、ｇＮＢによって示されてもよいと共に、活性化されたＣＯＲＥＳＥＴまたはサーチスペースを監視するための非活性化信号は、ＷＴＲＵのグループ内の第１のＷＴＲＵなどのＷＴＲＵによって示されてもよい。実施例では、第１のＷＴＲＵは、送信機ＷＴＲＵであってもよい。
【0150】
活性化されたＣＯＲＥＳＥＴ（または、サーチスペース）は、タイマが満了するまで活性であってもよい。タイマ値は、予め定義されてもよく、または構成されてもよく、活性化信号が送信または受信される制御情報において示されてもよい。タイマが満了する前にＷＴＲＵがそのサイドリンク送信を終了することができないことがある場合、ＷＴＲＵは、タイマ延長を要求してもよい。
【0151】
活性化されたＣＯＲＥＳＥＴまたはサーチスペースは、カウンタが稼働している間に活性であってもよく、または活性のままであってもよい。カウンタは、各々のＰＳＣＣＨ監視機会（PSCCH monitoring occasion）において更新されてもよく、ＰＳＣＣＨ監視機会は、ＰＳＣＣＨ候補のセットが監視されるスロットまたはサブスロットであってもよい。実施例では、カウンタは、増加または減少させることによって更新されてもよい。カウンタは、ＷＴＲＵが、例えば、ｇＮＢから活性化信号またはインジケーションを受信するときに、例えば、ゼロまたは別の開始値にリセットされてもよい。カウンタは、例えば、カウンタを増加させるための最大であることができる停止値（stopping value）もしくは閾値、または、例えば、カウンタを減少させるため最小であることができる停止値もしくは閾値に到達するときに停止してもよい。停止値または閾値は、サイドリンクリソースに対して、構成されてもよく、予め定められてもよく、またはグラントにおいて示されてもよい。
【0152】
用語「ＣＯＲＥＳＥＴ」および「サーチスペース」は、交換可能に使用されてもよく、１つまたは複数の本明細書で提供される実施例となおも一貫してもよい。加えて、用語「ＣＯＲＥＳＥＴ」および「ＰＳＣＣＨリソースセット」は、交換可能に使用されてもよく、本明細書で提供される実施例となおも一貫してもよい。サーチスペースは、ＰＳＣＣＨ監視機会における１つまたは複数のＰＳＣＣＨ候補を含んでもよい。サイドリンクに対するサーチスペースは、サイドリンク送信に対して構成されたＣＯＲＥＳＥＴと関連付けられてもよい。１つまたは複数のサーチスペースは、サイドリンク送信に対して構成されてもよく、同一のＣＯＲＥＳＥＴまたは異なるＣＯＲＥＳＥＴと関連付けられてもよい。
【0153】
実施例に従って、未使用ＣＥが識別されてもよい。ＰＳＣＣＨブラインド復号に対して１つまたは複数のＰＲＵセットが使用されてもよく、ＰＲＵセットは、１つまたは複数のＲＢを含む。
【0154】
図４は、ＰＳＣＣＨブラインド復号に対する複数のＰＳＣＣＨリソースユニット（ＰＲＵ）セットの実施例を示す図である。図４００に示される実施例では、ＰＲＵ４１０は、１乃至１６と番号付けられてもよい。ＰＲＵセット－１は、ＰＲＵ１およびＰＲＵ２を含んでもよい。また、ＰＲＵセット－２は、ＰＲＵ１乃至ＰＲＵ４を含んでもよい。更に、ＰＲＵセット－３は、ＰＲＵ１乃至ＰＲＵ８を含んでもよく、ＰＲＵセット－４は、ＰＲＵ１乃至ＰＲＵ１６を含んでもよい。
【0155】
ＰＳＳＣＨをスケジュールすることができるＰＲＵのセットは、ＰＳＳＣＨ周波数リソース内に位置してもよい。例えば、ＰＳＳＣＨと関連付けられたＰＳＣＣＨは、関連するＰＳＳＣＨに対する周波数リソース内に位置してもよい。ＰＲＵのサブセットは、ＰＳＣＣＨに対して使用されてもよく、ＰＳＳＣＨ周波数リソース内のＣＣＥの残りは、他の信号送信に対して使用されてもよく、ＣＣＥのサブセットは、ＣＣＥ集約レベルと称されてもよい。例えば、他の信号は、関連するＰＳＳＣＨの一部、自動利得制御（ＡＧＣ）トレーニング信号、基準信号、例えば、ＤＭ－ＲＳもしくはＣＳＩ－ＲＳ、および／または負いブリッド自動再送要求確認応答（ＨＡＲＱ－ＡＣＫ）信号、例えば、物理サイドリンクフィードバックチャネル（ＰＳＦＣＨ）、のうちの少なくとも１つを含んでもよい。ＣＣＥのセットは、予め定められてもよく、または予め構成されてもよい。
【0156】
実施例に従って、ＰＳＣＣＨ送信に対して使用されるＰＲＵ（複数可）の数は、ＳＣＩにおいて示されてもよく、未使用ＰＲＵは、関連するＰＳＳＣＨ送信に対して使用されてもよい。例えば、ＳＣＩは、ＳＣＩ送信に対して使用されるＰＲＵの数に関連する情報を含んでもよい。ＳＣＩにおけるビットフィールドは、ＳＣＩ送信に対して使用されるＰＲＵの数を示してもよい。このビットフィールドは、ＰＳＣＣＨ送信の開始ＲＢ（starting RB）、ＰＳＣＣＨ送信の終了ＲＢ（ending RB）、またはＰＳＣＣＨ送信に対して使用されるＲＢの数、のうちの少なくとも１つと称されてもよい。代わりにまたは加えて、ＳＣＩ送信に対して使用されるＣＲＣに対するスクランブルＩＤ（scrambling id）および／またはスクランブルマスク（scrambling mask）は、使用されるＰＲＵの数を示してもよい。ＳＣＩのＣＲＣをスクランブルするために、１つまたは複数のアイデンティティが使用されてもよく、その結果、各々のアイデンティティをＰＲＵの数と関連付けることができる。更に、ＰＳＣＣＨ送信に対して使用されるＰＲＵの数を判定するために、関連するＰＳＳＣＨのＭＣＳレベルが使用されてもよい。例えば、関連するＰＳＳＣＨに対してより低いＭＣＳレベルが使用される場合、ＰＳＣＣＨ送信に対してより多い数のＰＲＵが使用されてもよく、関連するＰＳＳＣＨに対してより高いＭＣＳレベルが使用される場合、ＰＳＣＣＨ送信に対してより少ない数のＰＲＵが使用されてもよい。例えば、Ｎ１＜ＭＣＳレベル＜＝Ｎ２について、ＷＴＲＵは、ＰＳＣＣＨに対して第１の数のＰＲＵが使用されてもよいと判定してもよく、Ｎ２＜ＭＣＳレベル＜＝Ｎ３について、ＷＴＲＵは、ＰＳＣＣＨに対して第２の数のＰＲＵが使用されてもよいと判定してもよい、などである。ＰＳＣＣＨ送信に対して使用されるＰＲＵの数を判定するために、ＳＣＩフォーマットまたはＳＣＩフォーマットインジケータが使用されてもよい。
【0157】
実施例に従って、サイドリンク送信に対して、２つのタイプの波形が使用されてもよい。例えば、第１のタイプの波形は、サイドリンク送信に対するＯＦＤＭであってもよく、第２のタイプの波形は、サイドリンク送信に対するＤＦＴ－ｓ－ＯＦＤＭであってもよい。ＷＴＲＵ、例えば、送信ＷＴＲＵは、サイドリンク送信に対する範囲もしくはカバレッジ、ＰＳＳＣＨに対して判定されたＭＣＳレベル、ＰＳＣＣＨ、ＰＳＳＣＨ、もしくはその両方に対して判定された反復レベル、ＰＳＳＣＨに対する再送信数、送信電力レベル、例えば、最大送信電力からのオフセットレベル、ＭＩＭＯ関連スケジューリングパラメータ、例えば、送信ランク、サイドリンク送信に対してスケジュールされたＲＢの数、サイドリンクチャネルに対する相対速度、ＤＭ－ＲＳ密度、サイドリンクチャネル、ＳＣＩフォーマット、および／またはサブキャリア間隔、のうちの少なくとも１つに基づいて、ＰＳＣＣＨ送信および／またはＰＳＳＣＨ送信に対する波形を判定してもよい。
【0158】
ＷＴＲＵが送信電力レベルに基づいて波形を判定するために、例えば、送信電力レベルがピーク送信電力、例えば、Ｐｃ，ｍａｘからの或る範囲内にある場合、ＷＴＲＵは、サイドリンク送信に対する第２のタイプの波形を使用してもよい。そうでなければ、ＷＴＲＵは、サイドリンク送信に対して第１のタイプの波形を使用してもよい。
【0159】
ＷＴＲＵがサイドリンク送信に対してスケジュールされたＲＢの数に基づいて波形を判定するために、実施例では、スケジュールされたＲＢの数が閾値未満である場合、ＷＴＲＵは、サイドリンク送信に対して第１のタイプの波形を使用してもよい。そうでなければ、ＷＴＲＵは、サイドリンク送信に対して第２のタイプの波形を使用してもよい。
【0160】
ＷＴＲＵがサイドリンクチャネルに対する相対速度に基づいて波形を判定するために、例えば、相対速度が閾値よりも高いとき、ＷＴＲＵは、サイドリンク送信に対して第２のタイプの波形を使用してもよい。そうでなければ、サイドリンク送信に対して第１のタイプの波形が使用されてもよい。実施例では、相対速度は、それぞれが相互にサイドリンク通信しているデバイスの相互の速度であってもよい。相対速度は、ＤＭ－ＲＳ密度に基づいて判定されてもよい。例えば、より高いＤＭ－ＲＳ密度は、通信しているＷＴＲＵがより高い相対速度にあるときに使用が好ましいとして考えられてもよい。
【0161】
ＷＴＲＵがＤＭ－ＲＳ密度に基づいて波形を判定する実施例では、ＰＳＣＣＨおよび／またはＰＳＳＣＨに対して１つまたは複数のＤＭ－ＲＳ密度が使用されてもよく、ＤＭ－ＲＳ密度は、例えば、ＤＭ－ＲＳに対して使用されるスロット内のシンボルの数を少なくとも意味してもよく、またはシンボルの数に少なくとも対応してもよい。例えば、第１のタイプの波形は、最大でＤＭ－ＲＳシンボルの数、例えば、２つのＤＭ－ＲＳシンボルを有する密度に対して使用されてもよく、第２のタイプの波形は、ＤＭ－ＲＳシンボルの数、例えば、２つのＤＭ－ＲＳシンボルよりも多い密度に対して使用されてもよい。
【0162】
ＷＴＲＵがサイドリンクチャネル、例えば、第１のサイドリンク物理チャネルに基づいて波形を判定するために、例えば、第１のサイドリンク物理チャネル、例えば、ＰＳＣＣＨは、第１のタイプの波形、例えば、ＤＦＴ－ｓ－ＯＦＤＭに基づいてもよく、第２のサイドリンク物理チャネル、例えば、ＰＳＳＣＨは、第２のタイプの波形、例えば、ＯＦＤＭに基づいてもよい。代わりに、第１のサイドリンク物理チャネルは、第１のタイプの波形に基づいてもよく、第２のサイドリンク物理チャネルに対する波形は、第１のサイドリンク物理チャネルから示されてもよい。
【0163】
ＷＴＲＵがＳＣＩフォーマットに基づいて波形を判定するために、例えば、第１の波形は、サイドリンクチャネルの送信または受信が第１のＳＣＩフォーマットと関連付けられるときに使用されてもよく、第２の波形は、サイドリンクチャネルの送信または受信が第２のＳＣＩフォーマットと関連付けられるときに使用されてもよい。実施例では、第１のＳＣＩフォーマットは、フォーマット０であってもよい。更なる実施例では、第２のＳＣＩフォーマットは、フォーマット１であってもよい。
【0164】
ＰＳＣＣＨリソースプールでは、ＰＳＣＣＨリソースの第１のサブセットは、第１のタイプの波形に対して予約されてもよく、ＰＳＣＣＨリソースの第２のサブセット、例えば、ＰＳＣＣＨリソースの残りは、第２のタイプの波形に対して予約されてもよい。ＷＴＲＵ、例えば、送信ＷＴＲＵは、ＷＴＲＵがサイドリンク送信に対して使用すると判定し、または使用することを意図する波形に基づいて、送信に対するＰＳＣＣＨリソースを判定してもよい。更に、ｇＮＢは、どのＰＳＣＣＨリソース（複数可）がどのタイプの波形と関連付けられるかに関する構成情報メッセージを提供してもよい。異なるタイプの波形に対するＰＳＣＣＨリソースが時間で多重化されてもよい。
【0165】
同様の実施例では、ＰＳＣＣＨＰＳＳＣＨリソースプールでは、ＰＳＳＣＨリソースの第１のサブセットは、第１のタイプの波形に対して予約されてもよく、ＰＳＳＣＨリソースの第２のサブセット、例えば、ＰＳＳＣＨリソースの残りは、第２のタイプの波形に対して予約されてもよい。ＷＴＲＵ、例えば、送信ＷＴＲＵは、ＷＴＲＵがサイドリンク送信に対して使用すると判定し、または使用することを意図する波形に基づいて、送信に対するＰＳＳＣＨリソースを判定してもよい。その上、ｇＮＢは、どのＰＳＳＣＨリソース（複数可）がどのタイプの波形と関連付けられるかに関する構成情報を提供してもよい。異なるタイプの波形に対するＰＳＳＣＨリソースが時間で多重化されてもよい。
【0166】
実施例に従って、制御チャネルは、ＵｕとＰＣ５との間で共有されてもよい。一般的な事項として、リソースを使用する際の効率性を改善するために、アプローチは、ＵｕリンクとＰＣ５との間でリソースを共有することであってもよい。実施例に従って、アプローチは、サイドリンク（ＰＣ５）に対してダウンリンクリソースの一部を共有することであってもよい。
【0167】
ＵｕとＰＣ５との間でリソースを共有する実施例は、ＰＳＣＣＨおよびＰＤＣＣＨに対して割り当てられたリソースの一部を使用することによって実行されてもよい。ＰＤＣＣＨとＰＳＣＣＨとの間でリソースを共有することを促進するために、ＰＳＣＣＨに対して同一のＰＤＣＣＨ構造または類似の構造が使用されてもよい。
【0168】
この実施例に従って、ＰＳＣＣＨ、ＰＳＣＣＨリソース、ＰＳＣＣＨ候補、またはＰＳＣＣＨ復号候補のうちの少なくとも１つは、１つまたは複数のＣＣＥから構成されてもよく、ＣＣＥは、ＣＣＥのＮＲ ＰＤＣＣＨに基づいて構築されてもよい。
【0169】
サイドリンク制御チャネルリソースプールとも称されてもよい、サイドリンク制御チャネルに対して割り当てられたリソースの集合は、１つのＣＯＲＥＳＥＴとして、またはＰＤＣＣＨ ＣＯＲＥＳＥＴの一部として構成されてもよい。リソースプール内のＰＳＣＣＨ候補の中からの選択は、チャネル測定と共に準永続的スケジューリング（ＳＰＳ）などの機構を使用して、ＷＴＲＵによって自律的に実行されてもよく、または代わりに、選択は、例えば、構成された割り当ての動的適合など、準静的構成、動的スケジューリング、もしくは、その両方の混合を通じてｇＮＢによって実行されてもよい。
【0170】
ＰＳＣＣＨのサイズは、ｇＮＢによって構成可能であってもよく、全てのケースに対して固定されてもよく、ＳＣＩフォーマットに依存してもよく、または送信ＷＴＲＵによって選択されてもよい。ＰＳＣＣＨのサイズは、ＰＳＣＣＨまたはＰＳＣＣＨ候補を形成するＣＣＥの数によって計測されてもよい。
【0171】
以下で使用されるように、ＰＳＣＣＨ、ＰＳＣＣＨ候補、ＰＳＣＣＨ復号候補、ＰＳＣＣＨブラインド復号候補、およびＰＳＣＣＨリソースは、交換可能に使用されてもよく、本明細書で提供される実施例となおも一貫してもよい。加えて、サイドリンク送信ＷＴＲＵ、送信ＷＴＲＵ、送信機ＷＴＲＵ、サイドリンクＴｘ ＷＴＲＵ、Ｔｘ ＷＴＲＵ、および第１のＷＴＲＵは、交換可能に使用されてもよく、本明細書で提供される実施例となおも一貫してもよい。サイドリンク受信ＷＴＲＵ、受信ＷＴＲＵ、サイドリンクＲｘ ＷＴＲＵ、Ｒｘ ＷＴＲＵ、受信側ＷＴＲＵ（recipient WTRU）、および第２のＷＴＲＵは、交換可能に使用されてもよく、本明細書で提供される実施例となおも一貫してもよい。
【0172】
実施例に従って、ＷＴＲＵは、ＳＣＩフォーマットに基づいて、ＰＳＣＣＨのサイズを判定してもよく、またはＰＳＣＣＨのサイズを最小のサブセットに制限してもよい。例えば、ＳＣＩフォーマット１と関連付けられたＰＳＣＣＨ（複数可）の全ては、４個のＣＣＥのサイズを有してもよい。別の実施例では、ＳＣＩフォーマット１は、｛４，８｝の集約レベルと関連付けられてもよく、ＳＣＩフォーマット２は、｛８，１６｝の集約レベルと関連付けられてもよい。
【0173】
別の実施例に従って、割り当てられたリソースプール内のＰＳＣＣＨ候補は、異なるサイズまたは集約レベルを有してもよく、サイドリンク送信ＷＴＲＵは、目標ＳＮＲを達成するために、チャネル測定およびリンク適合に基づいて、どの集約レベルが使用されることになるかを決定してもよい。
【0174】
別の実施例に従って、ＷＴＲＵは、他のＷＴＲＵからのトラフィックの測定および最良の衝突回避の基準に基づいて、集約レベルを選択してもよい。ＷＴＲＵがＰＳＣＣＨ集約レベルを選択するとき、ＰＳＣＣＨにおける利用可能なリソース要素の数と共に、ＳＣＩサイズおよびレートマッチングに基づいて、コーディングレートを選択してもよい。
【0175】
ＰＳＣＣＨのＣＣＥは、構成されたＣＯＲＥＳＥＴの中で連続してもよく、および／または周波数において隣接してもよい。別の実施例に従って、ＰＳＣＣＨのＣＣＥの論理インデックスは、連続してもよいが、それらの物理的な位置は、隣接しなくてもよい。ＰＳＣＣＨに対する隣接するＣＣＥまたは隣接しないＣＣＥの間の選択は、ＣＯＲＥＳＥＴにおけるＣＣＥへのＲＥＧバンドルのインタリーブされていないマッピングまたはインタリーブされたマッピングの選択によって黙示的に構成されてもよい。
【0176】
別の実施例に従って、ＰＳＣＣＨ送信に対して、構成されたＰＤＣＣＨ候補のセットまたはサブセットが許容されてもよく、許可されてもよく、または使用されてもよい。例えば、サーチスペース内のＰＤＣＣＨ候補のサブセットは、ＰＤＣＣＨとＰＳＣＣＨとの間で共有されてもよく、ＤＣＩサイズおよびＳＣＩサイズは、調整されてもよい。ＰＤＣＣＨ候補のサブセットでは、ＷＴＲＵは、Ｃ－ＲＮＴＩを有するＤＣＩおよびＳＬ－ＲＮＴＩを有するＳＣＩを監視してもよい。ＤＣＩおよびＳＣＩの１つがより大きなペイロードサイズを有する場合、他の制御情報がゼロパディングされてもよい。送信ＷＴＲＵは、サイドリンク送信に対して受信ＷＴＲＵのＰＤＣＣＨ候補のサブセットに関連する情報を受信してもよい。
【0177】
ＰＳＣＣＨリソースは、ＣＯＲＥＳＥＴおよびリソースプールを通じて構成されてもよい。実施例では、ＰＳＣＣＨに対するリソースのプールは、セル内の全てのサイドリンクユーザに対し、それらのグループに対し、またはそれらの各々に対し、準静的に構成されてもよく、動的にスケジュールされてもよく、またはそれらの２つのアプローチの混合によって割り当てられてもよい。
【0178】
実施例に従って、サイドリンク制御チャネルに対するリソースのプールは、Ｕｕのダウンリンク制御チャネル、例えば、ＰＤＣＣＨに対して既に構成されているＣＯＲＥＳＥＴの１つと関連付けられた共通サーチスペースとして構成されてもよい。サイドリンクリソースプールに対するサーチスペース構成は、監視機会、ＰＳＣＣＨ候補の数およびそれらのサイズ（または、集約レベル）、ならびに関連するＳＣＩフォーマット（複数可）を含んでもよい。実施例では、監視機会は、監視周期性、監視オフセット、およびスロット内の監視パターンを含んでもよい。別のソリューションでは、それらのパラメータの一部は、他の構成されたパラメータから黙示的に識別されてもよい。例えば、ＰＳＣＣＨ候補のサイズは、ＰＳＣＣＨリソースプールに対して構成されたＳＣＩフォーマットに基づいて黙示的に取得されてもよい。例えば、構成されたＳＣＩフォーマットがフォーマット１である場合、４の集約レベルが取得されてもよい。
【0179】
別の実施例に従って、ＰＳＣＣＨに対する構成されたＣＯＲＥＳＥＴの一部は、周波数割り当てによって割り当てられてもよい。ＰＳＣＣＨに対するこの周波数割り当ては、ＣＯＲＥＳＥＴの構成の間に行われてもよい。この実施例に従って、ＣＯＲＥＳＥＴは、周波数割り当ての２つのセットによって構成されてもよい。このケースでは、第１のセットは、Ｕｕダウンリンク制御チャネルに対するリソースを示してもよく、第２のセットは、サイドリンク制御チャネルに対するリソースプールを示してもよい。第１のセットおよび第２のセットは、分断（disjointed）されてもよく、または重複してもよい。１つの実施例では、第２のセットは、第１のセットのサブセットであってもよい。２つのセットの間で重複するケースでは、ｇＮｏｄｅＢは、ＣＯＲＥＳＥＴ０において送信されるグループ共通ＰＤＣＣＨなどの機構によって動的に、それらの重複したリソースの利用可能性または反対のものを示してもよい。それらの重複したリソースの利用可能性は、例えば、Ｕｕダウンリンク制御が存在しないことを伴ってもよく、反対のものは、例えば、Ｕｕダウンリンク制御が存在することを伴ってもよい。この実施例の別の変形例では、ＣＯＲＥＳＥＴは、１つの周波数割り当てによってではあるが、ＣＣＥの２つの範囲により構成されてもよい。更なる実施例では、ＣＣＥの１つの範囲は、ＰＤＣＣＨと関連付けられてもよく、ＣＣＥの別の範囲は、ＰＳＣＣＨと関連付けられてもよい。この方法では、ＰＳＣＣＨ候補のサイズは、固定された値Ｌまたは固定された値のセット｛Ｌi｝（ＳＣＩフォーマットに基づいた）であってもよい。また、各々のＰＳＣＣＨ候補は、リソースプール内のＬi個の重複しない連続したＣＣＥと関連付けられてもよい。例えば、構成されたＣＯＲＥＳＥＴにおけるＣＣＥ１、…、１６がＰＳＣＣＨと関連付けられ、ＰＳＣＣＨサイズのセットが｛４，８｝である場合、ＰＳＣＣＨ候補は、｛１，２，３，４｝、｛５，６，７，８｝、｛９，１０，１１，１２｝、｛１３，１４，１５，１６｝、｛１，２，３，４，５，６，７，８｝、｛９，１０，１１，１２，１３，１４，１５，１６｝であってもよい。
【0180】
図５は、リソースプール構成に基づいてＰＳＣＣＨを送信するＷＴＲＵ手順の実施例を示すフローチャートである。フローチャート５００に示されるように、ＷＴＲＵの手順は、自律ＰＳＣＣＨスケジューリングのケースを含んでもよい。実施例では、ＷＴＲＵは、手順を開始してもよく（５０５）、ＰＳＣＣＨに対するＣＣＥ範囲を含むＣＯＲＥＳＥＴ構成および関連するＳＣＩフォーマットを受信してもよい（５１０）。ＷＴＲＵは次いで、受信された関連するＳＣＩフォーマットがＳＣＩフォーマット１であるかどうかを判定してもよい（５２０）。
【0181】
ＷＴＲＵが、ＳＣＩフォーマット１を受信したと判定する場合、ＷＴＲＵは次いで、ＣＣＥ範囲およびＳＣＩフォーマット１に対するＡＬに基づいて、ＰＳＣＣＨ候補を識別してもよい（５２５）。ＷＴＲＵは次いで、測定に基づいて、ＰＳＣＣＨ候補を選択してもよい（５３５）。実施例では、ＷＴＲＵは、衝突の可能性を最小にするのに最良であることができるＰＳＣＣＨ候補を選択してもよい。更に、ＷＴＲＵは、ＳＣＩフォーマット１に基づいたコーディングレートによりＰＳＣＣＨを送信してもよい（５４５）。
【0182】
ＷＴＲＵが、ＳＣＩフォーマット１を受信していないと判定する場合、ＷＴＲＵは次いで、チャネル測定およびリンク適合に基づいて、ＰＳＣＣＨサイズを選択してもよい（５３０）。更に、ＷＴＲＵは次いで、ＣＣＥ範囲および選択されたＰＳＣＣＨサイズに基づいて、ＰＳＣＣＨ候補を識別してもよい（５４０）。また、ＷＴＲＵは、測定に基づいて、ＰＳＣＣＨ候補を選択してもよい（５５０）。実施例では、ＷＴＲＵは、衝突の可能性を最小にするのに最良であることができるＰＳＣＣＨ候補を選択してもよい。更に、ＷＴＲＵは、ＳＣＩサイズおよび選択されたＰＳＣＣＨサイズに基づいたコーディングレートによりＰＳＣＣＨを送信してもよい（５６０）。
【0183】
実施例では、リソースサブセット判定は、ＷＴＲＵ－ＩＤに基づいてもよい。実施例に従って、サイドリンクに対するユニキャストアプリケーションおよびマルチキャストアプリケーションをサポートするために、１つのアプローチは、ＷＴＲＵ－ＩＤおよび／またはグループＩＤを利用することである。ＷＴＲＵ－ＩＤ、グループＩＤ、またはその両方がサイドリンクＷＴＲＵに対して定義され、全ての隣接するＷＴＲＵがそのようなＩＤを知っているケースでは、それらは、ユニキャストサイドリンクおよびマルチキャストサイドリンクをより効率的にするために使用されてもよい。
【0184】
実施例に従って、ユニキャストサイドリンク通信およびマルチキャストサイドリンク通信をより効率的にするためのソリューションは、ＰＳＣＣＨのリソースプール全体の代わりに、ＷＴＲＵ－ＩＤおよび／またはグループＩＤを、ＰＳＣＣＨに対するリソースプールのサブセットにリンク付けすることであってもよい。この実施例に従って、ユニキャストまたはマルチキャストに対するＰＳＣＣＨリソースプールの活性サブセットは、受信機ＷＴＲＵのＷＴＲＵ－ＩＤまたはグループＩＤに応じて（関数として）判定されてもよい。この関数は、ｇＮＢによって、予め定められてもよく、予め定義されてもよく、もしくは準静的に構成されてもよく、またはｇＮＢによって構成された何らかのパラメータによる特定の関数であってもよい。このソリューションでは、送信機ＷＴＲＵは、ＰＳＣＣＨをスケジュールするために、意図した受信機（複数可）または受信ＷＴＲＵ（複数可）に基づいて、リソースプールのサブセットを使用してもよく、受信ＷＴＲＵ（複数可）は、リソースプール全体の代わりに、ＰＳＣＣＨのブラインド検出に対してリソースプールのサブセットを使用してもよい。以下では、ＷＴＲＵ－ＩＤ、Ｃ－ＲＮＴＩ、ＣＳ－ＲＮＴＩ、ＩＭＳＩ、システムアーキテクチャエボリューション（ＳＡＥ）一時モバイル加入者識別子（ｓ－ＴＭＳＩ）、およびＷＴＲＵに対して割り当てられ、または構成されたいずれかのＲＮＴＩは、交換可能に使用されてもよく、本明細書で提供される実施例となおも一貫してもよい。グループＩＤは、ＷＴＲＵのグループに対して割り当てられ、または構成されたＲＮＴＩであってもよい。
【0185】
実施例に従って、ＷＴＲＵ－ＩＤまたはグループＩＤと関連付けられた活性サブセットを示す関数は、ＰＳＣＣＨ候補の開始を示すハッシュ関数であってもよい。このハッシュ関数は、ＮＲまたはＬＴＥにおけるＵｕ ＰＤＣＣＨに対して定義された、ＲＮＴＩの関数としてのハッシュ関数であってもよい。
【0186】
別の実施例に従って、ＷＴＲＵ－ＩＤまたはグループＩＤと関連付けられた活性サブセットを示す関数は、パリティ演算またはモジュロ演算に基づいた多対一関数であってもよい。例えば、リソースプール全体は、２つのサブセットに区分化されてもよく、ＷＴＲＵ－ＩＤまたはグループＩＤと関連付けられた活性サブセットは、それぞれ奇数または偶数であるかに関わらず、第１のサブセットまたは第２のサブセットであってもよい。本明細書で使用されるように、ＷＴＲＵ－ＩＤは、グループＩＤ、送信元ＩＤ、送信機ＩＤ、送信先ＩＤ、受信機ＩＤ、および／またはグループキャストＩＤと交換可能に使用されてもよく、本明細書で提供される実施例となおも一貫してもよい。
【0187】
実施例では、ＰＳＣＣＨ設計は、ＮＲ ＰＵＣＣＨに基づいてもよい。実施例に従って、ＷＴＲＵは、サイドリンク通信に対してＰＵＣＣＨリソースの専用プールの中で、ＰＵＣＣＨリソース上でＳＣＩを送信または受信してもよい。サイドリンク送信に対するＰＵＣＣＨリソースセットは、上位レイヤシグナリングによって提供されてもよい。ＷＴＲＵはまた、ＷＴＲＵが上位レイヤによってＰＵＣＣＨリソースセットにおいてＰＵＣＣＨリソースを使用して送信することができる最大数のＳＣＩビットが提供されてもよい。本明細書で提供される実施例のコンテキストでは、ＳＣＩは、送信ＷＴＲＵによって送信される制御スケジューリング情報または受信ＷＴＲＵによって送信されるフィードバック制御情報を含んでもよい。フィードバック制御情報は、ＨＡＲＱ－ＡＣＫおよびＣＳＩなどを含んでもよい。また、ＰＳＣＣＨは、いずれかの方向においてＳＣＩを搬送する物理チャネルとして交換可能に使用されてもよい。例えば、２つのＷＴＲＵの間で双方通信が存在してもよい。この設計の原理に基づいて、いずれかの通信方向においてサイドリンク制御情報を搬送するために、使用されることになるサイドリンク制御チャネルに対する統一された設計が設けられてもよい。
【0188】
実施形態に従って、ＷＴＲＵは、サイドリンク通信とＵｕ通信との間でＰＵＣＣＨリソースを共有してもよい。ＷＴＲＵは、サイドリンク通信およびＵｕ通信の両方に対して、上位レイヤによってＰＵＣＣＨリソースの１つまたは複数のセットにより構成されてもよい。
【0189】
ＷＴＲＵは、例えば、ＰＳＣＣＨに対して、サイドリンク通信に対するＰＵＣＣＨリソースを判定してもよく、その結果、ＷＴＲＵは、ＷＴＲＵがカバレッジ内またはカバレッジ外にあるｇＮＢカバレッジに基づいて、サイドリンク送信に対するＵｕ通信に対して構成されたＰＵＣＣＨリソースを使用するかどうかを判定することができる。例えば、ＷＴＲＵがｇＮＢカバレッジ外にあるとき、ＷＴＲＵは、サイドリンク通信に対するＵｕ通信に対して構成されたＰＵＣＣＨリソースセットの中からいずれかのＰＵＣＣＨリソースを選択してもよい。ＷＴＲＵがｇＮＢカバレッジ内にあるとき、ＷＴＲＵは、サイドリンク通信に対して、ＰＵＣＣＨリソースセットのサブセット、またはＰＵＣＣＨリソースセット内のＰＵＣＣＨリソースインデックスのリストへのアクセスを有することができにすぎない。サイドリンク通信に対する利用可能なＰＵＣＣＨリソースインデックスまたはＰＵＣＣＨリソースセット（複数可）のインデックス（複数可）のリストは、上位レイヤによって構成されてもよい。
【0190】
ＷＴＲＵが所与のスロットにおいてＵｕ通信に対する構成されたＰＵＣＣＨリソース上で送信していない場合、およびＷＴＲＵがＳＣＩを送信している場合、実施例では、ＷＴＲＵは、Ｕｕ通信に対して構成されたＰＵＣＣＨリソースにおいてＳＣＩを送信してもよい。
【0191】
ＷＴＲＵは、そのタイミング同期またはＷＴＲＵにおいて利用可能な同期機構の精度に応じて、サイドリンク送信に対してＰＵＣＣＨリソースを使用するべきかどうかを判定してもよい。ＷＴＲＵにおいて利用可能な同期機構は、サイドリンク同期信号、Ｕｕ同期信号、およびＧＮＳＳなどを含んでもよい。実施例として、同期精度が特定のタイミング閾値などのＶ２Ｘのユースケース要件を満たず、他のＵＬ送信に対して干渉を引き起こすことがあるとＷＴＲＵが判定する場合、ＷＴＲＵは、サイドリンク通信に対してＵｕ通信に対して構成されたＰＵＣＣＨリソースを使用することを控えてもよい。ＷＴＲＵがサイドリンク同期信号、ＧＮＳＳ、またはその両方に基づいて、サイドリンク同期を排他的に行う場合、ＷＴＲＵは、Ｕｕ通信に対して構成されたＰＵＣＣＨリソースを使用することを控えてもよい。更に、ＷＴＲＵがｇＮＢから受信された同期信号に基づいて同期を行う場合、ＷＴＲＵは、サイドリンク通信に対してＵｕ通信に対して構成されたＰＵＣＣＨリソースを使用してもよい。
【0192】
ＷＴＲＵは、いくつかの優先度ルールに基づいて、サイドリンク送信またはＵｕ送信に対してＰＵＣＣＨリソースを使用するべきかどうかを判定してもよい。例えば、ＷＴＲＵがＨＡＲＱ－ＡＣＫ／スケジューリング要求（ＳＲ）および周期的／準永続的ＣＳＩに対して使用されると予測されるＰＵＣＣＨリソース上で、ｇＮＢにＳＣＩを送信する必要がある場合、またはＳＣＩに対して使用されることになるＰＵＣＣＨリソースがＵＣＩ送信に対して使用されることになるＰＵＣＣＨリソースと重複するとＷＴＲＵが判定する場合、ＷＴＲＵは、事前に指定された優先度基準に基づいて、ＳＣＩまたはＵＣＩをドロップさせてもよい。例えば、ＷＴＲＵがＰＵＣＣＨ上でサービングｇＮＢにＨＡＲＱ－ＡＣＫ／ＳＲを送信することが予測される場合、ＷＴＲＵは、ＳＣＩをドロップさせてもよく、ＨＡＲＱ－ＡＣＫ／ＳＲのみをＰＵＣＣＨに含めてもよい。したがって、実施例では、ＰＵＣＣＨリソースは、Ｕｕ通信に対して使用されてもよい。ＷＴＲＵがＰＵＣＣＨ上でサービングｇＮＢに周期的／準永続的ＣＳＩを送信することが予測される場合、ＷＴＲＵは、周期的／準永続的ＣＳＩ報告（複数可）をドロップさせてもよく、ＰＵＣＣＨにおいてＳＣＩのみを送信してもよい。したがって、実施例では、ＰＵＣＣＨリソースは、サイドリンク通信に対して使用されてもよい。
【0193】
ＮＲにおけるＵｕ通信に対してサポートされるアップリンク制御チャネルフォーマットの中で、ＷＴＲＵは、サイドリンク通信に対する特定の閾値、例えば、２ビットよりも大きいペイロードをサポートするＰＵＣＣＨフォーマット、例えば、ＰＵＣＣＨフォーマット２、ＰＵＣＣＨフォーマット３、またはＰＵＣＣＨフォーマット４に対して構成されたＰＵＣＣＨリソースを使用してもよい。
【0194】
ＷＴＲＵは、ＰＵＣＣＨフォーマットの関連する波形、スロット内のシンボルの数を単位とするＰＵＣＣＨの長さ、ＲＢの数を単位とするＰＵＣＣＨ帯域幅、またはＰＵＣＣＨフォーマットのユーザ多重化能力に基づいて、Ｕｕ通信に対して構成されたＰＵＣＣＨフォーマットのサブセットを使用してもよい。実施例として、ＷＴＲＵは、サイドリンク送信、例えば、ＰＳＣＣＨに対する１つまたは２つのシンボルを有するショートＰＵＣＣＨフォーマットと関連付けられたＰＵＣＣＨリソースのみを使用してもよい。ＷＴＲＵは、サイドリンク送信、例えば、ＰＳＣＣＨに対する４個以上のシンボルを有するロングＰＵＣＣＨフォーマットと関連付けられたＰＵＣＣＨリソースのみを使用してもよい。また、ＷＴＲＵは、サイドリンク送信に対するＯＦＤＭ波形に基づいて、ＰＵＣＣＨフォーマットと関連付けられたＰＵＣＣＨリソースのみを使用してもよい。更に、ＷＴＲＵは、サイドリンク送信に対するＤＦＴ－ｓ－ＯＦＤＭ波形に基づいて、ＰＵＣＣＨフォーマットと関連付けられたＰＵＣＣＨリソースのみを使用してもよい。加えて、ＷＴＲＵは、サイドリンク送信に対する同一の時間－周波数リソース上でのユーザ多重化をサポートすることができるＰＵＣＣＨフォーマットと関連付けられたＰＵＣＣＨリソースのみを使用してもよい。
【0195】
ＷＴＲＵは、上位レイヤによって、ＰＳＣＣＨの送信に対して１つ、およびＰＳＣＣＨの受信に対して１つの、２つのＰＳＣＣＨリソースセットにより構成されてもよい。ＰＳＣＣＨリソースセットは、リソース使用効率を最大にするために、部分的または完全に重複してもよい。
【0196】
実施例に従って、ＷＴＲＵは、パラメータを含む、拡張したＶ２Ｘシナリオをサポートする要件のカテゴリに基づいて、ＰＳＣＣＨフォーマット、ＰＳＣＣＨリソース、スロット内のシンボルの数、およびＰＳＣＣＨ送信に対するＲＢのセットを判定してもよい。Ｖ２Ｘシナリオは、例えば、車両隊列走行、進化型運転、拡張型センサ、および遠隔運転などを含んでもよい。パラメータは、例えば、ＳＣＩのペイロード、最大エンドツーエンド待ち時間、信頼性、および／または最小の必要とされるＶ２Ｘ通信範囲を含んでもよい。実施例では、ＳＣＩのペイロードは、コーディングされていないビットまたはコーディングされたビットの数を単位として設けられてもよい。更に、最大エンドツーエンド待ち時間は、例えば、送信ＷＴＲＵによるＳＣＩ送信の時間から、ＳＣＩが受信ＷＴＲＵにおいて正確に検出される時間までを含んでもよい。また、信頼性は、例えば、１０％から０．００１％までの範囲のＳＣＩブロック誤り率を含んでもよい。加えて、最小の必要とされるＶ２Ｘ通信範囲は、例えば、短距離通信に対して５０メートル、および長距離通信に対して最大で１０００メートルを含んでもよい。
【0197】
実施例に従って、ＷＴＲＵは、短距離通信を含むＶ２Ｘアプリケーション、例えば、センサ情報をＷＴＲＵの間で共有すること、および／または低待ち時間アプリケーションに対して、１つのまたは２つのＯＦＤＭシンボルを有するショートＰＳＣＣＨフォーマットを使用してもよい。低待ち時間アプリケーションは、例えば、進化型運転をサポートするためのＷＴＲＵの間の緊急軌道調整（emergency trajectory alignment）を含んでもよい。
【0198】
別の実施例に従って、ＷＴＲＵは、長距離通信を含むＶ２Ｘアプリケーション、例えば、拡張型センサをサポートするためにビデオをＷＴＲＵの間で共有すること、および／または高信頼性アプリケーションに対して、４個以上のＯＦＤＭシンボルを有するロングＰＳＣＣＨフォーマットを使用してもよい。高信頼性アプリケーションは、例えば、遠隔運転をサポートするためのＶ２ＸアプリケーションをサポートするＷＴＲＵとＶ２Ｘアプリケーションサーバとの間での情報交換を含んでもよい。
【0199】
実施例では、ＷＴＲＵは、ＳＣＩフォーマットに基づいて、サイドリンク制御チャネルフォーマット／リソース判定を行ってもよい。例として、ＷＴＲＵは、ＳＣＩフォーマットに従って、ＰＳＣＣＨフォーマットおよび対応するＰＳＣＣＨリソースまたはリソースプールを判定してもよい。例えば、ショートペイロード、低待ち時間、または短距離サイドリンク通信に対してＳＣＩフォーマットを定義することができる場合、ＷＴＲＵは、ショートＰＳＣＣＨフォーマットを使用してもよい。更に、ラージペイロード、高信頼性、または長距離サイドリンク通信に対してＳＣＩフォーマットを定義する場合、ＷＴＲＵは、ロングＰＳＣＣＨフォーマットを使用してもよい。
【0200】
更なる実施例では、ＰＳＣＣＨに対して適合的スクランブラ初期化パラメータ（adaptive scrambler initializing parameter）が使用されてもよい。実施例に従って、ＷＴＲＵは、ＰＳＳＣＨ送信モードに対して適合されたＰＳＣＣＨペイロードをスクランブルするためのスクランブルシーケンスジェネレータに対して、異なる初期化パラメータ例えば、ｃ＿ｉｎｉｔを推定してもよい。実施例では、ＰＳＳＣＨ送信モードは、ユニキャスト、グループキャスト、またはブロードキャストであってもよい。実施例では、ＷＴＲＵは、以下のステップのうちの１つまたは複数にあるように、初期化パラメータ、例えば、ｃ＿ｉｎｉｔを判定してもよい。例えば、ＰＳＳＣＨがユニキャストに対するものである場合、初期化パラメータ、例えば、ｃ＿ｉｎｉｔは、ＷＴＲＵ－ＩＤまたはＲＮＴＩの関数であってもよい。更に、実施例では、ｎ＿ＲＮＴＩ＝Ｃ＿ＲＮＴＩである。また、ＰＳＳＣＨがブロードキャストに対するものである場合、初期化パラメータ、例えば、ｃ＿ｉｎｉｔは、ＷＴＲＵ－ＩＤまたはＲＮＴＩの関数でなくてもよい。例えば、ｎ＿ＲＮＴＩ＝０であり、またはスクランブルが全く実行されなくてもよい。ＰＳＳＣＨＰＳＳＣＨがマルチキャストに対するものである場合、初期化パラメータ、例えば、ｃ＿ｉｎｉｔは、グループＩＤ、例えば、グループＲＮＴＩの関数であってもよい。
【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】
特徴および要素が特定の組み合わせにおいて上記説明されたが、当業者は、各々の特徴または要素が単独で使用されてもよく、または他の特徴および要素とのいずれかの組み合わせにおいて使用されてもよいことを認識するであろう。加えて、本明細書で説明される方法は、コンピュータまたはプロセッサによる実行のための、コンピュータ可読媒体に組み込まれたコンピュータプログラム、ソフトウェア、またはファームウェアにおいて実装されてもよい。コンピュータ可読媒体の例は、電気信号（有線接続または無線接続と通じて送信される）およびコンピュータ可読記憶媒体を含む。コンピュータ可読記憶媒体の例は、リードオンリメモリ（ＲＯＭ）、ランダムアクセスメモリ（ＲＡＭ）、レジスタ、キャッシュメモリ、半導体メモリデバイス、内蔵ハードディスクおよび着脱可能ディスクなどの磁気媒体、磁気光学媒体、ならびにＣＤ－ＲＯＭディスクおよびデジタル多用途ディスク（ＤＶＤ）などの光学媒体を含むが、それらに限定されない。ソフトウェアと関連したプロセッサは、ＴＲＵ、ＵＥ、端末、基地局、ＲＮＣ、またはいずれかのホストコンピュータにおける使用に対して無線周波数送受信機を実装するために使用されてもよい。
【図1A】
【図1B】
【図1C】
【図1D】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】