JP7664261B2 - 端末、サイドリンク通信制御方法、通信方法および集積回路 - Google Patents

Description

本開示は、端末およびサイドリンク通信制御方法に関する。

第５世代移動通信システム（5G）と呼ばれる通信システムが検討されている。国際標準化団体である3rd Generation Partnership Project（3GPP）では、LTE／LTE-Advancedシステムの高度化と、LTE/LTE-Advancedシステムとは必ずしも後方互換性を有しない新しい方式であるNew Radio Access Technology（New RAT又はNRとも呼ぶ）（例えば、非特許文献１を参照）の両面から、5G通信システムの高度化が検討されている。

また、3GPPでは、LTEシステムにおいてV2X（vehicle to X）をサポートすることが先行して検討されていた。より広帯域を使用できるNRにおいても、V2Xをサポートすることが検討された。また、V2Xに限らず、サイドリンク（SL:Sidelink）を使用する通信の更なる拡張も検討される。

3GPP TR 38.885 V16.0.0，Study on NR Vehicle-to-Everything (V2X)(Release 16)，2019-03 RP-201385, "WID revision: NR sidelink enhancement", LG Electronics, 3GPP TSG RAN Meeting #88e, Electronic Meeting, June 29 - July 3, 2020

しかしながら、サイドリンクにおける通信性能（例えば、信頼性、低遅延、及び、消費電力削減の少なくとも１つ）の更なる向上については検討の余地がある。

本開示の非限定的な実施例は、サイドリンクの通信性能を向上できる端末、サイドリンク通信制御方法の提供に資する。

本開示の一実施例に係る端末は、サイドリンクリソースの端末間協調使用に関する情報を生成する制御回路と、前記情報を他の端末へ送信する送信回路と、を備える。

なお、これらの包括的または具体的な態様は、システム、装置、方法、集積回路、コンピュータプログラム、または、記録媒体で実現されてもよく、システム、装置、方法、集積回路、コンピュータプログラムおよび記録媒体の任意な組み合わせで実現されてもよい。

本開示の一実施例によれば、サイドリンクの通信性能を向上できる。

本開示の一実施例における更なる利点および効果は、明細書および図面から明らかにされる。かかる利点および／または効果は、いくつかの実施形態並びに明細書および図面に記載された特徴によってそれぞれ提供されるが、１つまたはそれ以上の同一の特徴を得るために必ずしも全てが提供される必要はない。

サイドリンクのスロット内のチャネル配置例を示す図 端末の一部の構成例を示すブロック図 基地局の構成例を示すブロック図 端末の構成例を示すブロック図 端末の（送信）動作例を示すフローチャート 端末の（受信）動作例を示すフローチャート 端末の他の構成例を示すブロック図 リソース利用調整情報１の送信例を示す図 リソース利用調整情報１の他の送信例を示す図 リソース利用調整情報３の送信例を示す図 リソース利用調整情報４の送信例を示す図 PSSCH（physical SL shared channel）動作例１を示す図 PSSCH動作例１の変形例を示す図 リソース利用調整情報のための新規チャネルの設定例を示す図 1st stage SCI（Sidelink Control Information）動作例１を示す図 1st stage SCI動作例２を示す図 3GPP NRシステムの例示的なアーキテクチャの図 NG-RANと5GCとの間の機能分離を示す概略図 Radio Resource Control(RRC)接続のセットアップ／再設定の手順のシーケンス図 大容量・高速通信（eMBB：enhanced Mobile BroadBand）、多数同時接続マシンタイプ通信（mMTC：massive Machine Type Communications）、および高信頼・超低遅延通信（URLLC：Ultra Reliable and Low Latency Communications）の利用シナリオを示す概略図 非ローミングシナリオのための例示的な5Gシステムアーキテクチャを示すブロック図

以下、本開示の実施の形態について図面を参照して詳細に説明する。

［V2Xの説明］
V2Xは、車車間（V2V:Vehicle to Vehicle）、路車間（V2I:Vehicle to Infrastructure）、歩車間（V2P: Vehicle to Pedestrian）、車ネットワーク間（V2N：Vehicle to Network）の通信を想定しており、V2V、V2I、V2Pでは、基地局とのネットワークを介さずに、サイドリンク(SL:Sidelink)またはPC5とよばれるリンクを使用して端末間が直接に通信（例えば、送信及び受信の少なくとも１つ）を行うことができる。V2Nでは、基地局(例えば、NRではgNB、LTEではeNB)と端末との間のUuとよばれるリンクを介して通信することが想定される。

サイドリンクに使用するリソースは、例えば、SL BWP（Band width part）およびリソースプールにより設定される。SL BWPは、サイドリンクに使用できる周波数バンドを指定し、基地局－端末間（Uu）に設定されるDL BWP やUL BWPとは別途設定されてよい。周波数バンドがUL BWPとオーバラップする可能性もある。

リソースプールは、例えば、SL BWP内のリソースにおいて指定される周波数方向及び時間方向のリソースを含む。１つの端末に、複数のリソースプールが設定されてもよい。リソースプール内の周波数リソースは、例えば、サブチャネルという単位に分割されてよく、サブチャネル単位でリソースの割り当てが設定されてよい。サブチャネルには、複数のPRB（Physical resource block）が含まれてよい。

［NRにおけるサイドリンクの説明］
NRのV2Xでは、サイドリンクでの通信（例えば、送信及び受信の少なくとも１つ）において、ユニキャスト、グループキャスト、ブロードキャストをサポートすることが検討されている。

ユニキャストでは、例えば、送信端末（例えば、transmitter UE又はTx UEとも呼ぶ）から受信端末（例えば、receiver UE又はRx UE）への１対１の送信を想定する。グループキャストでは、例えば、送信端末から、或るグループに含まれる複数の受信端末への送信を想定する。ブロードキャストは、例えば、送信端末から、受信端末を特定しない送信を想定する。なお、UEは、User Equipmentの略記であり、「端末」の一例である。

［SLのチャネルの説明］
NRのSLでは、例えば、PSCCH（physical SL control channel）、PSSCH（physical SL shared channel）、及び、PSFCH（physical SL feedback channel）、PSBCH（physical SL broadcast channel）といったチャネルの設定が検討される。

PSCCHは、SLにおける制御チャネルの一例であり、PSSCHは、SLにおけるデータチャネルの一例である。PSFCHは、SLにおいてフィードバック信号の伝送に用いられるチャネルの一例であり、PSBCHは、受信端末を特定しない送信に用いられる報知（ブロードキャスト）チャネルの一例である。なお、以降の説明において、「信号」と「情報」とは文脈に応じて相互に読み替えられてよい。

PSCCHには、例えば、sidelink control information（SCI）と呼ばれる制御信号（又は制御情報）が配置される。SCIには、例えば、データ信号（例えば、PSSCH）のリソース割当情報といったPSSCHの送信及び受信の少なくとも１つに関する情報（あるいは、パラメータ）が含まれる。

SCIの情報内容は、後述するように、例えば、第１の情報（又は制御情報）と、第２の情報（又は制御情報）と、に分割（あるいは、区分又は分類）されてよい。別言すると、SCIは、例えば、SLに関する「第１の制御情報」および「第２の制御情報」を含んでよい。「第２の制御情報」は、「第１の制御情報」に関連した情報の一例と捉えてもよい。「第１の制御情報」および「第２の制御情報」は、それぞれ、例えば、「1st stage SCI」および「2nd stage SCI」と称されてよい。

1st stage SCIが、SLの制御チャネルの一例であるPSCCHに配置され、2nd stage SCIが、SLのデータチャネルの一例であるPSSCHに配置されてよい。別言すると、SCIは、PSCCHとPSSCHとに分散して配置されてよい。なお、「配置」という用語は、例えば、「マッピング」、「割当」、「（マッピング）パターン」といった、当業者において他の適切な用語に相互に読み替えられてもよい（以降において同じ）。

PSSCHには、例えば、データ信号、あるいはデータ信号とSCI（例えば、2nd stage SCI）とが配置される。

PSFCHには、例えば、PSSCH（例えば、データ信号）に対するフィードバック信号（例えば、hybrid automatic repeat request（HARQ）feedback）が配置される。フィードバック信号には、例えば、ACK又はNACKを示す応答信号（例えば、ACK/NACK情報、HARQ-ACKとも呼ばれる）が含まれてよい。

フィードバック信号は、例えば、PSSCHがユニキャスト及びグループキャストによって送受信される場合に適用されることが想定される。ACK及びNACKは、例えば、それぞれHARQ-ACK及びHARQ-NACKと呼ばれてもよい。

PSBCHには、例えば、受信端末を特定しないブロードキャスト信号が配置される。PSBCHは、例えば、同期用の信号であるsidelink Primary synchronization signal (S-PSS) and sidelink secondly synchronization signal（S-SSS）と共に送信され、S-SSB（sidelink synchronization signal block）とも総称される。

［SCIの説明］
1st stage SCIおよび2nd stage SCIのそれぞれに含まれる情報の非限定的な一例は、以下のとおりである。

