JP2023546906A - サイドリンクスケジューリングのオフロードによるユーザ機器の省電力化 - Google Patents

Abstract

ユーザ機器（ＵＥ）が、ＵＥによる使用のためのサイドリンク送信リソースのセットを第２のＵＥに決定させるスケジューリング要求（ＳＲ）を、第２のＵＥに送信するように構成される。次いで、ＵＥは第２のＵＥから、決定されたサイドリンク送信リソースのセットに関する情報を受信し、次いで、決定されたサイドリンク送信リソースのセットの少なくともサブセットを使用してサイドリンク通信を送信し得る。決定されたサイドリンク送信リソースのセットは、推奨、及び予約されたリソース又は予約されていないリソースであり得る。ＵＥは第２のＵＥに、ＳＲを送信する際に使用される送信リソースに関する構成情報を送信し得る。第２のＵＥは、リソースの到着についてチャネルを監視し得る。ＳＲは、ＡＣＫのみのシーケンス、ＡＣＫ／ＮＡＣＫシーケンス、又は構成インデックスに基づくＳＲのある１つのシーケンスに相当する、ＳＲの巡回シフトとして符号化され得る。

Description

本出願は無線デバイスに関し、より具体的には、レイテンシ及び電力消費の低減、並びに信頼性の向上のために、変化する電力能力を有する無線デバイスのサイドリンクリソースのスケジューリング及び割り当てを行う装置、システム、及び方法に関する。

無線通信システムの使用が急速に増大している。無線通信の提案された用途の１つは、車両アプリケーション、特にＶ２Ｘ（ビークルツーエブリシング）システムにおけるものである。Ｖ２Ｘシステムは、交通活動を調整すること、自律運転を円滑にすること、及び衝突回避を実行することなどの様々な目的のために、（例えば、車両内に収容されるか、又は他の方法で車両によって運搬される通信デバイスを介して）車両と、（サイクリストなど、他の人によって運搬されるＵＥを含む）歩行者ＵＥと、他の無線通信デバイスとの間の通信を可能にする。

ある一定のＶ２Ｘシステムでは通信要件が増大し、ポータブルなバッテリ駆動ＵＥデバイスの電力及びリソース能力に負担をかけることがある。加えて、いくつかのＵＥは他のＵＥより電力が制限されており、ＵＥのホストと通信すると、バッテリ寿命の減少、レイテンシの増加、及び通信問題の悪化が呈されることがある。したがって、この分野における改善が望まれる。

本明細書には、レイテンシ及び電力消費の低減、並びに信頼性の向上のために、サイドリンクリソースのスケジューリング及び割り当てを別の高電力の無線デバイスにオフロードする、無線デバイスのための装置、システム、及び方法の実施形態が提示される。

いくつかの実施形態は、少なくとも１つのアンテナと、少なくとも１つのアンテナに動作可能に結合された無線機と、無線機に動作可能に結合されたプロセッサとを備える、ユーザ機器（ＵＥ）に関する。このＵＥ（第１のＵＥ）は、第１のＵＥによる使用のためのサイドリンク送信リソースのセットを第２のＵＥに決定させるスケジューリング要求を、第２のＵＥに送信するように構成されていてもよい。言い換えれば、第１のＵＥは、第１のＵＥの利用可能なサイドリンクリソースを決定する作業を、第１のＵＥと比較して高い電力能力を有し得る第２のＵＥにオフロードしてもよい。このスケジューリング要求に応答して、第２のＵＥは、例えば、サイドリンクチャネル上のトラフィックを検知することによって、第１のＵＥが使用するために利用可能なサイドリンクリソースのセットを決定してもよい。次いで、第２のＵＥは、これらの決定されたサイドリンクリソースを第１のＵＥに提供してもよい。いくつかの態様では、第２のＵＥは、これらのリソースの到着について、このチャネルを監視してもよい。したがって、第１のＵＥは、決定されたサイドリンク送信リソースのセットに関する情報を第２のＵＥから受信してもよく、このサイドリンクリソースのセットは、送信されたスケジューリング要求に基づいて第２のＵＥによって決定されたものである。最後に、第１のＵＥは、第２のＵＥによって示された決定されたサイドリンク送信リソースのセットのうち少なくともサブセットを使用して、サイドリンク通信を送信してもよい。

いくつかの態様では、決定されたサイドリンク送信リソースのセットは、推奨（予約されていない）リソースであってもよい。それに反して、他の態様では、決定されたサイドリンク送信リソースのセットは、第１のＵＥによる使用のために第２のＵＥによって予約されていてもよい。

更に、上記の第１及び第２のＵＥの一方又は両方は、構成情報を他方と交換するように更に構成されていてもよく、構成情報は、スケジューリング要求を送信する際に使用される送信リソースを構成する。

サイドリンクスケジューリング要求（Ｓ－ＳＲ）は、ＡＣＫのみのシーケンス又はＡＣＫ／ＮＡＣＫシーケンスに相当するＳ－ＳＲの巡回シフトとして符号化されてもよい。いくつかの実施形態では、スケジューリング要求は、Ｓ－ＳＲのある１つのシーケンスを示す構成インデックスとして符号化されてもよい。

いくつかの実施形態は、無線通信を実行するための少なくとも１つのアンテナと、無線機と、無線機に結合された処理要素とを有するユーザ機器（ＵＥ）デバイスに関してもよい。ＵＥは、本明細書に記載の方法のうち少なくともいくつかを実行してもよい。

いくつかの実施形態は、上記の動作の少なくとも一部又は全部を実行するように構成された処理回路を有するベースバンドプロセッサに関する。

この発明の概要は、本文書に記載の主題のいくつかの簡易的な概要を提供することが意図されている。よって、上記の特徴は単なる一例に過ぎず、本明細書に記載の主題の範囲又は趣旨を狭めるものとして解釈されるべきでないことを理解されたい。本明細書に記載の主題の他の特徴、態様、及び利点は、以下の詳細な説明、図面、及び特許請求の範囲から明らかになる。

各種実施形態の以下の詳細な説明が、以下の図面と共に考察されたときに、本主題のより良い理解が得られ得る。

いくつかの実施形態による、ビークルツーエブリシング（Ｖ２Ｘ）通信システムの例を示す図である。

いくつかの実施形態による、ユーザ機器（ＵＥ）デバイスと通信する基地局を示す図である。

いくつかの実施形態による、ＵＥのブロック図の例を示す図である。

いくつかの実施形態による、基地局のブロック図の例を示す図である。

いくつかの実施形態による、ビークルツーエブリシングネットワークの例を示す図である。

いくつかの実施形態による、スレーブＵＥデータ送信の手順例を示す図である。

いくつかの実施形態による、マスタＵＥデータ送信の手順例を示す図である。

いくつかの実施形態による、サイドリンクスケジューリング要求（Ｓ－ＳＲ）信号の構造例を示す図である。

いくつかの実施形態による、サイドリンクスケジューリング要求（Ｓ－ＳＲ）信号の周波数リソース及び符号リソースを示す図である。

いくつかの実施形態による、マスタＵＥが、推奨されるが予約されていないリソースをスレーブＵＥに提供する様子の例を示す図である。

いくつかの実施形態による、マスタＵＥが、推奨及び予約されたリソースをスレーブＵＥに提供する様子の例を示す図である。

本明細書に記載の特徴は、様々な変更形態及び代替的形態が可能ではあるが、その特定の実施形態を例として図面に示し、本明細書において詳細に説明する。しかしながら、図面及びその詳細な説明は、開示されている特定の形態に限定することを意図しておらず、むしろ、添付の特許請求の範囲によって定義されている本主題の趣旨及び範囲内の全ての修正、等価物、及び代替案を包含することが意図されていることを理解されたい。

用語
本開示に全般的に様々な頭字語が使用される。本開示に全般的に出現し得る、最も顕著に使用される頭字語の定義は以下のとおりである。
●ＵＥ：ユーザ機器
●ＲＦ：無線周波数
●ＢＳ：基地局
●ＧＳＭ：移動体通信グローバルシステム
●ＵＭＴＳ：ユニバーサル移動体通信システム
●ＬＴＥ：ロングタームエボリューション
●ＮＲ：新無線
●ＮＲ－Ｕ：免許不要ＮＲ
●ＴＸ：送信／送信する
●ＲＸ：受信／受信する
●ＲＡＴ：無線アクセス技術
●ＴＲＰ：送信受信点
●ＤＣＩ：下りリンク制御情報
●Ｖ２Ｘ：ビークルツーエブリシング
●ＰＳＣＣＨ：物理サイドリンク制御チャネル
●ＰＳＳＣＨ：物理サイドリンク共有チャネル
●ＰＵＣＣＨ：物理上りリンク制御チャネル
●Ｓ－ＳＲ：サイドリンクスケジューリング要求
●ＰＵＥ：歩行者ユーザ機器
●ＶＵＥ：車両ユーザ機器
●ＳＬ：サイドリンク
●ＭＣＳ：変調及び符号化の方式
●ＤＭＲＳ：復調参照信号
●ＲＯ：リソース占有
●ＲＳＵ：路側ユニット
●ＳＰＳ：準永続的スケジューリング
●ＱｏＳ：サービス品質

以下は、本開示で使用されている用語の解説である。

メモリ媒体－様々な種類の非一時的メモリデバイス又は記憶デバイスのうちの任意のもの。用語「メモリ媒体」は、例えば、ＣＤ－ＲＯＭ、フロッピーディスク、又はテープデバイスなどのインストール媒体、ＤＲＡＭ、ＤＤＲ ＲＡＭ、ＳＲＡＭ、ＥＤＯ ＲＡＭ、Ｒａｍｂｕｓ ＲＡＭなどのコンピュータシステムメモリ又はランダムアクセスメモリ；フラッシュ、ハードドライブなどの磁気媒体、又は光学ストレージなどの不揮発性メモリ；レジスタ、又は他の類似のタイプのメモリ要素などを含むことが意図されている。メモリ媒体は、他のタイプの非一時的メモリも含んでもよく、又はこれらの組み合わせを含んでもよい。加えて、メモリ媒体は、プログラムが実行される第１のコンピュータシステムに配置されてもよく、又はインターネットなどのネットワークを介して第１のコンピュータシステムに接続する第２の異なるコンピュータシステムに配置されてもよい。後者の事例では、第２のコンピュータシステムは、実行するために、プログラム命令を第１のコンピュータに提供することができる。用語「メモリ媒体」は、異なる場所において、例えば、ネットワークを介して接続された異なるコンピュータシステムにおいて存在することができる２つ以上のメモリ媒体を含んでもよい。メモリ媒体は、１つ以上のプロセッサによって実行され得る（例えば、コンピュータプログラムとして具現化された）プログラム命令を記憶してもよい。

プログラム可能ハードウェア要素－プログラム可能相互接続子を介して接続された複数のプログラム可能機能ブロックを備える、様々なハードウェアデバイスを含む。例として、フィールドプログラム可能ゲートアレイ（Field Programmable Gate Array、ＦＰＧＡ）、プログラム可能論理デバイス（Programmable Logic Device、ＰＬＤ）、フィールドプログラム可能オブジェクトアレイ（Field Programmable Object Array、ＦＰＯＡ）、及び複合ＰＬＤ（Complex PLD、ＣＰＬＤ）が挙げられる。プログラム可能機能ブロックは、細かい粒度のもの（組み合わせ論理又はルックアップテーブル）から粗い粒度のもの（演算論理装置又はプロセッサコア）にまで及ぶことができる。プログラム可能ハードウェア要素はまた、「再構成可能論理」と称され得る。

コンピュータシステム－パーソナルコンピュータシステム（ＰＣ）、メインフレームコンピュータシステム、ワークステーション、ネットワーク装置、インターネット装置、携帯情報端末（ＰＤＡ）、テレビシステム、グリッドコンピューティングシステム、又はその他のデバイス若しくはデバイスの組み合わせ、を含む様々な種類のコンピューティング又は処理システムのうちの任意のもの。一般的に、用語「コンピュータシステム」は、メモリ媒体からの命令を実行する少なくとも１つのプロセッサを有する任意のデバイス（又はデバイスの組み合わせ）を包含するように広義に定義することができる。

