特許 7389109 端末、基地局、送信方法及び受信方法

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

(12)【公報種別】特許公報(B2)

(11)【特許番号】

(24)【登録日】2023-11-20

(45)【発行日】2023-11-29

(54)【発明の名称】端末、基地局、送信方法及び受信方法

(51)【国際特許分類】

   H04W 28/04 20090101AFI20231121BHJP

   H04W 16/14 20090101ALI20231121BHJP

   H04W 72/0446 20230101ALI20231121BHJP

   H04W 72/02 20090101ALI20231121BHJP

【ＦＩ】

H04W28/04 110

H04W16/14

H04W72/0446

H04W72/02

【請求項の数】 18

(21)【出願番号】P 2021508127

(86)(22)【出願日】2020-01-22

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

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

(87)【国際公開日】2020-10-01

【審査請求日】2022-11-02

(31)【優先権主張番号】P 2019064579

(32)【優先日】2019-03-28

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

(73)【特許権者】

【識別番号】514136668

【氏名又は名称】パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカ

【氏名又は名称原語表記】Ｐａｎａｓｏｎｉｃ Ｉｎｔｅｌｌｅｃｔｕａｌ Ｐｒｏｐｅｒｔｙ Ｃｏｒｐｏｒａｔｉｏｎ ｏｆ Ａｍｅｒｉｃａ

(74)【代理人】

【識別番号】110002952

【氏名又は名称】弁理士法人鷲田国際特許事務所

(72)【発明者】

【氏名】布目 知也

(72)【発明者】

【氏名】鈴木 秀俊

(72)【発明者】

【氏名】岩井 敬

(72)【発明者】

【氏名】堀内 綾子

【審査官】石田 信行

(56)【参考文献】

【文献】Qualcomm Incorporated，TxOP Frame Structure for NR unlicensed [online]，3GPP TSG RAN WG1 #95 R1-183410，Internet<URL:http://www.3gpp.org/ftp/tsg_ran/WG1_RL1/TSGR1_95/Docs/R1-1813410.zip>，2018年11月16日

【文献】MediaTek Inc.，Discussion on NR-U configured grant [online]，3GPP TSG RAN WG1 adhoc_NR_AH_1901 R1-1900189，Internet<URL:http://www.3gpp.org/ftp/tsg_ran/WG1_RL1/TSGR1_AH/NR_AH_1901/Docs/R1-1900189.zip>，2019年01月25日

【文献】Panasonic，Configured grant enhancements for NR-U [online]，3GPP TSG RAN WG1 #96 R1-1902854，Internet<URL:http://www.3gpp.org/ftp/tsg_ran/WG1_RL1/TSGR1_96/Docs/R1-1902854.zip>，2019年03月01日

【文献】Panasonic，On NR URLLC enhancements for grant-free transmission [online]，3GPP TSG RAN WG1 #95 R1-1812797，Internet<URL:http://www.3gpp.org/ftp/tsg_ran/WG1_RL1/TSGR1_95/Docs/R1-1812797.zip>，2018年11月16日

(58)【調査した分野】(Int.Cl.，ＤＢ名)

Ｈ０４Ｗ ４／００ － ９９／００

Ｈ０４Ｂ ７／２４ － ７／２６

３ＧＰＰ ＴＳＧ ＲＡＮ ＷＧ１－４

ＳＡ ＷＧ１－４

ＣＴ ＷＧ１，４

(57)【特許請求の範囲】

【請求項1】

上りリンクデータのデータサイズ及び再送の少なくとも一方に応じて、前記上りリンクデータに対して設定される時間リソースの第１の終了位置を第２の終了位置に設定する制御回路と、
前記第２の終了位置に基づいて、前記上りリンクデータを送信する送信回路と、
を具備する端末。

【請求項2】

前記制御回路は、設定された前記データサイズよりも送信される前記データサイズが小さい場合、及び、前記上りリンクデータの再送の場合の少なくとも一方において、前記第１の終了位置を前記第２の終了位置に設定する、
請求項１に記載の端末。

【請求項3】

前記時間リソースはシンボル単位のリソースであり、
前記第２の終了位置に対応するシンボルは、前記上りリンクデータに設定された少なくとも一つの送信開始シンボル候補のｎシンボル（ただし、ｎは１以上の整数）前のシンボル、及び、前記第１の終了位置に対応するシンボルの何れかである、
請求項１に記載の端末。

【請求項4】

前記第２の終了位置に対応するシンボルは、前記送信される上りリンクデータの符号化率に基づいて決定される、
請求項２に記載の端末。

【請求項5】

前記第２の終了位置に対応するシンボルは、前記送信される上りリンクデータと、前記上りリンクデータに多重される信号とに基づく符号化率に基づいて決定される、
請求項２に記載の端末。

【請求項6】

前記制御回路は、前記上りリンクデータに多重される信号の有無に基づいて、前記第１の終了位置を前記第２の終了位置に変更するか否かを決定する、
請求項１に記載の端末。

【請求項7】

前記制御回路は、前記送信される上りリンクデータのデータサイズが前記設定されたデータサイズである第１のケースと、前記送信される上りリンクデータのデータサイズが前記設定されたデータサイズより小さい第２のケースとで、上りリンクにおける送信開始タイミングのオフセットを異ならせる、
請求項１に記載の端末。

【請求項8】

前記オフセットは、前記第１のケースよりも前記第２のケースの方が短い、
請求項７に記載の端末。

【請求項9】

前記オフセットは、前記第２のケースよりも前記第１のケースの方が短い、
請求項７に記載の端末。

【請求項10】

前記オフセットは、前記時間リソース内における前記上りリンクデータの送信開始位置候補に応じて決定される、
請求項７に記載の端末。

【請求項11】

前記設定された時間リソース内の最初の前記送信開始位置候補では、前記オフセットは、前記第２のケースよりも前記第１のケースの方が短く、
前記設定された時間リソース内の前記最初の送信開始位置候補と異なる送信開始位置候補では、前記オフセットは、前記第１のケースよりも前記第２のケースの方が短い、
請求項１０に記載の端末。

【請求項12】

前記送信開始位置候補の前記オフセットは、上りリンクの使用状況に応じて決定される、
請求項１０に記載の端末。

【請求項13】

前記オフセットは、前記上りリンクデータの送信タイミングに応じて決定される、
請求項７に記載の端末。

【請求項14】

前記オフセットは、前記上りリンクデータに対する応答信号に応じて決定される、
請求項７に記載の端末。

【請求項15】

前記第１のケースは前記上りリンクデータの初回送信時であり、前記第２のケースは前記上りリンクデータの再送時である、
請求項７に記載の端末。

【請求項16】

上りリンクデータのデータサイズ及び再送の少なくとも一方に応じて、前記上りリンクデータに対して設定される時間リソースの第１の終了位置を第２の終了位置に設定する制御回路と、
前記第２の終了位置に基づいて、前記上りリンクデータを受信する受信回路と、
を具備する基地局。

【請求項17】

端末が、
上りリンクデータのデータサイズ及び再送の少なくとも一方に応じて、前記上りリンクデータに対して設定される時間リソースの第１の終了位置を第２の終了位置に設定し、
前記第２の終了位置に基づいて、前記上りリンクデータを送信する、
送信方法。

【請求項18】

基地局が、
上りリンクデータのデータサイズ及び再送の少なくとも一方に応じて、前記上りリンクデータに対して設定される時間リソースの第１の終了位置を第２の終了位置に設定し、
前記第２の終了位置に基づいて、前記上りリンクデータを受信する、
受信方法。

【発明の詳細な説明】

【技術分野】

【0001】

本開示は、端末、基地局、送信方法及び受信方法に関する。

【背景技術】

【0002】

3rd Generation Partnership Project（3GPP）では、第5世代移動通信システム（5G：5th Generation mobile communication sysmtems）の実現に向けて、Release 15 NR（New Radio access technology）の仕様策定が完了した。NRでは、モバイルブロードバンドの高度化（eMBB: enhanced Mobile Broadband）の基本的な要求条件である高速及び大容量と合わせ、超高信頼低遅延通信（URLLC: Ultra Reliable and Low Latency Communication）を実現する機能をサポートしている（例えば、非特許文献１－４を参照）。

【0003】

Release 15 NRでは、上りリンクデータ（例えば、PUSCH: Physical Uplink Control Channel）の送信に対して「Configured grant送信」（又は、Grant-free送信と呼ぶ）をサポートする。Configured grant送信では、端末（又は、user equipment（UE）とも呼ぶ）は、予め設定された送信タイミング及び無線リソースに基づいて半静的に送信を継続する。

【0004】

