特表 2024-513013 ＵＥ間協調フィードバックのためのサイドリンク送信リソース

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

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

(11)【公表番号】

(43)【公表日】2024-03-21

(54)【発明の名称】ＵＥ間協調フィードバックのためのサイドリンク送信リソース

(51)【国際特許分類】

   H04W 72/25 20230101AFI20240313BHJP

   H04W 92/18 20090101ALI20240313BHJP

   H04W 76/14 20180101ALI20240313BHJP

   H04W 28/04 20090101ALI20240313BHJP

【ＦＩ】

H04W72/25

H04W92/18

H04W76/14

H04W28/04 110

【審査請求】有

【予備審査請求】未請求

(21)【出願番号】P 2023560086

(86)(22)【出願日】2022-03-30

(85)【翻訳文提出日】2023-09-28

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

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

(87)【国際公開日】2022-10-06

(31)【優先権主張番号】63/169,704

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

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

(31)【優先権主張番号】63/169,715

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

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

(31)【優先権主張番号】63/171,029

(32)【優先日】2021-04-05

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

(81)【指定国・地域】

【公序良俗違反の表示】

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

１．３ＧＰＰ

(71)【出願人】

【識別番号】593096712

【氏名又は名称】インテル コーポレイション

(74)【代理人】

【識別番号】100107766

【弁理士】

【氏名又は名称】伊東 忠重

(74)【代理人】

【識別番号】100070150

【弁理士】

【氏名又は名称】伊東 忠彦

(74)【代理人】

【識別番号】100135079

【弁理士】

【氏名又は名称】宮崎 修

(74)【代理人】

【識別番号】100135105

【弁理士】

【氏名又は名称】渡邊 直満

(72)【発明者】

【氏名】コリャエフ，アレクセイ

(72)【発明者】

【氏名】シロフ，ミハイル

(72)【発明者】

【氏名】ロマエフ，アルチョム

(72)【発明者】

【氏名】パンテレーエフ，セルゲイ

(72)【発明者】

【氏名】ロト，キリアン ペーター アントン

(72)【発明者】

【氏名】プチリン，アルチョム

(72)【発明者】

【氏名】ベロフ，ドミトリー

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

5K067

【Ｆターム（参考）】

5K067AA03

5K067EE02

5K067EE25

(57)【要約】

コンピュータ可読記憶媒体は、5G NRネットワークにおけるサイドリンク動作のためにUEを構成し、UEに対して、第2のUEから受信された第1のサイドリンク送信を復号することを含む動作を実行させる命令を記憶する。第1のサイドリンク送信は、第2のUEによる後続のサイドリンク送信のための第1のリソース予約を含む。第3のUEから受信された第2のサイドリンク送信が復号される。第2のサイドリンク送信は、第3のUEによる後続のサイドリンク送信のための第2のリソース予約を含む。第1のリソース予約及び第2のリソース予約が同じサイドリンクスロット内にあることに基づいて、同一チャネル衝突が検出される。第2のUE及び第3のUEへの送信のために、フィードバックメッセージが符号化される。フィードバックメッセージは、同一チャネル衝突を示す。

【特許請求の範囲】

【請求項1】

第5世代新無線(5G NR)ネットワークにおける動作のために構成されたユーザ機器(UE)のための装置であって、
前記5G NRネットワークにおけるサイドリンク動作のために前記UEを構成するために、
第2のUEから受信された、前記第2のUEによる後続のサイドリンク送信のための第1のリソース予約を含む第1のサイドリンク送信を復号し、
第3のUEから受信された、前記第3のUEによる後続のサイドリンク送信のための第2のリソース予約を含む第2のサイドリンク送信を復号し、
前記第1のリソース予約及び前記第2のリソース予約が同じサイドリンクスロット内にあることに基づいて、同一チャネル衝突を検出し、
前記第2のUE及び前記第3のUEへの送信のために、前記同一チャネル衝突を示すフィードバックメッセージを符号化する
ように構成された処理回路と、
前記処理回路に結合され、前記第1のサイドリンク送信及び前記第2のサイドリンク送信を記憶するように構成されたメモリと
を含む装置。

【請求項2】

前記処理回路は、
物理サイドリンクフィードバックチャネル(PSFCH)を使用して前記第2のUE及び前記第3のUEへの送信のために前記フィードバックメッセージを符号化するように構成される、請求項１に記載の装置。

【請求項3】

前記処理回路は、
前記PSFCHのリソースのプールを使用して前記第2のUE及び前記第3のUEへの送信のために前記フィードバックメッセージを符号化するように構成され、前記リソースのプールは、UE間協調フィードバックに専用である、請求項２に記載の装置。

【請求項4】

前記リソースのプールは、PSFCHシンボル上の物理リソースブロック(PRB)ビットマップを含み、前記PRBビットマップは、前記PSFCHについて事前構成される、請求項３に記載の装置。

【請求項5】

前記処理回路は、前記PSFCHのリソースの共有プールを使用して前記第2のUE及び前記第3のUEへの送信のために前記フィードバックメッセージを符号化するように構成される、請求項２に記載の装置。

【請求項6】

前記処理回路は、前記PSFCHのリソースの前記共有プールを使用して送信のためにハイブリッド自動再送要求(HARQ)情報を符号化するように構成され、前記HARQ情報の送信及び前記フィードバックメッセージの送信は、異なるリソースIDで前記共有プールからのリソースに関連付けられる、請求項５に記載の装置。

【請求項7】

前記フィードバックメッセージは、
前記第2のUE及び前記第3のUEのソースIDと、
前記第1のサイドリンク送信及び前記第2のサイドリンク送信に関連付けられたリソースIDと、
前記フィードバックメッセージに関連付けられたフィードバックタイプと、
前記第2のUE又は前記第3のUEのサイドリンク送信優先度と
のうちの少なくとも1つを含む、請求項１に記載の装置。

【請求項8】

前記処理回路は、
物理サイドリンク制御チャネル(PSCCH)サイドリンク制御情報(SCI)を使用して、前記第2のUE及び前記第3のUEへの送信のために前記フィードバックメッセージを符号化するように構成される、請求項１に記載の装置。

【請求項9】

前記UEは、前記第2のUE及び前記第3のUEを含むUEグループのグループメンバである、請求項１に記載の装置。

【請求項10】

前記処理回路に結合されたトランシーバ回路と、前記トランシーバ回路に結合された1つ以上のアンテナとを更に含む、請求項１に記載の装置。

【請求項11】

ユーザ機器(UE)の1つ以上のプロセッサによる実行のための命令を含むコンピュータプログラムであって、
前記命令は、第5世代新無線(5G NR)ネットワークにおけるサイドリンク動作のために前記UEを構成し、前記UEに対して、
物理サイドリンク共有チャネル(PSSCH)を使用したサイドリンク送信のための、前記UEによる後続のサイドリンク送信のためのリソース予約を含むデータを符号化し、
第2のUEから受信された、前記リソース予約及び第3のUEからの少なくとも別のリソース予約が同じサイドリンクスロットにあることに基づく同一チャネル衝突を示すフィードバックメッセージを復号し、
前記受信されたフィードバックメッセージに基づいてサイドリンク再送のために前記データを符号化する
ことを含む動作を実行させる、コンピュータプログラム。

【請求項12】

前記フィードバックメッセージは、物理サイドリンクフィードバックチャネル(PSFCH)又は物理サイドリンク制御チャネル(PSCCH)サイドリンク制御情報(SCI)のうち1つを使用して受信される、請求項１１に記載のコンピュータプログラム。

【請求項13】

ユーザ機器(UE)の1つ以上のプロセッサによる実行のための命令を含むコンピュータプログラムであって、
前記命令は、第5世代新無線(5G NR)ネットワークにおけるサイドリンク動作のために前記UEを構成し、前記UEに対して、
第2のUEから受信された、前記第2のUEによる後続のサイドリンク送信のための第1のリソース予約を含む第1のサイドリンク送信を復号し、
第3のUEから受信された、前記第3のUEによる後続のサイドリンク送信のための第2のリソース予約を含む第2のサイドリンク送信を復号し、
前記第1のリソース予約及び前記第2のリソース予約が同じサイドリンクスロット内にあることに基づいて、同一チャネル衝突を検出し、
前記第2のUE及び前記第3のUEへの送信のために、前記同一チャネル衝突を示すフィードバックメッセージを符号化する
ことを含む動作を実行させる、コンピュータプログラム。

【請求項14】

前記動作は、
物理サイドリンクフィードバックチャネル(PSFCH)を使用して前記第2のUE及び前記第3のUEへの送信のために前記フィードバックメッセージを符号化することを更に含む、請求項１３に記載のコンピュータプログラム。

【請求項15】

前記動作は、
前記PSFCHのリソースのプールを使用して前記第2のUE及び前記第3のUEへの送信のために前記フィードバックメッセージを符号化することを更に含み、
前記リソースのプールは、UE間協調フィードバックに専用である、請求項１４に記載のコンピュータプログラム。

【請求項16】

前記リソースのプールは、PSFCHシンボル上の物理リソースブロック(PRB)ビットマップを含み、前記PRBビットマップは、PSFCHについて事前構成される、請求項１５に記載のコンピュータプログラム。

【請求項17】

前記動作は、前記PSFCHのリソースの共有プールを使用して前記第2のUE及び前記第3のUEへの送信のために前記フィードバックメッセージを符号化することを更に含む、請求項１４に記載のコンピュータプログラム。

【請求項18】

前記動作は、
前記PSFCHのリソースの前記共有プールを使用して送信のためにハイブリッド自動再送要求(HARQ)情報を符号化することを更に含み、前記HARQ情報の送信及び前記フィードバックメッセージの送信は、異なるリソースIDで前記共有プールからのリソースに関連付けられる、請求項１７に記載のコンピュータプログラム。

【請求項19】

前記フィードバックメッセージは、
前記第2のUE及び前記第3のUEのソースIDと、
前記第1のサイドリンク送信及び前記第2のサイドリンク送信に関連付けられたリソースIDと、
前記フィードバックメッセージに関連付けられたフィードバックタイプと、
前記第2のUE又は前記第3のUEのサイドリンク送信優先度と
のうちの少なくとも1つを含む、請求項１３に記載のコンピュータプログラム。

【請求項20】

前記動作は、物理サイドリンク制御チャネル(PSCCH)サイドリンク制御情報(SCI)を使用して、前記第2のUE及び前記第3のUEへの送信のために前記フィードバックメッセージを符号化することを更に含む、請求項１３に記載のコンピュータプログラム。

【請求項21】

請求項１１乃至２０のうちいずれか１項に記載のコンピュータプログラムを記憶したコンピュータ可読記憶媒体。

【発明の詳細な説明】

【技術分野】

【0001】

［優先権主張］
本出願は、以下の米国仮特許出願に対する優先権の利益を主張する。

【0002】

2021年4月1日に出願された「MECHANISMS FOR DETERMINING RESOURCES FOR SIDELINK TRANSMISSION FOR INTER-UE COORDINATION FEEDBACK」という名称の米国仮特許出願第63/169,704号。

【0003】

2021年4月1日に出願された「MECHANISMS FOR DETERMINING USER EQUIPMENT FOR INTER-UE COORDINATION FEEDBACK」という名称の米国仮特許出願第63/169,715号。

【0004】

2021年4月5日に出願された「SUPPORT OF PARTIAL SENSING AND INTER-UE COORDINATION FEEDBACK FOR RELIABLE SIDELINK COMMUNICATION WITH THE REDUCED POWER CONSUMPTION」という名称の米国仮特許出願第63/171,029号。
上記に列挙した特許出願のそれぞれの全内容を参照により援用する。

【0005】

［技術分野］
諸態様は、ワイヤレス通信に関する。いくつかの態様は、3GPP(Third Generation Partnership Project)ネットワーク、3GPP LTE(Long Term Evolution)ネットワーク、3GPP LTE-A(LTE Advanced)ネットワーク、(MulteFire, LTE-U)、並びに第5世代(5G, fifth-generation)ネットワーク及びそれ以降を含み、5G新無線(NR, new radio)(又は5G-NR)ネットワーク、5G NRアンライセンススペクトル(NR-U)ネットワークのような5G-LTEネットワーク、及びWi-Fi、CBRS(OnGo)等を含む他のアンライセンスネットワークを含むワイヤレスネットワークに関する。他の態様は、5G-NR(及びそれ以降の)ネットワークにおけるUE間協調フィードバックのためのサイドリンク(SL, sidelink)伝送リソースのためのリソースを決定するための機構を対象とする。更なる態様は、5G-NR(及びそれ以降の)ネットワークにおけるUE間協調フィードバックのためのユーザ機器(UE, user equipment)を決定するための機構を対象とする。更なる態様は、5G-NR(及びそれ以降の)ネットワークにおける低減された電力消費を有する信頼できるサイドリンク通信のための部分センシング(検知)及びUE間協調フィードバックをサポートすることを対象とする。

【背景技術】

【0006】

モバイル通信は、初期の音声システムから今日の高度に洗練された統合通信プラットフォームへと著しく進化してきた。様々なネットワークデバイスと通信する異なるタイプのデバイスの増加とともに、3GPP LTEシステムの使用が増加している。現代社会におけるモバイルデバイス(ユーザ機器又はUE)の浸透は、多くの異なる環境における多種多様なネットワーク化されたデバイスに対する需要を駆り立て続けている。第5世代(5G, fifth-generation)ワイヤレスシステムが登場しており、更に大きい速度、接続性及び有用性を可能にすることが想定される。次世代5Gネットワーク(又はNRネットワーク)は、スループット、カバレッジ及びロバスト性を増加させ、レイテンシ並びに運用及び資本支出を低減することが想定される。5G-NRネットワークは、高速でリッチなコンテンツ及びサービスを配信するシームレスなワイヤレス接続ソリューションによって人々の生活を豊かにするために、更なる潜在的な新たな無線アクセス技術(RAT, radio access technology)を有する3GPP LTE-Advancedに基づいて進化し続けるであろう。現在のセルラーネットワーク周波数は飽和しているので、ミリメートル波(mmWave, millimeter wave)周波数のようなより高い周波数は、これらの高い帯域幅のため有益になる可能性がある。

【0007】

アンライセンススペクトルにおける潜在的なLTE動作は、デュアルコネクティビティ(DC, dual connectivity)又はDCベースのLAAを介したアンライセンススペクトルにおけるLTE動作と、アンライセンススペクトルにおけるスタンドアロンLTEシステムとを含み(これらに限定されない)、スタンドアロンLTEシステムによれば、LTEベースの技術は、MulteFireと呼ばれるライセンススペクトルにおける「アンカー」を必要とせずにアンライセンススペクトルにおいて単独で動作する。ライセンススペクトル及びアンライセンススペクトルにおけるLTE及びNRシステムの更なる拡張動作が、将来のリリース及び5G-NR(及びそれ以降の)システムにおいて想定される。このような拡張動作は、5G-NR(及びそれを以降の)ネットワークにおけるUE間協調フィードバックのためのサイドリンク(SL, sidelink)送信のためのリソースを決定するための機構と、5G-NR(及びそれ以降の)ネットワークにおけるUE間協調フィードバックのためのユーザ機器(UE, user equipment)を決定するための機構と、5G-NR(及びそれ以降の)ネットワークにおける低減された電力消費を有する信頼できるサイドリンク通信のための部分センシング及びUE間協調フィードバックのサポートとを含むことができる。

【図面の簡単な説明】

【0008】

必ずしも縮尺通りではない図面において、同様の数字は、異なる図において同様のコンポーネントを記述することがある。異なる添え字を有する同様の数字は、同様のコンポーネントの異なるインスタンスを表すことがある。図面は、概して、限定としてではなく、例として、本文書で議論される様々な態様を例示する。

【図1A】いくつかの態様によるネットワークのアーキテクチャを示す。

【図1B】いくつかの態様による非ローミング5Gシステムアーキテクチャを示す。

【図1C】いくつかの態様による非ローミング5Gシステムアーキテクチャを示す。

【図2】開示の実施形態の態様を実装し得る様々なシステム、デバイス及びコンポーネントを示す。

【図3】開示の実施形態の態様を実装し得る様々なシステム、デバイス及びコンポーネントを示す。

【図4】開示の実施形態の態様を実装し得る様々なシステム、デバイス及びコンポーネントを示す。

【図5】いくつかの態様による、タイプ1隠れノード衝突の図を示す。

【図6】いくつかの態様による、タイプ2同時アクセス衝突の図を示す。

【図7】いくつかの態様によるUE間協調フィードバックを用いた送信における半二重の図を示す。

【図8】いくつかの態様によるUE間協調フィードバックを用いたリソース予約における半二重の図を示す。

【図9】いくつかの態様によるUE間協調フィードバックを用いた送信における同一チャネル衝突の図を示す。

【図10】いくつかの態様によるUE間協調フィードバックを用いた予約における同一チャネル衝突の図である。

【図11】いくつかの態様によるUE間協調フィードバックのためのPSCCHの多重化の図を示す。

【図12】いくつかの態様によるHARQのためのRel.16 PSFCHとUE間協調フィードバックのためのRel.17 PSFCHとの多重化の図を示す。

【図13】いくつかの態様によるSL DRXアクティブ時間の前に開始する最小選択ウィンドウを用いたリソース(再)選択トリガの例の図を示す。

【図14】いくつかの態様によるSL DRXアクティブ時間の後に終了する最小選択ウィンドウを用いたリソース(再)選択トリガの例の図を示す。

【図15】いくつかの態様による、進化型Nod-B(eNB, evolved Node-B)、新世代Node-B(gNB, new generation Node-B)(又は別のRANノード若しくは基地局)、送受信ポイント(TRP, transmission-reception point)、アクセスポイント(AP, access point)、ワイヤレス局(STA, wireless station)、移動局(MS, mobile station)又はユーザ機器(UE, user equipment)のような通信デバイスのブロック図を示す。

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

【0009】

以下の説明及び図面は、当業者が態様を実施することを可能にするために、態様を十分に例示する。他の態様は、構造的、論理的、電気的、プロセス的及び他の変更を組み込んでもよい。いくつかの態様の部分及び特徴は、他の態様のものに含まれてもよく、或いは、他の態様のものと置換されてもよい。特許請求の範囲に概説される態様は、これらの特許請求の範囲の全ての利用可能な均等物を包含する。

【0010】

図１Ａは、いくつかの態様によるネットワークのアーキテクチャを示す。ネットワーク140Aは、ユーザ機器(UE, user equipment)101及びUE102を含むように示されている。UE101及び102は、スマートフォン(例えば、1つ以上のセルラーネットワークに接続可能なハンドヘルド型タッチスクリーンモバイルコンピューティングデバイス)として示されているが、パーソナルデータアシスタント(PDA, Personal Data Assistant)、ページャ、ラップトップコンピュータ、デスクトップコンピュータ、ワイヤレスハンドセット、ドローン、又はワイヤード及び/又はワイヤレス通信インタフェースを含むいずれかの他のコンピューティングデバイスのように、いずれかのモバイル又は非モバイルコンピューティングデバイスをも含んでもよい。UE101及び102は、ここでは併せてUE101と呼ばれる可能性があり、UE101は、ここで開示する技術のうち1つ以上を実行するために使用できる。

【0011】

(例えば、ネットワーク140A又はいずれかの他の図示のネットワークにおいて使用されるような)ここに記載の無線リンクのいずれかは、いずれかの例示的な無線通信技術及び/又は標準に従って動作してもよい。

【0012】

LTE及びLTE-Advancedは、移動電話のようなUEのための高速データのワイヤレス通信のための標準である。LTE-Advanced及び様々なワイヤレスシステムでは、キャリアアグリゲーションは、異なる周波数上で動作する複数のキャリア信号が単一のUEのための通信を搬送するために使用され得る技術であり、したがって、単一のデバイスに利用可能な帯域幅を増加させる。いくつかの態様では、1つ以上のコンポーネントキャリアがアンライセンス周波数上で動作する場合、キャリアアグリゲーションが使用されてもよい。

【0013】

ここで説明する態様は、例えば、専用ライセンススペクトル、アンライセンススペクトル、(ライセンス)共有スペクトル(2.3～2.4GHz、3.4～3.6GHz、3.6～3.8GHz及び更なる周波数におけるライセンス共有アクセス(LSA, Licensed Shared Access)、並びに3.55～3.7GHz及び更なる周波数におけるスペクトルアクセスシステム(SAS, Spectrum Access System)等)を含む、いずれかのスペクトル管理方式の文脈において使用できる。

【0014】

ここで説明する態様はまた、異なるシングルキャリア又はOFDMフレーバ(CP-OFDM、SC-FDMA、SC-OFDM、フィルタバンクベースのマルチキャリア(FBMC, filter bank-based multicarrier)、OFDMA等)に適用でき、特に、OFDMキャリアデータビットベクトルを対応するシンボルリソースに割り当てることによって3GPP NRに適用できる。

【0015】

いくつかの態様では、UE101及び102のいずれかは、モノのインターネット(IoT, Internet-of-Things)UE又はセルラーIoT(CIoT, Cellular IoT)UEを含むことができ、これは、短期間のUE接続を利用する低電力IoTアプリケーションのために設計されたネットワークアクセスレイヤを含むことができる。いくつかの態様では、UE101及び102のいずれかは、狭帯域(NB, narrowband)IoT UE(例えば、拡張NB-IoT(eNB-IoT, enhanced NB-IoT)UE及び更なる拡張(FeNB-IoT, Further Enhanced IoT)UE等)を含むことができる。IoT UEは、パブリックランドモバイルネットワーク(PLMN, public land mobile network)、近接ベースサービス(ProSe, Proximity-Based Service)若しくはデバイス対デバイス(D2D, device-to-device)通信、センサネットワーク、又はIoTネットワークを介してMTCサーバ又はデバイスとデータを交換するために、マシン対マシン(M2M, machine-to-machine)又はマシンタイプ通信(MTC, machine-type communications)のような技術を利用できる。データのM2M又はMTC交換は、データのマシン開始交換でもよい。IoTネットワークは、(インターネットインフラストラクチャ内の)一意に識別可能な埋め込みコンピューティングデバイスを含んでもよいIoT UEを、短期間の接続で相互接続することを含む。IoT UEは、IoTネットワークの接続を容易にするために、バックグラウンドアプリケーション(例えば、キーアライブメッセージ、状態更新等)を実行してもよい。