ユーザデバイス－本明細書で使用される場合、概して、Ｖ２Ｘシステムのコンテキストにおいて、基地局、路側ユニット（ＲＳＵ）、及びサーバなどのインフラストラクチャデバイスとは対照的に、Ｖ２Ｘシステムにおけるモバイルアクター又はトラフィック参加者に関連付けられたデバイス、すなわち、車両及び歩行者ユーザ機器（ＰＵＥ）デバイスなどのモバイル（移動可能な）通信デバイスを指し得る。

インフラストラクチャデバイス－本明細書で使用される場合、概して、Ｖ２Ｘシステムのコンテキストにおいて、ユーザデバイスではなく、トラフィックアクター（すなわち、歩行者、車両、又は他のモバイルユーザ）によって運搬されないが、ユーザデバイスのＶ２Ｘネットワークへの参加を容易にする、Ｖ２Ｘシステム内の特定のデバイスを指し得る。インフラストラクチャデバイスは、基地局及び路側ユニット（ＲＳＵ）を含む。

ユーザ機器（ＵＥ）（又は「ＵＥデバイス」）－無線通信を実行する様々な種類の移動式又は携帯式コンピュータシステムデバイス。ＵＥデバイスの例としては、携帯電話若しくはスマートフォン（例えば、ｉＰｈｏｎｅ（商標）、Ａｎｄｒｏｉｄ（商標）ベースの電話）、ポータブルゲーミングデバイス（例えば、Ｎｉｎｔｅｎｄｏ ＤＳ（商標）、ＰｌａｙＳｔａｔｉｏｎ Ｐｏｒｔａｂｌｅ（商標）、Ｇａｍｅｂｏｙ Ａｄｖａｎｃｅ（商標）、ｉＰｈｏｎｅ（商標））、ラップトップ、ウェアラブルデバイス（例えば、スマートウォッチ、スマートグラス）、ＰＤＡ、ポータブルインターネットデバイス、音楽プレーヤ、データ記憶デバイス、又は他のハンドヘルドデバイスなどが挙げられる。一般に、用語「ＵＥ」又は「ＵＥデバイス」は、ユーザによって容易に持ち運ばれ、無線通信が可能なあらゆる電子、コンピューティング及び／又は電気通信デバイス（又はデバイスの組み合わせ）を包含するように広義に定義することができる。

歩行者ＵＥ（ＰＵＥ）デバイス－道路の近くを歩く人という厳密な意味での歩行者のみならず、交通環境における、他の周辺的若しくは軽度の参与者、又は潜在的な参与者も含む、様々な人によって装着又は携行され得る、ユーザ機器（ＵＥ）デバイス。これらは、静止している人、必ずしも交通又は道路の近くにいるとは限らない、車両に乗っていない人、ジョギング、ランニング、スケートなどをしている人、又は自転車、スクーター、若しくはある種の自動車など、ＵＥの電力能力を実質的に高めない車両に乗っている人を含む。歩行者ＵＥの例には、スマートフォン、ウェアラブルＵＥ、ＰＤＡなどが挙げられる。

基地局－用語「基地局」は、その通常の意味の全範囲を有し、少なくとも、固定場所に設置され、無線電話システム又は無線システムの一部として通信するために使用される無線通信局を含む。

処理要素－様々な要素又は要素の組み合わせを指す。処理要素は、例えば、特定用途向け集積回路（Application Specific Integrated Circuit、ＡＳＩＣ）などの回路、個別のプロセッサコアの一部分若しくは回路、プロセッサコア全体、個別プロセッサ、フィールドプログラマブルゲートアレイ（field programmable gate array、ＦＰＧＡ）などのプログラム可能なハードウェアデバイス、及び／又は複数のプロセッサを含むシステムのより大きい部分を含む。

チャネル－送信側（送信機）から受信機に情報を伝達するために使用される媒体。用語「チャネル」の特性は、異なる無線プロトコルに従って異なり得るため、本明細書に使用される場合、用語「チャネル」は、この用語が関連して使用されるデバイスのタイプの規格に一致するように使用されると見なされることに留意されたい。いくつかの規格では、チャネル幅は、（例えば、デバイス能力、帯域条件などに依存して）可変であり得る。例えば、ＬＴＥは、１．４ＭＨｚ～２０ＭＨｚのスケーラブルなチャネル帯域幅をサポートしてもよい。対照的に、ＷＬＡＮのチャネルは、２２ＭＨｚ幅を有することができ、Ｂｌｕｅｔｏｏｔｈのチャネルは、１Ｍｈｚ幅を有することができる。他のプロトコル及び規格は、異なるチャネルの定義を含み得る。更に、いくつかの規格は、複数のタイプのチャネル、例えば、上りリンク若しくは下りリンクのための異なるチャネル、及び／又は、データ、制御情報などの異なる使用のための異なるチャネルを定義及び使用することができる。
図１－Ｖ２Ｘ通信システム

図１は、いくつかの実施形態による、例示的なビークルツーエブリシング（Ｖ２Ｘ）通信システムを示す。図１のシステムは、可能なシステムの単なる一例であり、本開示の特徴は、様々なシステムのうちのいずれかにおいて所望に応じて実装されてもよいことに留意されたい。

ビークルツーエブリシング（Ｖ２Ｘ）通信システムは、他の可能な目的の中でもとりわけ、トラフィックアクティビティを調整するために、車両、ＵＥ、及び／又は他のデバイス及びネットワークエンティティが通信を交換するネットワークとして特徴付けられ得る。Ｖ２Ｘ通信は、車両（例えば、車両の一部を構成する、又は車両に含まれる、若しくは他の方法で車両によって運搬される無線デバイス又は通信デバイス）と様々な他のデバイスとの間で伝達される通信を含む。Ｖ２Ｘ通信は、車両対歩行者（Ｖ２Ｐ）、車両対インフラストラクチャ（Ｖ２Ｉ）、車両対ネットワーク（Ｖ２Ｎ）、及び車両対車両（Ｖ２Ｖ）通信、並びに車両と他の可能なネットワークエンティティ又はデバイスとの間の通信を含む。Ｖ２Ｘ通信はまた、Ｖ２Ｘ関連情報を共有する目的でＶ２Ｘネットワークに参加する他の非車両デバイス間の通信を指すことがある。

Ｖ２Ｘ通信は、例えば、３ＧＰＰセルラＶ２Ｘ（Ｃ－Ｖ２Ｘ）仕様、又は、車両及びその他のデバイス及びネットワークエンティティが通信し得る１つ以上のその他又は後続の規格に準拠し得る。Ｖ２Ｘ通信では、長距離（例えば、セルラ）通信並びに短中距離（例えば、非セルラ）通信の両方を利用することができる。セルラ対応Ｖ２Ｘ通信は、セルラＶ２Ｘ（Ｃ－Ｖ２Ｘ）通信と呼ばれることがある。Ｃ－Ｖ２Ｘシステムは、４Ｇ ＬＴＥ又は５Ｇ ＮＲ ＲＡＴなど、様々なセルラ無線アクセス技術（ＲＡＴ）を使用し得る。Ｖ２Ｘシステムにおいて使用可能なある種のＬＴＥ規格は、ＬＴＥ－Ｖｅｈｉｃｌｅ（ＬＴＥ－Ｖ）規格と呼ばれることがある。

図に示すように、例示的なＶ２Ｘシステムは、いくつかのユーザデバイスを含む。Ｖ２Ｘシステムのコンテキストにおいて本明細書で使用される場合、及び、上記のとおりに定義される場合、用語「ユーザデバイス」は、一般に、Ｖ２Ｘシステム内のモバイル行動者又はトラフィック参加者に関連付けられたデバイス、すなわち、車両及び歩行者ユーザ機器（ＰＵＥ）デバイスなどのモバイル（移動可能）通信デバイスを指し得る。例示的なＶ２Ｘシステムにおけるユーザデバイスは、ＰＵＥ１０４Ａ及び１０４Ｂ並びに車両１０６Ａ及び１０６Ｂを含む。

車両１０６は、様々なタイプの車両を構成することができる。例えば、車両１０６Ａは、路上車両若しくは自動車、大量輸送車両、又は別のタイプの車両であり得る。車両１０６は、様々な手段によって無線通信を行うことができる。例えば、車両１０６Ａは、車両の一部として、又は車両に収容された通信機器を含み得、あるいは、数ある可能性の中でも特に、運転者、乗客、又は車両に乗っている他の人によって携行又は装着されるユーザ機器（ＵＥ）デバイス（例えば、スマートフォン又は同様のデバイス）など、車両内に現在含まれているか、又は他の方法で車両によって運搬される無線通信デバイスを通じて通信し得る。簡略化のために、本明細書で使用される「車両」という用語は、車両を表し、その通信を行う無線通信機器を含み得る。したがって、例えば、車両１０６Ａが無線通信を行うと言われるとき、より具体的には、車両１０６Ａに関連付けられ、車両１０６Ａによって運搬される特定の無線通信機器がその無線通信を行っていることが理解される。

歩行者ＵＥ（ＰＵＥ）１０４は、様々なタイプのユーザ機器（ＵＥ）デバイス、すなわち、スマートフォン、スマートウォッチなど、無線通信が可能なポータブルデバイスを構成してよく、様々なタイプのユーザに関連付けられ得る。したがって、ＰＵＥ１０４はＵＥであり、ＵＥ又はＵＥデバイスと呼ばれることがある。ＵＥ１０４はＰＵＥ（歩行者ＵＥ）と呼ばれることがあるが、それらは必ずしも道路又は通りの近くを活発に歩いている人によって運搬されるとは限らないことに留意されたい。ＰＵＥは、Ｖ２Ｘシステムに参加しているＵＥであって、静止している人によって、歩いている若しくは走っている人によって、又は自転車、スクーター、若しくはある種の自動車など、デバイスの電力能力を実質的に高めない可能性がある車両に乗っている人によって運搬されるＵＥを指すことがある。また、Ｖ２Ｘシステムに参加する全てのＵＥが必ずしもＰＵＥであるとは限らないことに留意されたい。

ユーザデバイスは、複数の無線通信規格を使用して通信することができる場合がある。例えば、ＵＥ１０４Ａは、少なくとも１つのセルラ通信プロトコル（例えば、ＧＳＭ、ＵＭＩＴＳ、ＬＴＥ、ＬＴＥ－Ａ、ＬＴＥ－Ｖ、ＨＳＰＡ、３ＧＰＰ２ ＣＤＭＡ２０００、５Ｇ ＮＲなど）に加えて、無線ネットワーキング（例えば、Ｗｉ－Ｆｉ）及び／又はピアツーピア無線通信プロトコル（例えば、Ｂｌｕｅｔｏｏｔｈ、Ｗｉ－Ｆｉピアツーピアなど）を使用して通信するように構成され得る。ＵＥ１０４Ａは、加えて又は代替として、１つ以上のグローバルナビゲーション衛星システム（Global Navigational Satellite System、ＧＮＳＳ、例えば、ＧＰＳ若しくはＧＬＯＮＡＳＳ）、１つ以上のモバイルテレビ放送規格（例えば、ＡＴＳＣ－Ｍ／Ｈ若しくはＤＶＢ－Ｈ）、及び／又は、所望であれば、任意の他の無線通信プロトコルを使用して通信するように構成され得る。（３つ以上の無線通信規格を含む）無線通信規格の他の組み合わせもまた、可能である。

図示のように、いくつかのユーザデバイスは、互いに直接、すなわち、基地局１０２Ａ又はＲＳＵ１１０Ａなどの中間インフラストラクチャデバイスなしに、通信を行うことが可能であり得る。図示のように、車両１０６Ａは、車両１０６Ｂと直接Ｖ２Ｘ関連通信を行うことができる。同様に、車両１０６Ｂは、ＰＵＥ１０４Ｂと直接Ｖ２Ｘ関連通信を行い得る。そのようなピアツーピア通信は、ＬＴＥ及び／又は５Ｇ ＮＲのいくつかの実施形態の場合、ＰＣ５インタフェースなどの「サイドリンク」インタフェースを利用することがある。いくつかの実施形態では、ＰＣ５インタフェースは、ユーザデバイス間（例えば、車両１０６間）の直接セルラ通信をサポートし、Ｕｕインタフェースは、基地局などのインフラストラクチャデバイスとのセルラ通信をサポートする。ＰＣ５／Ｕｕインタフェースは単に例として使用され、ＰＣ５は、本明細書で使用される場合、ユーザデバイス間の直接サイドリンク通信を可能にする様々な他の可能な無線通信技術を表すことがあり、Ｕｕは、ユーザデバイスと基地局などのインフラストラクチャデバイスとの間で行われるセルラ通信を表すことがある。Ｖ２Ｘシステム内の、例えばＰＵＥ１０４Ａなどの、いくつかのユーザデバイスは、例えば、そのような通信を行うために必要なある種のハードウェアを欠いているため、サイドリンク通信を行うことができないことがある。