また、Release 16 NRでは、アンライセンス周波数帯（又は、免許不要帯域とも呼ぶ）において、NRの無線アクセス方式に基づいた通信を行うNR-Unlicensed（NR-U）が検討されている。アンライセンス周波数帯では、各装置は、送信前に、他のシステム又は端末等が無線チャネルを使用しているか否かを確認するキャリアセンス（例えば、Listen Before Talk（LBT）とも呼ぶ）を行う。

【先行技術文献】

【非特許文献】

【0005】

【文献】3GPP TS 38.211 V15.3.0, "NR; Physical channels and modulation (Release 15)," September 2018

【文献】3GPP TS 38.212 V15.3.0, "NR; Multiplexing and channel coding (Release 15)," September 2018

【文献】3GPP TS 38.213 V15.3.0, "NR; Physical layer procedure for control (Release 15)," September 2018

【文献】3GPP TS 38.214 V15.3.0, "NR; Physical layer procedures for data (Release 15)," September 2018

【発明の概要】

【0006】

しかしながら、免許不要帯域における上りリンク信号の送信方法について十分に検討されていない。

【0007】

本開示の非限定的な実施例は、免許不要帯域における上りリンクリソースの利用効率を向上できる端末、基地局、送信方法及び受信方法の提供に資する。

【0008】

本開示の一実施例に係る端末は、上りリンクデータのデータサイズ及び再送の少なくとも一方に応じて、前記上りリンクデータに対して設定される時間リソースの第１の終了位置を第２の終了位置に設定する制御回路と、前記第２の終了位置に基づいて、前記上りリンクデータを送信する送信回路と、を具備する。

【0009】

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

【0010】

本開示の一実施例によれば、免許不要帯域における上りリンクリソースの利用効率を向上できる。

【0011】

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

【図面の簡単な説明】

【0012】

【図1】Multiple starting symbolの一例を示す図

【図2】基地局の一部の構成を示すブロック図

【図3】端末の一部の構成を示すブロック図

【図4】基地局の構成を示すブロック図

【図5】端末の構成を示すブロック図

【図6】基地局及び端末の動作例を示すシーケンス図

【図7】PUSCHの送信例を示す図

【図8】time offsetの設定例を示す図

【図9】実施の形態２の決定方法１に係るtime offsetの設定例を示す図

【図10】time offsetの設定例を示す図

【図11】実施の形態２の決定方法３に係るtime offsetの設定例を示す図

【図12】実施の形態２の決定方法５に係るtime offsetの設定例を示す図

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

【0013】

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

【0014】

［Configured grant送信］
Release 15 NRの上りリンクデータのConfigured grant送信には、「Configured grant type 1送信」と「Configured grant type 2送信」とがある。

【0015】

Configured grant type 1送信では、例えば、Modulation and Coding Scheme（MCS）、無線リソース割当情報（例えば、時間リソース又は周波数リソースの割り当て）、送信タイミング、及び、hybrid automatic repeat request（HARQ）プロセス数等のConfigured grant設定情報が端末固有の上位レイヤ信号（例えば、RRC: Radio Resource Comtrol）によって設定される。端末は、上りリンクデータが発生した場合、基地局（例えば、gNBとも呼ぶ）から下り制御チャネル（例えば、PDCCH：Physical Downlink Control Channel）によるUL grant（換言すると、動的な上りリンクデータのスケジューリング情報）無しに、予め設定されたMCS及び無線リソース等のConfigured grant設定情報を用いてPUSCHを送信する。

【0016】

Configured grant type 2送信では、基地局からのPDCCH（例えば、DCI：Downlink Control Information）により、Configured grant送信がActivation又はReleaseされる。Configured grant type 2送信では、送信タイミング及びHARQプロセス数等は、Configured grant type 1送信と同様に、端末固有の上位レイヤ信号によって設定される。一方、Configured grant type 2送信では、MCS及び無線リソース割当情報等は、「Activation用DCI」によって設定される。端末は、上りリンクデータが発生した場合、上位レイヤ信号及びActivation用DCIによって設定されたMCS及び無線リソース等のConfigured grant設定情報を半永久的に用いて（換言するとUL grant無しに）、PUSCHを送信する。

【0017】

また、NR-Uにおいても、Configured grant送信をサポートすることが検討されている。NR-UにおけるConfigured grant送信では、例えば、アンライセンス周波数帯に特有の制約（例えば。LBTの動作）に合わせるため、Release 15 NRからの機能拡張が検討されている。

【0018】

［CBG単位の再送］
Release 15 NRでは、コードブロックグループ（CBG：Code Block Group）毎の再送制御が導入された。

【0019】

CBGは、１つ以上のコードブロック（CB：Code Block）をグループ化して構成される。また、トランスポートブロック（TB：Transport Block）は１つ以上のCBGから構成される。例えば、端末は、上りリンクデータをCBG単位で再送することにより、TB（例えば、全てのCBG）単位の再送よりも送信するデータ量を低減し、再送効率（換言すると、リソース利用効率）を向上できる。

【0020】

［NR-UにおけるConfigured grant送信の再送制御］
NR-Uでは、Configured grant送信の再送制御に関して、例えば、UL grantによる再送制御に加え、PUSCHに対する明示的なHARQ-ACK情報（以下、単にHARQ-ACKとも呼ぶ）をフィードバックするUL grant無しの再送制御が議論されている。明示的なHARQ-ACKによる再送制御では、例えば、再送用の上りリンクデータのMCS及び無線リソース割当は、初回送信時と同様となり得る。

【0021】

また、例えば、TB単位の再送では、UL grantによる再送、及び、HARQ-ACKによる再送の両方が導入されることが合意されている。一方、CBG単位の再送では、UL grantによる再送は導入されるが、HARQ-ACKによる再送が導入されるかは現在議論中である。

【0022】

［Multiple starting symbol］
NR-U configured grantでは、slot内に複数の送信開始シンボル（multiple starting symbol）を導入することが検討されている。multiple starting symbolの導入により、例えば、slotの先頭付近のシンボルにおいてLBTに失敗した場合でも、端末は、slotの途中に設定された送信開始シンボルから上りリンク送信を開始できるので、端末の送信機会を増加できる。multiple starting symbolの位置には、複数の候補（例えば、starting symbol候補（starting symbol candidate）と呼ぶ）が設定され、例えば、基地局から端末へシグナリングされてもよく、仕様において予め決められてもよい。

【0023】

図１は、multiple starting symbolの一例を示す。図１は、一例として、configured grant送信に設定された１slot内のシンボル構成を示す。

【0024】

図１では、例えば、スロット内に３個のstarting symbol候補が設定される。例えば、シンボル#0がstarting symbol候補#0に設定され、シンボル#5がstarting symbol候補#1に設定され、シンボル#10がstarting symbol候補#2に設定されている。なお、starting symbol候補は、図１に示す例に限定されない。

【0025】

また、例えば、図１に示す例では、slot内のシンボル#0～#3においてLBTに失敗している（換言すると、チャネルがbusy状態である）。また、図１に示す例では、slot内のシンボル#5（又は、シンボル#4）においてLBTに成功している（換言すると、チャネルがidle状態である）。図１では、端末は、starting symbol候補のうち、チャネルが空いているシンボル#5（starting symbol候補#1）から、上りリンクデータ（PUSCH）の送信を開始できる。

【0026】

上述したような、NR-Uにおいて、複数の端末におけるリソース利用効率を向上する方法については検討の余地がある。そこで、本開示の一実施例では、NR-Uにおける上りリンクデータの送信方法（又は再送方法）について説明する。

【0027】

（実施の形態１）
［通信システムの概要］
本開示の一態様に係る通信システムは、図２及び図４に示す基地局１００（例えば、gNB）、及び、図３及び図５に示す端末２００（例えば、UE）及びを備える。

【0028】

図２は本開示の一態様に係る基地局１００の一部の構成例を示すブロック図である。図２に示す基地局１００において、受信制御部１０４（例えば、制御回路に相当する）は、端末２００に設定されたデータサイズ（例えば、CB数又はCBG数等）よりも端末２００が送信する上りリンクデータのデータサイズが小さい場合、又は上りリンクデータの再送の場合の少なくとも一方において、上りリンクデータに対して設定される時間リソースの第１の終了位置（例えば、ending symbol）を第２の終了位置（例えば、ending symbol）に変更する。受信部１０１（例えば、受信回路に相当する）は、第２の終了位置に基づいて、上りリンクデータを受信する。

【0029】