【0016】

いくつかの態様では、UE101及び102のいずれかは、拡張MTC(eMTC, enhanced MTC)UE又は更なる拡張MTC(FeMTC, further enhanced MTC)UEを含むことができる。

【0017】

UE101及び102は、無線アクセスネットワーク(RAN, radio access network)110と接続するように、例えば、通信可能に結合するように構成されてもよい。RAN110は、例えば、UMTS(Universal Mobile Telecommunications System)、E-UTRAN(Evolved UMTS Terrestrial Radio Access Network)、NG RAN(NextGen RAN)、又は何らかの他のタイプのRANでもよい。UE101及び102は、それぞれ接続103及び104を利用し、これらのそれぞれは、物理通信インタフェース又はレイヤ(以下で更に詳細に議論される)を含み、この例では、接続103及び104は、通信結合を可能にするためのエアインタフェースとして示され、GSM(Global System for Mobile Communications)プロトコル、符号分割多元接続(CDMA, code-division multiple access)ネットワークプロトコル、プッシュツートーク(PTT, Push-to-Talk)プロトコル、POC(PTT over Cellular)プロトコル、UMTS(Universal Mobile Telecommunications System)プロトコル、3GPP LTE(Long Term Evolution)プロトコル、第5世代(5G, fifth-generation)プロトコル、新無線(NR, New Radio)プロトコル等のようなセルラー通信プロトコルと整合することができる。

【0018】

一態様では、UE101及び102は、ProSeインタフェース105を介して通信データを更に直接交換してもよい。ProSeインタフェース105は、代替として、物理サイドリンク制御チャネル(PSCCH, Physical Sidelink Control Channel)、物理サイドリンク共有チャネル(PSSCH, Physical Sidelink Shared Channel)、物理サイドリンクディスカバリチャネル(PSDCH, Physical Sidelink Discovery Channel)及び物理サイドリンクブロードキャストチャネル(PSBCH, Physical Sidelink Broadcast Channel)を含むがこれらに限定されない1つ以上の論理チャネルを含むサイドリンクインタフェースと呼ばれてもよい。

【0019】

UE102は、接続107を介してアクセスポイント(AP, access point)106にアクセスするように構成されるように示されている。接続107は、例えば、いずれかのIEEE802.11プロトコルと整合する接続のような、ローカルワイヤレス接続を含むことができ、これに従って、AP106はワイヤレスフィデリティ(WiFi(登録商標), wireless fidelity)ルータを含むことができる。この例では、AP106は、ワイヤレスシステムのコアネットワークに接続することなくインターネットに接続されるように示されている(以下で更に詳細に議論される)。

【0020】

RAN110は、接続103及び104を可能にする1つ以上のアクセスノードを含むことができる。これらのアクセスノード(AN, access node)は、基地局(BS, base station)、NodeB、進化型NodeB(eNB, evolved NodeB)、次世代NodeB(gNB, Next Generation NodeB)、RANネットワークノード等と呼ばれる可能性があり、地理的エリア(例えば、セル)内のカバレッジを提供する地上局(例えば、地上波アクセスポイント)又は衛星局を含むことができる。いくつかの態様では、通信ノード111及び112は、送信/受信ポイント(TRP, transmission/reception point)とすることができる。通信ノード111及び112がNodeB(例えば、eNB又はgNB)である場合、1つ以上のTRPは、NodeBの通信セル内で機能することができる。RAN110は、マクロセルを提供するための1つ以上のRANノード、例えば、マクロRANノード111と、フェムトセル又はピコセル(例えば、マクロセルと比較して、より小さいカバレッジエリア、より小さいユーザ容量又はより高い帯域幅を有するセル)を提供するための1つ以上のRANノード、例えば、低電力(LP)RANノード112又はアンライセンススペクトルベースのセカンダリRANノード112とを含んでもよい。

【0021】

RANノード111及び112のいずれかは、エアインタフェースプロトコルを終端することができ、UE101及び102のための最初のコンタクトポイントとすることができる。いくつかの態様では、RANノード111及び112のいずれかは、無線ベアラ管理、アップリンク及びダウンリンク動的無線リソース管理及びデータパケットスケジューリング、並びにモビリティ管理のような無線ネットワークコントローラ(RNC, radio network controller)機能を含むがこれらに限定されない、RAN110のための様々な論理機能を実現することができる。一例では、ノード111及び/又は112のいずれかは、新世代Node-B(gNB, new generation Node-B)、進化型Node-B(eNB, evolved node-B)又は別のタイプのRANノードとすることができる。

【0022】

RAN110は、S1インタフェース113を介してコアネットワーク(CN, core network)120に通信可能に結合されるように示されている。態様では、CN120は、進化型パケットコア(EPC, evolved packet core)ネットワーク、NPC(NextGen Packet Core)ネットワーク、又は(例えば、図１Ｂ～図１Ｃを参照して説明するような)何らかの他のタイプのCNでもよい。この態様では、S1インタフェース113は、2つの部分、すなわち、RANノード111及び112とサービングゲートウェイ(S-GW, serving gateway)122との間でユーザトラフィックデータを搬送するS1-Uインタフェース114と、RANノード111及び112とモビリティ管理エンティティ(MME)121との間のシグナリングインタフェースであるS1-MMEインタフェース115とに分割される。

【0023】

この態様では、CN120は、MME121と、S-GW122と、パケットデータネットワーク(PDN, Packet Data Network)ゲートウェイ(P-GW, PDN Gateway)123と、ホーム加入者サーバ(HSS, home subscriber server)124とを含む。MME121は、レガシーサービング汎用パケット無線サービス(GPRS, General Packet Radio Service)サポートノード(SGSN, Serving GPRS Support Node)の制御プレーンと機能的に同様でもよい。MME121は、ゲートウェイ選択及びトラッキングエリアリスト管理のようなアクセスにおけるモビリティ態様を管理してもよい。HSS124は、通信セッションのネットワークエンティティの処理をサポートするための加入関連情報を含む、ネットワークユーザのためのデータベースを含んでもよい。CN120は、モバイル加入者の数、機器の容量、ネットワークの編成等に依存して、1つ又はいくつかのHSS124を含んでもよい。例えば、HSS124は、ルーティング/ローミング、認証、許可、ネーミング/アドレス解決、位置依存性等のためのサポートを提供することができる。

【0024】

S-GW122は、RAN110に向かうS1インタフェース113を終端してもよく、RAN110とCN120との間のデータパケットをルーティングする。さらに、S-GW122は、RANノード間ハンドオーバのためのローカルモビリティアンカーポイントでもよく、3GPP間モビリティのためのアンカーを提供してもよい。S-GW122の他の機能は、合法的傍受、課金及び何らかのポリシー実施を含んでもよい。

【0025】

P-GW123は、PDNに向かうSGiインタフェースを終端してもよい。P-GW123は、インターネットプロトコル(IP, Internet Protocol)インタフェース125を介して、EPCネットワーク120と、アプリケーションサーバ184(代替としてアプリケーション機能(AF, application function)と呼ばれる)を含むネットワークのような外部ネットワークとの間でデータパケットをルーティングしてもよい。P-GW123はまた、インターネット、IPマルチメディアサブシステム(IPS, IP multimedia subsystem)ネットワーク及び他のネットワークを含むことができる他の外部ネットワーク131Aにデータを通信することができる。概して、アプリケーションサーバ184は、コアネットワークと共にIPベアラリソースを使用するアプリケーションを提供するエレメントでもよい(例えば、UMTSパケットサービス(PS, Packet Services)ドメイン、LTE PSデータサービス等)。この態様では、P-GW123は、IPインタフェース125を介してアプリケーションサーバ184に通信可能に結合されるように示されている。アプリケーションサーバ184はまた、CN120を介してUE101及び102のための1つ以上の通信サービス(例えば、ボイスオーバインターネットプロトコル(VoIP, Voice-over-Internet Protocol)セッション、PTTセッション、グループ通信セッション、ソーシャルネットワーキングサービス等)をサポートするように構成できる。

【0026】

さらに、P-GW123は、ポリシー実施及び課金データ収集のためのノードでもよい。ポリシー及び課金ルール機能(PCRF, Policy and Charging Rules Function)126は、CN120のポリシー及び課金制御エレメントである。非ローミングシナリオにおいて、いくつかの態様では、UEのインターネットプロトコル接続アクセスネットワーク(IP-CAN, Internet Protocol Connectivity Access Network)セッションに関連付けられたホームパブリックランドモバイルネットワーク(HPLMN, Home Public Land Mobile Network)内に単一のPCRFが存在してもよい。トラフィックのローカルブレークアウトを伴うローミングシナリオにおいて、UEのIP-CANセッションに関連付けられた2つのPCRF、すなわち、HPLMN内のホームPCRF(H-PCRF, Home PCRF)と、訪問先パブリックランドモバイルネットワーク(VPLMN, Visited Public Land Mobile Network)内の訪問先PCRF(V-PCRF, Visited PCRF)とが存在してもよい。PCRF126は、P-GW123を介してアプリケーションサーバ184に通信可能に結合されてもよい。

【0027】

いくつかの態様では、通信ネットワーク140Aは、ライセンス(5G NR)スペクトル及びアンライセンス(5G NR-U)スペクトルにおける通信を使用する5G新無線ネットワークを含む、IoTネットワーク又は5Gネットワークとすることができる。IoTの現在のイネーブラの1つは、狭帯域IoT(NB-IoT, narrowband-IoT)である。

【0028】

NGシステムアーキテクチャは、RAN110及び5Gネットワークコア(5GC, 5G network core)120を含むことができる。NG-RAN110は、gNB及びNG-eNBのような複数のノードを含むことができる。コアネットワーク120(例えば、5Gコアネットワーク又は5GC)は、アクセス及びモビリティ機能(AMF, access and mobility function)及び/又はユーザプレーン機能(UPF, user plane function)を含むことができる。AMF及びUPFは、NGインタフェースを介してgNB及びNG-eNBに通信可能に結合できる。より具体的には、いくつかの態様では、gNB及びNG-eNBは、NG-CインタフェースによってAMFに接続され、NG-UインタフェースによってUPFに接続されることができる。gNB及びNG-eNBは、Xnインタフェースを介して互いに結合できる。

【0029】

いくつかの態様では、NGシステムアーキテクチャは、3GPP技術仕様(TS, Technical Specification)23.501(例えば、V15.4.0, 2018-12)によって提供されるような様々なノードの間の参照点を使用できる。いくつかの態様では、gNB及びNG-eNBのそれぞれは、基地局、モバイルエッジサーバ、スモールセル、ホームeNB、RANネットワークノード等として実装できる。いくつかの態様では、5Gアーキテクチャにおいて、gNBはマスタノード(MN, master node)とすることができ、NG-eNBはセカンダリノード(SN, secondary node)とすることができる。いくつかの態様では、マスタ/プライマリノードはライセンスバンドで動作してもよく、セカンダリノードはアンライセンスバンドで動作してもよい。

【0030】

図１Ｂは、いくつかの態様による非ローミング5Gシステムアーキテクチャを示す。図１Ｂを参照すると、5Gシステムアーキテクチャ140Bが参照点表現で示されている。より具体的には、UE102は、RAN110及び1つ以上の他の5Gコア(5GC, 5G core)ネットワークエンティティと通信することができる。5Gシステムアーキテクチャ140Bは、アクセス及びモビリティ管理機能(AMF, access and mobility management function)132、位置管理機能(LMF, location management function)133、セッション管理機能(SMF, session management function)136、ポリシー制御機能(PCF, policy control function)148、アプリケーション機能(AF, application function)150、ユーザプレーン機能(UPF, user plane function)134、ネットワークスライス選択機能(NSSF, network slice selection function)142、認証サーバ機能(AUSF, authentication server function)144及び統合データ管理(UDM, unified data management)/ホーム加入者サーバ(HSS, home subscriber server)146のような複数のネットワーク機能(NF, network function)を含む。UPF134は、例えば、オペレータサービス、インターネットアクセス又はサードパーティサービスを含むことができるデータネットワーク(DN, data network)152への接続を提供できる。AMF132は、アクセス制御及びモビリティを管理するために使用でき、ネットワークスライス選択機能を含むこともできる。SMF136は、ネットワークポリシーに従って様々なセッションを設定及び管理するように構成できる。UPF134は、所望のサービスタイプに従って1つ以上の構成で展開できる。PCF148は、(4G通信システムにおけるPCRFと同様に)ネットワークスライシング、モビリティ管理及びローミングを使用してポリシーフレームワークを提供するように構成できる。UDMは、(4G通信システムにおけるHSSと同様に)加入者プロファイル及びデータを記憶するように構成できる。

【0031】

LMF133は、5G測位機能に関連して使用されてもよい。いくつかの態様では、LMF133は、UE101の位置を計算するために、NLインタフェース上でAMF132を介して次世代無線アクセスネットワーク(NG-RAN, next generation radio access network)110及びモバイルデバイス(例えば、UE101)から測定値及び支援情報を受信する。いくつかの態様では、NR測位プロトコルA(NRPPa, NR positioning protocol A)が、次世代制御プレーンインタフェース(NG-C, next generation control plane interface)上でNG-RANとLMF133との間で測位情報を搬送するために使用されてもよい。いくつかの態様では、LMF133は、AMF132を介してLTE測位プロトコル(LPP, LTE positioning protocol)を使用してUEを構成する。NG RAN110は、LTE-Uu及びNR-Uuインタフェース上で無線リソース制御(RRC, radio resource control)プロトコルを使用してUE101を構成する。

【0032】

いくつかの態様では、5Gシステムアーキテクチャ140Bは、測位測定を可能にするために異なる参照信号を構成する。測位測定のために使用され得る例示的な参照信号は、ダウンリンクにおける測位参照信号(NR PRS, positioning reference signal)と、アップリンクにおける測位のためのサウンディング参照信号(SRS, sounding reference signal)とを含む。ダウンリンク測位参照信号(PRS, positioning reference signal)は、ダウンリンクベースの測位方法をサポートするように構成された参照信号である。

【0033】

いくつかの態様では、5Gシステムアーキテクチャ140Bは、IPマルチメディアサブシステム(IMS, IP multimedia subsystem)168Bと、呼セッション制御機能(CSCF, call session control function)のような複数のIPマルチメディアコアネットワークサブシステムエンティティとを含む。より具体的には、IMS168Bは、プロキシCSCF(P-CSCF, proxy CSCF)162BE、サービングCSCF(S-CSCF, serving CSCF)164B、緊急CSCF(E-CSCF, emergency CSCF)(図１Ｂに図示せず)又は問い合わせCSCF(I-CSCF, interrogating CSCF)166Bとして動作することができるCSCFを含む。P-CSCF162Bは、IMサブシステム(IMS, IM subsystem)168B内でUE102のための最初のコンタクトポイントとなるように構成できる。S-CSCF164Bは、ネットワーク内のセッション状態を処理するように構成でき、E-CSCFは、緊急要求を正しい緊急センタ又はPSAPにルーティングすることのような、緊急セッションの特定の態様を処理するように構成できる。I-CSCF166Bは、そのネットワークオペレータの加入者、又はそのネットワークオペレータのサービスエリア内に現在位置するローミング加入者に宛てられた全てのIMS接続のためのオペレータのネットワーク内のコンタクトポイントとして機能するように構成できる。いくつかの態様では、I-CSCF166Bは、別のIPマルチメディアネットワーク170E、例えば、異なるネットワークオペレータによって運用されるIMSに接続できる。

【0034】

いくつかの態様では、UDM/HSS146は、電話アプリケーションサーバ(TAS, telephony application server)又は別のアプリケーションサーバ(AS, application server)を含むことができるアプリケーションサーバ160Eに結合できる。AS160Bは、S-CSCF164B又はI-CSCF166Bを介してIMS168Bに結合できる。

【0035】

参照点表現は、対応するNFサービスの間に相互作用が存在できることを示す。例えば、図１Ｂは、以下の参照点、すなわち、N1(UE102とAMF132との間)、N2(RAN110とAMF132との間)、N3(RAN110とUPF134との間)、N4(SMF136とUPF134との間)、N5(PCF148とAF150との間、図示せず)、N6(UPF134とDN152との間)、N7(SMF136とPCF148との間、図示せず)、N8(UDM146とAMF132との間、図示せず)、N9(2つのUPF134の間、図示せず)、N10(UDM146とSMF136との間、図示せず)、N11(AMF132とSMF136との間、図示せず)、N12(AUSF144とAMF132との間、図示せず)、N13(AUSF144とUDM146との間、図示せず)、N14(2つのAMF132の間、図示せず)、N15(非ローミングシナリオの場合のPCF148とAMF132との間、又はローミングシナリオの場合のPCF148と訪問先ネットワーク及びAMF132との間、図示せず)、N16(2つのSMFの間、図示せず)、及びN22(AMF132とNSSF142との間、図示せず)を示す。図１Ｂに示されていない他の参照点表現も使用できる。

【0036】

図１Ｃは、5Gシステムアーキテクチャ140C及びサービスベースの表現を示す。図１Ｂに示すネットワークエンティティに加えて、システムアーキテクチャ140Cはまた、ネットワーク公開機能(NEF, network exposure function)154及びネットワークリポジトリ機能(NRF, network repository function)156を含むことができる。いくつかの態様では、5Gシステムアーキテクチャは、サービスベースとすることができ、ネットワーク機能の間の相互作用は、対応するポイントツーポイント参照点Niによって、或いは、サービスベースのインタフェースとして表現できる。

【0037】

いくつかの態様では、図１Ｃに示すように、他の許可されるネットワーク機能がこれらのサービスにアクセスすることを可能にする制御プレーン内のネットワーク機能を表すために、サービスベースの表現が使用できる。この点に関して、5Gシステムアーキテクチャ140Cは、以下のサービスベースのインタフェース、すなわち、Namf158H(AMF132によって示されるサービスベースのインタフェース)、Nsmf158I(SMF136によって示されるサービスベースのインタフェース)、Nnef158B(NEF154によって示されるサービスベースのインタフェース)、Npcf158D(PCF148によって示されるサービスベースのインタフェース)、Nudm158E(UDM146によって示されるサービスベースのインタフェース)、Naf158F(AF150によって示されるサービスベースのインタフェース)、Nnrf158C(NRF156によって示されるサービスベースのインタフェース)、Nnssf158A(NSSF142によって示されるサービスベースのインタフェース)、Nausf158G(AUSF144によって示されるサービスベースのインタフェース)を含むことができる。図１Ｃに示されていない他のサービスベースのインタフェース(例えば、Nudr、N5g-eir及びNudsf)も使用できる。

【0038】

図２、図３及び図４は、5G-NR(及びそれ以降の)ネットワークのような、異なる通信システムにおいて開示の実施形態の態様を実装し得る様々なシステム、デバイス及びコンポーネントを示す。図１Ａ～図４に関連して議論されるUE、基地局(gNB等)及び/又は他のノード(例えば、衛星又は他のNTNノード)は、開示の技術を実行するように構成できる。

【0039】

図２は、様々な実施形態によるネットワーク200を示す。ネットワーク200は、LTE又は5G/NRシステムのための3GPP技術仕様と一貫性のある方式で動作してもよい。しかし、例示的な実施形態はこの点で限定されず、記載の実施形態は、将来の3GPPシステム等のように、ここで説明する原理から利益を受ける他のネットワークに適用されてもよい。

【0040】

ネットワーク200はUE202を含んでもよく、UE202は、無線接続を介してRAN204と通信するように設計されたいずれかのモバイル又は非モバイルコンピューティングデバイスを含んでもよい。UE202は、限定されるものではないが、スマートフォン、タブレットコンピュータ、ウェアラブルコンピューティングデバイス、デスクトップコンピュータ、ラップトップコンピュータ、車載インフォテインメント、車載エンターテインメントデバイス、計器群、ヘッドアップディスプレイデバイス、車載診断デバイス、ダッシュトップモバイル機器、モバイルデータ端末、電子エンジン管理システム、電子/エンジン制御ユニット、電子/エンジン制御モジュール、組み込みシステム、センサ、マイクロコントローラ、制御モジュール、エンジン管理システム、ネットワークアプライアンス、マシンタイプ通信デバイス、M2M又はD2Dデバイス、IoTデバイス等でもよい。

【0041】

いくつかの実施形態では、ネットワーク200は、サイドリンクインタフェースを介して互いに直接結合された複数のUEを含んでもよい。UEは、限定されるものではないが、PSBCH、PSDCH、PSSCH、PSCCH、PSFCH等のような物理サイドリンクチャネルを使用して通信するM2M/D2Dデバイスでもよい。

【0042】

いくつかの実施形態では、UE202は、無線接続を介してAP206と更に通信してもよい。AP206は、WLAN接続を管理してもよく、これは、RAN204から一部/全部のネットワークトラフィックをオフロードするように機能してもよい。UE202とAP206との間の接続は、いずれかのIEEE802.11プロトコルと一貫性があってもよく、AP206は、ワイヤレスフィデリティ(Wi-Fi(登録商標), wireless fidelity)ルータでもよい。いくつかの実施形態では、UE202、RAN204及びAP206は、セルラーWLANアグリゲーション(例えば、LWA/LWIP)を利用してもよい。セルラーWLANアグリゲーションは、UE202がセルラー無線リソースとWLANリソースとの双方を利用するようにRAN204によって構成されることを伴ってもよい。

【0043】