図に示すように、例示的なＶ２Ｘシステムは、上述のユーザデバイスに加えて、いくつかのインフラストラクチャデバイスを含む。本明細書で使用される場合、Ｖ２Ｘシステムのコンテキストにおける「インフラストラクチャデバイス」はユーザデバイスではなく、トラフィックアクター（すなわち、歩行者、車両、又は他のモバイルユーザ）によって運搬されないが、Ｖ２Ｘネットワークへのユーザデバイスの参加を容易にする、Ｖ２Ｘシステム内のある種のデバイスを指す。例示的なＶ２Ｘシステムにおけるインフラストラクチャデバイスは、基地局１０２Ａ及び路側ユニット（ＲＳＵ）１１０Ａを含む。

基地局（ＢＳ）１０２Ａは、ベーストランシーバ局（ＢＴＳ）又はセルサイト（「セルラ基地局」）であってよく、ユーザデバイスとの、例えば、ユーザデバイス１０４Ａ及び１０６Ａとの無線通信を可能にするハードウェアを含み得る。

基地局の通信領域（すなわちカバレッジ領域）は、「セル」又は「カバレッジ」と称され得る。基地局１０２Ａ及びＰＵＥ１０４Ａなどのユーザデバイスは、ＧＳＭ、ＵＭＴＳ、ＬＴＥ、ＬＴＥアドバンスト（ＬＴＥーＡ）、ＬＴＥ－Ｖｅｈｉｃｌｅ（ＬＴＥ－Ｖ）、ＨＳＰＡ、３ＧＰＰ２ ＣＤＭＡ２０００、５Ｇ ＮＲなどの無線通信技術又は電気通信規格とも呼ばれる様々な無線アクセス技術（ＲＡＴ）のいずれかを使用して伝送媒体を介して通信するように構成され得る。基地局１０２ＡがＬＴＥのコンテキストで実施される場合は代替的に「ｅＮｏｄｅＢ」又はｅＮＢと呼ばれることがあり、対して、基地局１０２Ａが５Ｇ ＮＲのコンテキストで実施される場合は代替的に「ｇＮｏｄｅＢ」又はｇＮＢと呼ばれることがあることに留意されたい。

図に示すように、基地局１０２Ａはまた、ネットワーク１００（例えば、様々な可能性の中でもとりわけ、Ｖ２Ｘネットワーク、並びにセルラサービスプロバイダのコアネットワーク、公衆交換電話網（ＰＳＴＮ）などの電気通信ネットワーク、及び／又はインターネット）と通信するように装備され得る。したがって、基地局１０２Ａは、ユーザデバイス間の通信、及び／又は、ユーザデバイスとネットワーク１００との間の通信を容易にし得る。特に、セルラ基地局１０２Ａは、音声、ＳＭＳ、及び／又はデータサービスなどの様々な電気通信機能をＵＥ１０４Ａなどのユーザデバイスに提供し得る。特に、基地局１０２Ａは、ＵＥ１０４Ａ及び車両１０６Ａなどの接続されたユーザデバイスに、Ｖ２Ｘネットワークへのアクセスを提供し得る。

したがって、基地局１０２Ａは、図１に示すように、ユーザデバイス１０４Ａ及び１０６Ａのための「サービングセル」として動作し得るが、ユーザデバイス１０４Ｂ及び１０６Ｂもまた、基地局１０２Ａと通信することが可能であり得る。図示のユーザデバイス、すなわち、ユーザデバイス１０４Ａ、１０４Ｂ、１０６Ａ、及び１０６Ｂはまた、１つ以上の他のセル（基地局１０２Ｂ～１０２Ｎ及び／又は任意の他の基地局によって提供され得る）から、（その通信範囲内にあることも考えられる）信号を受信することもできる可能性があり、これは「隣接セル」と呼ばれることがある。このようなセルはまた、ユーザデバイス間の通信、及び／又はユーザデバイスとネットワーク１００との間の通信を容易にすることが可能である。このようなセルは、「マクロ」セル、「マイクロ」セル、「ピコ」セル、及び／又はサービスエリアサイズの様々な他の粒度を提供するセルを含んでもよい。例えば、図１に示す基地局１０２Ａ～１０２Ｂは、マクロセルであってもよく、基地局１０２Ｎは、マイクロセルであってもよい。当然ながら、他の構成も可能である。

路側ユニット（ＲＳＵ）１１０Ａは、特定のユーザデバイスにＶ２Ｘネットワークへのアクセスを提供するために使用可能な別のインフラストラクチャデバイスを構成する。ＲＳＵ１１０Ａは、基地局、例えばトランシーバ局（ＢＴＳ）若しくはセルサイト（「セルラ基地局」）、又はユーザデバイスとの無線通信を可能にし、Ｖ２Ｘネットワークへのそれらの参加を容易にするハードウェアを含む別のタイプのデバイスなど、様々なタイプのデバイスのうちの１つであり得る。

ＲＳＵ１１０Ａは、１つ以上の無線ネットワーキング通信プロトコル（例えば、Ｗｉ－Ｆｉ）、セルラ通信プロトコル（例えば、ＬＴＥ、ＬＴＥ－Ｖ、５Ｇ ＮＲなど）、及び／又は他の無線通信プロトコルを使用して通信するように構成され得る。いくつかの実施形態では、ＲＳＵ１１０Ａは、ＰＣ５などの「サイドリンク」技術を使用してデバイスと通信することが可能であり得る。

ＲＳＵ１１０Ａは、図示の車両１０６Ａ及び１０６Ｂなどのユーザデバイスと直接通信することができる。ＲＳＵ１１０Ａはまた、基地局１０２Ａと通信し得る。場合によっては、ＲＳＵ１１０Ａは、特定のユーザデバイス、例えば車両１０６Ｂに、基地局１０２Ａへのアクセスを提供し得る。ＲＳＵ１１０Ａは、車両１０６と通信するように示されているが、ＰＵＥ１０４と通信することも（又は他の方法で）可能であり得る。同様に、ＲＳＵ１１０Ａは、必ずしもユーザデバイス通信を基地局１０２Ａに転送しなくてもよい。いくつかの実施形態では、ＲＳＵ１１０Ａは、基地局自体を構成することができ、かつ／又は通信をサーバ１２０に転送することができる。

サーバ１２０は、図に示すように、Ｖ２Ｘシステムのネットワークエンティティを構成し、クラウドサーバと呼ばれることがある。基地局１０２Ａ及び／又はＲＳＵ１１０Ａは、ユーザデバイス１０４及び１０６とサーバ１２０との間のいくつかのＶ２Ｘ関連通信を中継し得る。サーバ１２０は、複数のユーザデバイスから収集された特定の情報を処理するために使用され得、トラフィックアクティビティを調整するために、ユーザデバイスへのＶ２Ｘ通信を管理し得る。Ｖ２Ｘシステムの様々な他の実施形態では、クラウドサーバ１２０の様々な機能は、基地局１０２Ａ又はＲＳＵ１１０Ａなどのインフラストラクチャデバイスによって実行されてもよく、１つ以上のユーザデバイスによって実行されてもよく、及び／又は全く実行されなくてもよい。
図２－ＵＥと基地局との間の通信

図２は、いくかの実施形態による、基地局１０２（例えば、図１の基地局１０２Ａ）と通信するユーザ機器（ＵＥ）デバイス１０４（例えば、図１のＰＵＥ１０４Ａ又は１０４Ｂのうちの１つ）を示す。ＵＥ１０４は、携帯電話、ハンドヘルドデバイス、コンピュータ若しくはタブレット、又は実質上あらゆるタイプのポータブル無線デバイスなどのセルラ通信能力を有するデバイスであり得る。

ＵＥ１０４は、メモリに記憶されたプログラム命令を実行するように構成されたプロセッサを含んでもよい。ＵＥ１０４は、そのような記憶された命令を実行することによって、本明細書に記載の方法の実施形態のうちのいずれかを実行することができる。代替として、又は加えて、ＵＥ１０４は、本明細書に記載の方法の実施形態のうちのいずれか、又は本明細書に記載の方法の実施形態のうちのいずれかの任意の部分を実行するように構成された、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）などのプログラム可能ハードウェア要素を含んでもよい。

ＵＥ１０４は、１つ以上の無線通信プロトコル又は技術を使用して通信するための１つ以上のアンテナを含み得る。いくつかの実施形態では、ＵＥ１０４は、例えば、単一の共用無線機を使用するＣＤＭＡ２０００（１ｘＲＴＴ／１ｘＥＶ－ＤＯ／ＨＲＰＤ／ｅＨＲＰＤ）、ＬＴＥ、及び／若しくは５Ｇ ＮＲ、並びに／又は、単一の共用無線機を使用する５Ｇ ＮＲ若しくはＬＴＥを使用して、通信するように構成されていてもよい。共用無線機は、無線通信を実行するために、単一のアンテナに結合してもよく、又は（例えば、ＭＩＭＯについて）複数のアンテナに結合してもよい。一般に、無線機は、ベースバンドプロセッサ、（例えば、フィルタ、ミキサ、発振器、増幅器などを含む）アナログＲＦ信号処理回路、又は（例えば、デジタル変調及び他のデジタル処理のための）デジタル処理回路の任意の組み合わせを含み得る。類似して、無線機は、上記のハードウェアを使用して１つ以上の受信及び送信チェーンを実行してもよい。例えば、ＵＥ１０４は、上記の技術などの複数の無線通信技術間で、受信及び／又は送信チェーンの１つ以上の部分を共用し得る。

いくつかの実施形態では、ＵＥ１０４は、ＵＥ１０４がそれで通信するように構成されている各無線通信プロトコルについて、（例えば、別個のアンテナ及び他の無線機構成要素を含む）別個の送信及び／又は受信チェーンを含み得る。更なる可能性として、ＵＥ１０４は、複数の無線通信プロトコル間で共用される１つ以上の無線機、及び単一の無線通信プロトコルによって排他的に使用される１つ以上の無線機を含み得る。例えば、ＵＥ１０４は、５Ｇ ＮＲ、ＬＴＥ及び／又は１ｘＲＴＴ（あるいは、ＬＴＥ又はＧＳＭ）のいずれかを使用して通信するための共有無線機と、Ｗｉ－Ｆｉ及びＢｌｕｅｔｏｏｔｈのそれぞれを使用して通信するための別々の無線機とを含み得る。他の構成も可能である。
図３－ＵＥブロック図

図３は、いくつかの実施形態による、ＵＥ１０４の例示的なブロック図を示す。図に示すように、ＵＥ１０４は、様々な目的のための部分を含み得る、システムオンチップ（ＳＯＣ）３００を含み得る。例えば、図に示すように、ＳＯＣ３００は、ＵＥ１０４のためにプログラム命令を実行し得るプロセッサ（単数又は複数）３０２、及び、グラフィック処理を実行し表示信号をディスプレイ３６０へ供給し得る表示回路３０４を含み得る。プロセッサ（単数又は複数）３０２は、メモリ管理ユニット（memory management unit、ＭＭＵ）３４０に連結してもよく、ＭＭＵ３４０は、プロセッサ（単数又は複数）３０２からアドレスを受信し、それらのアドレスを、メモリ（例えば、メモリ３０６、読み出し専用メモリ（read only memory、ＲＯＭ）３５０、ＮＡＮＤフラッシュメモリ３１０）内の位置に変換し、並びに／又は表示回路３０４、無線通信回路３３０、コネクタＩ／Ｆ３２０、及び／若しくはディスプレイ３６０などの、その他の回路若しくはデバイスに変換するように構成されてもよい。ＭＭＵ３４０は、メモリ保護及びページテーブル変換又はセットアップを実行するように構成されていてもよい。いくつかの実施形態では、ＭＭＵ３４０は、プロセッサ（単数又は複数）３０２の一部分として含まれていてもよい。