図３は本開示の一態様に係る端末２００の一部の構成例を示すブロック図である。図３に示す端末２００において、送信制御部２０６（例えば、制御回路に相当する）は、設定されたデータサイズ（例えば、CB数又はCBG数）よりも送信される上りリンクデータのデータサイズが小さい場合、又は上りリンクデータの再送の場合の少なくとも一方において、上りリンクデータに対して設定される時間リソースの第１の終了位置を第２の終了位置に変更する。送信部２１０（例えば、送信回路に相当する）は、第２の終了位置に基づいて、上りリンクデータを送信する。

【0030】

［基地局の構成］
図４は、本開示の一態様に係る基地局１００の構成例を示すブロック図である。図４において、基地局１００は、受信部１０１と、UCI（Uplink Control Information）復調・復号部１０２と、制御情報保持部１０３と、受信制御部１０４と、データ復調・復号部１０５と、スケジューリング部１０６と、データ生成部１０７と、DFI生成部１０８と、符号化・変調部１０９と、送信部１１０と、を有する。

【0031】

受信部１０１は、端末２００から送信された信号をアンテナを介して受信し、受信信号に対してダウンコンバート又はＡ／Ｄ変換等の受信処理を行い、受信処理後の受信信号をUCI復調・復号部１０２及びデータ復調・復号部１０５へ出力する。

【0032】

UCI復調・復号部１０２は、受信部１０１から入力される受信信号に含まれるの上り制御信号（例えば、UCI）に対して復調及び復号を行い、復号後のUCIを、制御情報保持部１０３及び受信制御部１０４に出力する。

【0033】

制御情報保持部１０３は、各端末２００に関するConfigured grant設定情報（例えば、MCS、及び、無線リソース割当情報等）を保持し、保持した情報を必要に応じて各構成部（例えば、受信制御部１０４、データ復調・復号部１０５、スケジューリング部１０６又はDFI生成部１０８等）に出力する。また、制御情報保持部１０３は、UCI復調・復号部１０２から入力される制御情報（UCI）を保持し、保持した制御情報を必要に応じてスケジューリング部１０６に出力する。

【0034】

受信制御部１０４は、制御情報保持部１０３から入力される制御情報、及び、UCI復調・復号部１０２から入力されるUCIに基づいて、上りリンクデータに関する情報（例えば、送信されたCBG数又は後述するending symbol等）を決定し、決定した情報をデータ復調・復号部１０５に出力する。

【0035】

データ復調・復号部１０５は、制御情報保持部１０３から入力される制御情報、及び、受信制御部１０４から入力される上りリンクデータに関する情報に基づいて、受信部１０１から入力される受信信号に含まれる上りリンクデータに対して復調及び復号を行い、上りリンクデータの復号結果をスケジューリング部１０６及びDFI生成部１０８に出力する。上りリンクデータの復号結果には、例えば、TB単位、CBG数単位又はCBG単位の復号成功又は失敗を示す情報が含まれてよい。

【0036】

スケジューリング部１０６は、例えば、制御情報保持部１０３から入力される制御情報（例えば、端末２００がバッファに保持するデータ種別又はデータ量、又は、Configured grant設定情報等）に基づいて、データ生成部１０７に対して、送信データの生成（又は送信データの送信）を指示する。また、スケジューリング部１０６は、データ復調・復号部１０５から入力される上りリンクデータの復号結果に基づいて、上りリンクデータの再送を制御する。例えば、スケジューリング部１０６は、上りリンクデータに対して、明示的なHARQ-ACK情報による再送制御を行う場合、DFI生成部１０８に対して、DFI生成（又はDFI送信）を指示する。

【0037】

データ生成部１０７は、スケジューリング部１０６からの指示に従って、送信データを生成し、生成した送信データを符号化・変調部１０９に出力する。

【0038】

DFI生成部１０８は、スケジューリング部１０６からの指示に従って、データ復調・復号部１０５から入力される上りリンクデータの復号結果（例えば、HARQ-ACK）、及び、制御情報保持部１０３から入力されるConfigured grant設定情報に基づいて、DFI（例えば、DFIのペイロード）を生成する。DFI生成部１０８は、生成したDFIを符号化・変調部１０９に出力する。

【0039】

符号化・変調部１０９は、データ生成部１０７から入力される送信データ、及び、DFI生成部１０８から入力されるDFIを符号化及び変調し、変調後の信号（シンボル系列）を送信部１１０に出力する。

【0040】

送信部１１０は、符号化・変調部１０９から入力される信号に対してＤ／Ａ変換、アップコンバート又は増幅等の送信処理を行い、送信処理により得られた無線信号をアンテナから端末２００へ送信する。

【0041】

［端末の構成］
図５は、本開示の一態様に係る端末２００の構成例を示すブロック図である。図５において、端末２００は、受信部２０１と、チャネル状態推定部２０２と、復調・復号部２０３と、再送判定部２０４と、制御情報保持部２０５と、送信制御部２０６と、データ生成部２０７と、UCI生成部２０８と、符号化・変調部２０９と、送信部２１０と、を有する。

【0042】

受信部２０１は、アンテナを介して受信した受信信号に対してダウンコンバート又はＡ／Ｄ変換等の受信処理を行い、受信信号をチャネル状態推定部２０２及び復調・復号部２０３に出力する。

【0043】

チャネル状態推定部２０２は、受信部２０１から入力される受信信号に基づいて、例えば、キャリアセンス（例えば、LBT）を実行し、チャネル状態がbusyであるか、idleであるかを判定する。チャネル状態推定部２０２は、判定したチャネル状態（換言すると、LBT結果）を示す情報を送信制御部２０６に出力する。また、チャネル状態推定部２０２は、例えば、CSI（Channel state information）推定を行い、CSIをUCI生成部２０８に出力する。

【0044】

復調・復号部２０３は、受信部２０１から入力される受信信号を復調及び復号する。復調・復号部２０３は、復号後の信号（例えば、DFI）を再送判定部２０４に出力する。また、復調・復号部２０３は、復号結果に含まれる制御情報（例えば、Configured grant設定情報）を抽出し、制御情報保持部２０５に出力する。

【0045】

再送判定部２０４は、復調・復号部２０３から入力される信号（例えば、DFI）に基づいて、再送するデータ（例えば、再送するCBG）を判定し、判定結果を示す再送情報を送信制御部２０６に出力する。また、再送判定部２０４は、例えば、CBG毎の判定結果を示す情報（例えば、HARQ-ACK）をUCI生成部２０８に出力する。

【0046】

制御情報保持部２０５は、復調・復号部２０３から入力される制御情報（例えば、Configured grant設定情報）を保持し、保持した制御情報を、必要に応じて、各構成部（例えば、送信制御部２０６又は符号化・変調部２０９）に出力する。

【0047】

送信制御部２０６は、制御情報保持部２０５から入力されるConfigured grant設定情報（例えば、starting symbol位置の候補、設定されたTBサイズ（又はCB数）、又は、設定されたシンボル数等）、送信CB数、及び、チャネル状態推定部２０２から入力されるチャネル状態（例えば、busy状態又はidle情報）に基づいて、上りリンクデータ（例えば、PUSCH）送信の開始位置（例えば、starting symbol）及び終了位置（例えば、ending symbol）を決定する。送信制御部２０６は、決定した情報を含むリソース情報を符号化・変調部２０９に出力する。

【0048】

また、送信制御部２０６は、再送判定部２０４から入力される再送情報に基づいて、データ生成指示（例えば、初送及び再送の種別、又は、送信CB情報等）を決定し、データ生成部２０７に出力する。

【0049】

また、送信制御部２０６は、制御情報保持部２０５から入力されるUCI設定、Configured grant設定情報、及び、再送判定部２０４から入力される再送情報に基づいて、UCI生成指示（例えば、どのUCIを送信するか、又は、どのHARQ processにおいてどのCBGを送信するかを示す情報等）をUCI生成部２０８に出力する。

【0050】

データ生成部２０７は、送信制御部２０６から入力されるデータ生成指示に基づいて、送信データ（例えば、PUSCH）を生成し、符号化・変調部２０９に出力する。

【0051】

また、データ生成部２０７は、初送及び再送の種別が再送の場合、初送時と同じデータを出力してもよく、送信CB情報に基づいて、再送するCBに対応する送信データを出力してもよい。

【0052】

UCI生成部２０８は、送信制御部２０６から入力されるUCI生成指示、チャネル状態推定部２０２から入力されるCSI、及び、再送判定部２０４から入力されるHARQ-ACKに基づいて、UCIを生成し、符号化・変調部２０９に出力する。UCIには、例えば、送信されるデータ（例えば、CB又はCBG等）に関する情報、端末２００がバッファに保持するデータ種別又はデータ量等が含まれてよい。

【0053】

