▶ パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカの特許一覧
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】
(24)【登録日】2024-10-22
(45)【発行日】2024-10-30
(54)【発明の名称】通信装置、通信方法及び集積回路
(51)【国際特許分類】
H04W 72/566 20230101AFI20241023BHJP
H04W 28/04 20090101ALI20241023BHJP
H04W 72/1268 20230101ALI20241023BHJP
【ＦＩ】
H04W72/566
H04W28/04 110
H04W72/1268
【請求項の数】
3
(21)【出願番号】P 2020534058
(86)(22)【出願日】2019-04-12
(86)【国際出願番号】 JP2019015885
(87)【国際公開番号】W WO2020026532
(87)【国際公開日】2020-02-06
【審査請求日】2022-03-15
【審判番号】
【審判請求日】2023-11-27
(31)【優先権主張番号】P 2018144984
(32)【優先日】2018-08-01
(33)【優先権主張国・地域又は機関】JP
(73)【特許権者】
【識別番号】514136668
【氏名又は名称】パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカ
【氏名又は名称原語表記】Ｐａｎａｓｏｎｉｃ Ｉｎｔｅｌｌｅｃｔｕａｌ Ｐｒｏｐｅｒｔｙ Ｃｏｒｐｏｒａｔｉｏｎ ｏｆ Ａｍｅｒｉｃａ
(74)【代理人】
【識別番号】110002952
【氏名又は名称】弁理士法人鷲田国際特許事務所
(72)【発明者】
【氏名】山本 哲矢
(72)【発明者】
【氏名】リ ホンチャオ
(72)【発明者】
【氏名】鈴木 秀俊
(72)【発明者】
【氏名】岩井 敬
【合議体】
【審判長】中木 努
【審判官】廣川 浩
【審判官】圓道 浩史
(56)【参考文献】
【文献】国際公開第２０１９／０１６９５１（ＷＯ，Ａ１）
【文献】Ｈｕａｗｅｉ， ＨｉＳｉｌｉｃｏｎ，Ｄｉｓｃｕｓｓｉｏｎ ｏｎ ｐａｒｔｉａｌｌｙ ｏｖｅｒｌａｐｐｅｄ ＰＵＣＣＨ ａｎｄ ＰＵＳＣＨ ｆｏｒ ＵＲＬＬＣ［ｏｎｌｉｎｅ］，３ＧＰＰ ＴＳＧ ＲＡＮ ＷＧ１ ＃９３ Ｒ１－１８０６８９５，２０１８年５月１１日アップロード
(58)【調査した分野】(Int.Cl.，ＤＢ名)
H04B7/24- 7/26
H04W4/00-99/00
3GPP TSG RAN WG1-4
SA WG1-4
CT WG1,4
(57)【特許請求の範囲】
【請求項1】
物理上りリンク共有チャネル（PUSCH）のスケジュールされた送信の第１の信頼度を示す第１のビット情報を含む第１の下りリンク制御情報（DCI）を受信し、物理上りリンク制御チャネル（PUCCH）のスケジュールされたハイブリッド自動再送要求承認（HARQ-ACK）情報送信の第２の信頼度を示す第２のビット情報を含む第２のDCIを受信し、前記第２の信頼度は、前記第１の信頼度よりも高い、受信機と、前記第２の信頼度に対応する、前記HARQ-ACK情報の符号化率を制御するためのパラメータであるオフセット値に基づいて、前記HARQ-ACK情報を前記PUSCHのスケジュールされた送信に多重するためのリソース数を決定する、回路と、
前記リソース数に基づいて、前記PUSCHに多重して前記HARQ-ACK情報を送信する、送信機と、を備える、
通信装置。
【請求項2】
物理上りリンク共有チャネル（PUSCH）のスケジュールされた送信の第１の信頼度を示す第１のビット情報を含む第１の下りリンク制御情報（DCI）を受信し、物理上りリンク制御チャネル（PUCCH）のスケジュールされたハイブリッド自動再送要求承認（HARQ-ACK）情報送信の第２の信頼度を示す第２のビット情報を含む第２のDCIを受信し、前記第２の信頼度は、前記第１の信頼度よりも高く、前記第２の信頼度に対応する、前記HARQ-ACK情報の符号化率を制御するためのパラメータであるオフセット値に基づいて、前記HARQ-ACK情報を前記PUSCHのスケジュールされた送信に多重するためのリソース数を決定し、
前記リソース数に基づいて、前記PUSCHに多重して前記HARQ-ACK情報を送信する、
通信方法。
【請求項3】
物理上りリンク共有チャネル（PUSCH）のスケジュールされた送信の第１の信頼度を示す第１のビット情報を含む第１の下りリンク制御情報（DCI）を受信し、物理上りリンク制御チャネル（PUCCH）のスケジュールされたハイブリッド自動再送要求承認（HARQ-ACK）情報送信の第２の信頼度を示す第２のビット情報を含む第２のDCIを受信し、前記第２の信頼度は、前記第１の信頼度よりも高い、処理と、前記第２の信頼度に対応する、前記HARQ-ACK情報の符号化率を制御するためのパラメータであるオフセット値に基づいて、前記HARQ-ACK情報を前記PUSCHのスケジュールされた送信に多重するためのリソース数を決定する、処理と、
前記リソース数に基づいて、前記PUSCHに多重して前記HARQ-ACK情報を送信する、処理と、を制御する、
集積回路。
【発明の詳細な説明】
【技術分野】
【0001】
本開示は、端末及び通信方法に関する。
【背景技術】
【0002】
3GPP（3rd Generation Partnership Project）では、第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】
3GPPが定義するRelease 15におけるURLLCへの要求条件として、片道0.5ms以下のユーザプレーン遅延、かつ、一定の信頼性を担保し、1ms以下の遅延を達成することが求められている。
【0004】
Release 15 NRでは、サブキャリア間隔又は送信シンボル数を柔軟に制御してTTI（Transmit Time Interval）を短縮することにより低遅延を実現する。また、低い目標ブロック誤り率（BLER: Block Error Rate）を達成するための変調符号化方式（MCS: Modulation and Coding Scheme）又はチャネル状態報告（CQI：Channel Quality Indicator）を設定又は通知することにより高信頼なデータ伝送を実現する。例えば、目標誤り率（又は、目標BLER）は、通常モード（例えば、BLER=10-1）と、高信頼モード（例えば、BLER=10-5）とが設定できる。
【先行技術文献】
【非特許文献】
【0005】
【文献】3GPP TS 38.211 V15.2.0, "NR; Physical channels and modulation (Release 15)," March 2018.
【文献】3GPP TS 38.212 V15.2.0, "NR; Multiplexing and channel coding (Release 15)," June 2018.
【文献】3GPP TS 38.213 V15.2.0, "NR; Physical layer procedure for control (Release 15)," June 2018.
【文献】3GPP TS 38.214 V15.2.0, "NR; Physical layer procedures for data (Release 15)," June 2018.
【文献】H. Shariatmadari, Z. Li, S. Iraji, M. A. Uusitalo, and R. Jantti, “Control channel enhancements for ultra-reliable low-latency communications,” Proc. The 10th International Workshop on Evolutional Technologies and Ecosystems for 5G and Beyond (WDN-5G ICC2017), May 2017.
【発明の概要】
【0006】
NRにおいて、上りリンク信号の送信方法について十分に検討されていない。
【0007】
本開示の非限定的な実施例は、上りリンク信号を適切に送信できる端末及び通信方法の提供に資する。
【0008】
本開示の一実施例に係る端末は、上りリンクデータを含む上りリンクデータチャネルの送信と、上りリンク制御情報を含む上りリンク制御チャネルの送信と、が時間的に重なる場合、前記上りリンクデータ及び前記上りリンク制御情報の少なくとも一方に対する要求条件に応じて、前記上りリンクデータ及び前記上りリンク制御情報に対する処理態様を決定する回路と、前記決定された処理態様に基づいて、前記上りリンクデータ及び前記上りリンク制御情報の少なくとも一方を送信する送信機と、を具備する。
【0009】
本開示の一実施例に係る通信方法は、上りリンクデータを含む上りリンクデータチャネルの送信と、上りリンク制御情報を含む上りリンク制御チャネルの送信と、が時間的に重なる場合、前記上りリンクデータ及び前記上りリンク制御情報の少なくとも一方に対する要求条件に応じて、前記上りリンクデータ及び前記上りリンク制御情報に対する処理態様を決定し、前記決定された処理態様に基づいて、前記上りリンクデータ及び前記上りリンク制御情報の少なくとも一方を送信する。
【0010】
なお、これらの包括的または具体的な態様は、システム、装置、方法、集積回路、コンピュータプログラム、または、記録媒体で実現されてもよく、システム、装置、方法、集積回路、コンピュータプログラムおよび記録媒体の任意な組み合わせで実現されてもよい。
【0011】
本開示の一実施例によれば、上りリンク信号を適切に送信できる。
【0012】
本開示の一実施例における更なる利点および効果は、明細書および図面から明らかにされる。かかる利点および／または効果は、いくつかの実施形態並びに明細書および図面に記載された特徴によってそれぞれ提供されるが、１つまたはそれ以上の同一の特徴を得るために必ずしも全てが提供される必要はない。
【図面の簡単な説明】
【0013】
【図1】実施の形態１に係る端末の一部の構成を示すブロック図
【図2】実施の形態１に係る基地局の構成を示すブロック図
【図3】実施の形態１に係る端末の構成を示すブロック図
【図4】実施の形態１に係る基地局及び端末の処理を示すシーケンス図
【図5】実施の形態１に係る上りリンク信号の送信処理の一例を示す図
【図6】実施の形態１に係る上りリンク信号の送信処理の一例を示す図
【図7】実施の形態１に係る上りリンク信号の送信処理の一例を示す図
【図8】実施の形態３に係る上りリンク信号の送信処理の一例を示す図
【図9】実施の形態３に係る上りリンク信号の送信処理の一例を示す図
【図10】実施の形態３に係る上りリンク信号の送信処理の一例を示す図
【図11】実施の形態５に係る上りリンク信号の送信処理の一例を示す図
【図12】実施の形態５に係る上りリンク信号の送信処理の一例を示す図
【図13】実施の形態５に係る上りリンク信号の送信処理の一例を示す図
【図14】実施の形態５に係る上りリンク信号の送信処理の一例を示す図
【発明を実施するための形態】
【0014】
以下、本開示の実施の形態について図面を参照して詳細に説明する。
【0015】
LTE（Long-Term Evolution）又はNRにおけるeMBBのユースケースでは、セルスループット又は周波数利用効率を最大化することが求められる。このような場合、データの目標誤り率を比較的高い値（例えば、BLER=10-1）に設定して運用されることが一般的である。これは、ハイブリッド自動再送要求（HARQ: Hybrid Automatic Repeat Request）を適用しているためである。eMBBでは、例えば、HARQによる数回の再送による合成利得を考慮した上で、最終的に高信頼のパケット伝送(例えば、BLER=10-5)を実現することを許容している。
【0016】
一方、URLLCでは、高信頼のパケット伝送（例えば、BLER=10-5）を1ms以下の遅延で実現することが求められる。例えば、上述したHARQでは、データ伝送に誤りが発生した場合に再送要求が起こり、データが再送されるため、再送回数の増加に応じて遅延時間が長くなり、低遅延の要求条件を満たせなくなる。よって、URLLCでは、HARQによる再送無しで高信頼のパケット伝送を可能とするために、上述したような高信頼モード（データの目標誤り率を比較的低い値（例えば、BLER=10-5）に設定するモード）により１回目の送信においてデータを確実に伝送できるように運用することが考えられる。
【0017】
低い目標誤り率を設定することは、高信頼のデータ伝送につながるものの、高い目標誤り率を設定する場合と比較して、無線リソースをより多く必要とする。Release 15 NRでは、URLLCのデータサイズは、比較的小さい32byteに制限されているため、低い目標誤り率の設定によるリソース利用効率への影響はそれほど大きくなかった。
【0018】
一方で、Release 16又は今後のURLLCでは、Release 15 NRよりも大きなデータサイズを扱い、URLLCのユースケースを拡大していくことが期待される。この場合、低い目標誤り率を設定すると、１回の送信によって高信頼のパケット送信を実現するためには、膨大な無線リソースを必要とする可能性があり、リソース利用効率の観点から非効率である。
【0019】
したがって、比較的大きなデータサイズを扱うURLLCのユースケースでは、例えば、高速なHARQ再送制御の適用が想定される。高速なHARQ再送制御では、例えば、１回目の送信において高い目標誤り率（例えば、BLER=10-1又はBLER=10-2等）を設定し、１回目の送信において誤りが発生しても次の再送（２回目の送信）においてデータを確実に伝送する運用が行われる。このように、高速なHARQ再送制御は、リソース利用効率を向上させつつ、低遅延で高信頼なパケット伝送を行うために有効である。
【0020】
ここで、下りリンクにおけるHARQ伝送に着目すると、端末（UE：User Equipment）は、下りリンクデータに対する誤り検出結果を示す応答信号（ACK/NACK：Acknowledgement / Negative Acknowledgement。又は、HARQ-ACKと呼ぶ）を、上りリンク制御チャネル（例えば、PUCCH：Physical Uplink Control Channel）を用いて基地局（例えば、eNB又はgNB）へ送信する。
【0021】
このとき、応答信号の伝送に必要とされる信頼度又は遅延要求は、下りリンクデータ伝送の信頼度、遅延要求、又は、ユースケース（またはサービス）の種類（又はusage scenario）によって異なる。
【0022】
例えば、URLLCにおいて、１回目の送信において誤りが発生しても次の送信（再送）においてデータを確実に伝送できるような運用を想定する。この場合、１回目のデータ送信の目標誤り率が高いほど、より高い信頼度の応答信号の伝送（換言すると、目標誤り率がより低い応答信号の伝送）が求められる。例えば、１回目のデータ送信の目標誤り率がBLER=10-1である場合、応答信号にはBLER=10-4以下の誤り率が求められ、１回目のデータ送信の目標誤り率がBLER=10-3である場合、応答信号にはBLER=10-2以下の誤り率が求められる（例えば、非特許文献５を参照）。
【0023】
また、eMBBとURLLCとでは、URLLCのデータ伝送に対する応答信号は、eMBBのデータ伝送に対する応答信号と比較してより低遅延が要求される。
【0024】
NRの端末は、複数のユースケース又はサービスの種類（例えば、eMBB及びURLLC）に対応することが想定される。また、NRの端末は、URLLCにおいて、目標誤り率の異なる複数のURLLCデータ伝送に対応することも想定される。このとき、上りリンクにおいて、同一スロット内に信頼度、遅延要求又はユースケース(サービス)の種類の異なる下りリンクデータ伝送に対応する応答信号の送信と、上りリンクデータの送信とが同時に発生する可能性がある。
【0025】
NRでは、応答信号等の上りリンク制御情報（例えば、UCI：Uplink Control Information）を含むPUCCH送信と、上りリンクデータ（例えば、UL-SCH：Uplink-Shared Channel）を含むPUSCH（Physical Uplink Shared Channel）の送信とが時間的に重なる場合、端末は、PUSCHにUCIを多重して送信する「UCI on PUSCH」をサポートする（例えば、非特許文献２及び３を参照）。
【0026】
例えば、UCIの一つである応答信号がPUSCHに多重される場合、PUSCH内において応答信号に割り当てられるリソース量（リソースエレメント（RE：Resource Element）数）Q’ACKは、以下の式（１）により算出される。
ここで、
OACK：応答信号のビット数
LACK：応答信号に対するCRC（Cyclic Redundancy Check）ビット数
βoffset HARQ-ACK：応答信号の符号化率を制御するパラメータ
CUL-SCH：PUSCHにおいて送信するUL-SCHのコードブロック数
Kr：第r番目のコードブロックのコードブロックサイズ
Msc UCI(l)：第l番目のOFDM（Orthogonal Frequency Division Multiplexing）シンボルにおけるUCI送信に用いることができるRE数
Nsymbol,all PUSCH：PUSCHのOFDMシンボル数
α：PUSCH内において応答信号に割り当てるリソース量の上限を制御するパラメータ
【数1】
OACK：応答信号のビット数
LACK：応答信号に対するCRC（Cyclic Redundancy Check）ビット数
βoffset HARQ-ACK：応答信号の符号化率を制御するパラメータ
CUL-SCH：PUSCHにおいて送信するUL-SCHのコードブロック数
Kr：第r番目のコードブロックのコードブロックサイズ
Msc UCI(l)：第l番目のOFDM（Orthogonal Frequency Division Multiplexing）シンボルにおけるUCI送信に用いることができるRE数
Nsymbol,all PUSCH：PUSCHのOFDMシンボル数
α：PUSCH内において応答信号に割り当てるリソース量の上限を制御するパラメータ
【0027】
一般に、式（１）において、βoffset
HARQ-ACKの値を大きくするほど、応答信号により多くのリソースが割り当てられる。また、式（１）において、αの値を大きくするほど、応答信号に割り当てるリソース量の上限が大きくなる。
【0028】
しかしながら、Release 15 NRでは、UCI on PUSCHにおいて、信頼性、遅延要求又はユースケース（またはサービス）の種類に応じた応答信号及び上りリンクデータ（UL-SCH）に関する動作について十分に検討されていない。
【0029】
例えば、PUSCHに多重する応答信号に要求される信頼度が、上りリンクデータに要求される信頼度より高い場合、高い信頼度が要求される応答信号の要求条件を満たすために、応答信号により多くのリソースが割り当てられることが考えられる。例えば、式（１）において、βoffset
HARQ-ACKの値及びαの値の少なくとも一方を大きく設定することが考えられる。
【0030】
しかし、βoffset
HARQ-ACK及びαの設定が動的に制御できない場合（例えば、準静的な設定である場合）には、βoffset
HARQ-ACK及びαの値が大きく設定されている状態において、高い信頼度が要求されない応答信号がPUSCHに多重される場合にも、高い信頼度が要求される応答信号と同様の無線リソース（より多くの無線リソース）が設定され得るため、リソース利用効率の観点から非効率である。また、上りリンクデータに高い信頼度が要求される場合には、高い信頼度が要求されない応答信号に対して余分に無線リソースが割り当てられると、上りリンクデータに無線リソースが十分に割り当てられず、上りリンクデータの信頼度に関する要求条件を満たせない可能性がある。
【0031】
反対に、PUSCHに多重する応答信号に要求される信頼度よりも上りリンクデータに要求される信頼度が高い場合、高い信頼度が要求される上りリンクデータの要求条件を満たすために、応答信号に割り当てられるリソース量を低減することが考えられる。例えば、式（１）において、βoffset
HARQ-ACKの値及びαの値の少なくとも一方を小さく設定することが考えられる。
【0032】
しかし、βoffset
HARQ-ACK及びαの設定が動的に制御できない場合（例えば、準静的な設定である場合）には、βoffset
HARQ-ACK及びαの値が大きく設定されている状態において、高い信頼度が要求される応答信号がPUSCHに多重される場合に、応答信号に無線リソースが十分に割り当てられず、応答信号の信頼度に関する要求条件を満たせない可能性がある。
【0033】
また、例えば、応答信号と上りリンクデータとで遅延要求が異なる場合（例えば、eMBBに対応する上りリンクデータ、及び、URLLCに対応する応答信号の場合）、端末においてURLLCに対応する応答信号をeMBBのPUSCHに多重して送信すると、低遅延を要求されないPUSCH（例えば、eMBBに対応するPUSCH）の送信が遅延のボトルネックとなる場合がある。
【0034】
そこで、本開示の一実施例では、信頼度、遅延要求、又は、ユースケース（またはサービス）の種類が異なる応答信号及び上りリンクデータの送信方法について説明する。換言すると、信頼度、遅延要求又はユースケース（又はサービス）の種類等の「要求条件」に応じた応答信号及び上りリンクデータの送信方法について説明する。
【0035】
以下、各実施の形態について、詳細に説明する。
【0036】
（実施の形態１）
［通信システムの概要］
本開示の各実施の形態に係る通信システムは、基地局１００及び端末２００を備える。
［通信システムの概要］
本開示の各実施の形態に係る通信システムは、基地局１００及び端末２００を備える。
【0037】
図１は、本開示の各実施の形態に係る端末２００の一部の構成を示すブロック図である。図１に示す端末２００において、制御部２１１は、上りリンクデータ（例えば、UL-SCH）を含む上りリンクデータチャネル（例えば、PUSCH）の送信と、上りリンク制御情報（例えば、UCI）を含む上りリンク制御チャネル（例えば、PUCCH）の送信と、が時間的に重なる場合、上りリンクデータ及び上りリンク制御情報の少なくとも一方に対する要求条件（例えば、信頼度、遅延要求、又は、ユースケース（またはサービス）の種類）に応じて、上りリンクデータ及び上りリンク制御情報に対する処理態様を決定する。送信部２１８は、決定された処理態様に基づいて、上りリンクデータ及び上りリンク制御情報の少なくとも一方を送信する。
【0038】
［基地局の構成］
図２は、本開示の実施の形態１に係る基地局１００の構成を示すブロック図である。図２において、基地局１００は、制御部１０１と、データ生成部１０２と、符号化部１０３と、再送制御部１０４と、変調部１０５と、上位制御信号生成部１０６と、符号化部１０７と、変調部１０８と、下り制御信号生成部１０９と、符号化部１１０と、変調部１１１と、信号割当部１１２と、IFFT（Inverse Fast Fourier Transform）部１１３と、送信部１１４と、アンテナ１１５と、受信部１１６と、FFT（Fast Fourier Transform）部１１７と、抽出部１１８と、復調部１１９と、復号部１２０と、判定部１２１と、復調部１２２と、復号部１２３と、判定部１２４と、を有する。
図２は、本開示の実施の形態１に係る基地局１００の構成を示すブロック図である。図２において、基地局１００は、制御部１０１と、データ生成部１０２と、符号化部１０３と、再送制御部１０４と、変調部１０５と、上位制御信号生成部１０６と、符号化部１０７と、変調部１０８と、下り制御信号生成部１０９と、符号化部１１０と、変調部１１１と、信号割当部１１２と、IFFT（Inverse Fast Fourier Transform）部１１３と、送信部１１４と、アンテナ１１５と、受信部１１６と、FFT（Fast Fourier Transform）部１１７と、抽出部１１８と、復調部１１９と、復号部１２０と、判定部１２１と、復調部１２２と、復号部１２３と、判定部１２４と、を有する。
【0039】
制御部１０１は、端末２００の下りリンクデータ送信に関する情報を決定し、決定した情報を符号化部１０３、変調部１０５及び信号割当部１１２に出力する。下りリンクデータ送信に関する情報には、例えば、PDSCHにおいて送信される下りリンクデータの変調符号化方法（例えば、MCS）、又は、PDSCHの無線リソース（以下、「PDSCHリソース」と呼ぶ）等が含まれる。また、制御部１０１は、決定した情報を下り制御信号生成部１０９に出力する。
【0040】
また、制御部１０１は、端末２００の下りリンクデータの信頼度、遅延要求又はユースケース（又はサービス）の種類に関する情報（換言すると、応答信号の要求条件に関する情報）を決定し、決定した情報を上位制御信号生成部１０６又は下り制御信号生成部１０９へ出力する。この情報は、端末２００（例えば、制御部２１１）へ通知される。
【0041】
また、制御部１０１は、端末２００の上りリンクデータの信頼度、遅延要求又はユースケース（又はサービス）の種類に関する情報（換言すると、上りリンクデータの要求条件に関する情報）を決定し、決定した情報を上位制御信号生成部１０６又は下り制御信号生成部１０９へ出力する。この情報は、端末２００（例えば、制御部２１１）へ通知される。
【0042】
また、制御部１０１は、端末２００の上りリンク制御情報（UCI）の送信に関する情報を決定し、決定した情報を、抽出部１１８及び復号部１２０へ出力する。UCIの送信に関する情報には、例えば、PUSCHへUCIを多重する際のリソース量を算出するためのパラメータ（例えば、式（１）のβoffset
HARQ-ACK及びα等）に関する情報等が含まれる。
【0043】
また、制御部１０１は、上位レイヤの制御信号（上位制御信号）又は下りリンク制御情報を送信するための下りリンク制御信号に対する無線リソース割当、及び、下りリンクデータに対する無線リソース割当を決定し、決定した情報を信号割当部１１２へ出力する。
【0044】
また，制御部１０１は、端末２００の上りリンクデータに関する情報を決定し、決定した情報を抽出部１１８及び下り制御信号生成部１０９へ出力する。端末２００の上りリンクデータ送信に関する情報には、例えば、PUSCHを用いて送信されるデータ信号の変調符号化方式（例えば、MCS）、及び、PUSCHの無線リソース（以下、「PUSCHリソース」と呼ぶ）等が含まれる。
【0045】
データ生成部１０２は、端末２００に対する下りリンクデータを生成し、符号化部１０３へ出力する。
【0046】
符号化部１０３は、データ生成部１０２から入力される下りリンクデータに対して、制御部１０１から入力される情報（例えば、符号化率に関する情報）に基づいて誤り訂正符号化を行い、符号化後のデータ信号を再送制御部１０４へ出力する。
【0047】
再送制御部１０４は、初回送信時には、符号化部１０３から入力される符号化後のデータ信号を保持するとともに、変調部１０５へ出力する。また、再送制御部１０４は、後述する判定部１２１から、送信したデータ信号に対するNACKが入力されると、対応する保持データを変調部１０５へ出力する。一方、再送制御部１０４は、判定部１２１から、送信したデータ信号に対するACKが入力されると、対応する保持データを削除する。
【0048】
変調部１０５は、制御部１０１から入力される情報（例えば、変調方式に関する情報）に基づいて、再送制御部１０４から入力されるデータ信号を変調して、データ変調信号を信号割当部１１２へ出力する。
【0049】
上位制御信号生成部１０６は、制御部１０１から入力される制御情報を用いて、制御情報ビット列（上位制御信号）を生成し、生成した制御情報ビット列を符号化部１０７へ出力する。
【0050】
符号化部１０７は、上位制御信号生成部１０６から入力される制御情報ビット列に対して誤り訂正符号化を行い、符号化後の制御信号を変調部１０８へ出力する。
【0051】
変調部１０８は、符号化部１０７から入力される制御信号を変調して、変調後の制御信号を信号割当部１１２へ出力する。
【0052】
下り制御信号生成部１０９は、制御部１０１から入力される制御情報を用いて、制御情報ビット列（下り制御信号。例えば、DCI）を生成し、生成した制御情報ビット列を符号化部１１０へ出力する。なお、制御情報が複数の端末向けに送信されることもあるため、下り制御信号生成部１０９は、各端末向けの制御情報に、各端末の端末IDを含めてビット列を生成してもよい。なお、端末IDには、後述するスクランブリング系列が用いられてもよい。
【0053】
符号化部１１０は、下り制御信号生成部１０９から入力される制御情報ビット列に対して誤り訂正符号化を行い、符号化後の制御信号を変調部１１１へ出力する。
【0054】
変調部１１１は、符号化部１１０から入力される制御信号を変調して、変調後の制御信号を信号割当部１１２へ出力する。
【0055】
信号割当部１１２は、制御部１０１から入力される無線リソースを示す情報に基づいて、変調部１０５から入力されるデータ信号、変調部１０８から入力される上位制御信号、又は、変調部１１１から入力される下り制御信号を、無線リソースにマッピングする。信号割当部１１２は、信号がマッピングされた下りリンクの信号をIFFT部１１３へ出力する。
【0056】
IFFT部１１３は、信号割当部１１２から入力される信号に対して、OFDM等の送信波形生成処理を施す。IFFT部１１３は、CP（Cyclic Prefix）を付加するOFDM伝送の場合には、CPを付加する（図示せず）。IFFT部１１３は、生成した送信波形を送信部１１４へ出力する。
【0057】
送信部１１４は、IFFT部１１３から入力される信号に対してD/A（Digital-to-Analog）変換、アップコンバート等のRF（Radio Frequency）処理を行い、アンテナ１１５を介して端末２００に無線信号を送信する。
【0058】
受信部１１６は、アンテナ１１５を介して受信された端末２００からの上りリンク信号波形に対して、ダウンコンバート又はA/D（Analog-to-Digital）変換などのRF処理を行い、受信処理後の上りリンク信号波形をFFT部１１７に出力する。
【0059】
FFT部１１７は、受信部１１６から入力される上りリンク信号波形に対して、時間領域信号を周波数領域信号に変換するFFT処理を施す。FFT部１１７は、FFT処理により得られた周波数領域信号を抽出部１１８へ出力する。
【0060】
抽出部１１８は、制御部１０１から入力される情報（例えば、UCIの送信に関する情報、及び、上りリンクデータに関する情報）に基づいて、FFT部１１７から入力される信号から、UCIが送信された無線リソース成分、及び、上りリンクデータが送信された無線リソース成分を抽出する。抽出部１１８は、抽出したUCIが送信された無線リソース成分を復調部１１９へ出力し、抽出した上りリンクデータが送信された無線リソース成分を復調部１２２へ出力する。
【0061】
復調部１１９は、抽出部１１８から入力される、UCIに対応する無線リソース成分に対して、等化及び復調を行い、復調結果（復調系列）を復号部１２０へ出力する。
【0062】
復号部１２０は、制御部１０１から入力されるUCIの送信に関する情報（例えば、UCIの符号化に関する情報）に基づいて、復調部１１９から入力される復調結果に対して誤り訂正復号を行い、復号後のビット系列を判定部１２１へ出力する。
【0063】
判定部１２１は、復号部１２０から入力されるビット系列に基づいて、端末２００から送信された応答信号が、送信したデータ信号に対してACK（誤り有り）又はNACK（誤り無し）の何れを示しているかを判定する。判定部１２１は、判定結果を再送制御部１０４に出力する。
【0064】
復調部１２２は、抽出部１１８から入力される、上りリンクデータに対応する無線リソース成分に対して、等化及び復調を行い、復調結果（復調系列）を復号部１２３へ出力する。
【0065】
復号部１２３は、復調部１２２から入力される復調結果に対して誤り訂正復号を行い、復号後のビット系列を判定部１２４へ出力する。
【0066】
判定部１２４は、復号部１２３から入力されるビット系列に対して誤り検出を行い、誤りが検出されない場合、受信データ（受信UL-SCH）を得る。なお、判定部１２４は、誤り検出結果を用いて、端末２００に対する再送要求のための応答信号（ACK/NACK又はHARQ-ACK）を生成し、再送制御部１０４に出力してもよい（図示せず）。
【0067】
［端末の構成］
図３は、本開示の実施の形態１に係る端末２００の構成を示すブロック図である。図３において、端末２００は、アンテナ２０１と、受信部２０２と、FFT部２０３と、抽出部２０４と、下り制御信号復調部２０５と、復号部２０６と、上位制御信号復調部２０７と、復号部２０８と、データ復調部２０９と、復号部２１０と、制御部２１１と、符号化部２１２，２１４と、変調部２１３，２１５と、信号割当部２１６と、IFFT部２１７と、送信部２１８と、を有する。
図３は、本開示の実施の形態１に係る端末２００の構成を示すブロック図である。図３において、端末２００は、アンテナ２０１と、受信部２０２と、FFT部２０３と、抽出部２０４と、下り制御信号復調部２０５と、復号部２０６と、上位制御信号復調部２０７と、復号部２０８と、データ復調部２０９と、復号部２１０と、制御部２１１と、符号化部２１２，２１４と、変調部２１３，２１５と、信号割当部２１６と、IFFT部２１７と、送信部２１８と、を有する。
【0068】
受信部２０２は、アンテナ２０１を介して受信された基地局１００からの下りリンク信号（データ信号又は制御信号）の信号波形に対して、ダウンコンバート又はA/D（Analog-to-Digital）変換などのRF処理を行い、得られる受信信号（ベースバンド信号）をFFT部２０３に出力する。
【0069】
FFT部２０３は、受信部２０２から入力される信号（時間領域信号）に対して、時間領域信号を周波数領域信号に変換するFFT処理を施す。FFT部２０３は、FFT処理により得られた周波数領域信号を抽出部２０４へ出力する。
【0070】
抽出部２０４は、制御部２１１から入力される制御情報（例えば、下りリンクデータ又は制御信号の無線リソースに関する情報）に基づいて、FFT部２０３から入力される信号から、下り制御信号（例えば、DCI）、上位制御信号、又は、下りリンクデータを抽出する。抽出部２０４は、下り制御信号を下り制御信号復調部２０５へ出力し、上位制御信号を上位制御信号復調部２０７へ出力し、下りリンクデータをデータ復調部２０９へ出力する。
【0071】
下り制御信号復調部２０５は、抽出部２０４から入力される下り制御信号を等化及び復調して、復調結果を復号部２０６へ出力する。
【0072】
復号部２０６は、下り制御信号復調部２０５から入力される復調結果を用いて誤り訂正復号を行い、制御情報を得る。復号部２０６は、得られた制御情報を制御部２１１に出力する。
【0073】
上位制御信号復調部２０７は、抽出部２０４から入力される上位制御信号を等化及び復調し、復調結果を復号部２０８へ出力する。
【0074】
復号部２０８は、上位制御信号復調部２０７から入力される復調結果を用いて誤り訂正復号を行い、制御情報を得る。復号部２０８は、得られた制御情報を制御部２１１に出力する。
【0075】
データ復調部２０９は、抽出部２０４から入力される下りリンクデータを等化及び復調し、復号結果を復号部２１０へ出力する。
【0076】
復号部２１０は、データ復調部２０９から入力される復調結果を用いて誤り訂正復号を行う。また、復号部２１０は、下りリンクデータに対して誤り検出を行い、誤り検出結果を制御部２１１に出力する。また、復号部２１０は、誤り検出の結果、誤り無しと判定した下りリンクデータを受信データとして出力する。
【0077】
制御部２１１は、復号部２０６又は復号部２０８から入力される制御情報に含まれる、端末２００のPUCCHの送信に関する情報及びPUSCHの送信に関する情報に基づいて、上りリンク送信（例えば、UCI又は上りリンクデータ）における送信方法又はパラメータ（例えば、MCS又は無線リソース等）を決定する。制御部２１１は、決定した情報を符号化部２１２，２１４、変調部２１３，２１５及び信号割当部２１６へ出力する。
【0078】
また、制御部２１１は、復号部２１０から入力される誤り検出結果を用いて応答信号（ACK/NACK又はHARQ-ACK）を生成し、符号化部２１２に出力する。
【0079】
また、制御部２１１は、復号部２０６又は復号部２０８から入力される制御情報に含まれる、下りリンクデータ又は制御信号の無線リソースに関する情報を、抽出部２０４に出力する。
【0080】
符号化部２１２は、制御部２１１から入力される情報に基づいて、応答信号（ビット系列）を誤り訂正符号化し、符号化後の応答信号（ビット系列）を変調部２１３へ出力する。
【0081】
変調部２１３は、制御部２１１から入力される情報に基づいて、符号化部２１２から入力される応答信号を変調して、変調後の応答信号（変調シンボル列）を信号割当部２１６へ出力する。
【0082】
符号化部２１４は、制御部２１１から入力される情報に基づいて、上りリンクデータ（送信ビット系列）を誤り訂正符号化し、符号化後の上りリンクデータ（ビット系列）を変調部２１５へ出力する。
【0083】
変調部２１５は、制御部２１１から入力される情報に基づいて、符号化部２１４から入力される上りリンクデータを変調して、変調後の上りリンクデータ（変調シンボル列）を信号割当部２１６へ出力する。
【0084】
信号割当部２１６は、変調部２１３から入力される応答信号（変調シンボル列）を、制御部２１１から指示される無線リソース（例えば、PUCCHリソース又はPUSCHリソース）にマッピングする。また、信号割当部２１６は、変調部２１５から入力される上りリンクデータ（変調シンボル列）を、制御部２１１から指示されるPUSCHリソースにマッピングする。例えば、信号割当部２１６は、後述するように、信頼度、遅延要求又はユースケース(またはサービス)の種類が異なる応答信号及び上りリンクデータの双方に対してリソースを割り当てる場合もあり、又は、リソースの全てをドロップ又は一部をパンクチャする場合もある。信号割当部２１６は、応答信号又は上りリンクデータがマッピングされた信号をIFFT部２１７へ出力する。
【0085】
IFFT部２１７は、信号割当部２１６から入力される信号に対して、OFDM等の送信波形生成処理を施す。IFFT部２１７は、CP（Cyclic Prefix）を付加するOFDM伝送の場合には、CPを付加する（図示せず）。または、IFFT部２１７がシングルキャリア波形を生成する場合には、信号割当部２１６の前段にDFT（Discrete Fourier Transform）部が追加されてもよい（図示せず）。IFFT部２１７は、生成した送信波形を送信部２１８へ出力する。
【0086】
送信部２１８は、IFFT部２１７から入力される信号に対してD/A（Digital-to-Analog）変換、アップコンバート等のRF（Radio Frequency）処理を行い、アンテナ２０１を介して基地局１００に無線信号を送信する。
【0087】
［基地局１００及び端末２００の動作］
以上の構成を有する基地局１００及び端末２００における動作について詳細に説明する。
以上の構成を有する基地局１００及び端末２００における動作について詳細に説明する。
【0088】
図４は、本実施の形態に係る基地局１００及び端末２００の処理のフローを示す。
【0089】
基地局１００は、PUSCHに多重するUCIのリソース量に関する情報を端末２００へ送信する（ＳＴ１０１）。端末２００は、基地局１００から通知されるPUSCHに多重するUCIのリソース量に関する情報を取得する（ＳＴ１０２）。PUSCHに多重するUCIのリソース量に関する情報には、例えば、PUSCHに多重するUCIのリソース量を制御するパラメータ（例えば、式（１）に示すパラメータ）が含まれる。
【0090】
基地局１００は、下りリンクデータに関する情報を含むDCIを、端末２００へ送信する（ＳＴ１０３）。端末２００は、例えば、基地局１００から通知されるDCIに基づいて、下りリンクデータのスケジューリング情報、又は、PUCCHに関する情報を取得する（ＳＴ１０４）。
【0091】
基地局１００は、下りリンクデータを端末２００へ送信する（ＳＴ１０５）。端末２００は、例えば、基地局１００から通知されているDCIに基づいて、下りリンクデータ（PDSCH）を受信する（ＳＴ１０６）。
【0092】
基地局１００は、上りリンクデータに関する情報を含むDCIを、端末２００へ送信する（ＳＴ１０７）。端末２００は、例えば、基地局１００から通知されるDCIに基づいて、PUSCHに関する情報を取得する（ＳＴ１０８）。
【0093】
端末２００は、応答信号又は上りリンクデータに対する要求条件（換言すると、信頼度、遅延要求又はユースケース（サービス）の種類）に応じて、上りリンク信号（例えば、UCI及び上りリンクデータ）に関する動作を制御する（ＳＴ１０９）。
【0094】
端末２００は、決定した動作に基づいて、PUCCH又はPUSCHを用いて上りリンク信号（例えば、UCI又は上りリンクデータを含む）を基地局１００へ送信する（ＳＴ１１０）。基地局１００は、端末２００から送信される上りリンク信号を受信する（ＳＴ１１１）。
【0095】
なお、図４において、ＳＴ１０３～ＳＴ１０６の処理と、ＳＴ１０７～ＳＴ１０８の処理との順序は入れ替わってもよい。
【0096】
次に、端末２００におけるUCI送信に関する動作（例えば、図４のＳＴ１０９の処理）の制御方法について詳細に説明する。
【0097】
本実施の形態では、URLLCに対応する応答信号を含むPUCCH送信と、eMBBに対応する上りリンクデータ（例えば、UL-SCH）を含むPUSCH送信とが時間的に重なる場合の端末２００における動作について説明する。
【0098】
なお、本実施の形態において、PUCCHにURLLCに対応する応答信号が含まれ、PUSCHにeMBBに対応する上りリンクデータが含まれる場合に限らず、例えば、PUCCHに含まれる信号が、PUSCHに含まれる信号と比較して、URLLCのように高い信頼度又は低遅延等の要求条件の厳しい信号であればよい。
【0099】
端末２００は、応答信号の信頼度（例えば、応答信号の目標誤り率又は目標BLER）に応じて、応答信号又は上りリンクデータの処理態様（例えば、送信方法又はパラメータ）を決定する。換言すると、端末２００は、URLLCに対応する応答信号の信頼度に応じて、応答信号又は上りリンクデータの送信方法又はパラメータに差異を生じさせる。
【0100】
応答信号又は上りリンクデータの送信に差異を生じさせる例として、応答信号の信頼度が異なる場合について説明する。例えば、URLLCにおいて、１回目のデータ送信の目標誤り率が高い（例えば、BLER=10-1）下りリンクデータに対する応答信号と、１回目のデータ送信の目標誤り率が低い（例えば、BLER=10-5）下りリンクデータに対する応答信号と、で送信方法又はパラメータに差異を生じさせてもよい。
【0101】
１回目のデータ送信の目標誤り率が高い場合、データを確実に再送させるために、応答信号には高い信頼度が要求される。一方、１回目のデータ送信の目標誤り率が低い場合、データの誤りが発生しにくいので、応答信号にはそれほど高い信頼度が要求されない。
【0102】
そこで、高い信頼度が要求されない応答信号（例えば、１回目のデータ送信の目標誤り率が低い下りリンクデータに対する応答信号）を含むPUCCH送信と、eMBBに対応する上りリンクデータを含むPUSCH送信とが時間的に重なる場合、端末２００は、例えば、上述した非特許文献２及び３に記載された方法又はパラメータと同様の方法又はパラメータを用いて、応答信号をPUSCHに多重する。
【0103】
一方、高い信頼度が要求される応答信号（例えば、１回目のデータ送信の目標誤り率が高い下りリンクデータに対する応答信号）を含むPUCCH送信と、eMBBに対応する上りリンクデータを含むPUSCH送信とが時間的に重なる場合、端末２００は、例えば、非特許文献２及び３に記載された方法又はパラメータと異なる方法又はパラメータを用いて、応答信号をPUCCHで送信、又は、応答信号をPUSCHに多重する。
【0104】
高い信頼度が要求される応答信号（例えば、目標誤り率が所定値以下の応答信号）を含むPUCCH送信と、eMBBに対応する上りリンクデータを含むPUSCH送信とが時間的に重なる場合における応答信号のPUSCHへの多重方法の一例として、以下の3つの方法（Option 1, 2及び3）について説明する。
【0105】
[Option 1]
Option 1では、端末２００は、eMBBのPUSCH（すなわち、上りリンクデータ）をドロップし（換言すると、送信をキャンセルし）、PUCCHを用いて応答信号を送信する。
Option 1では、端末２００は、eMBBのPUSCH（すなわち、上りリンクデータ）をドロップし（換言すると、送信をキャンセルし）、PUCCHを用いて応答信号を送信する。
【0106】
図５は、Option 1における端末２００の動作例を示す。
【0107】
図５に示すように、URLLCに対応する応答信号を含むPUCCH（URLLC PUCCH）の送信と、eMBBに対応する上りリンクデータを含むPUSCH（eMBB PUSCH）の送信とが同一スロット内において発生する場合、端末２００は、eMBB PUSCH（上りリンクデータ）をドロップし、URLLC PUCCH（応答信号）を送信する。
【0108】
Option 1によれば、高い信頼度が要求されるURLLCのための応答信号の送信に対して、eMBBのPUSCH送信が影響を与えることがなくなるため、高い信頼度が要求される応答信号の品質を保証できる。
【0109】
また、Option 1によれば、端末２００は単にeMBB PUSCH（上りリンクデータ）をドロップすればよく、端末２００において複雑な処理を要しないため、端末２００の実装が容易である利点がある。
【0110】
なお、Option 1において、端末２００は、eMBB PUSCHにおいて、上りリンクデータ（UL-SCH）をドロップし、PUSCHを用いて応答信号を送信してもよい。
【0111】
[Option 2]
Option 2では、端末２００は、同一スロット内において、eMBB PUSCHの送信区間のうち、URLLCのためのPUCCHの送信区間と時間的に重なる区間においてeMBBのPUSCH（上りリンクデータ）の送信を行わない（パンクチャする）。換言すると、端末２００は、同一スロット内において、eMBB PUSCHの送信区間のうち、URLLCのためのPUCCHの送信区間と時間的に重ならない区間においてPUSCHを用いて上りリンクデータを送信する。
Option 2では、端末２００は、同一スロット内において、eMBB PUSCHの送信区間のうち、URLLCのためのPUCCHの送信区間と時間的に重なる区間においてeMBBのPUSCH（上りリンクデータ）の送信を行わない（パンクチャする）。換言すると、端末２００は、同一スロット内において、eMBB PUSCHの送信区間のうち、URLLCのためのPUCCHの送信区間と時間的に重ならない区間においてPUSCHを用いて上りリンクデータを送信する。
【0112】
図６は、Option 2における端末２００の動作例を示す。
【0113】
図６に示すように、URLLCに対応する応答信号を含むPUCCH（URLLC PUCCH）の送信と、eMBBに対応する上りリンクデータを含むPUSCH（eMBB PUSCH）の送信とが同一スロット内において発生する場合、端末２００は、URLLC PUCCH（例えば、応答信号）を送信する。また、図６に示すように、端末２００は、同一スロット内において、eMBB PUSCHの送信区間のうち、URLLC PUCCHの送信区間と時間的に重なる区間においてeMBB PUSCH（上りリンクデータ）をパンクチャし、URLLC PUCCHの送信区間と時間的に重なる区間以外の区間においてeMBB PUSCH（例えば、上りリンクデータ）を送信する。
【0114】
eMBBに対応する送信では、送信するデータ量が比較的多い。このため、eMBBに対応する送信は、スロット単位の送信（例えば、１スロット全て又は１スロットの大半を使用する送信)となる。一方、URLLCに対応する送信では、送信するデータ量が比較的少ない。また、URLLCに対応する送信は、低遅延を実現するために、非スロット単位の送信（例えば、数シンボルを使用する送信）を用いることが主なユースケースであると想定される。
【0115】
よって、eMBBに対応する送信に対してURLLCに対応する送信が時間的に重なる区間は、図６に示すように、スロット内における数シンボル、つまり、eMBBに対応する送信区間の一部であることが想定される。このため、端末２００は、URLLCに対応する送信以降のeMBBに対応する送信を全てドロップせずに、図６に示すように、eMBBに対応する送信区間のうち、URLLCに対応する送信区間と時間的に重なる区間の送信を行わない（パンクチャする）ことにより、eMBBの伝送品質及び周波数利用効率の劣化を抑圧できる。
【0116】
なお、Option 2において、端末２００は、eMBB PUSCHにおいて、上りリンクデータをパンクチャし、上りリンクデータがパンクチャされた区間において応答信号を送信してもよい。
【0117】
[Option 3]
Option 3では、端末２００は、URLLCのための応答信号をeMBBのPUSCHに多重して送信する。
Option 3では、端末２００は、URLLCのための応答信号をeMBBのPUSCHに多重して送信する。
【0118】
図７は、Option 3における端末２００の動作例を示す。
【0119】
図７に示すように、URLLCに対応する応答信号を含むPUCCH（URLLC PUCCH）の送信と、eMBBに対応する上りリンクデータを含むPUSCH（eMBB PUSCH）の送信とが同一スロット内において発生する場合、端末２００は、URLLC PUCCHに含まれる応答信号（換言すると、URLLC UCI）を、PUSCHに多重する。そして、端末２００は、応答信号（URLLC UCI）が多重されたeMBB PUSCHの信号を送信する。
【0120】
例えば、基地局１００は、端末２００に対して、応答信号の要求条件（例えば、信頼度）に応じて、式（１）におけるβoffset
HARQ-ACK及びαの値の少なくとも一つに異なる値を設定する。
【0121】
例えば、応答信号の信頼度に応じたβoffset
HARQ-ACK及びαの値は、端末固有の上位レイヤ信号により明示的に端末２００へ設定されてもよく、応答信号の信頼度に応じた係数が導入されてもよい。例えば、端末２００は、高い信頼度の応答信号が多重される場合には、式（１）に示すβoffset
HARQ-ACK及びαの値に係数を乗算し、係数が乗算されたβoffset
HARQ-ACK及びαの値を、式（１）に示すリソース量の計算に当てはめてもよい。例えば、応答信号の信頼度に応じた係数は、βoffset
HARQ-ACK及びαに対して共通の値でもよく、異なる値でもよい。
【0122】
これにより、端末２００は、応答信号の信頼度に応じて、PUSCHにおいて応答信号に対して適切なリソースを割り当てることが可能になる。
【0123】
Opiton 3では、更に、以下の方法（Option 3-1～3-3）を適用してもよい。
【0124】
＜Option 3-1＞
式（１）のうち、次式（２）によって算出される値は、PUSCHにおいて応答信号に要するリソース量を示し、次式（３）によって算出される値は、応答信号に割り当てるリソース量の上限値を示す。
式（１）のうち、次式（２）によって算出される値は、PUSCHにおいて応答信号に要するリソース量を示し、次式（３）によって算出される値は、応答信号に割り当てるリソース量の上限値を示す。
【数2】
【数3】
【0125】
Option 3-1では、端末２００は、式（２）によって算出される応答信号に要するリソース量が、式（３）によって算出される上限値を超えない場合に、応答信号をPUSCHへ多重する。よって、端末２００は、PUSCHにおいて、上りリンクデータ及び応答信号を送信する。
【0126】
一方、端末２００は、式（２）によって算出される応答信号に要するリソース量が、式（３）によって算出される上限値を超える場合、例えば、上りリンクデータをドロップし、応答信号をPUSCHへ多重する。よって、端末２００は、PUSCHにおいて、上りリンクデータを送信せずに、応答信号を送信する。
【0127】
または、端末２００は、式（２）によって算出される応答信号に要するリソース量が、式（３）によって算出される上限値を超える場合、例えば、PUSCH（上りリンクデータ）をドロップし、PUCCHを用いて応答信号を送信してもよい。
【0128】
Option 3-1では、応答信号に要するリソース量が上限値を超えない範囲では、端末２００は、高い信頼度が要求されるURLLCのための応答信号の送信に対して、十分なリソースを割り当てつつ、eMBBに対応する上りリンクデータと応答信号とを多重して送信できる。このため、Option 3-1によれば、高い信頼度の応答信号の送信を保証しつつ、上りリンクのリソース利用効率の劣化を抑圧できる。
【0129】
また、Option 3-1では、応答信号に要するリソース量が上限値を超える場合、つまり、応答信号に必要なりソースが足りない場合、端末２００は、上りリンクデータをドロップする。これにより、Option 3-1によれば、高い信頼度が要求される応答信号の品質を他の信号よりも優先的に保証できる。
【0130】
＜Option 3-2＞
Option 3-2では、端末２００は、式（２）によって算出される応答信号に要するリソース量が、式（３）によって算出される上限値を超えない場合に、応答信号をPUSCHへ多重する。よって、端末２００は、PUSCHにおいて、上りリンクデータ及び応答信号を送信する。
Option 3-2では、端末２００は、式（２）によって算出される応答信号に要するリソース量が、式（３）によって算出される上限値を超えない場合に、応答信号をPUSCHへ多重する。よって、端末２００は、PUSCHにおいて、上りリンクデータ及び応答信号を送信する。
【0131】
一方、端末２００は、式（２）によって算出される応答信号に要するリソース量が、式（３）によって算出される上限値を超える場合、応答信号をPUSCHへ多重し、かつ、PUSCHの送信電力が端末２００の最大送信電力を超えない範囲においてPUSCHの送信電力を増大させる。
【0132】
ここで、PUSCHの送信電力を増大させるパラメータは、基地局１００から端末２００へ、端末固有の上位レイヤ信号又は上りリンクデータをスケジューリングするUL grant（DCI）によって予め通知されてもよく、固定値が予め規定されてもよい。
【0133】
また、端末２００は、PUSCHの送信電力が端末２００の最大送信電力を超える場合、PUSCHにおいて、上りリンクデータをドロップし、応答信号をPUSCHに多重し、PUSCH（換言すると応答信号）を端末２００の最大送信電力で送信する。または、端末２００は、PUSCHをドロップし、PUCCHを用いて応答信号を送信してもよい。
【0134】
Option 3-2では、応答信号に要するリソース量が上限値を超えない範囲では、端末２００は、Option 3-1と同様、高い信頼度が要求されるURLLCのための応答信号の送信に対して、十分なリソースを割り当てつつ、eMBBに対応する上りリンクデータと応答信号とを多重して送信できる。このため、Option 3-2によれば、高い信頼度の応答信号の送信を保証しつつ、上りリンクのリソース利用効率の劣化を抑圧できる。
【0135】
また、Option 3-2では、応答信号に要するリソース量が上限値を超える場合、つまり、応答信号に必要なりソースが足りない場合でも、端末２００の最大送信電力を超えない範囲では、端末２００は、上りリンク信号の送信電力を増大させることにより、上りリンク送信の品質を改善できる。このため、Option 3-2によれば、高い信頼度の応答信号の送信を保証しつつ、上りリンクのリソース利用効率の劣化を抑圧できる。
【0136】
また、Option 3-2では、応答信号に要するリソース量が足りず、かつ、設定される送信電力が最大送信電力を超える場合、端末２００は、上りリンクデータをドロップすることにより、高い信頼度が要求される応答信号の品質を他の信号よりも優先的に保証できる。
【0137】
＜Option 3-3＞
Option 3-3では、端末２００は、基地局１００から端末２００へ特定のパラメータが通知された場合に、PUSCHにおいて、上りリンクデータをドロップし、応答信号をPUSCHに多重して送信する。または、端末２００は、基地局１００から特定のパラメータが通知された場合、PUSCH（上りリンクデータ）をドロップし、PUCCHを用いて応答信号を送信してもよい。
Option 3-3では、端末２００は、基地局１００から端末２００へ特定のパラメータが通知された場合に、PUSCHにおいて、上りリンクデータをドロップし、応答信号をPUSCHに多重して送信する。または、端末２００は、基地局１００から特定のパラメータが通知された場合、PUSCH（上りリンクデータ）をドロップし、PUCCHを用いて応答信号を送信してもよい。
【0138】
基地局１００から通知される特定のパラメータには、例えば、応答信号に要するリソース量を算出するためのパラメータを利用できる。例えば、式（１）のβoffset
HARQ-ACKの値が特定の値（例えば、0）である場合、端末２００は、上りリンクデータ又はPUSCHをドロップすると判断する。なお、基地局１００から通知される特定のパラメータは、式（１）のβoffset
HARQ-ACKの特定の値に限らず、他のパラメータを用いてもよい。
【0139】
このように、Option 3-3では、端末２００は、基地局１００から通知されるパラメータに基づいて、応答信号又は上りリンクデータの送信方法を決定する。よって、端末２００は、Option 3-1又はOption 3-2のような応答信号に要するリソース量の計算及び上限値との比較を行わずに、上りリンクデータ又はPUSCHをドロップするか否かを判断できるので、端末２００の処理が簡易になる利点がある。
【0140】
以上、応答信号のPUSCHへの多重方法の一例（Option 1, 2及び3）について説明した。
【0141】
このように、本実施の形態では、端末２００は、eMBBに対応する上りリンクデータを含むPUSCH送信と、URLLCに対応するUCI（例えば、応答信号）を含むPUCCH送信と、が時間的に重なる場合、UCIに対する要求条件に応じて、上りリンクデータ及びUCIに対する処理態様（送信方法又はパラメータ）を決定する。そして、端末２００は、決定された処理態様に基づいて、UCI、又は、UCI及び上りリンクデータを送信する。
【0142】
これにより、端末２００は、UCI（例えば、応答信号）の信頼度に応じて適切な端末動作又はリソース割当を行い、URLLCに対応する応答信号の要求条件を満たす上りリンク送信を行うことができる。
【0143】
以上より、本実施の形態によれば、端末２００は、上りリンク信号を適切に送信できる。
【0144】
なお、応答信号に要するリソース量の算出方法は、式（１）に示す計算式に限らない。例えば、応答信号に要するリソース量を算出する計算式には、式（１）のβoffset
HARQ-ACKに相当する応答信号の符号化率（換言すると、リソース量）を制御するパラメータ、及び、式（１）のαに相当するリソース量の上限値を制御するパラメータが含まれていればよい。
【0145】
また、NRでは、上りリンクデータを含むPUSCH送信に対して、基地局からのUL grantによりPUSCHを送信する無線リソースを動的に指示される「GrantベースのPUSCH送信」と、基地局からのUL grant無しに、端末が、データが発生した時点で予め準静的に割り当てられた無線リソースを用いてPUSCHを送信する「Grant-freeのPUSCH送信」(又は、「Configured grant PUSCH送信」とも呼ぶ)とがサポートされる。
【0146】
端末２００がUCIをPUSCHに多重して送信する場合、GrantベースのPUSCH送信では、基地局１００は、UCIをPUSCHに多重することが分かっているので、Grant（UL grant）によって無線リソースを指示する際に、UCIの多重を考慮した無線リソースを割り当てることができる。一方、Grant-freeのPUSCH送信では、基地局１００は、端末２００に対して、UCIの多重を考慮した無線リソースを事前に割り当てることができない。
【0147】
そこで、GrantベースのPUSCH送信とGrant-freeのPUSCH送信とで、Option 1（例えば、図５を参照）、Option 2（例えば、図６を参照）又はOption 3（例えば、図７を参照）を切り替えて適用してもよい。例えば、端末２００は、GrantベースのPUSCH送信ではOption 3を適用してUCIをPUSCHへ多重して送信する。一方、端末２００は、Grant-freeのPUSCH送信では、Option 1又はOption 2を適用してPUSCHをドロップし、PUCCHを用いて応答信号を送信する。これにより、端末２００は、GrantベースのPUSCH送信及びGrant-freeのPUSCH送信に応じて、応答信号を適切に送信できる。
【0148】
また、本実施の形態では、URLLCに対応する応答信号を含むPUCCH送信とeMBBに対応する上りリンクデータを含むPUSCH送信とが時間的に重なる場合について、URLLCに対応する応答信号の信頼度に応じて、応答信号又は上りリンクデータの送信方法、又は、パラメータに差異を生じさせる方法について説明した。
【0149】
ただし、上りリンク信号（例えば、応答信号又は上りリンクデータ）の送信方法又はパラメータに差異を生じさせる方法は、上記例に限らない。例えば、応答信号の遅延要求が異なる場合又はユースケース(またはサービス)の種類が異なる場合に、URLLCの応答信号とeMBBの応答信号とで差異を生じさせてもよい。
【0150】
例えば、eMBBに対応する下りリンクデータに対する応答信号を含むPUCCH送信と、eMBBに対応する上りリンクデータを含むPUSCH送信とが時間的に重なる場合、端末２００は、非特許文献２、３に記載の方法と同様の方法又はパラメータを用いて、応答信号をPUSCHに多重する。一方、URLLCに対応する下りリンクデータに対する応答信号を含むPUCCH送信とeMBBに対応する上りリンクデータを含むPUSCH送信とが時間的に重なる場合、端末２００は、上述したOption 1、Option 2又はOption 3の方法を用いて応答信号を送信してもよい。
【0151】
【0152】
本実施の形態では、実施の形態１と同様、URLLCに対応する応答信号を含むPUCCH送信と、eMBBに対応する上りリンクデータ（例えば、UL-SCH）を含むPUSCH送信とが時間的に重なる場合の端末２００における動作について説明する。
【0153】
また、本実施の形態では、PUCCHに、信頼度、遅延要求又はユースケース(サービス)の種類（換言すると、要求条件）が異なる複数の応答信号が含まれる場合の端末２００における動作について説明する。
【0154】
例えば、URLLCにおいて、１回目のデータ送信の目標誤り率が高い（例えば、BLER=10-1）下りリンクデータに対する応答信号と、１回目のデータ送信の目標誤り率が低い（例えばBLER=10-5）下りリンクデータに対する応答信号とがPUCCHに含まれる場合がある。目標誤り率が高い下りリンクデータに対する応答信号には高い信頼度が要求される一方、目標誤り率が低い下りリンクデータに対する応答信号には高い信頼度が要求されない。
【0155】
この場合、PUCCHには、高い信頼度が要求される応答信号が含まれているため、端末２００は、応答信号の送信の優先度が高いと判断する。よって、端末２００は、例えば、実施の形態１で説明したOption 1、Option 2又はOption 3の方法を適用してもよい。
【0156】
また、本実施の形態では、応答信号をPUSCHへ多重して送信する場合（例えば、上記Option 3の場合）、応答信号の信頼度、遅延要求又はユースケース(サービス)の種類（換言すると、要求条件）に応じて、PUSCHにおける応答信号の送信方法又はパラメータに差異を生じさせる。
【0157】
PUSCHにおける応答信号の送信方法又はパラメータに差異を生じさせる例として、応答信号の信頼度が異なる場合について説明する。例えば、URLLCにおいて、１回目のデータ送信の目標誤り率が高い（例えば、BLER=10-1）下りリンクデータに対する応答信号と、１回目のデータ送信の目標誤り率が低い（例えば、BLER=10-5）下りリンクデータに対する応答信号と、で送信方法又はパラメータに差異を生じさせてもよい。
【0158】
例えば、UCIの一つである応答信号がPUSCHに多重される場合、PUSCH内において応答信号に割り当てられるリソース量（RE数)Q’ACKは以下の式（４）により算出される。
ここで、
LACK：応答信号に対するCRCビット数
βoffset HARQ-ACK：応答信号の符号化率を制御するパラメータ
CUL-SCH：PUSCHにおいて送信するUL-SCHのコードブロック数
Kr：第r番目のコードブロックのコードブロックサイズ
Msc UCI(l)：第l番目のOFDMシンボルにおけるUCI送信に用いることができるRE数
Nsymbol,all PUSCH：PUSCHのOFDMシンボル数
α：PUSCH内において応答信号に割り当てるリソース量の上限を制御するパラメータ
【数4】
LACK：応答信号に対するCRCビット数
βoffset HARQ-ACK：応答信号の符号化率を制御するパラメータ
CUL-SCH：PUSCHにおいて送信するUL-SCHのコードブロック数
Kr：第r番目のコードブロックのコードブロックサイズ
Msc UCI(l)：第l番目のOFDMシンボルにおけるUCI送信に用いることができるRE数
Nsymbol,all PUSCH：PUSCHのOFDMシンボル数
α：PUSCH内において応答信号に割り当てるリソース量の上限を制御するパラメータ
【0159】
また、式（４）において、OACK_totalは、信頼度、遅延要求又はユースケース(サービス)の種類が異なる複数の応答信号の合計ビット数を示す。
【0160】
また、応答信号に割り当てられるリソース量は、信頼度、遅延要求又はユースケース(サービス)の種類が異なる応答信号の各々に対して以下の式により算出されてもよい。なお、一例として、２つの応答信号（ACK1及びACK2）について説明するが、複数の応答信号の数は、３個以上でもよい。
【数5】
【数6】
【0161】
式（５）及び式（６）において、ACK1は、高い信頼度を要求する応答信号を表し、ACK2は、高い信頼度を要求されない応答信号を表す。この場合、式（５）及び式（６）におけるβoffset
HARQ-ACK及びαの少なくとも一つの値には、応答信号の信頼度に応じて異なる値が端末２００へ設定されてもよい。応答信号の信頼度に応じたβoffset
HARQ-ACK及びα値は、端末固有の上位レイヤ信号により明示的に設定してもよく、応答信号の信頼度に応じた係数が導入されてもよい。例えば、端末２００は、高い信頼度の応答信号を多重する場合には、式（４）及び式（５）においてUCI on PUSCHに適用されるβoffset
HARQ-ACK及びαの値に係数を乗算し、係数が乗算されたβoffset
HARQ-ACK及びαの値を、式（５）及び式（６）に示すリソース量の計算に当てはめてもよい。例えば、応答信号の信頼度に応じた係数は、βoffset
HARQ-ACK及びαに対して共通の値でもよく、異なる値でもよい。
【0162】
これにより、端末２００は、応答信号の信頼度に応じて、PUSCHにおいて応答信号に対して適切なリソースを割り当てることが可能になる。
【0163】
また、実施の形態１と同様、Opiton 3では、更に、以下の方法（Option 3-1～3-3）を適用してもよい。
【0164】
＜Option 3-1＞
式（４）のうち、次式（７）によって算出される値は、PUSCHにおいて複数の応答信号に要するリソース量を示し、次式（８）によって算出される値は、複数の応答信号に割り当てるリソース量の上限値を示す。
式（４）のうち、次式（７）によって算出される値は、PUSCHにおいて複数の応答信号に要するリソース量を示し、次式（８）によって算出される値は、複数の応答信号に割り当てるリソース量の上限値を示す。
【数7】
【数8】
【0165】
Option 3-1では、端末２００は、式（７）によって算出される複数の応答信号に要するリソース量が、式（８）によって算出される上限値を超えない場合に、応答信号をPUSCHへ多重する。よって、端末２００は、PUSCHにおいて、上りリンクデータ及び応答信号を送信する。
【0166】
一方、端末２００は、式（７）によって算出される複数の応答信号に要するリソース量が、式（８）によって算出される上限値を超える場合、例えば、上りリンクデータをドロップし、複数の応答信号をPUSCHへ多重する。よって、端末２００は、PUSCHにおいて、上りリンクデータを送信せずに、応答信号を送信する。
【0167】
または、端末２００は、式（７）によって算出される複数の応答信号に要するリソース量が、式（８）によって算出される上限値を超える場合、例えば、PUSCH（上りリンクデータ）をドロップし、PUCCHを用いて複数の応答信号を送信してもよい。
【0168】
同様に、高い信頼度が要求される応答信号（ACK1）に対して、式（５）のうち、次式（９）によって算出される値は、PUSCHにおいて、高い信頼度が要求される応答信号（ACK1）に要するリソース量を示し、次式（１０）によって算出される値は、高い信頼度が要求される応答信号に割り当てるリソース量の上限値を示す。
【数9】
【数10】
【0169】
Option 3-1では、端末２００は、式（９）によって算出される応答信号に要するリソース量が、式（１０）によって算出される上限値を超えない場合に、応答信号（ACK1）をPUSCHへ多重する。よって、端末２００は、PUSCHにおいて、上りリンクデータ及び応答信号（少なくともACK1）を送信する。
【0170】
一方、端末２００は、式（９）によって算出される応答信号に要するリソース量が、式（１０）によって算出される上限値を超える場合、例えば、上りリンクデータをドロップし、応答信号をPUSCHへ多重する。よって、端末２００は、PUSCHにおいて、上りリンクデータを送信せずに、応答信号（少なくともACK1）を送信する。または、端末２００は、式（９）によって算出される応答信号に必要なリソース量が、式（１０）によって算出される上限値を超える場合、例えば、PUSCHをドロップし、PUCCHを用いて応答信号（少なくともACK1）を送信してもよい。
【0171】
また、例えば、高い信頼度が要求されない答信号（ACK1）に対して、式（６）のうち、次式（１１）によって算出される値は、PUSCHにおいて、高い信頼度が要求されない応答信号（ACK2）に要するリソース量を示し、次式（１２）によって算出される値は、高い信頼度が要求されない応答信号に割り当てるリソース量の上限値を示す。
【数11】
【数12】
【0172】
式（１２）に示すように、応答信号（ACK2）のリソース量の上限値は、複数の応答信号の上限値（RE数）から応答信号（ACK1）のリソース量Q'ACK1を減算した残りのリソース量を示す。換言すると、応答信号（ACK2）のリソース量は、応答信号（ACK1）のリソースが確保された後に決定される。
【0173】
Option 3-1では、端末２００は、式（１１）によって算出される応答信号に要するリソース量が、式（１２）によって算出される上限値を超えない場合に、応答信号（ACK2）をPUSCHへ多重する。よって、端末２００は、PUSCHにおいて、上りリンクデータ及び複数の応答信号（ACK1及びACK2）を送信する。
【0174】
また、端末２００は、式（１１）によって算出される応答信号に必要なリソース量が、式（１２）によって算出される上限値を超える場合、例えば、上りリンクデータをドロップせずに、各応答信号をPUSCHへ多重する。よって、端末２００は、PUSCHにおいて、上りリンクデータ及び複数の応答信号（ACK1及びACK2）を送信する。この際、応答信号（ACK2）には、PUSCHリソースが十分に割り当てられないが、応答信号（ACK2）に要求される信頼度は高くないので、ACK2に対する信頼度に関する要求条件を満たせる可能性がある。
【0175】
このように、Option 3-1では、応答信号に要するリソース量が上限値を超えない範囲では、端末２００は、高い信頼度が要求されるURLLCのための応答信号の送信に対して、十分なリソースを割り当てつつ、eMBBに対応する上りリンクデータと複数の応答信号とを多重して送信できる。このため、Option 3-1によれば、高い信頼度の応答信号の送信を保証しつつ、上りリンクのリソース利用効率の劣化を抑圧できる。
【0176】
また、Option 3-1では、高い信頼度が要求される応答信号に要するリソースが上限値を超える場合、つまり、高い信頼度が要求される応答信号に必要なりソースが足りない場合、端末２００は、上りリンクデータをドロップする。これにより、Option 3-1によれば、高い信頼度が要求される応答信号の品質を他の信号よりも優先的に保証できる。
【0177】
＜Option 3-2＞
Option 3-2では、端末２００は、式（７）によって算出される複数の応答信号に要するリソース量が、式（８）によって算出される上限値を超えない場合に、複数の応答信号をPUSCHへ多重する。よって、端末２００は、PUSCHにおいて、上りリンクデータ及び複数の応答信号を送信する。
Option 3-2では、端末２００は、式（７）によって算出される複数の応答信号に要するリソース量が、式（８）によって算出される上限値を超えない場合に、複数の応答信号をPUSCHへ多重する。よって、端末２００は、PUSCHにおいて、上りリンクデータ及び複数の応答信号を送信する。
【0178】
一方、端末２００は、式（７）によって算出される複数の応答信号に要するリソース量が、式（８）によって算出される上限値を超える場合、複数の応答信号をPUSCHへ多重し、かつ、PUSCHの送信電力が端末２００の最大送信電力を超えない範囲においてPUSCHの送信電力を増大させる。
【0179】
ここで、PUSCHの送信電力を増大させるパラメータは、基地局１００から端末２００へ、端末固有の上位レイヤ信号又は上りリンクデータをスケジューリングするUL grant（DCI）によって予め通知されてもよく、固定値が予め規定されてもよい。
【0180】
また、端末２００は、PUSCHの送信電力が端末２００の最大送信電力を超える場合、PUSCHにおいて、上りリンクデータをドロップし、応答信号をPUSCHに多重し、PUSCH（換言すると応答信号）を端末２００の最大送信電力で送信する。または、端末２００は、PUSCHをドロップし、PUCCHを用いて応答信号を送信してもよい。
【0181】
次に、（５）及び式（６）に示すように、信頼度、遅延要求又はユースケース(サービス)の種類が異なる応答信号の各々に対して割り当てるリソース量を算出する場合について説明する。
【0182】
端末２００は、式（９）によって算出される高い信頼度が要求される応答信号（ACK1）に要するリソース量が、式（１０）によって算出される上限値を超えない場合に、応答信号（ACK1）をPUSCHへ多重する。よって、端末２００は、PUSCHにおいて、上りリンクデータ及び応答信号（少なくともACK1）を送信する。
【0183】
一方、端末２００は、式（９）によって算出される高い信頼度が要求される応答信号（ACK1）に要するリソース量が、式（１０）によって算出される上限値を超える場合、応答信号（ACK1）をPUSCHへ多重し、かつ、PUSCHの送信電力が端末２００の最大送信電力を超えない範囲においてPUSCHの送信電力を増大させる。
【0184】
ここで、PUSCHの送信電力を増大させるパラメータは、基地局１００から端末２００へ、端末固有の上位レイヤ信号又は上りリンクデータをスケジューリングするUL grant（DCI）によって予め通知されてもよく、固定値が予め規定されてもよい。
【0185】
また、端末２００は、PUSCHの送信電力が端末２００の最大送信電力を超える場合、PUSCHにおいて、上りリンクデータをドロップし、応答信号（ACK1）をPUSCHに多重し、PUSCHを端末２００の最大送信電力で送信する。または、端末２００は、PUSCHをドロップし、PUCCHを用いて応答信号（ACK1）を送信してもよい。
【0186】
また、端末２００は、式（１１）によって算出される高い信頼度が要求されない応答信号（ACK2）に要するリソース量が、式（１２）によって算出される上限値を超えない場合に、応答信号（ACK2）をPUSCHへ多重する。よって、端末２００は、PUSCHにおいて、上りリンクデータ及び複数の応答信号（例えば、ACK1及びACK2）を送信する。
【0187】
一方、端末２００は、式（１１）によって算出される高い信頼度が要求されない応答信号（ACK2）に要するリソース量が、式（１２）によって算出される上限値を超える場合、PUSCHの送信電力を増大させずに、各応答信号（ACK1及びACK2）をPUSCHへ多重する。この際、応答信号（ACK2）には、PUSCHリソースが十分に割り当てられないが、応答信号（ACK2）に要求される信頼度は高くないので、ACK2に対する信頼度に関する要求条件を満たせる可能性がある。
【0188】
Option 3-2では、高い信頼度が要求される応答信号に要するリソース量が上限値を超えない範囲では、端末２００は、Option 3-1と同様、高い信頼度が要求されるURLLCのための応答信号の送信に対して、十分なリソースを割り当てつつ、eMBBに対応する上りリンクデータと応答信号とを多重して送信できる。このため、Option 3-2によれば、高い信頼度の応答信号の送信を保証しつつ、上りリンクのリソース利用効率の劣化を抑圧できる。
【0189】
また、Option 3-2では、高い信頼度が要求される応答信号に要するリソース量が上限値を超える場合、つまり、応答信号に必要なりソースが足りない場合でも、端末２００の最大送信電力を超えない範囲では、端末２００は、上りリンク信号の送信電力を増大させることにより、上りリンク送信の品質を改善できる。このため、Option 3-2によれば、高い信頼度の応答信号の送信を保証しつつ、上りリンクのリソース利用効率の劣化を抑圧できる。
【0190】
また、Option 3-2では、高い信頼度が要求される応答信号に要するリソース量が足りず、かつ、設定される送信電力が最大送信電力を超える場合、端末２００は、上りリンクデータをドロップすることにより、高い信頼度が要求される応答信号の品質を他の信号よりも優先的に保証できる。
【0191】
＜Option 3-3＞
Option 3-3では、端末２００は、基地局１００から端末２００へ特定のパラメータが通知された場合に、PUSCHにおいて、上りリンクデータをドロップし、複数の応答信号をPUSCHに多重する。または、端末２００は、基地局１００から特定のパラメータが通知された場合、PUSCH（上りリンクデータ）をドロップし、PUCCHを用いて複数の応答信号を送信してもよい。
Option 3-3では、端末２００は、基地局１００から端末２００へ特定のパラメータが通知された場合に、PUSCHにおいて、上りリンクデータをドロップし、複数の応答信号をPUSCHに多重する。または、端末２００は、基地局１００から特定のパラメータが通知された場合、PUSCH（上りリンクデータ）をドロップし、PUCCHを用いて複数の応答信号を送信してもよい。
【0192】
基地局１００から通知される特定のパラメータには、例えば、応答信号に要するリソース量を算出するためのパラメータを利用できる。例えば、式（４）、式（５）又は式（６）のβoffset
HARQ-ACKの値が特定の値（例えば、0）である場合、端末２００は、上りリンクデータ又はPUSCHをドロップすると判断する。なお、基地局１００から通知される特定のパラメータは、式（４）、式（５）又は式（６）のβoffset
HARQ-ACKの特定の値に限らず、他のパラメータを用いてもよい。
【0193】
このように、Option 3-3では、端末２００は、基地局１００から通知されるパラメータに基づいて、複数の応答信号又は上りリンクデータの送信方法を決定する。よって、端末２００は、複数の応答信号に要するリソース量の計算及び上限値との比較を行わずに、上りリンクデータ又はPUSCHをドロップするか否かを判断できるので、端末２００の処理が簡易になる利点がある。
【0194】
以上、本実施の形態における応答信号のPUSCHへの多重方法の一例（Option 3-1, 3-2及び3-3）について説明した。
【0195】
このように、本実施の形態では、端末２００は、eMBBに対応する上りリンクデータを含むPUSCH送信と、URLLCに対応する複数のUCI（例えば、複数の応答信号）を含むPUCCH送信と、が時間的に重なる場合、複数のUCIに対する要求条件に応じて、上りリンクデータ及び複数のUCIに対する処理態様（送信方法又はパラメータ）を決定する。そして、端末２００は、決定された処理態様に基づいて、複数のUCI、又は、複数のUCI及び上りリンクデータを送信する。
【0196】
これにより、端末２００は、信頼度が異なる複数の応答信号がPUCCHに含まれる場合でも、複数の応答信号の信頼度に応じて適切な端末動作又はリソース割当を行い、URLLCに対応する応答信号の要求条件を満たす上りリンク送信を行うことができる。
【0197】
以上より、本実施の形態によれば、端末２００は、上りリンク信号を適切に送信できる。
【0198】
なお、応答信号に要するリソース量の算出方法は、式（４）、式（５）又は式（６）に示す計算式に限らない。例えば、応答信号に要するリソース量を算出する計算式には、式式（４）、式（５）又は式（６）のβoffset
HARQ-ACKに相当する応答信号の符号化率（換言すると、リソース量）を制御するパラメータ、及び、式（４）、式（５）又は式（６）のαに相当するリソース量の上限値を制御するパラメータが含まれていればよい。
【0199】
また、本実施の形態では、信頼度、遅延要求又はユースケース(サービス)の種類が異なる応答信号に対して、端末２００は、異なる符号化を適用してHARQ-ACKビットを生成してもよく、１つの符号化を適用してHARQ-ACKビットを生成してもよい。
【0200】
例えば、複数の応答信号に対して異なる符号化処理を行うことは、端末２００の処理量を増大させるため、実装を複雑にする恐れがある。一方で、端末２００が１つの符号化処理を行う場合、端末２００の実装を簡易にできるものの、下りリンクデータを受信してから、下りリンクデータの復号、応答信号の生成、及び、応答信号の送信までに要する処理時間に関する能力(UE capability。以下、「N1」と表す)を考慮する必要がある。
【0201】
NRでは、端末２００は、「N1」を基地局１００へ報告する。
【0202】
基地局１００は、端末２００が下りリンクデータに対する応答信号を送信するためのPUCCHのスロット位置（又は、下りリンクデータを受信したスロットからPUCCH（例えば、応答信号）を送信するスロットまでの時間：「PDSCH-to-HARQ-ACK timing」）を設定し、端末２００へ通知する。このとき、基地局１００は、PDSCH-to-HARQ-ACK timingについて、端末２００から報告された端末２００の処理能力(N1)を超える値（換言すると、N1より小さい値）を設定及び通知できない。
【0203】
本実施の形態では、端末２００は、信頼度、遅延要求又はユースケース(またはサービス)の種類が異なる応答信号の送信に対する能力（N1）をそれぞれ規定し、基地局１００へ報告する。また、端末２００は、基地局１００から設定及び通知されたPDSCH-to-HARQ-ACK timingの値と、規定したN1の値とに基づいて、信頼度、遅延要求又はユースケース(またはサービス)の種類が異なる応答信号に対する符号化方法を決定してもよい。
【0204】
例えば、端末２００は、下りリンクデータを受信してから、データを復号し、応答信号を生成し、PUCCHを送信するまでに必要な処理時間に関する能力(N1)について、信頼度、遅延要求又はユースケース(またはサービス)の種類に応じた２つ以上の能力を有する。端末２００は、２つ以上の能力（N1）を基地局１００へ報告する。
一例として、端末２００は、eMBBに対するN1(以下、「N1_X」又は「N1_eMBB」と表す)、及び、URLLCに対するN1(以下、「N1_Y」又は「N1_URLLC」と表す)の２つの端末能力(UE capability)を有してもよい。例えば、URLLCでは、eMBBよりも低遅延が要求される可能性が高いので、URLLCに対するN1は、eMBBに対するN1よりも小さい値が設定されてもよい。
一例として、端末２００は、eMBBに対するN1(以下、「N1_X」又は「N1_eMBB」と表す)、及び、URLLCに対するN1(以下、「N1_Y」又は「N1_URLLC」と表す)の２つの端末能力(UE capability)を有してもよい。例えば、URLLCでは、eMBBよりも低遅延が要求される可能性が高いので、URLLCに対するN1は、eMBBに対するN1よりも小さい値が設定されてもよい。
【0205】
下りリンクデータに対する応答信号を送信するためのPUCCHのスロット位置（PDSCH-to-HARQ-ACK timing）の特定に関して、基地局１００が端末固有の上位レイヤ信号（例えば、RRCシグナリング）によって準静的なスロット位置の集合を通知し、下りリンクデータを割り当てるDCIによって、集合の中のどのPDSCH-to-HARQ-ACK timingを実際に用いるかを通知する。
【0206】
同一スロット内において、信頼度、遅延要求又はユースケース(またはサービス)の種類が異なるデータ伝送に対応する応答信号の送信が同時に発生する場合、端末２００は、各応答信号に対するPDSCH-to-HARQ-ACK timingの値と、端末２００が有する能力（N1）とに基づいて、応答信号に対する処理を決定する。
【0207】
例えば、端末２００は、各応答信号に対するPDSCH-to-HARQ-ACK timingの値の最小値がN1_X又はN1_eMBB以上である場合、各応答信号に対して共通の符号化処理を行い、HARQ-ACKビットを生成する。
【0208】
一方、高い信頼度又は低遅延が要求される応答信号、又は、URLLCに対応する応答信号に対するPDSCH-to-HARQ-ACK timingの値が、N1_X又はN1_eMBB未満である場合、端末２００は、各応答信号に対して共通の符号化処理を行うことができない。この場合、端末２００は、各応答信号に対して異なる符号化方法を適用して、HARQ-ACKビットを生成する。
【0209】
これにより、端末２００の処理能力に応じて、符号処理をできる限り共通化することができるため、端末２００の処理量の増大又は実装の複雑さを軽減できる。
【0210】
【0211】
実施の形態１、２では、URLLCに対応する応答信号を含むPUCCH送信と、eMBBに対応する上りリンクデータを含むPUSCH送信とが時間的に重なる場合について説明した。これに対して、本実施の形態では、eMBBに対応する応答信号を含むPUCCH送信と、URLLCに対応する上りリンクデータ（例えば、UL-SCH）を含むPUSCH送信とが時間的に重なる場合の端末２００における動作について説明する。
【0212】
なお、本実施の形態において、PUCCHにeMBBに対応する応答信号が含まれ、PUSCHにURLLCに対応する上りリンクデータが含まれる場合に限らず、例えば、PUSCHに含まれる信号が、PUCCHに含まれる信号と比較して、URLLCのように高い信頼度又は低遅延等の要求条件の厳しい信号であればよい。
【0213】
端末２００は、上りリンクデータの信頼度（例えば、上りリンクデータの目標誤り率又は目標BLER）に応じて、応答信号又は上りリンクデータの処理態様（例えば、送信方法又はパラメータ）を決定する。換言すると、端末２００は、URLLCに対応する上りリンクデータの信頼度に応じて、応答信号又は上りリンクデータの送信方法又はパラメータに差異を生じさせる。
【0214】
応答信号又は上りリンクデータの送信に差異を生じさせる例として、上りリンクデータの信頼度が異なる場合について説明する。例えば、URLLCにおいて、目標誤り率が高い（例えば、BLER=10-1）上りリンクデータと、目標誤り率が低い（例えば、BLER=10-5）上りリンクデータと、で送信方法又はパラメータに差異を生じさせてもよい。
【0215】
目標誤り率が高い上りリンクデータには高い信頼度が要求されない一方、目標誤り率が低い上りリンクデータには高い信頼度が要求される。
【0216】
そこで、高い信頼度が要求されない上りリンクデータ（例えば、目標誤り率が高いデータ信号）を含むPUSCH送信と、eMBBに対応する下りリンクデータに対する応答信号を含むPUCCH送信とが時間的に重なる場合、端末２００は、例えば、上述した非特許文献２、３に記載された方法又はパラメータと同様の方法又はパラメータを用いて、応答信号をPUSCHに多重する。
【0217】
一方、高い信頼度が要求される上りリンクデータ(例えば、目標誤り率が低いデータ信号)を含むPUSCH送信と、eMBBに対応する下りリンクデータに対する応答信号を含むPUCCH送信とが時間的に重なる場合、端末２００は、例えば、非特許文献２及び３に記載された方法又はパラメータと異なる方法又はパラメータを用いて、応答信号をPUCCHで送信、又は、応答信号をPUSCHに多重する。
【0218】
高い信頼度が要求される上りリンクデータ（例えば、目標誤り率が所定値以下の上りリンクデータ）を含むPUSCH送信と、eMBBに対応する下りリンクデータに対する応答信号を含むPUCCH送信とが時間的に重なる場合における応答信号のPUSCHへの多重方法の一例として、以下の3つの方法（Option 1, 2及び3）について説明する。
【0219】
[Option 1]
Option 1では、端末２００は、eMBBのPUCCH（例えば、応答信号）をドロップし（換言すると、送信をキャンセルし）、PUSCHを用いて上りリンクデータを送信する。
Option 1では、端末２００は、eMBBのPUCCH（例えば、応答信号）をドロップし（換言すると、送信をキャンセルし）、PUSCHを用いて上りリンクデータを送信する。
【0220】
図８は、Option 1における端末２００の動作例を示す。
【0221】
図８に示すように、URLLCに対応する上りリンクデータを含むPUSCH（URLLC PUSCH）の送信と、eMBBに対応する下りリンクデータに対する応答信号を含むPUCCH（eMBB PUCCH）の送信とが同一スロット内において発生する場合、端末２００は、eMBB PUCCH（応答信号）をドロップし、URLLC PUSCH（上りリンクデータ）を送信する。
【0222】
Option 1によれば、高い信頼度が要求されるURLLCのためのPUSCH送信に対して、eMBBのPUCCH送信が影響を与えることがなくなるため、高い信頼度が要求される上りリンクデータの品質を保証できる。
【0223】
また、Option 1によれば、端末２００は単にeMBB PUCCH（応答信号）をドロップすればよく、端末２００において複雑な処理を要しないため、端末２００の実装が容易である利点がある。
【0224】
[Option 2]
Option 2では、端末２００は、同一スロット内において、eMBB PUCCHの送信区間のうち、URLLCのためのPUSCHの送信区間と時間的に重なる区間においてeMBBのPUCCH（例えば、応答信号）の送信を行わない（パンクチャする）。換言すると、端末２００は、同一スロット内において、eMBB PUCCHの送信区間のうち、URLLCのためのPUSCHの送信区間と時間的に重ならない区間においてPUCCHを用いて応答信号を送信する。
Option 2では、端末２００は、同一スロット内において、eMBB PUCCHの送信区間のうち、URLLCのためのPUSCHの送信区間と時間的に重なる区間においてeMBBのPUCCH（例えば、応答信号）の送信を行わない（パンクチャする）。換言すると、端末２００は、同一スロット内において、eMBB PUCCHの送信区間のうち、URLLCのためのPUSCHの送信区間と時間的に重ならない区間においてPUCCHを用いて応答信号を送信する。
【0225】
図９は、Option 2における端末２００の動作例を示す。
【0226】
図９に示すように、URLLCに対応する上りリンクデータを含むPUSCH（URLLC PUSCH）の送信と、eMBBに対応する下りリンクデータに対する応答信号を含むPUCCH（eMBB PUCCH）の送信とが同一スロット内において発生する場合、端末２００は、URLLC PUSCH（上りリンクデータ）を送信する。また、図９に示すように、端末２００は、同一スロット内において、eMBB PUCCHの送信区間のうち、URLLC PUSCHの送信区間と時間的に重なる区間においてeMBB PUCCH（例えば、応答信号）をパンクチャし、URLLC PUSCHの送信区間と時間的に重なる区間以外の区間においてeMBB PUCCH（例えば、応答信号）を送信する。
【0227】
eMBBに対応する送信では、送信するデータ量が比較的多い。このため、eMBBに対応する送信は、スロット単位の送信（例えば、１スロット全て又は１スロットの大半を使用する送信)となる。一方、URLLCに対応する送信では、送信するデータ量が比較的少ない。また、URLLCに対応する送信は、低遅延を実現するために、非スロット単位の送信（例えば、数シンボルを使用する送信）を用いることが主なユースケースであると想定される。
【0228】
よって、eMBBに対応する送信に対してURLLCに対応する送信が時間的に重なる区間は、図９に示すように、スロット内における数シンボル、つまり、eMBBに対応する送信区間の一部であることが想定される。このため、端末２００は、URLLCに対応する送信以降のeMBBに対応する送信を全てドロップせずに、図９に示すように、eMBBに対応する送信区間のうち、URLLCに対応する送信区間と時間的に重なる区間の送信を行わない（パンクチャする）ことにより、eMBBの伝送品質及び周波数利用効率の劣化を抑圧できる。
【0229】
[Option 3]
Option 3では、端末２００は、eMBBのための応答信号をURLLCのPUSCHに多重して送信する。
Option 3では、端末２００は、eMBBのための応答信号をURLLCのPUSCHに多重して送信する。
【0230】
図１０は、Option 3における端末２００の動作例を示す。
【0231】
図１０に示すように、eMBBに対応する応答信号を含むPUCCH（eMBB PUCCH）の送信と、URLLCに対応する上りリンクデータを含むPUSCH（URLLC PUSCH）の送信とが同一スロット内において発生する場合、端末２００は、eMBB PUCCHに含まれる応答信号（換言すると、eMBB UCI）を、PUSCHに多重する。そして、端末２００は、応答信号（eMBB UCI）が多重されたURLLC PUSCHの信号を送信する。
【0232】
例えば、基地局１００は、端末２００に対して、上りリンクデータ（又はPUSCH）の要求条件（例えば、信頼度）に応じて、式（１）におけるβoffset
HARQ-ACK及びαの値の少なくとも一つに異なる値を設定する。
【0233】
例えば、PUSCHの信頼度に応じたβoffset
HARQ-ACK及びαの値は、端末固有の上位レイヤ信号により明示的に端末２００へ設定されてもよく、上りリンクデータの信頼度に応じた係数が導入されてもよい。例えば、端末２００は、高い信頼度の上りリンクデータを含むPUSCHに応答信号が多重される場合には、式（１）に示すβoffset
HARQ-ACK及びαの値に係数を乗算し、係数が乗算されたβoffset
HARQ-ACK及びαの値を、式（１）に示すリソース量の計算に当てはめてもよい。例えば、上りリンクデータ（又はPUSCH）の信頼度に応じた係数は、βoffset
HARQ-ACK及びαに対して共通の値でもよく、異なる値でもよい。
【0234】
これにより、端末２００は、上りリンクデータ（又はPUSCH）の信頼度に応じて、PUSCHにおいて応答信号に対して適切なリソースを割り当てることが可能になる。
【0235】
以上、応答信号のPUSCHへの多重方法の一例（Option 1, 2及び3）について説明した。
【0236】
このように、本実施の形態では、端末２００は、URLLCに対応する上りリンクデータを含むPUSCH送信と、eMBBに対応するUCI（例えば、応答信号）を含むPUCCH送信と、が時間的に重なる場合、上りリンクデータに対する要求条件に応じて、上りリンクデータ及びUCIに対する処理態様（送信方法又はパラメータ）を決定する。そして、端末２００は、決定された処理態様に基づいて、上りリンクデータ、又は、UCI及び上りリンクデータを送信する。
【0237】
これにより、端末２００は、上りリンクデータの信頼度に応じて適切な端末動作又はリソース割当を行い、URLLCに対応する上りリンクデータの要求条件を満たす上りリンク送信を行うことができる。
【0238】
以上より、本実施の形態によれば、端末２００は、上りリンク信号を適切に送信できる。
【0239】
なお、Option 3において、実施の形態１のOption 3（Option 3-3）と同様、端末２００は、基地局１００から端末２００へ特定のパラメータが通知された場合に、PUCCH（例えば、応答信号）をドロップし、PUSCHを用いて上りリンクデータを送信してもよい。基地局１００から通知される特定のパラメータには、例えば、応答信号に要するリソース量を算出するためのパラメータを利用できる。例えば、式（１）のβoffset
HARQ-ACKの値が特定の値（例えば、0）である場合、端末２００は、PUCCHをドロップすると判断する。なお、基地局１００から通知される特定のパラメータは、式（１）のβoffset
HARQ-ACKの特定の値に限らず、他のパラメータを用いてもよい。
【0240】
また、上述したように、NRでは、上りリンクデータを含むPUSCH送信に対して、基地局からのUL grantによりPUSCHを送信する無線リソースを動的に指示される「GrantベースのPUSCH送信」と、基地局からのUL grant無しに、端末が、データが発生した時点で予め準静的に割り当てられた無線リソースを用いてPUSCHを送信する「Grant-freeのPUSCH送信」(又は、「Configured grant PUSCH送信」とも呼ぶ)とがサポートされる。
【0241】
端末２００がUCIをPUSCHに多重して送信する場合、GrantベースのPUSCH送信では、基地局１００は、UCIをPUSCHに多重することが分かっているので、Grant（UL grant）によって無線リソースを指示する際に、UCIの多重を考慮した無線リソースを割り当てることができる。一方、Grant-freeのPUSCH送信では、基地局１００は、端末２００に対して、UCIの多重を考慮した無線リソースを事前に割り当てることができない。
【0242】
そこで、GrantベースのPUSCH送信とGrant-freeのPUSCH送信とで、Option 1（例えば、図８を参照）、Option 2（例えば、図９を参照）又はOption 3（例えば、図１０を参照）を切り替えて適用してもよい。例えば、端末２００は、GrantベースのPUSCH送信ではOption 3を適用してUCIをPUSCHへ多重して送信する。一方、端末２００は、Grant-freeのPUSCH送信では、Option 1又はOption 2を適用してPUCCHをドロップし、PUSCHを用いて上りリンクデータを送信する。これにより、端末２００は、GrantベースのPUSCH送信及びGrant-freeのPUSCH送信に応じて、応答信号を適切に送信できる。
【0243】
また、本実施の形態では、URLLCに対応する上りリンクデータを含むPUSCH送信とeMBBに対応する下りリンクデータに対する応答信号を含むPUCCH送信とが時間的に重なる場合について、URLLCに対応する上りリンクデータの信頼度に応じて、応答信号又は上りリンクデータの送信方法、又は、パラメータに差異を生じさせる方法について説明した。
【0244】
ただし、上りリンク信号（例えば、応答信号又は上りリンクデータ）の送信方法又はパラメータに差異を生じさせる方法は、上記例に限らない。例えば、上りリンクデータの遅延要求が異なる場合又はユースケース(またはサービス)の種類が異なる場合に、URLLCの上りリンクデータとeMBBの上りリンクデータとで差異を生じさせてもよい。
【0245】
例えば、eMBBに対応する上りリンクデータ（又は低遅延が要求されない上りリンクデータ）を含むPUSCH送信と、eMBBに対応する下りリンクデータを含むPUSCH送信とが時間的に重なる場合、端末２００は、非特許文献２、３に記載の方法と同様の方法又はパラメータを用いて、応答信号をPUSCHに多重する。一方、URLLCに対応する上りリンクデータ（又は低遅延が要求される上りリンクデータ）を含むPUSCH送信とeMBBに対応する下りリンクデータに対する応答信号を含むPUCCH送信とが時間的に重なる場合、端末２００は、上述したOption 1、Option 2又はOption 3の方法を用いて上りリンクデータ（及び応答信号）を送信してもよい。
【0246】
【0247】
本実施の形態では、URLLCに対応する応答信号を含むPUCCH送信と、URLLCに対応する上りリンクデータを含むPUSCH送信とが時間的に重なる場合の端末２００における動作について説明する。
【0248】
なお、本実施の形態において、PUCCHにURLLCに対応する応答信号が含まれ、PUSCHにURLLCに対応する上りリンクデータが含まれる場合に限らず、例えば、PUSCH及びPUCCHの双方に含まれる信号が、URLLCのように高い信頼度又は低遅延等の要求条件の厳しい信号であればよい。
【0249】
端末２００は、応答信号の信頼度（例えば、応答信号の目標誤り率又は目標BLER）及び上りリンクデータの信頼度（例えば、上りリンクデータの目標誤り率又は目標BLER）に応じて、応答信号又は上りリンクデータの処理態様（例えば、送信方法又はパラメータ）を決定する。換言すると、端末２００は、応答信号の信頼度及び上りリンクデータの信頼度に応じて、応答信号又は上りリンクデータの送信方法又はパラメータに差異を生じさせる。
【0250】
応答信号については、例えば、URLLCにおいて、１回目のデータ送信の目標誤り率が高い（例えば、BLER=10-1）下りリンクデータに対する応答信号、及び、１回目のデータ送信の目標誤り率が低い（例えば、BLER=10-5）下りリンクデータに対する応答信号が送信され得る。前者の応答信号には高い信頼度が要求される一方、後者の応答信号には高い信頼度が要求されない。
【0251】
また、上りリンクデータについては、例えば、URLLCにおいて、目標誤り率が高い（例えば、BLER=10-1）上りリンクデータ、及び、目標誤り率が低い（例えばBLER=10-5）上りリンクデータが送信され得る。前者の上りリンクデータには高い信頼度が要求されない一方、後者の上りリンクデータには高い信頼度が要求される。
【0252】
そこで、上述した応答信号の信頼度と、上りリンクデータの信頼度との組み合わせに応じて、送信方法に差異を生じさせてもよい。
【0253】
まず、高い信頼度が要求されない応答信号を含むPUCCH送信と、高い信頼度が要求される上りリンクデータを含むPUSCH送信とが時間的に重なる場合、上りリンクデータの信頼度の方が応答信号の信頼度よりも高い。そこで、端末２００は、例えば、実施の形態３で説明した方法（例えば、図８、図９又は図１０を参照）に基づいて、非特許文献２、３に記載された方法又はパラメータと異なる方法又はパラメータを用いて、上りリンクデータを送信、又は、応答信号及び上りリンクデータを送信する。
【0254】
次に、高い信頼度が要求される応答信号を含むPUCCH送信と、高い信頼度が要求される上りリンクデータを含むPUSCH送信とが時間的に重なる場合、応答信号の信頼度と上りリンクデータの信頼度とは同等である。そこで、端末２００は、例えば、上述した非特許文献２、３に記載された方法又はパラメータと同様の方法又はパラメータを用いて、応答信号をPUSCHに多重する。
【0255】
次に、高い信頼度が要求されない応答信号を含むPUCCH送信と、高い信頼度が要求されない上りリンクデータを含むPUSCH送信とが時間的に重なる場合、応答信号の信頼度と上りリンクデータの信頼度とは同等である。そこで、端末２００は、例えば、上述した非特許文献２、３に記載された方法又はパラメータと同様の方法又はパラメータを用いて、応答信号をPUSCHに多重する。
【0256】
最後に、高い信頼度が要求される応答信号を含むPUCCH送信と、高い信頼度が要求されない上りリンクデータを含むPUSCH送信とが時間的に重なる場合、応答信号の信頼度の方が上りリンクデータの信頼度よりも高い。そこで、端末２００は、例えば、実施の形態１で説明した方法（例えば、図５、図６又は図７を参照）に基づいて、非特許文献２、３に記載された方法又はパラメータと異なる方法又はパラメータを用いて、応答信号を送信、又は、応答信号及び上りリンクデータを送信する。
【0257】
このように、本実施の形態では、端末２００は、URLLCに対応する上りリンクデータを含むPUSCH送信と、URLLCに対応するUCI（例えば、応答信号）を含むPUCCH送信と、が時間的に重なる場合、上りリンクデータ及びUCIの双方に対する要求条件に応じて、上りリンクデータ及びUCIに対する処理態様（送信方法又はパラメータ）を決定する。そして、端末２００は、決定された処理態様に基づいて、上りリンクデータ及びUCIの少なくとも一方を送信する。
【0258】
これにより、端末２００は、上りリンクデータ及びUCIの双方の信頼度に応じて適切な端末動作又はリソース割当を行い、URLLCに対応する上りリンク信号の要求条件を満たす上りリンク送信を行うことができる。
【0259】
以上より、本実施の形態によれば、端末２００は、上りリンク信号を適切に送信できる。
【0260】
【0261】
本実施の形態では、繰り返し送信（Repetition）を適用したPUCCH送信と、上りリンクデータを含むPUSCH送信とが時間的に重なる場合の端末２００における動作について説明する。
【0262】
Release 15 NRでは、Repetitionを適用したPUCCH送信と上りリンクデータを含むPUSCH送信とが時間的に重なる場合、PUSCH（上りリンクデータ）はドロップされる。Release 15 NRでは、信頼性、遅延要求及びユースケース(サービス)の種類が異なる応答信号及び上りリンクデータに関する動作が考慮されていない。
【0263】
そこで、本実施の形態では、端末２００は、応答信号の信頼度（例えば、応答信号の目標誤り率又は目標BLER）及び上りリンクデータの信頼度（例えば、上りリンクデータの目標誤り率又は目標BLER）に応じて、繰り返し送信される応答信号又は上りリンクデータの処理態様（例えば、送信方法又はパラメータ）を決定する。換言すると、端末２００は、応答信号の信頼度及び上りリンクデータの信頼度に応じて、応答信号又は上りリンクデータの送信方法又はパラメータに差異を生じさせる。
【0264】
以下、本実施の形態に係る動作例（Case 1, 2及び3）について説明する。
【0265】
[Case 1]
Case 1は、実施の形態１又は２と同様、URLLCに対応する応答信号を含むRepetitionを適用したPUCCH送信と、eMBBに対応する上りリンクデータを含むPUSCH送信とが時間的に重なる場合である。
Case 1は、実施の形態１又は２と同様、URLLCに対応する応答信号を含むRepetitionを適用したPUCCH送信と、eMBBに対応する上りリンクデータを含むPUSCH送信とが時間的に重なる場合である。
【0266】
例えば、URLLCにおいて、１回目のデータ送信の目標誤り率が高い（例えば、BLER=10-1）下りリンクデータに対する応答信号と、１回目のデータ送信の目標誤り率が低い（例えば、BLER=10-5）下りリンクデータに対する応答信号と、が送信され得る。目標誤り率が高い下りリンクデータに対する応答信号には高い信頼度が要求される。一方、目標誤り率が低い下りリンクデータに対する応答信号には高い信頼度が要求されない。
【0267】
そこで、端末２００は、例えば、高い信頼度が要求されない応答信号を含むRepetitionを適用したPUCCH送信と、eMBBに対応する上りリンクデータを含むPUSCH送信とが時間的に重なる場合、図１１に示すように、Release 15 NRと同様にPUSCH（上りリンクデータ）をドロップする。
【0268】
また、端末２００は、例えば、高い信頼度が要求される応答信号を含むRepetitionを適用したPUCCH送信と、eMBBに対応する上りリンクデータを含むPUSCH送信とが時間的に重なる場合、図１１に示すように、Release 15 NRと同様にPUSCH（上りリンクデータ）をドロップする。
【0269】
このように、Case 1では、端末２００は、URLLCに対応する応答信号を含むPUCCH（URLLC PUCCH）にRepetitionが適用された場合、応答信号の信頼度に依らず、時間的に重なるeMBB PUSCH（上りリンクデータ）をドロップする。
【0270】
[Case 2]
Case 2は、実施の形態３と同様に、eMBBに対応する応答信号を含むRepetitionを適用したPUCCH送信と、URLLCに対応する上りリンクデータを含むPUSCH送信とが時間的に重なる場合である。
Case 2は、実施の形態３と同様に、eMBBに対応する応答信号を含むRepetitionを適用したPUCCH送信と、URLLCに対応する上りリンクデータを含むPUSCH送信とが時間的に重なる場合である。
【0271】
例えば、URLLCにおいて、目標誤り率が高い(例えば、BLER=10-1)上りリンクデータと、目標誤り率が低い(例えば、BLER=10-5)上りリンクデータとが送信され得る。目標誤り率が高い上りリンクデータには高い信頼度が要求されない。一方、目標誤り率が低い上りリンクデータには高い信頼度が要求される。
【0272】
そこで、端末２００は、高い信頼度が要求されない上りリンクデータを含むPUSCH送信と、eMBBに対応する下りリンクデータに対する応答信号を含むRepetitionを適用したPUCCH送信とが時間的に重なる場合、Release 15 NRと同様、PUSCH（上りリンクデータ）をドロップする。
【0273】
一方、端末２００は、高い信頼度が要求される上りリンクデータを含むPUSCH送信と、eMBBに対応する下りリンクデータに対する応答信号を含むRepetitionを適用したPUCCH送信とが時間的に重なる場合、Release 15 NRとは異なる方法を用いて上りリンクデータを送信、又は、Release 15 NRとは異なるパラメータを用いて応答信号をPUSCHに多重する。
【0274】
高い信頼度が要求される上りリンクデータ（例えば、目標誤り率が所定値以下の上りリンクデータ）を含むPUSCH送信と、eMBBに対応する下りリンクデータを含むPUCCH送信とが時間的に重なる場合における応答信号のPUSCHへの多重方法の一例として、以下の3つの方法（Option 1, 2及び3）について説明する。
【0275】
[Option 1]
Option 1では、端末２００は、eMBBのPUCCH（例えば、応答信号）をドロップし（換言すると、送信をキャンセルし）、PUSCHを用いて上りリンクデータを送信する。このとき、端末２００は、Repetitionを適用したPUCCH（例えば、応答信号）を全てドロップしてもよく、URLLCに対応するPUSCHと時間的に重なるスロットのPUCCH（例えば、応答信号）をドロップして、URLLCに対応するPUSCHと時間的に重ならないスロットのPUCCH（例えば、応答信号）を送信してもよい。
Option 1では、端末２００は、eMBBのPUCCH（例えば、応答信号）をドロップし（換言すると、送信をキャンセルし）、PUSCHを用いて上りリンクデータを送信する。このとき、端末２００は、Repetitionを適用したPUCCH（例えば、応答信号）を全てドロップしてもよく、URLLCに対応するPUSCHと時間的に重なるスロットのPUCCH（例えば、応答信号）をドロップして、URLLCに対応するPUSCHと時間的に重ならないスロットのPUCCH（例えば、応答信号）を送信してもよい。
【0276】
図１２は、Option 1における端末２００の動作例を示す。
【0277】
図１２に示すように、URLLCに対応する上りリンクデータを含むPUSCH（URLLC PUSCH）の送信と、eMBBに対応する下りリンクデータに対する応答信号を含むPUCCH（eMBB PUCCH）の送信とが同一スロット内において発生する場合、端末２００は、当該スロットにおいて、eMBB PUCCH（応答信号）をドロップし、URLLC PUSCH（上りリンクデータ）を送信する。
【0278】
また、図１２に示すように、端末２００は、PUSCH送信とPUCCH送信とが重なるスロット以外のスロットでは、eMBB PUCCH（応答信号）を送信する。ただし、端末２００は、PUSCH送信とPUCCH送信とが重なるスロット以外のスロットにおいてもeMBB PUCCH（応答信号）をドロップしてもよい。または、端末２００は、PUSCH送信とPUCCH送信とが重なるスロットにおいてドロップした分のeMBB PUCCH（応答信号）を、後方のスロットにおいて送信（postpone）してもよい。
【0279】
Option 1によれば、高い信頼度が要求されるURLLCのためのPUSCH送信に対して、eMBBのPUCCH送信が影響を与えることがなくなるため、高い信頼度が要求される上りリンクデータの品質を保証できる。
【0280】
また、Option 1によれば、端末２００は単にeMBB PUCCH（応答信号）をドロップすればよく、端末２００において複雑な処理を要しないため、端末２００の実装が容易である利点がある。
【0281】
[Option 2]
Option 2では、端末２００は、同一スロット内において、eMBB PUCCHの送信区間のうち、URLLCのためのPUSCHの送信区間と時間的に重なる区間においてeMBBのPUCCH（例えば、応答信号）の送信を行わない（パンクチャする）。換言すると、端末２００は、同一スロット内において、eMBB PUCCHの送信区間のうち、URLLCのためのPUSCHの送信区間と時間的に重ならない区間においてPUCCHを用いて応答信号を送信する。
Option 2では、端末２００は、同一スロット内において、eMBB PUCCHの送信区間のうち、URLLCのためのPUSCHの送信区間と時間的に重なる区間においてeMBBのPUCCH（例えば、応答信号）の送信を行わない（パンクチャする）。換言すると、端末２００は、同一スロット内において、eMBB PUCCHの送信区間のうち、URLLCのためのPUSCHの送信区間と時間的に重ならない区間においてPUCCHを用いて応答信号を送信する。
【0282】
図１３は、Option 2における端末２００の動作例を示す。
【0283】
図１３に示すように、URLLCに対応する上りリンクデータを含むPUSCH（URLLC PUSCH）の送信と、eMBBに対応する下りリンクデータに対する応答信号を含むPUCCH（eMBB PUCCH）の送信とが同一スロット内において発生する場合、端末２００は、URLLC PUSCH（上りリンクデータ）を送信する。また、図１３に示すように、端末２００は、同一スロット内において、eMBB PUCCHの送信区間のうち、URLLC PUSCHの送信区間と時間的に重なる区間においてeMBB PUCCH（例えば、応答信号）をパンクチャし、URLLC PUSCHの送信区間と時間的に重なる区間以外の区間においてeMBB PUCCH（例えば、応答信号）を送信する。
【0284】
また、図１３に示すように、端末２００は、PUSCH送信とPUCCH送信とが重ならないスロットでは、eMBB PUCCH（例えば、応答信号）を送信する。
【0285】
eMBBに対応する送信では、送信するデータ量が比較的多い。このため、eMBBに対応する送信は、スロット単位の送信（例えば、１スロット全て又は１スロットの大半を使用する送信)となる。一方、URLLCに対応する送信では、送信するデータ量が比較的少ない。また、URLLCに対応する送信は、低遅延を実現するために、非スロット単位の送信（例えば、数シンボルを使用する送信）を用いることが主なユースケースであると想定される。
【0286】
よって、eMBBに対応する送信に対してURLLCに対応する送信が時間的に重なる区間は、図１３に示すように、スロット内における数シンボル、つまり、eMBBに対応する送信区間の一部であることが想定される。このため、端末２００は、URLLCに対応する送信以降のeMBBに対応する送信を全てドロップせずに、図１３に示すように、eMBBに対応する送信区間のうち、URLLCに対応する送信区間と時間的に重なる区間の送信を行わない（パンクチャする）ことにより、eMBBの伝送品質及び周波数利用効率の劣化を抑圧できる。
【0287】
[Option 3]
Option 3では、端末２００は、eMBBのための応答信号をURLLCのPUSCHに多重して送信する。このとき、端末２００は、応答信号をPUSCHに多重した後、Repetitionを適用したPUCCH（応答信号）の全てをドロップしてもよく、URLLCに対応するPUSCHと時間的に重なるスロットのPUCCH（応答信号）をドロップしてもよい。
Option 3では、端末２００は、eMBBのための応答信号をURLLCのPUSCHに多重して送信する。このとき、端末２００は、応答信号をPUSCHに多重した後、Repetitionを適用したPUCCH（応答信号）の全てをドロップしてもよく、URLLCに対応するPUSCHと時間的に重なるスロットのPUCCH（応答信号）をドロップしてもよい。
【0288】
図１４は、Option 3における端末２００の動作例を示す。
【0289】
図１４に示すように、eMBBに対応する応答信号を含むPUCCH（eMBB PUCCH）の送信と、URLLCに対応する上りリンクデータを含むPUSCH（URLLC PUSCH）の送信とが同一スロット内において発生する場合、端末２００は、eMBB PUCCHに含まれる応答信号（換言すると、eMBB UCI）を、PUSCHに多重する。そして、端末２００は、応答信号（eMBB UCI）が多重されたURLLC PUSCHの信号を送信する。
【0290】
また、図１４に示すように、端末２００は、PUSCH送信とPUCCH送信とが重ならないスロットにおいて、eMBB PUCCH（応答信号）を送信する。
【0291】
また、本実施の形態では、応答信号をPUSCHに多重して送信する場合のPUSCH内において応答信号に割り当てるリソース量は、実施の形態３と同様の方法に従って決定されてもよい。
【0292】
これにより、端末２００は、上りリンクデータ（又はPUSCH）の信頼度に応じて、PUSCHにおいて応答信号に対して適切なリソースを割り当てることが可能になる。
【0293】
以上、Case 2における、応答信号のPUSCHへの多重方法の一例（Option 1, 2及び3）について説明した。
【0294】
[Case 3]
Case 3は、実施の形態４と同様、URLLCに対応する応答信号を含むPUCCH送信と、URLLCに対応する上りリンクデータを含むPUSCH送信とが時間的に重なる場合である。
Case 3は、実施の形態４と同様、URLLCに対応する応答信号を含むPUCCH送信と、URLLCに対応する上りリンクデータを含むPUSCH送信とが時間的に重なる場合である。
【0295】
応答信号については、例えば、URLLCにおいて、１回目のデータ送信の目標誤り率が高い（例えば、BLER=10-1）下りリンクデータに対する応答信号、及び、１回目のデータ送信の目標誤り率が低い（例えば、BLER=10-5）下りリンクデータに対する応答信号が送信され得る。前者の応答信号には高い信頼度が要求される一方、後者の応答信号には高い信頼度が要求されない。
【0296】
また、上りリンクデータについては、例えば、URLLCにおいて、目標誤り率が高い（例えば、BLER=10-1）上りリンクデータ、及び、目標誤り率が低い（例えばBLER=10-5）上りリンクデータが送信され得る。前者の上りリンクデータには高い信頼度が要求されない一方、後者の上りリンクデータには高い信頼度が要求される。
【0297】
そこで、上述した応答信号の信頼度と、上りリンクデータの信頼度との組み合わせに応じて、送信方法に差異を生じさせてもよい。
【0298】
まず、高い信頼度が要求されない応答信号を含むRepetitionを適用したPUCCH送信と、高い信頼度が必要とされる上りリンクデータを含むPUSCH送信とが時間的に重なる場合、上りリンクデータの信頼度の方が応答信号の信頼度よりも高い。そこで、端末２００は、例えば、Case 2で説明した方法に基づいて、Release 15 NRとは異なる方法を用いて上りリンクデータを送信、又は、Release 15 NRとは異なるパラメータを用いて、応答信号をPUSCHに多重する。
【0299】
次に、高い信頼度が要求される応答信号を含むRepetitionを適用したPUCCH送信と、高い信頼度が要求される上りリンクデータを含むPUSCH送信とが時間的に重なる場合、応答信号の信頼度と上りリンクデータの信頼度とは同等である。そこで、端末２００は、例えば、Release 15 NRと同様にPUSCHをドロップする。
【0300】
次に、高い信頼度が要求されない応答信号を含むRepetitionを適用したPUCCH送信と、高い信頼度が要求されない上りリンクデータを含むPUSCH送信とが時間的に重なる場合、応答信号の信頼度と上りリンクデータの信頼度とは同等である。そこで、端末２００は、例えば、Release 15 NRと同様にPUSCHをドロップする。
【0301】
最後に、高い信頼度が要求される応答信号を含むRepetitionを適用したPUCCH送信と、高い信頼度が要求されない上りリンクデータを含むPUSCH送信とが時間的に重なる場合、応答信号の信頼度の方が上りリンクデータの信頼度よりも高く、応答信号の信頼度が優先されるべきである。そこで、端末２００は、例えば、Case 1で説明した方法により、PUSCHをドロップする。
【0302】
以上、本実施の形態に係る動作例（Case 1, 2及び3）について説明した。
【0303】
このように、本実施の形態では、端末２００は、上りリンクデータを含むPUSCH送信と、繰り返し送信されるUCI（例えば、応答信号）を含むPUCCH送信と、が時間的に重なる場合、上りリンクデータ及びUCIの双方に対する要求条件に応じて、上りリンクデータ及びUCIに対する処理態様（送信方法又はパラメータ）を決定する。そして、端末２００は、決定された処理態様に基づいて、上りリンクデータ及びUCIの少なくとも一方を送信する。
【0304】
これにより、端末２００は、上りリンクデータ及びUCIの双方の信頼度に応じて適切な端末動作又はリソース割当を行い、URLLCに対応する上りリンク信号の要求条件を満たす上りリンク送信を行うことができる。
【0305】
以上より、本実施の形態によれば、端末２００は、上りリンク信号を適切に送信できる。
【0306】
なお、NRでは、上りリンクデータを含むPUSCH送信に対して、基地局からのUL grantによりPUSCHを送信する無線リソースを動的に指示される「GrantベースのPUSCH送信」と、基地局からのUL grant無しに、端末が、データが発生した時点で予め準静的に割り当てられた無線リソースを用いてPUSCHを送信する「Grant-freeのPUSCH送信」(又は、「Configured grant PUSCH送信」とも呼ぶ)とがサポートされる。
【0307】
端末２００がUCIをPUSCHに多重して送信する場合、GrantベースのPUSCH送信では、基地局１００は、UCIをPUSCHに多重することが分かっているので、Grant（UL grant）によって無線リソースを指示する際に、UCIの多重を考慮した無線リソースを割り当てることができる。一方、Grant-freeのPUSCH送信では、基地局１００は、端末２００に対して、UCIの多重を考慮した無線リソースを事前に割り当てることができない。
【0308】
そこで、GrantベースのPUSCH送信とGrant-freeのPUSCH送信とで、Option 1、Option 2又はOption 3を切り替えて適用してもよい。例えば、端末２００は、GrantベースのPUSCH送信ではOption 3を適用してUCIをPUSCHへ多重して送信する。一方、端末２００は、Grant-freeのPUSCH送信では、Option 1又はOption 2を適用してPUSCH又はPUCCHをドロップする。これにより、端末２００は、GrantベースのPUSCH送信及びGrant-freeのPUSCH送信に応じて、応答信号を適切に送信できる。
【0309】
以上、本開示の各実施の形態について説明した。
【0310】
（１）上記実施の形態では、応答信号の信頼度、遅延要求又はユースケース(またはサービス)の種類に応じて、上りリンクの送信方法、及びパラメータに差異を生じさせた。
【0311】
ここで、上りリンクの送信方法、及びパラメータに差異を生じさせる例としては、応答信号の信頼度が異なる場合がある。例えば、URLLCにおいて、１回目のデータ送信の目標誤り率が高い（例えば、BLER=10-1）下りリンクデータに対する応答信号と、１回目のデータ送信の目標誤り率が低い（例えば、BLER=10-5）下りリンクデータに対する応答信号とで、上りリンクの送信方法、及びパラメータに差異を生じさせることができる。前者の応答信号には高い信頼度が要求される一方、後者の応答信号にはそれほど高い信頼度が要求されない。
【0312】
また、上りリンクの送信方法、及びパラメータに差異を生じさせる例として、応答信号の遅延要求が異なる場合又はユースケース(またはサービス)が異なる場合がある。例えば、URLLCに対応する応答信号とeMBBに対応する応答信号とで、上りリンクの送信方法、及びパラメータに差異を生じさせることもできる。前者の応答信号には高い信頼度又は低遅延が要求される一方、後者の応答信号にはそれほど高い信頼度又は低遅延が要求されない。また、URLLCには、上述したように、１回目のデータ送信の目標誤り率が高い(例えば、BLER=10-1)下りリンクデータに対する応答信号と、１回目のデータ送信の目標誤り率が低い(例えば、BLER=10-5)下りリンクデータに対する応答信号とが含まれる場合がある。
【0313】
また、上りリンクの送信方法の差異を生じさせる例としては、信頼度、遅延要求又はユースケース(サービス)の種類に限らず、例えば、物理層のパラメータが異なる場合でもよい。例えば、eMBBを「スロット単位の送信」と置き換え、URLLCを「非スロット単位の送信」と置き換えてもよい。また、eMBBを「PDSCH mapping type A」又は「PUSCH mapping type A」と置き換え、URLLCを「PDSCH mapping type B」又は「PUSCH mapping type B」と置き換えてもよい。また、eMBB及びURLLCに対応する送信に限定されず、例えば、eMBBを送信区間(例えば、スロット長又はシンボル長)が長い送信と置き換え、URLLCを前述の送信区間よりも送信区間が短い送信と置き換えてもよい。
【0314】
また、本開示において、目標誤り率は、上述したように１回目のデータ送信の目標誤り率でもよく、再送が発生する場合は、再送における目標誤り率でもよい。また、目標誤り率は、１回目及び再送の各々の目標誤り率という意味で「瞬時目標誤り率」と呼んでもよい。
【0315】
（２）上記実施の形態において説明した、応答信号の「信頼度、遅延要求又はユースケース(またはサービス)の種類」（換言すると、要求条件）を判断する方法には、例えば、以下の例１～例５のような方法がある。
【0316】
[例１：スクランブル系列]
例１では、端末２００は、各応答信号に対応する下りリンクデータ伝送をスケジューリングするDCIに用いられる端末固有のスクランブリング系列に基づいて、応答信号の信頼度、遅延要求又はユースケース(サービス)の種類を判断する。
例１では、端末２００は、各応答信号に対応する下りリンクデータ伝送をスケジューリングするDCIに用いられる端末固有のスクランブリング系列に基づいて、応答信号の信頼度、遅延要求又はユースケース(サービス)の種類を判断する。
【0317】
例えば、eMBBを想定したPDSCH用のDCIでは、端末固有のスクランブリング系列に、C-RNTI（Cell-Radio Network Temporary Identifier）又はCS-RNTI（Configured Scheduling-RNTI）等が用いられる。そこで、端末２００は、検出したスクランブリング系列がC-RNTI及びCS-RNTIと異なる場合、応答信号の信頼度が高い、遅延要求が厳しい、又は、URLLCであると判断する。また、端末２００は、検出したスクランブリング系列がC-RNTI又はCS-RNTIである場合、応答信号の信頼度が高くない、遅延要求が厳しくない、又は、eMBBであると判断する。
【0318】
例えば、基地局１００の制御部１０１（例えば、図２を参照）は、端末２００の下りリンクデータの信頼度、遅延要求又はユースケース(サービス)の種類に関する情報を決定する。決定した情報は、基地局１００の下り制御信号生成部１０９へ出力される。下り制御信号生成部１０９は、上述したように、端末２００の下りリンクデータの信頼度、遅延要求又はユースケース(またはサービス)の種類に応じたスクランブリング系列を用いてDCIのビット列を生成する。
【0319】
一方、端末２００の復号部２０６（例えば、図３を参照）は、検出したスクランブリング系列を制御部２１１へ出力する。制御部２１１は、得られたスクランブリング系列に基づいて、下りリンクデータの信頼度、遅延要求又はユースケース(サービス)の種類に関する情報を判断する。
【0320】
[例２：MCSテーブル]
例２では、端末２００は、各応答信号に対応する下りリンクデータ伝送のスケジューリングに用いられるMCSテーブルに基づいて、応答信号の信頼度、遅延要求又はユースケース（サービス）の種類を判断する。
例２では、端末２００は、各応答信号に対応する下りリンクデータ伝送のスケジューリングに用いられるMCSテーブルに基づいて、応答信号の信頼度、遅延要求又はユースケース（サービス）の種類を判断する。
【0321】
例えば、Release 15 NRでは、目標BLER=10-1を達成するためのMCSテーブル、及び、目標BLER=10-5を達成するためのMCSテーブルの何れを用いるかを設定できる。
【0322】
例えば、端末２００は、URLLCにおいて設定されたMCSテーブルが目標BLER=10-1を達成するためのMCSテーブルである場合、応答信号に要求される信頼度が高いと判断する。一方、端末２００は、URLLCにおいて設定されたMCSテーブルが目標BLER=10-5を達成するためのMCSテーブルである場合、応答信号に要求される信頼度は高くないと判断する。
【0323】
例えば、基地局１００の制御部１０１は、端末２００の下りリンクデータの信頼度、遅延要求又はユースケース(サービス)の種類に関する情報を決定する。決定した情報は、基地局１００の下り制御信号生成部１０９、符号化部１０３及び変調部１０５へ出力される。下り制御信号生成部１０９は、下りリンクデータ伝送に用いられるMCSテーブルに関する情報をDCIのビット列に含める。また、符号化部１０３及び変調部１０５は、制御部１０１から入力されるMCSテーブルに関する情報を用いて、下りリンクデータを符号化及び変調する。
【0324】
一方、端末２００の復号部２０６は、DCIを復号し、復号結果を制御部２１１へ出力する。制御部２１１は、DCIから得られるMCSテーブルに関する情報に基づいて、下りリンクデータの信頼度、遅延要求又はユースケース(サービス)の種類に関する情報を判断する。
【0325】
[例３：PDSCH-to-HARQ-ACK timing又はPDSCHの送信シンボル数]
例３では、端末２００は、各応答信号に対応する下りリンクデータ伝送をスケジューリングするDCIによって通知された「PDSCH-to-HARQ-ACK timing」又はPDSCHの送信シンボル数に基づいて、応答信号の信頼度、遅延要求又はユースケース(サービス)の種類を判断する。
例３では、端末２００は、各応答信号に対応する下りリンクデータ伝送をスケジューリングするDCIによって通知された「PDSCH-to-HARQ-ACK timing」又はPDSCHの送信シンボル数に基づいて、応答信号の信頼度、遅延要求又はユースケース(サービス)の種類を判断する。
【0326】
例えば、端末２００は、PDSCH-to-HARQ-ACK timingが所定の値以下、又は、PDSCHの送信シンボル数が所定のシンボル数以下である場合、応答信号の遅延要求が厳しい又はURLLCのための応答信号であると判断する。一方、端末２００は、PDSCH-to-HARQ-ACK timingが所定の値より大きい、又は、PDSCHの送信シンボル数が所定のシンボル数より多い場合、応答信号の遅延要求が厳しくない又はeMBBのための応答信号であると判断する。
【0327】
なお、上記所定の値又は所定のシンボル数は、規格において予め決まった値でもよく、基地局１００が上位レイヤ信号によって端末２００へ設定可能な値でもよい。
【0328】
例えば、基地局１００の制御部１０１は、端末２００の下りリンクデータに対する応答信号を送信するスロット位置を示すPDSCH-to-HARQ-ACK timing又はPDSCHの送信シンボル数を決定する。決定した情報は、基地局１００の下り制御信号生成部１０９、信号割当部１１２及び抽出部１１８へ出力される。下り制御信号生成部１０９は、PDSCH-to-HARQ-ACK timing又はPDSCHの送信シンボル数に関する情報をDCIのビット列に含める。
【0329】
一方、端末２００の復号部２０６は、DCIを復号し、復号結果を制御部２１１へ出力する。制御部２１１は、DCIから得られるPDSCH-to-HARQ-ACK timing又はPDSCHの送信シンボル数に関する情報に基づいて、下りリンクデータの信頼度、遅延要求又はユースケース(サービス)の種類に関する情報を判断する。
【0330】
[例４：CQIテーブル]
例４では、端末２００は、各応答信号に対応する下りリンクデータ伝送用に設定されるCQIテーブルに基づいて、応答信号の信頼度、遅延要求又はユースケース(サービス)の種類を判断する。
例４では、端末２００は、各応答信号に対応する下りリンクデータ伝送用に設定されるCQIテーブルに基づいて、応答信号の信頼度、遅延要求又はユースケース(サービス)の種類を判断する。
【0331】
例えば、Release 15 NRでは、目標BLER=10-1を達成するためのCQIテーブル、及び、目標BLER=10-5を達成するためのCQIテーブルの何れを用いるかを設定できる。
【0332】
例えば、端末２００は、URLLCにおいて設定されたCQIテーブルが目標BLER=10-1を達成するためのCQIテーブルである場合、応答信号に要求される信頼度が高いと判断する。一方、URLLCにおいて設定されたCQIテーブルが目標BLER=10-5を達成するためのCQIテーブルである場合、応答信号に要求される信頼度は高くないと判断する。
【0333】
例えば、基地局１００の制御部１０１は、端末２００の下りリンクデータ伝送用に設定されるCQIテーブルに関する情報を決定する。決定した情報は、上位制御信号生成部１０６へ出力される。上位制御信号生成部１０６は、CQIテーブルに関する情報を上位制御信号に含める。
【0334】
一方、端末２００の復号部２０８は、上位制御信号を復号し、復号結果を制御部２１１へ出力する。制御部２１１は、上位制御信号から得られるCQIテーブルに関する情報に基づいて、下りリンクデータの信頼度、遅延要求又はユースケース(サービス)の種類に関する情報を判断する。
【0335】
[例５：DCIによる明示的な通知]
例５では、端末２００は、各応答信号に対応する下りリンクデータ伝送をスケジューリングするDCI内の数ビットによる明示的な通知により、応答信号の信頼度、遅延要求又はユースケース(サービス)の種類を判断する。
例５では、端末２００は、各応答信号に対応する下りリンクデータ伝送をスケジューリングするDCI内の数ビットによる明示的な通知により、応答信号の信頼度、遅延要求又はユースケース(サービス)の種類を判断する。
【0336】
明示的な通知は、応答信号自体の信頼度、遅延要求又はユースケース(サービス)の種類に関する情報でもよく、PDSCHの信頼度(例えば目標BLER)、遅延要求又はユースケース(サービス)の種類に関する情報でもよい。
【0337】
例えば、基地局１００の制御部１０１は、端末２００の下りリンクデータに対する応答信号の信頼度、遅延要求又はユースケース(サービス)の種類に関する情報を決定する。決定された情報は、下り制御信号生成部１０９へ出力される。下り制御信号生成部１０９は、ACK/NACKの信頼度、遅延要求又はユースケース(サービス)の種類に関する情報をDCIのビット列に含める。
【0338】
一方、端末２００の復号部２０６は、DCIを復号し、復号結果を制御部２１１へ出力する。制御部２１１は、DCIから応答信号の信頼度、遅延要求又はユースケース(サービス)の種類に関する情報を得る。
【0339】
以上、「応答信号の信頼度、遅延要求又はユースケース(またはサービス)の種類」を判断する方法について説明した。なお、「応答信号の信頼度、遅延要求又はユースケース(またはサービス)の種類」を判断する方法は、上述した例１～例５に限定されず、要求条件に関する他の情報に基づく判断方法でもよい。
【0340】
（３）また、上記実施の形態では、下りリンクデータ伝送に対する応答信号がPUCCH又はPUSCHを用いて送信される場合を一例として説明した。しかし、本開示においてPUCCH又はPUSCHを用いて送信されるUCIは応答信号に限らない。例えば、上記実施の形態において、「応答信号（ACK/NACK又はHARQ-ACK）」をチャネル状態情報（CSI)に置き換えてもよく、応答信号とCSIとを含むUCIに置き換えてもよい。
【0341】
（４）また、本開示はソフトウェア、ハードウェア、又は、ハードウェアと連携したソフトウェアで実現することが可能である。上記実施の形態の説明に用いた各機能ブロックは、部分的に又は全体的に、集積回路であるＬＳＩとして実現され、上記実施の形態で説明した各プロセスは、部分的に又は全体的に、一つのＬＳＩ又はＬＳＩの組み合わせによって制御されてもよい。ＬＳＩは個々のチップから構成されてもよいし、機能ブロックの一部または全てを含むように一つのチップから構成されてもよい。ＬＳＩはデータの入力と出力を備えてもよい。ＬＳＩは、集積度の違いにより、ＩＣ、システムＬＳＩ、スーパーＬＳＩ、ウルトラＬＳＩと呼称されることもある。集積回路化の手法はＬＳＩに限るものではなく、専用回路、汎用プロセッサ又は専用プロセッサで実現してもよい。また、ＬＳＩ製造後に、プログラムすることが可能なＦＰＧＡ（Field Programmable Gate Array）や、ＬＳＩ内部の回路セルの接続や設定を再構成可能なリコンフィギュラブル・プロセッサを利用してもよい。本開示は、デジタル処理又はアナログ処理として実現されてもよい。さらには、半導体技術の進歩または派生する別技術によりＬＳＩに置き換わる集積回路化の技術が登場すれば、当然、その技術を用いて機能ブロックの集積化を行ってもよい。バイオ技術の適用等が可能性としてありえる。
【0342】
本開示は、通信機能を持つあらゆる種類の装置、デバイス、システム（通信装置と総称）において実施可能である。通信装置の、非限定的な例としては、電話機（携帯電話、スマートフォン等）、タブレット、パーソナル・コンピューター（ＰＣ）（ラップトップ、デスクトップ、ノートブック等）、カメラ（デジタル・スチル／ビデオ・カメラ等）、デジタル・プレーヤー（デジタル・オーディオ／ビデオ・プレーヤー等）、着用可能なデバイス（ウェアラブル・カメラ、スマートウオッチ、トラッキングデバイス等）、ゲーム・コンソール、デジタル・ブック・リーダー、テレヘルス・テレメディシン（遠隔ヘルスケア・メディシン処方）デバイス、通信機能付きの乗り物又は移動輸送機関（自動車、飛行機、船等）、及び上述の各種装置の組み合わせがあげられる。
【0343】
通信装置は、持ち運び可能又は移動可能なものに限定されず、持ち運びできない又は固定されている、あらゆる種類の装置、デバイス、システム、例えば、スマート・ホーム・デバイス（家電機器、照明機器、スマートメーター又は計測機器、コントロール・パネル等）、自動販売機、その他ＩｏＴ（Ｉｎｔｅｒｎｅｔ ｏｆ Ｔｈｉｎｇｓ）ネットワーク上に存在し得るあらゆる「モノ（Things）」をも含む。
【0344】
通信には、セルラーシステム、無線ＬＡＮシステム、通信衛星システム等によるデータ通信に加え、これらの組み合わせによるデータ通信も含まれる。
【0345】
また、通信装置には、本開示に記載される通信機能を実行する通信デバイスに接続又は連結される、コントローラやセンサー等のデバイスも含まれる。例えば、通信装置の通信機能を実行する通信デバイスが使用する制御信号やデータ信号を生成するような、コントローラやセンサーが含まれる。
【0346】
また、通信装置には、上記の非限定的な各種装置と通信を行う、あるいはこれら各種装置を制御する、インフラストラクチャ設備、例えば、基地局、アクセスポイント、その他あらゆる装置、デバイス、システムが含まれる。
【0347】
本開示の一実施例における端末は、上りリンクデータを含む上りリンクデータチャネルの送信と、上りリンク制御情報を含む上りリンク制御チャネルの送信と、が時間的に重なる場合、前記上りリンクデータ及び前記上りリンク制御情報の少なくとも一方に対する要求条件に応じて、前記上りリンクデータ及び前記上りリンク制御情報に対する処理態様を決定する回路と、前記決定された処理態様に基づいて、前記上りリンクデータ及び前記上りリンク制御情報の少なくとも一方を送信する送信機と、を具備する端末。
【0348】
本開示の一実施例における端末において、前記要求条件には目標誤り率が含まれ、前記回路は、前記上りリンク制御情報の前記目標誤り率に応じて、前記上りリンクデータ及び前記上りリンク制御情報の前記処理態様を決定する。
【0349】
本開示の一実施例における端末において、前記送信機は、前記上りリンク制御情報の前記目標誤り率が所定値以下の場合、前記上りリンクデータをドロップし、前記上りリンク制御チャネルを用いて前記上りリンク制御情報を送信する。
【0350】
本開示の一実施例における端末において、前記送信機は、前記上りリンク制御情報の前記目標誤り率が所定値以下の場合、前記上りリンクデータチャネルの送信区間のうち、前記上りリンク制御チャネルの送信区間と重なる区間において前記上りリンクデータをパンクチャし、前記上りリンク制御チャネルの送信区間と重なる区間以外の区間において前記上りリンクデータを送信し、前記上りリンク制御チャネルを用いて前記上りリンク制御情報を送信する。
【0351】
本開示の一実施例における端末において、前記送信機は、前記上りリンク制御情報の前記目標誤り率が所定値以下の場合、前記上りリンク制御情報を、前記上りリンクデータチャネルに多重して送信する。
【0352】
本開示の一実施例における端末において、前記上りリンク制御情報は、下りリンクデータに対する応答信号であり、前記上りリンクデータチャネルにおいて前記応答信号に要するリソース量を制御するためのパラメータ、及び、前記リソース量の上限値を制御するためのパラメータの少なくとも１つは、前記応答信号の前記要求条件に応じて設定される。
【0353】
本開示の一実施例における端末において、前記上りリンク制御情報は、下りリンクデータに対する応答信号であり、前記上りリンクデータチャネルにおいて前記応答信号に要するリソース量が、前記リソース量の上限値を超える場合、前記送信機は、前記上りリンクデータチャネルにおいて、前記上りリンクデータをドロップし、前記応答信号を送信する。
【0354】
本開示の一実施例における端末において、前記上りリンク制御情報は、下りリンクデータに対する応答信号であり、前記上りリンクデータチャネルにおいて前記応答信号に要するリソース量が、前記リソース量の上限値を超える場合、前記回路は、前記上りリンクデータチャネルの送信電力を増加する。
【0355】
本開示の一実施例における端末において、前記上りリンクデータチャネルの送信電力が、前記端末の最大送信電力を超える場合、前記送信機は、前記上りデータチャネルにおいて、前記上りリンクデータをドロップし、前記応答信号を前記最大送信電力で送信する。
【0356】
本開示の一実施例における端末において、基地局から前記端末へ特定のパラメータが通知された場合、前記送信機は、前記上りリンクデータチャネルにおいて、前記上りリンクデータをドロップし、前記上りリンク制御情報を送信する。
【0357】
本開示の一実施例における端末において、前記回路は、前記上りリンク制御情報の前記要求条件に応じて、前記上りリンクデータチャネルにおける前記上りリンク制御情報の前記処理態様を決定する。
【0358】
本開示の一実施例における端末において、前記上りリンクデータチャネルの送信には、基地局から前記端末へ動的に指示されるリソースを用いる送信と、前記端末に対して準静的に割り当てられているリソースを用いる送信とが含まれる。
【0359】
本開示の一実施例における端末において、前記要求条件には目標誤り率が含まれ、前記回路は、前記上りリンクデータの前記目標誤り率に応じて、前記上りリンクデータ及び前記上りリンク制御情報の前記処理態様を決定する。
【0360】
本開示の一実施例における端末において、前記送信機は、前記上りリンクデータの前記目標誤り率が所定値以下の場合、前記上りリンク制御チャネルにおける前記上りリンク制御情報をドロップし、前記上りリンクデータチャネルを用いて前記上りリンクデータを送信する。
【0361】
本開示の一実施例における端末において、前記送信機は、前記上りリンクデータの前記目標誤り率が所定値以下の場合、前記上りリンク制御チャネルの送信区間のうち、前記上りリンクデータチャネルの送信区間と重なる区間において前記上りリンク制御情報をパンクチャし、前記上りリンクデータチャネルの送信区間と重なる区間以外の区間において前記上りリンク制御情報を送信する。
【0362】
本開示の一実施例における端末において、前記送信機は、前記上りリンクデータの前記目標誤り率が所定値以下の場合、前記上りリンク制御情報を、前記上りリンクデータチャネルに多重して送信する。
【0363】
本開示の一実施例における端末において、前記上りリンク制御情報は、下りリンクデータに対する応答信号であり、前記上りリンクデータチャネルにおいて前記応答信号に要するリソース量を制御するためのパラメータ、及び、前記リソース量の上限値を制御するためのパラメータの少なくとも１つは、前記上りリンクデータの前記要求条件に応じて設定される。
【0364】
本開示の一実施例における端末において、基地局から前記端末へ特定のパラメータが通知された場合、前記送信機は、前記上りリンク制御チャネルにおける前記上りリンク制御情報をドロップし、前記上りリンクデータチャネルを用いて前記上りリンクデータ信号を送信する。
【0365】
本開示の一実施例における端末において、前記上りデータチャネルの送信には、基地局から前記端末へ動的に指示されるリソースを用いる送信と、前記端末に対して準静的に割り当てられているリソースを用いる送信とが含まれる。
【0366】
本開示の一実施例における端末において、前記要求条件には目標誤り率が含まれ、前記回路は、前記上りリンクデータの前記目標誤り率、及び、前記上りリンク制御情報の前記目標誤り率に応じて、前記上りリンクデータ及び前記上りリンク制御情報の前記処理態様を決定する。
【0367】
本開示の一実施例における端末において、前記要求条件には目標誤り率が含まれ、前記回路は、前記上りリンクデータの前記目標誤り率、及び、繰り返し送信される前記上りリンク制御情報の前記目標誤り率に応じて、前記上りリンクデータ信号及び前記上りリンク制御情報の前記処理態様を決定する。
【0368】
本開示の一実施例における端末において、前記上りデータチャネルの送信には、基地局から前記端末へ動的に指示されるリソースを用いる送信と、前記端末に対して準静的に割り当てられているリソースを用いる送信とが含まれる。
【0369】
本開示の一実施例における通信方法は、上りリンクデータを含む上りリンクデータチャネルの送信と、上りリンク制御情報を含む上りリンク制御チャネルの送信と、が時間的に重なる場合、前記上りリンクデータ及び前記上りリンク制御情報の少なくとも一方に対する要求条件に応じて、前記上りリンクデータ及び前記上りリンク制御情報に対する処理態様を決定し、前記決定された処理態様に基づいて、前記上りリンクデータ及び前記上りリンク制御情報の少なくとも一方を送信する。
【0370】
２０１８年８月１日出願の特願２０１８－１４４９８４の日本出願に含まれる明細書、図面および要約書の開示内容は、すべて本願に援用される。
【産業上の利用可能性】
【0371】
本開示の一実施例は、移動通信システムに有用である。
【符号の説明】
【0372】
１００ 基地局
１０１，２１１ 制御部
１０２ データ生成部
１０３，１０７，１１０，２１２，２１４ 符号化部
１０４ 再送制御部
１０５，１０８，１１１，２１３，２１５ 変調部
１０６ 上位制御信号生成部
１０９ 下り制御信号生成部
１１２，２１６ 信号割当部
１１３，２１７ IFFT部
１１４，２１８ 送信部
１１５，２０１ アンテナ
１１６，２０２ 受信部
１１７，２０３ FFT部
１１８，２０４ 抽出部
１１９，１２２ 復調部
１２０，１２３，２０６，２０８，２１０ 復号部
１２１，１２４ 判定部
２００ 端末
２０５ 下り制御信号復調部
２０７ 上位制御信号復調部
２０９ データ復調部
１０１，２１１ 制御部
１０２ データ生成部
１０３，１０７，１１０，２１２，２１４ 符号化部
１０４ 再送制御部
１０５，１０８，１１１，２１３，２１５ 変調部
１０６ 上位制御信号生成部
１０９ 下り制御信号生成部
１１２，２１６ 信号割当部
１１３，２１７ IFFT部
１１４，２１８ 送信部
１１５，２０１ アンテナ
１１６，２０２ 受信部
１１７，２０３ FFT部
１１８，２０４ 抽出部
１１９，１２２ 復調部
１２０，１２３，２０６，２０８，２１０ 復号部
１２１，１２４ 判定部
２００ 端末
２０５ 下り制御信号復調部
２０７ 上位制御信号復調部
２０９ データ復調部
【図1】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
【図11】
【図12】
【図13】
【図14】