図に示すように、ＳＯＣ３００は、ＵＥ１０４の様々な他の回路に結合され得る。例えば、ＵＥ１０４は、（例えば、ＮＡＮＤフラッシュメモリ３１０を含む）様々なタイプのメモリ、（例えば、コンピュータシステム、ドック、充電ステーションなどに結合するための）コネクタインタフェース３２０、ディスプレイ３６０、及び（例えば、ＬＴＥ、ＬＴＥ－Ａ、ＬＴＥーＶ、５Ｇ ＮＲ、ＣＤＭＡ２０００、Ｂｌｕｅｔｏｏｔｈ、Ｗｉ－Ｆｉ、ＧＰＳなどのための）無線通信回路３３０を含んでもよい。ＵＥは、少なくとも１つのＳＩＭデバイスを含むこともでき、個別の国際モバイル加入者識別（ＩＭＳＩ）及び関連付けられた機能をそれぞれ提供する２つのＳＩＭデバイスを含むことができる。

図に示すように、ＵＥデバイス１０４は、基地局、アクセスポイント、及び／又は他のデバイスと無線通信を実行するための少なくとも１つのアンテナ（おそらくは、様々な可能性のうち、例えば、ＭＩＭＯ用の、及び／又は異なる無線通信技術を実施するための、複数のアンテナ）を含み得る。例えば、ＵＥデバイス１０４は、アンテナ３３５を使用して無線通信を実行し得る。

ＵＥ１０４はまた、１つ以上のユーザインタフェース要素を含むことができ、かつ／又は１つ以上のユーザインタフェース要素と共に使用するために構成することができる。ユーザインタフェース要素は、（タッチスクリーンディスプレイであってもよい）ディスプレイ３６０、（分離キーボードであってもよく、又はタッチスクリーンディスプレイの一部分として実装されてもよい）キーボード、マウス、マイクロフォン、及び／若しくはスピーカ、１つ以上のカメラ、１つ以上のボタン、並びに／又は情報をユーザに提供すること及び／又はユーザ入力を受信若しくは解釈することが可能である様々な他の要素のうちのいずれかなどの様々な要素のうちのいずれかを含んでもよい。

本明細書に記載のとおり、ＵＥ１０４は、本明細書に記載されるとおりの、より効率的な車両関連通信を実行する機能を実装するためのハードウェア及びソフトウェア構成要素を含んでもよい。ＵＥデバイス１０４のプロセッサ３０２は、例えば、メモリ媒体（例えば、非一時的コンピュータ可読メモリ媒体）に記憶されたプログラム命令を実行することによって、本明細書に記載される方法の一部又は全てを実装するように構成することができる。他の実施形態では、プロセッサ３０２は、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）などのプログラム可能ハードウェア要素として、又は特定用途向け集積回路（ＡＳＩＣ）として構成されてもよい。代替として（又は加えて）、ＵＥデバイス１０４のプロセッサ３０２は、他の構成要素３００、３０４、３０６、３１０、３２０、３３０、３３５、３４０、３５０、３６０のうちの１つ以上と連携して、本明細書で説明する機能の一部又は全てを実施するように、構成することができる。
図４－基地局ブロック図

図４は、いくつかの実施形態による、基地局１０２（例えば、図１の基地局１０２Ａ）の例示的なブロック図を示す。図４の基地局は、あり得る基地局の単なる一例に過ぎないことに留意されたい。図に示すように、基地局１０２は、基地局１０２のためのプログラム命令を実行することができるプロセッサ（単数又は複数）４０４を含んでもよい。プロセッサ（単数又は複数）４０４はまた、メモリ管理ユニット（ＭＭＵ）４４０に結合されていてもよく、このユニットは、プロセッサ（単数又は複数）４０４からアドレスを受信して、それらのアドレスをメモリ（例えば、メモリ４６０及び読み出し専用メモリ（ＲＯＭ）４５０）内の位置又は他の回路若しくはデバイスに変換するように構成されていてもよい。

基地局１０２は、少なくとも１つのネットワークポート４７０を含んでもよい。ネットワークポート４７０は、電話網に結合し、ＵＥデバイス１０４などの複数のデバイスに電話網へのアクセスを提供するように構成され得る。

ネットワークポート４７０（若しくは追加のネットワークポート）はまた、又は代替として、例えば、セルラサービスプロバイダのコアネットワークのセルラネットワークに結合するように構成されていてもよい。コアネットワークは、モビリティ関連サービス及び／又は他のサービスを、ＵＥデバイス１０４などの複数のデバイスに提供することができる。場合により、ネットワークポート４７０は、コアネットワークを介して電話網に結合することができ、及び／又はコアネットワークは、（例えば、セルラサービスプロバイダによってサービスを提供される他のＵＥデバイス間で）電話網を提供することができる。

いくつかの実施形態では、基地局１０２は、次世代基地局、例えば、５Ｇ新無線（５Ｇ ＮＲ）基地局、又は「ｇＮＢ」であってもよい。このような実施形態では、基地局１０２は、従来型進化型パケットコア（ＥＰＣ）ネットワーク及び／又はＮＲコア（ＮＲＣ）ネットワークに接続されてもよい。加えて、基地局１０２は、５Ｇ ＮＲセルと見なされてもよく、１つ以上の遷移及び受信ポイント（ＴＲＰ）を含んでもよい。加えて、５Ｇ ＮＲに従って動作することが可能であるＵＥは、１つ以上のｇＮＢ内の１つ以上のＴＲＰに接続されてもよい。

基地局１０２は、少なくとも１つのアンテナ４３４、可能な場合、複数のアンテナを含んでもよい。少なくとも１つのアンテナ４３４は、無線送受信機として動作するように構成されてもよく、無線機４３０を介してＵＥデバイス１０４と通信するように更に構成されてもよい。アンテナ４３４は、通信チェーン４３２を介して無線機４３０と通信する。通信チェーン４３２は、受信チェーン、送信チェーン、又はその両方であってもよい。無線機４３０は、ＬＴＥ、ＬＴＥ－Ａ、ＬＴＥ－Ｖ、ＧＳＭ、ＵＭＴＳ、ＣＤＭＡ２０００、５Ｇ ＮＲ、Ｗｉ－Ｆｉなどを含むがこれらには限定されない種々の無線通信規格によって、通信するように構成され得る。

基地局１０２は、複数の無線通信規格を使用して無線通信するように構成することができる。場合によっては、基地局１０２は、複数の無線機を含むことができ、複数の無線機は、基地局１０２が複数の無線通信技術に従って通信することを可能にすることができる。例えば、１つの可能性として、基地局１０２は、ＬＴＥに従って通信を実行するためのＬＴＥ無線機、並びに５Ｇ ＮＲに従って通信を実行するための５Ｇ ＮＲ無線機を含んでもよい。このような場合、基地局１０２は、ＬＴＥ基地局及び５Ｇ ＮＲ基地局の両方として動作することが可能であってもよい。別の例として、基地局１０２は、５Ｇ ＮＲに従って通信を実行するための５Ｇ ＮＲ無線機、並びに、Ｗｉ－Ｆｉに従って通信するためのＷｉ－Ｆｉ無線機を含んでもよい。このような場合、基地局１０２は、５Ｇ ＮＲ基地局及びＷｉ－Ｆｉアクセスポイントの両方として動作することができる。更なる可能性として、基地局１０２は、マルチモード無線機を含んでもよく、これによって、複数の無線通信技術（例えば、ＬＴＥとＷｉ－Ｆｉ、ＬＴＥとＵＭＴＳ、ＬＴＥとＣＤＭＡ２０００、ＵＭＴＳとＧＳＭ、など）のうちのいずれかに従って、通信を行うことができる。

本明細書に以下に更に説明するように、ＢＳ１０２は、本明細書に記載の特徴を実行する、又はそれらの実行をサポートするためのハードウェア及びソフトウェア構成要素を含むことができる。基地局１０２のプロセッサ４０４は、例えば、メモリ媒体（例えば、非一時的コンピュータ可読メモリ媒体）に記憶されたプログラム命令を実行することによって、本明細書に記載の方法のうちの一部又は全部を実装する又はこれらの実装をサポートするように構成され得る。代替として、プロセッサ４０４は、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）などのプログラム可能ハードウェア要素として、又は特定用途向け集積回路（ＡＳＩＣ）として、又はこれらの組み合わせとして構成されてもよい。代替として（又は加えて）、ＢＳ１０２のプロセッサ４０４は、他の構成要素４３０、４３２、４３４、４４０、４５０、４６０、４７０のうちの１つ以上と共に、本明細書に記載の特徴のうちの一部又は全てを実行する又はこれらの実行をサポートするように構成され得る。
図５－サイドリンクリソース管理

上述したように、ある一定のユーザデバイス（又はＵＥデバイス）は、互いに直接、すなわち、基地局１０２Ａ又はＲＳＵ１１０Ａなどの中間インフラストラクチャデバイスなしに、通信を行うことが可能であり得る。２つの車両の間、又は、車両ＵＥと歩行者ＵＥの間など、２つの無線デバイス間のこの直接通信は、サイドリンク通信と呼ばれる。別の言い方をすれば、互いにピアツーピア（直接）通信を実行している２つのＵＥデバイスはそれぞれ、「サイドリンク」インタフェースを利用してもよく、サイドリンクチャネルを介して通信していると言える。

いくつかの既存の実装形態では、サイドリンク通信の間、衝突（例えば、共有媒体にアクセスしようと試みる２つ以上の無線デバイスから発せられる送信）を回避し、媒体の利用効率を向上させるために、リッスンビフォアトーク（ＬＢＴ）メカニズムを使用して、共有媒体（例えば、Ｗｉ－Ｆｉ、Ｂｌｕｅｔｏｏｔｈ、及び他の短中距離通信、例えば非３ＧＧＰアクセスに、共通に使用される免許不要帯域など）にアクセスし得る。しかしながら、ＬＢＴメカニズムは衝突フリーではない。換言すれば、ＬＢＴメカニズムは、衝突のない送信を保証することができない。

例えば、ユニキャスト送信の場合、送信機は、受信機の肯定応答／否定応答（ＡＣＫ／ＮＡＣＫ）フィードバックに基づいて、送信衝突を容易に検出することができる。しかしながら、マルチキャスト（又はグループキャスト）送信の場合、送信機は、少なくとも部分的には、複数の受信機からのＡＣＫ／ＮＡＣＫに関連付けられたトラフィックが多いため、及び、受信したＡＣＫ／ＮＡＣＫに基づき送信衝突をチャネル品質の問題から送信機が区別できない（又は分離できない）ため、受信機のＡＣＫ／ＮＡＣＫに基づいて衝突を簡単に検出できない場合がある。換言すれば、マルチキャスト送信における受信機は異なるチャネル品質を備える異なる場所を有し得るため、ＮＡＣＫの理由（例えば、劣悪なチャネル品質に対する送信衝突）は、送信機によって判定することができない。加えて、ブロードキャスト送信の場合、受信機からのフィードバックは実行可能ではないことが知られており、したがって、このシナリオでは、送信機は衝突の知識を有さないことになる。更に、いくつかの実施態様では、送信機は、通信のための予約期間内に周期的スロットを予約することができる。そのような実施態様では、衝突が発生すると、送信機が衝突を検出しない（又は検出できない）場合に、予約期間の少なくとも一部（及び最悪ケースのシナリオでは予約期間の持続期間）にわたって、衝突が持続する可能性がある。