RAN204は、1つ以上のアクセスノード、例えば、アクセスノード(AN, access node)208を含んでもよい。AN208は、RRC、パケットデータコンバージェンスプロトコル(PDCP, Packet Data Convergence Protocol)、無線リンク制御(RLC, Radio Link Control)、MAC及びL1プロトコルを含むアクセス層プロトコルを提供することによって、UE202のためのエアインタフェースプロトコルを終端してもよい。このように、AN208は、コアネットワーク(CN, core network)220とUE202との間のデータ/音声接続を可能にしてもよい。いくつかの実施形態では、AN208は、ディスクリートデバイスにおいて、或いは、例えば、CRAN又は仮想ベースバンドユニットプールと呼ばれてもよい仮想ネットワークの一部としてサーバコンピュータ上で実行する1つ以上のソフトウェアエンティティとして実装されてもよい。AN208は、BS、gNB、RANノード、eNB、ng-eNB、NodeB、RSU、TRxP、TRP等と呼ばれてもよい。AN208は、マクロセルと比較してより小さいカバレッジエリア、より小さいユーザ容量、又はより高い帯域幅を有するフェムトセル、ピコセル又は他の同様のセルを提供するためのマクロセル基地局又は低電力基地局でもよい。

【0044】

RAN204が複数のANを含む実施形態では、複数のANは、X2インタフェース(RAN204がLTE RANである場合)又はXnインタフェース(RAN204が5G RANである場合)を介して互いに結合されてもよい。いくつかの実施形態では制御/ユーザプレーンインタフェースに分離され得るX2/Xnインタフェースは、ANがハンドオーバ、データ/コンテキスト転送、モビリティ、負荷管理、干渉制御等に関連する情報を通信することを可能にしてもよい。

【0045】

RAN204のANはそれぞれ、1つ以上のセル、セルグループ、コンポーネントキャリア等を管理して、ネットワークアクセスのためのエアインタフェースをUE202に提供してもよい。UE202は、RAN204の同じAN又は異なるANによって提供される複数のセルに同時に接続されてもよい。例えば、UE202及びRAN204は、キャリアアグリゲーションを使用して、UE202がPcell又はScellにそれぞれ対応する複数のコンポーネントキャリアに接続することを可能にしてもよい。デュアルコネクティビティのシナリオにおいて、第1のANは、MCGを提供するマスタノードでもよく、第2のANは、SCGを提供するセカンダリノードでもよい。第1/第2のANは、eNB、gNB、ng-eNB等のいずれかの組み合わせでもよい。

【0046】

RAN204は、ライセンススペクトル又はアンライセンススペクトル上でエアインタフェースを提供してもよい。アンライセンススペクトルにおいて動作するために、ノードは、PCell/Scellを用いたCA技術に基づいて、LAA、eLAA及び/又はfeLAA機構を使用してもよい。アンライセンススペクトルにアクセスする前に、ノードは、例えば、リッスンビフォートーク(LBT ,listen-before-talk)プロトコルに基づく媒体/キャリア検知動作を実行してもよい。

【0047】

V2Xシナリオにおいて、UE202又はAN208は、路側ユニット(RSU, roadside unit)でもよく或いはRSUとして機能してもよく、これは、V2X通信に使用されるいずれかの交通インフラストラクチャエンティティを示してもよい。RSUは、好適なAN又は静的な(或いは比較的静的な)UEにおいて或いはこれによって実装されてもよい。UEにおいて或いはUEによって実装されるRSUは「UEタイプRSU」と呼ばれてもよく、eNBは「eNBタイプRSU」と呼ばれてもよく、gNBは「gNBタイプRSU」と呼ばれてもよく、以下同様である。一例では、RSUは、通過する車両UEに接続サポートを提供する、路側に位置する無線周波数回路に結合されたコンピューティングデバイスである。RSUはまた、交差点マップジオメトリ、トラフィック統計、媒体を記憶する内部データストレージ回路と、進行中の車両及び歩行者の交通を検知及び制御するアプリケーション/ソフトウェアとを含んでもよい。RSUは、衝突回避、交通警告等のような高速の事象に必要とされる非常に低レイテンシの通信を提供してもよい。さらに或いは代替として、RSUは、他のセルラー/WLAN通信サービスを提供してもよい。RSUのコンポーネントは、屋外設置に好適な耐候性の筐体のパッケージ化されてもよく、交通信号コントローラ又はバックホールネットワークに有線接続(例えば、Ethernet(登録商標))を提供するためのネットワークインタフェースコントローラを含んでもよい。

【0048】

いくつかの実施形態では、RAN204は、eNB、例えばeNB212を含むLTE RAN210でもよい。LTE RAN210は、以下の特徴、すなわち、15kHzのサブキャリア間隔(SCS, sub-carrier spacing)、DL用のCP-OFDM波形及びUL用のSC-FDMA波形、データ用のターボコード及び制御用のTBCC等をLTEエアインタフェースに提供してもよい。LTEエアインタフェースは、CSI取得及びビーム管理のためにCSI-RSに依存し、PDSCH/PDCCH復調のためにPDSCH/PDCCH DMRSに依存し、セルサーチ及び初期取得、チャネル品質測定、並びにUEにおけるコヒーレント復調/検出のためのチャネル推定のためにCRSに依存してもよい。LTEエアインタフェースは、サブ6GHz帯域で動作してもよい。

【0049】

いくつかの実施形態では、RAN204は、gNB、例えばgNB216、又はng-eNB、例えばng-eNB218を有するNG-RAN214でもよい。gNB216は、5G NRインタフェースを使用して5G対応UEに接続してもよい。gNB216は、N2インタフェース又はN3インタフェースを含んでもよいNGインタフェースを通じて5Gコアに接続してもよい。ng-eNB218はまた、NGインタフェースを通じて5Gコアに接続してもよいが、LTEエアインタフェースを介してUEと接続してもよい。gNB216及びng-eNB218は、Xnインタフェースを介して互いに接続してもよい。

【0050】

いくつかの実施形態では、NGインタフェースは2つの部分、すなわち、NG-RAN214のノードとUPF248との間でトラフィックデータを保持するNGユーザプレーン(NG-U, NG user plane)インタフェース(例えば、N3インタフェース)と、NG-RAN214のノードとAMF244との間のシグナリングインタフェースであるNG制御プレーン(NG-C, NG control plane)インタフェース(例えば、N2インタフェース)とに分割されてもよい。

【0051】

NG-RAN214は、以下の特徴、すなわち、可変SCS、DL用のCP-OFDM、UL用のCP-OFDM及びDFT-s-OFDM、データの制御及びLDPCのためのポーラ(polar)符号、反復符号、シンプレックス(simplex)符号及びReed-Muller符号を5G NRエアインタフェースに提供してもよい。5G NRエアインタフェースは、LTEエアインタフェースと同様に、CSI-RS、PDSCH/PDCCH DMRSに依存してもよい。5G NRエアインタフェースは、CRSを使用しなくてもよいが、PBCH復調のためにPBCH DMRSを使用してもよく、PDSCHの位相トラッキングのためにPTRSを使用してもよく、時間追跡のために追跡参照信号を使用してもよい。5G NRエアインタフェースは、24.25GHz～52.6GHzの帯域を含むサブ6GHz帯域又はFR2帯域を含むFR1帯域で動作してもよい。5G NRエアインタフェースは、PSS/SSS/PBCHを含むダウンリンクリソースグリッドのエリアである同期信号及び物理ブロードキャストチャネル(SS/PBCH, synchronization signal and physical broadcast channel)ブロック(SSB, SS/PBCH block)を含んでもよい。

【0052】

いくつかの実施形態では、5G NRエアインタフェースは、様々な目的のために帯域幅部分(BWP, bandwidth part)を利用してもよい。例えば、BWPは、SCSの動的適合のために使用できる。例えば、UE202は、各BWP構成が異なるSCSを有する複数のBWPで構成できる。BWPの変更がUE202に示されると、伝送のSCSも同様に変更される。BWPの別のユースケースは省電力化に関する。特に、異なるトラフィック負荷シナリオの下でのデータ伝送をサポートするために異なる量の周波数リソース(例えば、PRB)を有する複数のBWPがUE202のために構成できる。より少ない数のPRBを含むBWPは、小さいトラフィックを有するデータ伝送のために使用でき、UE202において、また、いくつかの場合にはgNB216において省電力化を可能にする。より多い数のPRBを含むBWPは、より高いトラフィック負荷を有するシナリオに使用できる。

【0053】

RAN204は、顧客/加入者(例えば、UE202のユーザ)へのデータ及び電気通信サービスをサポートするための様々な機能を提供するためのネットワークエレメントを含むCN220に通信可能に結合される。CN220のコンポーネントは、1つの物理ノード又は別個の物理的ノードに実装されてもよい。いくつかの実施形態では、CN220のネットワークエレメントによって提供される機能のいずれか又は全てを、サーバ、スイッチ等における物理計算/ストレージリソース上に仮想化するためにNFVが利用されてもよい。CN220の論理インスタンス化はネットワークスライスと呼ばれてもよく、CN220の一部の論理インスタンス化はネットワークサブスライスと呼ばれてもよい。

【0054】

いくつかの実施形態では、CN220は、EPC(又は進化型パケットコア)とも呼ばれもよい進化型パケットシステム(EPS, Enhanced Packet System)222の一部としてのLTE無線ネットワークに接続されてもよい。EPC222は、図示のように、インタフェース(又は「参照点」)上で互いに結合されたMME224、SGW226、SGSN228、HSS230、PGW232及びPCRF234を含んでもよい。EPC222のエレメントの機能は以下の通り簡潔に紹介され得る。

【0055】

MME224は、UE202の現在位置を追跡して、ページング、ベアラアクティブ化/非アクティブ化、ハンドオーバ、ゲートウェイ選択、認証等を容易にするためのモビリティ管理機能を実装してもよい。

【0056】

SGW226は、RANに向かうS1インタフェースを終端し、RANとEPC222との間でデータパケットをルーティングしてもよい。SGW226は、RANノード間ハンドオーバのローカルモビリティアンカーポイントでもよく、また、3GPP間モビリティのためのアンカーを提供してもよい。他の複数の役割は、合法的傍受、課金及び何らかのポリシー実施を含んでもよい。

【0057】

SGSN228は、UE202の位置を追跡し、セキュリティ機能及びアクセス制御を実行してもよい。さらに、SGSN228は、異なるRATネットワークの間のモビリティのためのEPCノード間シグナリング、MME224によって指定されるようなPDN及びS-GW選択、ハンドオーバのためのMME選択等を実行してもよい。MME224とSGSN228との間のS3参照点は、アイドル/アクティブ状態での3GPPアクセスネットワーク間モビリティについてのユーザ及びベアラ情報の交換を可能にしてもよい。

【0058】

HSS230は、ネットワークエンティティによる通信セッションの処理をサポートするために、加入関連情報を含む、ネットワークユーザのためのデータベースを含んでもよい。HSS230は、ルーティング/ローミング、認証、許可、ネーミング/アドレス解決、位置依存性等のためのサポートを提供できる。HSS230とMME224との間のS6a参照点は、LTE CN220へのユーザアクセスを認証/許可するために加入及び認証データの転送を可能にしてもよい。

【0059】

PGW232は、アプリケーション/コンテンツサーバ238を含んでもよいデータネットワーク(DN, data network)236に向かうSGiインタフェースを終端してもよい。PGW232は、LTE CN220とデータネットワーク236との間でデータパケットをルーティングしてもよい。PGW232は、ユーザプレーントンネリング及びトンネル管理を容易にするために、S5参照点によってSGW226と結合されてもよい。PGW232は、ポリシー実施及び課金データ収集(例えば、PCEF)のためのノードを更に含んでもよい。さらに、PGW232とデータネットワーク236との間のSGi参照点は、例えば、IMSサービスの提供のために、オペレータ外部のパブリック、プライベートPDN又はオペレータ内パケットデータネットワークでもよい。PGW232は、Gx参照点を介してPCRF234に結合されてもよい。

【0060】

PCRF234は、LTE CN220のポリシー及び課金制御エレメントである。PCRF234は、サービスフローのための適切なQoS及び課金パラメータを決定するためにアプリ/コンテンツサーバ238に通信可能に結合されてもよい。PCRF234は、関連付けられたルールを適切なTFT及びQCIを有するPCEFに(Gx参照点を介して)提供してもよい。

【0061】

いくつかの実施形態では、CN220は5GC240でもよい。5GC240は、図示のように、インタフェース(又は「参照点」)上で互いに結合されたAUSF242、AMF244、SMF246、UPF248、NSSF250、NEF252、NRF254、PCF256、UDM258、及びAF260を含んでもよい。5GC240のエレメントの機能は以下の通り簡潔に紹介され得る。

【0062】

AUSF242は、UE202の認証のためのデータを記憶し、認証関連の機能を処理してもよい。AUSF242は、様々なアクセスタイプのための共通の認証フレームワークを容易にしてもよい。図示のような参照点上で5GC 240の他のエレメントと通信することに加えて、AUSF242は、Nausfサービスベースのインタフェースを示してもよい。

【0063】

AMF244は、UE202及びRAN204と通信するため、且つ、UE202に関するモビリティイベントについての通知に加入するために、5GC240の他の機能を可能にしてもよい。AMF244は、登録管理(例えば、UE202の登録のため)、接続管理、到達可能性管理、モビリティ管理、AMF関連イベントの合法的傍受並びにアクセス認証及び許可を担ってもよい。AMF244は、UE202とSMF246との間でSMメッセージの転送を提供し、SMメッセージのルーティングのためのトランスペアレントなプロキシとして機能してもよい。AMF244はまた、UE202とSMSFとの間でSMSメッセージの転送を提供してもよい。AMF244は、様々なセキュリティアンカー及びコンテキスト管理機能を実行するためにAUSF242及びUE202と相互作用してもよい。さらに、AMF244は、RAN204とAMF244との間のN2参照点を含んでもよく或いはN2参照点でもよいRAN CPインタフェースの終端点でもよく、AMF244は、NAS(N1)シグナリングの終端点でもよく、NAS暗号化及び完全性保護を実行してもよい。AMF244はまた、N3 IWFインタフェース上でのUE202とのNASシグナリングをサポートしてもよい。

【0064】

SMF246は、SM(例えば、UPF248とAN208との間のセッション確立、トンネル管理)、UE IPアドレスの割り当て及び管理(任意選択の許可を含む)、UP機能の選択及び制御、適切な宛先にトラフィックをルーティングするためのUPF248におけるトラフィックステアリングの構成、ポリシー制御機能に向かうインタフェースの終端、ポリシー実施、課金及びQoSの一部の制御、合法的傍受(SMイベント及びLIシステムへのインタフェースのため)、NASメッセージのSM部分の終端、ダウンリンクデータ通知、N2上でAMF244を介してAN208に送信されるAN固有SM情報の開始、並びにセッションのSSCモードの決定を担ってもよい。SMは、PDUセッションの管理を示してもよく、PDUセッション又は「セッション」は、UE202とデータネットワーク236との間のPDUの交換を提供又は可能にするPDU接続サービスを提示してもよい。

【0065】

UPF248は、RAT内及びRAT間のモビリティのアンカーポイント、データネットワーク236への相互接続の外部PDUセッションポイント、並びにマルチホームPDUセッションをサポートするための分岐点として機能してもよい。UPF248はまた、パケットルーティング及び転送を実行し、パケット検査を実行し、ポリシールールのユーザプレーン部分を実施し、パケットを合法的に傍受し(UP収集)、トラフィック使用レポートを実行し、ユーザプレーンのQoS処理(例えば、パケットフィルタリング、ゲーティング、UL/DLレート実施)を実行し、アップリンクトラフィック検証(例えば、SDFからQoSへのフローのマッピング)を実行し、アップリンク及びダウンリンクにおけるトランスポートレベルのパケットのマーキングを行い、ダウンリンクパケットのバッファリング及びダウンリンクデータ通知のトリガを実行してもよい。UPF248は、トラフィックフローをデータネットワークにルーティングするのをサポートするためのアップリンク分類器を含んでもよい。

【0066】

NSSF250は、UE202にサービス提供するネットワークスライスインスタンスのセットを選択してもよい。NSSF250はまた、許可されるNSSAIを決定し、必要に応じて、加入したS-NSSAIへのマッピングを決定してもよい。NSSF250はまた、好適な構成に基づいて、場合によってはNRF254をクエリすることによって、UE202にサービス提供するために使用されるべきAMFセット、又は候補AMFのリストを決定してもよい。UE202のためのネットワークスライスインスタンスのセットの選択は、NSSF250と相互作用することによって、UE202が登録されているAMF244によってトリガされてもよく、これは、AMFの変更をもたらしてもよい。NSSF250は、N22参照点を介してAMF244と相互作用してもよく、N31参照点(図示せず)を介して訪問先ネットワーク内の別のNSSFと通信してもよい。さらに、NSSF250は、Nnssfサービスベースのインタフェースを提示してもよい。

【0067】

NEF252は、サードパーティ、内部公開/再公開、AF(例えば、AF260)、エッジコンピューティング又はフォグコンピューティングシステム等のために、3GPPネットワーク機能によって提供されるサービス及び能力を安全に公開してもよい。このような実施形態では、NEF252は、AFを認証、許可又はスロットルしてもよい。NEF252はまた、AF260と交換された情報、及び内部ネットワーク機能と交換された情報を変換してもよい。例えば、NEF252は、AFサービス識別子と内部5GC情報との間で変換してもよい。NEF252はまた、他のNFの公開された能力に基づいて、他のNFから情報を受信してもよい。この情報は、構造化データとしてNEF252に記憶されてもよく、或いは、標準化インタフェースを使用してデータストレージNFに記憶されてもよい。次いで、記憶された情報は、NEF252によって他のNF及びAFに再公開でき、或いは、分析のような他の目的のために使用できる。さらに、NEF252は、Nnefサービスベースのインタフェースを提示してもよい。

【0068】

NRF254は、サービスディスカバリ機能をサポートし、NFインスタンスからNFディスカバリ要求を受信し、発見したNFインスタンスの情報をNFインスタンスに提供してもよい。NRF254はまた、利用可能なNFインスタンス及びこれらのサポートされるサービスに関する情報を維持してもよい。ここで使用される場合、「インスタンス化する」及び「インスタンス化」等の用語はインスタンスの作成を示してもよく、「インスタンス」は、例えばプログラムコードの実行中に生じ得るオブジェクトの具体的な発生を示してもよい。さらに、NRF254は、Nnrfサービスベースのインタフェースを提示してもよい。

【0069】

PCF256は、制御プレーン機能にポリシールールを提供してこれらを実施してもよく、また、ネットワーク挙動を統制するために統一ポリシーフレームワークをサポートしてもよい。PCF256はまた、UDM258のUDRにおいてポリシー決定に関連する加入情報にアクセスするためのフロントエンドを実装してもよい。図示のように参照点上で機能と通信することに加えて、PCF256は、Npcfサービスベースのインタフェースを提示してもよい。

【0070】

UDM258は、ネットワークエンティティによる通信セッションの処理をサポートするために加入関連情報を処理してもよく、UE202の加入データを記憶してもよい。例えば、加入データは、UDM258とAMF244との間のN8参照点を介して通信されてもよい。UDM258は、2つの部分、すなわち、アプリケーションフロントエンド及びUDRを含んでもよい。UDRは、UDM258及びPCF256のための加入データ及びポリシーデータ、及び/又は公開のための構造化データ及びNEF252のためのアプリケーションデータ(複数のUE202のためのアプリケーション検出、アプリケーション要求情報のためのPFDを含む)を記憶してもよい。Nudrサービスベースのインタフェースは、UDM258、PCF256及びNEF252が記憶されたデータの特定のセットにアクセスすることと、UDR内の関連データの変更の通知を読み取り、更新(例えば、追加、修正)し、削除し、加入することとを可能にするために、UDR221によって提示されてもよい。UDMは、証明書の処理、位置管理、加入管理等を担うUDM-FEを含んでもよい。いくつかの異なるフロントエンドが、異なるトランザクションにおいて同じユーザにサービス提供してもよい。UDM-FEは、UDRに記憶された加入情報にアクセスし、認証証明書の処理、ユーザ識別情報の処理、アクセス許可、登録/モビリティ管理及び加入管理を実行する。図示のような参照点上で他のNFと通信することに加えて、UDM258は、Nudmサービスベースのインタフェースを提示してもよい。

【0071】

AF260は、トラフィックルーティングに対するアプリケーションの影響を提供し、NEFへのアクセスを提供し、ポリシー制御のためのポリシーフレームワークと相互作用してもよい。

【0072】

いくつかの実施形態では、5GC240は、UE202がネットワークにアタッチされる点に地理的に近くなるオペレータ/サードパーティサービスを選択することによってエッジコンピューティングを可能にしてもよい。これは、レイテンシ及びネットワークに対する負荷を低減してもよい。エッジコンピューティングの実装を提供するために、5GC240は、UE202に近いUPF248を選択し、N6インタフェースを介したUPF248からデータネットワーク236へのトラフィックステアリングを実行してもよい。これは、UE加入データ、UE位置、及びAF260によって提供された情報に基づいてもよい。このように、AF260は、UPF(再)選択及びトラフィックルーティングに影響を及ぼしてもよい。オペレータ展開に基づいて、AF260が信頼できるエンティティであると考えられると、ネットワークオペレータは、AF260が関連するNFと直接的に相互作用することを許可してもよい。さらに、AF260は、Nafサービスベースのインタフェースを提示してもよい。

【0073】

データネットワーク236は、例えば、アプリケーション/コンテンツサーバ238を含む1つ以上のサーバによって提供されてもよい、様々なネットワークオペレータサービス、インターネットアクセス又はサードパーティサービスを表してもよい。

【0074】

図３は、様々な実施形態によるワイヤレスネットワーク300を概略的に示す。ワイヤレスネットワーク300は、AN304とワイヤレスで通信するUE302を含んでもよい。UE302及びAN304は、ここでの他の箇所で説明する同様の名称のコンポーネントと同様でもよく、実質的に交換可能でもよい。

【0075】

UE302は、接続306を介してAN304と通信可能に結合されてもよい。接続306は、通信結合を可能にするエアインタフェースとして示されており、mmWave又はサブ6GHz周波数で動作するLTEプロトコル又は5G NRプロトコルのようなセルラー通信プロトコルと一貫性があるものとすることができる。

【0076】