＜1st stage SCI＞
- Priority - 3 bits
- Frequency resource assignment
- Time resource assignment- 5 bits or 9 bits
- Resource reservation period - [log2(N_(reservePeriod)] bits or 0 bits
- DMRS pattern [x] bits or 0 bits
- 2nd stage SCI format 2 bits
- Beta_offset indicator 2 bits
- Number of DMRS port 1 bit
- Modulation and coding scheme - 5 bits
- Additional MCS table indicator - 2 bits or 0 bits
- PSFCH overhead indication - 1bit
- Reserved - [sl-NumReservedBits] bits or 0 bits

＜2nd stage SCI＞
2nd stage SCIには、例えば、以下のとおり、SCI format 2-AとSCI format 2-Bとの２種類のフォーマットが用意されてよい。

＜SCI format 2-A＞
- HARQ process number - [log_2(N_process)] bits
- New data indicator - 1 bit
- Redundancy version - 2 bits
- Source ID - 8 bits
- Destination ID - 16 bits
- HARQ feedback enabled/disabled indicator - 1 bit
- Cast type indicator - 2 bits
- CSI request - 1 bit

＜SCI format 2-B＞
- HARQ process number - [log_2(N_process)] bits
- New data indicator - 1 bit
- Redundancy version - 2 bits
- Source ID - 8 bits
- Destination ID - 16 bits
- HARQ feedback enabled/disabled indicator - 1 bit
- Zone ID - 12 bits
- Communication range requirement - 4 bits

V2XのSL通信において、端末は、例えば、センシングによって他の端末によるリソースの利用状況（あるいは予約状況）を確認してから、送信に使用するリソースを決定する。SCIの情報内容を２つに分割することで、1st stage SCIのビット数及びサイズを削減できるため、センシングに使用する領域を小さくできるという利点がある。1st stage SCIは、例えば、PSCCHに配置され、2nd stage SCIは、例えば、PSSCH（PSSCHの一部でよい）に配置されてよい。なお、「DMRS」は、復調用参照信号（demodulation reference signal）の略記であり、「CSI」は、チャネル状態情報（channel state information）の略記である。

図１に、PSCCH, PSSCH, PSFCHのスロット内の配置例を示す。PSFCHは設定により配置されない場合もある。また、PSSCHのシンボル数は、設定により可変である。また、2nd stage SCIは、例えば、図示しないPSSCHにおけるDMRSの配置に応じて配置が変更されてよい。1st stage SCIは、例えば、PSSCHを割り当てる周波数リソースよりも低い周波数リソースから配置されてよい。１スロットは、例えば、１４シンボル（拡張CP（Cyclic Prefix）が用いられる場合は１２シンボル）から構成される。

［SLのモードの説明］
SLの通信には、例えば、２つのモード（例えば、Mode 1及びMode 2）がある。

Mode 1では、例えば、基地局が、SLにおいて端末が使用するリソース（例えば、SLリソースと呼ぶ）を決定（別言すると、スケジュール）する。

Mode 2では、例えば、端末が、予め設定されたリソースプール内のリソースから、SLに使用するリソースを選択（又は、決定）する。別言すると、Mode 2では、基地局は、SLのリソースをスケジュールしなくてよい。

Mode 1は、例えば、基地局と端末との間が接続されている状態であり、基地局からの指示（又は通知）をサイドリンク通信する端末が受信できる環境下での使用が想定される。一方、Mode 2では、例えば、端末は、基地局からの指示がない場合でもSLに使用するリソースを決定できる。そのため、例えば、異なるオペレータの配下の端末、又は、カバレッジ外の端末を含めてサイドリンク通信が可能である。

以上、サイドリンクに関して説明した。

＜通信システムの概要＞
本実施の形態に係る通信システムは、例えば、図２に例示した端末２００と、図３に例示した基地局１００とを備える。端末２００の数は、１以上でよいが、サイドリンク通信に着目した場合には、２以上である。

図２は、実施の形態に係る端末２００の一部の構成例を示すブロック図である。図２に示す端末２００は、例えば、制御部（又は制御回路）２０Ａと、通信部（又は通信回路）２０Ｂと、を備えてよい。

制御部２０Ａは、サイドリンクの送信端末２００の観点において、例えば、サイドリンク通信におけるリソースの使用（又は利用）を端末２００間で調整（あるいは協調制御）する情報を決定、生成する。この情報は、サイドリンクリソースの端末間協調使用に関する情報の一例であり、端末２００間において送信又は受信される制御情報の一種と理解されてよい。また、この情報は、例えば便宜的に、「リソース利用調整情報」、「リソース協調制御情報」、あるいは「端末間協調情報（inter-UE coordinate information）」と称されてもよい。

通信部２０Ｂは、サイドリンクの送信端末の観点において、リソース利用調整情報を他の端末２００宛に送信する。したがって、通信部２０Ｂは、サイドリンクの送信端末２００の観点において、リソース利用調整情報を送信する送信回路の一例と理解されてよい。また、通信部２０Ｂは、サイドリンクの受信端末２００の観点では、他の端末２００が送信したリソース利用調整情報を受信する。したがって、通信部２０Ｂは、受信端末２００の観点において、リソース利用調整情報を受信する受信回路の一例に相当すると理解されてよい。また、サイドリンクの受信端末の観点において、制御部２０Ａは、通信部２０Ｂにおいて受信したリソース利用調整情報に基づいて、サイドリンクの通信（例えば、送信）に使用するリソースを決定する。

［基地局１００の構成］
図３は、実施の形態に係る基地局１００の構成例を示すブロック図である。図３に例示したように、基地局１００は、例えば、リソース利用調整情報設定部１０１と、誤り訂正符号化部１０３と、変調部１０４と、送信部１０６と、受信部１０７と、復調部１０９と、誤り訂正復号部１１０と、を備える。

リソース利用調整情報設定部１０１は、図示を省略したユースケースや、端末２００から報告された情報、例えば、端末２００の特性あるいは能力（Capability）といった情報を基に、端末２００にサイドリンクのリソース利用調整情報を送信させるか否かを決定する。リソース利用調整情報設定部１０１は、端末２００にサイドリンクのリソース利用調整情報を送信させることを決定した場合、リソース利用調整情報の送信設定に関する情報を、例えば上位レイヤ（例えば、ＲＲＣ）のシグナリングとして誤り訂正符号化部１０３へ出力する。

なお、本例では、上位レイヤ（例えば、ＲＲＣ）にて送信する情報をリソース利用調整情報設定部１０１において生成し、端末２００に対してリソース利用調整情報の送信を設定する。ただし、この設定は、例えば、Pre-configuredと呼ばれる、アプリケーションレイヤでの設定であってもよいし、SIM（Subscriber Identity Module）に予め設定されてもよく、端末２００は、基地局１００からの設定がなくても動作可能である。

誤り訂正符号化部１０３は、例えば、送信データ信号（DLデータ信号）、および、上位レイヤのシグナリングを入力とし、入力された信号を誤り訂正符号化し、符号化した信号を変調部１０４へ出力する。

変調部１０４は、例えば、誤り訂正符号化部１０３から入力された信号に対して変調処理を施し、変調後のデータ信号を送信部１０６へ出力する。

送信部１０６は、例えば、信号割当部１０５から入力される信号に対してアップコンバート、増幅といった無線送信処理を施し、無線信号をアンテナから端末２００へ送信する。

受信部１０７は、例えば、端末２００から送信された信号をアンテナにおいて受信し、低雑音増幅、ダウンコンバートといった無線受信処理を施し、受信信号を復調部１０９へ出力する。

復調部１０９は、例えば、入力信号に対して復調処理を施し、得られた信号を誤り訂正復号部１１０へ出力する。

誤り訂正復号部１１０は、例えば、復調部１０９から入力される信号を復号して、端末２００からの受信データ信号（ULデータ信号）を得る。

なお、Mode 1の場合、端末２００がサイドリンクにて送信するSCIの情報は、基地局１００（例えば、リソース利用調整情報設定部１０１あるいは図示しない他のブロック）において生成されてもよい。基地局１００が生成したSCI情報は、例えば、上位レイヤの信号として、または物理レイヤ（例えば、PDCCH; Physical Downlink Control Channel）の信号として端末２００に送信されてよい。

［端末２００の構成］
図４は、実施の形態に係る端末２００の構成例を示すブロック図である。サイドリンク通信において、端末２００は、送信端末及び受信端末の何れにもなり得る。図４において、端末２００は、例えば、受信部２０１と、信号分離部２０２と、復調部２０３と、誤り訂正復号部２０４と、リソース利用調整情報受信部２０５と、リソース利用調整情報生成部２０６と、誤り訂正符号化部２０７と、変調部２０８と、信号割当部２０９と、送信部２１０と、を備える。

受信部２０１は、例えば、受信信号をアンテナによって受信し、受信信号に対して低雑音増幅、ダウンコンバートといった無線受信処理を施した後に信号分離部２０２へ出力する。

信号分離部２０２は、例えば、受信部２０１の出力信号から、受信データ信号と、センシングの結果を示す情報（以下「センシング情報」と略称することがある）と、を分離する。受信データ信号は、例えば、復調部２０３へ出力される。センシング情報は、例えば、リソース利用調整情報受信部２０５へ出力される。なお、「センシング」とは、他の端末２００が送信する1st stage SCIをある時間区間において受信すること、と理解されてもよい。

復調部２０３は、例えば、信号分離部２０２から入力された受信データ信号に対して復調処理を施し、復調した信号を誤り訂正復号部２０４へ出力する。

誤り訂正復号部２０４は、例えば、復調部２０３から入力される復調信号を復号し、復号信号に対して、例えば、cyclic redundancy check（CRC）といった誤り判定を行う。誤り判定の結果、誤り無しと判定された信号が受信データ信号として出力される。また、誤り訂正復号部２０４は、受信データ信号のうち、例えば、上位レイヤで受信したリソース利用調整に関する設定情報をリソース利用調整情報受信部２０５へ出力する。

リソース利用調整情報受信部２０５は、例えば、上位レイヤの信号として誤り訂正復号部２０４から入力される、リソース利用調整に関する設定情報を受信する。また、リソース利用調整情報受信部２０５は、例えば、信号分離部２０２から入力される、センシングによって得られた他の端末２００が使用するリソースの情報または他の端末２００が送信したリソース利用調整情報を受信する。リソース利用調整情報受信部２０５が受信した情報は、例えば、リソース利用調整情報生成部２０６へ出力される。また、端末２００は、例えば、リソース利用調整に関する設定情報を基に自局が使用するリソースを決定した場合、信号割当部２０９へ使用するリソースを通知する。

リソース利用調整情報生成部２０６は、例えば、Pre-configuredされた設定情報、あるいはリソース利用調整情報受信部２０５から入力されたリソース利用調整情報を基に、他の端末２００へ送信するリソース利用調整情報を生成するか否かを決定する。他の端末２００向けのリソース利用調整情報を生成する場合、リソース利用調整情報生成部２０６は、例えば、どのチャネルでリソース利用調整情報を送信するかを決定し、生成したリソース利用調整情報を信号割当部２０９へ出力する。

誤り訂正符号化部２０７は、例えば、サイドリンクの送信データ信号（SLデータ信号）を入力とし、当該送信データ信号を誤り訂正符号化し、符号化した信号を変調部２０８へ出力する。

変調部２０８は、例えば、誤り訂正符号化部２０７から入力される信号を変調し、変調信号を信号割当部２０９へ出力する。

信号割当部２０９は、例えば、リソース利用調整情報受信部２０５から入力される割当情報に基づき、1st stage SCIを送信するPSCCH、SLデータ信号を送信するPSSCH、および、PSSCHに配置される2nd stage SCIをリソースに割り当てる。リソース利用調整情報生成部２０６から入力がある場合、信号割当部２０９は、例えば、リソース利用調整情報をSLリソースの該当チャネルへ割り当てる。リソースに割り当てられた信号は、送信部２１０へ出力される。

なお、信号割当部２０９において、例えば、ACK/NACK情報が、SLのフィードバックチャネル（例えば、PSFCH）に割り当てられてもよい。

送信部２１０は、信号割当部２０９からの入力信号に対して、増幅、アップコンバートといった無線送信処理を施し、無線信号をアンテナから送信する。

送信処理に着目した場合、信号割当部２０９が、例えば図１に示した制御部２０Ａに相当してよい。制御部２０Ａには、例えば、1st stage SCI生成部２１２－１、2nd stage SCI生成部２１２－２、リソース利用調整情報生成部２０６、及び、信号割当部２０９の少なくとも１つが含まれてもよい。また、送信部２１０が、図１に示した通信部２０Ｂに相当してよい。

一方、受信処理に着目した場合、信号分離部２０２が、例えば図１に示した制御部２０Ａに相当してよい。制御部２０Ａには、例えば、1st stage SCI受信部２１１－１、2nd stage SCI受信部２１１－２、リソース利用調整情報受信部２０５、及び、信号分離部２０２の少なくとも１つが含まれてもよい。また、受信部２０１が、図１に示した通信部２０Ｂに相当してよい。

（端末２００の動作例）
次に、端末２００の動作の一例について説明する。

図５は、端末２００の送信処理に着目した動作の一例を示すフローチャートであり、図６は、端末２００の受信処理に着目した動作の一例を示すフローチャートである。図５及び図６に示した動作例は、１つの端末２００における動作例と捉えてもよいし、異なる端末２００における動作例と捉えてもよい。例えば、図５に示した動作例が送信端末２００の動作例に相当し、図６に示した動作例が受信端末２００の動作例に相当してよい。

図５に例示したように、端末２００は、リソース利用調整情報を生成する（Ｓ１０１）。そして、端末２００は、生成したリソース利用調整情報を他の端末２００へ送信する（Ｓ１０２）。

また、図６に例示したように、端末２００は、他の端末２００が送信したリソース利用調整情報を受信する（Ｓ２０１）。そして、端末２００は、他の端末から受信したリソース利用調整情報に基づいて、サイドリンクの送信に使用するリソースを決定し（Ｓ２０２）、決定したリソースにおいて送信を行う（Ｓ２０３）。

このような動作によって、例えば、受信端末２００は、送信端末を含む他の端末２００によって予約済みのリソース（例えば、他の端末２００が送信に利用する可能性のあるリソース）を避けて、サイドリンクの送信に使用するリソースを選択、決定できる。

したがって、サイドリンクのリソースにおいて端末２００間で利用する送信リソースに衝突（あるいは競合）が発生する確率を低減できる。よって、例えば、サイドリンク通信の信頼性、低遅延、及び、消費電力削減といった、サイドリンクの通信性能の向上に寄与する。

［端末２００の他の構成例］
図７は、実施の形態に係る端末２００の他の構成例を示すブロック図である。図７に例示した構成例は、図４に例示した構成において、Uuリンク用とSL用とで、復調部、誤り訂正復号部、誤り訂正符号化部、変調部のそれぞれを個別のブロックとし、また、リソース利用調整情報とSCIとの関連性を非限定的な一例として明確化した構成に相当する、と理解されてよい。なお、「Uuリンク」は、基地局１００と端末２００との間のリンクを意味する。また、図７において、図４で使用した符号と同一符号を付したブロックは、図４にて既述のブロックに対応する、と理解されてよい。

図７において、端末２００は、例えば、受信部２０１と、信号分離部２０２と、1st stage SCI受信部２１１－１と、2nd stage SCI受信部２１１－２と、Uu復調部２０３－１と、SL復調部２０３－２と、Uu誤り訂正復号部２０４－１と、SL誤り訂正復号部２０４－２と、を備える。また、端末２００は、例えば、リソース利用調整情報受信部２０５と、リソース利用調整情報生成部２０６と、1st stage SCI生成部２１２－１と、2nd stage SCI生成部２１２－２と、を備える。更に、端末２００は、例えば、Uu誤り訂正符号化部２０７－１と、SL誤り訂正符号化部２０７－２と、Uu変調部２０８－１と、SL変調部２０８－２と、信号割当部２０９と、送信部２１０と、を備える。

受信部２０１は、例えば、受信信号をアンテナによって受信し、受信信号に対して低雑音増幅、ダウンコンバートといった無線受信処理を施した後に信号分離部２０２へ出力する。

信号分離部２０２は、例えば、受信部２０１において受信された信号のうち、リソース利用調整に関する設定情報に基づき、Uuリンク信号とSL信号とを分離する。Uuリンク信号は、Uu復調部２０３－１へ出力される。また、信号分離部２０２は、例えば、SL信号のうち、PSCCH信号を分離して1st stage SCI受信部２１１－１へ出力し、1st stage SCI受信部２１１－１から入力されるリソース割当情報を基に、SL信号のうち、PSSCH内の2nd stage SCIを分離して2nd stage SCI受信部２１１－２へ出力する。また、信号分離部２０２は、例えば、SL信号のうち、PSSCH内の端末２００宛のデータ部分を分離してSL復調部２０３－２へ出力する。

1st stage SCI受信部２１１－１は、例えば、信号分離部２０２から入力されたPSCCH信号の復調及び復号を試行する。復号に成功した場合（別言すると、SCIを検出した場合）、SCIに含まれる、PSSCHの周波数及び時間リソースの割当情報と2nd stage SCIフォーマットの情報とを信号分離部２０２へ出力する。また、1st stage SCI受信部２１１－１は、例えば、端末２００がサイドリンクにて送信予定のリソースの情報を、リソース利用調整情報生成部２０６へ出力する。

2nd stage SCI受信部２１１－２は、例えば、2nd stage SCIに含まれる送信元（source）IDおよび送信先（destination）IDを基に、受信部２０１で受信した信号が当該端末２００宛の信号であるか否かを確認（又は判定）する。受信部２０１で受信した信号が当該端末２００宛の信号である場合、2nd stage SCI受信部２１１－２は、例えば、PSSCHの復調及び復号に用いる情報をSL復調部２０３－２へ出力する。

Uu復調部２０３－１は、例えば、信号分離部２０２から入力された信号に対して、復調処理を施し、復調された信号をUu誤り訂正復号部２０４－１へ出力する。

Uu誤り訂正復号部２０４－１は、Uu復調部２０３－１から入力された復調信号を復号し、復号した信号を出力する。復号した信号のうち、例えば、上位レイヤのシグナリングは、リソース利用調整情報受信部２０５へ出力される。

SL復調部２０３－２は、例えば、2nd stage SCI受信部２１１－２からの2nd stage SCIの情報を基に、信号分離部２０２から入力された信号に対して復調処理を施し、復調した信号をSL誤り訂正復号部２０４－２へ出力する。

SL誤り訂正復号部２０４－２は、例えば、SL復調部２０３－２から入力された復調信号を復号し、復号した信号に対して、例えば、CRCといった誤り判定を行う。誤り判定の結果、誤り無しと判定された信号が受信データ信号として出力される。

リソース利用調整情報受信部２０５は、例えば、上位レイヤの信号、または、PSSCHの信号としてUu誤り訂正復号部２０４－１から入力されるリソース利用調整に関する設定情報を受信する。また、リソース利用調整情報受信部２０５は、例えば、1st stage SCI受信部２１１－１から入力される、センシングによって得られた他の端末２００が使用するリソースの情報または他の端末２００が送信したリソース利用調整情報を受信する。リソース利用調整情報受信部２０５が受信した情報は、例えば、リソース利用調整情報生成部２０６へ出力される。また、リソース利用調整に関する設定情報を基に自局が使用するリソースを決定した場合、リソース利用調整情報受信部２０５は、例えば、信号割当部２０９へ使用するリソースを通知する。

リソース利用調整情報生成部２０６は、例えば、Pre-configuredされた設定情報、あるいはリソース利用調整情報受信部２０５から入力されたリソース利用調整情報を基に、他の端末２００へ送信するリソース利用調整情報を生成するか否かを決定する。他の端末２００向けのリソース利用調整情報を生成する場合、リソース利用調整情報生成部２０６は、例えば、どのチャネルでリソース利用調整情報を送信するかを決定し、生成したリソース利用調整情報を信号割当部２０９へ出力する。

例えば、PSSCHを用いてリソース利用調整情報を送信する場合、リソース利用調整情報生成部２０６は、PSSCHを用いてリソース利用調整情報を送信することを通知する2nd stage SCIの生成を2nd stage SCI生成部２１２－２へ指示する。また、リソース利用調整情報生成部２０６は、例えば、2nd stage SCIのフォーマットに変更があることを通知する信号の送信を1st stage SCI生成部２１２－１に指示する。また、リソース利用調整情報生成部２０６は、例えば、PSSCHを用いて送信するリソース利用調整情報を信号割当部２０９へ出力する。

1st stage SCI生成部２１２－１は、例えば、PSSCHを送信する周波数リソースを決定し、決定した情報を含むSCIを生成し、生成したSCIを、信号割当部２０９に制御信号として入力すると共に、信号割当部２０９にPSCCHを用いて送信する信号として出力する。また、1st stage SCI生成部２１２－１は、例えば、リソース利用調整情報生成部２０６からの指示に応じて、2nd stage SCIのフォーマットの変更を指示する情報を生成し、生成した情報を1st stage SCIに配置する。

2nd stage SCI生成部２１２－２は、例えば、SCI（2nd stage SCI）を生成し、生成したSCIを信号割当部２０９へ出力する。SCIには、例えば、送信元の端末２００を識別する情報（例えば、送信元ID）、送信先の端末２００を識別する情報（例えば、送信先ID）、及び、復調及び復号に関する情報が含まれてよい。また、リソース利用調整情報生成部２０６から指示があり、PSSCHを用いてリソース利用調整情報を他の端末２００へ通知する場合、2nd stage SCI生成部２１２－２は、例えば、リソース利用調整情報を送信することを通知する情報を2nd stage SCIに含めてよい。

Uu誤り訂正符号化部２０７－１は、例えば、Uuリンクの送信データ信号（ULデータ信号）を入力とし、当該送信データ信号を誤り訂正符号化し、符号化した信号をUu変調部２０８－１へ出力する。

Uu変調部２０８－１は、例えば、Uu誤り訂正符号化部２０７－１から入力される信号を変調し、変調信号を信号割当部２０９へ出力する。

SL誤り訂正符号化部２０７－２は、例えば、SLの送信データ信号（SLデータ信号）を入力とし、当該送信データ信号を誤り訂正符号化し、符号化した信号をSL変調部２０８－２へ出力する。

SL変調部２０８－２は、例えば、SL誤り訂正符号化部２０７－２から入力される信号を変調し、変調信号を信号割当部２０９へ出力する。

信号割当部２０９は、例えば、1st stage SCI生成部２１２－１から入力されるSL信号の割当情報に基づき、1st stage SCIを送信するPSCCHと、SLデータ信号を送信するPSSCHと、PSSCHに配置される2nd stage SCIとを、リソースに割り当てる。リソース利用調整情報受信部２０５から入力がある場合、信号割当部２０９は、例えば、リソース利用調整情報受信部２０５からの指示に応じて、SLデータ信号をPSSCHに割り当てる。また、リソース利用調整情報生成部２０６から入力がある場合、信号割当部２０９は、例えば、リソース利用調整情報をPSSCHに割り当てる。また、信号割当部２０９は、例えば、基地局１００と端末２００との間においてPUSCHに使用されるリソースに、ULデータ信号を割り当てる。以上のようにリソースに割り当てられた信号は、送信部２１０へ出力される。

信号割当部２０９において、例えば、ACK/NACK情報が、SLのフィードバックチャネル（例えば、PSFCH）に割り当てられてもよい。

送信部２１０は、例えば、信号割当部２０９からの入力信号に対して、増幅、アップコンバートといった無線送信処理を施し、無線信号をアンテナから送信する。

なお、図７に例示した構成では、UuリンクとSLとで、復調部、誤り訂正復号部、誤り訂正符号化部、及び、変調部のそれぞれを個別のブロックとしたが、一部又は全部が共通のブロックであってもよい。

また、リソース利用調整情報は、上位レイヤのシグナリングとして端末２００において受信される場合に限られない。例えば、リソース利用調整情報は、SIMに予め設定されてもよいし、Pre-configuredと呼ばれる、アプリケーションレイヤによって予め端末２００に設定されてもよい。端末２００は、リソース利用調整に関する設定情報を受信せずに、予め設定された情報をリソース利用調整に使用することもできる。

［実施例］
本実施例において、端末２００は、例えば、リソース利用調整情報を他の端末２００へ送信する。リソース利用調整情報を受信した他の端末２００は、例えば、どのリソースが他の端末２００によって使用される可能性があるか、または、どのリソースを使用して送信を行うかを判断、決定する。リソース利用調整情報を使用することで、他の端末２００が送信に使用するリソースとの衝突発生率を低減できる。

リソース利用調整情報が複数ある場合、端末２００は、どのリソース利用調整情報を送信するか、および、どのチャネルでリソース利用調整情報を送信するかを決定（あるいは設定）してよい。このようにすると、端末２００の特性又は能力に応じて、リソース利用調整情報を選択して端末２００に設定できる。

リソース利用調整情報は、以下に説明する複数種類の情報のうち１つまたは複数を設定できる。リソースは、例えば、周波数及び時間リソースの単位によって特定されてよい。非限定的な一例として、周波数領域を複数のサブチャネルに分割し、時間領域を複数のスロットに分割し、スロット番号とサブチャネル番号とによってリソースが特定されてよい。

以下、リソース利用調整情報を送信する端末２００をUE-Aと表記し、リソース利用調整情報を受信する端末２００をUE-Bと表記して、端末２００間協調動作の一例について説明する。なお、リソース利用調整情報が、例えば、ユニキャストのように特定の端末２００に限って受信できるように送信される設定の場合は、その特定のUEに限ってリソース利用調整情報を受信できる。

一方、リソース利用調整情報が、ブロードキャストまたはグループキャストのように複数のUEに受信できるように送信される設定の場合は、複数のUEがリソース利用調整情報を受信できる。したがって、UE-Bに相当する端末２００は１台とは限らない。

リソース利用調整情報を送信したUE-Aは、他のUEに対してリソースの利用が可能であることを通知したリソースにおいて送信を行わないこととする。したがって、他のUEが送信を行った場合に、UE-Aと他のUEとの間において使用するリソースの衝突が発生することを回避あるいは抑制できる。

［リソース利用調整情報１]
UE-Aは、他のUEが送信する1st stage SCIをある時間区間において受信する。これは、センシングとも呼ばれる。UE-Aは、1st stage SCIを受信することで、他のUEが送信を予定しているリソースの情報を得ることができる。