一例として、例えば３ＧＰＰ ＴＳ ２２．１８５ Ｖ１４．３．０によって指定されているようなビークルツーエブリシング（Ｖ２Ｘ）の通信は、車両（例えば、車両内に構成されているか車両内に現在含まれている無線デバイス、及び／又は車両に含まれているか構成されている別の送信機などの、車両内のモバイルユニット）と様々な無線デバイスとの間の通信を可能にする。例えば、図５に示すように、車両５０２ａなどの車両は、道路側ユニット（ＲＳＵ）、インフラストラクチャ（Ｖ２Ｉ）、ネットワーク（Ｖ２Ｎ）、歩行者（Ｖ２Ｐ）、及び／又は他の車両（Ｖ２Ｖ）などの様々なデバイス（例えば、デバイス５０２ｂ～ｆ）と通信し得る。加えて、図示するように、Ｖ２Ｘフレームワーク内の様々なデバイスは、他のデバイスと通信し得る。Ｖ２Ｘ通信では、長距離（例えば、セルラ）通信並びに短中距離通信（例えば、非セルラ）の両方を利用することができる。いくつかの企図される実装形態では、非セルラ通信は、免許不要帯域並びに５．９ＧＨｚにおける専用スペクトルが使用され得る。更に、Ｖ２Ｘ通信は、ユニキャスト、マルチキャスト、グループキャスト、及び／又はブロードキャスト通信を含んでもよい。各通信タイプは、ＬＢＴメカニズムを使用することができる。更に、Ｖ２Ｘ通信プロトコルの下で、送信機は、予約期間内に周期的スロットを予約することができる。したがって、上述のように、様々な場合において、Ｖ２Ｘ通信を利用する送信機は、場合によっては、ＬＢＴメカニズムの使用後に衝突を検出できない場合がある。

共有サイドリンクチャネル上の衝突防止に役立つように、ネットワーク（例えば、Ｖ２Ｘネットワーク）内の様々なＵＥは、ネットワーク支援型リソース管理と自律型（例えば、非ネットワーク支援型）リソース管理の両方について、サイドリンクリソース管理を実行してもよい。言い換えれば、様々なＵＥデバイスは、他のＵＥへの送信のためのサイドリンクリソースの使用を決定又はスケジュールするように動作してもよい。いくつかの実施形態では、ＵＥ１０６などのＵＥは、あるリソースについて、半永続的なサイドリンクスケジュールを作出してもよい。ＵＥは、リソース占有メッセージ（ＲＯメッセージ）を周期的にブロードキャストしてもよい。ＲＯメッセージは、使用される（スケジュールされた）リソースブロック（ＲＢ）及び／若しくはサブフレーム、リソース占有（例えば、予約）の周期、並びに／又はリソース占有（例えば、予約）の残り時間を含んでもよい。加えて、いくつかの実施形態では、最大許容チャネル占有時間（Ｔ＿ｍａｘ＿ＣＯＴ）が規定されてもよい。そのような実施形態では、リソース占有の初期残り時間は最大許容チャネル占有時間を超えてはならない。言い換えれば、リソース占有は、最大許容チャネル占有時間より短い時間の間のみであり得る。

いくつかの実施形態では、ＵＥが新しいシステム（例えば、ＵＥの新しいセット及び／又は新しいロケーション）に入るとき、ＵＥは、既存のＵＥ ＲＯメッセージを収集して新しいシステム内の利用可能なリソースを決定するために、チャネルを検知（リッスン）してもよい。言い換えれば、新しいＵＥのセット／エリア（例えば、サイドリンク通信のための近接性をもつＵＥのセット）に入るときにＲＯメッセージを送信する前に、ＵＥは、近隣ＵＥからのＲＯメッセージの受信を介して利用可能なリソースを決定してもよい。いくつかの実施形態では、リソース占有が満了すると、ＵＥは、新しいＲＯメッセージを送信する前に、近隣ＵＥからのＲＯメッセージの受信を介して利用可能なリソースを決定してもよい。
サイドリンクスケジューリング要求及びリソース割り当てによるユーザ機器の省電力化

いくつかの既存の実装形態では、５Ｇ ＮＲ Ｖ２Ｘは、様々なスケジューリングモードを含んでもよい。例えば、ＵＥがサイドリンク送信リソースを自己判断するために、５Ｇ ＮＲ Ｖ２Ｘモード２が設計されてもよい。５Ｇ ＮＲ Ｖ２Ｘモード２は、以下を含む様々なサブモードを含む。
モード２（ａ）：ユーザ機器デバイス（ＵＥ）が送信のためのサイドリンクリソースを自律的に選択する。
モード２（ｂ）：ＵＥが他のＵＥのためのサイドリンクリソース選択を支援する。
モード２（ｃ）：ＵＥが、サイドリンク送信のためのＮＲ構成済みグラント（例えば、ネットワーク定義された半永続的グラント）を使用して構成される。
モード２（ｄ）：ＵＥが他のＵＥのサイドリンク送信をスケジューリングする。
加えて、Ｖ２Ｘの既存の実装形態は、Ｖ２Ｘメッセージングの周期性に起因して、例えば構成済みグラントなどの半永続的スケジューリング（ＳＰＳ）をサポートすることがある。例えば、ＳＰＳにおける半永続的リソースは、ある繰り返し周期を有する不連続サブフレームのセットにわたって時間的に繰り返されるリソースを表し得る。半永続的リソースは、あるサブフレーム繰り返し期間を有する不連続サブフレームのセットにわたってスケジュールされ得る。更に、ＳＰＳ（例えば、ＬＴＥ Ｖ２Ｘ）の既存の実装形態及びその対応するリソース割り当て設計は、ブロードキャストサービスのために最適化されている。ところが、５Ｇ ＮＲ Ｖ２Ｘモード２はユニキャストサービスとグループキャストサービスの両方を更にサポートする。したがって、５Ｇ ＮＲ Ｖ２Ｘモード２でユニキャストサービス及びグループキャストサービスのための半永続的リソース割り当てを支援する方法を拡張する強い必要性がある。

ＮＲ Ｖ２Ｘ Ｒ１６では、モード１リソース割り当て方式とモード２リソース割り当て方式の両方がサポートされ得る。モード２リソース割り当て方式には、送信側ＵＥが、それ自体の検知及びリソース選択手順に基づいてサイドリンク送信リソースを選択することを伴い得る。Ｒｅｌ－１７サイドリンク拡張では、Ｒｅｌ－１４のＬＴＥサイドリンク無作為リソース選択及び部分的検知の原理をＲｅｌ－１６のＮＲサイドリンクリソース割り当てモード２に導入することによって、リソース割り当てを指定することが目的である。

上述したように、モード２を使用するとき、いくつかのＵＥでは、サイドリンク通信のために他のＵＥの潜在的なリソースを特定して利用するために、比較的高い周波数のサイドリンクチャネル上で検知動作を周期的に実行する必要があり得る。そのような能動的な検知は、例えば電力などのデバイスリソースを比較的高率で消費し得る。しかし、検知動作を部分的な検知の状態（ＵＥが受信しているサブフレームのサブセットのみを監視するなど）に低減するという選択肢をとっても、やはりエネルギーは消費される。更に、検知を実行しないという選択肢（例えば、無作為なリソース選択）では、リソース衝突の見込みが高くなり得る。

この潜在的に高いリソース使用量及び潜在的に高い電力消費率は、Ｖ２Ｘシステムに参加する、ある一定のデバイスに重い負担をかけ得る。大規模なリソース及び電力能力を有し得る、例えばバッテリ駆動ではない、基地局及び路側ユニット（ＲＳＵ）などのインフラストラクチャデバイスでは、この高いリソース使用量は、あまり懸念されないこともある。同様に、広範な電力能力へのアクセスも有し得る、ある一定の車両デバイスでは、あまり懸念されないこともある。ところが、利用可能なサイドリンクリソースについてサイドリンクチャネルを検知することに伴う潜在的に高い電力消費は、他のＶ２Ｘ通信に並び、Ｖ２Ｘネットワークに参加しているある種のハンドヘルド又はポータブルバッテリ駆動デバイス、すなわち、ある種のユーザ機器（ＵＥ）デバイスに過度の負担をかけることがある。Ｖ２Ｘシステム内のＵＥは、歩行者又は他の人によって携行又は装着されるＵＥであり得、ここで、歩行者ＵＥ（ＰＵＥ）という用語は、上記で説明したように、静止中、歩行中、走行中、サイクリング中などであり得る人物によって携行されているＵＥを含む。

したがって、ＵＥは一般にリソースが限られている（バッテリ駆動であり、したがって電力が限られている）ため、ＵＥ、特にＰＵＥを含むＶ２Ｘシステムでは電力節約及び通信技術の改善が望まれ得る。このことは、ウェアラブルＵＥ、例えば、スマートウォッチ又はスマートグラスなどの、更に電力の制限が高いデバイスに特に当てはまる。

いくつかの実施形態では、「スレーブＵＥ」と呼ばれる第１のＵＥが、「マスタＵＥ」と呼ばれる第２のＵＥに、利用可能なサイドリンクリソースを決定する作業をオフロードすることを要求してもよい。第１のＵＥによって行われる要求は、スケジューリング要求の形であってもよい。別の言い方をすれば、第１のＵＥは電力が制限されているため、いくつかの通信又は検知の責任を、電力の制限が少ないマスタＵＥにオフロードすることによって電力消費を低減しようとしてもよい。この責任をオフロードするために、第１のＵＥはマスタＵＥにサイドリンクスケジューリング要求を送信する。より具体的には、サイドリンクスケジューリング要求の確立によって、マスタＵＥとスレーブＵＥとの間のＵＥ間協調が可能になり、マスタＵＥが、リソース割り当て及び検知のプロトコルに関して第１のＵＥに通信し、命令できるようになる。ＵＥ間協調の例には、リソースのセットがマスタＵＥ（ＵＥ－Ｂ）によって決定されることもあり得る。次いで、このセットが第１のＵＥ（ＵＥ－Ａ）（モード２で動作中）に送信され、次にＵＥ－Ａは、それ自体の送信のためのリソース選択において、この受信したリソースセットを考慮に入れる。このＵＥ間協調の効果は、リソース割り当て及び検知に関係する、分担された、又は指令された責任による信頼性の向上に加えて、第１のＵＥの電力消費及びレイテンシの低減をもたらすと意図されている。

いくつかの実施形態では、スレーブＵＥは電力が制限されていることがあるので、スケジューリング情報を受信するため、すなわち、そのスケジューリング情報を決定する作業をオフロードするために、マスタＵＥに接続することを試みてもよい。マスタＵＥは、スレーブＵＥよりも多くの利用可能な電力を有することがあり、したがって、スレーブＵＥの電力利用を低減するためにスレーブＵＥにスケジューリング情報を与えてもよい。一例として、例えば、マスタＵＥが車両ＵＥ又はＲＳＵであり得るなど、マスタＵＥは電力が制限されていないことがある。あるいは、マスタＵＥもまた電力が制限されてはいるが、電力制限が比較的緩いこともある。例えば、スレーブＵＥはスマートウォッチなどのウェアラブルデバイスであってもよく、マスタＵＥはスマートフォンであってもよい。更に、前述のマスタ及びスレーブの関係は、スマートウォッチなどのウェアラブルデバイスであるスレーブＵＥ及びスマートフォンであるマスタＵＥ、又は、スマートフォンであるスレーブＵＥ及びマスタＶＵＥに言及した上記の例に限定されるべきではない。更に、スレーブＵＥとマスタＵＥとの間の接続は、１対１である必要はない。いくつかの態様では複数のスレーブＵＥが単一のマスタＵＥと接続されてもよく、他の実施形態では複数のマスタＵＥが単一のスレーブＵＥと接続されてもよい。
図６－スレーブＵＥデータ送信

図６は、いくつかの実施形態による、ＵＥデータ送信の例示的な手順を示す。

まずステップ６０２で、スレーブＵＥはマスタＵＥとの間にマスタ／スレーブ通信を構成するために、マスタＵＥとのサイドリンクスケジューリング構成情報を送信してもよい。サイドリンクスケジューリング構成情報は、サイドリンク制御情報（ＳＣＩ）に含まれてもよく、例えば、リソースブロック割り当て、変調及び符号化の方式、グループ宛先ＩＤ（サイドリンク通信用）、及びＰｒｏＳｅパケット単位優先度（ProSe Per－Packet Priority：ＰＰＰＰ、Ｖ２Ｘサイドリンク通信用）を詳述してもよい。加えて、サイドリンクスケジューリング要求（Ｓ－ＳＲ）の構成には、ＵＥのペアが、特定のＳ－ＳＲリソース、すなわちスケジューリング要求（オフロード要求）の将来の送信のために使用すべきリソースを構成する必要を伴うことがあり、そのリソースは、時間リソース、周波数リソース、又は符号化情報から成り得る。