符号化・変調部２０９は、送信制御部２０６から入力されるリソース情報、及び、制御情報保持部２０５から入力されるConfigured grant設定情報に基づいて、データ生成部２０７から入力される送信データ、及び、UCI生成部２０８から入力されるUCIを符号化及び変調し、変調後の信号を送信部２１０に出力する。

【0054】

送信部２１０は、符号化・変調部２０９から入力される信号に対してＤ／Ａ変換、アップコンバート又は増幅等の送信処理を行い、送信処理により得られた無線信号をアンテナから基地局１００へ送信する。

【0055】

［基地局１００及び端末２００の動作］
以上の構成を有する基地局１００及び端末２００における動作例について説明する。

【0056】

図６は基地局１００及び端末２００の動作を示すシーケンス図である。

【0057】

基地局１００は、例えば、端末２００のスケジューリング情報に基づいて、Configured grant設定情報を生成する（ＳＴ１０１）。基地局１００は、Configured grant設定情報を端末２００へ通知する（ＳＴ１０２）。端末２００は、基地局１００から通知されるConfigured grant設定情報を取得する（ＳＴ１０３）。

【0058】

端末２００は、例えば、上りリンクデータが発生した場合、LBTを実行する（ＳＴ１０４）。端末２００は、LBTに成功した場合（換言すると、無線チャネルがidleの場合）、Configured grant設定情報、及び、LBT結果（例えば、LBTに成功したシンボル）に基づいて、上りリンクデータを配置する時間リソースであるシンボル（換言すると、データサイズ又は送信開始位置等）を決定する。

【0059】

端末２００は、決定した時間リソースにおいて上りリンクデータを送信する（ＳＴ１０５）。

【0060】

基地局１００は、上りリンクデータを受信し（ＳＴ１０６）、例えば、上りリンクデータに対するHARQ-ACK（例えば、ACK又はNACK）を含むDFIを端末２００へ送信（換言すると、フィードバック）する（ＳＴ１０７）。端末２００は、受信したDFIに含まれるHARQ-ACKに基づいて、上りリンクデータに対する再送制御（例えば、再送するCB又はCBGの決定）を行う（ＳＴ１０８）。例えば、端末２００は、再送する上りリンクデータ（CB又はCBG）の送信開始位置（starting symbol）及び送信終了位置（ending symbol）を決定する。

【0061】

端末２００は、上りリンクデータの再送前に、LBTを実行する（ＳＴ１０９）。端末２００は、LBTに成功した場合（換言すると、無線チャネルがidleの場合）、LBT結果（例えば、LBTに成功したシンボル）に基づいて、上りリンクデータを配置する時間リソースであるシンボル（換言すると、データサイズ又は送信開始位置等）を決定する。

【0062】

端末２００は、決定した時間リソースにおいて上りリンクデータを再送する（ＳＴ１１０）。

【0063】

基地局１００は、再送された上りリンクデータを受信する（ＳＴ１１１）。この際、基地局１００は、例えば、端末２００と同様、再送された上りリンクデータ（CB又はCBG）の送信開始位置（starting symbol）及び送信終了位置（ending symbol）を決定する。

【0064】

［Multiple starting symbol適用時の符号化率］
ここで、例えば、図１に示すようなMultiple starting symbolが適用される場合の符号化率について説明する。

【0065】

例えば、Multiple starting symbolが適用される場合、端末２００に設定（configure）されたstarting symbol（例えば、slot内の先頭シンボル）よりも後のシンボルから上りリンクデータ（例えば、PUSCH）の送信が開始される場合がある。換言すると、例えば、LBTの結果に応じて、PUSCHのstarting symbolが変更（換言すると、後ろ倒し又はシフト）される場合がある。

【0066】

この場合、例えば、PUSCHのstarting symbolの後ろ倒しに応じて、PUSCHのending symbolも後ろ倒しされる場合、当該PUSCHが後ろ倒しして配置されるシンボルには、他の端末用のリソースは割り当てられない。換言すると、端末２００におけるLBT結果に応じてPUSCHが配置されるシンボルが後ろ倒しされる可能性があるので、後ろ倒しになる可能性のあるシンボルは他の端末において空けることになる。このため、PUSCHのstarting symbolの後ろ倒しに応じて、PUSCHのending symbolも後ろ倒しされる場合には、リソースの利用効率が低下する。

【0067】

よって、starting symbolの開始位置が変更されても、PUSCHが配置されるending symbolは後ろ倒ししないことが想定される。

【0068】

ending symbolが後ろ倒しされない場合、PUSCHが配置されるstarting symbolの後ろ倒しにより、PUSCHのシンボルのデータはパンクチャされることが想定される。図１では、シンボル#0～#3では、LBT結果がbusyであるので、PUSCHのstarting symbolは、例えば、次のstarting symbol候補であるシンボル#5に後ろ倒しされる。また、図１では、PUSCHのending symbolは、後ろ倒しされず、例えば、シンボル#13である。換言すると、図１に示すシンボル#0～#4のPUSCHはパンクチャされる。あるいは、図１において、PUSCHがマッピングされるシンボルを全体的に5シンボル後ろ倒しし、シンボル#9～#13にマッピングされることになっていたPUSCHがパンクチャされても良い。

【0069】

この場合、端末２００では、LBT結果に応じて、TBサイズを選択し直し、TBサイズに応じたデータの作成、符号化又はレートマッチング等を行う十分な処理時間が無い可能性が高い。よって、端末２００は、LBTの結果、後ろ倒しになって送信できないデータ（例えば、図１では、シンボル#0～#4に配置されたPUSCH）は、破棄されることが想定される。

【0070】

データが破棄される場合、端末２００が送信するPUSCHは、基地局１００において想定する符号化率よりも高い符号化率で送信されることになる。このため、基地局１００では端末２００が送信するPUSCHを正しく復号できない可能性がある。よって、Multiple starting symbolが適用され、starting symbolを後ろ倒しした場合には、PUSCHの再送が発生する可能性が高い。

【0071】

例えば、図１に示す例では、１スロット内の14シンボルに配置されるPUSCHの送信が基地局１００によってスケジューリング（換言すると、設定）されているのに対して、LBT結果によって、端末２００は、9シンボル（シンボル#5～#13）に配置されるPUSCHを送信する。よって、図１に示す例では、端末２００から実際に送信されるPUSCHの符号化率は、基地局１００によってスケジューリングされたPUSCHの符号化率の14/9倍になる。

【0072】

［再送時のリソース割当］
HARQ-ACKによる再送は、例えば、Configured grantリソースにおいて行われる。例えば、再送時に使用されるリソースのサイズは、初送時に使用されるリソースと同じでもよい。ただし、再送時に使用されるリソースは、初送時に使用されるリソースと比較して少なくてもよい場合もあり得る。

【0073】

図７は、PUSCHのCBG単位の再送処理の一例を示す。図７では、例えば、初送時のCBG数が4CBGであり、送信に失敗したCBGが2CBGである場合について説明する。なお、各CBGに含まれるCB数は同じとし、CBサイズも同じとする。

【0074】

図７においてCBG単位の再送を行う場合、再送時に送信されるCBG数は2CBGとなる。よって、再送時（例えば、2CBGs）において、初送時（例えば、4CBGs）に設定された符号化率と同じ符号化率で送信するには、リソースは、初送時に設定されたConfigured grantリソース（図７では14シンボル）の半分程度でよい。

【0075】

これに対して、図７に示すように、再送時（例えば、2CBGs）において、端末２００が、設定されたConfigured grantリソース（換言すると、初送時に使用されるリソース。例えば、14シンボル）で2CBGのデータを送信する場合、再送されるデータに対して割り当てられるリソースのサイズは、基地局１００が想定するサイズと比較して大きすぎる（換言すると、過剰なサイズである）。例えば、図７に示す例では、再送時のPUSCHの符号化率は、設定された符号化率の1/2になる。このため、Configured grantリソースにおけるリソースの利用効率が低下する。

【0076】

そこで、本実施の形態では、端末２００は、Configured grant送信において、送信されるデータのサイズ、又は、送信種別（例えば、初送及び再送の何れか）に応じて、データが配置されるending symbolを可変に設定する。

【0077】

例えば、端末２００は、例えば、Configured grant設定されたCB数（換言すると、データサイズ）よりも実際に送信されるPUSCHのCB数（以下、送信CB数とも呼ぶ）が少ない場合、又は、PUSCHの再送の場合、Configured grant設定されるPUSCHの時間リソースの終了位置（例えば、ending symbol）を異なるending symbolに変更する。よって、本実施の形態では、データが配置されるending symbolは、Configured grant設定において設定されるending symbol（例えば、図７ではスロットの最後尾のシンボル#13）と異なる場合があり得る。