UE-Aは、他のUEが送信を予定しているリソースの情報をまとめて送信してよい。その際、UE-Aは、UE-Aが送信を予定しているリソースの情報を併せて送信してもよい。また、UE-Aは、1st stage SCIとは異なる情報から得られる、RRCやMAC（Media Access Control）といったレイヤの通知や、アプリケーションレイヤからの通知や設定等により、使用できないリソースを把握している場合、それらのリソースの情報も加えて、使用できるリソース、使用できないリソースの情報をリソース利用調整情報として送信してもよい。

このようにすると、UE-Aからリソース利用調整情報を受信したUE-Bは、1st stage SCIが未受信であるために得られなかったリソース利用に関する情報を得ることができる。例えば、同一周波数帯において、送信しながら受信を行えないUEは、送信中に他のUEから1st stage SCIを受信しない。これは、半二重通信問題（Half duplex issue）と呼ばれる。UEは、Half duplex issueにより受信しない情報を、他のUEからのリソース利用調整情報から得る（あるいは補完する）ことができる。また、消費電力低減のために1st stage SCIのセンシング時間を短縮したUEにとっても、短縮したセンシング時間では得られない情報を他のUEから得られるという利点がある。

なお、UE-Aは、例えば、UE-Aにおいてセンシングが「available」であるウィンドウあるいはスロットに関する情報、あるいは、UE-Aにおいてセンシングが「not available」であるウィンドウあるいはスロットに関する情報をUE-Bに通知してもよい。UE-Bは、UE-Aにおいてセンシングによって得られるリソースの情報、あるいは得られない情報を認識、把握できる。

以上のように、UEは、SLに使用するリソース選択の際にリソース利用調整情報を考慮してよい。

非限定的な一例を図８に示す。図８に例示したように、UE-Aは、スロット＃０～スロット＃７において、他のUEの1st stage SCIをセンシングし、スロット＃８において、リソース利用調整情報（inter-UE coordinate information）を送信する。この場合、UE-Aは、スロット＃８以前に受信した、複数の1st stage SCIから得られた、送信が予定されたリソースの情報をまとめてリソース利用調整情報として送信してよい。

例えば、スロット＃０においてセンシングした情報から、スロット＃１０のサブチャネル＃２において他のUEが送信を行う可能性があることが把握され、また、スロット＃１においてセンシングした情報から、スロット＃１２の２つのサブチャネル＃０及び＃１において他のUEが送信を行う可能性があることが把握された場合を想定する。

この場合、リソース利用調整情報によって、スロット＃１０のサブチャネル＃２と、スロット＃１２のサブチャネル＃０及び＃２と、が他のUEに使用される可能性があることを通知する。この通知には、例えば、使用される可能性のあるリソースを「１」で表し、使用される可能性が低いか、あるいは可能性のないリソースを「０」で表したビットマップが使用されてもよい。また、スロット単位で、他のUEに使用される可能性のあるリソースが通知される設定としてもよい。

また、複数のUEが、リソース利用調整情報を送信して、互いに、Half duplex issueにより受信しなかった情報を補い合うこともできる。例えば図９に示したように、UE-A及びUE-Bのそれぞれがリソース利用調整情報を送信することで、UE-A及びUE-Bのそれぞれにおいて得られなかったリソース利用に関する情報を、UE-AとUE-Bとの間で互いに補い合うことができる。

［リソース利用調整情報２］
UE-Aは、例えば、UE-Aが使用する可能性のあるリソースの情報をリソース利用調整情報として送信してよい。これは、rel.16 NRのサイドリンクの1st stage SCIにおいて、送信する情報と同じであってもよい。rel.16 NRのサイドリンクの1st stage SCIでは、３２スロット後方までの送信予定であるリソースの情報を送信できる。ただし、UE-Aは、予定していた送信を取りやめる場合、送信する予定として通知していたリソースを使用しなくてもよい。

リソース利用調整情報２では、rel.16 NRの1st stage SCIにおいて送信するリソースの情報よりも、長い期間について、使用する可能性のあるリソースを通知してもよい。また、rel.16 NRのサイドリンクの1st stage SCIでは、同一リソースプール内のリソース送信予定を通知するが、異なるリソースプール内のリソースについての送信予定を通知することとしてもよい。異なるリソースプールは、同一周波数帯である、BWP（band width part）に存在してもよいし、異なるBWPでもよい。また、同一セルIDが付与されるキャリアであってもよいし、異なるキャリアであってもよい。

[リソース利用調整情報３]
UE-Aは、例えば、UE-Bが送信に利用可能なリソースの情報をリソース利用調整情報として送信してもよい。例えば、UE-Aは、センシングによって得られた、他のUEが送信を予定しているリソースの情報、及び、回線品質測定によって得られた情報の少なくとも１つを基に、UE-Bによる送信に適したリソースを候補リソースに選択してよい。なお、この場合の「候補リソース」は、「推奨リソース」と称されてもよい。UE-Aは、選択した候補リソースの情報をリソース利用調整情報としてUE-Bに送信（又は通知）してよい。

なお、回線品質測定によって得られる情報の非限定的な一例としては、以下の情報が挙げられる。
- CQI（channel quality indicator）
- RSRP（Reference Signal Received Power）
- RSRQ（Reference Signal Received Quality）
- SINR（Signal to Interference plus Noise Ratio）

UE-Aから送信されるリソース利用調整情報において示される候補リソースの数は、１つでもよいし２以上でもよい。UE-Bは、候補リソースの数が２以上の場合、２以上の候補リソースの中から、例えば、送信に使用するリソースを選択してよい。

ただし、UE-Bは、UE-Aからの指示に従わずに（別言すると、受信したリソース利用調整情報を使用しないで、あるいは無視して）、UE-Bの判断によって、送信に使用するリソースを決定してもよいし、送信を行わないことを決定してもよい。

図１０に非限定的な一例を示す。図１０に例示したように、UE-Aは、スロット＃０からスロット＃７においてセンシングによって得られた情報から、他のUEが使用する可能性のあるリソース（図１０において「reserved」と表記）を把握する。

UE-Aは、例えば、他のUEが使用する可能性の低いリソース（例えば、「reserved」となっていないリソース）から、UE-Bの送信に使用可能な候補リソース（図１０において「recommended」と表記）を決定し、スロット＃８のリソース利用調整情報によって、スロット＃１１のサブチャネル＃１およびスロット＃１２のサブチャネル＃２を候補リソースとしてUE-Bに通知する。

UE-Bは、リソース利用調整情報において示された２つの候補リソース（スロット＃１１のサブチャネル＃１およびスロット＃１２のサブチャネル＃２）のうちの１つを選択し、選択したリソースを使用して送信を行ってよい。ただし、UE-Bは、リソース利用調整情報において示されたリソースとは異なる他のリソースを使用して送信を行ってもよいし、送信を行わなくてもよい。

図１０には、UE-Bが、UE-Aから受信したリソース利用調整情報において示された複数の候補リソースのうち、スロット＃１１のサブチャネル＃１を選択して送信を行った例が示される。この場合、UE-Bが送信に使用するフォーマットは、rel.16のフォーマットと同様にできる。