UE302は、モデムプラットフォーム310と結合されたホストプラットフォーム308を含んでもよい。ホストプラットフォーム308は、モデムプラットフォーム310のプロトコル処理回路314と結合され得るアプリケーション処理回路312を含んでもよい。アプリケーション処理回路312は、アプリケーションデータをソース(source)/シンク(sink)するUE302のための様々なアプリケーションを実行してもよい。アプリケーション処理回路312は、データネットワークとの間でアプリケーションデータを送信/受信するための1つ以上のレイヤ動作を更に実装してもよい。これらのレイヤ動作は、トランスポート(例えば、UDP)及びインターネット(例えば、IP)動作を含んでもよい。

【0077】

プロトコル処理回路314は、接続306上でのデータの送信又は受信を容易にするために、レイヤ動作のうちの1つ以上を実装してもよい。プロトコル処理回路314によって実装されるレイヤ動作は、例えば、MAC、RLC、PDCP、RRC及びNAS動作を含んでもよい。

【0078】

モデムプラットフォーム310は、ネットワークプロトコルスタックにおいてプロトコル処理回路314によって実行されるレイヤ動作の「下」にある1つ以上のレイヤ動作を実装してもよいデジタルベースバンド回路316を更に含んでもよい。これらの動作は、例えば、HARQ-ACK機能、スクランブリング/デスクランブリング、符号化/復号、レイヤマッピング/デマッピング、変調シンボルマッピング、受信シンボル/ビットメトリック決定、空間-時間、空間-周波数又は空間コーディングのうちの1つ以上を含んでもよいマルチアンテナポートプリコーディング/デコーディング、参照信号生成/検出、プリアンブルシーケンス生成及び/又は復号、同期シーケンス生成/検出、制御チャネル信号ブラインド復号、並び他の関連する機能のうち1つ以上を含むPHY動作を含んでもよい。

【0079】

モデムプラットフォーム310は、送信回路318と、受信回路320と、RF回路322と、1つ以上のアンテナパネル326を含んでもよく或いは接続してもよいRFフロントエンド(RFFE, RF front end)324とを含んでもよい。簡潔には、送信回路318は、デジタルアナログ変換器、ミキサ、中間周波数(IF, intermediate frequency)コンポーネント等を含んでもよく、受信回路320は、アナログデジタル変換器、ミキサ、IFコンポーネント等を含んでもよく、RF回路322は、低雑音増幅器、電力増幅器、電力追跡コンポーネント等を含んでもよく、RFFE324は、フィルタ(例えば、表面/バルク音響波フィルタ)、スイッチ、アンテナチューナ、ビームフォーミングコンポーネント(例えば、位相アレイアンテナコンポーネント)等を含んでよい。送信回路318、受信回路320、RF回路322、RFFE324及びアンテナパネル326のコンポーネント(一般的に「送信/受信コンポーネント」と呼ばれる)の選択及び構成は、例えば、通信がTDMであるかFDMであるか、mmWaveであるかサブ6GHz周波数であるか等のような特定の実装の詳細に固有でもよい。いくつかの実施形態では、送信/受信コンポーネントは、複数の並列送信/受信チェーンで構成されてもよく、同じ或いは異なるチップ/モジュール等に配置されてもよい。

【0080】

いくつかの実施形態では、プロトコル処理回路314は、送信/受信コンポーネントのための制御機能を提供するために制御回路(図示せず)の1つ以上のインスタンスを含んでもよい。

【0081】

UE受信は、アンテナパネル326、RFFE324、RF回路322、受信回路320、デジタルベースバンド回路316及びプロトコル処理回路314によって、且つ、これらを介して確立されてもよい。いくつかの実施形態では、アンテナパネル326は、1つ以上のアンテナパネル326の複数のアンテナ/アンテナ素子によって受信された受信ビームフォーミング信号によってAN304からの伝送を受信してもよい。

【0082】

UE伝送は、プロトコル処理回路314、デジタルベースバンド回路316、送信回路318、RF回路322、RFFE324及びアンテナパネル326によって、且つ、これらを介して確立されてもよい。いくつかの実施形態では、UE302の送信コンポーネントは、アンテナパネル326のアンテナ素子によって放射される送信ビームを形成するために、送信されるべきデータに空間フィルタを適用してもよい。

【0083】

UE302と同様に、AN304は、モデムプラットフォーム330に結合されたホストプラットフォーム328を含んでもよい。ホストプラットフォーム328は、モデムプラットフォーム330のプロトコル処理回路334に結合されたアプリケーション処理回路332を含んでもよい。モデムプラットフォームは、デジタルベースバンド回路336、送信回路338、受信回路340、RF回路342、RFFE回路344及びアンテナパネル346を更に含んでもよい。AN304のコンポーネントは、UE302の同様の名称のコンポーネントと同様でもよく、実質的に交換可能でもよい。上記のようにデータ送信/受信を実行することに加えて、AN304のコンポーネントは、例えば、無線ベアラ管理、アップリンク及びダウンリンク動的無線リソース管理、並びにデータパケットスケジューリングのようなRNC機能を含む、様々な論理機能を実行してもよい。

【0084】

図４は、いくつかの例示的な実施形態に従って、機械可読媒体又はコンピュータ可読媒体(例えば、非一時的な機械可読記憶媒体)から命令を読み取り、ここで議論される方法論のうちいずれか1つ以上を実行できるコンポーネントを示すブロック図である。具体的には、図４は、それぞれがバス440又は他のインタフェース回路を介して通信可能に結合され得る、1つ以上のプロセッサ(又はプロセッサコア)410、1つ以上のメモリ/記憶デバイス420及び1つ以上の通信リソース430を含むハードウェアリソース400の概略表現を示す。ノード仮想化(例えば、NFV)が利用される実施形態について、1つ以上のネットワークスライス/サブスライスがハードウェアリソース400を利用するための実行環境を提供するために、ハイパーバイザ402が実行されてもよい。

【0085】

プロセッサ410は、例えば、プロセッサ412及びプロセッサ414を含んでもよい。プロセッサ410は、例えば、中央処理装置(CPU, central processing unit)、縮小命令セットコンピューティング(RISC, reduced instruction set computing)プロセッサ、複合命令セットコンピューティング(CISC, complex instruction set computing)プロセッサ、グラフィックス処理ユニット(GPU, graphics processing unit)、ベースバンドプロセッサのようなDSP、ASIC、FPGA、無線周波数集積回路(RFIC, radio-frequency integrated circuit)、別のプロセッサ(ここで議論されるものを含む)又はこれらのいずれかの好適な組み合わせでもよい。

【0086】

メモリ/記憶デバイス420は、メインメモリ、ディスクストレージ又はこれらのいずれかの好適な組み合わせを含んでもよい。メモリ/記憶デバイス420は、いずれかのタイプの揮発性、不揮発性又は半揮発性メモリ、例えば、ダイナミックランダムアクセスメモリ(DRAM, dynamic random access memory)、スタティックランダムアクセスメモリ(SRAM, static random access memory)、消去可能プログラム可能読み取り専用メモリ(EPROM, erasable programmable read-only memory)、電気的消去可能プログラム可能読み取り専用メモリ(EEPROM, electrically erasable programmable read-only memory)、フラッシュメモリ、ソリッドステートストレージ等を含んでもよいが、これらに限定されない。

【0087】

通信リソース430は、ネットワーク408を介して1つ以上の周辺デバイス404又は1つ以上のデータベース406又は他のネットワークエレメントと通信するために、相互接続若しくはネットワークインタフェースコントローラ、コンポーネント又は他の好適なデバイスを含んでもよい。例えば、通信リソース430は、有線通信コンポーネント(例えば、USB、Ethernet等を介した結合のため)、セルラー通信コンポーネント、NFCコンポーネント、Bluetooth(登録商標)(又はBluetooth(登録商標)Low Energy)コンポーネント、Wi-Fi(登録商標)コンポーネント及び他の通信コンポーネントを含んでもよい。

【0088】

命令450は、プロセッサ410のうち少なくともいずれかに対して、ここで議論された方法論のうちいずれか1つ以上を実行させるための、ソフトウェア、プログラム、アプリケーション、アプレット、アプリ又は他の実行可能コードを含んでもよい。命令450は、プロセッサ410の少なくとも1つ(例えば、プロセッサのキャッシュメモリ内)、メモリ/記憶デバイス420又はこれらのいずれかの好適な組み合わせの中に完全に或いは部分的に存在してもよい。さらに、命令450のいずれかの部分は、周辺デバイス404又はデータベース406のいずれかの組み合わせからハードウェアリソース400に転送されてもよい。したがって、プロセッサ410のメモリ、メモリ/記憶デバイス420、周辺デバイス404及びデータベース406は、コンピュータ可読及び機械可読媒体の例である。

【0089】

1つ以上の実施形態について、上記の図のうち1つ以上において概説されるコンポーネントのうち少なくとも1つは、以下の例示的なセクションにおいて概説されるような1つ以上の動作、技術、プロセス及び/又は方法を実行するように構成されてもよい。例えば、上記の図のうち1つ以上に関連するベースバンド回路は、以下に記載される例のうち1つ以上に従って動作するように構成されてもよい。別の例では、上記の図のうち1つ以上に関連して上記で説明したようなUE、基地局、衛星、ネットワークエレメント等に関連する回路は、例示的なセクションにおいて以下で説明する例のうち1つ以上に従って動作するように構成されてもよい。

【0090】

「アプリケーション」という用語は、完全で展開可能なパッケージ、動作環境において特定の機能を達成するための環境を示してもよい。「AI/MLアプリケーション」等の用語は、いくつかの人工知能(AI, artificial intelligence)/機械学習(ML, machine learning)モデル及びアプリケーションレベルの記述を含むアプリケーションでもよい。いくつかの実施形態では、AI/MLアプリケーションは、開示の態様のうち1つ以上を構成又は実装するために使用されてもよい。

【0091】

「機械学習」又は「ML」という用語は、明示的な命令を使用せずに、代わりにパターン及び推論に依存して、特定のタスクを実行するためのアルゴリズム及び/又は統計モデルを実装するコンピュータシステムの使用を示す。MLアルゴリズムは、このようなタスクを実行するように明示的にプログラムされることなく予測又は決定を行うために、サンプルデータ(「トレーニングデータ」、「モデルトレーニング情報」等と呼ばれる)に基づいて数学モデル(「MLモデル」等と呼ばれる)を構築又は推定する。一般的に、MLアルゴリズムは、いくつかのタスク及びいくつかの性能指標に関して経験から学習するコンピュータプログラムであり、MLモデルは、MLアルゴリズムが1つ以上のトレーニングデータセットでトレーニングされた後に作成されるいずれかのオブジェクト又はデータ構造でもよい。トレーニングの後に、MLモデルは新たなデータセットの予測を行うために使用されてもよい。「MLアルゴリズム」という用語は「MLモデル」という用語とは異なる概念を示すが、ここで議論されるこれらの用語は、本開示では互換的に使用されてもよい。

【0092】

「機械学習モデル」、「MLモデル」等の用語はまた、ML支援ソリューションによって使用されるML方法及び概念を示してもよい。「ML支援ソリューション」は、動作中にMLアルゴリズムを使用して特定のユースケースに対処するソリューションである。MLモデルは、教師あり学習(例えば、線形回帰、k近傍法(KNN, k-nearest neighbor)、決定木アルゴリズム、サポートマシンベクトル、ベイズアルゴリズム、アンサンブルアルゴリズム等)、教師なし学習(例えば、K平均クラスタリング、主成分分析(PCA, principal component analysis)等)、強化学習(例えば、Q学習、多腕バンディット学習、ディープRL等)、ニューラルネットワーク等を含む。実装に依存して、特定のMLモデルは、コンポーネントとして多くのサブモデルを有してもよく、MLモデルは、全てのサブモデルを一緒にトレーニングしてもよい。別々にトレーニングされたMLモデルはまた、推論中にMLパイプラインにおいて一緒に繋がれてもよい。「MLパイプライン」は、ML支援ソリューションに特有の機能性、機能又は機能エンティティのセットであり、MLパイプラインは、データパイプライン、モデルトレーニングパイプライン、モデル評価パイプライン及びアクターの中の1つ又はいくつかのデータソースを含んでもよい。「アクター」は、MLモデル推論の出力を使用してML支援ソリューションをホストするエンティティである。「MLトレーニングホスト」という用語は、モデルのトレーニングをホストするネットワーク機能のようなエンティティを示す。「ML推論ホスト」という用語は、推論モード(モデル実行及び適用可能な場合にはいずれかのオンライン学習の双方を含む)中にモデルをホストする、ネットワーク機能のようなエンティティを示す。MLホストは、MLアルゴリズムの出力についてアクターに通知し、アクターはアクションを決定する(「アクション」は、ML支援ソリューションの出力の結果としてアクターによって実行される)。「モデル推論情報」という用語は、推論を決定するためのMLモデルへの入力として使用される情報を示し、MLモデルをトレーニングするために使用されるデータ及び推論を決定するために使用されるデータは重複してもよいが、「トレーニングデータ」及び「推論データ」は異なる概念を示す。

【0093】

サイドリンクV2X通信の高信頼性及び低レイテンシは、NR V2Xシステムのための重要なKPIである。NR Rel.17では、UE間協調方法は、サイドリンク信頼性向上に有益である。開示の技術は、次世代のNR V2Xシステムのための低レイテンシ及び高信頼性を提供できる特定のUE間協調の解決策を含む。いくつかの態様では、ベースラインNR V2Xシステムの以下のコンポーネントが使用できる。

【0094】

(a)サイドリンクデータを送信する(ユニキャスト又はグループキャスト又はブロードキャストモードのいずれかで通信する)UEは、TBの将来の再送のためにサイドリンクリソースを予約するために、制御チャネルを使用する。

【0095】

(b)UEは、各スロット内でサイドリンク制御チャネルを監視し、他のUEからの制御チャネル送信を復号し、SL-RSRPを測定することによってセンシング手順を実行する。

【0096】

(c)送信のために選択されるサイドリンクリソースは、UEの間の衝突を回避することを目的とするセンシング及びリソース(再)選択手順の結果に基づいて決定される。

【0097】

(d)UEは、ユニキャスト及びグループキャスト通信の場合にHARQ動作のために導入されるサイドリンクフィードバックチャネルを使用する。

【0098】

Rel.16において定義されているUE自律センシング及びリソース(再)選択の手順は、ランダムリソース(再)選択を上回る性能利益を提供する。開示の技術は、低レイテンシUE間協調フィードバックシグナリングを使用してNR V2Xサイドリンク通信の信頼性を更に改善するための拡張を含む。

【0099】

UE間協調シグナリングは、Rel.16 NR-V2X通信システムにおける半二重及び同一チャネル衝突(co-channel collision)イベントに起因する負の性能影響を低減することによって信頼性を向上させるのに役立つことができる。開示の技術は、半二重及び同一チャネル衝突のようなサイドリンク競合を区別し、以下の定義を使用するために使用できる。

【0100】

半二重及び同一チャネル衝突のサイドリンク競合
(A)半二重競合。

【0101】

(A.1)UE_PがUE_QのターゲットRXであり(例えば、UE_PがUE_Qグループのメンバである)、その送信のためにUE_Qからの送信を受信することができない可能性がある場合、UE_PはUE_Qとの半二重イベントを有する。以下の半二重競合が区別できる。

【0102】

(A.1.a)送信における半二重(HD-TX, half-duplex in transmission):UE_P及びUE_Qは、同じサイドリンクスロット内で(周波数における重複するリソース又は重複しないリソース上で)既に送信している。このタイプの衝突は、新たなUE間協調シグナリングを導入することによって対処できる。

【0103】

(A.1.b)受信における半二重(HD-RX, half-duplex in reception):UE_Pは、スロット「n」内でUE_Qへの送信のためのリソースを予約している。UE_Qは、より優先されるアップリンク(UL, uplink)又はサイドリンク(SL, sidelink)送信のためにスケジューリングされ、したがって、スロット「n」内の予約されたリソース上でUE_Pからの送信を受信できない。このタイプの競合は、新たなUE間協調シグナリングが予約されたリソース上での送信の前に受信できる場合、このシグナリングを導入することによって部分的に対処できる。

【0104】

(A.1.c)リソース選択における半二重(HD-SLCT, half-duplex in resource selection):UE_P及びUE_Qは、同じスロット内の(周波数における重複するリソース又は重複しないリソース上での)送信のためにリソースを選択している。このタイプの競合は、選択されたリソースの予約がUEのうちの1つによってまだ行われておらず、リソースを再選択するのに十分な処理遅延が存在する場合、Rel.16において定義されている(再)評価手順によって部分的に対処できる。

【0105】

(A.1.d)リソース予約における半二重(HD-RSV, half-duplex in resource reservation):UE_P及びUE_Qは、同じスロット内の(周波数における重複するリソース又は重複しないリソース上の)送信のためにリソースを予約している。このタイプの競合は、新たなUE間協調シグナリングを導入することによって対処できる。

【0106】

(A.2)半二重は、UE_P及びUE_Qが重複する周波数リソース上で送信した場合(同一チャネル衝突)、双方の送信が復号可能でないかのように、他のRX UEについてのサイドリンク受信の性能を著しく劣化させる可能性がある。

【0107】

(B)同一チャネル衝突。

【0108】

(B.1)UE_P及びUE_Qが重複する周波数又は時間リソース上で送信する場合、UE_Pは、UE_Qと同一チャネル衝突を有する。以下の同一チャネル衝突タイプは、以下のように区別できる。

【0109】

(B.1.a)送信における同一チャネル衝突(CC-TX, co-channel collision in transmission):この場合、TX UE(UE_P及びUE_Q)は、重複する周波数リソース(完全重複又は部分重複)上の同じサイドリンクスロット内で既に送信している。

【0110】

(B.1.b)リソース選択における同一チャネル衝突(CC-RS, co-channel collision in resource selection):この場合、TX UE(UE_P及びUE_Q)は、重複する周波数リソース(完全重複又は部分重複)上の同じスロット内での送信のためにリソースを選択している。いくつかの態様では、TX UEの1つが既にリソース予約を行っていない限り、このイベントは検出可能でない可能性がある。

【0111】

(B.1.c)リソース予約における同一チャネル衝突(CC-RSV, co-channel collision in resource reservation):この場合、TX UE(UE_P及びUE_Q)は、重複する周波数リソース(完全又は部分的重複)上の同じスロット内での送信のためにリソースを予約している。

【0112】

上記のサイドリンク競合は、単一のTX UEの観点から考慮される。

【0113】

いくつかの態様では、半二重及び同一チャネル衝突は、トランスポートブロック(TB, transport block)の初期送信若しくは再送のいずれか、又はTX UEの観点からの様々な組み合わせのために使用されるリソース上で生じる可能性がある。

【0114】

(a)組み合わせ-A:UE_P及びUE_QによるTBの初期送信のために使用されるリソース。

【0115】

(b)組み合わせ-B:UE_P及びUE_QによるTBの再送のために使用されるリソース。

【0116】

(c)組み合わせ-C:UE_PによるTBの初期送信のために使用されるリソース、及びUE_QによるTBの再送を搬送するリソース。

【0117】

以下の同一チャネル衝突タイプが、Rel.16 V2X設計に存在する。

【0118】

(a)タイプ-1(隠れノード):隠れノード(hidden node)問題による同一チャネル衝突。図５は、いくつかの態様によるタイプ1隠れノード衝突の図500を示す。送信側UEは、互いに通信範囲外にある(すなわち、互いを検知できない)が、RX UEの通信範囲内にある。

【0119】

(b)タイプ2(同時アクセス):処理時間遅延又はサイドリンク送信によるセンシングデータの欠如等によって引き起こされる同時リソース(再)選択による同一チャネル衝突。図６は、いくつかの態様によるタイプ2同時アクセス衝突の図600を示す。送信側UEは、互いに通信範囲内にある(すなわち、互いを検知することが可能である)が、同時にリソース(再)選択を実行し、重複するリソース上の同じスロット内のチャネルにアクセスする。

【0120】

(c)タイプ-3(輻輳媒体):占有されていないリソースの不足(高い媒体輻輳)による同一チャネル衝突。TX UEは、互いに通信範囲内にある(すなわち、互いを検知できる)が、チャネルへのアクセスは輻輳しており(リソースが占有されており)、UEは、最小RX電力レベルでリソースのセット内の占有されたリソースを選択する。この場合、衝突は回避不可能であり、したがって、衝突率を低減するために輻輳制御機構が使用されるべきである。

【0121】

以下は、モード2リソース割り当て拡張のためのUE間協調の解決策のリストである。モード2は、自律的リソース選択(例えば、時間及び周波数リソースの自律的選択)に関連付けられる。いくつかの態様では、UE間協調フィードバック及びシグナリングは、NR-V2Xサイドリンク通信の以下の競合、すなわち、送信における半二重(HD-TX, half-duplex in transmission)、予約における半二重(HD-RSV, half-duplex in the reservation)、受信における半二重(HD-RX, half-duplex in reception)、送信における同一チャネル衝突(CC-TX, co-channel collision in transmission)、及び予約における同一チャネル衝突(CC-RSV, co-channel collision in the reservation)を緩和するために使用できる。

【0122】

UE間協調によるこれらの競合に対処するために、提案される技術は、低レイテンシのサイドリンクフィードバックシグナリングを導入する。提案されるUE間協調フレームワークは、以下の設計コンポーネントのうち1つ以上を含んでもよい。

【0123】

(a)RX UEによる半二重及び同一チャネル衝突を決定するための条件を含む、UE間協調フィードバックを用いた信頼できるサイドリンク通信のためのサイドリンク衝突及び半二重競合を決定するための方法。

【0124】

(b)UL、SL HARQ、SL半二重/同一チャネル及びSL優先度を含む、UE間協調フィードバックを用いた信頼できるサイドリンク通信のためのUE間協調フィードバックを優先させるための方法。

【0125】

(c)距離、RSRP、半二重/同一チャネル衝突イベントの検出を含む、UE間協調フィードバックのためのUEを決定するための方法。

【0126】

(d)指示シグナリングのためにどのスロットを使用すべきか及びUE間協調のための新たな処理時間を含む、信頼できるサイドリンク通信のためのUE間協調フィードバックタイミングを決定するための方法。

【0127】

(e)半二重及び同一チャネル衝突のUE自律検出並びにリソース割り当てに関するTX UE挙動を含む、拡張リソース再選択手順並びに送信側UEによるサイドリンク半二重及び衝突イベントを決定するための方法。