Ｓ－ＳＲリソース構成には、構成されるべきスロットオフセット値、Ｓ－ＳＲの周期、ＱｏＳ、Ｓ－ＳＲの特定のＰＲＢ、又はＳ－ＳＲシーケンスの巡回シフトに関する情報もまた含まれ得る。更に、ＵＥのペア間のＳ－ＳＲの構成には、推奨リソースサイズ（例えば、サブチャネルの数）、ブラインド再送回数、データＱｏＳ、ＭＣＳテーブル、ＤＭＲＳポート、電力制御パラメータ（例えば、公称電力（Ｐ_ｏ，ＳＬ）又はＳＬ経路損失スケーリング係数（α_ＳＬ））などのサイドリンクデータ送信パラメータも含まれ得る。

ステップ６０４で、スレーブＵＥは、低減検知モード（すなわち、スリープモード）に入ってもよく、したがって、通常行われるように完全な検知を行わなくてもよい。部分的検知の場合、スレーブＵＥは利用可能なサブフレームのサブセットのみを監視してもよい。スレーブＵＥは、電力消費を低減し、バッテリ寿命を延長するために、低減電力モードに入ってもよい。上記で簡単に説明したように、スレーブＵＥは電力が制限されていることがあるため、以下で更に説明するように、通信又は検知の責任を、電力の制限が少ないマスタＵＥにオフロードすることによって電力消費を低減しようとしてもよい。

次にステップ６０６で、スレーブＵＥは、マスタＵＥ又は他のＵＥにリダイレクトされるべきサイドリンクデータ（例えば、ＶＵＥ、ＰＵＥ、又は他のＵＥからの）を集積してもよい。このサイドリンクデータは、運動情報（例えば、速度、加速度、及び／又はブレーキの状態）、位置又はロケーションの情報（例えば、緯度及び経度、高度など）、並びに他の詳細など、ネットワーク内の異なるＵＥに関係する情報を含むこともできる。

ステップ６０８で、スレーブＵＥは、このサイドリンクデータを送信するために、サイドリンクスケジューリング要求（Ｓ－ＳＲ）をマスタＵＥに送信してもよい。より具体的には、スレーブＵＥは、スレーブＵＥによって使用可能なスケジューリングリソースを決定する作業を別のデバイス（例えば、マスタデバイス）にオフロードするために、サイドリンクスケジューリング要求を送信してもよい。したがって、サイドリンクスケジューリング要求（Ｓ－ＳＲ）は、オフロード要求と呼ばれてもよく、より適切には、「サイドリンクリソース決定オフロード要求」として特徴付けられ得る。

図７で説明されるように、マスタＵＥは、スレーブＵＥからＳ－ＳＲを受信したことに応答して、サイドリンクチャネル上での第２のＵＥによる使用のためのサイドリンク送信リソースのセットを決定してもよい。このサイドリンク送信リソースのセットは、スロット又は物理リソースブロック（ＰＲＢ）に対応する時間、周波数、及び／又は符号のセットであってもよい。この決定されたリソース情報を使用して、マスタＵＥは、どのリソースを推奨したか、及びリソースが予約されているか予約されていないかをスレーブＵＥに通信することができる。

更に、スレーブＵＥがマスタＵＥにＳ－ＳＲを送信した後、スレーブＵＥは、マスタＵＥから推奨リソースを受信するためにチャネルを監視してもよい。この監視窓は事前構成されていてもよく、リソースプールごとに構成されてもよく、又は、ＰＣ５－ＲＲＣによって構成されてもよい。加えて、監視窓のサイズはＳ－ＳＲの周期に依存してもよく、いくつかの実施形態では、監視窓はＳ－ＳＲの周期に等しくてもよい。更に、スレーブＵＥが、推奨されたリソースについてのマスタＵＥからの送信を監視窓の後で受信しない場合、スレーブＵＥは、別のＳ－ＳＲを送信してもよい。

ステップ６１０で、スレーブＵＥはマスタＵＥから推奨リソースを受信する。スレーブＵＥによって受信された推奨リソースは、６０８で送信されたスケジューリング要求に応答したものである。マスタＵＥは、推奨リソースの数、現在のスロットと第１の推奨スロットとの間の時間間隔、並びに、第１の推奨スロットのサブチャネルインデックス及びサブチャネル番号を含め、推奨リソースのソースＩＤ及び宛先ＩＤを示すために、ＳＣＩステージ２フォーマットを利用してもよい。スレーブＵＥは、この情報を使用して、マスタＵＥ又は他のＵＥに送信しようとしているサイドリンクデータに関して、より効果的にマスタＵＥ又は他のＵＥと通信することができる。更に、マスタＵＥの推奨には、送信／受信シンボル衝突の可能性、及びその衝突を回避するための推奨リソースがあらかじめ考慮されていてもよい。これにより、マスタＵＥとスレーブＵＥとの間の通信がより効率的になる。重要なことに、スレーブＵＥは、これらの利用可能なリソースを検知／決定する際に、それ自体の電力又はリソースを費やす必要なく、これらの推奨リソースを受信及び使用することができる。

更に、推奨リソースの中から更に選択することも可能である。例えば、スレーブＵＥは、マスタＵＥによって推奨されるリソースの全てを直接使用してもよい。他の態様では、マスタＵＥはＮ個のリソースユニットを推奨してもよく、スレーブＵＥはＭ個のリソースユニットを無作為に選択してもよく、ここで、ＭはＮ以下である。更に、別の態様では、スレーブＵＥは、Ｎ個の推奨されたリソースから、完全又は部分的な検知に基づいてＭ個のリソースユニットを選択してもよい。加えて、他の態様では、スレーブＵＥが監視窓の間にサイドリンクチャネルを測定しないこともある。この例では、監視窓の間にスレーブＵＥがマスタＵＥからの推奨リソースに関する送信を受信する場合、スレーブＵＥは、マスタＵＥからの推奨リソースを使用して後続のサイドリンクデータを送る。

最後にステップ６１２で、スレーブＵＥは、推奨リソースに基づいて、又は推奨リソースを使用して、サイドリンクデータをマスタＵＥに送信する。上記で説明したように、サイドリンクデータは、運動情報（例えば、速度、加速度、及び／又はブレーキの状態）、位置又はロケーションの情報（例えば、緯度及び経度、高度など）、並びに他の詳細など、ネットワーク内の異なるＵＥに関係する情報を含むこともできる。

図７－マスタＵＥデータ送信

図７は、いくつかの実施形態による、マスタＵＥデータ送信の手順例を示す。より具体的には、図７は、第１のＵＥからスケジューリング要求を受信したことに応答する、すなわち、６０８で送信されたスケジューリング要求（オフロード要求）に応答するマスタＵＥの動作を示す。

まずステップ７０２で、マスタＵＥは、６０２で上述したように、スレーブＵＥとの間でマスタ／スレーブ通信を確立するために、スレーブＵＥとのサイドリンクスケジューリング要求を構成してもよい。したがって、７０２のマスタＵＥ動作は、Ｓ－ＳＲリソースの構成に関連しており、６０２のスレーブＵＥ動作と連係して実行される。

更に、ＵＥのペア間のＳ－ＳＲの構成には、推奨リソースサイズ（例えば、サブチャネルの数）、ブラインド再送回数、データＱｏＳ、ＭＣＳテーブル、ＤＭＲＳポート、電力制御パラメータ（例えば、公称電力（Ｐ_ｏ，ＳＬ）又はＳＬ経路損失スケーリング係数（α_ＳＬ））などのサイドリンクデータ送信パラメータ構成も含まれ得る。

本明細書で説明するように、スレーブＵＥは電力が制限されているため、通信又は検知の責任を、電力の制限が少ないマスタＵＥにオフロードすることによって電力消費を低減しようとしてもよい。より具体的には、サイドリンクスケジューリング要求のためのリソースの確立によって、リソース割り当て及び検知のプロトコルに関して通信し、命令を提供するように、マスタＵＥとスレーブＵＥとの間のＵＥ間協調が可能になる。より具体的には、サイドリンクスケジューリング要求のためのリソースの確立によって、第１のＵＥ（スレーブＵＥ）が、自身に代わってサイドリンクリソース決定を実行するようにマスタＵＥに要求できるようになる。

次にステップ７０４で、マスタＵＥは、近くのＵＥ、及びそれらのそれぞれの利用可能又は利用不可能なリソースを検出して特定するために、検知（又は部分的検知）を実行してもよい。部分的検知の場合、ＵＥはサブフレームのサブセットのみを監視してもよい。通常はスレーブＵＥに関連する検知作業を実行することによって、マスタＵＥはスレーブＵＥの検知責任を軽減することができる。これにより、スレーブＵＥがより効率的に電力を節約できるようになるだけでなく、通信信頼性の強化及びレイテンシの低減に関する他の改善もまた、もたらされ得る。具体的には、マスタＵＥは第１のＵＥよりも電力が制約されていない（又は電力の制約が少ない）ので、マスタＵＥはより包括的な検知を実行できる場合があり、よって、マスタＵＥは、第１のＵＥによって生成できるものよりも信頼性の高い、利用可能な（候補の）リソースのセットを生成することができ得る。

ステップ７０６で、マスタＵＥは、スレーブＵＥからサイドリンクスケジューリング要求を受信し、このことは、サイドリンクデータをスケジューリングして、スレーブＵＥから受信しようとする試みと連係してもよい。マスタＵＥは、スレーブＵＥからＳ－ＳＲを受信したことに応答して、サイドリンクチャネル上での第２のＵＥによる使用のためのサイドリンク送信リソースのセットを、例えば７０４で実行した検知に基づいて、決定してもよい。このサイドリンク送信リソースのセットは、スロット又は物理リソースブロック（ＰＲＢ）に対応する時間、周波数、及び符号のセットであってもよい。

ステップ７０８で、マスタＵＥは、決定されたサイドリンク送信リソースのセットに関する情報をスレーブＵＥに送信する。言い換えれば、マスタＵＥは、推奨リソースをスレーブＵＥに送信する。マスタＵＥは、所望のサイドリンク通信又はデータを折り返し受信するために、この決定されたリソース情報をスレーブＵＥに提供してもよい。更に、マスタＵＥは、ＳＣＩステージ２フォーマットを利用して、推奨リソースの数、現在のスロットと第１の推奨スロットとの間の時間間隔、並びに、第１の推奨スロットのサブチャネルインデックス及びサブチャネル番号を含め、１つ以上の複数の推奨リソースのソースＩＤ及び宛先ＩＤを示してもよい。例えば、マスタＵＥが受信を望んでいた、特定の、又は優先順位付けされた情報があった場合、マスタＵＥは、ある一定の好ましい、又は推奨されるリソースを、スレーブＵＥが利用するように、スレーブＵＥに示してもよい。いくつかの態様では、マスタＵＥはスレーブＵＥにサイドリンクスケジューリング要求を送信して、より多くの完全検知又は部分的検知動作を再開することのできる非省電力モードに戻るようにスレーブＵＥに命令、すなわち「ウェイクアップ」してもよい。他の実施形態では、決定されたサイドリンク送信リソースのセットは、予約されたリソースではなく、推奨されるリソースであってもよい。あるいは、マスタＵＥによってスレーブＵＥに提供される、決定されたサイドリンク送信リソースのセットは、推奨と予約の両方がなされたリソースであってもよい。

図６に関して上記で簡単に説明したように、マスタＵＥがスレーブＵＥからＳ－ＳＲを受信した後に、マスタＵＥはスレーブＵＥにリソースを推奨してもよい。この送信のＰＤＢ（packet delay budget、パケット遅延許容時間）はリソースプールごとに事前構成されてもよいし、又はＰＣ５－ＲＲＣによって構成されてもよく、この送信のＰＤＢに基づいてリソース選択窓が決定されてもよい。加えて、この送信のデータ優先度は、Ｓ－ＳＲによって示されるデータ優先度レベルに依存してもよいし、リソースプールごとに事前構成されてもよいし、又は、（ＰＤＢと同様に）ＰＣ５－ＲＲＣによって構成されてもよい。