なお、UE-Aは、上述した例とは逆に、UE-Bによる送信に適さないリソース（便宜的に「非推奨リソース」と称されてもよい）をリソース利用調整情報によってUE-Bに通知してもよい。この場合、UE-Bは、受信したリソース利用調整情報が示すリソースを避けて、送信に使用するリソースを選択、決定してよい。非推奨リソースは、例えば、他のUEが送信を予定しているリソースの情報、及び、回線品質測定によって得られた情報の少なくとも１つを基に選択、決定されてよい。

［リソース利用調整情報４］
UE-Aは、UE-Bが送信に使用するリソースの情報をリソース利用調整情報として送信してもよい。このリソース利用調整情報は、他のUEに対するリソース割当情報（あるいはスケジューリング情報）に相当する、と理解されてもよい。UE-Bは、UE-Aによるリソース割り当て（別言すると、リソースのスケジューリング）に従って送信を行う。

UE-Aが送信するリソース利用調整情報４は、１台のUE向けの情報であってもよいし、複数のUE向けの情報であってもよい。複数のUE向けのリソース利用調整情報を送信するUE-Aは、ヘッダーUEと呼ばれてもよい。UE-Aは、基地局１００（例えば、gNB）のように、グループ内または近傍UEのスケジューリングを行う。

スケジューリング情報は、リソース利用調整情報４を受信し、その情報に基づき送信を行うUE-Bに限って受信される設定としてもよいし、UE-Bが送信を行う宛先のUEにおいても受信される設定としてもよい。

UE-Bが送信する宛先UEもリソース利用調整情報を受信する場合、UE-Bは、宛先UEが指定されたリソースにおいて、宛先UEによる送信の受信に備えて受信状態になることができるため、Half duplex issueを回避できる。また、UE-Bは、指定されたリソースにおいて受信状態となり、他のリソースでは受信を休止することで、消費電力を削減できる。

図１１に非限定的な一例を示す。図１１に例示したように、リソース利用調整情報３と同様、UE-Aは、スロット＃０～スロット＃７においてセンシングによって得られた情報から、他のUEが使用する可能性のあるリソース（図１１において「reserved」と表記）を把握する。

そして、UE-Aは、例えば、他のUEが使用する可能性の低いリソース（例えば、「reserved」となっていないリソース）から、UE-Bの送信に割り当てるリソース（図１１において「scheduled」と表記）を決定し、スロット＃８のリソース利用調整情報４によって、スロット＃１１のサブチャネル＃１をUE-Bに対するリソース割当情報として通知する。

UE-Bは、UE-Aから通知（別言すると、スケジューリング）されたリソース（図１１において、スロット＃１１のサブチャネル＃１）において送信を行う。この場合、UE-Bが送信に使用するフォーマットは、rel.16のフォーマットと同様にできる。

［実施の形態に共通の項目］
UE-Aが、UE-Bに対する受信UE（Rx UE）に相当する場合、UE-Aが送信するリソース利用調整情報に含まれる、UE-Bが使用可能なリソースの情報は、UE-Aが受信状態になるスロットから選択されてよい。このようにすると、UE-Aは、UE-Aが送信状態であるために、UE-Bが送信する信号の受信に失敗することを回避できる。

また、UE-AからUE-Bへ送信される、UE-Bが送信に利用可能なリソースの情報は、UE-BがUE-A宛の送信に使用するリソースの情報に限定されてもよいし、UE-BがUE-Aとは異なる他のUE宛の送信に使用するリソース情報を含んでもよい。UE-BがUE-Aとは異なる他のUE宛の送信に使用するリソースについては、UE-Bによる送信の宛先UEをUE-Aが指定することとしてもよい。

UEがリソース利用調整情報を送信するタイミングは、周期的（Periodic）に設定されてもよいし、非周期的(Aperiodic)に送信されてもよい。周期的な場合は、例えば、10, 11,…, 160, 200, 300 （m second or slot）のような単位で設定されてもよい。非周期的な場合は、UE-Aがデータ信号を送信する際にデータ信号と共にリソース利用調整情報を送信する設定としてもよいし、他のUEからリソース利用調整情報の送信を要求された場合に送信する設定としてもよい。

リソース利用調整情報１，２，３，４によって送信するリソースの情報は、スロット番号とサブチャネル番号とを通知する情報としたが、時間方向の情報はスロット番号ではなく、シンボル番号や、サブスロット、サブフレームと呼ばれる異なる時間単位でもよい。また、周波数方向の情報は、サブチャネルとしたが、リソースブロックや、サブバンド、リソースプール、BWP、キャリアといった異なる周波数単位でもよい。

リソース利用調整情報２では、rel.16 NRの1st stage SCIによって送信するリソースの情報よりも、長い期間について、使用する可能性のあるリソースを通知してもよいとした。他のリソース利用調整情報１，３，４についても、例えば３２スロット分の後方リソースを通知してもよいし、より長い期間について、リソース利用調整情報を通知してもよい。

次に、リソース利用調整情報を送信するチャネルについて説明する。リソース利用調整情報を送信するチャネルの一例としては、PSSCH、2nd stage SCI、新規チャネル、PSFCH、上位レイヤのシグナリング、1st stage SCIが考えられる。複数のチャネルを組み合わせてリソース利用調整情報を送信することも可能である。

［PSSCH］
UE-Aは、PSSCHを用いてリソース利用調整情報を送信してよい。PSSCHにリソース利用調整情報が含まれることを通知する方法の一例として、以下の２つの動作例が挙げられる。

（PSSCH動作例１)
PSSCH動作例１では、1st stage SCIまたは2nd stage SCIによって、PSSCHにリソース利用調整情報が含まれることを通知し、PSSCHによってリソース利用調整情報を送信する。

2nd stage SCIは、SCI format 2-AまたはSCI format 2-Bを用いてPSSCHにリソース利用調整情報が含まれることを通知してもよいし、また、SCI format 2-Cといった別の名称の新規フォーマットを用いて通知してもよい。

PSSCHは、ブロードキャスト、グループキャスト、及び、ユニキャストの何れかのキャストタイプにおいて送信されてよい。SCI format 2-Aでは、キャストタイプが通知される。SCI format 2-Bは、グループキャストに使用されるフォーマットである。ブロードキャストの場合、リソース利用調整情報は、どのUEでも受信できる情報である。

リソース利用調整情報１やリソース利用調整情報２の場合、どのUE宛の情報であるかは必須でなくてよいので、ブロードキャストを使用して送信することで、複数のUEがリソース利用に関する状況を共有できる。

一方、リソース利用調整情報３、あるいはリソース利用調整情報４の場合、どのUE宛のリソース割当情報であるのかを明確にするため、例えば、PSSCHの通知の中に、UEを識別するIDであるDestination IDが含まれてもよい。

グループキャストの場合、リソース利用調整情報はUEグループ宛に送信される。UEグループは、例えば、2nd stage SCIによって通知されるDestination IDを基に判別することが可能である。グループキャストの場合、あるUEグループにおけるUEが、リソース利用調整情報を共有できる。

リソース利用調整情報３、あるいはリソース利用調整情報４の場合、ブロードキャストと同様に、どのUE宛のリソース割当情報であるのかを明確にするため、例えば、PSSCHの通知の中に、どのUE宛であるのかを識別するIDであるDestination IDが含まれてもよい。

ユニキャストの場合、リソース利用調整情報は、あるUE宛に送信される。どのUE宛であるのかは、2nd stage SCIによって通知されるDestination IDから判別できるので、PSSCHにDestination IDが含まれなくても、宛先UEを判別できる。

PSSCHにリソース利用調整情報が含まれる場合、リソース利用調整情報は、PSSCH内のデータ信号として符号化されてもよいし、PSSCH内のデータ信号とは個別に符号化されてもよい。

図１２に、PSSCH領域においてリソース利用調整情報が送信される例を示す。図１２に例示したように、スロット内においてリソース利用調整情報が送信（又は配置）される候補のリソースは、PSSCH領域の全体であってよい。

PSSCH内のデータ信号とは個別にリソース利用調整情報が符号化される場合、例えば図１３に示すように、PSSCH内にリソース利用調整情報を送信するためのリソースが確保されてよい。別言すると、スロット内においてリソース利用調整情報が送信（又は配置）される候補のリソースは、PSSCH領域の一部のリソースであってもよい。利用調整情報を送信するためのリソースは、例えば、PSSCH内のどのシンボルおよびどのサブキャリアを用いるかが予め定められておいてよい。

PSSCHのデータ信号とは個別にリソース利用調整情報が復号されると、例えば、データ信号に先行してリソース利用調整情報を復号できるという利点がある。PSSCHのデータ信号とソース利用調整情報と個別に復号する場合、リソース利用調整情報のサイズによって、PSSCHにおいて送信できるデータ量が異なる。そのため、例えば、PSSCHにおいて送信するデータ量であるTBS（Transport block size）は、リソース利用調整情報のリソース量を除外したリソースを基に算出されてもよい。

SCI format 2-AまたはSCI format 2-BによってPSSCHにリソース利用調整情報が含まれることを通知する場合、例えば、SCI format 2-AまたはSCI format 2-BにPSSCHにリソース利用調整情報が含まれることを通知するビットが追加されてもよい。あるいは、SCI format 2-AまたはSCI format 2-Bのビットが、PSSCHにリソース利用調整情報が含まれることを通知するビットに置き換えられてもよい。

通知ビットを追加する場合、通知ビットを追加しない場合と比較して、SCI format 2-AまたはSCI format 2-Bのビット数が異なる。SCI format 2-AまたはSCI format 2-Bのビットを通知ビットに置き換える場合は、SCI format 2-AまたはSCI format 2-Bの情報内容が異なる。

そこで、ビット数が異なること、またはビットが置き換えられることを、例えば、予め上位レイヤ（例えば、RRC）で通知するか、pre-configuredと呼ばれるように予め設定しておく。このようにすると、通知または設定があったUEは、2nd stage SCIの受信ビット数を変更または置き換えできる。

また、1st stage SCIによってビット数の変更または置き換えを通知することも設定可能である。例えば、1st stage SCIに含まれるreserved bitsを用いて、SCI format 2-AまたはSCI format 2-Bのビット数が異なること、またはビットの置き換えを通知してもよい。

また、SCI format 2-Aにおいては、HARQ feedback enabled/disabled indicatorをenableに設定し、Cast type indicatorをbroadcastに設定することで、PSSCHにリソース利用調整情報が含まれることを通知してもよい。この組み合わせは、rel.16においては存在しない組み合わせであるため、ブロードキャストの場合、HARQフィードバックは設定できない。この信号を受信したレガシーUEは、存在しない組み合わせであるため、SCI format 2-Aの受信を誤ったと判断する可能性があるが、新規設定を知っているUEは、PSSCHにリソース利用調整情報が含まれることを通知されたと判断できる。

新規のSCIフォーマットを用いてPSSCHにリソース利用調整情報が含まれることを通知する場合も、新規SCIフォーマットを使用することを、予め上位レイヤ（例えば、RRCなど）で通知するか、pre-configuredと呼ばれるように予め設定しておくか、あるいは、1st stage SCIに含まれるreserved bitsにおいて、新規SCIフォーマットを受信するように指示することで、UEは新規SCIフォーマットを受信できる。

また、SCI format 2-A、SCI format 2-B、あるいは新規のSCIを用いてPSSCHにリソース利用調整情報が含まれることを通知する場合、宛先ID（Destination ID）または送信元ID（Source ID）によって通知が行われてもよい。

例えば、PSSCHにおいてリソース利用調整情報を送信する場合に使用する宛先IDまたは送信元IDを予め設定しておく。予め設定する宛先IDまたは送信元IDは、他のPSSCHのデータ送信時に使用する宛先IDまたは送信元IDとは異なる値とする。

このようにすると、SCI format 2-A、SCI format 2-B、または新規のSCIを受信したUEは、宛先IDまたは送信元IDから、PSSCHにリソース利用調整情報が含まれることを認識できる。

また、1st stage SCIを用いてPSSCHにリソース利用調整情報が含まれることを通知する場合、この通知は、例えば、reserved bitを用いて行われてもよい。

（PSSCH動作例２）
PSSCH動作例２では、例えば、MACヘッダー（サブヘッダーとも呼ばれる）リソース利用調整情報を送信する領域がMAC CE（Control Element）にあることを通知し、MAC CEにおいてリソース利用調整情報を送信する。MACヘッダーおよびMAC CEはPSSCHのデータ領域において送信される。

［2nd stage SCI］
リソース利用調整情報は、2nd stage SCIまたは新規SCIフォーマットにおいて送信されてもよい。SCI format 2-AまたはSCI format 2-Bにおいてリソース利用調整情報を送信する場合、SCI format 2-AまたはSCI format 2-Bに通知ビットが追加されてよい。あるいは、SCI format 2-AまたはSCI format 2-Bのビットを通知ビットに置き換える。

通知ビットを追加する場合、SCI format 2-AまたはSCI format 2-Bのビット数が、通知ビットを追加しない場合と比較して、異なる。SCI format 2-AまたはSCI format 2-Bのビットを通知ビットに置き換える場合、SCI format 2-AまたはSCI format 2-Bの情報内容が異なる。

そこで、例えば、ビット数が異なること、またはビットが置き換えられることを、予め上位レイヤ（例えば、RRC）において通知するか、pre-configuredと呼ばれるように予め設定しておく。

このようにすると、通知または設定があったUEは、2nd stage SCIの受信ビット数を変更または置き換えできる。また、1st stage SCIによって、2nd stage SCIのビット数の変更または置き換えを通知することも設定可能である。また、1st stage SCIに含まれるreserved bitsにおいて、SCI format 2-AまたはSCI format 2-Bのビット数が異なることまたはビットの置き換えを通知してもよい。

例えば、SCI format 2-Bを使用する場合、HARQ feedback enabled/disabled indicatorをdisabled に設定し、
- Zone ID - 12 bits
- Communication range requirement - 4 bitsを使用して、リソース利用調整情報を送信してもよい。

SCI format 2-Bを使用するブロードキャストにおいて、HARQ feedbackを要求しない場合（例えば、disabledの場合）、Zone ID、及び、Communication range requirementの情報はHARQフィードバックに使用する情報であるので、使用されない。したがって、これらのビットがリソース利用調整情報に使用されてよい。