【0128】

(f)UE間協調フィードバックのためのサイドリンク送信のためのリソースを決定する方法。

【0129】

(g)信頼できるサイドリンク通信のためのUE間協調フィードバックシグナリングの方法。

【0130】

図７～図１０は、上記の方法及び開示の技術を使用して対処できるNRサイドリンク通信の問題を示す。

【0131】

図７は、いくつかの態様によるUE間協調フィードバックを用いた送信における半二重の図700を示す。より具体的には、図７は、送信における半二重の衝突を示す。特に、UE1及びUE2は、TBの再送のために使用されるリソース内で半二重を有する。UE3は、送信における半二重及び更なる再送の潜在的な必要性を示すフィードバックをUE1及びUE2に提供する。さらに、UE4及びUE5は、TBの初期送信のために使用されるリソース上で半二重を有する。UE6は、初期送信における半二重及び更なる再送の潜在的な必要性を示すフィードバックをUE4及びUE5に提供する。

【0132】

図８は、いくつかの態様によるUE間協調フィードバックを用いたリソース予約における半二重の図800を示す。より具体的には、図８は、予約における半二重の競合を示す。特に、UE1及びUE2は、TBの再送のために計画された予約リソース内で半二重を有する。例えば、UE2は、再送リソースのために予約されたところで半二重を検出し、フィードバックをUE1に提供する。いくつかの態様では、UE1は、再送リソースのために予約されたところで半二重を検出し、フィードバックをUE2に提供する。いくつかの実施形態では、別のUE(例えば、図８に図示しないUE3)は、予約における半二重及びリソース(再)選択の潜在的な必要性を示すフィードバックをUE1及びUE2に提供する。

【0133】

図９は、いくつかの態様によるUE間協調フィードバックを用いた送信における同一チャネル衝突の図900を示す。より具体的には、UE1及びUE2は、TBの再送のために使用されるリソース内で同一チャネル衝突を有する。UE3は、送信における同一チャネル衝突及び更なる再送の潜在的な必要性を示すフィードバックをUE1及びUE2に提供する。さらに、UE4及びUE5は、TBの初期送信のために使用されるリソース上で同一チャネル衝突を有する。UE6は、初期送信における同一チャネル衝突及び更なる再送の潜在的な必要性を示すフィードバックをUE4及びUE5に提供する。

【0134】

図１０は、いくつかの態様によるUE間協調フィードバックを用いた予約における同一チャネル衝突の図1000を示す。より具体的には、UE1及びUE2は、TBの再送のために重複するリソースを予約している。UE3は、予約における同一チャネル衝突及びリソース(再)選択又は再送の潜在的な必要性を示すフィードバックをUE1及びUE2に提供する。

【0135】

いくつかの実施形態では、開示の技術は、送信側UE及び拡張リソース再選択手順によって、サイドリンク半二重及び衝突イベントを決定するための方法を含む。

【0136】

以下のタイプのUE間協調フィードバック、すなわち、送信における半二重(HD-TX, half-duplex in transmission)、予約における半二重(HD-RSV, half-duplex in the reservation)、受信における半二重(HD-RX, half-duplex in reception)、送信における同一チャネル衝突(CC-TX, co-channel collision in transmission)、及び予約における同一チャネル衝突(CC-RSV, co-channel collision in the reservation)は、サイドリンク通信において存在し得る異なるタイプの競合の緩和のために識別できる。

【0137】

上記の競合は、フィードバックがTBの進行中の送信のために適応できるように、低レイテンシを確保するための物理層シグナリングを必要としてもよい。このようなシグナリングの主な候補は、物理サイドリンクフィードバックチャネル(PSFCH, physical sidelink feedback channel)である。

【0138】

UE間協調フィードバックを提供するために、TX UE挙動が特定のフィードバックタイプを処理するように最適化でき、RX UEが異なるサイドリンク競合を区別することができるので、上記に列挙されたサイドリンク競合がフィードバックシグナリングの観点から区別される必要があるか否かが決定される必要がある。しかし、これは、受信されたUE間協調フィードバックに応じて、より複雑なシグナリング設計及びTX UEリソース割り当て手順を生じる可能性がある。

【0139】

いくつかの態様では、フィードバックシグナリングの観点から全てのサイドリンク競合を区別することが有益になり得る。

【0140】

以下の選択肢が、フィードバックシグナリング設計のために考慮できる。

【0141】

(A)TX UEによるUE間フィードバック区別。

【0142】

(A.1)選択肢1:全てのフィードバックタイプの区別。

【0143】

(A.2)選択肢2:予約における競合からの送信における競合に基づくフィードバックタイプの区別。

【0144】

(A.3)選択肢3:同一チャネル衝突フィードバックタイプからの半二重の区別。

【0145】

(B)UE間協調フィードバックのコンテンツ/ペイロード。

【0146】

(B.1)選択肢1。

【0147】

(B.1.a)TX UE(ソースID)。これは、サイドリンク送信が競合をもたらしたTX UEのソースIDである。

【0148】

(B.1.b)リソースID。これは、サイドリンク送信が競合をもたらしたTX UEのリソースIDである。リソースIDは、UE間協調フィードバック送信のために使用されるフィードバックリソースの時間周波数コードに符号化されてもよい。

【0149】

(B.2)選択肢2。

【0150】

(B.2.a)TX UE(ソースID)。

【0151】

(B.2.b)リソースID。

【0152】

(B.2.c)フィードバックタイプ。これは、提供されるフィードバックのタイプ(例えば、HD-TX、HD-RSV、CC-TX、CC-RSV、HARQ)に関する情報である。

【0153】

(B.3)選択肢3。

【0154】

(B.3.a)TX UE(ソースID)。

【0155】

(B.3.b)リソースID。

【0156】

(B.3.c)フィードバックタイプ。

【0157】

(B.3.d)競合しているTX UEのサイドリンク送信優先度。これは、競合を有するTX UE送信の優先度に関する情報である。

【0158】

(C)UE間協調フィードバックのためのシグナリング選択肢。

【0159】

(C.1)選択肢1:Rel.16におけるHARQフィードバックを搬送するPSFCHと同じ物理構造を使用するPSFCH。

【0160】

(C.1.a)PSFCHでの送信は、低いレイテンシ及び信頼性を提供する。

【0161】

(C.1.b)PSFCHリソースは、PSSCH、したがって、フィードバックの送信と時間において多重化される。これは、他との競合を生成しないので、フィードバック送信に有益である。

【0162】

(C.2)選択肢2:PSCCH SCI(段階1又は段階2)。

【0163】

(C.2.a)一実施形態では、新たな第1段階のSCIフォーマット1-xが、UE間協調情報を搬送するように定義されたペイロードとともに導入されてもよい。

【0164】

(C.2.b)一実施形態では、新たな第2段階のSCIフォーマット2-xが、UE間協調情報を搬送するように定義されたペイロードとともに導入されてもよい。

【0165】

(C.2.c)この送信のレイテンシは、センシング及びリソース選択の対象となってもよい。

【0166】

(C.2.d)1つの選択肢では、UE間協調情報を搬送するSCIフォーマットのためのPSCCHリソースは、SCIフォーマット1-A送信のためのPSCCHリソースとは別個に構成される。別の選択肢では、同じPSCCHリソースプールが、UE間協調情報を搬送するSCIのために使用される。

【0167】

図１１は、いくつかの態様によるUE間協調フィードバックのためのPSCCHの多重化の図1100を示す。

【0168】

(C.3)選択肢3:PSSCH(MAC CE)。

【0169】

(C.3.a)この送信のレイテンシは、センシング及びリソース選択手順の対象である。

【0170】

(C.3.b)この選択肢の潜在的な利点は、ペイロードを拡張し、競合に関するより多くの情報を提供する可能性である。

【0171】

(C.4)選択肢4:Uuインタフェース。

【0172】

(C.4.a)双方のUEもネットワークに接続されている場合、このフィードバックはネットワークを通じて送信されてもよい。

【0173】

(C.4.b)MAC CEの場合のように、これは、かなりのレイテンシを意味するが、より大量の情報を交換する可能性の潜在的な利益を有する。

【0174】

(D)PSFCH上のUE間協調フィードバックのためのリソース決定。

【0175】

フィードバックタイプの区別は、TX UE側で必要とされてもよく、これはまた、HARQフィードバックを他のUE間協調フィードバックタイプから区別する必要があってもよい。以下の選択肢が可能である。

【0176】

(D.1)選択肢1:UE間協調フィードバックのためのリソースの専用プール。

【0177】

(D.1.a)PSFCHシンボル上の別個のPRBビットマップは、UE間協調情報を搬送するPSFCHについて(事前)構成されてもよい。

【0178】

(D.1.b)期間L=1,2,4,8を有するスロット内のPSFCHリソースの別個の周期、及びいずれかの他の選択肢は、UE間協調情報を搬送するPSFCHのために(事前)構成されてもよい。

【0179】

図１２は、いくつかの態様によるHARQのためのRel.16 PSFCHとUE間協調フィードバックのためのRel.17 PSFCHとの多重化の図1200を示す。

【0180】

(D.2)選択肢2:共有PSFCHリソースプール。

【0181】

(D.2.a)選択肢2A:異なるリソースIDが、HARQ及びUE間協調フィードバックタイプのために使用される。この場合、PSFCHリソース決定は、PSFCHタイプの関数である。

【0182】

(D.2.b)選択肢2B:リソースIDの共通セットが、HARQ及びUE間協調フィードバックタイプのために使用される(すなわち、TX UEにトランスペアレントであり、UE間協調フィードバックは、HARQフィードバックと同じように扱われる)。

【0183】

(E)PSFCHリソース決定。

【0184】

(E.1)各フィードバック送信のためのPSFCHリソース決定(すなわち、PSFCHリソース送信のためのシーケンス、時間及び周波数リソースの決定)は、サイドリンク通信キャストタイプ及びHARQタイプに依存し得る以下の引数、すなわち、(サイドリンク競合が発生したか或いは発生し得る)スロットインデックス、(サイドリンク競合が発生したか或いは発生し得る)TX UEリソースインデックス、TX UEソースID(L1又はL2ソースID)、宛先ID(L1又はL2宛先ID)、TXゾーンID、TXターゲット通信範囲ID(SCI内のフィールド)、及びL1/L2宛先IDの一部でない場合のサービスID、又はこれらのサブセットの関数である。

【0185】

PSFCHリソース決定のための機能は、複数のRX UEが同じリソース上で同じシーケンスを送信するSFNタイプの送信をもたらしてもよい。

【0186】

一例では、UE間協調情報を搬送するPSFCHのためのPSFCHリソース決定手順は、3GPP TS38.213、セクション16.3において定義されているHARQフィードバックを搬送するPSFCHのものから、以下の修正によって再利用されてもよい。

【0187】

(E.2)UEは、PSSCH受信に応じてPSFCH送信のためのPSFCHリソースのインデックスを、(P_ID+M_ID+L_ID)modR_PRB,CS ^PSFCHとして決定する。ここで、P_IDは、PSSCH受信をスケジューリングするSCIフォーマット2-A又は2-B[5,TS38.212]によって提供される物理層ソースIDであり、M_IDは、UEが「01」のキャストタイプインジケータフィールド値を有するSCIフォーマット2-Aを検出した場合、上位レイヤによって示される、PSSCHを受信するUEの識別情報であり、そうでない場合、M_IDは0であり、L_IDは、UE間協調情報に対応するIDオフセットであり、PSFCHがHARQ情報を搬送する場合、L_ID=0である。UE間協調情報について、L_IDは、上位レイヤ構成又はSCIフォーマット2-A若しくは2-Bから導出され、上記に列挙されたパラメータの関数でもよい。

【0188】

(E.3)代替として、周波符号リソース選択のためのPSFCH PRBのセットR_PRB,CS ^PSFCH=N_type ^PSFCH・M_subch,slot ^PSFCH・N_CS ^PSFCHは、M_subch,slot ^PSFCHを2つの部分に分割することによって導出でき、第1の部分は、HARQを搬送する通常のPSFCHのためのものであり、第2の部分は、UE間協調情報を搬送するPSFCHのためのものである。

【0189】

フィードバックのためにより多くの情報を伝達するために、CRCを用いたFEC方式及び復調のための参照信号を有してもよいPSFCHのCRCベースの設計が導入されてもよい。

【0190】

(F)RX UEからのUE間協調フィードバックのためのターゲットTX UEの決定。

【0191】

(F.1)予約における半二重/衝突の場合、
(F.1.a)RX UEによって決定されるUE間協調フィードバックのためのターゲットUE。

【0192】

(F.1.a.1)選択肢1:衝突したTX UEの中で、送信の優先度がより低いTX UE(送信(プリエンプション動作)のために予約されたリソースを生じることが想定されるTX UEのみに送信される)。

【0193】

この場合、RX UEは、フィードバックのためのターゲットTX UEを決定するためにTX UEの優先度を考慮に入れることが想定される。この場合、受信されたフィードバックは、予約されたリソース上での送信を生じ、それを再選択するか或いはTX電力を低減するための要求として、TX UEによって解釈できる。フィードバックを受信していないUEは、予約されたリソース上で送信を継続する。

【0194】

(F.1.a.2)選択肢2:競合しているTX UE(リソース(再)選択をトリガするために、送信優先度にかかわらず全ての衝突するUEに送信される)。

【0195】

この場合、RX UEは、スロット当たりの同時フィードバックの最大数に関する制約を扱う優先度ルールに従って、競合している全てのUEにフィードバックを提供することが想定される。この場合、受信されたフィードバックは、予約されたリソースを再選択するか或いはTX電力を低減するための要求としてTX UEによって解釈できる。

【0196】

(F.1.a.3)選択肢3:送信のより高い優先度を有するTX UE(所与のTBについて再送を増加させることが想定されるTX UEのみに送信される)。

【0197】

この場合、RX UEは、フィードバックのためのターゲットTX UEを決定するためにTX UEの優先度を考慮に入れることが想定される。この場合、受信されたフィードバックは、影響を受けるTBのための再送方策を調整するか或いはTX電力を増加させるか或いはUE実装に基づく他の動作を行うための要求として、TX UEによって解釈できる。

【0198】

(F.1.a.4)UE間協調フィードバックの送信は、(事前)構成に従うことができる。(事前)構成は、TX UEに関連付けられたサイドリンク送信優先度値のサブセット(すなわち、上位レイヤによって事前構成されるか或いは事前定義されたサブセット)についてのみフィードバックの生成を制限してもよい。

【0199】

(F.1.a.5)UE間協調の送信はまた、輻輳制御関連の測定に依存できる。

【0200】

(F.1.a.6)上記の選択肢は排他的なものではない。

【0201】

(F.2)送信における半二重/衝突の場合、
(F.2.a)UE間協調フィードバックのためのターゲットUEは、RX UEによって決定される。

【0202】

(F.2.a.1)選択肢1:より低いか或いは等しい送信の優先度を有するTX UE。

【0203】

(F.2.a.2)選択肢2:送信の優先度に関係ないTX UE。

【0204】

(F.2.a.3)選択肢3:より高いか或いは等しい送信の優先度を有するTX UE。

【0205】

(F.2.a.4)全ての選択肢において、TX UEは、競合が既に発生しているのでリソースの譲歩を行うことが想定されないが、後続の送信のために再送方策及び/又はTX電力レベルを調整できる。

【0206】

(G)複数の予約における競合の取り扱い。

【0207】

現在のRel.16から、構成設定に依存して、各SCIは、N_SCI_maxが3である場合、最大で2つのリソースを予約できる。RX UEは、双方の予約における競合を検出してもよい。この場合、以下の選択肢が考慮できる。

【0208】

(G.1)選択肢1:競合している時間リソースおける最も早いものについてフィードバックを生成する。

【0209】

(G.2)選択肢2:競合している双方のリソースについてフィードバックを生成する。選択肢2は、TX及びRX UE挙動に関して不必要な複雑性をもたらす可能性があるが、選択肢1は、より簡単であり、したがって、仕様のために推奨できる。

【0210】

例示的な態様は、以下のうち1つ以上を含んでもよい。UE間協調フィードバックは、コンテンツが、送信機ソースID、リソースID、競合リソースのリソースID、UE間協調フィードバックタイプ、競合送信の送信優先度、又は上記のいずれかの組み合わせに基づく場合に構成される。フィードバックがPSFCH上でシグナリングされるUE間協調フィードバック方式が構成される。いくつかの態様では、単一のPRB、シーケンスベースのPSFCHが使用される。いくつかの態様では、Rel.16の定義から拡張された複数のPRB、シーケンスベースのPSFCHが使用される。いくつかの態様では、チャネルコード及びDMRSベースのPSFCHが使用される。いくつかの態様では、フィードバックは、第1及び第2段階のSCI上でシグナリングされる。いくつかの態様では、シグナリングは、フィードバック情報を含む新たな第1のSCIフォーマットを使用している。いくつかの態様では、シグナリングは、フィードバック情報を含む新たな第2のSCIフォーマットを使用している。いくつかの態様では、PSCCHベースのフィードバックの送信は、使用されるセンシング及びリソース選択手順に従う。いくつかの態様では、UE間協調を搬送するSCI1のためのリソースは、他のSCI送信とは別個に構成される。いくつかの態様では、SCI1のためのリソースは、別個のリソースプール内にある。いくつかの態様では、フィードバックは、MAC CEとして共有チャネル(PSSCH, shared channel)でシグナリングされる。いくつかの態様では、フィードバックは、ネットワーク(Uuインタフェース)を介してシグナリングされる。

【0211】

いくつかの態様では、PSFCH上のUE間協調フィードバックが、UE間協調のための専用リソースプールを用いて構成される。いくつかの態様では、別個のPRBビットマップは、UE間協調フィードバックのみのためのPSFCHリソースを示す。いくつかの実施形態では、PSFCHの別個の周期が、UE間協調フィードバックのためにのみ定義される。いくつかの実施形態では、PSFCH上のUE間協調フィードバックが、共有リソースプールを用いて構成される。いくつかの実施形態では、異なるリソースIDが、PSFCHタイプに依存して、UE間協調フィードバック及びHARQフィードバックのために使用される。いくつかの実施形態では、共通リソースIDが、UE間協調及びHARQフィードバックのために使用される。いくつかの実施形態では、PSFCHリソース決定方式が、UE間協調のために構成され、リソースは、スロットインデックス、Tx UEリソースインデックス、Tx UEソースID、宛先ID、TXゾーンID、Txターゲット通信範囲ID、サービスID、又は上記のいずれかの組み合わせの関数である。いくつかの実施形態では、リソース決定は、複数のUEがフィードバックを送信する場合、同じ周波数ネットワークタイプの送信を生じる。

【0212】

いくつかの態様では、PSFCHリソースは、(P_ID+M_ID+L_ID)modR_PRB,CS ^PSFCHとして計算され、ここで、P_IDは、PSSCH受信をスケジューリングするSCIフォーマット2-A又は2-Bによって提供される物理層ソースIDでありM_IDは、UEが「01」のキャストタイプインジケータフィールド値を有するSCIフォーマット2-Aを検出した場合、上位レイヤによって示される、PSSCHを受信するUEの識別情報であり、そうでない場合、M_IDは0であり、L_IDは、UE間協調情報に対応するIDオフセットであり、PSFCHがHARQ情報を搬送する場合、L_ID=0である。UE間協調情報について、L_IDは、上位レイヤ構成又はSCIフォーマット2-A若しくは2-Bから導出され、上記に列挙されたパラメータの関数でもよい。

【0213】

いくつかの態様では、周波符号リソース選択のためのPSFCH PRBのセットR_PRB,CS ^PSFCH=N_type ^PSFCH・M_subch,slot ^PSFCH・N_CS ^PSFCHは、M_subch,slot ^PSFCHを2つの部分に分割することによって導出でき、第1の部分は、HARQを搬送する通常のPSFCHのためのものであり、第2の部分は、UE間協調情報を搬送するPSFCHのためのものである。

【0214】

いくつかの実施形態では、UE間協調フィードバック方式が構成され、RX UEからのUE間協調フィードバックのためのターゲットTX UEの決定は、リソースを生じるより低い優先度を有するUEの想定での半二重/衝突予約の場合、より低い優先度を有する1つ以上のTx UEに基づき、リソース再選択の想定での半二重/衝突予約の場合、Tx UEは全ての送信側UEと競合し、更なる再送の想定での半二重/衝突予約の場合、より高い優先度を有するTxUEに基づき、再送方策及び他の送信信号考慮の想定での送信における半二重/衝突の場合、より低いか或いはより高い優先度を有するTx UEに基づき、再送方策及び他の送信信号考慮の想定で送信優先度に関係なくTx UEに基づく。

【0215】

いくつかの実施形態では、開示の技術は、UE間協調フィードバックのためのUEを決定するための方法を含む。いくつかの実施形態では、開示の技術は、以下の新たなUE挙動を構成するために使用できる。

【0216】

(a)センシング手順の一部としてのサイドリンク競合の分類及びサイドリンク競合のRXベースの決定。

【0217】

(b)TX UEに対するサイドリンク競合を示すフィードバックのためのUEの決定。

【0218】

(c)UE間協調フィードバックに基づくTXベースのリソース割り当ての拡張。

【0219】

いくつかの実施形態では、RX UE(UE_R)は、半二重又は同一チャネル衝突イベントを検出してもよく、TX UEに向けてUE間協調フィードバックを提供できる。以下の半二重及び同一チャネル衝突イベント、すなわち、送信における半二重(HD-TX, half-duplex in transmission)、予約における半二重(HD-RSV, half-duplex in the reservation)、受信における半二重(HD-RX, half-duplex in reception)、送信における同一チャネル衝突(CC-TX, co-channel collision in transmission)、及び予約における同一チャネル衝突(CC-RSV, co-channel collision in the reservation)は、RX UEによって検出できる。

【0220】

サイドリンク通信では、複数のRX UEがこのようなイベントを検出でき、したがって、UE間協調フィードバックを提供するための潜在的な候補と見なすことができる。いくつかの態様では、以下のこと、すなわち、どのRX UEがUE間協調フィードバックを提供すべきか、及びどのTX UEにフィードバックが提供されるべきかが、開示の技術に関連して考慮されてもよい。