更に、マスタＵＥによって提供される推奨リソースは、スレーブＵＥが推奨リソースの中から更なる選択を実行できるようになっていてもよい。例えば、マスタＵＥは、あるリソース数Ｎを推奨して、その数の中で、スレーブＵＥがマスタによって推奨されたリソースの全てを直接使用してもよい。あるいは、スレーブＵＥはＭがＮ以下であるＭ個のリソースユニットを無作為に選択してもよいし、又は、スレーブＵＥは完全検知又は部分的検知に基づいて、Ｎ個の推奨リソースからＭ個のリソースユニットを選択してもよい。更に、マスタＵＥが監視窓内でスレーブＵＥに推奨リソースについて送信を送ると、スレーブＵＥは、マスタＵＥからの推奨リソースを使用して後続のサイドリンクデータを送信してもよい。

最後にステップ７１０で、マスタＵＥはスレーブＵＥから推奨リソース上でサイドリンクデータを受信する。上記で説明したように、この受信されたサイドリンクデータは、スレーブＵＥの運動又は運行情報（例えば、速度、加速度、及び／又はブレーキの状態）、スレーブＵＥの位置又はロケーション情報（例えば、緯度及び経度、高度など）、並びに他の詳細など、様々なデータを含んでもよい。
図８－サイドリンクスケジューリング要求信号の構造

図８は、いくつかの実施形態による、サイドリンクスケジューリング要求（Ｓ－ＳＲ）信号の構造例を示す。詳細には、図８は、Ｓ－ＳＲ信号システム設計のリソース及び構造、すなわち、Ｓ－ＳＲ信号をＰＳＦＣＨ（物理サイドリンクフィードバックチャネル）などの他のシグナリングにどのように組み込むことができるかを示す。Ｓ＿ＳＲのリソースに関して、ある一定の周波数におけるスロットの最後のシンボルはＰＳＦＣＨのために予約されていないことがあり、したがって、Ｓ＿ＳＲ信号を送信する際に使用するために再利用され得る。これらのシンボルは、ＰＳＦＣＨリソースを用いて周波数分割多重化（ＦＤＭ）されてもよく、他のＰＳＦＣＨリソースと同じ又は異なる周期を有してもよい。更に、Ｓ－ＳＲの送信及び受信は、ＰＳＣＣＨ又はＰＳＳＣＨ信号の送信及び受信よりも少ない電力を消費し得る。

構造に関して、それぞれのＳ－ＳＲ信号は、１つのＰＲＢ及び２つのシンボルを占有し得る（ＰＳＦＣＨと同様）。加えて、シーケンス（巡回シフトを伴う）は選択に基づき得る（ＮＲ ＰＵＣＣＨフォーマット０と同様）。更に、Ｓ－ＳＲ信号巡回シフトは、符号領域の多重化に基づいてもよい。いくつかの実施形態では、Ｓ－ＳＲリソース構成は、ＡＣＫのみのシーケンス（すなわち、事前構成された巡回シフトを有する単一のシーケンス）に相当するＳ－ＳＲの巡回シフトとして符号化されてもよい。この例では、シーケンスの送信が肯定のサイドリンクＳＲを示してもよく、シーケンス送信の不在又は欠如が否定のサイドリンクＳＲを示してもよい。他の態様によれば、Ｓ－ＳＲリソース構成は、ＡＣＫ／ＮＡＣＫシーケンス（すなわち、事前構成された巡回シフトのペアを有する２つのシーケンス）に対するＳ－ＳＲの巡回シフトのペアとして符号化されてもよい。この例では、一方の巡回シフトを有するシーケンスの送信が肯定のサイドリンクＳＲを示してもよく、他方の巡回シフトを有するシーケンスの送信が否定のサイドリンクＳＲを示してもよい。

更に構造に関して、Ｓ－ＳＲリソース構成は、Ｓ－ＳＲのある１つのシーケンスを示す構成インデックスとして符号化されてもよい。この例では、複数のシーケンスが複数の巡回シフトを用いて構成されてもよく、各シーケンスは構成インデックスに関連付けられていてもよい。更に、Ｓ－ＳＲのシーケンス又はシーケンスペアは、サイドリンクデータ送信パラメータに対応する構成に関連付けられていてもよい。更に、各構成インデックスは、リソース周期、サブチャネルの数、及び／又はリソースの数などのサイドリンクデータ送信パラメータに対応していてもよい。他の態様では、それぞれの構成インデックスは、ある１つのデータＱｏＳ又は異なるキャストタイプに対応していてもよい。いくつかの実施形態では、構成インデックスによって示されるシーケンスと、事前構成された巡回シフトのペアを有するシーケンス（すなわち、ＡＣＫ／ＮＡＣＫシーケンス）との組み合わせもまた、Ｓ－ＳＲ構造によってサポートされ得る。
図９－サイドリンクスケジューリング要求信号の周波数リソース及び符号リソース

図９は、いくつかの実施形態による、サイドリンクスケジューリング要求（Ｓ－ＳＲ）信号の周波数リソース及び符号リソースを示す。より具体的には、図９は、Ｓ－ＳＲの周波数リソース及び符号リソースが、スケジューリングされるＵＥ（すなわち、宛先ＩＤ）のＩＤ、及び／又はスケジューリングするＵＥ（すなわち、ソースＩＤ）のＩＤに依存することを示す。更に、Ｓ－ＳＲリソースを決定するとき、最初のステップはソースＩＤと宛先ＩＤとを組み合わせることであり得る。いくつかの態様では、これは、宛先ＩＤとソースＩＤとを連結することを伴い得る。他の態様では、これは、ソースＩＤと宛先ＩＤとを連結することを伴い得る。いくつかの態様では、Ｓ－ＳＲリソースを決定するときの最初のステップは、排他的論理和（ＸＯＲ）演算の使用によってソースＩＤと宛先ＩＤとを組み合わせることを伴い得る。

Ｓ－ＳＲリソースを決定する際の２番目のステップは、周波数及び符号領域のＳ－ＳＲリソースの総数を計算することを含み得る。いくつかの実施形態では、これは、第１に周波数、第２に符号のインデックス付けを伴い得る。他の態様では、これは、第１に符号、第２に周波数のインデックス付けを伴い得る。

次に、上記の最初のステップから得られた組み合わせＩＤに対して周波数－符号領域Ｓ－ＳＲリソースの総数でモジュロ演算を実行することによって、周波数－符号領域Ｓ－ＳＲリソースＩＤが決定され得る。

最後に、ＵＥは次いで、決定されたＳ－ＳＲリソースＩＤ上でＳ－ＳＲを送信又は受信し得る。
図１０－マスタＵＥが予約されていないリソースを推奨する

図１０は、いくつかの実施形態による、マスタＵＥが推奨されるが予約されていないリソースをスレーブＵＥに提供する様子の例を示す。例えば、マスタＵＥがスレーブＵＥからＳ－ＳＲを受信した後、マスタＵＥは次いで、マスタＵＥの検知動作に基づく推奨リソースを示すためにシグナリングを送信してもよい。加えて、ＰＳＳＣＨ受信及び送信の半二重問題を回避するために、マスタＵＥは、マスタＵＥの既存のスケジューリングに基づく推奨リソースを示すためにシグナリングを送信してもよい。更に、マスタＵＥによって送信される推奨リソースは、符号化され、ＰＳＳＣＨデータとして配信されてもよい。

例えば図１０に示すように、最初のリソースボックス（左上）は、左側の矢印によって示すように、ＰＳＣＣＨデータを含んでもよい。このＰＳＣＣＨデータは、最初のリソースボックスのリソースだけを示すために使用される、リソース予約情報を含んでもよい。このリソース予約情報は、他の２つのリソースボックスを示すためには使用されない。

一方、ＰＳＳＣＨボックスについてのＳＣＩステージ２は、他の２つのリソースボックス（中央及び右）を示すために使用されるリソース推奨情報を含んでもよい。図１０の右側の２つの矢印は、ＰＳＳＣＨボックスについてのＳＣＩステージ２に含まれるリソース推奨情報を示す。言い換えれば、右側の２つの矢印は、マスタＵＥが、推奨されているが予約されていないリソースをＰＳＳＣＨのＳＣＩステージ２を介して示すことに対応し得る。これらの推奨リソースは予約されていない（ＰＳＣＣＨ内で）ので、他のＵＥはこれらのリソースの使用を試みてもよい。

他の態様では、マスタＵＥによって送信される推奨リソースは、ＳＣＩステージ２フォーマットで配信されてもよい。更に、ＳＣＩステージ２フォーマットは、推奨リソースのソースＩＤ及び宛先ＩＤを示すために使用されてもよい。更に、推奨リソースの数、現在のスロットと第１の推奨スロットとの間の時間間隔、並びに、第１の推奨スロットのサブチャネルインデックス及びサブチャネル番号を含め、最大３つの別個のリソースが、ＳＣＩステージ２フォーマットで示されてもよい。更に、ＳＣＩステージ２フォーマットが２つ以上の推奨リソースを示す場合、残りのリソースは、ＦＲＩＶ（frequency resource indicator value：周波数リソース指示値）及びＴＲＩＶ（time resource indicator value：時間リソース指示値）として示される。

更に、スレーブＵＥの動作を軽減するために、他のサイドリンクデータ送信パラメータをＳＣＩステージ２で示すことができる。例えば、ＨＡＲＱフィードバックに並び、変調及び符号化の方式（ＭＣＳ）、ＭＣＳテーブル、ＤＭＲＳポートが、このタイプでは常にＳＣＩステージ２に有効化されていてもよい。更に、チャネルビジー無線（ＣＢＲ）レベルなどのＣＢＲ関連情報、及び電力制御情報（例えば、サイドリンク経路損失ＰＬ_ＳＬ、サイドリンク経路損失スケーリング係数α_ＳＬ）が示されてもよく、又は電力レベルが直接送信されてもよい。
図１１－マスタＵＥが予約されたリソースを推奨する

図１１は、いくつかの実施形態による、マスタＵＥが、予約されたリソースの所有権の移転に加えて、推奨及び予約されたリソースをスレーブＵＥに提供する様子の例を示す。例えば、マスタＵＥがスレーブＵＥからＳ－ＳＲを受信した後、マスタＵＥは次いで、マスタＵＥの検知動作に基づく推奨リソースを示すためにシグナリングを送信してもよい。これらの推奨リソースは、予約されたリソースであってもよい。いくつかの実施形態では、リソース予約情報はＰＳＣＣＨデータにのみ含まれてもよい。この例では、どのリソースが予約されているかを知るために、別のＵＥがＰＳＣＣＨを受信する。

更にマスタＵＥは、ステップ１１０２に示すように、ＳＣＩステージ１を利用して、スレーブＵＥの送信のための１つ以上の予約されたリソースを示してもよい。更に、構成されたサイドリンクデータＱｏＳとしてＱｏＳが送信されてもよく、予約されたリソースの所有者を示す追加のビットもまた、マスタＵＥとスレーブＵＥとの間で交換されてもよい。

予約されたリソースの所有権を移転するために、ステップ１１０４でＨＡＲＱ－ＡＣＫを受信した後、マスタＵＥは、スレーブＵＥによって使用される予約されたリソースは、そこでマスタＵＥがデータを受信することのできる予約されたリソースであると決定してもよい。マスタＵＥは次いで、ステップ１１０６に示すように、残りの予約されたリソースをスレーブＵＥに移転してもよい（すなわち、所有権の移転）。そうすることで、スレーブＵＥは次いで、新しく移転された予約されたリソースを使用して適切なサイドリンクデータを送信し得る。一方、ＨＡＲＱ－ＮＡＣＫが受信された場合、マスタＵＥは、予約されたリソースはスレーブＵＥによって使用されないと決定してもよい。この場合、マスタＵＥは、より多くの推奨及び予約されたリソースを含み得る情報が包含された別の送信をスレーブＵＥに送信してもよい。言い換えれば、ステップ１１０８に示すように、マスタＵＥは、次の予約されたリソースを使用して、スレーブＵＥへの情報（より多くの新しいリソースが予約され得る）を包含する追加の送信を送信してもよい。

本開示の実施形態は、任意の様々な形態で実現されてもよい。例えば、いくつかの実施形態は、コンピュータにより実施される方法、コンピュータ可読メモリ媒体、又はコンピュータシステムとして実現することができる。他の実施形態は、ＡＳＩＣなどの１つ以上のカスタム設計されたハードウェアデバイスを使用して実現されてもよい。更なる他の実施形態は、ＦＰＧＡなどの１つ以上のプログラム可能ハードウェア要素を使用して実現されてもよい。