新規のSCIフォーマットを用いてリソース利用調整情報を通知する場合も、新規SCIフォーマットを使用することを、予め上位レイヤ（例えば、RRC）において通知するか、pre-configuredと称されるように予め設定しておくか、あるいは、1st stage SCIに含まれるreserved bitsにおいて新規SCIフォーマットの受信を指示することで、UEは、新規SCIフォーマットを受信できる。新規フォーマットは、リソース利用調整情報を含むため、SCI format 2-A またはSCI format 2-Bよりも含まれるビット数、ペイロードサイズが大きいフォーマットでもよい。

SCI format 2-A、SCI format 2-B、または新規のSCIを用いてリソース利用調整情報を通知する場合、宛先IDまたは送信元IDによってリソース利用調整情報の存在を通知してもよい。例えば、リソース利用調整情報を送信する場合に使用する宛先IDまたは送信元IDを予め設定しておく。予め設定する宛先IDまたは送信元IDは、他のPSSCHのデータ送信時に使用する宛先IDまたは送信元IDとは異なる値とする。

このようにすると、SCI format 2-A、SCI format 2-B、または新規のSCIを受信したUEは、宛先IDまたは送信元IDから、2nd stage SCIにリソース利用調整情報が含まれることを認識できる。SCI format 2-A、SCI format 2-B、または新規のSCIの中のどのビットをリソース利用調整情報に置き換えるかは、例えば、予め定めておく。

また、SCI format 2-Aにおいては、HARQ feedback enabled/disabled indicatorをenableに設定し、Cast type indicatorをbroadcastに設定することで、リソース利用調整情報の存在を通知してもよい。この組み合わせは、rel.16においては存在しない組み合わせであるため、ブロードキャストの場合、HARQフィードバックは設定できない。この信号を受信したレガシーUEは、存在しない組み合わせであるため、SCI format 2-Aの受信を誤ったと判断する可能性があるが、新規設定を知っているUEは、リソース利用調整情報の存在を通知されたと判断できる。その際、SCI format 2-Aの情報の一部は、リソース利用調整情報に置き換えられてよい。

［new channel］
リソース利用調整情報は、新規チャネルによって送信されてもよい。新規チャネルによってリソース利用調整情報を通知する場合も、新規チャネルを使用することを、予め上位レイヤ（例えば、RRC）において通知するか、pre-configuredと呼ばれるように予め設定しておくか、あるいは、1st stage SCIに含まれるreserved bits、または、2nd stage SCIにおいて、新規チャネルにリソース利用調整情報が存在することを指示することで、UEは新規チャネルを受信できる。

新規チャネルは、既存のチャネルとは異なるPRB、サブチャネル、リソースプール、BWP、キャリアに配置されてもよい。例えば、Rel.16において、リソースプール内のPRB数がサブチャネルに含まるPRB数の倍数でない場合、余りのPRBは、リソース割り当てに使用されない。そこで、例えば図１４に示すように、余りのPRB（remaining PRB(s)）に新規チャネルを配置して、この新規チャネルにおいてリソース利用調整情報が送信されてよい。このようにすると、リソース利用効率が向上するという利点がある。なお、新規チャネルは、スロットの全部にわたって設定されてもよいし一部に限って設定されてもよく、また、複数スロットに跨って設定されてもよい。

［PSFCH］
リソース利用調整情報は、PSFCHによって送信されてもよい。Rel.16のPSFCHではACK/NACKの１ビットを１シンボルで送信することとされており、PUCCHフォーマット０と同様のフォーマットである。ここで、フォーマットとは、シンボル数、シーケンス、DMRSの配置等を示す。

リソース利用調整情報を配置するPSFCHは、Rel.16のPSFCHとは異なるフォーマットにしてもよい。異なるフォーマットとは、例えば、PUCCHフォーマット１，２，３，または４と同等のフォーマットでもよい。例えば、PUCCHフォーマット２，３，４では、２ビットよりも多いビット数を配置できるので、リソース利用調整情報の情報量が２ビットよりも多い場合に適する。また、PUCCHフォーマットとは異なるフォーマットを用いてPSFCHを構成してもよい。

PSFCHによってリソース利用調整情報を送信する場合、他のUEからリクエストがあった場合に、リソース利用調整情報を送信する設定としてもよい。例えば、UE-BからUE-Aへ、リソース利用調整情報の送信をリクエストした場合、UE-AがPSFCHによってリソース利用調整情報を送信する。

このようにすると、UE-Aが送信するPSFCHに使用するリソースを、UE-Bの送信時に決定することもできる。UE-Aは、PSFCHのリソースの配置や変調に関する情報を、PSSCHを送信する場合のように、1st stage SCIや2nd stage SCIといった情報によって通知しなくてもよい。したがって、例えば、1st stage SCIや2nd stage SCIを送信せずにPSFCHを送信してもよく、リソース利用のオーバーヘッドを削減できるという利点がある。

[RRC]
リソース利用調整情報は、例えば、UuリンクのRRCまたはUE-UE間のPC5 RRCを用いて送信されてもよい。あるいは、一部のリソース利用調整情報をRRCまたはPC5 RRCを用いて送信し、他のリソース利用調整情報を上述した動作例に示した方法の何れかによって送信することとしてもよい。例えば、割り当て周期が長い情報は、RRCまたはPC5 RRCを用いて送信し、割り当て周期が短い情報は上述した動作例に示した方法の何れかによって送信することとしてもよい。

［1st stage SCI］
リソース利用調整情報は、1st stage SCIによって送信されてもよい。例えば、リソース利用調整情報３、またはリソース利用調整情報４において、UE-AがUE-Bのリソース利用調整情報を送信する場合に1st stage SCIが用いられよい。

（1st stage SCI動作例１）
リソース利用調整情報は、例えば、1st stage SCIと同じスロットのリソースにおいて送信されてよい。図１５に一例を示す。

UE-Aは、例えば、同一スロット内において送信するUE-Bのリソース割当情報を1st stage SCIを用いて送信する。1st stage SCI内のreserved bitを使用して、どのUEへの割り当てかを指示してもよい。UE-Aは、同一スロットの1st stage SCI以外において送信を行わない。

UE-Bは、1st stage SCIを受信し、UE-B宛のリソースが1st stage SCIを受信したスロットと同一スロットに存在する場合、2nd stage SCIとPSSCHとを送信する。ただし、リソース利用調整情報３の場合、UE-Bの判断によって、UE-Bは送信を実施しなくてもよい。

このようにすると、同一スロット内で、異なる端末からのPSSCHの送信割り当てとPSSCHの送信とを実施できるので、割り当てからデータ送信までの遅延を短くできる。なお、rel.16のフレームフォーマットでは、1st stage SCIとPSSCH領域とが周波数多重されることが許容される。そのため、Rel.16のフォーマットをそのまま使用することは避けた方が好ましい。そこで、UE-Aが送信する1st stage SCIと、UE-Bが送信する2nd stage SCI PSSCHとは周波数多重せずに、例えば、1st stage SCIのＸシンボル後からUE-Bが送信を開始するといった時間多重とする。

なお、1st stage SCIと2nd stage SCIとをUE-Aが送信し、PSSCHのデータ部分をUE-Bが送信することとしてもよい。

（1st stage SCI動作例２）
本動作例では、1st stage SCIによって、自局のリソース割り当てと、他のUE宛のリソース利用調整情報と、を送信する。1st stage SCI内のreserved bitを使用して、どのUEへの割り当てかを指示してもよい。

1st stage SCIの時間リソースの割り当て（time resource assignment）では、２スロット分または３スロット分の時間リソースの割り当てが可能である。１スロット目は、1st stage SCIを送信するスロットである。

本動作例では、１スロット目の1st stage SCIと同じスロットの割り当ては、1st stage SCIを送信するUEと同じUEへの割り当て、つまりUE-Aのリソースとし、２スロット目、３スロット目の割り当てを他のUE向けの割り当てとする。

このようにすると、１スロット目の1st stage SCIと2nd stage SCIとPSSCHとの配置（あるいはフォーマット）をRe.16と比較して変更しなくてもよいという利点がある。

２スロット目、３スロット目では、１スロット目でリソースを割り当てられたUEが、1st stage SCI及び2nd stage SCIを送信できる。

このようにすると、Rel.16からフォーマットを変えずに送信を実施できる。図１６に一例を示す。図１６において、UE-Aは、UE-Bにスロット＃３にて送信を行うように通知する。UE-Aは、スロット＃０においてUE-Aの送信を実施し、UE-Bは、スロット＃３において送信を実施する。

本動作例の場合、Rel.16からフォーマットを変えなくてよいので、リソース利用調整情報を受信する機能をサポートしないUEも、リソースを受信できる。

（1st stage SCI動作例３）
本動作例では、1st stage SCIによって、他のUEに、上位レイヤなどで予め周期的に定めていたリソースに、送信をしてよいかどうかを通知する。この通知は、例えば、1st stage SCI内のreserved bitを使用して行われてもよい。このようにすると、1st stage SCIにおいてリソース割当情報を送信しなくてもよいので、ビット数を削減できる。

次に、リソース利用調整情報を送信するUEを決定する方法の一例について説明する。

（方法１：事前設定）
リソース利用調整情報を送信するUEは、例えば、基地局１００（例えば、eNBあるいはgNB）が決定し、configuredと呼ばれるSIB（System Information Block）や、その他のRRCといった上位レイヤやMACにおいて設定されてよい。あるいは、リソース利用調整情報を送信するUEは、例えば、Pre-configuredと呼ばれるように仕様で予め設定されてもよいし、SIMに予め設定されてもよいし、アプリケーションレイヤにおいて設定されてもよい。例えば、サイドリンク通信が、mission critical communicationのような通信に使用される場合は、どのUEからリソース利用調整情報を送信するかを予め設定しておくことで、無駄なリソース利用を抑制できるので効率的である。

（方法２：S-SSB）
リソース利用調整情報を送信するUEは、例えば、S-SSBを送信するUEであってよい。S-SSBを送信するUEは、例えば、基地局１００とUuリンクを確立済みのUEである。S-SSBを送信するUEが、S-SSBと共にリソース利用調整情報を送信してよい。

S-SSBは、S-PSS,S-SSS,PSBSHを含む信号であり、例えば、160msの周期で送信され、同期獲得や、PSBCHでの情報の送信に使用される。このS-SSBを送信する際に、S-SSBに隣り合うPRBや、S-SSBに隣り合うシンボルまたはスロットにおいて、リソース利用調整情報が送信されてよい。このようにすると、他のUEは、160ms周期といった決まったタイミングにおいてリソース利用調整情報を受信できる。

（方法３：UEが決定）
UEが、リソース利用調整情報を送信するかどうかを決定してもよい。例えば、UEが、ランダム値を生成し、そのランダム値と、予め定められた値を比較して、ランダム値が或る範囲にあれば、リソース利用情報を送信することを決定してもよい。ランダム値は、例えば、UE ID、メンバーID、スクランブリングに使用されるシーケンス、および、スロット番号といった情報を基に生成されてよい。このようにすると、多数のUEが無秩序にリソース利用情報を送信することを防止できる。

（方法４：PSSCHの条件により決定）
UEは、送信するTBSが、或る値（例えば、閾値）よりも大きい場合に、リソース利用調整情報を送信するとしてもよい。TBSが大きいほど、リソース利用調整情報のオーバーヘッドの割合が相対的に小さくなるので、リソース利用に与える影響が小さいという効果がある。

また、UEは、MCSが或る値（例えば、閾値）よりも高い場合に、リソース利用調整情報を送信するとしてもよい。MCSが高いほどUE間の通信品質が良いと考えられるので、例えばUE間の距離が近いことが予想される。その場合、周囲のUEが同様の通信環境にあるUEであると考えらえるので、センシングした情報の共有が有効である。

（方法５：事前の通信の有無により決定）
リソース利用調整情報を送信するUEは、事前（又は過去）に他のUEとサイドリンクの通信を行ったUEとしてもよい。例えば、UE-AとUE-Bとの間において通信があった場合、UE-Aがリソース利用調整情報を送信することとしてよい。例えば、リソース利用調整情報を送信するUE-Aは、UE-Bに対する宛先UEまたは送信元UEであったUEとしてよい。

（方法６：歩行者（Pedestrian）UEから要望されたUE）
Pedestrian UEから要望のあったUEが、リソース利用調整情報を送信することとしてもよい。Pedestrian UEは、例えば、スマートフォンといった携帯端末であることが想定されるため、消費電力をなるべく抑えたいという要望がある。したがって、センシング情報を他のUEから共有してもらうことが有効であるため、Pedestrian UEから要望された他のUEが、リソース利用調整情報を送信することとしてよい。

（方法７：距離またはSINRを基に決定）
SINRが或る値（例えば、閾値）よりも高い、または端末間の距離が或る距離（例えば、閾値）よりも近い場合に、リソース利用調整情報を送信することとしてもよい。SINRが閾値よりも高い場合、あるいは距離が閾値よりも近い場合は、周囲のUEが同様の通信環境にあるUEであると考えらえるので、センシングした情報の共有が有効である。端末間の距離は、例えば、Zone IDを基に判断、決定されてよい。代替的あるいは追加的に、端末間の距離は、アプリケーションレイヤからの情報に基づいて判断、決定されてもよい。

（その他）
上述した実施の形態では、新規にリソース利用調整情報を送信する場合のチャネルについて説明したが、リソースへの新規チャネルの配置方法は、他の新規情報の配置に用いてもよい。他の新規情報の一例としては、異なるキャリアまたはBWPへの割り当て情報、繰り返し送信の有無や回数の情報、PSFCHのフォーマット、送信リソースを指定する情報、送信パワーを設定する情報、送信ビームを指定する情報、MIMO（Multiple-Input and Multiple-Output）送信のレイヤ数を指定する情報、同期信号の送信の有無やリソースを指定する情報が挙げられる。

上述した動作例は、組み合わせて使用されてもよい。例えば、動作例は、UE毎に異なってもよいし、１つのUEが、複数の動作例によってリソース利用調整情報を送信してもよい。例えば、リソース利用調整情報２を送信するUEが、1st stage SCIとPSSCHとを用いてリソース利用調整情報２を送信してもよい。このとき、1st stage SCIでは、３２スロット後方までの情報を指示し、PSSCHにおいて、より後方のスロットの情報を指示することとしてもよい。