【0221】

いくつかの態様では、開示の技術は、UE間協調フィードバックの送信のための候補UEを決定するために使用できる。UE間協調シグナリングのためのRX UE(UE_R)の中からの候補UEの決定は、以下を含んでもよい以下の条件のセットに従うことができる。

【0222】

(A)協調フィードバックは、UE間協調フィードバックシグナリングのための関連する条件及び構成設定を用いて(事前)構成される。

【0223】

(B)UE_Rは、TX UEの少なくとも1つ(すなわち、UE_Q又はUE_P)についてのグループメンバである。

【0224】

(B.1)グループメンバの定義は、UE間協調フィードバックのための事前定義/事前構成された距離基準(UER及びTX UE、すなわち、UEQ又はUEPの間)に従うことができる。特定の実施形態では、SCIにおいてTX UEによってシグナリングされたターゲット通信範囲が使用できる。

【0225】

(B.2)グループメンバの定義は、UE間協調フィードバックのための事前定義/事前構成されたSL-RSRP基準(UER及びTX UE、すなわち、UEQ又はUEPの間)に従うことができる。

【0226】

(B.3)グループメンバの定義は、共通の宛先ID及び/又はソースIDとの関連付けに従うことができる。

【0227】

(C)UE_Rは、通信サービスの観点からグループメンバとみなされないが、以下の条件を満たす。

【0228】

(C.1)どの選択肢(複数可)がサポートされ、事前定義/事前構成されるかに依存して、UE_Rは、UE_Pのみから事前定義/事前構成された距離(又は距離範囲)内にあるか、或いは、UE_Pのみから事前定義/事前構成されたSL-RSRP値(又はSL-RSRP値範囲)内にある。特定の実施形態では、SCIにおいてTX UEPによってシグナリングされたターゲット通信範囲が使用できる。

【0229】

(C.2)UE_Rは、UE_P送信に関連する半二重又は同一チャネル衝突を決定し、UE_Pへのその指示が必要とされる。

【0230】

(C.3)どの選択肢(複数可)がサポートされ、事前定義/事前構成されるかに依存して、UE_Rは、UE_Qのみから事前定義/事前構成された距離(又は距離範囲)内にあるか、或いは、UE_Qのみから事前定義/事前構成されたSL-RSRP値(又はSL-RSRP値範囲)内にある。特定の実施形態では、SCIにおいてTX UEQによってシグナリングされたターゲット通信範囲が使用できる。

【0231】

(C.4)UE_Rは、UEQ送信に関連する半二重又は同一チャネル衝突を決定し、UE_Qへのその指示が必要とされる。

【0232】

(C.5)どの選択肢(複数可)がサポートされ、事前定義/事前構成されるかに依存して、UE_Rは、UE_P及びUE_Qの事前定義/事前構成された距離(又は距離範囲)内にあるか、或いは、事前定義/事前構成されたSL-RSRP値(又はSL-RSRP範囲)内にある。

【0233】

(C.6)UE_Rは、1つより多くのTX UE(すなわち、UE_P及びUE_Q又は他のUE)への指示が必要であると決定する。

【0234】

いくつかの態様では、半二重/衝突指示に関する支援は、TX UEによってシグナリングされたターゲット通信範囲内又は外のUEよって、或いは、事前構成された距離又はSL-RSRP基準を使用して、提供できる。

【0235】

(D)UEが指示を提供することを想定されるか否かは、以下によって制御できる。

【0236】

(D.1)TX UEへの事前定義/事前構成されたSL-RSRP範囲[RSRP1,RSRP2]又はRSRP限界-RSRPmin。

【0237】

(D.2)TX UEへの事前定義/事前構成された距離[D1,D2]又は距離限界-Dmax。

【0238】

いくつかの態様では、これらの範囲はまた、輻輳制御の状態に依存できる。これは、CBR及び/又はCR測定値に基づいて関連する閾値を適応させることを意味し、これは、高度に輻輳した媒体の場合に、より少ない協調フィードバックを生じることができる。

【0239】

いくつかの態様では、各スロット内の送信の数を制御し、フィードバックを提供するUEの電力消費を低減するために、フィードバック送信に関する決定は、スロットインデックスと、割り当てられたUE ID又はフィードバックID(例えば、UEソースID、MACアドレス等)との関数でもよい。この場合、全てのUEは、フィードバックの送信のためにタイムスロットにわたって均等に分散されてもよい。例えば、スロットn内で送信することが想定されるUEは、以下の条件、すなわち、n=mod(UE ID,FeedbackCycle)を満たす必要があり、ここで、フィードバックサイクルは、各UEについてのフィードバック送信の間の最小時間間隔を定義する。要するに、フィードバック送信のためのスロットは、他のパラメータの関数として定義できる。各UE又はグループメンバは、フィードバック送信のための特定の時点/スロットに明示的に関連付けられることができる。

【0240】

代替として、確率的手法が使用でき、UEは、各スロット内でフィードバックを送信する必要があるか否かを決定するためにランダム変数/イベントを用いて構成できる。この場合、フィードバック送信の確率が構成できる。

【0241】

開示の技術は、以下の態様のうち1つ以上を含むことができる。RX UE(複数可)(例えば、UE_R)が、以下のサイドリンク競合、すなわち、送信における半二重(HD-TX, half-duplex in transmission)、予約における半二重(HD-RSV, half-duplex in the reservation)、受信における半二重(HD-RX, half-duplex in reception)、送信における同一チャネル衝突(CC-TX, co-channel collision in transmission)、及び予約における同一チャネル衝突(CC-RSV, co-channel collision in the reservation)を緩和/回避するための情報を含む1つ以上のフィードバックをTX UE(複数可)(例えば、UE_P/UE_Q)に提供する必要があるか否かを決定する方法が開示される。いくつかの実施形態では、RX UEが協調フィードバックを提供する必要があるか否かの決定は、グループメンバの決定(UE_Rは、TX UEのうち少なくとも1つ(すなわち、UE_Q又はUE_P)についてのグループメンバである)を含む、UE間協調フィードバックシグナリングのための関連する条件及び構成設定を用いて(事前)構成され、グループメンバ自体の決定は、UE間協調フィードバックのための事前定義/事前構成された距離基準(UE_R及びTX UE、すなわち、UE_Q又はUE_Pの間)に従うことができ(特定の実施形態では、SCIにおいてTX UEによってシグナリングされたターゲット通信範囲が使用できる)、グループメンバの決定は、UE間協調フィードバックのための事前定義/事前構成されたSL-RSRP基準(UE_R及びTX UE、すなわち、UE_Q又はUE_Pの間)に従うことができ、グループメンバの決定は、共通宛先ID及び/又はソースIDとの関連付けに従うことができる。

【0242】

いくつかの態様では、RX UEが協調フィードバックを提供する必要があるか否かの決定は、UE間協調フィードバックシグナリングのための関連する条件及び構成設定を用いて(事前)構成され、UE_Rが通信サービスの観点からグループメンバと見なされないが、以下の条件を満たすことを含む。UE_Rは、どの選択肢(複数可)がサポートされ、事前定義/事前構成されるかに依存して、UE_Pのみから事前定義/事前構成された距離(又は距離範囲)内にあることができ、或いは、UE_Pのみから事前定義/事前構成されたSL-RSRP値(又はSL-RSRP値範囲)内にあることができる。いくつかの態様では、SCIにおいてTX UE_Pによってシグナリングされたターゲット通信範囲が使用できる。いくつかの態様では、UE_Rは、UE_P送信に関連する半二重又は同一チャネル衝突を決定し、UE_Pへのその指示が必要とされる。

【0243】

どの選択肢(複数可)がサポートされ、事前定義/事前構成されるかに依存して、UE_Rは、UE_Qのみから事前定義/事前構成された距離(又は距離範囲)内にあるか、或いは、UE_Qのみから事前定義/事前構成されたSL-RSRP値(又はSL-RSRP値範囲)内にある。

【0244】

特定の実施形態では、SCIにおいてTX UE_Qによってシグナリングされたターゲット通信範囲が使用できる。

【0245】

いくつかの態様では、RX UEがフィードバックを提供する必要があるか否かの決定が使用できる。いくつかの態様では、UE_Rは、UE_Q送信に関連する半二重又は衝突を決定し、UE_Qへのその指示が必要とされる。

【0246】

いくつかの態様では、どの選択肢(複数可)がサポートされ、事前定義/事前構成されるかに依存して、UE_Rは、UE_P及びUE_Qの事前定義/事前構成された距離(又は距離範囲)内にあるか、或いは、事前定義/事前構成されたSL-RSRP値(又はSL-RSRP範囲)内にある。

【0247】

いくつかの態様では、UE_Rは、1つより多くのTX UE(すなわち、UE_P及びUE_Q又は他のUE)へのフィードバック指示が必要であると決定する。

【0248】

特定の実施形態では、SCIにおいてTX UE_Qによってシグナリングされたターゲット通信範囲が使用できる。

【0249】

いくつかの態様では、UE_Rは、UE_Q送信に関連する半二重又は衝突を決定し、UE_Qへのその指示が必要とされる。

【0250】

いくつかの態様では、どの選択肢(複数可)がサポートされ、事前定義/事前構成されるかに依存して、UE_Rは、UE_P及びUE_Qの事前定義/事前構成された距離(又は距離範囲)内にあるか、或いは、事前定義/事前構成されたSL-RSRP値(又はSL-RSRP範囲)内にある。

【0251】

いくつかの実施形態では、UE_Rは、1つより多く以上のTX UE(すなわち、UE_P及びUE_Q又は他のUE)への指示が必要であると決定する。

【0252】

いくつかの態様では、RX UEがフィードバックを提供する必要があるか否かの決定は、スロットインデックス及びUE ID(ソースID等)の事前定義された確率又は事前定義された関数を有するランダムプロセスを含む。

【0253】

エネルギー効率及び低電力消費は、現代のワイヤレス通信システム設計の主要な属性の1つである。電力節約機構/特徴は、無線インタフェースプロトコルに直接統合される。開示の技術は、NRサイドリンクエアインタフェースに適用される機構を含む。NR V2Xサイドリンク通信プロトコルは、主に車両間通信のために設計されたものであり、ミッションクリティカルなサービスのための信頼できる低レイテンシ通信能力を提供する。しかし、Rel.16 NR V2Xエアインタフェースにおける設計は、電力消費に関して非効率性を有する可能性があり、したがって、実質的な電力節約を提供することを対象とする新たな機構が、3GPPにおいて研究/議論中である。

【0254】

開示の技術は、物理層の特定の省電力態様を扱い、これらの態様に対する解決策を提供するために使用することができる。

【0255】

信頼性(例えば、リソース選択のためのセンシング)及び電力消費(例えば、ランダムリソース選択及び部分センシングベースのリソース選択)に基づく解決策は、特定の非効率性(例えば、高いUE電力消費、及び低レイテンシ下で超高信頼性を必要とするV2Xアプリケーションのための十分なレベルの信頼性にないこと)に関連付けられる。

【0256】

(A)UE間協調フィードバックに関連する拡張
(A.1)UE間協調情報処理能力指示。

【0257】

UE間協調フィードバックについて、このフィードバックが送信機によって考慮されるか否かを知ることは重要になり得る。送信から、送信側デバイスがUE間協調フィードバックに応答できるか否かは不明である。これは、トランスペアレントな方法で、例えば、HARQフィードバック生成を通じてフィードバックが提供されない限り、フィードバックを与えることができるUEがこの能力を知る必要があることを意味する。したがって、送信の中でUE間協調フィードバック考慮能力をシグナリングすることが有益である。特に、UEは、SCIにおいてUE間協調フィードバックを要求できる。これは、第1(SCIフォーマット1-X)又は第2(SCIフォーマット2-Y)段階のSCIにおいて、且つ、グループ又はユニキャスト接続設定中の能力交換中にシグナリングできる。

【0258】

第1段階のSCI(フォーマット1-X)。いくつかの態様では、構成可能な数の予約ビットが利用可能になり得る。したがって、これらの予約ビットを用いてUE間協調フィードバックに応答するデバイスの能力を表すことが可能である。この場合、送信するUEは、その送信においてこのビットを設定し、したがって、他のUEからのUE間協調フィードバックを要求する。

【0259】

代替として、新たなSCIフォーマット(複数可)が、後方互換性の問題を回避する別個に提供されたリソースプールにおいて監視されると仮定して、新たなSCIフォーマット1-Xが使用されてもよく、或いは、既存のSCIフォーマット1-A内の新たなフィールドのRRC構成可能な存在が指定されてもよい。

【0260】

第2段階のSCI(フォーマット2-Y)。いくつかの態様では、制御情報の送信機のUE間協調フィードバック能力に関する情報と、UE間協調フィードバックを提供するための要求とを含む、新たな第2段階のSCIフォーマットが定義されてもよい。可能な限り少ないビットを使用して制御チャネルにおいてこの能力をシグナリングする場合には、望ましい。これは、多くの場合、この能力をシグナリングするのに1ビットで十分であることを意味する。しかし、これは、この能力がシグナリングされるべきときに(事前)構成されてもよい。この処理は、物理層優先度、キャストタイプ及び/又は輻輳制御状態に依存できる。

【0261】

双方のSCIの場合(第1段階又は第2段階)において、UEはまた、以下のサイドリンク競合タイプ、すなわち、送信における半二重(HD-TX, half-duplex in transmission)、予約における半二重(HD-RSV, half-duplex in the reservation)、受信における半二重(HD-RX, half-duplex in reception)、送信における同一チャネル衝突(CC-TX, co-channel collision in transmission)、及び予約における同一チャネル衝突(CC-RSV, co-channel collision in the reservation)についてのフィードバックの要求を含み、どのタイプのフィードバックが要求されるかを指定したい場合、1ビットより多くを使用できる。

【0262】

いくつかの態様では、ユニキャスト又はグループキャスト接続設定中にUE間協調フィードバックの交換を可能にするために、ユニキャスト及びグループキャストが使用できる。接続設定中の情報交換は、最も単純な場合には、UE間協調に応答するための能力の1ビット指示でもよい。しかし、UE間協調によって衝突タイプ毎に別個の能力をシグナリングすることも可能である。競合タイプは、送信における半二重(HD-TX, half-duplex in transmission)、予約における半二重(HD-RSV, half-duplex in the reservation)、受信における半二重(HD-RX, half-duplex in reception)、送信における同一チャネル衝突(CC-TX, co-channel collision in transmission)、及び予約における同一チャネル衝突(CC-RSV, co-channel collision in the reservation)とすることができる。

【0263】

いくつかの態様では、この能力は、物理層送信優先度毎に更に定義できる。これは、例えば、高い優先度の場合に、UEがUE間調整フィードバックにのみ応答することを可能にする。要求されるフィードバックタイプのセットは、(事前)構成シグナリングを通じて優先度値に関連付けられることができる。

【0264】

(A.2)協調フィードバックのための宛先UE(宛先選択の詳細)。

【0265】

いずれかのタイプ(例えば、HD-TX、HD-RSV、HD-RX、CC-TX及びCC-RSV)の衝突の検出の結果として、協調UEは、1つ又は複数のTX UEへの1つ又は複数のUE間協調フィードバックを生成してもよい。複数のフィードバックの生成は、以下の問題をもたらす可能性がある。

【0266】

(A.2.a)フィードバック物理チャネルの過負荷。

【0267】

(A.2.a.1)協調UEは、異なるUEにアドレス指定された複数のフィードバックを同時に生成しなければならない場合がある。多数の生成されたフィードバックは、いくつかの理由、例えば、送信電力共有、増加したペイロードサイズ等に起因して、フィードバック配信信頼性を低減する可能性がある。

【0268】

(A.2.a.2)協調UEがフィードバックの数に関して制限された送信能力を有する場合、いくつかのフィードバックは、優先順位を下げられる(例えば、ドロップされるか或いは低減された電力で送信される)必要があってもよい。

【0269】

(A.2.b)システム全体の性能低下。

【0270】

(A.2.b.1)いくつかの場合、システム全体の性能は、選択的UE間協調フィードバック報告から利益を得ることがある。例えば、CC-RSV又はHD-RSVが検出された場合、協調UEは、全ての検出されたサイドリンク競合参加者にフィードバックを報告してもよい。協調フィードバックを受信した各UEがリソース再選択を実行する場合、新たな非シグナリングリソースが各UEによって選択されるので、システム性能を劣化させる可能性がある。その結果、このような挙動は、予約リソースが、センシング中に他のUEによって候補リソースから既に除外されたが、最終的に送信のために使用されなかった場合、システム性能を劣化させる可能性がある。

【0271】

(A.3)UE間協調フィードバックのために宛先UEを選択するためのルール(優先順位付けルール)。

【0272】

一実施形態では、N個の参加ノードとの衝突が検出された場合、協調UEは、これらのうちのK個にフィードバックを送信することを選択してもよい。例えば、フィードバックのためにN個の検出された候補からK個を選択するために、以下の選択肢又は選択肢の組み合わせが使用されてもよい。

【0273】

(A.3.a)選択肢1:NからKのランダムな選択。

【0274】

(A.3.b)選択肢2:リソース予約シグナリング送信のタイミング(サイドリンクフレーム/スロットインデックスのランキング)に基づく。この場合、予約情報受信のパラメータは、フィードバック先を選択するために使用されてもよい。一実施形態では、サイドリンク競合を有する予約リソースに先行するリソースのスロットインデックス又はスロットインデックスの送信に関する情報が使用されてもよい。協調フィードバックは、その予約情報を最も最近に送信したUE(すなわち、競合を生じる最も最近の予約を行ったUE、すなわち、予約が競合を生じたもの)に送信されてもよい。

【0275】

(A.3.c)選択肢3:リソース予約シグナリングに基づく。検出された衝突を有するリソースに先行する、示されたリソースのパラメータは、協調フィードバック先を選択するために使用されてもよい。例えば、協調フィードバックは、より低い(或いはより高い)インデックスを有するPRBを用いてリソース割り当てを開始するUEに向けて生成されてもよい。

【0276】

(A.3.d)選択肢4:制御シグナリングのパラメータ。一実施形態では、ソースID及び送信の優先度、サイドリンク競合のタイプが、協調フィードバック先を選択するために使用されてもよい。

【0277】

(B)部分センシングに関連する拡張
(B.1)非周期的トラフィックのための監視ウィンドウ設定(TA,TB)。

【0278】

いくつかの態様では、非周期的トラフィックは未知のパケット到着時間を有する。パケット到着の直前にウェイクアップして無線環境をセンシングすることは可能でないことがあり、したがって、部分センシング手順は、リソース(再)選択トリガによって直接アクティブ化できる。この場合、以下の2つの選択肢が可能である。

【0279】

選択肢1:UEは、N=32個の論理スロット(SCIシグナリングウィンドウ持続時間)の間に部分センシングを実行し、次いで、TBの最後の再送までセンシングを継続しつつ、リソース選択手順をトリガする。

【0280】

選択肢2:UEは、部分センシング及びリソース選択手順の双方を同時にトリガする。この場合、UEは、N=32個の論理スロットからセンシング情報を集約する前に、最終的に送信できる。

【0281】

選択肢2は、パケット遅延バジェットが十分に大きい場合、選択肢1がUE実装によって達成され得るので、より一般的であると考えられてもよい。これに関して、以下の監視ウィンドウ設定が使用できる。

【0282】

(a)TA≦ΔA(監視ウィンドウがスロット「n+1」から開始する場合、ΔA=1スロット)。ΔAの値は、スリープ状態から監視状態に切り替えるために必要とされる最大時間に依存してもよい(これは、異なるスリープ状態、すなわち、マイクロ、ライト、ディープについて異なるものとすることができる)。この処理は、リソース(再)選択トリガが受信されたときにUEがスリープ状態にある可能性があるという仮定に基づいてもよい。

【0283】

いくつかの態様では、リソース(再)選択トリガ(到着パケット)の時点「n」が事前に知られていないことを考えると、これはUEによって補償できないので、これは監視ウィンドウ定義に影響を及ぼすと仮定されてもよい。

【0284】

いくつかの態様では、UEは、物理層がリソース(再)選択トリガを受信するときまでに、デバイスが既に監視状態にあることを確保する。これは、デバイスがいずれかの可能なスリープ状態からウェイクアップするまで、上位レイヤが、上位レイヤにおけるリソース(再)選択トリガを遅延させていることを意味する。これは、デバイス固有のウェイクアップ時間が正確に考慮できるという利点を有する。

【0285】

(b)TB=ΔB-T3≦PDB。

【0286】

(b.1)選択肢1:T3≦Tproc,x=(Tproc,1+Tproc,0)。

【0287】

(b.2)選択肢2:T3≦Tproc,x=Tproc,1。

【0288】

(b.3)選択肢3:T3≦Tproc,x=Tproc,0。

【0289】

(b.4)選択肢4:T3=0。

【0290】

(b.5)選択肢5:T3は、Tproc,1及びTproc,0又はこれらのいずれかの組み合わせとは異なる所定の値に等しい。

【0291】

(b.6)場合A(HARQ有効化)。ΔBは、所与のサイドリンクHARQプロセスについての最後のHARQフィードバックが受信されると想定されるスロットに対応する。NACKのみのモードでは、NACKが検出されなかったPSFCHスロット。ACK/NACKモードでは、最後に想定されるACKが受信されたPSFCHスロット。

【0292】

(b.7)場合B(HARQ無効-ブラインド送信)。ΔBは、TBの最後の(再)送信を搬送するスロットに対応する。

【0293】

(b.8)場合C(最後の再送)。ΔBは、HARQフィードバックがTX UEによって要求されるか否かにかかわらず、TBの最後の(再)送信を搬送するスロットに対応する。

【0294】

(b.9)場合D(HARQ+UE間協調フィードバック)。ΔBは、UE間協調フィードバックによってトリガされ得る、TBの最後の再送のためのHARQフィードバックを搬送するスロットに対応する。

【0295】

(b.10)場合E(HARQが無効化されたUE間協調フィードバック)。ΔBは、UE間協調フィードバックによってトリガされる、TBの最後の(再)送信を搬送するスロットに対応する。