【0078】

以下、ending symbolの決定方法について説明する。なお、例えば、基地局１００の受信制御部１０４及び端末２００の送信制御部２０６は、後述するending symbol（換言すると、時間リソースの終了位置）の決定方法を共有し、共有する方法に基づいて、PUSCHが配置されるending symbolを決定すればよい。

【0079】

＜決定方法１＞
決定方法１では、端末２００は、例えば、実際に送信されるデータ（例えば、PUSCH）の符号化率に基づいて、実際に送信されるデータを配置する時間リソースのending symbol（換言すると、変更後のending symbol）を決定する。

【0080】

例えば、端末２００は、Configured grant設定に基づく符号化率を満たすシンボル数（以下、「必要シンボル数」と呼ぶ）を決定する。例えば、必要シンボル数は、次式(1)から決定されてよい。

【数1】

【0081】

式(1)の右辺は、「{(送信CB数) / (設定CB数)} * (設定シンボル数) 」以上の最小の整数を返すceil関数である。ここで、「設定CB数」、及び、「設定シンボル数」は、例えば、Configured grant設定として、RRCシグナリング又はPDCCH（例えば、DCI）によって端末２００に設定される値を表す。また、「送信CB数」は、端末２００から実際に送信されるCB数を表し、例えば、Configured grant-UCI（CG-UCI）によって端末２００から基地局１００へ通知される値である。

【0082】

CG-UCIは、例えば、NR-U configured grantのPUSCH送信のための制御情報（例えば、HARQ process ID等）であり、PUSCHと併せて端末２００から基地局１００へ送信される。

【0083】

一例として、式(1)において、「設定CB数」が4CBであり、「送信CB数」が2CBであり、「設定シンボル数」が14シンボルの場合（例えば、図７を参照）、PUSCHの送信に対する「必要シンボル数」は7シンボルとなる。なお、式(1)に設定されるパラメータはこれらに限定されない。

【0084】

また、例えば、変更後のending symbolの位置は、端末２００に設定されたstarting symbol候補のｎシンボル前（ｎは１以上の整数）のシンボル、及び、Configured grant設定されたending symbol（例えば、configured ending symbol）の何れかに設定されてよい。

【0085】

ここで、「ｎ」は、例えば、starting symbol候補の前に設定されるLBT用のギャップに応じて決定されてもよい。例えば、LBT用ギャップが短いほど、ｎの値は小さく設定されてよい。これは、端末２００の送信の後に他の端末が送信する場合には、starting symbolから送信を開始することが想定されるため、端末２００はstarting symbolの直前まで送信を継続したほうが符号化率を低くでき、基地局１００においてPUSCHの受信成功の確率を向上できるためである。そのため、ギャップが必要なければ、ｎは１が望ましい。

【0086】

端末２００は、例えば、LBT結果に基づいて決定されるstarting symbol候補（端末２００がPUSCH送信を開始するシンボル）に基づいて、例えば、式(1)に示す必要シンボル数を満たし、かつ、PUSCHの送信に使用されるシンボル数がより少なくなるように（例えば、最小になるように）、ending symbol位置を決定してもよい。これにより、端末２００は、PUSCHに割り当てる時間リソースを低減しつつ、Configured grant設定における符号化率を満たして、PUSCHを送信できる。

【0087】

また、変更後のending symbolの位置がstarting symbol候補より前に設定されることにより、例えば、他の端末２００がstarting symbol候補からPUSCHを送信できる。これにより、リソース利用効率を向上できる。

【0088】

決定方法１では、端末２００は、PUSCHのstarting symbolから式(1)によって算出される必要シンボル数分の位置（換言すると、starting symbol + 必要シンボル数）をending symbolの位置に設定せずに、他のstarting symbol候補のnシンボル前のsymbolをending symbolの位置に設定する。例えば、「starting symbol + シンボル数」が、後続するstarting symbol候補のnシンボル前のsymbolよりも前の位置に対応する場合でも、端末２００は、後続するstarting symbol候補のnシンボル前のsymbolをending symbolに設定する。

【0089】

ここで、他の端末は、starting symbol候補の位置からPUSCHの送信を開始する。そのため、端末２００がstarting symbol候補のnシンボル前のsymbolよりも前において、途中でPUSCHの送信を止めたとしても、残りのリソースは他の端末において使用できないので、リソース利用効率の向上にはつながらない。よって、端末２００は、starting symbol候補のnシンボル前のsymbolまでPUSCHの送信を継続させることにより、PUSCHの符号化率を低下させ、基地局１００においてPUSCHの受信成功の確率を向上できる。これにより、リソース利用効率を低下させることなく、PUSCH送信の成功する確率を上げられる。

【0090】

なお、端末２００は、端末２００に設定されたending symbol（例えば、configured ending symbol）までPUSCHを送信しても必要シンボル数を満たさない場合、実際のending symbolを、設定されたending symbolに設定すればよい。

【0091】

また、端末２００は、（starting symbol +必要シンボル数）に対応するシンボルをending symbolの位置に設定してもよい。

【0092】

また、基地局１００は、端末２００と同様の処理によって、端末２００が送信するPUSCHのending symbolを決定し、決定したending symbolに基づいて、PUSCHを受信する。

【0093】

このように、決定方法１では、PUSCHのending symbolは、starting symbol候補の位置、及び、送信CB数等の基地局１００と端末２００との間において既知の情報（換言すると、共有情報）に基づいて一意に決定される。これにより、基地局１００及び端末２００は、追加のシグナリング無しでending symbol位置を変更できる。

【0094】

また、決定方法１によれば、基地局１００が設定したデータの符号化率（換言すると、基地局１００が意図する符号化率）を維持したうえで、PUSCH送信に使用されるシンボル数を低減することにより、端末２００のデータ送信に影響を与えず、他の端末が利用できるリソースを増加できるので、リソースの利用効率を向上できる。

【0095】

なお、決定方法１－１においてPUSCHのending symbolの決定は、式(1)に基づく方法に限らず、例えば、端末２００がPUSCHに対するNACKの数をカウントして、送信CB数（換言sうると、必要シンボル数）を決定してもよい。

【0096】

＜決定方法２＞
決定方法２では、端末２００は、例えば、実際に送信されるデータ（例えば、PUSCH）と、PUSCHに多重される信号（例えば、UCI又は、追加のDMRS：Demodulation Reference Signal）とに基づく符号化率に基づいて、実際に送信されるデータを配置する時間リソースのending symbol（換言すると、変更後のending symbol）を決定する。

【0097】

例えば、決定方法１のように、ending symbolの変更によってPUSCHのシンボル数を低減させるにもかかわらず、PUSCHに多重される信号に使用されるリソースのサイズが変わらない場合、端末２００の送信データ（PUSCH及び多重される信号）の符号化率は高くなる。そこで、決定方法２では、PUSCHに多重される信号を考慮して、決定方法１よりも符号化率を低下させる。

【0098】

例えば、端末２００は、Configured grant設定に基づく符号化率を満たすシンボル数（「必要シンボル数」）を決定する。例えば、必要シンボル数は、次式(2)から決定されてよい。

【数2】

【0099】

式(2)の右辺は、「{(送信CB数)/(設定CB数)}*(設定シンボル数)+(多重RE数)/(割当サブキャリア数)」以上の最小の整数を返すceil関数である。ここで、「多重RE数」は、PUSCHに追加で多重される信号のリソースエレメント（Resource element：RE）数を表す。また、「割当サブキャリア数」は、PUSCH送信用に割り当てられたリソースブロック（Resource Block：RB）数と、RBあたりのサブキャリア数とから求められる。よって、式(2)において、「(多重RE数)/(割当サブキャリア数)」は、PUSCHに多重される信号の送信に使用されるシンボル数(小数)を表す。

【0100】

なお、「多重RE数」には、2 bit以下のHARQ-ACK用RE数は含まれなくてもよい。2 bit以下のHARQ-ACKは、データのレートマッチングに影響を与えないようにパンクチャにより多重される動作となる。このため、決定方法２においても、2 bit以下のHARQ-ACKがending symbolの決定に影響を与えないように動作することにより、端末２００でのPDCCHの検出誤りによる基地局１００でのPUSCHの受信誤り（例えば、レートマッチングの認識が端末２００と基地局１００との間で合わなくなることにより、正しくPUSCHを受信できなくなる状態）を抑制できる。

【0101】

また、「多重RE数」には、CG-UCI用のRE数は含まれなくてもよい。Configured grant送信においては、CG-UCIはPUSCHに多重して送信されるので、基地局１００でCG-UCIが多重されることを予め加味してデータの符号化率を設定しておくことにより、「多重RE数」にCG-UCI用のRE数を含めない動作とすることもできる。