また、例えば、ヘッダーUEと呼ばれるUEが、リソース利用調整情報３またはリソース利用調整情報４を送信し、ヘッダーUEに接続する他のUEが、リソース利用調整情報１またはリソース利用調整情報２を送信してもよい。このようにすると、ヘッダーUEが自身の送信時に受信できない他UEのリソース割り当て情報を、メンバーの他のUEから受信して情報を補うことができる。

サイドリンクにおいて通信する端末には、送信及び受信の一方のみを行う端末と、送信及び受信の双方を行う端末と、が含まれてよい。

サイドリンクに関する設定が、予め設定されているとする場合、その設定方法は、例えば、仕様によって予め設定されてもよいし、SIMに予め設定されてもよい。また、設定方法には、Pre-configuredと呼ばれるアプリケーションレイヤでの設定、configuredと呼ばれるSIBやその他のRRCのような上位レイヤでの設定、あるいは、MACでの設定が含まれてもよい。

PSCCHをPDCCHに、PSSCHをPDSCHまたはPUSCHに、PSFCHをPUCCHに、PSBCHをPBCHに置き換えて、基地局１００と端末２００との間の通信に、上述した実施の形態が適用されてもよい。また、2nd stage SCIをアップリンクの制御情報であるUCI（Uplink control information）に置き換え、PUSCHにおいて送信されるUCIに対して上述した実施の形態が適用されてもよい。

また、上述した実施の形態は、サイドリンクのMode 1及びMode 2のうちのMode 2のみに適用されてもよい。

リソース利用調整情報は、複数のUE間で互いに共有されてもよい。このようにすると、Half duplex issue により受信しないセンシング情報を互いに補い合うことができる。リソース利用調整情報の受信を設定されたUEは、センシングを行わないという設定にしてもよい。このようにすると、センシングに伴う消費電力の低減を図ることができる。

以上、本開示の実施の形態について説明した。

［他の実施の形態］
（基地局）
本開示において、基地局は、TRP（Transmission Reception Point）、クラスタヘッド、アクセスポイント、RRH（Remote Radio Head）、eNodeB (eNB)、gNodeB(gNB)、BS(Base Station)、BTS(Base Transceiver Station)、親機、ゲートウェイ等でもよい。また、サイドリンク通信では、基地局の代わりに端末としてもよい。上位ノードと端末の通信を中継する中継装置であってもよい。

（上りリンク／下りリンク／サイドリンク）
本開示は、上りリンク、下りリンク、サイドリンクのいずれに適用してもよい。例えば、本開示を上りリンクのPUSCH（Physical Uplink Shared Channel）、PUCCH（Physical Uplink Control Channel）、PRACH（Physical Random Access CHannel）、下りリンクのPDSCH（Physical Downlink Shared Channel）、PDCCH（Physical Downlink Control Channel）、PBCH、サイドリンクのPSSCH、PSCCH、PSBCHに適用してもよい。PSCCH、PSSCHは、それぞれ、サイドリンク制御チャネル、サイドリンクデータチャネルの一例である。PBCH及びPSBCHは、報知（ブロードキャスト）チャネルの一例である。

（データチャネル／制御チャネル）
本開示は、データチャネル及び制御チャネルのいずれに適用してもよい。例えば、本開示のチャネルをデータチャネルのPDSCH、PUSCH、PSSCH、制御チャネルのPDCCH、PUCCH、PBCH、PSCCH、PSBCHに置き換えてもよい。

（参照信号）
本開示において、参照信号は、基地局及び端末の双方で既知の信号であり、RS (Reference Signal)又はパイロット信号と呼ばれることもある。参照信号は、DMRS、CSI-RS（Channel State Information - Reference Signal）、TRS（Tracking Reference Signal）、PTRS(Phase Tracking Reference Signal)、CRS(Cell-specific Reference Signal), SRS(Sounding Reference Signal)であってもよい。

（時間間隔）
上記実施の形態において、時間リソースの単位は、スロット及びシンボルの１つ又は組み合わせに限らず、例えば、フレーム、スーパーフレーム、サブフレーム、スロット、タイムスロットサブスロット、ミニスロット又は、シンボル、OFDM（Orthogonal Frequency Division Multiplexing）シンボル、SC-FDMA（Single Carrier - Frequency Division Multiplexing）シンボルといった時間リソース単位でもよく、他の時間リソース単位でもよい。また、１スロットに含まれるシンボル数は、上述した実施の形態において例示したシンボル数に限定されず、他のシンボル数でもよい。

（周波数帯域）
本開示は、ライセンスバンド、アンライセンスバンドのいずれに適用されてもよい。

（通信）
本開示は、基地局と端末との間の通信、端末と端末との間の通信（Sidelink通信，Uuリンク通信）、V2X（Vehicle to Everything）の通信のいずれに適用されてもよい。例えば、本開示のチャネルは、PSCCH、PSSCH、PSFCH、PSBCH、PDCCH、PUCCH、PDSCH、PUSCH、PBCHに置き換えてられてもよい。

また、本開示は、地上のネットワーク、衛星や高度疑似衛星（HAPS）を用いた地上以外のネットワーク（NTN：Non-Terrestrial Network）のいずれに適用されてもよい。また、本開示は、セルサイズの大きなネットワーク、超広帯域伝送ネットワークなどシンボル長やスロット長に比べて伝送遅延が大きい地上ネットワークに適用されてもよい。

＜５Ｇ ＮＲのシステムアーキテクチャおよびプロトコルスタック＞
３ＧＰＰは、１００ＧＨｚまでの周波数範囲で動作する新無線アクセス技術（ＮＲ）の開発を含む第５世代携帯電話技術（単に「５Ｇ」ともいう）の次のリリースに向けて作業を続けている。５Ｇ規格の初版は２０１７年の終わりに完成しており、これにより、５Ｇ ＮＲの規格に準拠した端末（例えば、スマートフォン）の試作および商用展開に移ることが可能である。

例えば、システムアーキテクチャは、全体としては、ｇＮＢを備えるＮＧ－ＲＡＮ（Next Generation - Radio Access Network）を想定する。ｇＮＢは、ＮＧ無線アクセスのユーザプレーン（ＳＤＡＰ／ＰＤＣＰ／ＲＬＣ／ＭＡＣ／ＰＨＹ）および制御プレーン（ＲＲＣ）のプロトコルのＵＥ側の終端を提供する。ｇＮＢは、Ｘｎインタフェースによって互いに接続されている。また、ｇＮＢは、Next Generation（ＮＧ）インタフェースによってＮＧＣ（Next Generation Core）に、より具体的には、ＮＧ－ＣインタフェースによってＡＭＦ（Access and Mobility Management Function）（例えば、ＡＭＦを行う特定のコアエンティティ）に、また、ＮＧ－ＵインタフェースによってＵＰＦ（User Plane Function）（例えば、ＵＰＦを行う特定のコアエンティティ）に接続されている。ＮＧ－ＲＡＮアーキテクチャを図１７に示す（例えば、3GPP TS 38.300 v15.6.0, section 4参照）。

ＮＲのユーザプレーンのプロトコルスタック（例えば、3GPP TS 38.300, section 4.4.1参照）は、ｇＮＢにおいてネットワーク側で終端されるＰＤＣＰ（Packet Data Convergence Protocol（TS 38.300の第６．４節参照））サブレイヤ、ＲＬＣ（Radio Link Control（TS 38.300の第６．３節参照））サブレイヤ、およびＭＡＣ（Medium Access Control（TS 38.300の第６．２節参照））サブレイヤを含む。また、新たなアクセス層（ＡＳ：Access Stratum）のサブレイヤ（ＳＤＡＰ：Service Data Adaptation Protocol）がＰＤＣＰの上に導入されている（例えば、3GPP TS 38.300の第６．５節参照）。また、制御プレーンのプロトコルスタックがＮＲのために定義されている（例えば、TS 38.300, section 4.4.2参照）。レイヤ２の機能の概要がTS 38.300の第６節に記載されている。ＰＤＣＰサブレイヤ、ＲＬＣサブレイヤ、およびＭＡＣサブレイヤの機能は、それぞれ、TS 38.300の第６．４節、第６．３節、および第６．２節に列挙されている。ＲＲＣレイヤの機能は、TS 38.300の第７節に列挙されている。

例えば、Medium-Access-Controlレイヤは、論理チャネル（logical channel）の多重化と、様々なニューメロロジーを扱うことを含むスケジューリングおよびスケジューリング関連の諸機能と、を扱う。

例えば、物理レイヤ（ＰＨＹ）は、符号化、ＰＨＹ ＨＡＲＱ処理、変調、マルチアンテナ処理、および適切な物理的時間－周波数リソースへの信号のマッピングの役割を担う。また、物理レイヤは、物理チャネルへのトランスポートチャネルのマッピングを扱う。物理レイヤは、ＭＡＣレイヤにトランスポートチャネルの形でサービスを提供する。物理チャネルは、特定のトランスポートチャネルの送信に使用される時間周波数リソースのセットに対応し、各トランスポートチャネルは、対応する物理チャネルにマッピングされる。例えば、物理チャネルには、上り物理チャネルとして、ＰＲＡＣＨ（Physical Random Access Channel）、ＰＵＳＣＨ（Physical Uplink Shared Channel)、ＰＵＣＣＨ(Physical Uplink Control Channel)があり、下り物理チャネルとして、ＰＤＳＣＨ（Physical Downlink Shared Channel)、ＰＤＣＣＨ（Physical Downlink Control Channel)、ＰＢＣＨ(Physical Broadcast Channel) がある。

ＮＲのユースケース／展開シナリオには、データレート、レイテンシ、およびカバレッジの点で多様な要件を有するenhanced mobile broadband（ｅＭＢＢ）、ultra-reliable low-latency communications（ＵＲＬＬＣ）、massive machine type communication（ｍＭＴＣ）が含まれ得る。例えば、ｅＭＢＢは、ＩＭＴ－Ａｄｖａｎｃｅｄが提供するデータレートの３倍程度のピークデータレート（下りリンクにおいて２０Ｇｂｐｓおよび上りリンクにおいて１０Ｇｂｐｓ）および実効（user-experienced）データレートをサポートすることが期待されている。一方、ＵＲＬＬＣの場合、より厳しい要件が超低レイテンシ（ユーザプレーンのレイテンシについてＵＬおよびＤＬのそれぞれで０．５ｍｓ）および高信頼性（１ｍｓ内において１－１０－５）について課されている。最後に、ｍＭＴＣでは、好ましくは高い接続密度（都市環境において装置１，０００，０００台／ｋｍ^２）、悪環境における広いカバレッジ、および低価格の装置のための極めて寿命の長い電池（１５年）が求められうる。

そのため、１つのユースケースに適したＯＦＤＭのニューメロロジー（例えば、サブキャリア間隔、ＯＦＤＭシンボル長、サイクリックプレフィックス（ＣＰ：Cyclic Prefix）長、スケジューリング区間毎のシンボル数）が他のユースケースには有効でない場合がある。例えば、低レイテンシのサービスでは、好ましくは、ｍＭＴＣのサービスよりもシンボル長が短いこと（したがって、サブキャリア間隔が大きいこと）および／またはスケジューリング区間（ＴＴＩともいう）毎のシンボル数が少ないことが求められうる。さらに、チャネルの遅延スプレッドが大きい展開シナリオでは、好ましくは、遅延スプレッドが短いシナリオよりもＣＰ長が長いことが求められうる。サブキャリア間隔は、同様のＣＰオーバーヘッドが維持されるように状況に応じて最適化されてもよい。ＮＲがサポートするサブキャリア間隔の値は、１つ以上であってよい。これに対応して、現在、１５ｋＨｚ、３０ｋＨｚ、６０ｋＨｚ…のサブキャリア間隔が考えられている。シンボル長Ｔｕおよびサブキャリア間隔Δｆは、式Δｆ＝１／Ｔｕによって直接関係づけられている。ＬＴＥシステムと同様に、用語「リソースエレメント」を、１つのＯＦＤＭ／ＳＣ－ＦＤＭＡシンボルの長さに対する１つのサブキャリアから構成される最小のリソース単位を意味するように使用することができる。

新無線システム５Ｇ－ＮＲでは、各ニューメロロジーおよび各キャリアについて、サブキャリアおよびＯＦＤＭシンボルのリソースグリッドが上りリンクおよび下りリンクのそれぞれに定義される。リソースグリッドの各エレメントは、リソースエレメントと呼ばれ、周波数領域の周波数インデックスおよび時間領域のシンボル位置に基づいて特定される（3GPP TS 38.211 v15.6.0参照）。

＜５Ｇ ＮＲにおけるＮＧ－ＲＡＮと５ＧＣとの間の機能分離＞
図１８は、ＮＧ－ＲＡＮと５ＧＣとの間の機能分離を示す。ＮＧ－ＲＡＮの論理ノードは、ｇＮＢまたはｎｇ－ｅＮＢである。５ＧＣは、論理ノードＡＭＦ、ＵＰＦ、およびＳＭＦを有する。

例えば、ｇＮＢおよびｎｇ－ｅＮＢは、以下の主な機能をホストする：
－ 無線ベアラ制御（Radio Bearer Control）、無線アドミッション制御（Radio Admission Control）、接続モビリティ制御（Connection Mobility Control）、上りリンクおよび下りリンクの両方におけるリソースのＵＥへの動的割当（スケジューリング）等の無線リソース管理（Radio Resource Management）の機能；
－ データのＩＰヘッダ圧縮、暗号化、および完全性保護；
－ ＵＥが提供する情報からＡＭＦへのルーティングを決定することができない場合のＵＥのアタッチ時のＡＭＦの選択；
－ ＵＰＦに向けたユーザプレーンデータのルーティング；
－ ＡＭＦに向けた制御プレーン情報のルーティング；
－ 接続のセットアップおよび解除；
－ ページングメッセージのスケジューリングおよび送信；
－ システム報知情報（ＡＭＦまたは運用管理保守機能（ＯＡＭ：Operation, Admission, Maintenance）が発信源）のスケジューリングおよび送信；
－ モビリティおよびスケジューリングのための測定および測定報告の設定；
－ 上りリンクにおけるトランスポートレベルのパケットマーキング；
－ セッション管理；
－ ネットワークスライシングのサポート；
－ ＱｏＳフローの管理およびデータ無線ベアラに対するマッピング；
－ ＲＲＣ＿ＩＮＡＣＴＩＶＥ状態のＵＥのサポート；
－ ＮＡＳメッセージの配信機能；
－ 無線アクセスネットワークの共有；
－ デュアルコネクティビティ；
－ ＮＲとＥ－ＵＴＲＡとの緊密な連携。