【0296】

いくつかの実施形態では、TBの値は、所与のTBの最後の再送又は所与のTBについて提供される最後のHARQフィードバックを有するスロットに依存できる。

【0297】

(B.2)周期的トラフィックのための監視ウィンドウ設定(TA,TB)。

【0298】

半永続的送信/予約はリソースプールによってサポートされない可能性があるが、実装によるUEは、周期的トラフィックの場合にパケット到着時間を依然として予測でき、したがって、TBの次の送信の直前にウェイクアップし、無線環境をセンシングできる。この場合、UE部分センシングは、リソース再選択トリガの前のN=32個の論理スロットにトリガでき、それにより、1つのSCIシグナリングウィンドウにわたるセンシングデータは、新たなTB/パケット到着の前に利用可能になる。この場合、以下の2つの選択肢が可能である。

【0299】

選択肢1:UEは、32個の論理スロット(SCIシグナリングウィンドウ持続時間)上で次のリソース再選択トリガの前に部分センシングをトリガし、TBの最後の再送までセンシングを継続する。

【0300】

選択肢2:UEは、部分センシング及びリソース再選択手順の双方を同時にトリガする。この場合、UEは、32個の論理スロットからセンシング情報を集約した時間までに最終的に送信できる。

【0301】

選択肢1は、半永続的な予約がリソースプールにおいて無効にされるときの周期トラフィックに最適である。これはまた、半永続的な予約がサイドリンクリソースプールにおいて有効化される場合、周期的及び非周期的トラフィックのより良好な共存のために適用されてもよい。したがって、選択肢1は、周期的トラフィックに関連付けられた送信に対してより高い信頼性を提供することができるので、リソースプール内の有効化された半永続的予約の場合について同様の挙動が合意される場合、いくつかの態様で使用できる。

【0302】

いくつかの実施形態では、以下の監視ウィンドウ設定が使用できる。

【0303】

(a)-max((ΔA+tn-32),リソース選択ウィンドウサイズ)≦TA≦1スロットであり、tn-32は、物理インデックスnを有するスロットの前の32個の論理スロットまでの物理スロットにおける距離である。ΔAの値は、監視ウィンドウの開始が以下によって決定されるように、UE実装によって適応できる。

【0304】

(a.1)選択肢1:-max(tn-32スロット,リソース選択ウィンドウサイズ)≦TA≦1スロット
(a.2)選択肢2:TA=-max(tn-32スロット,リソース選択ウィンドウサイズ)。

【0305】

(a.3)選択肢3:-max((ΔA+tn-32),リソース選択ウィンドウサイズ)≦TA≦1スロットの範囲内で上位レイヤによって物理層に提供される。

【0306】

(b)TB(例えば、非周期的トラフィックの場合と同じ選択肢が使用できる)。

【0307】

(B.3)候補スロットの最小値Y。

【0308】

いくつかの態様では、候補スロットの最小数Yについての値の範囲は、部分センシングを使用するUEが監視する必要があるスロットの数を調整する。LTE V2Xにおける部分センシングについて、1～13の範囲内の値が定義できる。Yの最小値は、T2,minによって決定される最小リソース選択ウィンドウとして優先度レベル毎に定義されるべきであり、これも優先度の関数である。

【0309】

(B.4)輻輳制御。

【0310】

部分センシングの場合、CBR測定のために使用されるスロットの数は、完全センシングと比較して低減できる。実験/平均化の欠如に起因して、粗いCBR測定及びその変動/偏差は、輻輳制御の場合にシステム性能に影響を及ぼす可能性がある。この理由は、この測定のために使用される低減した量のリソースであり、したがって測定の増加した偏差があるためである。

【0311】

Rel.16 NR V2Xでは、CBR測定値の変化のため、輻輳制御状態も変化する可能性があり、異なるMCSがTBの更なる再送のために選択され得ることが可能である。Rel.16 NR V2Xにおける変更されたMCSは、多くの場合、異なる割り当てサイズ及び異なるTBSを生じる可能性がある。TBSが変更された場合、LLRを組み合わせる物理層はもはや可能ではない。したがって、HARQの一般的な原理が破られる。Rel.17 NR V2Xにおける部分センシングのため、これは、粗いCBR測定に起因してより頻繁に起こる可能性がある。

【0312】

いくつかの態様では、この問題に対する例示的な解決策は、MCSを保持し、TBの最初の送信のために選択されたものを使用することである。しかし、これは、共有伝送媒体の現在の状態に常に完全に適合されるとは限らない。

【0313】

いくつかの態様では、部分センシングUEのための輻輳制御状態の量を制限することが可能になり得る。これは、推定品質が低下しても、後続の送信のために状態を変更する可能性が低減されることを意味する。

【0314】

いくつかの態様では、CBR測定値に依存してサブチャネルの数、再送、MCSエントリ及びTX電力を制御するために、部分センシングモードにあるUEのための新たなCBRテーブルを定義することが可能になり得る。

【0315】

(B.5)UE SL DRX及び部分センシング挙動の相互作用。

【0316】

いくつかの実施形態では、定義による完全センシングはデバイスがDRX状態に入ることを可能にしないので、SL DRX及び完全センシングの構成は相互に排他的になる可能性がある。SL DRX構成は、DRX機構を使用するデバイス(すなわち、TX UE)のトラフィックのプロパティを考慮することができる。さらに、部分センシング手順は、全ての潜在的な受信機(すなわち、RX UE)のSL DRX構成を考慮する必要がある。以下の例では、ユニキャストシナリオのための構成について説明する。これらを複数の受信者との通信に適合させるために、SL DRX構成は、全ての既知のアクティブ時間の交点を表す。グループキャストについては、SL DRXを使用する全ての参加デバイスが、これらのDRXサイクルを同期させるか、或いは、少なくとも最小パターンに合意することが可能である。

【0317】

(B.5.a)周期的トラフィック。

【0318】

周期的トラフィックの場合、SL DRXアクティブ時間は、周期的送信間隔と整合する必要がある。この点に関して、半永続的な予約について、UEは、受信者のアクティブ時間内でのみリソースを選択できる。この処理は、SL DRXの周期を周期的送信と同じにするか或いはその整数倍にすることによって実現できる。この処理は、周期的トラフィックの各送信について少なくとも1つのSL DRXアクティブ時間が存在すことを確保する。

【0319】

(B.5.b)非周期的トラフィック。

【0320】

非周期的トラフィックの場合、SL DRXアクティブ時間周期は、想定される通信周波数及びPDBと整合してもよい。これは、物理層が非アクティブ時間中にリソース選択トリガを受信した場合、許可されたPDBが後続のSL DRXアクティブ時間のうち少なくとも1つと重複することが確保される必要があることを意味する。

【0321】

周期的及び非周期的トラフィックについて、最小SL DRXアクティブ時間は、少なくとも最小リソース選択時間ウィンドウT2,minと同じ大きさとすることができ、そうでなければ、モード2リソース選択アルゴリズムの公平性原理が破られる可能性がある。

【0322】

以下の段落は、SL DRXアクティブ時間がリソース選択のための選択ウィンドウをどのように制限するかについて更に記載する。この処理は、非周期的トラフィック及び周期的トラフィックについて同じように行うことができる。いくつかの態様では、設定SL DRXアクティブ時間は、これらの場合について異なる方法で構成されてもよい。

【0323】

図１３は、いくつかの態様によるSL DRXアクティブ時間の前に開始する最小選択ウィンドウを用いたリソース(再)選択トリガの例の図1300を示す。

【0324】

図１３では、リソース再選択トリガは、SL DRXアクティブ時間の前に来る。最小選択ウィンドウはSL DRX時間と完全に重複しないので、極端な場合には、最小選択ウィンドウがSL DRX時間と重複しない可能性がある。したがって、この場合、最小選択ウィンドウの開始をSL DRXアクティブ時間の開始に調整することが必要になる。

【0325】

SL DRXアクティブ時間の開始の前にトラフィックが到着した場合、以下の解決策が可能である。

【0326】

(a)解決策1:リソース(再)選択トリガは、上位レイヤによって遅延される。この場合、上位レイヤは、スロットnにおけるリソース(再)選択トリガを示し、スロットnについて、選択ウィンドウ(n+T1)の最も遅い可能な開始が、送信の全ての潜在的な受信者のSL DRXアクティブ時間内に既にあることが確保される。

【0327】

(b)解決策2.選択ウィンドウの開始は、リソース選択によってSL DRXアクティブ時間の開始に設定される。選択ウィンドウの対応する最も早い終了時間は、それに従ってウィンドウのこの遅い開始を考慮するようにシフトされる。

【0328】

いくつかの態様では、解決策2について、リソース選択ウィンドウの開始時間の計算は変更される必要がある。現在、完全センシングについて、T1は、0≦T1≦Tproc,1の範囲でUE実装に任されている。SL DRXアクティブ時間の開始時間に適応するために、これは、n+Tproc,1<nactive,start及びn+Tproc,1≧nactive,startの2つの場合が区別される必要があることを意味し、nactive,startはSL DRXアクティブ時間の開始である。

【0329】

(b.1)n+Tproc,1<nactive,startの場合:T1の値は、nactive,start-n≦T1≦Tproc,1の範囲でUE実装に任される。

【0330】

(b.2)n+Tproc,1≧nactive,startの場合:センシングウィンドウは最小処理時間の後に開始するので、T1=nactive,start-nである。

【0331】

図１４は、いくつかの態様によるSL DRXアクティブ時間の後に終了する最小選択ウィンドウを用いたリソース(再)選択トリガの例の図1400を示す。

【0332】

図１４において、最小選択ウィンドウは、SL DRXアクティブ時間を超えて延びている。SL DRX時間外のリソースが選択された場合、それらは潜在的に受信されない可能性がある。この問題に対する以下の解決策が使用できる。

【0333】

(a)解決策1:最小選択ウィンドウが達成できない場合、リソース選択は、次のSL DRXアクティブ時間まで遅延される。この遅延は、上位レイヤで行われてもよい。また、物理層が、リソース割り当てが可能でないことを上位レイヤに報告することも可能である。場合によっては、次のSL DRXアクティブ時間及びPDBが与えられた場合に送信が達成できるか否かの情報さえも与える。その後、上位レイヤは、次のSL DRXアクティブ時間において、送信をドロップするか、或いは、リソース(再)選択を再トリガするかのいずれかを決定してもよい。このシナリオは、非周期的トラフィックに対してのみ行われるべきである点に留意する。

【0334】

(b)解決策2:選択のために利用可能になり得る最小選択ウィンドウの一部を定義する。そうでない場合、リソース選択は解決策1のように処理されるべきである。

【0335】

解決策2について、リソース選択ウィンドウの終了は、SL DRXアクティブ時間の既知の終了を考慮する。Rel.16 NR V2Xについての関連するパラメータの定義は以下の通りである。「T2minが(スロット単位の)残りのパケット遅延バジェットより短い場合、T2は、T2min≦T2≦(スロット単位の)残りのパケットバジェットに従うUE実装であり、そうでない場合、T2は(スロット単位の)残りのパケット遅延バジェットに設定される」。SL DRXアクティブ時間の終了に適応させるために、定義は、「T2minがmin((スロット単位の)残りのパケット遅延バジェット,(スロット単位の)残りのRX SL DRXアクティブ時間)より短い場合、T2は、T2min≦T2≦min((スロット単位の)残りのパケット遅延バジェット,(スロット単位の)残りのRX SL DRXアクティブ時間)に従うUE実装であり、そうでない場合、T2はmin((スロット単位の)残りのパケット遅延バジェット,(スロット単位の)残りのRX SL DRXアクティブ時間)に設定される」と再公式化できる。

【0336】

上記の考慮に加えて、部分センシングはまた、HARQ又はUE間協調フィードバックのいずれかによる再送の場合も考慮してもよい。これは、リソース選択が、何らかのフィードバックが受信された場合にSL DRXアクティブ時間がどれだけ延長されるかを知る必要があることを意味する。

【0337】

開示の技術は、以下の態様のうちの1つ以上を含んでもよい。UE間協調フィードバックを有するNRサイドリンク通信の方法が開示され、サイドリンクUE間協調フィードバックの要求と、サイドリンクUE間協調フィードバック設定のネゴシエーションと、UE間協調フィードバック送信のための優先順位付けルールとを含む。

【0338】

いくつかの態様では、サイドリンクUE間協調フィードバックの要求は、サイドリンクUE間協調の要求のSCIにおける少なくとも1つの指示と、要求されたサイドリンクUE間協調フィードバックのタイプのSCIにおける指示と、UE間協調フィードバック処理のための能力の交換とを含む。

【0339】

いくつかの態様では、指示は、UE間協調フィードバックの要求及び/又はそのタイプを示すためのSCIフォーマット1A/1B又は2A/2B内の予約ビットの使用と、UE間協調フィードバックの要求及びそのタイプを示すための新たなSCIフォーマット1X/1Y又は2X/2Yの設計と、UEがUE間協調フィードバックをサポートするという能力指示とを含む。

【0340】

いくつかの実施形態では、UE間協調フィードバックのタイプは、送信における半二重(HD-TX, half-duplex in transmission)、予約における半二重(HD-RSV, half-duplex in the reservation)、受信における半二重(HD-RX, half-duplex in reception)、送信における同一チャネル衝突(CC-TX, co-channel collision in transmission)、及び予約における同一チャネル衝突(CC-RSV, co-channel collision in the reservation)を含む。

【0341】

いくつかの態様では、サイドリンクUE間協調フィードバック設定のネゴシエーションは、フィードバックに対して送信及び応答する能力と、異なるタイプ(例えば、HD-TX、HD-RSV、HD-RX、CC-TX及びCC-RSV)に関連するフィードバックに対して送信及び応答する能力と、送信優先度によって分離されたフィードバックに対して送信及び応答する能力とを含む。

【0342】

いくつかの実施形態では、UE間協調フィードバック送信のための優先順位付けルールは、シグナリングされるUE間協調フィードバックのためのUE要求と、それを処理するためのUE能力と、フィードバックを送信するためのUE能力に従って与えられ得る全てのフィードバックからのランダム選択と、予約されたスロット/サブチャネルに基づいて、競合するUEがそれぞれのリソース予約を送信したタイミングと、制御シグナリングのパラメータとを含む。

【0343】

いくつかの実施形態では、UE間協調フィードバックは、どの送信が作成したサイドリンク競合が、競合を生じる最後の予約を有するフレーム/スロットインデックスを含むかについてUEに提供される。

【0344】

いくつかの態様では、部分センシングのための方法は、周期的トラフィック及び/又は非周期的トラフィックをセンシングすることを含む。いくつかの態様では、非周期的トラフィックについてのセンシングは、リソース選択トリガの前に開始する。いくつかの態様では、非周期的トラフィックについてのセンシングは、リソース再選択トリガと同時に開始する。いくつかの態様では、監視ウィンドウは、スリープ状態からアクティブ監視への切り替え時間、又はスリープ状態からアクティブ監視への定義された最大切り替え時間よりも短いデバイス実装固有のものに依存して、リソース再選択トリガの1スロット後に開始する。いくつかの態様では、監視ウィンドウは、TBの最後の再送の前の最大処理時間、又は残りのPDBの終了の前の最大処理時間において停止する。いくつかの態様では、周期的トラフィックについてのセンシングは、リソース選択トリガの前に開始する。いくつかの態様では、周期的トラフィックについてのセンシングは、リソース再選択トリガと同時に開始する。いくつかの態様では、監視ウィンドウは、先行する送信のSCIにおいて予約された全ての更なる送信が経過したことを確保するスロットにおいて、1つよりも大きいが上記のスロットよりも小さい実装定義されたスロットにおいて、リソース再選択トリガから開始する上記のスロット又はリソース選択ウィンドウの最大値が経過したことを確保するスロットにおいて、及び/又は1よりも大きいが上記のスロットよりも小さい実装定義されたスロットにおいて開始する。

【0345】

いくつかの態様では、監視ウィンドウは、TBの最後の再送の前の最大処理時間、又は残りのPDBの終了の前の最大処理時間において停止する。

【0346】

いくつかの実施形態では、候補リソースの最小数は、送信優先度毎に定義される。いくつかの態様では、輻輳制御に関係する送信パラメータは、同じTBの後続の送信について変更されない。いくつかの態様では、輻輳制御に関係する送信パラメータは、部分センシングのみのために再定義される。いくつかの態様では、SL DRX構成は、周期的トラフィックの周期及び関連するPDB要件と整合される。いくつかの態様では、SL DRX構成は、非周期的トラフィックの想定通信周波数及びトラフィックPDB要件と整合される。いくつかの態様では、全ての受信者のためのSL DRX構成は、送信のために知られている。いくつかの態様では、リソース選択ウィンドウの開始は、受信機のSL DRXアクティブ時間の開始と整合される。いくつかの態様では、リソース選択トリガは遅延され、SL DRXアクティブ時間開始とのリソース選択ウィンドウ整合を確保する。いくつかの態様では、リソース選択は、上位レイヤにおいてリソース(再)選択トリガを遅延させること、又は物理層においてリソース(再)選択を遅延させることによって、最小リソース選択ウィンドウが残りのSL DRXアクティブ時間に収まることができない場合、次のSL DRXアクティブ時間まで遅延される。

【0347】

いくつかの実施形態では、優先度毎に、部分センシング固有の最小リソース選択ウィンドウが定義される。いくつかの実施形態では、同じTBの後続の送信のためのリソース選択ウィンドウ終了は、SL DRXアクティブ時間の終了と整合される。

【0348】

図１５は、いくつかの態様による、進化型NodeB(eNB, evolved Node-B)、新世代Node-B(gNB, new generation Node-B)(又は別のRANノード若しくは基地局)、送受信ポイント(TRP, transmission-reception point)、アクセスポイント(AP, access point)、ワイヤレス局(STA, wireless station)、移動局(MS, mobile station)又はユーザ機器(UE, user equipment)のような通信デバイスのブロック図を示す。代替の態様では、通信デバイス1500は、スタンドアロンデバイスとして動作してもよく、或いは、他の通信デバイスに接続(例えば、ネットワーク接続)されてもよい。

【0349】

回路(例えば、処理回路)は、ハードウェア(例えば、簡単な回路、ゲート、ロジック等)を含むデバイス1500の有形のエンティティに実装される回路の集合である。回路のメンバーシップは、時間と共に柔軟になってもよい。回路は、動作するときに指定の動作を単独で或いは組み合わせて実行し得る部材を含む。一例では、回路のハードウェアは、特定の動作を実行するように不変に設計されてもよい(例えば、ハードワイヤード)。一例では、回路のハードウェアは、特定の動作の命令を符号化するために物理的に修正(例えば、磁気的に、電気的に、不変集合粒子の移動可能な配置等)された機械可読媒体を含む、可変的に接続された物理コンポーネント(例えば、実行ユニット、トランジスタ、簡易回路等)を含んでもよい。

【0350】

物理コンポーネントを接続する際に、ハードウェアコンポーネントの基礎となる電気特性は、例えば、絶縁体から導体に、或いはその逆に変更される。命令は、埋め込みハードウェア(例えば、実行ユニット又はローディング機構)が、動作中に特定の動作の一部を実行するために、可変の接続を介してハードウェア内に回路のメンバを作成することを可能にする。したがって、一例では、機械可読媒体要素は、回路の一部であるか、或いは、デバイスが動作しているときに回路の他のコンポーネントに通信可能に結合される。一例では、物理コンポーネントのいずれかは、1つより多くの回路の1つより多くのメンバで使用されてもよい。例えば、動作中に、実行ユニットは、或る時点で第1の回路の第1の回路において使用され、異なる時点で第1の回路の第2の回路によって或いは第2の回路の第3の回路によって再利用されてもよい。デバイス1500に関するこれらのコンポーネントの更なる例が以下に続く。

【0351】

いくつかの態様では、デバイス1500は、スタンドアロンデバイスとして動作してもよく、或いは、他のデバイスに接続(例えば、ネットワーク接続)されてもよい。ネットワーク接続された展開において、通信デバイス1500は、サーバクライアント型ネットワーク環境においてサーバ通信デバイス、クライアント通信デバイス又はこれらの双方の能力で動作してもよい。一例では、通信デバイス1500は、ピアツーピア(peer-to-peer, P2P)(又は他の分散)ネットワーク環境においてピア通信デバイスとして動作してもよい。通信デバイス1500は、UE、eNB、PC、タブレットPC、STB、PDA、携帯電話、スマートフォン、ウェブ機器、ネットワークルータ、スイッチ若しくはブリッジ、又はその通信デバイスにより行われるべき動作を指定する命令(順次又は他の命令)を実行できるいずれかの通信デバイスでもよい。さらに、単一の通信デバイスのみが示されているが、「通信デバイス」という用語はまた、クラウドコンピューティング、サービスとしてのソフトウェア(SaaS, software as a service)、他のコンピュータクラスタ構成のように、ここで議論される方法論のうちいずれか1つ以上を実行するための命令のセット(又は複数のセット)を個別に或いは共同で実行する通信デバイスのいずれかの集合も含むと解釈されるものとする。

【0352】

ここで説明する例は、ロジック又は多数のコンポーネント、モジュール又はメカニズムを含んでもよく、或いは、これらで動作してもよい。モジュールは、指定の動作を実行できる有形のエンティティ(例えば、ハードウェア)であり、特定の方式で構成又は配置されてもよい。一例では、回路は、指定の方式でモジュールとして(例えば、内部的に或いは他の回路のような外部エンティティに対して)配置されてもよい。一例では、1つ以上のコンピュータシステム(例えば、スタンドアロン、クライアント又はサーバコンピュータシステム)又は1つ以上のハードウェアプロセッサの全体又は一部は、指定の動作を実行するように動作するモジュールとして、ファームウェア又はソフトウェア(例えば、命令、アプリケーション部分又はアプリケーション)により構成されてもよい。一例では、ソフトウェアは、通信デバイス可読媒体上に存在してもよい。一例では、ソフトウェアは、モジュールの基礎となるハードウェアにより実行されると、ハードウェアに対して指定の動作を実行させる。

【0353】