【0102】

一例として、式(2)において、「送信CB数」が2CBであり、「設定CB数」が4CBであり、「設定シンボル数」が14シンボルであり、「多重RE数」が636REであり、「割当サブキャリア数」が1272サブキャリアの場合、PUSCH（及び多重される信号）の送信に対する「必要シンボル数」は8シンボルとなる。なお、式(2)に設定されるパラメータはこれらに限定されない。

【0103】

なお、決定方法２において、変更後のending symbolの位置は、例えば、決定方法１と同様、端末２００に設定されたstarting symbol候補のnシンボル前（ｎは１以上の整数）、及び、設定されたending symbol（例えば、configured ending symbol）の何れかに設定されてよい。

【0104】

このように、決定方法２では、PUSCHに多重される信号も考慮して、基地局１００が設定したデータの符号化率（換言すると、基地局１００が意図するデータの符号化率）を維持したうえで、PUSCH送信に使用されるシンボル数を低減することにより、端末２００のデータ送信に影響を与えず、他の端末が利用できるリソースを増加できるので、リソースの利用効率を向上できる。

【0105】

＜決定方法３＞
決定方法３では、端末２００は、例えば、PUSCHに追加で多重される信号（例えば、UCI、又は、追加のDMRS）の有無に基づいて、PUSCHのending symbolを変更するか否かを決定する。

【0106】

例えば、端末２００は、PUSCHに多重される信号が無い場合、PUSCHのending symbolを変更（例えば、前倒し）する。この場合、ending symbolの決定方法は、例えば、決定方法１でもよい。

【0107】

一方、端末２００は、PUSCHに多重される信号が有る場合、PUSCHのending symbolを変更（例えば、前倒し）せずに、基地局１００から設定されたending symbolに設定する。

【0108】

例えば、2 bit以下のHARQ-ACKは、データ（例えば、PUSCH）をパンクチャして多重される。よって、データのシンボル数が少ないほど、HARQ-ACK等の信号の多重（換言すると、パンクチャ）がデータに与える影響は大きくなることが想定される。このため、決定方法３では、端末２００は、PUSCHに多重される信号がある場合には、PUSCHのending symbolの前倒しを行わない（換言すると、変更しない）。これにより、PUSCHのデータ送信を保護できる。

【0109】

なお、データのシンボル数が十分に多い場合（例えば、シンボル数が閾値以上の場合）、端末２００は、PUSCHに多重される信号がある場合でも、PUSCHのending symbolの前倒しを行ってもよい。

【0110】

このように、決定方法３では、PUSCHに多重される信号も考慮し、基地局１００が設定したデータの符号化率（換言すると、基地局１００が意図するデータの符号化率）を維持したうえで、PUSCH送信に使用されるシンボル数を低減することにより、端末２００のデータ送信に影響を与えず、他の端末が利用できるリソースを増加できるので、リソースの利用効率を向上できる。

【0111】

また、決定方法３では、PUSCHに多重される信号（換言すると、当該信号によるパンクチャ）がPUSCH送信に影響を与え得る場合には、PUSCH送信に使用するシンボル数を低減させないことで、端末２００は、PUSCH送信を適切に行うことができる。

【0112】

以上、決定方法１～３についてそれぞれ説明した。

【0113】

このように、本実施の形態では、基地局１００及び端末２００は、PUSCHのCB数（例えば、データサイズ）及び再送の少なくとも一方に応じて、PUSCHに対して設定される時間リソースのending symbolを設定し、設定されたending symbolに基づいてPUSCHの送受信を行う。

【0114】

例えば、端末２００は、設定されたCB数（例えば、データサイズ）よりも送信されるPUSCHのCB数が少ない場合（例えば、図７を参照）、又は、PUSCHの再送の場合（例えば、図７を参照）、PUSCHに対して設定される時間リソースのending symbol（換言すると、終了位置）を変更し、変更後のending symbolに基づいて、PUSCHを送信する。

【0115】

また、基地局１００は、端末２００に設定されたCB数（データサイズ）よりも端末２００が送信するPUSCHのCB数が少ない場合（例えば、図７を参照）、又は、PUSCHの再送の場合（例えば、図７を参照）、PUSCHに対して設定される時間リソースのending symbol（換言すると、終了位置）を変更し、変更後のending symbolに基づいて、PUSCHを受信する。

【0116】

これにより、端末２００は、例えば、Configured grant設定において設定されたリソース（換言すると、基地局１００が想定するリソース）に応じたリソースに基づいて、PUSCHを送信できる。また、端末２００が過剰にリソースを使用することを抑制することにより、残りのリソース（例えば、変更後のending symbolより後のリソース）を他の端末が使用できるので、リソース利用効率を向上できる。

【0117】

よって、本実施の形態によれば、例えば、アンライセンス周波数帯域における上りリンクリソースの利用効率を向上できる。

【0118】

なお、本実施の形態では、PUSCHのending symbolの決定方法において、CB数を用いる場合について説明したが、これに限定されない。例えば、CB数の代わりにCBG数を用いてもよい。

【0119】

また、本実施の形態において、基地局１００は、PUSCHのending symbol位置を端末２００に明示的に通知してもよい。明示的な通知には、例えば、DFIが使用されてもよい。また、基地局１００は、例えば、端末２００と他の端末との多重が不要の場合、PUSCHのending symbolを変更しないことを端末２００へ通知してもよい。

【0120】

また、本実施の形態において、基地局１００は、例えば、端末２００と他の端末との多重する不要であることを端末２００へ通知してもよい。この場合、端末２００は、PUSCHのending symbolを変更しない。

【0121】

（実施の形態２）
［Time offset］
NR-Uのconfigured grantでは、上りリンクにおける送信開始タイミングに関して、シンボル長よりも細かい粒度のオフセット「time offset」を用いて、端末間の送信の衝突を回避する仕組みの導入が議論されている。

【0122】

NR-U configured grantでは、例えば、同じ物理リソースを複数の端末に割り当てる運用が想定されている。同じ物理リソースを利用する端末が、同じタイミングで送信を開始すると、送信が衝突し、基地局において信号を正しく受信できない場合があり得る。

【0123】

そこで、例えば、各端末は、starting symbolにおいて、シンボル長より細かい粒度のオフセット（time offset）分待ってから送信を開始する。

【0124】

time offset値は、例えば、端末毎に上位レイヤから設定される。なお、１つの端末に対して複数のconfigured grant設定が有る場合には、同じ端末でもConfigured grant設定毎に異なるtime offset値が設定されてもよい。また、time offset値の選択は、例えば、複数のtime offset値の候補が設定され、端末が複数の候補の中からランダムに選択する方法でもよい。

【0125】

ある端末が先に送信を開始した場合、他の端末は送信できなくなるため、time offset値が短い端末ほど（換言すると、より早く送信を開始できる端末ほど）、上りリンク送信の優先度が高いことになる。これにより、端末間の送信の衝突を回避できる。

【0126】

図８は、time offsetの設定例を示す。例えば、各シンボル（図８ではシンボル#0）には、シンボル長よりも細かい粒度のtime offset#1～#4が設定されている。例えば、図８において、time offset#2が設定（又は選択）されている端末が送信開始した場合、time offset#2よりも長いtime offset#3又は#4が設定されている端末はPUSCHを送信できない。このとき、例えば、time offset#3又は#4が設定されている端末では、time offset#2が設定されている端末が送信する信号（例えば、reservation信号）によってLBTが失敗している。

【0127】

ここで、初送（例えば、全てのCBを含む送信）と再送（例えば、一部のCBを含む送信、又は、incremental redundancy（IR）合成を行う場合に初送と比較して高い符号化率の送信でもよい)とでは、PUSCHの送信に使用されるリソースサイズは異なる。

【0128】

そこで、本実施の形態では、端末は、time offset値を初送と再送とで異ならせる。これにより、空きリソースを利用して複数の端末の送信を時間分割多重（time division multiplexing：TDM）できるので、リソースの利用効率を向上できる。

【0129】

本実施の形態に係る基地局及び端末は、実施の形態１に係る基地局１００及び端末２００と基本構成が共通するので、図３及び図４を援用して説明する。以下、本実施の形態に係る基地局１００及び端末２００において、実施の形態１と異なる動作について説明する。

【0130】

［基地局の構成］
基地局１００は、スケジューリング部１０６において端末２００毎にtime offset値を決定し、決定したtime offset値を含むシグナリング情報を、例えば、データ生成部１０７を介して端末２００に通知する。なお、基地局１００は、例えば、基地局１００と端末２００とが共有するtime offsetの複数の候補の中から、１つの候補を端末２００に通知してもよく、１つの候補を端末２００に選択させるように設定してもよい。