いくつかの実施形態では、非一時的コンピュータ可読メモリ媒体は、非一時的コンピュータ可読メモリ媒体がプログラム命令及び／又はデータを記憶するように構成されてもよく、プログラム命令は、コンピュータシステムによって実行された場合、コンピュータシステムに、方法、例えば、本明細書に記載の方法実施形態のうちのいずれか、又は本明細書に記載の方法実施形態の任意の組み合わせ、又は本明細書に記載の方法実施形態のうちのいずれかの任意のサブセット、又はこのようなサブセットの任意の組み合わせを実行させる。

いくつかの実施形態では、デバイス（例えば、ＵＥ１０４）は、プロセッサ（又はプロセッサのセット）及びメモリ媒体を含むように構成されてもよく、ここで、メモリ媒体は、プログラム命令を記憶し、プロセッサは、メモリ媒体からプログラム命令を読み込み、実行するように構成され、プログラム命令は、本明細書に記載された種々の方法の実施形態の任意のもの（又は、本明細書に記載された方法の実施形態の任意の組み合わせ、又は、本明細書に記載された方法の実施形態のいずれかの任意のサブセット、又は、このようなサブセットの任意の組み合わせ）を実施するために実行可能である。デバイスは、様々な形態のいずれにおいて実現されてもよい。

上記の実施形態は、かなり詳細に記載されているが、上記の開示が完全に理解されれば、多数の変形形態及び修正形態が当業者には明らかになる。以下の特許請求の範囲は、全てのそのような変形形態及び修正形態を包含すると解釈されることが意図されている。

Claims (35)

1. ユーザ機器（ＵＥ）であって、
   少なくとも１つのアンテナと、
   前記少なくとも１つのアンテナに動作可能に結合された無線と、
   前記無線に動作可能に結合されたプロセッサと、
   を備え、
   前記ＵＥが、
   第２のＵＥに、スケジューリング要求であって、前記ＵＥによる使用のためのサイドリンク送信リソースのセットを前記第２のＵＥに決定させるように構成された前記スケジューリング要求を送信し、
   前記第２のＵＥから、決定されたサイドリンク送信リソースのセットであって、前記送信されたスケジューリング要求に基づいて決定された前記サイドリンクリソースのセットに関する情報を受信し、
   前記決定されたサイドリンク送信リソースのセットの少なくともサブセットを使用して、サイドリンク通信を送信するように構成されている、
   ＵＥ。
2. 前記決定されたサイドリンク送信リソースのセットが、推奨された、予約されていないリソースである、
   請求項１に記載のＵＥ。
3. 前記決定されたサイドリンク送信リソースのセットが、推奨及び予約されたリソースである、
   請求項１に記載のＵＥ。
4. 前記ＵＥが、前記第２のＵＥにＨＡＲＱ－ＡＣＫを送信したことへの応答に少なくとも部分的に基づいて、前記第２のＵＥから前記予約されたリソースのうち１つ以上を受信するように構成されている、
   請求項３に記載のＵＥ。
5. 前記ＵＥが、前記第２のＵＥにＨＡＲＱ－ＮＡＣＫを送信したことに応答して、前記第２のＵＥから前記決定されたサイドリンク送信リソースのセットに関する情報を、１つ以上の追加の予約されたリソースを使用して受信するように更に構成されている、
   請求項３に記載のＵＥ。
6. 前記ＵＥが、
   構成情報であって、前記スケジューリング要求の送信に使用される送信リソースを指定する前記構成情報を、前記第２のＵＥに送信するように更に構成されている、請求項１に記載のＵＥ。
7. 前記ＵＥが、前記スケジューリング要求を、ＡＣＫのみのシーケンスに相当するＳ－ＳＲの巡回シフトとして符号化するように構成されている、請求項６に記載のＵＥ。
8. 前記ＵＥが、前記スケジューリング要求を、ＡＣＫ／ＮＡＣＫシーケンスに相当する前記Ｓ－ＳＲの巡回シフトペアとして符号化するように構成されている、請求項６に記載のＵＥ。
9. 前記ＵＥが、前記スケジューリング要求を、前記Ｓ－ＳＲのある１つのシーケンスを示す構成インデックスとして符号化するように構成され、前記Ｓ－ＳＲの各シーケンスが１つの構成に関連付けられている、請求項６に記載のＵＥ。
10. 前記ＵＥが、前記決定されたサイドリンク送信リソースのセットの到着について無線チャネルを監視する、請求項１に記載のＵＥ。
11. ユーザ機器（ＵＥ）における使用のために構成されたベースバンドプロセッサであって、
    制御回路を備え、前記制御回路が、
    第２のＵＥに、スケジューリング要求であって、前記ＵＥによる使用のためのサイドリンク送信リソースのセットを前記第２のＵＥに決定させるように構成された前記スケジューリング要求を送信し、
    前記第２のＵＥから、決定されたサイドリンク送信リソースのセットであって、前記送信されたスケジューリング要求に基づいて決定された前記サイドリンクリソースのセットに関する情報を受信し、
    前記決定されたサイドリンク送信リソースのセットの少なくともサブセットを使用してサイドリンク通信を送信するように構成されている、
    ベースバンドプロセッサ。
12. 前記決定されたサイドリンク送信リソースのセットが、推奨された、予約されていないリソースである、
    請求項１１に記載のベースバンドプロセッサ。
13. 前記決定されたサイドリンク送信リソースのセットが、推奨及び予約されたリソースである、請求項１１に記載のベースバンドプロセッサ。
14. 前記ベースバンドプロセッサが、前記第２のＵＥにＨＡＲＱ－ＡＣＫを送信したことに部分的に応答して、前記第２のＵＥから、前記予約されたリソースのうち１つ以上を受信するように更に構成されている、
    請求項１３に記載のベースバンドプロセッサ。
15. 前記ベースバンドプロセッサが、前記第２のＵＥにＨＡＲＱ－ＮＡＣＫを送信したことに応答して、前記第２のＵＥから、前記決定されたサイドリンク送信リソースのセットに関する情報を、１つ以上の追加の予約されたリソースを使用して受信するように更に構成されている、
    請求項１３に記載のベースバンドプロセッサ。
16. 前記ベースバンドプロセッサが、
    前記第２のＵＥに、構成情報であって、前記スケジューリング要求を送信する際に使用される送信リソースを構成する前記構成情報を送信するように更に構成されている、
    請求項１１に記載のベースバンドプロセッサ。
17. 前記ベースバンドプロセッサが、前記スケジューリング要求を、ＡＣＫのみのシーケンスに相当するＳ－ＳＲの巡回シフトとして符号化するように構成されている、請求項１６に記載のベースバンドプロセッサ。
18. 前記ベースバンドプロセッサが、前記スケジューリング要求を、ＡＣＫ／ＮＡＣＫシーケンスに相当する前記Ｓ－ＳＲの巡回シフトペアとして符号化するように構成されている、請求項１６に記載のベースバンドプロセッサ。
19. 前記ベースバンドプロセッサが、前記スケジューリング要求を、前記Ｓ－ＳＲのある１つのシーケンスを示す構成インデックスとして符号化するように構成され、前記Ｓ－ＳＲの各シーケンスが１つの構成に関連付けられている、請求項１６に記載のベースバンドプロセッサ。
20. 前記ベースバンドプロセッサが、前記決定されたサイドリンク送信リソースのセットの到着について無線チャネルを監視するように構成されている、請求項１１に記載のベースバンドプロセッサ。
21. ユーザ機器（ＵＥ）であって、
    少なくとも１つのアンテナと、
    前記少なくとも１つのアンテナに動作可能に結合された無線と、
    前記無線に動作可能に結合されたプロセッサと、
    を備え、
    前記ＵＥが、
    第２のＵＥから、スケジューリング要求であって、サイドリンクチャネル上での前記第２のＵＥによる使用のためのサイドリンク送信リソースのセットを前記ＵＥに決定させるように構成された前記スケジューリング要求を受信し、
    前記受信されたスケジューリング要求に応答して、前記第２のＵＥによる使用のためのサイドリンク送信リソースのセットを決定し、
    前記第２のＵＥに、前記決定されたサイドリンク送信リソースのセットに関する情報であって、前記サイドリンクチャネル上で送信する際に前記第２のＵＥによって使用可能である前記決定されたサイドリンク送信リソースのセットに関する情報を送信するように構成されている、
    ＵＥ。
22. 前記ＵＥが、前記サイドリンクチャネル上の通信トラフィックを検知することによって前記サイドリンク送信リソースのセットを決定するように構成されている、
    請求項２１に記載のＵＥ。
23. 前記ＵＥが、前記ＵＥによって維持されている既存のリソーススケジュールに基づいて前記サイドリンク送信リソースのセットを決定するように構成されている、
    請求項２１に記載のＵＥ。
24. 前記サイドリンク送信リソースのセットが推奨リソースを含む、
    請求項２１に記載のＵＥ。
25. 前記サイドリンク送信リソースのセットが予約されたリソースを含む、
    請求項２１に記載のＵＥ。
26. 前記ＵＥが、前記第２のＵＥからＨＡＲＱ－ＡＣＫを受信したことに応答して、前記第２のＵＥに、前記予約されたリソースのうち１つ以上を移転するように更に構成されている、
    請求項２５に記載のＵＥ。
27. 前記ＵＥが、前記第２のＵＥからＨＡＲＱ－ＮＡＣＫを受信したことに応答して、前記第２のＵＥに、前記決定されたサイドリンク送信リソースのセットに関する前記情報を、１つ以上の追加の予約されたリソースを使用して再送信するように更に構成されている、
    請求項２５に記載のＵＥ。
28. 前記ＵＥが、前記決定されたサイドリンク送信リソースのセットに関する情報を、物理サイドリンク共有チャネル上、又はサイドリンク制御情報（ＳＣＩ）上で送信するように構成されている、
    請求項２１に記載のＵＥ。
29. ユーザ機器（ＵＥ）における使用のために構成されたベースバンドプロセッサであって、
    制御回路を備え、前記制御回路が、
    第２のＵＥから、スケジューリング要求であって、サイドリンクチャネル上での前記第２のＵＥによる使用のためのサイドリンク送信リソースのセットを前記ＵＥに決定させるように構成されている前記スケジューリング要求を受信し、
    前記受信されたスケジューリング要求に応答して、前記第２のＵＥによる使用のためのサイドリンク送信リソースのセットを決定し、
    前記第２のＵＥに、前記決定されたサイドリンク送信リソースのセットに関する情報であって、前記サイドリンクチャネル上で送信する際に前記第２のＵＥによって使用可能である前記決定されたサイドリンク送信リソースのセットに関する前記情報を送信するように構成されている、
    ベースバンドプロセッサ。
30. 前記ベースバンドプロセッサが、前記ＵＥによって維持されている既存のリソーススケジュールに基づいて前記サイドリンク送信リソースのセットを決定するように構成されている、
    請求項２９に記載のベースバンドプロセッサ。
31. 前記サイドリンク送信リソースのセットが推奨リソースを含む、
    請求項２９に記載のベースバンドプロセッサ。
32. 前記サイドリンク送信リソースのセットが予約されたリソースを含む、
    請求項２９に記載のベースバンドプロセッサ。
33. 前記ＵＥが、前記第２のＵＥからＨＡＲＱ－ＡＣＫを受信したことに応答して、前記第２のＵＥに、前記予約されたリソースのうち１つ以上を移転するように更に構成されている、
    請求項３２に記載のベースバンドプロセッサ。
34. 前記ＵＥが、前記第２のＵＥからＨＡＲＱ－ＮＡＣＫを受信したことに応答して、前記第２のＵＥに、前記決定されたサイドリンク送信リソースのセットに関する前記情報を、１つ以上の追加の予約されたソースを使用して再送信するように更に構成されている、
    請求項３２に記載のベースバンドプロセッサ。
35. 前記ベースバンドプロセッサが、前記決定されたサイドリンク送信リソースのセットに関する情報を、物理サイドリンク共有チャネル上、又はサイドリンク制御情報（ＳＣＩ）上で送信するように構成されている、
    請求項２９に記載のベースバンドプロセッサ。

Images