Access and Mobility Management Function（ＡＭＦ）は、以下の主な機能をホストする：
－ Non-Access Stratum（ＮＡＳ）シグナリングを終端させる機能；
－ ＮＡＳシグナリングのセキュリティ；
－ Access Stratum（ＡＳ）のセキュリティ制御；
－ ３ＧＰＰのアクセスネットワーク間でのモビリティのためのコアネットワーク（CN：Core Network）ノード間シグナリング；
－ アイドルモードのＵＥへの到達可能性（ページングの再送信の制御および実行を含む）；
－ 登録エリアの管理；
－ システム内モビリティおよびシステム間モビリティのサポート；
－ アクセス認証；
－ ローミング権限のチェックを含むアクセス承認；
－ モビリティ管理制御（加入およびポリシー）；
－ ネットワークスライシングのサポート；
－ Session Management Function（ＳＭＦ）の選択。

さらに、User Plane Function（ＵＰＦ）は、以下の主な機能をホストする：
－ ｉｎｔｒａ－ＲＡＴモビリティ／ｉｎｔｅｒ－ＲＡＴモビリティ（適用可能な場合）のためのアンカーポイント；
－ データネットワークとの相互接続のための外部ＰＤＵ(Protocol Data Unit)セッションポイント；
－ パケットのルーティングおよび転送；
－ パケット検査およびユーザプレーン部分のポリシールールの強制（Policy rule enforcement）；
－ トラフィック使用量の報告；
－ データネットワークへのトラフィックフローのルーティングをサポートするための上りリンククラス分類（uplink classifier）；
－ マルチホームＰＤＵセッション（multi-homed PDU session）をサポートするための分岐点(Branching Point)；
－ ユーザプレーンに対するＱｏＳ処理（例えば、パケットフィルタリング、ゲーティング（gating）、ＵＬ／ＤＬレート制御（UL/DL rate enforcement）；
－ 上りリンクトラフィックの検証（ＳＤＦのＱｏＳフローに対するマッピング）；
－ 下りリンクパケットのバッファリングおよび下りリンクデータ通知のトリガ機能。

最後に、Session Management Function（ＳＭＦ）は、以下の主な機能をホストする：
－ セッション管理；
－ ＵＥに対するＩＰアドレスの割当および管理；
－ ＵＰＦの選択および制御；
－ 適切な宛先にトラフィックをルーティングするためのUser Plane Function（ＵＰＦ）におけるトラフィックステアリング（traffic steering）の設定機能；
－ 制御部分のポリシーの強制およびＱｏＳ；
－ 下りリンクデータの通知。

＜ＲＲＣ接続のセットアップおよび再設定の手順＞
図１９は、ＮＡＳ部分の、ＵＥがRRC_IDLEからRRC_CONNECTEDに移行する際のＵＥ、ｇＮＢ、およびＡＭＦ（５ＧＣエンティティ）の間のやり取りのいくつかを示す（TS 38.300 v15.6.0参照）。

ＲＲＣは、ＵＥおよびｇＮＢの設定に使用される上位レイヤのシグナリング（プロトコル）である。この移行により、ＡＭＦは、ＵＥコンテキストデータ（これは、例えば、ＰＤＵセッションコンテキスト、セキュリティキー、ＵＥ無線性能（UE Radio Capability）、ＵＥセキュリティ性能（UE Security Capabilities）等を含む）を用意し、初期コンテキストセットアップ要求（INITIAL CONTEXT SETUP REQUEST）とともにｇＮＢに送る。そして、ｇＮＢは、ＵＥと一緒に、ＡＳセキュリティをアクティブにする。これは、ｇＮＢがＵＥにSecurityModeCommandメッセージを送信し、ＵＥがSecurityModeCompleteメッセージを用いてｇＮＢに応答することによって行われる。その後、ｇＮＢは、ＵＥにRRCReconfigurationメッセージを送信し、これに対するＵＥからのRRCReconfigurationCompleteをｇＮＢが受信することによって、Signaling Radio Bearer 2（ＳＲＢ２）およびData Radio Bearer（ＤＲＢ）をセットアップするための再設定を行う。シグナリングのみの接続については、ＳＲＢ２およびＤＲＢがセットアップされないため、RRCReconfigurationに関するステップは省かれる。最後に、ｇＮＢは、初期コンテキストセットアップ応答（INITIAL CONTEXT SETUP RESPONSE）でセットアップ手順が完了したことをＡＭＦに通知する。

したがって、本開示では、ｇＮｏｄｅＢとのNext Generation（ＮＧ）接続を動作時に確立する制御回路と、ｇＮｏｄｅＢとユーザ機器（ＵＥ：User Equipment）との間のシグナリング無線ベアラがセットアップされるように動作時にＮＧ接続を介してｇＮｏｄｅＢに初期コンテキストセットアップメッセージを送信する送信部と、を備える、5th Generation Core（５ＧＣ）のエンティティ（例えば、ＡＭＦ、ＳＭＦ等）が提供される。具体的には、ｇＮｏｄｅＢは、リソース割当設定情報要素(IE: Information Element)を含むRadio Resource Control（ＲＲＣ）シグナリングを、シグナリング無線ベアラを介してＵＥに送信する。そして、ＵＥは、リソース割当設定に基づき上りリンクにおける送信または下りリンクにおける受信を行う。

＜２０２０年以降のＩＭＴの利用シナリオ＞
図２０は、５Ｇ ＮＲのためのユースケースのいくつかを示す。3rd generation partnership project new radio（３ＧＰＰ ＮＲ）では、多種多様なサービスおよびアプリケーションをサポートすることがＩＭＴ－２０２０によって構想されていた３つのユースケースが検討されている。大容量・高速通信（ｅＭＢＢ：enhanced mobile-broadband）のための第一段階の仕様の策定が終了している。現在および将来の作業には、ｅＭＢＢのサポートを拡充していくことに加えて、高信頼・超低遅延通信（ＵＲＬＬＣ：ultra-reliable and low-latency communications）および多数同時接続マシンタイプ通信（ｍＭＴＣ：massive machine-type communicationsのための標準化が含まれる。図２０は、２０２０年以降のＩＭＴの構想上の利用シナリオのいくつかの例を示す（例えばＩＴＵ－Ｒ Ｍ．２０８３ 図２参照）。

ＵＲＬＬＣのユースケースには、スループット、レイテンシ（遅延）、および可用性のような性能についての厳格な要件がある。ＵＲＬＬＣのユースケースは、工業生産プロセスまたは製造プロセスのワイヤレス制御、遠隔医療手術、スマートグリッドにおける送配電の自動化、交通安全等の今後のこれらのアプリケーションを実現するための要素技術の１つとして構想されている。ＵＲＬＬＣの超高信頼性は、TR 38.913によって設定された要件を満たす技術を特定することによってサポートされる。リリース１５におけるＮＲ ＵＲＬＬＣでは、重要な要件として、目標とするユーザプレーンのレイテンシがＵＬ（上りリンク）で０．５ｍｓ、ＤＬ（下りリンク）で０．５ｍｓであることが含まれている。一度のパケット送信に対する全般的なＵＲＬＬＣの要件は、ユーザプレーンのレイテンシが１ｍｓの場合、３２バイトのパケットサイズに対してブロック誤り率（ＢＬＥＲ：block error rate）が１Ｅ－５であることである。

物理レイヤの観点では、信頼性は、多くの採り得る方法で向上可能である。現在の信頼性向上の余地としては、ＵＲＬＬＣ用の別個のＣＱＩ表、よりコンパクトなＤＣＩフォーマット、ＰＤＣＣＨの繰り返し等を定義することが含まれる。しかしながら、この余地は、ＮＲが（ＮＲ ＵＲＬＬＣの重要要件に関し）より安定しかつより開発されるにつれて、超高信頼性の実現のために広がりうる。リリース１５におけるＮＲ ＵＲＬＬＣの具体的なユースケースには、拡張現実／仮想現実（ＡＲ／ＶＲ）、ｅ－ヘルス、ｅ－セイフティ、およびミッションクリティカルなアプリケーションが含まれる。

また、ＮＲ ＵＲＬＬＣが目標とする技術強化は、レイテンシの改善および信頼性の向上を目指している。レイテンシの改善のための技術強化には、設定可能なニューメロロジー、フレキシブルなマッピングによる非スロットベースのスケジューリング、グラントフリーの（設定されたグラントの）上りリンク、データチャネルにおけるスロットレベルでの繰り返し、および下りリンクでのプリエンプション（Pre-emption）が含まれる。プリエンプションとは、リソースが既に割り当てられた送信が停止され、当該既に割り当てられたリソースが、後から要求されたより低いレイテンシ／より高い優先度の要件の他の送信に使用されることを意味する。したがって、既に許可されていた送信は、後の送信によって差し替えられる。プリエンプションは、具体的なサービスタイプと無関係に適用可能である。例えば、サービスタイプＡ（ＵＲＬＬＣ）の送信が、サービスタイプＢ（ｅＭＢＢ等）の送信によって差し替えられてもよい。信頼性向上についての技術強化には、１Ｅ－５の目標ＢＬＥＲのための専用のＣＱＩ／ＭＣＳ表が含まれる。

ｍＭＴＣ（massive machine type communication）のユースケースの特徴は、典型的には遅延の影響を受けにくい比較的少量のデータを送信する接続装置の数が極めて多いことである。装置には、低価格であること、および電池寿命が非常に長いことが要求される。ＮＲの観点からは、非常に狭い帯域幅部分を利用することが、ＵＥから見て電力が節約されかつ電池の長寿命化を可能にする１つの解決法である。

上述のように、ＮＲにおける信頼性向上のスコープはより広くなることが予測される。あらゆるケースにとっての重要要件の１つであって、例えばＵＲＬＬＣおよびｍＭＴＣについての重要要件が高信頼性または超高信頼性である。いくつかのメカニズムが信頼性を無線の観点およびネットワークの観点から向上させることができる。概して、信頼性の向上に役立つ可能性がある２つ～３つの重要な領域が存在する。これらの領域には、コンパクトな制御チャネル情報、データチャネル/制御チャネルの繰り返し、および周波数領域、時間領域、および／または空間領域に関するダイバーシティがある。これらの領域は、特定の通信シナリオにかかわらず一般に信頼性向上に適用可能である。

ＮＲ ＵＲＬＬＣに関し、ファクトリーオートメーション、運送業、および電力の分配のような、要件がより厳しいさらなるユースケースが想定されている。厳しい要件とは、高い信頼性（１０－６レベルまでの信頼性）、高い可用性、２５６バイトまでのパケットサイズ、数μｓ程度までの時刻同期（time synchronization）（ユースケースに応じて、値を、周波数範囲および０．５ｍｓ～１ｍｓ程度の短いレイテンシ（例えば、目標とするユーザプレーンでの０．５ｍｓのレイテンシ）に応じて１μｓまたは数μｓとすることができる）である。

さらに、ＮＲ ＵＲＬＬＣについては、物理レイヤの観点からいくつかの技術強化が有り得る。これらの技術強化には、コンパクトなＤＣＩに関するＰＤＣＣＨ（Physical Downlink Control Channel）の強化、ＰＤＣＣＨの繰り返し、ＰＤＣＣＨのモニタリングの増加がある。また、ＵＣＩ（Uplink Control Information）の強化は、ｅｎｈａｎｃｅｄ ＨＡＲＱ（Hybrid Automatic Repeat Request）およびＣＳＩフィードバックの強化に関係する。また、ミニスロットレベルのホッピングに関係するＰＵＳＣＨの強化、および再送信／繰り返しの強化が有り得る。用語「ミニスロット」は、スロットより少数のシンボルを含むTransmission Time Interval（ＴＴＩ）を指す（スロットは、１４個のシンボルを備える）。

＜ＱｏＳ制御＞
５ＧのＱｏＳ（Quality of Service）モデルは、ＱｏＳフローに基づいており、保証されたフロービットレートが求められるＱｏＳフロー（GBR：Guaranteed Bit Rate ＱｏＳフロー）、および、保証されたフロービットレートが求められないＱｏＳフロー（非ＧＢＲ ＱｏＳフロー）をいずれもサポートする。したがって、ＮＡＳレベルでは、ＱｏＳフローは、ＰＤＵセッションにおける最も微細な粒度のＱｏＳの区分である。ＱｏＳフローは、ＮＧ－Ｕインタフェースを介してカプセル化ヘッダー（encapsulation header）において搬送されるＱｏＳフローＩＤ（ＱＦＩ：QoS Flow ID）によってＰＤＵセッション内で特定される。

各ＵＥについて、５ＧＣは、１つ以上のＰＤＵセッションを確立する。各ＵＥについて、ＰＤＵセッションに合わせて、ＮＧ－ＲＡＮは、例えば図１９を参照して上に示したように少なくとも１つのData Radio Bearers（ＤＲＢ）を確立する。また、そのＰＤＵセッションのＱｏＳフローに対する追加のＤＲＢが後から設定可能である（いつ設定するかはＮＧ－ＲＡＮ次第である）。ＮＧ－ＲＡＮは、様々なＰＤＵセッションに属するパケットを様々なＤＲＢにマッピングする。ＵＥおよび５ＧＣにおけるＮＡＳレベルパケットフィルタが、ＵＬパケットおよびＤＬパケットとＱｏＳフローとを関連付けるのに対し、ＵＥおよびＮＧ－ＲＡＮにおけるＡＳレベルマッピングルールは、ＵＬ ＱｏＳフローおよびＤＬ ＱｏＳフローとＤＲＢとを関連付ける。

図２１は、５Ｇ ＮＲの非ローミング参照アーキテクチャ（non-roaming reference architecture）を示す（TS 23.501 v16.1.0, section 4.23参照）。Application Function（ＡＦ）（例えば、図２０に例示した、５Ｇのサービスをホストする外部アプリケーションサーバ）は、サービスを提供するために３ＧＰＰコアネットワークとやり取りを行う。例えば、トラフィックのルーティングに影響を与えるアプリケーションをサポートするために、Network Exposure Function（ＮＥＦ）にアクセスすること、またはポリシー制御（例えば、ＱｏＳ制御）のためにポリシーフレームワークとやり取りすること（Policy Control Function（ＰＣＦ）参照）である。オペレーターによる配備に基づいて、オペレーターによって信頼されていると考えられるApplication Functionは、関連するNetwork Functionと直接やり取りすることができる。Network Functionに直接アクセスすることがオペレーターから許可されていないApplication Functionは、ＮＥＦを介することにより外部に対する解放フレームワークを使用して関連するNetwork Functionとやり取りする。