したがって、「モジュール」という用語は、指定の方式で動作するように或いはここで説明するいずれかの動作の一部又は全部を実行するように、物理的に構築されるか、具体的に構成される(例えば、配線される)か、或いは一時的に(例えば、過渡的に)構成される(例えば、プログラムされる)エンティティである有形のエンティティを包含するものと理解される。モジュールが一時的に構成される例を考慮すると、モジュールのそれぞれは、いずれか1つの時点にインスタンス化される必要はない。例えば、モジュールがソフトウェアを使用して構成された汎用ハードウェアプロセッサを含む場合、汎用ハードウェアプロセッサは、異なる時間にそれぞれ異なるモジュールとして構成されてもよい。したがって、ソフトウェアは、ハードウェアプロセッサを、例えば、1つの時点に特定のモジュールを構成し、異なる時点に異なるモジュールを構成するように構成してもよい。

【0354】

通信デバイス(例えば、UE)1500は、ハードウェアプロセッサ1502(例えば、中央処理装置(CPU, central processing unit)、グラフィックス処理ユニット(GPU, graphics processing unit)、ハードウェアプロセッサコア又はこれらのいずれかの組み合わせ)と、メインメモリ1504と、スタティックメモリ1506と、記憶デバイス1507(例えば、ハードドライブ、テープドライブ、フラッシュストレージ又は他のブロック若しくは記憶デバイス)とを含んでもよく、これらの一部又は全部は、インターリンク(例えば、バス)1508を介して互いに通信してもよい。

【0355】

通信デバイス1500は、ディスプレイデバイス1510と、英数字入力デバイス1512(例えば、キーボード)と、ユーザインタフェース(UI, user interface)ナビゲーションデバイス1514(例えば、マウス)とを更に含んでもよい。一例では、ディスプレイデバイス1510、入力デバイス1512及びUIナビゲーションデバイス1514は、タッチスクリーンディスプレイでもよい。通信デバイス1500は、信号生成デバイス1518(例えば、スピーカ)と、ネットワークインタフェースデバイス1520と、全地球測位システム(GPS, global positioning system)センサ、コンパス、加速度計又は他のセンサのような1つ以上のセンサ1521とを更に含んでもよい。通信デバイス1500は、1つ以上の周辺デバイス(例えば、プリンタ、カードリーダ等)と通信又は制御するために、シリアル(例えば、ユニバーサルシリアルバス(USB, universal serial bus))、パラレル又は他の有線若しくは無線(例えば、赤外線(IR, infrared)、近距離通信(NFC, near field communication)等)接続のような出力コントローラ1528を含んでもよい。

【0356】

記憶デバイス1507は、ここで説明する技術又は機能のいずれか1つ以上を具現するか或いはこれらにより利用される、データ構造又は命令1524(例えば、ソフトウェア)の1つ以上のセットが記憶される通信デバイス可読媒体1522を含んでもよい。いくつかの態様では、プロセッサ1502のレジスタ、メインメモリ1504、スタティックメモリ1506及び/又は記憶デバイス1507は、ここで説明する技術又は機能のいずれか1つ以上を具現するか或いはこれらにより利用される、データ構造又は命令1524の1つ以上のセットが記憶されるデバイス可読媒体1522でもよく、或いは、これを(完全に或いは少なくとも部分的に)含んでもよい。一例では、ハードウェアプロセッサ1502、メインメモリ1504、スタティックメモリ1506又は大容量ストレージ1522のうち1つ又はいずれかの組み合わせが、デバイス可読媒体1522を構成してもよい。

【0357】

ここで使用される「デバイス可読媒体」という用語は、「コンピュータ可読媒体」又は「機械可読媒体」と交換可能である。通信デバイス可読媒体1522は単一の媒体として示されているが、「通信デバイス可読媒体」という用語は、1つ以上の命令1524を記憶するように構成された単一の媒体又は複数の媒体(例えば、集中型又は分散型データベース及び/又は関連するキャッシュ及びサーバ)を含んでもよい。「通信デバイス可読可能媒体」という用語は、通信デバイス1500による実行のための命令(例えば、命令1524)を記憶、符号化又は搬送でき、通信デバイス1500に対して本開示の技術のうちいずれか1つ以上を実行させるいずれかの媒体、又はこのような命令により使用されるか或いは関連するデータ構造を記憶、符号化又は搬送できるいずれかの媒体を含んでもよい。非限定的な通信デバイス可読媒体の例は、ソリッドステートメモリ、光及び磁気媒体を含んでもよい。通信デバイス可読媒体の具体的な例は、半導体メモリデバイス(例えば、電気的プログラム可能読み取り専用メモリ(EPROM, Electrically Programmable Read-Only Memory)、電気的消去可能プログラム可能読み取り専用メモリ(EEPROM, Electrically Erasable Programmable Read-Only Memory))及びフラッシュメモリデバイスのような不揮発性メモリと、内部ハードディスク及び取り外し可能ディスクのような磁気ディスクと、光磁気ディスクと、ランダムアクセスメモリ(RAM, Random Access Memory)と、CD-ROM及びDVD-ROMディスクとを含んでもよい。いくつかの例では、通信デバイス可読媒体は、非一時的な通信デバイス可読媒体を含んでもよい。いくつかの例では、通信デバイス可読媒体は、一時的な伝搬信号ではない通信デバイス可読媒体を含んでもよい。

【0358】

さらに、命令1524は、多数の転送プロトコルのいずれか1つを利用して、ネットワークインタフェースデバイス1520を介して伝送媒体を使用して通信ネットワーク1526上で送信又は受信されてもよい。一例では、ネットワークインタフェースデバイス1520は、通信ネットワーク1526に接続するために、1つ以上の物理ジャック(例えば、Ethernet、同軸又は電話ジャック)又は1つ以上のアンテナを含んでもよい。一例では、ネットワークインタフェースデバイス1520は、シングルインプット・マルチプルアウトプット(SIMO, single-input-multiple-output)、MIMO又はマルチプルインプット・シングルアウトプット(MISO, multiple-input-single-output)技術の少なくとも1つを使用してワイヤレスで通信するための複数のアンテナを含んでもよい。

【0359】

「伝送媒体」という用語は、通信デバイス1500による実行のための命令を記憶、符号化又は搬送できるいずれかの無形の媒体を含むものとして解釈されるものとし、このようなソフトウェアの通信を容易にするためのデジタル若しくはアナログ通信信号又は他の無形の媒体を含む。これに関して、本開示の文脈における伝送媒体はデバイス可読媒体である。

【0360】

「機械可読媒体」、「コンピュータ可読媒体」及び「デバイス可読媒体」という用語は、同じものを意味し、本開示では互換的に使用されてもよい。これらの用語は、機械記憶媒体及び伝送媒体の双方を含むように定義される。したがって、これらの用語は、記憶デバイス/媒体及び搬送波/変調データ信号の双方を含む。

【0361】

記載される主題の実装形態は、例として以下に示すように、1つ以上の特徴を単独で或いは組み合わせて含むことができる。

【0362】

例1は、第5世代新無線(5G NR)ネットワークにおける動作のために構成されたユーザ機器(UE)のための装置であり、当該装置は、5G NRネットワークにおけるサイドリンク動作のためにUEを構成するために、第2のUEから受信された、第2のUEによる後続のサイドリンク送信のための第1のリソース予約を含む第1のサイドリンク送信を復号し、第3のUEから受信された、第3のUEによる後続のサイドリンク送信のための第2のリソース予約を含む第2のサイドリンク送信を復号し、第1のリソース予約及び第2のリソース予約が同じサイドリンクスロット内にあることに基づいて、同一チャネル衝突を検出し、第2のUE及び第3のUEへの送信のために、同一チャネル衝突を示すフィードバックメッセージを符号化するように構成された処理回路と、処理回路に結合され、第1のサイドリンク送信及び第2のサイドリンク送信を記憶するように構成されたメモリとを含む。

【0363】

例2において、例1の主題は、処理回路が、物理サイドリンクフィードバックチャネル(PSFCH)を使用して第2のUE及び第3のUEへの送信のためにフィードバックメッセージを符号化するように構成される主題を含む。

【0364】

例3において、例2の主題は、処理回路が、PSFCHのリソースのプールを使用して第2のUE及び第3のUEへの送信のためにフィードバックメッセージを符号化するように構成され、リソースのプールが、UE間協調フィードバックに専用である主題を含む。

【0365】

例4において、例3の主題は、リソースのプールが、PSFCHシンボル上の物理リソースブロック(PRB)ビットマップを含み、PRBビットマップが、PSFCHについて事前構成される主題を含む。

【0366】

例5において、例2～4の主題は、処理回路が、PSFCHのリソースの共有プールを使用して第2のUE及び第3のUEへの送信のためにフィードバックメッセージを符号化するように構成される主題を含む。

【0367】

例6において、例5の主題は、処理回路が、PSFCHのリソースの共有プールを使用して送信のためにハイブリッド自動再送要求(HARQ)情報を符号化するように構成され、HARQ情報の送信及びフィードバックメッセージの送信が、異なるリソースIDで共有プールからのリソースに関連付けられる主題を含む。

【0368】

例7において、例1～6の主題は、フィードバックメッセージが、第2のUE及び第3のUEのソースIDと、第1のサイドリンク送信及び第2のサイドリンク送信に関連付けられたリソースIDと、フィードバックメッセージに関連付けられたフィードバックタイプと、第2のUE又は第3のUEのサイドリンク送信優先度とのうちの少なくとも1つを含む主題を含む。

【0369】

例8において、例1～7の主題は、処理回路が、物理サイドリンク制御チャネル(PSCCH)サイドリンク制御情報(SCI)を使用して、第2のUE及び第3のUEへの送信のためにフィードバックメッセージを符号化するように構成される主題を含む。

【0370】

例9において、例1～8の主題は、UEが、第2のUE及び第3のUEを含むUEグループのグループメンバである主題を含む。

【0371】

例10において、例1～9の主題は、処理回路に結合されたトランシーバ回路と、トランシーバ回路に結合された1つ以上のアンテナとを含む。

【0372】

例11は、ユーザ機器(UE)の1つ以上のプロセッサによる実行のための命令を記憶するコンピュータ可読記憶媒体であり、命令は、第5世代新無線(5G NR)ネットワークにおけるサイドリンク動作のためにUEを構成し、UEに対して、物理サイドリンク共有チャネル(PSSCH)を使用したサイドリンク送信のための、UEによる後続のサイドリンク送信のためのリソース予約を含むデータを符号化し、第2のUEから受信された、リソース予約及び第3のUEからの少なくとも別のリソース予約が同じサイドリンクスロットにあることに基づく同一チャネル衝突を示すフィードバックメッセージを復号し、受信されたフィードバックメッセージに基づいてサイドリンク再送のためにデータを符号化することを含む動作を実行させる。

【0373】

例12において、例11の主題は、フィードバックメッセージが、物理サイドリンクフィードバックチャネル(PSFCH)又は物理サイドリンク制御チャネル(PSCCH)サイドリンク制御情報(SCI)のうち1つを使用して受信される主題を含む。

【0374】

例13は、ユーザ機器(UE)の1つ以上のプロセッサによる実行のための命令を記憶するコンピュータ可読記憶媒体であり、命令は、第5世代新無線(5G NR)ネットワークにおけるサイドリンク動作のためにUEを構成し、UEに対して、第2のUEから受信された、第2のUEによる後続のサイドリンク送信のための第1のリソース予約を含む第1のサイドリンク送信を復号し、第3のUEから受信された、第3のUEによる後続のサイドリンク送信のための第2のリソース予約を含む第2のサイドリンク送信を復号し、第1のリソース予約及び第2のリソース予約が同じサイドリンクスロット内にあることに基づいて、同一チャネル衝突を検出し、第2のUE及び第3のUEへの送信のために、同一チャネル衝突を示すフィードバックメッセージを符号化することを含む動作を実行させる。

【0375】

例14において、例13の主題は、動作が、物理サイドリンクフィードバックチャネル(PSFCH)を使用して第2のUE及び第3のUEへの送信のためにフィードバックメッセージを符号化することを更に含むことを含む。

【0376】

例15において、例14の主題は、動作が、PSFCHのリソースのプールを使用して第2のUE及び第3のUEへの送信のためにフィードバックメッセージを符号化することを更に含み、リソースのプールが、UE間協調フィードバックに専用であることを含む。

【0377】

例16において、例15の主題は、リソースのプールが、PSFCHシンボル上の物理リソースブロック(PRB)ビットマップを含み、PRBビットマップが、PSFCHについて事前構成される主題を含む。

【0378】

例17において、例14～16の主題は、動作が、PSFCHのリソースの共有プールを使用して第2のUE及び第3のUEへの送信のためにフィードバックメッセージを符号化することを更に含むことを含む。

【0379】

例18において、例17の主題は、動作が、PSFCHのリソースの共有プールを使用して送信のためにハイブリッド自動再送要求(HARQ)情報を符号化することを更に含み、HARQ情報の送信及びフィードバックメッセージの送信が、異なるリソースIDで共有プールからのリソースに関連付けられることを含む。

【0380】

例19において、例13～18の主題は、フィードバックメッセージが、第2のUE及び第3のUEのソースIDと、第1のサイドリンク送信及び第2のサイドリンク送信に関連付けられたリソースIDと、フィードバックメッセージに関連付けられたフィードバックタイプと、第2のUE又は第3のUEのサイドリンク送信優先度とのうちの少なくとも1つを含む主題を含む。

【0381】

例20において、例13～19の主題は、動作が、物理サイドリンク制御チャネル(PSCCH)サイドリンク制御情報(SCI)を使用して、第2のUE及び第3のUEへの送信のためにフィードバックメッセージを符号化することを更に含むことを含む。

【0382】

例21は、命令を含む少なくとも1つの機械可読媒体であり、命令は、処理回路によって実行されると、処理回路に例1～20のいずれかを実施するための動作を実行させる。

【0383】

例22は、例1～20のいずれかを実施するための手段を含む装置である。

【0384】

例23は、例1～20のいずれかを実施するためのシステムである。

【0385】

例24は、例1～20のいずれかを実施するための方法である。

【0386】

特定の例示的な態様を参照して態様を説明したが、本開示のより広い範囲から逸脱することなく、これらの態様に対して様々な修正及び変更が行われてもよいことは明らかである。したがって、本明細書及び図面は、限定的な意味ではなく例示的な意味で考えられるべきである。したがって、この詳細な説明は、限定的な意味で解釈されるべきではなく、様々な態様の範囲は、添付の特許請求の範囲が権利を与えられる均等物の全範囲とともに、添付の特許請求の範囲によってのみ定義される。

【図1A】

【図1B】

【図1C】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】

【図13】

【図14】

【図15】

【手続補正書】

【提出日】2024-01-30

【手続補正1】

【補正対象書類名】特許請求の範囲

【補正対象項目名】全文

【補正方法】変更

【補正の内容】

【特許請求の範囲】

【請求項1】

第5世代新無線(5G NR)ネットワークにおける動作のために構成された第1のユーザ機器(UE)のための装置であって、
処理回路を含み、
前記5G NRネットワークにおけるサイドリンク通信のために前記第1のUEを構成するために、前記処理回路は、
第2のUEから受信された、UE間協調情報のための前記第2のUEからの要求を含む第2段階のサイドリンク制御情報(SCI)フォーマットを復号し、
リソースのセット内のスロットに関連する半二重競合を検出し、
物理サイドリンクフィードバックチャネル(PSFCH)を介した前記第2のUEへの送信のために、前記半二重競合に関する競合情報を、前記第2のUEにより要求された前記UE間協調情報として符号化する、装置。

【請求項2】

前記要求は、前記第2段階のSCIフォーマット内の1ビットのフィールドによって示される、請求項１に記載の装置。

【請求項3】

前記処理回路は、前記第2のUEから受信した第1段階のSCIフォーマットを復号し、
前記第1段階のSCIフォーマットは、前記第2のUEが前記UE間協調情報を受信できることを示す情報を含む、請求項１に記載の装置。

【請求項4】

前記処理回路は、前記第2のUEが前記UE間協調情報を受信できることを示す前記第1段階のSCIフォーマット内の前記情報に更に基づいて、前記PSFCHを介して前記競合情報を前記第2のUEに前記UE間協調情報として送信することを決定する、請求項３に記載の装置。

【請求項5】

前記処理回路は、
前記第2のUEから受信された、前記第2のUEによる後続のサイドリンク送信のための第1のリソース予約を含む第1のサイドリンク送信を復号し、
第3のUEから受信された、前記第3のUEによる後続のサイドリンク送信のための第2のリソース予約を含む第2のサイドリンク送信を復号し、
前記第1のリソース予約及び前記第2のリソース予約が同じサイドリンクスロット内にあることに基づいて、同一チャネル衝突を検出し、
前記第2のUE及び前記第3のUEへの送信のために、前記同一チャネル衝突を示すフィードバックメッセージを符号化する、請求項１に記載の装置。

【請求項6】

前記処理回路は、
物理サイドリンクフィードバックチャネル(PSFCH)を使用して前記第2のUE及び前記第3のUEへの送信のために前記フィードバックメッセージを符号化するように構成される、請求項５に記載の装置。

【請求項7】

前記処理回路は、
前記PSFCHのリソースのプールを使用して前記第2のUE及び前記第3のUEへの送信のために前記フィードバックメッセージを符号化するように構成され、前記リソースのプールは、UE間協調フィードバックに専用である、請求項６に記載の装置。

【請求項8】

前記リソースのプールは、PSFCHシンボル上の物理リソースブロック(PRB)ビットマップを含み、前記PRBビットマップは、前記PSFCHについて事前構成される、請求項７に記載の装置。

【請求項9】

前記処理回路は、前記PSFCHのリソースの共有プールを使用して前記第2のUE及び前記第3のUEへの送信のために前記フィードバックメッセージを符号化するように構成される、請求項６に記載の装置。

【請求項10】

前記処理回路は、前記PSFCHのリソースの前記共有プールを使用して送信のためにハイブリッド自動再送要求(HARQ)情報を符号化するように構成され、前記HARQ情報の送信及び前記フィードバックメッセージの送信は、異なるリソースIDで前記共有プールからのリソースに関連付けられる、請求項９に記載の装置。

【請求項11】

前記フィードバックメッセージは、
前記第2のUE及び前記第3のUEのソースIDと、
前記第1のサイドリンク送信及び前記第2のサイドリンク送信に関連付けられたリソースIDと、
前記フィードバックメッセージに関連付けられたフィードバックタイプと、
前記第2のUE又は前記第3のUEのサイドリンク送信優先度と
のうちの少なくとも1つを含む、請求項５に記載の装置。

【請求項12】

前記処理回路は、
物理サイドリンク制御チャネル(PSCCH)サイドリンク制御情報(SCI)を使用して、前記第2のUE及び前記第3のUEへの送信のために前記フィードバックメッセージを符号化するように構成される、請求項５に記載の装置。

【請求項13】

前記UEは、前記第2のUE及び前記第3のUEを含むUEグループのグループメンバである、請求項５に記載の装置。

【請求項14】

ユーザ機器(UE)の1つ以上のプロセッサによる実行のための命令を含むコンピュータプログラムであって、
前記命令は、第5世代新無線(5G NR)ネットワークにおけるサイドリンク動作のために前記UEを構成し、前記UEに対して、
第2のUEから受信された、UE間協調情報のための前記第2のUEからの要求を含む第2段階のサイドリンク制御情報(SCI)フォーマットを復号し、
リソースのセット内のスロットに関連する半二重競合を検出し、
物理サイドリンクフィードバックチャネル(PSFCH)を介した前記第2のUEへの送信のために、前記半二重競合に関する競合情報を、前記第2のUEにより要求された前記UE間協調情報として符号化する
ことを含む動作を実行させる、コンピュータプログラム。

【請求項15】

前記要求は、前記第2段階のSCIフォーマット内の1ビットのフィールドによって示される、請求項１４に記載のコンピュータプログラム。

【請求項16】

前記動作は、前記第2のUEから受信された第1段階のSCIフォーマットを復号することを更に含み、
前記第1段階のSCIフォーマットは、前記第2のUEが前記UE間協調情報を受信できることを示す情報を含む、請求項１４に記載のコンピュータプログラム。

【請求項17】

前記動作は、前記第2のUEが前記UE間協調情報を受信できることを示す前記第1段階のSCIフォーマット内の前記情報に更に基づいて、前記PSFCHを介して前記競合情報を前記第2のUEに前記UE間協調情報として送信することを決定することを更に含む、請求項１６に記載のコンピュータプログラム。

【請求項18】

ユーザ機器(UE)の1つ以上のプロセッサによる実行のための命令を含むコンピュータプログラムであって、
前記命令は、第5世代新無線(5G NR)ネットワークにおけるサイドリンク動作のために前記UEを構成し、前記UEに対して、
第2のUEから受信された、前記第2のUEによる後続のサイドリンク送信のための第1のリソース予約を含む第1のサイドリンク送信を復号し、
第3のUEから受信された、前記第3のUEによる後続のサイドリンク送信のための第2のリソース予約を含む第2のサイドリンク送信を復号し、
前記第1のリソース予約及び前記第2のリソース予約が同じサイドリンクスロット内にあることに基づいて、同一チャネル衝突を検出し、
前記第2のUE及び前記第3のUEへの送信のために、前記同一チャネル衝突を示すフィードバックメッセージを符号化する
ことを含む動作を実行させる、コンピュータプログラム。

【請求項19】

前記動作は、
物理サイドリンクフィードバックチャネル(PSFCH)を使用して前記第2のUE及び前記第3のUEへの送信のために前記フィードバックメッセージを符号化することを更に含む、請求項１８に記載のコンピュータプログラム。

【請求項20】

前記動作は、
前記PSFCHのリソースのプールを使用して前記第2のUE及び前記第3のUEへの送信のために前記フィードバックメッセージを符号化することを更に含み、
前記リソースのプールは、UE間協調フィードバックに専用である、請求項１９に記載のコンピュータプログラム。

【請求項21】

請求項１４乃至２０のうちいずれか１項に記載のコンピュータプログラムを記憶したコンピュータ可読記憶媒体。

【国際調査報告】