【0131】

［端末の構成］
端末２００において、送信制御部２０６は、制御情報保持部２０５から入力されるconfigured grant設定、チャネル状態推定部２０２から入力されるチャネル状態（例えば、busy状態又はidle状態）に基づいて、設定されたtime offsetに応じて送信可能か否かを判定する。送信制御部２０６は、送信可能と判定した場合、データ生成指示をデータ生成部２０７に出力し、リソース情報（例えば、time offsetによって送信タイミングをシフトさせることも含む）を符号化・変調部２０９に出力する。一方、送信制御部２０６は、送信不可能と判定した場合、データ送信処理を行わない。

【0132】

符号化・変調部２０９は、送信制御部２０６から入力されるリソース情報に基づいて、あるシンボルにおいてtime offsetにより１シンボルに満たない長さの信号送信となる場合には、当該シンボルにおいて、チャネルを確保するための信号（Reservation signalとも呼ぶ）を作成し、送信部２１０へ出力する。

【0133】

［time offsetの決定方法］
次に、端末２００（例えば、送信制御部２０６）におけるtime offsetの決定方法について説明する。なお、基地局１００（受信制御部１０４）も、後述する決定方法に基づいて受信を制御する。

【0134】

＜決定方法１＞
決定方法１では、time offsetは、初送時よりも再送時の方が短い。

【0135】

決定方法１により、再送は、初送よりも優先度が高く設定される。このため、端末２００は、再送をより早く完了できるので、PUSCH送信の遅延を低減できる。

【0136】

図９は、決定方法１におけるtime offsetの割当の一例を示す。図９では、例えば、端末２００のconfigured grant送信において、time offset#1及び#2の何れかが再送用に割り当てられ、time offset#3及び#4の何れかが初送用に割り当てられる。これにより、図９では、PUSCHの再送を行う端末は、PUSCHの初送を行う端末よりも先に送信を開始でき、PUSCHを優先的に送信（換言すると、再送）できる。

【0137】

このように、決定方法１では、複数の端末において再送を初送よりも優先的に行うように複数の端末の送信信号を多重できるので、PUSCHの送信遅延を短縮でき、リソースの利用効率を向上できる。

【0138】

＜決定方法２＞
決定方法２では、time offsetは、再送時よりも初送時の方が短い。

【0139】

初送と再送とが双方存在する場合、図１０に示すように、再送が送信され、その後に初送が送信される動作（換言すると、再送が優先される動作）が想定される。このような場合、初送のPUSCHのシンボルは、再送のPUSCHのシンボルによってパンクチャされる可能性が高くなり、基地局１００において受信に失敗しやすくなり、再送が増加することが想定される。

【0140】

そこで、決定方法２では、送信遅延が問題にならないケースにおいて、初送時のtime offsetは、再送時のtime offsetよりも短く設定される。これにより、初送が再送よりも優先的に行われるので、例えば、初送のPUSCHのシンボルが他の信号によってパンクチャされる可能性を低減し、再送の増加を抑制できる。

【0141】

このように、決定方法２では、複数の端末において初送のデータが再送のデータによってパンクチャされるケースを低減して複数の端末の送信信号を多重できるので、リソースの利用効率を向上できる。

【0142】

＜決定方法３＞
決定方法３では、time offsetは、PUSCHが配置される時間リソース内に設定されるstarting symbol候補に応じて決定される。

【0143】

例えば、図１１に示すように、スロット内の最初のstarting symbol候補#0では、初送のtime offsetが再送のtime offsetよりも短く設定される。換言すると、スロット内の最初のstarting symbol候補#0では、初送が再送よりも優先される。

【0144】

一方、例えば、図１１に示すように、スロット内の最初のstarting symbol候補#0と異なる他のstarting symbol候補#1及び#2では、再送のtime offsetが初送のtime offsetよりも短く設定される。換言すると、スロット内のstarting symbol候補#1及び#2では、再送が初送よりも優先される。

【0145】

ここで、初送のPUSCHが基地局１００において正しく復号されるには、端末２００に設定された全てのシンボルが送信に使用されることが想定される。一方、全てのタイミング（換言すると、starting symbol候補）において初送のtime offsetを再送のtime offsetよりも短くすると、再送の送信機会が低減し、送信遅延が長くなり得る。

【0146】

そのため、決定方法３では、最初のstarting symbol候補では、初送のtime offsetが再送のtime offsetよりも短く設定されることにより、端末２００は、PUSCHの初送時には最初のstarting symbolから、例えば、設定された全てのCBから構成されるPUSCHを送信できる。これにより、基地局１００では、初送のPUSCHの両方を正しく復号できる可能性が高くなる。

【0147】

また、決定方法３では、最小のstarting symbol候補と異なる他のstarting symbol候補では、再送のtime offsetが初送のtime offsetよりも短く設定されることにより、端末２００は、PUSCHの再送を優先的に行うことができる。また、再送されるPUSCHのCB数（送信CB数）は、端末２００に設定されるCB数（設定CB数）よりも少ない可能性が高いので、スロットの途中に設定されるstarting symbol候補から再送が開始される場合でも、基地局１００では、再送のPUSCHの両方を正しく復号できる可能性が高くなる。

【0148】

このように、決定方法３では、基地局１００において、複数の端末からの初送及び再送の両方のPUSCHの復号を成功できる可能性を高くするように複数の端末の送信信号を多重できるので、リソースの利用効率を向上できる。

【0149】

＜決定方法４＞
決定方法４では、Starting symbol候補毎のtime offsetは、configured grant送信の状況に応じて基地局によって決定される。

【0150】

starting symbol候補毎の送信（例えば、初送及び再送）の優先度は、configured grant送信の状況（換言すると、基地局１００によるスケジューリング状況）によって変わり得る。そのため、starting symbol候補毎のtime offsetは、基地局１００から端末２００へのシグナリングによって変更される。

【0151】

Configured grant送信の状況は、例えば、同じリソースを使用する端末の数によって表されてもよい。

【0152】

例えば、同じリソースを使用する端末数が多いほど、いずれかの端末によってリソースが使用されている状態になりやすい（換言すると、リソースが使用される頻度が高い）。この状態では、初送及び再送のいずれか一方を優先すると、優先した送信が行われ、他方の送信が行われない状態となり送信効率が低下する。例えば、初送を再送よりも優先すると、すべての端末が初送を終えるまで（換言すると、HARQ processをすべて使うまで）再送が行えなくなり、送信遅延が非常に長くなる。この場合、例えば、ターゲットBLER(Block Error Rate)に合わせて再送も一定程度優先してtime offsetが設定されることにより、初送と再送とがバランスよく発生し、送信効率を向上できる。

【0153】

逆に、同じリソースを使用する端末数が少ないほど、リソースが使用される頻度が低くなる。この状態では、初送と再送とが混在する可能性も低くなるため、例えば、初送を優先するようにtime offsetを設定しても上述したような送信遅延の問題となりにくい。

【0154】

このように、決定方法４では、configured grant送信の状況に応じて基地局１００がtime offsetを設定できるため、リソース利用効率を向上できる。

【0155】

＜決定方法５＞
決定方法５では、Time offsetは、PUSCHの送信タイミングに応じて決定される。

【0156】

１つのconfigured grant送信タイミング（例えば、スロット。又はtransmission occasionとも呼ぶ）において、初送と再送とが混在する場合、初送のPUSCHのシンボルは、再送のPUSCHのシンボルによってパンクチャされてしまう。

【0157】

そこで、決定方法５では、初送及び再送に対するtime offsetは、送信タイミング（例えば、異なるスロット）に応じて変更される。例えば、図１２では、初送が再送よりも優先されるスロット、及び、再送が初送よりも優先されるスロットがそれぞれ設定される。初送が再送よりも優先されるスロットでは、例えば、スロット内の各starting symbolでの初送におけるtime offsetは、再送におけるtime offsetよりも短く設定される。また、再送が初送よりも優先されるスロットでは、例えば、スロット内の各starting symbolでの再送におけるtime offsetは、初送におけるtime offsetよりも短く設定される。

【0158】

例えば、端末２００は、初送のPUSCHを、初送が優先されるスロットにおいて送信し、再送のPUSCHを、再送が優先されるスロットにおいて送信すればよい。これにより、例えば、初送と再送とが混在する場合でも、初送のPUSCHのシンボルが、再送のPUSCHのシンボルによってパンクチャされてしまう可能性を低減できる。また、再送のPUSCHは、スロット内の一部のリソース（一部のシンボル）によって送信できる可能性が高いので、再送が優先されるスロットでは、複数の端末による再送データを多重しやすくなる。