図２１は、５Ｇアーキテクチャのさらなる機能単位、すなわち、Network Slice Selection Function（ＮＳＳＦ）、Network Repository Function（ＮＲＦ）、Unified Data Management（ＵＤＭ）、Authentication Server Function（ＡＵＳＦ）、Access and Mobility Management Function（ＡＭＦ）、Session Management Function（ＳＭＦ）、およびData Network（ＤＮ、例えば、オペレーターによるサービス、インターネットアクセス、またはサードパーティーによるサービス）をさらに示す。コアネットワークの機能およびアプリケーションサービスの全部または一部がクラウドコンピューティング環境において展開されかつ動作してもよい。

したがって、本開示では、ＱｏＳ要件に応じたｇＮｏｄｅＢとＵＥとの間の無線ベアラを含むＰＤＵセッションを確立するために、動作時に、ＵＲＬＬＣサービス、ｅＭＭＢサービス、およびｍＭＴＣサービスの少なくとも１つに対するＱｏＳ要件を含む要求を５ＧＣの機能（例えば、ＮＥＦ、ＡＭＦ、ＳＭＦ、ＰＣＦ、ＵＰＦ等）の少なくとも１つに送信する送信部と、動作時に、確立されたＰＤＵセッションを使用してサービスを行う制御回路と、を備える、アプリケーションサーバ（例えば、５ＧアーキテクチャのＡＦ）が提供される。

本開示はソフトウェア、ハードウェア、又は、ハードウェアと連携したソフトウェアで実現することが可能である。上記実施の形態の説明に用いた各機能ブロックは、部分的に又は全体的に、集積回路であるＬＳＩとして実現され、上記実施の形態で説明した各プロセスは、部分的に又は全体的に、一つのＬＳＩ又はＬＳＩの組み合わせによって制御されてもよい。ＬＳＩは個々のチップから構成されてもよいし、機能ブロックの一部または全てを含むように一つのチップから構成されてもよい。ＬＳＩはデータの入力と出力を備えてもよい。ＬＳＩは、集積度の違いにより、ＩＣ、システムＬＳＩ、スーパーＬＳＩ、ウルトラＬＳＩと呼称されることもある。集積回路化の手法はＬＳＩに限るものではなく、専用回路、汎用プロセッサ又は専用プロセッサで実現してもよい。また、ＬＳＩ製造後に、プログラムすることが可能なＦＰＧＡ（Field Programmable Gate Array）や、ＬＳＩ内部の回路セルの接続や設定を再構成可能なリコンフィギュラブル・プロセッサを利用してもよい。本開示は、デジタル処理又はアナログ処理として実現されてもよい。さらには、半導体技術の進歩または派生する別技術によりＬＳＩに置き換わる集積回路化の技術が登場すれば、当然、その技術を用いて機能ブロックの集積化を行ってもよい。バイオ技術の適用等が可能性としてありえる。

本開示は、通信機能を持つあらゆる種類の装置、デバイス、システム（通信装置と総称）において実施可能である。通信装置は無線送受信機（トランシーバー）と処理／制御回路を含んでもよい。無線送受信機は受信部と送信部、またはそれらを機能として、含んでもよい。無線送受信機（送信部、受信部）は、ＲＦ（Ｒａｄｉｏ Ｆｒｅｑｕｅｎｃｙ）モジュールと１または複数のアンテナを含んでもよい。ＲＦモジュールは、増幅器、ＲＦ変調器／復調器、またはそれらに類するものを含んでもよい。通信装置の、非限定的な例としては、電話機（携帯電話、スマートフォン等）、タブレット、パーソナル・コンピューター（ＰＣ）（ラップトップ、デスクトップ、ノートブック等）、カメラ（デジタル・スチル／ビデオ・カメラ等）、デジタル・プレーヤー（デジタル・オーディオ／ビデオ・プレーヤー等）、着用可能なデバイス（ウェアラブル・カメラ、スマートウオッチ、トラッキングデバイス等）、ゲーム・コンソール、デジタル・ブック・リーダー、テレヘルス・テレメディシン（遠隔ヘルスケア・メディシン処方）デバイス、通信機能付きの乗り物又は移動輸送機関（自動車、飛行機、船等）、及び上述の各種装置の組み合わせがあげられる。

通信装置は、持ち運び可能又は移動可能なものに限定されず、持ち運びできない又は固定されている、あらゆる種類の装置、デバイス、システム、例えば、スマート・ホーム・デバイス（家電機器、照明機器、スマートメーター又は計測機器、コントロール・パネル等）、自動販売機、その他ＩｏＴ（Ｉｎｔｅｒｎｅｔ ｏｆ Ｔｈｉｎｇｓ）ネットワーク上に存在し得るあらゆる「モノ（Things）」をも含む。

通信には、セルラーシステム、無線ＬＡＮシステム、通信衛星システム等によるデータ通信に加え、これらの組み合わせによるデータ通信も含まれる。

また、通信装置には、本開示に記載される通信機能を実行する通信デバイスに接続又は連結される、コントローラやセンサー等のデバイスも含まれる。例えば、通信装置の通信機能を実行する通信デバイスが使用する制御信号やデータ信号を生成するような、コントローラやセンサーが含まれる。

また、通信装置には、上記の非限定的な各種装置と通信を行う、あるいはこれら各種装置を制御する、インフラストラクチャ設備、例えば、基地局、アクセスポイント、その他あらゆる装置、デバイス、システムが含まれる。

本開示の一実施例に係る端末は、サイドリンクリソースの端末間協調使用に関する情報を生成する制御回路と、前記情報を他の端末へ送信する送信回路と、を備えてよい。

本開示の一実施例において、前記情報は、前記他の端末が送信を予定しているリソースの情報、前記送信回路による送信を予定しているリソースの情報、前記他の端末に利用を推奨するリソースの情報、及び、前記他の端末に利用を推奨しないリソースの情報の少なくとも１つを含んでよい。

本開示の一実施例において、前記制御回路は、前記情報によって使用可能であることを示したリソースにおいて、前記送信回路による送信を行わなくてよい。

本開示の一実施例において、前記制御回路は、前記情報をサイドリンクのデータチャネルに配置し、前記送信回路は、前記情報がサイドリンクのデータチャネルおいて送信されることを示すサイドリンク制御情報を前記他の端末に送信してよい。

本開示の一実施例において、前記制御回路は、前記情報を第２のサイドリンク制御情報に配置し、前記送信回路は、前記情報が前記第２のサイドリンク制御情報において送信されることを示す前記第２のサイドリンク制御情報または第１のサイドリンク制御情報を前記他の端末に送信してよい。

本開示の一実施例において、前記制御回路は、前記情報をサイドリンクのフィードバックチャネルに配置し、前記情報が前記フィードバックチャネルにおいて送信されることは、前記他の端末との事前の通信に基づいて予約されてよい。

本開示の一実施例において、前記制御回路は、前記情報を第１のサイドリンク制御情報に配置し、前記第１のサイドリンク制御情報に、前記第１のサイドリンク制御情報の送信元である前記端末とは異なる端末向けのリソース割当情報を含めてよい。

本開示の一実施例に係る端末は、サイドリンクリソースの端末間協調使用に関する情報を他の端末から受信する受信回路と、前記情報に基づいて、サイドリンクにおいて送信を行うリソースを決定する制御回路と、を備えてよい。

本開示の一実施例に係るサイドリンク通信制御方法は、第１の端末が、サイドリンクリソースの端末間協調使用に関する情報を送信し、前記情報を受信した第２の端末は、前記情報に基づいて、サイドリンクにおいて送信を行うリソースを決定してよい。

２０２０年８月７日出願の特願２０２０－１３４８５１の日本出願に含まれる明細書、図面および要約書の開示内容は、すべて本願に援用される。

本開示の一実施例は、無線通信システムに有用である。

１００ 基地局
１０１ リソース利用調整情報設定部
１０３ 誤り訂正符号化部
１０４ 変調部
１０６ 送信部
１０７ 受信部
１０９ 復調部
１１０ 誤り訂正復号部
２００ 端末
２０１ 受信部
２０２ 信号分離部
２０３ 復調部
２０３－１ Uu復調部
２０３－２ SL復調部
２０４ 誤り訂正復号部
２０４－１ Uu誤り訂正復号部
２０４－２ SL誤り訂正復号部
２０５ リソース利用調整情報受信部
２０６ リソース利用調整情報生成部
２０７ 誤り訂正符号化部
２０７－１ Uu誤り訂正符号化部
２０７－２ SL誤り訂正符号化部
２０８ 変調部
２０８－１ Uu変調部
２０８－２ SL変調部
２０９ 信号割当部
２１０ 送信部
２１１－１ 1st stage SCI受信部
２１１－２ 2nd stage SCI受信部
２１２－１ 1st stage SCI生成部
２１２－２ 2nd stage SCI生成部

Claims (11)

1. サイドリンクリソースの端末間協調使用に関する情報を生成する制御回路と、
   前記情報を含む第２のサイドリンク制御情報を他の端末へ送信する送受信機と、
   を備え、
   前記第２のサイドリンク制御情報と、前記情報を含まない第３のサイドリンク制御情報はデータチャネルに配置され、
   前記送受信機は、前記第２のサイドリンク制御情報と前記第３のサイドリンク制御情報のうち１つを示すビットフィールドを含む第１のサイドリンク制御情報を、前記他の端末に送信する、
   端末。
2. 前記情報は、前記他の端末が送信を予定しているリソースの情報、前記送受信機による送信を予定しているリソースの情報、前記他の端末に利用を推奨するリソースの情報、及び、前記他の端末に利用を推奨しないリソースの情報の少なくとも１つを含む、
   請求項１に記載の端末。
3. 前記制御回路は、前記情報によって使用可能であることを示したリソースにおいて、前記送受信機による送信を行わない、
   請求項１に記載の端末。
4. 前記制御回路は、前記情報をサイドリンクのデータチャネルに配置し、
   前記送受信機は、前記情報がサイドリンクのデータチャネルおいて送信されることを示すサイドリンク制御情報を前記他の端末に送信する、
   請求項１に記載の端末。
5. 前記制御回路は、前記情報をサイドリンクのフィードバックチャネルに配置し、
   前記情報が前記フィードバックチャネルにおいて送信されることは、前記他の端末との事前の通信に基づいて予約される、
   請求項１に記載の端末。
6. サイドリンクリソースの端末間協調使用に関する情報を含む第２のサイドリンク制御情報を他の端末から受信する送受信機と、
   前記情報に基づいて、サイドリンクにおいて送信を行うリソースを決定する制御回路と、
   を備え、
   前記第２のサイドリンク制御情報と、前記情報を含まない第３のサイドリンク制御情報はデータチャネルに配置され、
   前記送受信機は、前記第２のサイドリンク制御情報と前記第３のサイドリンク制御情報のうち１つを示すビットフィールドを含む第１のサイドリンク制御情報を、前記他の端末から受信する、
   端末。
7. 第１の端末は、サイドリンクリソースの端末間協調使用に関する情報を含む第２のサイドリンク制御情報を送信し、
   前記情報を受信した第２の端末は、前記情報に基づいて、サイドリンクにおいて送信を行うリソースを決定し、
   前記第２のサイドリンク制御情報と、前記情報を含まない第３のサイドリンク制御情報はデータチャネルに配置され、
   前記第１の端末は、前記第２のサイドリンク制御情報と前記第３のサイドリンク制御情報のうち１つを示すビットフィールドを含む第１のサイドリンク制御情報を、前記第２の端末に送信する、
   サイドリンク通信制御方法。
8. サイドリンクリソースの端末間協調使用に関する情報を生成するステップと、
   前記情報を含む第２のサイドリンク制御情報を他の端末へ送信するステップと、
   を含み、
   前記第２のサイドリンク制御情報と、前記情報を含まない第３のサイドリンク制御情報はデータチャネルに配置され、
   前記第２のサイドリンク制御情報と前記第３のサイドリンク制御情報のうち１つを示すビットフィールドを含む第１のサイドリンク制御情報を、前記他の端末に送信する、
   通信方法。
9. サイドリンクリソースの端末間協調使用に関する情報を含む第２のサイドリンク制御情報を他の端末から受信するステップと、
   前記情報に基づいて、サイドリンクにおいて送信を行うリソースを決定するステップと、
   を含み、
   前記第２のサイドリンク制御情報と、前記情報を含まない第３のサイドリンク制御情報はデータチャネルに配置され、
   前記第２のサイドリンク制御情報と前記第３のサイドリンク制御情報のうち１つを示すビットフィールドを含む第１のサイドリンク制御情報を、前記他の端末から受信する、
   通信方法。
10. 端末の処理を制御する集積回路であって、前記処理は、
    サイドリンクリソースの端末間協調使用に関する情報を生成する処理と、
    前記情報を含む第２のサイドリンク制御情報を他の端末へ送信する処理と、
    を含み、
    前記第２のサイドリンク制御情報と、前記情報を含まない第３のサイドリンク制御情報はデータチャネルに配置され、
    前記第２のサイドリンク制御情報と前記第３のサイドリンク制御情報のうち１つを示すビットフィールドを含む第１のサイドリンク制御情報を、前記他の端末に送信する、
    集積回路。
11. 端末の処理を制御する集積回路であって、前記処理は、
    サイドリンクリソースの端末間協調使用に関する情報を含む第２のサイドリンク制御情報を他の端末から受信する処理と、
    前記情報に基づいて、サイドリンクにおいて送信を行うリソースを決定する処理と、
    を含み、
    前記第２のサイドリンク制御情報と、前記情報を含まない第３のサイドリンク制御情報はデータチャネルに配置され、
    前記第２のサイドリンク制御情報と前記第３のサイドリンク制御情報のうち１つを示すビットフィールドを含む第１のサイドリンク制御情報を、前記他の端末から受信する、
    集積回路。

Images