【0159】

なお、time offsetは、configured grant設定に応じて、初送と再送とで異なるように設定されてもよい。

【0160】

このように、決定方法５では、初送と再送とで異なる送信タイミングとすることにより、初送と再送との衝突を低減し、リソースの利用効率を向上できる。

【0161】

＜決定方法６＞
決定方法６では、再送に使用されるtime offsetは、DFIに応じて変更される。

【0162】

例えば、端末２００間の送信信号の多重の必要性は、通信状況（例えば、再送が必要な端末数など）によって異なる。

【0163】

PUSCH送信に対するHARQ-ACKは、DFIで通知されるため、DFIにtime offset情報も含めてもよい。これにより、基地局１００は再送のためのtime offsetを動的に変更することができ、端末間の多重を制御することが可能となる。

【0164】

このように、決定方法６では、通信状況に応じて動的に初送・再送の優先度を設定し、複数の端末の送信を多重できるため、無線リソースを効率的に利用できる。

【0165】

以上、決定方法１～６についてそれぞれ説明した。

【0166】

このように、本実施の形態では、端末２００は、初送と再送とで、time offsetを異ならせる。これにより、複数の端末から送信される信号の多重の効率を向上でき、リソースの利用効率を向上できる。

【0167】

なお、本実施の形態では、初送と再送とでtime offsetの設定を異ならせる場合について説明したが、これに限定されない。例えば、端末２００は、端末２００に設定されるCB（時間リソース）の全て（又は閾値以上のCB）にPUSCHが割り当てられるケース（例えば、初送時を含む）と、端末２００に設定されるCB（時間リソース）の一部（又は閾値未満のCB）にPUSCHが割り当てられるケース（例えば、再送時を含む）とで、time offsetを異ならせてもよい。

【0168】

また、本実施の形態に係るtime offsetの設定は、例えば、実施の形態１の動作（例えば、PUSCHのending symbolの変更（前倒し））によって空いたリソースにおいて適用されてもよい。

【0169】

または、本実施の形態に係るtime offsetの設定は、例えば、実施の形態１の動作とは別に、端末２００に設定されたconfigured grantリソースおいて空いているリソースにおいて適用されてもよい。

【0170】

また、端末２００は、time offsetの複数の候補が設定され、複数の候補の中からtime offsetをランダムに選択してもよく、ある基準に従って選択してもよい。この場合でも、端末２００が選択可能なtime offsetの値は、例えば、初送と再送とで大小関係があればよい。

【0171】

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

【0172】

（他の実施の形態）
上記各実施の形態は、type 1 PUSCH transmission（slot based送信とも呼ばれる）、及び、type 2 PUSCH（mini-slot based送信とも呼ばれる）の両方に適用できる。

【0173】

また、上記実施の形態では、上位レイヤのシグナリングには、RRCシグナリングを想定しているが、Medium Access Control（MAC）のシグナリング、及び、物理レイヤのシグナリングであるDCIでの通知に置き換えてもよい。MACのシグナリングおよび物理レイヤのシグナリングの場合、RRCのシグナリングと比較して、変更の頻度を上げることができる。

【0174】

また、上記実施の形態において、制御信号を送信する下り制御チャネルは、PDCCHに限らず、他の名称の制御チャネルでもよい。また、ULデータを送信する上りデータチャネルはPUSCHに限らず、他の名称のデータチャネルでもよい。

【0175】

上記実施の形態では、Configured grant送信に関する時間リソースは、スロット又はシンボル単位である場合に限定されず、他の時間リソース単位（例えば、サブフレーム、フレーム又はミニスロットなど）でもよい。

【0176】

上記実施の形態では、端末２００の送信後、他の端末がstarting symbolから送信するのではなく、端末２００が異なるHARQ processのデータを送信してもよい。

【0177】

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

【0178】

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

【0179】

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

【0180】

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

【0181】

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

【0182】

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

【0183】

本開示の一実施例に係る端末は、上りリンクデータのデータサイズ及び再送の少なくとも一方に応じて、前記上りリンクデータに対して設定される時間リソースの第１の終了位置を第２の終了位置に設定する制御回路と、前記第２の終了位置に基づいて、前記上りリンクデータを送信する送信回路と、を具備する。

【0184】

本開示の一実施例において、前記制御回路は、設定された前記データサイズよりも送信される前記データサイズが小さい場合、及び、前記上りリンクデータの再送の場合の少なくとも一方において、前記第１の終了位置を前記第２の終了位置に設定する。

【0185】

本開示の一実施例において、前記時間リソースはシンボル単位のリソースであり、前記第２の終了位置に対応するシンボルは、前記上りリンクデータに設定された少なくとも一つの送信開始シンボル候補のｎシンボル（ただし、ｎは１以上の整数）前のシンボル、及び、前記第１の終了位置に対応するシンボルの何れかである。

【0186】

本開示の一実施例において、前記第２の終了位置に対応するシンボルは、前記送信される上りリンクデータの符号化率に基づいて決定される。

【0187】

本開示の一実施例において、前記第２の終了位置に対応するシンボルは、前記送信される上りリンクデータと、前記上りリンクデータに多重される信号とに基づく符号化率に基づいて決定される。

【0188】

本開示の一実施例において、前記制御回路は、前記上りリンクデータに多重される信号の有無に基づいて、前記第１の終了位置を前記第２の終了位置に変更するか否かを決定する。

【0189】

本開示の一実施例において、前記制御回路は、前記送信される上りリンクデータのデータサイズが前記設定されたデータサイズである第１のケースと、前記送信される上りリンクデータのデータサイズが前記設定されたデータサイズより小さい第２のケースとで、上りリンクにおける送信開始タイミングのオフセットを異ならせる。

【0190】

本開示の一実施例において、前記オフセットは、前記第１のケースよりも前記第２のケースの方が短い。

【0191】

本開示の一実施例において、前記オフセットは、前記第２のケースよりも前記第１のケースの方が短い。

【0192】

本開示の一実施例において、前記オフセットは、前記時間リソース内における前記上りリンクデータの送信開始位置候補に応じて決定される。

【0193】

本開示の一実施例において、前記設定された時間リソース内の最初の前記送信開始位置候補では、前記オフセットは、前記第２のケースよりも前記第１のケースの方が短く、前記設定された時間リソース内の前記最初の送信開始位置候補と異なる送信開始位置候補では、前記オフセットは、前記第１のケースよりも前記第２のケースの方が短い。

【0194】

本開示の一実施例において、前記送信開始位置候補の前記オフセットは、上りリンクの使用状況に応じて決定される。

【0195】

本開示の一実施例において、前記オフセットは、前記上りリンクデータの送信タイミングに応じて決定される。

【0196】

本開示の一実施例において、前記オフセットは、前記上りリンクデータに対する応答信号に応じて決定される。

【0197】

本開示の一実施例において、前記第１のケースは前記上りリンクデータの初回送信時であり、前記第２のケースは前記上りリンクデータの再送時である。

【0198】

本開示の一実施例に係る基地局は、上りリンクデータのデータサイズ及び再送の少なくとも一方に応じて、前記上りリンクデータに対して設定される時間リソースの第１の終了位置を第２の終了位置に設定する制御回路と、前記第２の終了位置に基づいて、前記上りリンクデータを受信する受信回路と、を具備する。

【0199】

本開示の一実施例に係る送信方法は、端末が、上りリンクデータのデータサイズ及び再送の少なくとも一方に応じて、前記上りリンクデータに対して設定される時間リソースの第１の終了位置を第２の終了位置に設定し、前記第２の終了位置に基づいて、前記上りリンクデータを送信する。

【0200】

本開示の一実施例に係る受信方法は、上りリンクデータのデータサイズ及び再送の少なくとも一方に応じて、前記上りリンクデータに対して設定される時間リソースの第１の終了位置を第２の終了位置に設定し、前記第２の終了位置に基づいて、前記上りリンクデータを受信する。

【0201】

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

【産業上の利用可能性】

【0202】

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

【符号の説明】

【0203】

１００ 基地局
１０１，２０１ 受信部
１０２ UCI復調・復号部
１０３，２０５ 制御情報保持部
１０４ 受信制御部
１０５ データ復調・復号部
１０６ スケジューリング部
１０７，２０７ データ生成部
１０８ DFI生成部
１０９，２０９ 符号化・変調部
１１０，２１０ 送信部
２００ 端末
２０２ チャネル状態推定部
２０３ 復調・復号部
２０４ 再送判定部
２０６ 送信制御部
２０８ UCI生成部

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】