特許 7546717 基地局、通信方法及び集積回路

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

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

(11)【特許番号】

(24)【登録日】2024-08-29

(45)【発行日】2024-09-06

(54)【発明の名称】基地局、通信方法及び集積回路

(51)【国際特許分類】

   H04W 72/56 20230101AFI20240830BHJP

   H04W 28/04 20090101ALI20240830BHJP

   H04W 72/0446 20230101ALI20240830BHJP

   H04W 72/21 20230101ALI20240830BHJP

   H04W 72/23 20230101ALI20240830BHJP

   H04W 72/512 20230101ALI20240830BHJP

【ＦＩ】

H04W72/56

H04W28/04 110

H04W72/0446

H04W72/21

H04W72/23

H04W72/512

【請求項の数】 17

(21)【出願番号】P 2023067124

(22)【出願日】2023-04-17

(62)【分割の表示】P 2020534054の分割

【原出願日】2019-03-25

(65)【公開番号】P2023099023

(43)【公開日】2023-07-11

【審査請求日】2023-04-17

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

(32)【優先日】2018-08-01

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

(73)【特許権者】

【識別番号】514136668

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

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

(74)【代理人】

【識別番号】110002952

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

(72)【発明者】

【氏名】山本 哲矢

(72)【発明者】

【氏名】リ ホンチャオ

(72)【発明者】

【氏名】鈴木 秀俊

(72)【発明者】

【氏名】岩井 敬

【審査官】三枝 保裕

(56)【参考文献】

【文献】国際公開第２０１８／０５６７８６（ＷＯ，Ａ１）

【文献】OPPO，Summary of offline discussion on PUCCH resource allocation，3GPP TSG RAN WG1 #92 R1-1803428，2018年03月02日

【文献】Panasonic，Discussion on SR for URLLC and multiplexing with HARQ-ACK，3GPP TSG RAN WG1 adhoc_NR_AH_1706 R1-1710942，2017年06月30日

【文献】Qualcomm Incorporated，Considerations for URLLC resource allocation for PUCCH，3GPP TSG RAN WG1 #93 R1-1807362，2018年05月25日

【文献】Huawei, HiSilicon，Resource allocation for PUCCH HARQ-ACK feedback，3GPP TSG RAN WG1 #91 R1-1719398，2017年12月01日

【文献】Spreadtrum Communications，Considerations on PUCCH resource allocation for NR，3GPP TSG RAN WG1 #90b R1-1717749，2017年10月13日

【文献】Panasonic，Discussion on resource allocation for uplink control channel，3GPP TSG RAN WG1 #90b R1-1718260，2017年10月13日

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

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

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

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

ＳＡ ＷＧ１－４

ＣＴ ＷＧ１、４

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

【請求項1】

第１の優先度である第１の上り制御情報のために第１の上りリンク制御チャネル（PUCCH）リソースセット及び第２の優先度である第２の上り制御情報のために第２のPUCCHリソースセットを示す情報を送信する送信機と、
前記第１の上り制御情報及び前記第２の上り制御情報の少なくとも一方を受信する受信機と、を具備し、
前記第１の上り制御情報に含まれる応答信号のために第１のスロット位置の集合が決定され、前記第２の上り制御情報に含まれる応答信号のために第２のスロット位置の集合が決定され、
下り制御情報における第１の情報に基づいて、前記第１の優先度及び前記第２の優先度の何れか一方の優先度が決定され、前記何れか一方の優先度に基づいて、前記第１のスロット位置の集合及び前記第２のスロット位置の集合の何れか一方が決定され、
前記下り制御情報における第２の情報に基づいて、前記第１のスロット位置の集合及び前記第２のスロット位置の集合の何れか一方の中から一つのスロット位置が決定される、
基地局。

【請求項2】

前記第１の上り制御情報は前記第１のPUCCHリソースセットから選択された第１のPUCCHリソースを用いて受信され、前記第２の上り制御情報は前記第２のPUCCHリソースセットから選択された第２のPUCCHリソースを用いて受信される、
請求項１に記載の基地局。

【請求項3】

前記第１のPUCCHリソースセット及び前記第２のPUCCHリソースセットは上位レイヤ信号を用いて通知される、
請求項１に記載の基地局。

【請求項4】

前記第１のPUCCHリソースは、下りリンク制御情報を用いて、前記第１のPUCCHリソースセットの中から決定される、
請求項２に記載の基地局。

【請求項5】

前記第１のPUCCHリソースは、前記第１の上り制御情報におけるビット総数に基づいて決定される、
請求項２に記載の基地局。

【請求項6】

前記第１の上り制御情報に用いられる第１のスロット構成は、前記第２の上り制御情報に用いられる第２のスロット構成と異なる、
請求項１に記載の基地局。

【請求項7】

前記第１の優先度は前記第２の優先度よりも高く、
前記第１の優先度である前記第１の上り制御情報と前記第２の優先度である前記第２の上り制御情報とがオーバーラップする場合、前記第２の上り制御情報がドロップされる、
請求項１に記載の基地局。

【請求項8】

前記第１の上り制御情報及び前記第２の上り制御情報は応答信号及びチャネル状態情報を含む、
請求項１に記載の基地局。

【請求項9】

基地局は、
第１の優先度である第１の上り制御情報のために第１の上りリンク制御チャネル（PUCCH）リソースセット及び第２の優先度である第２の上り制御情報のために第２のPUCCHリソースセットを示す情報を送信し、
前記第１の上り制御情報及び前記第２の上り制御情報の少なくとも一方を受信し、
前記第１の上り制御情報に含まれる応答信号のために第１のスロット位置の集合が決定され、前記第２の上り制御情報に含まれる応答信号のために第２のスロット位置の集合が決定され、
下り制御情報における第１の情報に基づいて、前記第１の優先度及び前記第２の優先度の何れか一方の優先度が決定され、前記何れか一方の優先度に基づいて、前記第１のスロット位置の集合及び前記第２のスロット位置の集合の何れか一方が決定され、
前記下り制御情報における第２の情報に基づいて、前記第１のスロット位置の集合及び前記第２のスロット位置の集合の何れか一方の中から一つのスロット位置が決定される、
通信方法。

【請求項10】

前記第１の上り制御情報は前記第１のPUCCHリソースセットから選択された第１のPUCCHリソースを用いて受信され、前記第２の上り制御情報は前記第２のPUCCHリソースセットから選択された第２のPUCCHリソースを用いて受信される、
請求項９に記載の通信方法。

【請求項11】

前記第１のPUCCHリソースセット及び前記第２のPUCCHリソースセットは上位レイヤ信号を用いて通知される、
請求項９に記載の通信方法。

【請求項12】

前記第１のPUCCHリソースは、下りリンク制御情報を用いて、前記第１のPUCCHリソースセットの中から決定される、
請求項１０に記載の通信方法。

【請求項13】

前記第１のPUCCHリソースは、前記第１の上り制御情報におけるビット総数に基づいて決定される、
請求項１０に記載の通信方法。

【請求項14】

前記第１の上り制御情報に用いられる第１のスロット構成は、前記第２の上り制御情報に用いられる第２のスロット構成と異なる、
請求項９に記載の通信方法。

【請求項15】

前記第１の優先度は前記第２の優先度よりも高く、
前記第１の優先度である前記第１の上り制御情報と前記第２の優先度である前記第２の上り制御情報とがオーバーラップする場合、前記第２の上り制御情報がドロップされる、
請求項９に記載の通信方法。

【請求項16】

前記第１の上り制御情報及び前記第２の上り制御情報は応答信号及びチャネル状態情報を含む、
請求項１０に記載の通信方法。

【請求項17】

第１の優先度である第１の上り制御情報のために第１の上りリンク制御チャネル（PUCCH）リソースセット及び第２の優先度である第２の上り制御情報のために第２のPUCCHリソースセットを示す情報を送信する処理と、
前記第１の上り制御情報及び前記第２の上り制御情報の少なくとも一方を受信する処理と、を制御し、
前記第１の上り制御情報に含まれる応答信号のために第１のスロット位置の集合が決定され、前記第２の上り制御情報に含まれる応答信号のために第２のスロット位置の集合が決定され、
下り制御情報における第１の情報に基づいて、前記第１の優先度及び前記第２の優先度の何れか一方の優先度が決定され、前記何れか一方の優先度に基づいて、前記第１のスロット位置の集合及び前記第２のスロット位置の集合の何れか一方が決定され、
前記下り制御情報における第２の情報に基づいて、前記第１のスロット位置の集合及び前記第２のスロット位置の集合の何れか一方の中から一つのスロット位置が決定される、
集積回路。

【発明の詳細な説明】

【技術分野】

【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.

【文献】山本哲矢, 河内涼子, 湯田泰明, 鈴木秀俊, “Release 16 NR URLLCのための1シンボル上りリンク制御チャネルに関する一検討,” 信学会ソサイエティ大会2018, September 2018.

【発明の概要】

【発明が解決しようとする課題】

【0006】

NRにおいて、上りリンク制御情報の送信方法について十分に検討されていない。

【0007】

本開示の非限定的な実施例は、上りリンク制御情報を適切に送信できる端末及び通信方法の提供に資する。

【課題を解決するための手段】

【0008】

本開示の一実施例に係る端末は、上りリンク制御情報に対する要求条件に応じて、前記上りリンク制御情報又は前記上りリンク制御情報の送信に用いる上りリンク制御チャネルに対する処理態様を決定する回路と、前記決定された処理態様に基づいて、前記上りリンク制御チャネルを用いて前記上りリンク制御情報を送信する送信機と、を具備する。

【0009】

本開示の一実施例に係る通信方法は、上りリンク制御情報に対する要求条件に応じて、前記上りリンク制御情報又は前記上りリンク制御情報の送信に用いる上りリンク制御チャネルに対する処理態様を決定し、前記決定された処理態様に基づいて、前記上りリンク制御チャネルを用いて前記上りリンク制御情報を送信する。

【0010】

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

【発明の効果】

【0011】

本開示の一実施例によれば、上りリンク制御情報を適切に送信できる。

【0012】

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

【図面の簡単な説明】

【0013】

【図1】実施の形態１に係る端末の一部の構成を示すブロック図

【図2】実施の形態１に係る基地局の構成を示すブロック図

【図3】実施の形態１に係る端末の構成を示すブロック図

【図4】実施の形態１に係る基地局及び端末の処理を示すシーケンス図

【図5】実施の形態１に係るACK/NACKの送信処理の一例を示す図

【図6】実施の形態１のOption 1に係るACK/NACKのマッピング例を示す図

【図7】実施の形態１のOption 2に係るACK/NACKのマッピング例を示す図

【図8】実施の形態１のOption 3に係るACK/NACKのマッピング例を示す図

【図9】実施の形態１のOption 4に係るACK/NACKのマッピング例を示す図

【図10A】実施の形態２のOption 1に係るACK/NACK及の送信処理の一例を示す図

【図10B】実施の形態２のOption 1に係るACK/NACK及の送信処理の一例を示す図

【図11A】実施の形態２のOption 2に係るACK/NACK及の送信処理の一例を示す図

【図11B】実施の形態２のOption 2に係るACK/NACK及の送信処理の一例を示す図

【図12】実施の形態３に係るACK/NACK及の送信処理の一例を示す図

【図13】実施の形態４に係るACK/NACK及の送信処理の一例を示す図

【図14】実施の形態４に係るACK/NACK及の送信処理の他の例を示す図

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

【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と呼ぶ）を基地局（例えば、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】

しかしながら、Release 15 NRでは、端末からの応答信号のフィードバック機構において、信頼性、遅延要求又はユースケース（またはサービス）の種類が異なる応答信号に関する動作について十分に検討されていない。

【0025】

また、端末は、上りリンク制御チャネル（PUCCH：Physical Uplink Control Channel）を用いて応答信号を基地局へ送信する。しかしながら、Release 15 NRでは、再送を許容するURLLCにおいて応答信号の伝送に要する信頼度に関する要求条件（例えば、BLER＝10^-4以下の誤り率）を実現するようなPUCCHは設計されていない。

【0026】

また、NRの端末は、複数のユースケース又はサービス（例えば、eMBB及びURLLC等）に対応することが想定される。また、NRの端末は、URLLCにおいて、目標誤り率の異なる複数のデータ伝送に対応することも想定される。このとき、上りリンクの同一スロット内において、端末が、信頼度、遅延要求又はユースケース（またはサービス）の種類が異なるデータ伝送にそれぞれ対応する応答信号を同時に送信する場合が発生する可能性がある。

【0027】

Release 15 NRでは、１スロット内において応答信号を送信できるPUCCHの数は１つに制限されている。したがって、仮に、上述したように同一スロット内において信頼度、遅延要求又はユースケース(またはサービス)の種類が異なるデータ伝送に対応する応答信号が同時に送信される場合、これらの応答信号は、１つのPUCCHに多重して送信される。

【0028】

例えば、Release 15 NRにおける方法では、要求される信頼度が異なる応答信号が多重される場合、高い信頼度が要求される応答信号の要求条件を満たすために、高い信頼度が要求される応答信号の信頼度に合わせてPUCCHに対する無線リソースを設定することが考えられる。しかし、この場合、当該高い信頼度が要求される応答信号と比較して低い信頼度が要求される応答信号（換言すると、高い信頼度が要求されない応答信号）に対しても、高い信頼度が要求される応答信号と同様にPUCCHに対する無線リソースが設定されるため、リソース利用効率の観点から非効率である。

【0029】

また、要求される信頼度が異なる応答信号が多重される場合、応答信号を多重するためのHARQ-ACKコードブック（応答信号ビット列）では、信頼度、遅延要求又はユースケース(またはサービス)の種類に関係なく、時間的に早く受信した下りリンクデータに対応する応答信号から順に並べられる。例えば、遅延要求が異なる応答信号（例えば、eMBB及びURLLCに対応する応答信号）が１つのPUCCHに多重して送信される場合、低遅延を要求されない応答信号（例えば、eMBBの応答信号）の送信が遅延のボトルネックとなる場合がある。

【0030】

そこで、本開示の一実施例では、信頼度、遅延要求、又は、ユースケース（またはサービス）の種類が異なる応答信号の送信方法について説明する。換言すると、信頼度、遅延要求又はユースケース（又はサービス）の種類等の「要求条件」に応じた応答信号の送信方法について説明する。

【0031】

以下、各実施の形態について、詳細に説明する。

【0032】

（実施の形態１）
［通信システムの概要］
本開示の各実施の形態に係る通信システムは、基地局１００及び端末２００を備える。

【0033】

図１は、本開示の各実施の形態に係る端末２００の一部の構成を示すブロック図である。図１に示す端末２００において、制御部２１１は、上りリンク制御情報（UCI。例えば、下りリンクデータに対する応答信号）に対する要求条件（例えば、信頼度、遅延要求又はユースケース（サービス）の種類）に応じて、上りリンク制御情報又は上りリンク制御情報の送信に用いる上りリンク制御チャネル（例えば、PUCCH）に対する処理態様（例えば、送信方法又はパラメータ設定など）を決定する。送信部２１６は、決定された処理態様に基づいて、上りリンク制御チャネルを用いて上りリンク制御情報を送信する。

【0034】

［基地局の構成］
図２は、本開示の実施の形態１に係る基地局１００の構成を示すブロック図である。図２において、基地局１００は、制御部１０１と、データ生成部１０２と、符号化部１０３と、再送制御部１０４と、変調部１０５と、上位制御信号生成部１０６と、符号化部１０７と、変調部１０８と、下り制御信号生成部１０９と、符号化部１１０と、変調部１１１と、信号割当部１１２と、IFFT（Inverse Fast Fourier Transform）部１１３と、送信部１１４と、アンテナ１１５と、受信部１１６と、FFT（Fast Fourier Transform）部１１７と、抽出部１１８と、復調部１１９と、復号部１２０と、判定部１２１と、を有する。

【0035】

制御部１０１は、端末２００の下りリンクデータ送信に関する情報を決定し、決定した情報を符号化部１０３、変調部１０５及び信号割当部１１２に出力する。下りリンクデータ送信に関する情報には、例えば、PDSCHにおいて送信される下りリンクデータの変調符号化方法（例えば、MCS）、又は、PDSCHの無線リソース（以下、「PDSCHリソース」と呼ぶ）等が含まれる。また、制御部１０１は、決定した情報を下り制御信号生成部１０９に出力する。

【0036】

また、制御部１０１は、端末２００の下りリンクデータの信頼度、遅延要求又はユースケース（又はサービス）の種類に関する情報（換言すると、応答信号の要求条件に関する情報）を決定し、決定した情報を上位制御信号生成部１０６又は下り制御信号生成部１０９へ出力する。この情報は、端末２００（例えば、制御部２１１）へ通知される。

【0037】

また、制御部１０１は、端末２００の上りリンク制御情報（UCI：Uplink Control Information）の送信に関する情報を決定し、決定した情報を、抽出部１１８及び復号部１２０へ出力する。また、制御部１０１は、UCIの送信に関する情報を上位制御信号生成部１０６又は下り制御信号生成部１０９へ出力する。UCIの送信に関する情報には、例えば、UCI（例えば、応答信号又はCSI等）又はUCIの送信に用いるPUCCHの送信方法又はパラメータ等が含まれる。

【0038】

また、上位制御信号生成部１０６に出力される情報には、例えば、PUCCH resource setに関する情報、準静的（Semi-static）に設定されるスロット位置（例えば、PDSCH-to-HARQ-ACK timing）の集合に関する情報、又は、UCIの最大符号化率に関する情報等が含まれる。また、下り制御情報生成部１０９に出力される情報には、例えば、PUCCH resource set内の実際に用いるPUCCHの無線リソース（以下、PUCCHリソース）を指示するための情報、準静的に設定されるスロット位置の集合内の実際に用いるPDSCH-to-HARQ-ACK timingを指示するための情報等が含まれる。

【0039】

また、制御部１０１は、上位レイヤの制御信号（上位制御信号）又は下りリンク制御情報を送信するための下りリンク制御信号に対する無線リソース割当、及び、下りリンクデータに対する無線リソース割当を決定し、決定した情報を信号割当部１１２へ出力する。

【0040】

データ生成部１０２は、端末２００に対する下りリンクデータを生成し、符号化部１０３へ出力する。

【0041】

符号化部１０３は、データ生成部１０２から入力される下りリンクデータに対して、制御部１０１から入力される情報（例えば、符号化率に関する情報）に基づいて誤り訂正符号化を行い、符号化後のデータ信号を再送制御部１０４へ出力する。

【0042】

再送制御部１０４は、初回送信時には、符号化部１０３から入力される符号化後のデータ信号を保持するとともに、変調部１０５へ出力する。また、再送制御部１０４は、後述する判定部１２１から、送信したデータ信号に対するNACKが入力されると、対応する保持データを変調部１０５へ出力する。一方、再送制御部１０４は、判定部１２１から、送信したデータ信号に対するACKが入力されると、対応する保持データを削除する。

【0043】

変調部１０５は、制御部１０１から入力される情報（例えば、変調方式に関する情報）に基づいて、再送制御部１０４から入力されるデータ信号を変調して、データ変調信号を信号割当部１１２へ出力する。

【0044】

上位制御信号生成部１０６は、制御部１０１から入力される制御情報を用いて、制御情報ビット列（上位制御信号）を生成し、生成した制御情報ビット列を符号化部１０７へ出力する。

【0045】

符号化部１０７は、上位制御信号生成部１０６から入力される制御情報ビット列に対して誤り訂正符号化を行い、符号化後の制御信号を変調部１０８へ出力する。

【0046】

変調部１０８は、符号化部１０７から入力される制御信号を変調して、変調後の制御信号を信号割当部１１２へ出力する。

【0047】

下り制御信号生成部１０９は、制御部１０１から入力される制御情報を用いて、制御情報ビット列（下り制御信号。例えば、DCI）を生成し、生成した制御情報ビット列を符号化部１１０へ出力する。なお、制御情報が複数の端末向けに送信されることもあるため、下り制御信号生成部１０９は、各端末向けの制御情報に、各端末の端末IDを含めてビット列を生成してもよい。なお、端末IDには、後述するスクランブリング系列が用いられてもよい。

【0048】

符号化部１１０は、下り制御信号生成部１０９から入力される制御情報ビット列に対して誤り訂正符号化を行い、符号化後の制御信号を変調部１１１へ出力する。

【0049】

変調部１１１は、符号化部１１０から入力される制御信号を変調して、変調後の制御信号を信号割当部１１２へ出力する。

【0050】

信号割当部１１２は、制御部１０１から入力される無線リソースを示す情報に基づいて、変調部１０５から入力されるデータ信号、変調部１０８から入力される上位制御信号、又は、変調部１１１から入力される下り制御信号を、無線リソースにマッピングする。信号割当部１１２は、信号がマッピングされた下りリンクの信号をIFFT部１１３へ出力する。

【0051】

IFFT部１１３は、信号割当部１１２から入力される信号に対して、OFDM等の送信波形生成処理を施す。IFFT部１１３は、CP（Cyclic Prefix）を付加するOFDM伝送の場合には、CPを付加する（図示せず）。IFFT部１１３は、生成した送信波形を送信部１１４へ出力する。

【0052】

送信部１１４は、IFFT部１１３から入力される信号に対してD/A（Digital-to-Analog）変換、アップコンバート等のRF（Radio Frequency）処理を行い、アンテナ１１５を介して端末２００に無線信号を送信する。

【0053】

受信部１１６は、アンテナ１１５を介して受信された端末２００からの上りリンク信号波形に対して、ダウンコンバート又はA/D（Analog-to-Digital）変換などのRF処理を行い、受信処理後の上りリンク信号波形をFFT部１１７に出力する。

【0054】

FFT部１１７は、受信部１１６から入力される上りリンク信号波形に対して、時間領域信号を周波数領域信号に変換するFFT処理を施す。FFT部１１７は、FFT処理により得られた周波数領域信号を抽出部１１８へ出力する。

【0055】

抽出部１１８は、制御部１０１から入力される情報（例えば、UCIの送信に関する情報）に基づいて、FFT部１１７から入力される信号から、PUCCHが送信された無線リソース成分を抽出する。抽出部１１８は、抽出した無線リソース成分を復調部１１９へ出力する。

【0056】

復調部１１９は、抽出部１１８から入力されるPUCCHに対応する無線リソース成分に対して、等化及び復調を行い、復調結果（復調系列）を復号部１２０へ出力する。

【0057】

復号部１２０は、制御部１０１から入力されるUCIの送信に関する情報（例えば、UCIの符号化に関する情報）に基づいて、復調部１１９から入力される復調結果に対して誤り訂正復号を行い、復号後のビット系列を判定部１２１へ出力する。

【0058】

判定部１２１は、復号部１２０から入力されるビット系列に基づいて、端末２００から送信された応答信号が、送信したデータ信号に対してACK（誤り有り）又はNACK（誤り無し）の何れを示しているかを判定する。判定部１２１は、判定結果を再送制御部１０４に出力する。

【0059】

［端末の構成］
図３は、本開示の実施の形態１に係る端末２００の構成を示すブロック図である。図３において、端末２００は、アンテナ２０１と、受信部２０２と、FFT部２０３と、抽出部２０４と、下り制御信号復調部２０５と、復号部２０６と、上位制御信号復調部２０７と、復号部２０８と、データ復調部２０９と、復号部２１０と、制御部２１１と、符号化部２１２と、変調部２１３と、信号割当部２１４と、IFFT部２１５と、送信部２１６と、を有する。

【0060】

受信部２０２は、アンテナ２０１を介して受信された基地局１００からの下りリンク信号（データ信号又は制御信号）の信号波形に対して、ダウンコンバート又はA/D（Analog-to-Digital）変換などのRF処理を行い、得られる受信信号（ベースバンド信号）をFFT部２０３に出力する。

【0061】

FFT部２０３は、受信部２０２から入力される信号（時間領域信号）に対して、時間領域信号を周波数領域信号に変換するFFT処理を施す。FFT部２０３は、FFT処理により得られた周波数領域信号を抽出部２０４へ出力する。

【0062】

抽出部２０４は、制御部２１１から入力される制御情報（例えば、下りリンクデータ又は制御信号の無線リソースに関する情報）に基づいて、FFT部２０３から入力される信号から、下り制御信号（例えば、DCI）、上位制御信号、又は、下りリンクデータを抽出する。抽出部２０４は、下り制御信号を下り制御信号復調部２０５へ出力し、上位制御信号を上位制御信号復調部２０７へ出力し、下りリンクデータをデータ復調部２０９へ出力する。

【0063】

下り制御信号復調部２０５は、抽出部２０４から入力される下り制御信号を等化及び復調して、復調結果を復号部２０６へ出力する。

【0064】

復号部２０６は、下り制御信号復調部２０５から入力される復調結果を用いて誤り訂正復号を行い、制御情報を得る。復号部２０６は、得られた制御情報を制御部２１１に出力する。

【0065】

上位制御信号復調部２０７は、抽出部２０４から入力される上位制御信号を等化及び復調し、復調結果を復号部２０８へ出力する。

【0066】

復号部２０８は、上位制御信号復調部２０７から入力される復調結果を用いて誤り訂正復号を行い、制御情報を得る。復号部２０８は、得られた制御情報を制御部２１１に出力する。

【0067】

データ復調部２０９は、抽出部２０４から入力される下りリンクデータを等化及び復調し、復号結果を復号部２１０へ出力する。

【0068】

復号部２１０は、データ復調部２０９から入力される復調結果を用いて誤り訂正復号を行う。また、復号部２１０は、下りリンクデータに対して誤り検出を行い、誤り検出結果を制御部２１１に出力する。また、復号部２１０は、誤り検出の結果、誤り無しと判定した下りリンクデータを受信データとして出力する。

【0069】

制御部２１１は、復号部２０６又は復号部２０８から入力される制御情報に含まれる、端末２００のUCIの送信に関する情報に基づいて、UCI（例えば、ACK/NACK又はCSI）又はUCIの送信に用いるPUCCHの送信方法又はパラメータ（例えば、MCS又は無線リソース等）を決定する。制御部２１１は、決定した情報を符号化部２１２、変調部２１３及び信号割当部２１４へ出力する。

【0070】

また、制御部２１１は、復号部２１０から入力される誤り検出結果を用いて応答信号（ACK/NACK）を生成し、符号化部２１２に出力する。

【0071】

また、制御部２１１は、復号部２０６又は復号部２０８から入力される制御情報に含まれる、下りリンクデータ又は制御信号の無線リソースに関する情報を、抽出部２０４に出力する。

【0072】

符号化部２１２は、制御部２１１から入力される情報に基づいて、応答信号（ACK/NACKのビット系列）を誤り訂正符号化し、符号化後の応答信号（ビット系列）を変調部２１３へ出力する。例えば、符号化部２１２は、後述するように、信頼度、遅延要求又はユースケース(またはサービス)の種類等の要求条件の異なる応答信号に対して、異なる符号化方法を適用して符号化ビット列を生成してもよい。

【0073】

変調部２１３は、制御部２１１から入力される情報に基づいて、符号化部２１２から入力される応答信号を変調して、変調後の応答信号（変調シンボル列）を信号割当部２１４へ出力する。例えば、変調部２１３は、符号化部２１２から、異なる符号化方法が適用された符号化ビット列が入力される場合、各符号化ビット列に対して変調を行う。

【0074】

信号割当部２１４は、変調部２１３から入力される応答信号（変調シンボル列）を、制御部２１１から指示されるPUCCHの無線リソースにマッピングする。信号割当部２１４は、応答信号がマッピングされた信号をIFFT部２１５へ出力する。

【0075】

IFFT部２１５は、信号割当部２１４から入力される信号に対して、OFDM等の送信波形生成処理を施す。IFFT部２１５は、CP（Cyclic Prefix）を付加するOFDM伝送の場合には、CPを付加する（図示せず）。または、IFFT部２１５がシングルキャリア波形を生成する場合には、信号割当部２１４の前段にDFT（Discrete Fourier Transform）部が追加されてもよい（図示せず）。IFFT部２１５は、生成した送信波形を送信部２１６へ出力する。

【0076】

送信部２１６は、IFFT部２１５から入力される信号に対してD/A（Digital-to-Analog）変換、アップコンバート等のRF（Radio Frequency）処理を行い、アンテナ２０１を介して基地局１００に無線信号を送信する。

【0077】

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

【0078】

図４は、本実施の形態に係る基地局１００及び端末２００の処理のフローを示す。

【0079】

基地局１００は、PUCCHに関する情報を端末２００へ送信する（ＳＴ１０１）。端末２００は、基地局１００から通知されるPUCCHに関する情報を取得する（ＳＴ１０２）。PUCCHに関する情報には、例えば、PUCCH resource setに関する情報、又は、PUCCHの符号化率に関する情報が含まれる。

【0080】

基地局１００は、下りリンクデータに関する情報を含むDCIを、端末２００へ送信する（ＳＴ１０３）。端末２００は、例えば、基地局１００から通知されるDCIに基づいて、下りリンクデータのスケジューリング情報、又は、PUCCHに関する情報を取得する（ＳＴ１０４）。

【0081】

基地局１００は、下りリンクデータを端末２００へ送信する（ＳＴ１０５）。端末２００は、例えば、基地局１００から通知されているDCIに基づいて、下りリンクデータ（PDSCH）を受信する（ＳＴ１０６）。

【0082】

端末２００は、応答信号に対する要求条件（換言すると、信頼度、遅延要求又はユースケース（サービス）の種類）に応じて、応答信号又は応答信号の送信に関する動作を制御する（ＳＴ１０７）。例えば、端末２００は、応答信号に対する要求条件に応じて、応答信号又はPUCCHに対する処理態様を決定する。応答信号又はPUCCHに対する処理態様の決定では、例えば、応答信号の符号化方法、PUCCHリソースの決定方法、又は、PUCCH送信に関するパラメータ等が決定されてもよい。

【0083】

端末２００は、決定した動作に基づいて、PUCCHを用いてUCI（例えば、応答信号を含む）を基地局１００へ送信する（ＳＴ１０８）。基地局１００は、端末２００から送信されるUCIを受信する（ＳＴ１０９）。

【0084】

次に、端末２００におけるUCI送信に関する動作（例えば、図４のＳＴ１０７の処理）の制御方法について詳細に説明する。

【0085】

［符号化方法］
端末２００は、信頼度、遅延要求、又は、ユースケース（またはサービス）の種類が異なる応答信号（換言すると、要求条件の異なる応答信号）に対して、異なる符号化方法を適用して、HARQ-ACKビットを生成する。

【0086】

そして、端末２００は、異なる符号化方法を適用した符号化後の応答信号をPUCCHに多重して送信する。

【0087】

例えば、端末２００は、信頼度、遅延要求、又は、ユースケース（またはサービス）の種類が異なる応答信号に対して、異なる符号化率による符号化処理を適用する。

【0088】

例えば、端末２００は、高い信頼度が要求される応答信号に対して、低い符号化率（例えば、閾値以下の符号化率）を用いて応答信号を符号化して、HARQ-ACKビットを生成する。低い符号化率を適用することにより、応答信号の信頼度を向上できる。

【0089】

一方、端末２００は、高い信頼度が要求されない応答信号に対して、高い符号化率（例えば、閾値より高い符号化率）を用いて応答信号を符号化して、HARQ-ACKビットを生成する。高い符号化率を適用することにより、応答信号のビット数の増加を抑えて、リソース利用効率を向上できる。

【0090】

応答信号に対する符号化処理に差異を生じさせる例として、応答信号の信頼度が異なる場合について説明する。例えば、URLLCにおいて、１回目のデータ送信の目標誤り率が高い（例えば、BLER=10^-1）下りリンクデータに対する応答信号と、１回目のデータ送信の目標誤り率が低い（例えば、BLER=10^-5）下りリンクデータに対する応答信号と、で符号化処理に差異を生じさせてもよい。

【0091】

具体的には、１回目のデータ送信の目標誤り率が高い場合、データを確実に再送させるために、応答信号には高い信頼度が要求されるため、応答信号に対して、低い符号化率の符号化方法が適用される。一方、１回目のデータ送信の目標誤り率が低い場合、データの誤りが発生しにくいので、応答信号にはそれほど高い信頼度が要求されないため、応答信号に対して高い符号化率の符号化方法が適用される。

【0092】

また、応答信号に対する符号化処理に差異を生じさせる他の例として、応答信号の遅延要求が異なる場合、又は、応答信号のユースケース（またはサービス）の種類（例えば、URLLC又はeMBB等）が異なる場合がある。

【0093】

一例として、図５は、URLLCとeMBBとで異なる符号化方法（符号化処理）が応答信号に適用される例を示す。図５では、端末２００は、eMBBの下りリンクデータ（eMBB PDSCH）に対する応答信号に対して符号化処理１（encoding process 1）を適用し、URLLCの下りリンクデータ（URLLC PDSCH）に対する応答信号に対して符号化処理２（encoding process 2）を適用する。

【0094】

例えば、URLLCでは高い信頼度が要求されるため、応答信号に対する符号化処理２では、低い符号化率の符号化方法が適用される。一方、eMBBでは、URLLCと比較して高い信頼度が要求されないため、応答信号に対する符号化処理１では、高い符号化率の符号化方法が適用される。

【0095】

図５において、端末２００は、URLLCの応答信号及びeMBBの応答信号に対してそれぞれ異なる符号化方法を適用してHARQ-ACKビットをそれぞれ生成し、生成したHARQ-ACKビットを１つのPUCCHに多重して基地局１００へ送信する。

【0096】

このように、本実施の形態によれば、端末２００は、応答信号の信頼度、遅延要求又はユースケース(またはサービス)の種類に応じて、応答信号毎に適切な符号化方法（例えば、符号化率)を適用できる。これにより、１つのPUCCHに多重される応答信号の要求条件が異なる場合でも、各応答信号の要求条件に応じた符号化方法を用いて各応答信号が符号化されるので、リソース利用効率の観点から効率的なPUCCH送信が可能になる。

【0097】

なお、ACK/NACK毎に異なる符号化処理は、上述した信頼度、又は、ユースケース（サービス）の種類に基づいて決定される場合に限定されず、例えば、信頼度、遅延要求又はユースケース（サービス）の種類の少なくとも１つに基づいて決定されればよい。

【0098】

［マッピング方法］
次に、信頼度、遅延要求、又は、ユースケース（またはサービス）の種類が異なる応答信号（換言すると、要求条件の異なる応答信号）のPUCCHリソースへのマッピング方法について説明する。

【0099】

例えば、端末２００は、より高い信頼度が要求される応答信号の順に、又は、遅延要求においてより低遅延が要求される応答信号の順に、PUCCHにマッピングする。具体的には、端末２００は、まず、より高い信頼度又はより低遅延が要求される応答信号をPUCCHリソースへマッピングする。次に、端末２００は、高い信頼度又は低遅延が要求されない応答信号をPUCCHリソースへマッピングする。

【0100】

以下、一例として、１又は２シンボルで構成されるShort-PUCCH（例えば、PUCCH Format 2）及び４シンボル以上のシンボルで構成されるLong-PUCCH（例えば、PUCCH Format 3又はPUCCH Format 4）における応答信号のマッピング方法についてそれぞれ説明する。

【0101】

＜Short PUCCHの場合＞
Short PUCCHにおける応答信号のPUCCHリソースへのマッピングとしては、以下の２つの方法（Option 1及びOption 2）を適用できる。

【0102】

[Option 1]
図６は、Option 1における応答信号のRE（Resource Element）へのマッピング例を示す。

【0103】

図６に示すように、Option 1では、端末２００は、応答信号（HARQ-ACK）を変調した後の変調シンボル列を、「Frequency-first-time-second形式」に基づいて、参照信号（RS: Reference Signal。例えば、DMRS：Demodulation RS）がマッピングされるリソースエレメント（RE: Resource Element）を除いたREへマッピングする。換言すると、端末２００は、PUCCHにおいて、応答信号を、周波数方向から時間方向の順にマッピングする。

【0104】

具体的には、REへのマッピングにおいて、上述したように、高い信頼度又は低遅延が要求される応答信号（図６では、URLLCに対するHARQ-ACK）が最初にPUCCHリソースへマッピングされ、続いて、高い信頼度又は低遅延がそれほど要求されない応答信号（図６では、eMBBに対するHARQ-ACK）がPUCCHリソースへマッピングされる。

【0105】

Option 1のマッピング方法により、図６では、URLLCに対するHARQ-ACKは、PUCCHを構成する１シンボル目の全てのRE（ただし、DMRSがマッピングされたREを除く）と、２シンボル目の一部のREにマッピングされ、eMBBに対するHARQ-ACKは、２シンボル目の残りのREにマッピングされる。

【0106】

Option 1のマッピング方法によれば、例えば、より低遅延が要求される応答信号がPUCCHの先頭シンボルへマッピングされるので、２シンボルのShort PUCCHの場合に、遅延の削減効果が得られる。

【0107】

[Option 2]
図７は、Option 2における応答信号のREへのマッピング例を示す。

【0108】

図７に示すように、Option 2では、端末２００は、応答信号（HARQ-ACK）を変調した後の変調シンボル列を、Option 1と同様に「Frequency-first-time-second形式」に基づいて、参照信号がマッピングされるREを除いたREへマッピングする。更に、Option 2では、端末２００は、周波数方向において割当帯域内の応答信号が分散されるようにマッピングする。

【0109】

具体的には、REへのマッピングにおいて、上述したように、高い信頼度又は低遅延が要求される応答信号（図７では、URLLCに対するHARQ-ACK）が最初にPUCCHリソースへマッピングされ、続いて、高い信頼度又は低遅延がそれほど要求されない応答信号（図７では、eMBBに対するHARQ-ACK）がPUCCHリソースへマッピングされる。また、図７では、URLLCに対するACK/NACK及びeMBBに対応するACK/NACKは、周波数方向において分散してマッピングされる。

【0110】

Option 2のマッピング方法により、図７では、URLLCに対するHARQ-ACKは、PUCCHを構成する１シンボル目の全てのRE（ただし、DMRSがマッピングされたREを除く）と、２シンボル目の一部のREにマッピングされ、eMBBに対するHARQ-ACKは、２シンボル目の残りのREにマッピングされる。また、図７では、PUCCHの２シンボル目において、URLLCに対するHARQ-ACK及びeMBBに対するHARQ-ACKは、PUCCHの割り当て帯域（例えば、4RB（Resource Block））において周波数方向に分散してそれぞれマッピングされている。

【0111】

Option 2のマッピング方法によれば、Option 1のマッピング方法と同様、より低遅延が要求される応答信号がPUCCHの先頭シンボルへマッピングされるので、２シンボルのShort PUCCHの場合に、遅延の削減効果が得られる。

【0112】

また、Option 2のマッピング方法によれば、周波数方向への分散的なマッピングにより、周波数ダイバーシチ効果を得ることができるので、より高品質な応答信号（換言すると、より高信頼度の応答信号）の伝送を実現できる。

【0113】

＜Long PUCCHの場合＞
Long-PUCCHにおける応答信号のPUCCHリソースへのマッピングとしては、以下の２つの方法（Option 3及びOption 4）を適用できる。

【0114】

[Option 3]
Option 3では、NRのPUCCH Format 3又はPUCCH Format 4におけるHARQ-ACKビットとCSI（CSI Part 1及びCSI Part 2）とのマッピング関係と同様の方法（例えば、非特許文献２を参照）を、信頼度、遅延要求又はユースケース(またはサービス)の種類が異なる応答信号に対するマッピングに適用する。

【0115】

図８は、Option 3における応答信号のREへのマッピング例を示す。

【0116】

図８に示すように、Option 3では、端末２００は、応答信号（HARQ-ACK）を変調した後の変調シンボル列を、「Frequency-first-time-second形式」に基づいて、RS（図８ではDMRS）がマッピングされるREを除いたREへマッピングする。また、図８に示すように、端末２００は、より高い信頼度が要求される応答信号ほど、PUCCHにおいて参照信号（例えば、DMRS）がマッピングされたシンボルにより近いシンボルにマッピングする。

【0117】

具体的には、図８に示すように、REへのマッピングにおいて、上述したように、最初に、高い信頼度が要求されるURLLCに対するHARQ-ACKが、DMRSがマッピングされたシンボルに近いシンボル（前後のシンボル）に順にマッピングされる。続いて、図８に示すように、高い信頼度がそれほど要求されないeMBBに対するHARQ-ACKビットが残りのPUCCHリソースへマッピングされる。

【0118】

Option 3のマッピング方法によれば、より高い信頼度が要求されるHARQ-ACKビットが、チャネル推定精度の高いシンボル（DMRSがマッピングされたシンボルに近いシンボル）へマッピングされる。このため、Option 3によれば、より高品質な応答信号（換言すると、より高信頼度の応答信号）の伝送を実現できる。

【0119】

[Option 4]
図９は、Option 4における応答信号のREへのマッピング例を示す。

【0120】

図９に示すように、Option 4では、端末２００は、応答信号（HARQ-ACK）を変調した後の変調シンボル列を、「Frequency-first-time-second形式」に基づいて、RSがマッピングされるREを除いたREへマッピングする。また、図９に示すように、端末２００は、遅延要求においてより低遅延が要求される応答信号ほど、PUCCHのより早いシンボルにマッピングする。

【0121】

具体的には、図９に示すように、REへのマッピングにおいて、上述したように、最初に、低遅延が要求されるURLLCに対するHARQ-ACKがより早いタイミングのシンボル（例えば、先頭シンボル）から順にマッピングされる。続いて、図９に示すように、低遅延がそれほど要求されないeMBBに対するHARQ-ACKが残りのPUCCHリソースへマッピングされる。

【0122】

Option 4のマッピング方法によれば、より低遅延が要求される応答信号がPUCCHの先頭シンボルへマッピングされるので、遅延の削減効果がある。

【0123】

以上、応答信号のPUCCHリソースへのマッピング方法について説明した。

【0124】

このように、端末２００は、高い信頼度又は低遅延が要求される応答信号、つまり、要求条件が厳しい応答信号を、PUCCHリソースへ優先的にマッピングする。これにより、端末２００は、例えば、PUCCHに多重される応答信号のうち、より高い信頼度又はより低遅延が要求される応答信号を、高い信頼度又は低遅延を実現できるPUCCHリソースへ優先的にマッピングできる。よって、本実施の形態によれば、端末２００は、応答信号に対する要求条件に適したPUCCHリソースを用いて、応答信号を送信できる。

【0125】

なお、Option 3及びOption 4では、４シンボル以上を用いるLong-PUCCHに対する応答信号のマッピング方法について説明した。一方で、例えば、URLLCでは、Long-PUCCHを用いることは遅延削減の観点から望ましくない。そこで、本実施の形態では、信頼度、遅延要求又はユースケース(又はサービス)の種類が異なる応答信号を１つのPUCCHに多重することを許容するのは、Short-PUCCHに限定してもよい。これにより、低遅延の要求条件を満たしつつ、複数のPUCCH formatに対する設計を省くことができる。

【0126】

また、応答信号のPUCCHリソースへのマッピング方法は、上述したOption 1～4に限定されない。また、例えば、Option 1～4の何れかを組み合わせてもよい。例えば、Option 3（図８を参照）又はOption 4（図９を参照）において、Option 2（図７を参照）のように、応答信号（HARQ-ACK）は、周波数方向において分散してマッピングされてもよい。

【0127】

［PUCCHリソースの決定方法］
次に、本実施の形態におけるPUCCHリソースの決定方法について説明する。

【0128】

NRでは、端末の下りリンクデータに対する応答信号を送信するためのPUCCHリソースの特定に関して、基地局が、端末固有の上位レイヤ信号（例えば、RRC（Radio Resource Control）シングナリング）によって、準静的なPUCCHリソースの集合（PUCCH resource set）を通知し、下りリンクデータを割り当てるDCI（Downlink Control Information)によって、PUCCH resource setの中の実際に用いるPUCCHリソースを通知する方法を採用する（例えば、非特許文献３を参照）。

【0129】

ここで、PUCCHリソースは、例えば、スロット内のシンボル位置、スロット内のシンボル数、周波数領域位置、周波数領域のリソース数（例えば、RB数又はPRB（Physical RB）数）、周波数ホッピングの適用の有無、又は、符号リソース（例えば、巡回シフト系列又は直交符号）の少なくとも１つからなるパラメータで構成される。

【0130】

また、基地局は、端末に対して複数のPUCCH resource setを通知できる。端末は、PUCCHを用いて送信する上りリンク制御情報（UCI: Uplink Control Information）のビット数に基づいて、通知された複数のPUCCH resource setのうちのどのPUCCH resource setを用いるかを決定できる。

【0131】

本実施の形態では、端末２００は、PUCCHに多重される応答信号（HARQ-ACK）の符号化後のビット数の合計に基づいて、PUCCH resource setを決定する。

【0132】

また、本実施の形態では、PUCCHリソースの決定に係るパラメータについて、信頼度、遅延要求又はユースケース（またはサービス）の種類が異なる応答信号（換言すると、要求条件の異なる応答信号）に対して、異なる値が設定されてもよい。

【0133】

例えば、NRでは、PUCCH format毎に最大符号化率が設定されている。端末は、PUCCHの送信に用いるRB数を、PUCCHを用いて送信するUCIのビット数と最大符号化率とから決定する。ただし、PUCCHの送信に用いるRB数について、上述したPUCCH resource setにより通知されるPUCCHリソースのRB数が上限となる。

【0134】

本実施の形態では、最大符号化率は、PUCCH format毎、かつ、応答信号の信頼度、遅延要求又はユースケース(またはサービス)の種類毎（換言すると応答信号の要求条件毎）にそれぞれ設定される。

【0135】

例えば、端末２００は、信頼度、遅延要求又はユースケース(またはサービス)の種類が異なる応答信号の各々に対して、応答信号の符号化後のビット数と、設定された最大符号化率とに基づいて、応答信号の送信に用いるリソース量（例えば、RE数）を算出する。そして、端末２００は、１つのPUCCHに多重される各応答信号の送信に用いるRE数に基づいて、当該PUCCHの送信に用いるRB数を決定する。

【0136】

これにより、端末２００は、例えば、上述したように、応答信号毎に設定される符号化方法による符号化後のビット数に基づいて、要求条件の異なる応答信号が多重されるPUCCHにおけるPUCCH resource setを決定できる。例えば、端末２００は、応答信号の信頼度、遅延要求またはユースケース(またはサービス)の種類に応じた適切なリソース量を算出できるため、リソース利用効率の観点から効率的なPUCCH送信が可能になる。

【0137】

なお、PUCCHの送信に用いるRB数については、上述したように、PUCCH resource setにより通知されるPUCCHリソースのRB数が上限となる。このため、例えば、応答信号のビット数と最大符号化率とから決定されるRB数が、PUCCH resource setにより通知される上限値を超える場合には、応答信号の実際の符号化率は、設定された最大符号化率を超える場合がある。この場合、PUCCHの送信において要求される品質を満たせない可能性がある。

【0138】

そこで、本実施の形態では、端末２００は、応答信号の実際の符号化率が所定の閾値を超える場合、PUCCHを用いて送信する応答信号の一部をドロップしてもよい。これにより、PUCCHリソースにおいて、応答信号の一部をドロップした分のリソースは、残りの応答信号に使用されるので、PUCCHの送信における品質を向上できる。

【0139】

ここで、閾値は、例えば、PUCCH format毎、かつ、応答信号の信頼度、遅延要求又はユースケース(またはサービス)の種類毎に設定される最大符号化率でもよい。また、最大符号化率とは別に、一部の応答信号をドロップするための閾値が基地局１００から端末２００へ新たに通知されてもよい。

【0140】

また、端末２００は、PUCCHを用いて送信される応答信号（又はUCI）のビット数と、最大符号化率とから算出されるRB数が所定の閾値（上限値）を超える場合、PUCCHを用いて送信する応答信号の少なくとも一部をドロップしてもよい。これにより、PUCCHリソースにおいて、応答信号の一部をドロップした分のリソースは、残りの応答信号に使用されるので、PUCCHの送信における品質を向上できる。

【0141】

また、ドロップする応答信号は、応答信号の信頼度、遅延要求又はユースケース（またはサービス）の種類に応じて設定される優先度（換言すると、要求条件毎に設定される優先度）に応じて決定されてもよい。例えば、端末２００は、優先度の高い要求条件の応答信号を優先的に送信してもよい。換言すると、端末２００は、優先度の低い要求条件の応答信号を優先的にドロップしてもよい。

【0142】

優先度の一例として、応答信号の信頼度が異なる場合、例えば、URLLCにおいて、１回目のデータ送信の目標誤り率が高い（例えば、BLER=10^-1）下りリンクデータに対する応答信号の優先度は、１回目のデータ送信の目標誤り率が低い（例えば、BLER=10^-5）下りリンクデータに対する応答信号の優先度よりも高く設定される。または、応答信号の遅延要求が異なる場合又はユースケース(またはサービス)の種類が異なる場合、例えば、URLLCの優先度は、eMBBの優先度よりも高く設定される。

【0143】

信頼度、遅延要求又はユースケース(またはサービス)の種類が異なる応答信号の少なくとも１つの符号化率が閾値を超えた場合、端末２００は、優先度の低い応答信号からドロップしてもよい。これにより、優先度の高い応答信号、つまり、より高い信頼度が要求される応答信号の伝送品質の劣化を抑えることができる。

【0144】

また、信頼度、遅延要求またはユースケース(またはサービス)の種類が異なる応答信号がある場合、異なる応答信号に対してPUCCH内のリソース（例えば、RE）をどのような割合で共有又は分割するかを示す情報（例えば、resource sharing factor又はresource splitting factor）を基地局１００から端末２００へ予め通知してもよい。

【0145】

以上、PUCCHリソースの決定方法について説明した。

【0146】

このように、本実施の形態では、端末２００は、下りリンクデータの応答信号に対する要求条件（例えば、信頼度、遅延要求又はユースケース（サービス）の種類）に応じて、応答信号又はPUCCHに対する処理態様を決定する。具体的には、端末２００は、要求条件の異なる応答信号に対して、異なる符号化方法を適用する。そして、端末２００は、符号化後の応答信号を、PUCCHに多重して送信する。

【0147】

これにより、本実施の形態によれば、要求条件が異なる応答信号がPUCCHに多重される場合でも、端末２００は、PUCCHに多重される応答信号に要求される要求条件に応じた処理（例えば、符号化処理）又は無線リソースの設定（例えば、マッピング方法又はPUCCHリソースの決定）をそれぞれ行うことができる。例えば、端末２００は、応答信号に要求される信頼度に応じたPUCCHリソースの位置又は量を設定することにより、PUCCHにおけるリソース利用効率を向上できる。また、例えば、端末２００は、応答信号に対する遅延要求に応じたPUCCHリソースの位置を設定することにより、応答信号の遅延を削減できる。

【0148】

以上より、本実施の形態によれば、端末２００は、応答信号を含むUCIを適切に送信できる。

【0149】

（実施の形態２）
本実施の形態に係る基地局及び端末は、実施の形態１に係る基地局１００及び端末２００と基本構成が共通するので、図２及び図３を援用して説明する。

【0150】

本実施の形態では、端末２００は、信頼度、遅延要求又はユースケース(またはサービス)の種類が異なる応答信号（換言すると、要求条件の異なる応答信号）に対して、PUCCHリソース又はPUCCHリソースセットの決定方法を異ならせる。

【0151】

また、本実施の形態では、１スロット内において端末２００が応答信号を送信できるPUCCHの数を１つに制限しない。換言すると、本実施の形態では、１スロット内において端末２００が応答信号を送信できるPUCCHの数は、１つ以上である。

【0152】

例えば、端末２００は、要求条件の異なる各応答信号を、スロット内の異なるPUCCHを用いてそれぞれ送信する。例えば、複数のPUCCHは、時間分割多重（TDM：Time Division Multiplexing）、周波数分割多重（FDM：Frequency Division Multiplexing）、又は、符号分割多重（CDM：Code Division Multiplexing）により同一スロット内に多重される。

【0153】

これにより、端末２００は、応答信号の信頼度、遅延要求又はユースケース(またはサービス)の種類に応じて、応答信号毎に適切なPUCCHリソースを割り当てることができる。換言すると、端末２００は、要求条件の異なる応答信号を、１つのPUCCHに多重せずに、個別のPUCCHを用いて送信できる。このため、リソース利用効率の観点から効率的なPUCCH送信が可能となる。

【0154】

また、本実施の形態によれば、端末２００は、例えば、遅延要求の異なる応答信号を、異なるPUCCHを用いて送信できる。このため、例えば、URLLCのように低遅延が要求される応答信号をShort-PUCCHを用いて送信し、eMBBのように低遅延がそれほど要求されない応答信号をLong-PUCCHを用いて送信することにより、遅延要求に対するボトルネックを解消できる。

【0155】

例えば、端末２００の下りリンクデータに対する応答信号を送信するためのPUCCHリソースの特定に関して、基地局１００は、端末固有の上位レイヤ信号（例えば、RRCシグナリング）によって、準静的なPUCCHリソースの集合（例えば、PUCCH resource set）を通知する。端末２００は、例えば、以下の２つの方法（Option 1及びOption 2）の何れかに基づいてPUCCH resource setを決定する。

【0156】

[Option 1]
Option 1では、信頼度、遅延要求又はユースケース(またはサービス)の種類が異なる応答信号（換言すると、要求条件の異なる応答信号）に対して、異なるPUCCH resource setのグループが設定される。よって、端末２００は、要求条件の異なる応答信号に対して、異なるグループに含まれるPUCCH resource setをそれぞれ設定する。

【0157】

図１０Ａは、Option 1におけるPUCCH resource setの設定例を示す。

【0158】

図１０Ａでは、eMBB及に対するPUCCH resource setのグループ（例えばグループＸ）、及び、URLLCに対するPUCCH resource setのグループ（例えば、グループＹ）が設定されている。例えば、図１０Ａでは、グループＸには、PUCCH resource set X0, X1, X2及びX3が含まれ、グループＹには、PUCCH resource set Y0, Y1, Y2及びY3が含まれる。

【0159】

端末２００は、例えば、信頼度、遅延要求又はユースケース(またはサービス)の種類が異なる応答信号毎に、PUCCHを用いて送信するUCIのビット数（例えば、HARQ-ACKビット数）に基づいて、各グループ内のどのPUCCH resource setを用いるかを決定する。

【0160】

例えば、図１０Ａでは、端末２００は、eMBBに対する応答信号のビット数に基づいて、グループＸ内のPUCCH resource setの中から、PUCCH resource set X1を選択する。また図１０Ａでは、端末２００は、URLLCに対する応答信号のビット数に基づいて、グループＹ内のPUCCH resource setの中から、PUCCH resource set Y0を選択する。

【0161】

また、端末２００には、信頼度、遅延要求又はユースケース(またはサービス)の種類が異なる応答信号の各々に対応する下りリンクデータを割り当てるDCI（例えば、図１０Ｂに示すDL assignment for eMBB又はDL assignment for URLLC）によって、選択したPUCCH resource setの中の実際に用いるPUCCHリソースが通知される。端末２００は、選択したPUCCH resource setのうち、DCIによって通知されたPUCCHリソースを用いて、応答信号を送信する。

【0162】

Option 1によれば、信頼度、遅延要求又はユースケース(またはサービス)の種類毎にPUCCH resource setが個別に設定されるので、信頼度、遅延要求又はユースケース(またはサービス)の種類が異なる応答信号に適したPUCCHリソースをより柔軟に割り当てることができる。

【0163】

なお、図１０Ａに示すPUCCH resource setの設定例は一例であって、限定されない。例えば、eMBB及びURLLCに対するPUCCH resource setのグループ内に含まれるPUCCH resource setの数は、４個に限定されず、他の個数でもよい。また、eMBB及びURLLCに対するPUCCH resource setの各グループ内に含まれるPUCCH resource setの数は同一でもよく、異なってもよい。また、図１０Ａでは、要求条件の異なる場合の一例として、eMBB及びURLLCについて説明したが、これに限定されず、例えば、異なる信頼度又は異なる遅延要求の少なくとも一方に応じてPUCCH resource setのグループが設定されてもよい。

【0164】

[Option 2]
Option 2では、信頼度、遅延要求又はユースケース(またはサービス)の種類が異なる応答信号（換言すると、要求条件の異なる応答信号）に対して、同一のPUCCH resource setのグループが設定される。よって、端末２００は、要求条件の異なる応答信号に対して、同一グループに含まれるPUCCH resource setをそれぞれ設定する。

【0165】

図１１Ａは、Option 2におけるPUCCH resource setの設定例を示す。

【0166】

図１１Ａでは、PUCCH resource set 0, 1, 2及び3を含むグループが設定されている。

【0167】

端末２００は、例えば、信頼度、遅延要求又はユースケース(またはサービス)の種類に依らず、PUCCHを用いて送信するUCIのビット数（例えば、HARQ-ACKビット数）に基づいて、同一グループ内のどのPUCCH resource setを用いるかを決定する。

【0168】

例えば、図１１Ａでは、端末２００は、eMBBに対する応答信号のビット数に基づいて、PUCCH resource set 0～3の中から、PUCCH resource set 1を選択する。また、図１１Ａでは、端末２００は、URLLCに対する応答信号のビット数に基づいて、PUCCH resource set 0～3の中から、PUCCH resource set 0を選択する。

【0169】

また、端末２００には、信頼度、遅延要求又はユースケース(またはサービス)の種類が異なる応答信号の各々に対応する下りリンクデータを割り当てるDCI（例えば、図１１Ｂに示すDL assignment for eMBB又はDL assignment for URLLC）によって、選択したPUCCH resource setの中の実際に用いるPUCCHリソースが通知される。端末２００は、選択したPUCCH resource setのうち、DCIによって通知されたPUCCHリソースを用いて、応答信号を送信する。

【0170】

Option 2によれば、信頼度、遅延要求又はユースケース(またはサービス)の種類に依らず、選択可能なPUCCH resource setは同一である。このため、PUCCH resource setの通知に係るオーバヘッドを削減できる。

【0171】

また、端末２００は、信頼度、遅延要求又はユースケース(またはサービス)の種類が異なる応答信号の各々のビット数に基づいて、実際に用いるPUCCH resource setを個別に決定できる。このため、端末２００は、信頼度、遅延要求又はユースケース(またはサービス)の種類が異なる応答信号に適したPUCCHリソースをそれぞれ用いることができる。

【0172】

以上、PUCCH resource setの決定方法について説明した。

【0173】

このように、本実施の形態では、端末２００は、要求条件（例えば、信頼度、遅延要求又はユースケース（サービス）の種類）の異なる応答信号に対して、異なるリソース決定方法を適用する。そして、端末２００は、各応答信号に対して設定したPUCCHリソースを用いて、当該応答信号を送信する。

【0174】

これにより、本実施の形態によれば、端末２００は、応答信号に要求される要求条件に応じた無線リソースをそれぞれ個別に設定できるので、リソース利用効率の向上、又は、応答信号の遅延を削減できる。以上より、本実施の形態によれば、端末２００は、応答信号を含むUCIを適切に送信できる。

【0175】

なお、本実施の形態では、信頼度、遅延要求又はユースケース(またはサービス)の種類が異なる応答信号に対して、異なるPUCCHリソース又は異なるPUCCHリソースセットを決定する方法について説明した。ただし、本実施の形態におけるリソース決定方法に基づいて各応答信号に対して決定されたPUCCHリソースが同一である場合、端末２００は、実施の形態１と同様の処理を適用してもよい。

【0176】

また、本実施の形態に係るOption 1では、信頼度、遅延要求又はユースケース（またはサービス）の種類毎に、異なるPUCCH resource setのグループが設定される場合について説明した。これに対して、さらに、PUCCH resource setに関するパラメータについて、信頼度、遅延要求又はユースケース（またはサービス）の種類毎に設定可能な値(または値の範囲)に差異を生じさせてもよい。

【0177】

例えば、NRのPUCCH Format 0では、Sequence selectionが用いられる（例えば、非特許文献１を参照）。また、Release 15 NRでは、PUCCH送信に割り当て可能な送信帯域幅は1RBであり、1RB=12サブキャリアに相当する系列長12の送信系列が用いられる。また、NRでは、１セル繰り返しの周波数割当が用いられる。１セル繰り返しでは、セル間干渉が特性劣化の主要因である。特に、Short-PUCCHでは、利用するシンボル数（１シンボル又は２シンボル）が少ないため、複数シンボルを利用することによる干渉の平均化効果によるセル間干渉の抑圧ができない。

【0178】

このため、応答信号に対して高い信頼度が要求される場合、セル間干渉の抑圧が必要である。セル間干渉を抑圧する方法として、送信帯域幅（系列長）の拡大が有効である（例えば、非特許文献６を参照）。

【0179】

そこで、例えば、PUCCH Format 0について、信頼度、遅延要求又はユースケース(またはサービス)の種類が異なる応答信号に応じて、PUCCHの設定可能なRB数または系列長を異ならせてもよい。

【0180】

例えば、高い信頼度が要求される応答信号に対するPUCCH resource setでは、可変のPRB数（例えば、1，2，および4PRBの何れか）を設定可能としてもよい。一方、高い信頼度が要求されない応答信号に対するPUCCH resource setでは、設定可能なPRB数を１PRBとしてもよい。なお、各要求条件に対して設定可能なPRB数は、上記例に限定されず、他の個数でもよい。

【0181】

これにより、PUCCH Format 0において、応答信号に対して高い信頼度が要求される場合でも、送信帯域幅（系列長）の拡大によってセル間干渉を抑圧できる。

【0182】

また、PUCCH Format 0については、時間領域の繰り返し送信（Repetition）も特性改善に有効な技術である。

【0183】

そこで、PUCCH Format 0について、信頼度、遅延要求又はユースケース(またはサービス)の種類が異なる応答信号に応じて、PUCCHの設定可能なRepetition回数を異ならせてもよい。

【0184】

例えば、高い信頼度が要求される応答信号に対するPUCCH resource setでは、Repetitionを設定可能とし、可変のRepetition回数（例えば、1，2，および4回の何れか）を設定可能としてもよい。一方、高い信頼度が要求されない応答信号に対するPUCCH resource setでは、Repetitionを設定可能としない。なお、各要求条件に対して設定可能なRepetition回数は、上記例に限定されず、他の回数でもよい。

【0185】

これにより、PUCCH Format 0において、応答信号に対して高い信頼度が要求される場合でも、Repetitionによって、特性改善の効果を得ることができる。

【0186】

なお、時間領域のRepetitionには、同一の系列を複数シンボルに渡り繰り返し送信する方法がある。この方法では、受信側（例えば、基地局１００）においてRepetition信号を同相合成することにより、受信信号の電力向上による特性改善効果が期待できる。また、時間領域のRepetitionには、系列長を拡大し、拡大した系列の一部を異なるシンボルで送信する方法がある。例えば、系列長を12から24に拡大し、系列長24の前半部分が最初のシンボルで送信され、後半部分が次のシンボルで送信される。この方法では、長い系列長を用いることによる干渉抑圧の効果が期待できる。

【0187】

上述したように、PUCCH format 0について、高い信頼度が要求される応答信号に対するPUCCH resource setに対して、Release 15 NRとは異なるパラメータを設定可能とすることにより、Release 15 NRでは考慮されていない再送を許容するURLLCの応答信号の信頼度に関す要求条件（例えば、BLER=10^-4以下の誤り率）を実現するPUCCH送信が可能となる。

【0188】

（実施の形態２のバリエーション）
実施の形態２では、信頼度、遅延要求又はユースケース(またはサービス)の種類が異なる応答信号に対して、PUCCHリソース又はPUCCHリソースセットの決定方法を異ならせる場合について説明した。

【0189】

NRでは、端末は下りリンクデータに対する応答信号を送信するためのPUCCHのスロット位置（又は、下りリンクデータを受信したスロットからPUCCHを送信するスロットまでの時間）の特定に関して、基地局が端末固有の上位レイヤ信号（例えば、RRCシグナリング）によって準静的なスロット位置の集合を通知し、下りリンクデータを割り当てるDCIによって、スロット位置の集合の中の実際に用いるスロット位置を通知する方法が採用されている（例えば、非特許文献３を参照）。

【0190】

そこで、実施の形態２のバリエーションでは、応答信号を送信するためのPUCCHのスロット位置の集合についても同様に、信頼度、遅延要求又はユースケース(またはサービス)の種類が異なる応答信号（換言すると、要求条件の異なる応答信号）毎に設定可能とする。

【0191】

実施の形態２のバリエーションによれば、端末２００は、応答信号の信頼度、遅延要求又はユースケース(またはサービス)の種類に応じて、応答信号に対する適切な送信スロットを用いることができる。例えば、異なる遅延要求に対して異なるスロット位置の集合が設定されていれば、端末２００は、遅延要求の異なる応答信号を異なるPUCCHを用いてそれぞれ送信する場合でも、遅延要求の異なる応答信号の各々に対して、遅延要求に適したより柔軟なスロット割当が可能になる。

【0192】

（実施の形態３）
本実施の形態に係る基地局及び端末は、実施の形態１に係る基地局１００及び端末２００と基本構成が共通するので、図２及び図３を援用して説明する。

【0193】

本実施の形態では、端末２００は、同一スロット内に、信頼度、遅延要求又はユースケース(またはサービス)の種類が異なるデータ伝送に対する応答信号を同時に送信する場合、PUCCHの優先度に応じて、応答信号を送信するPUCCHの全てをドロップ、又は、一部をパンクチャする。

【0194】

ドロップ又は一部をパンクチャするPUCCHは、ACK/NACKの信頼度、遅延要求又はユースケース(またはサービス)の種類に応じて付与される優先度に基づいて決定されてもよい。

【0195】

具体的には、端末２００は、要求条件の異なる応答信号の送信タイミングが同一の場合、要求条件に基づく優先度がより低いPUCCHの全てをドロップ又は一部をパンクチャする。

【0196】

PUCCHの優先度の一例として、応答信号の信頼度が異なる場合について説明する。例えば、URLLCにおいて、１回目のデータ送信の目標誤り率が高い（例えば、BLER=10^-1）下りリンクデータに対する応答信号を送信するPUCCHの優先度は、１回目のデータ送信の目標誤り率が低い（例えば、BLER=10^-5）下りリンクデータに対する応答信号を送信するPUCCHの優先度よりも高く設定される。つまり、端末２００は、１回目のデータ送信の目標誤り率が低い（例えば、BLER=10^-5）下りリンクデータに対する応答信号を送信するPUCCHの全てをドロップ又は一部をパンクチャする。

【0197】

また、応答信号の遅延要求又はユースケース(またはサービス)の種類が異なる場合について説明する。例えば、図１２は、URLLC及びeMBBの２つのサービスが存在する場合を示す。URLLCに対応するPUCCHの優先度は、eMBBに対応するPUCCHの優先度よりも高く設定される。つまり、端末２００は、eMBBに対応するPUCCHの全てをドロップ又は一部をパンクチャする。例えば、図１２では、端末２００は、URLLCに対応するPUCCH（URLLC PUCCH）を用いて、URLLCに対応する応答信号を送信し、eMBBに対応するPUCCH（eMBB PUCCH）の全てをドロップする。

【0198】

本実施の形態によれば、より高い信頼度又は低遅延が要求される応答信号のためのPUCCH送信に対して、別の応答信号のためのPUCCH送信が影響を与えることがなくなるため、より高い信頼度又は低遅延が要求される応答信号の品質を保証できる。

【0199】

なお、PUCCHの一部をパンクチャする場合、例えば、異なる応答信号のPUCCH送信において、時間的に重なるシンボルをパンクチャする方法、又は、時間及び周波数が重なるREをパンクチャする方法がある。

【0200】

時間的に重なるシンボルをパンクチャする方法は、例えば、端末２００が複数の上りリンク信号を同時に送信できない場合、又は、端末２００に複数の上りリンク信号を同時送信できる能力があるものの、送信電力の総和が最大送信電力を超える場合において、何れか一方の信号を送信しなければならない場合に適用できる。

【0201】

また、時間及び周波数が重なるREをパンクチャする方法は、例えば、端末２００に複数の上りリンク信号を同時に送信できる能力があり、かつ、複数の上りリンク信号を同時に送信しても端末２００の最大送信電力を超えない場合に適用できる。

【0202】

（実施の形態４）
例えば、実施の形態１では、信頼度、遅延要求又はユースケース(またはサービス)の種類が異なる応答信号に対して異なる符号化処理を適用する場合について説明した。しかし、異なる符号化処理を行うことは、端末の処理量を増大させるため、実装を複雑にする恐れがある。

【0203】

そこで、本実施の形態では、信頼度、遅延要求又はユースケース(またはサービス)の種類が異なる応答信号に対して、１つの符号化処理を適用する方法について説明する。

【0204】

本実施の形態に係る基地局及び端末は、実施の形態１に係る基地局１００及び端末２００と基本構成が共通するので、図２及び図３を援用して説明する。

【0205】

端末２００は、下りリンクデータを受信してから、下りリンクデータの復号、応答信号の生成、及び、PUCCH送信までに要する処理時間に関する能力(UE capability。以下、「N1」と表す)を有する。NRでは、端末２００は、「N1」を基地局１００へ報告する。

【0206】

基地局１００は、端末２００が下りリンクデータに対する応答信号を送信するためのPUCCHのスロット位置（又は、下りリンクデータを受信したスロットからPUCCH（例えば、応答信号）を送信するスロットまでの時間：「PDSCH-to-HARQ-ACK timing」）を設定し、端末２００へ通知する。このとき、基地局１００は、PDSCH-to-HARQ-ACK timingについて、端末２００から報告された端末２００の処理能力(N1)を超える値（換言すると、N1より小さい値）を設定及び通知できない。

【0207】

本実施の形態では、端末２００は、信頼度、遅延要求又はユースケース(またはサービス)の種類が異なる応答信号の送信に対する能力（N1）をそれぞれ規定し、基地局１００へ報告する。また、端末２００は、基地局１００から設定及び通知されたPDSCH-to-HARQ-ACK timingの値と、規定したN1の値とに基づいて、応答信号又は応答信号の送信に用いるPUCCHの送信方法及びパラメータ（換言すると、応答信号又はPUCCHに対する処理態様）を決定する。

【0208】

例えば、端末２００は、下りリンクデータを受信してから、データを復号し、応答信号を生成し、PUCCHを送信するまでに必要な処理時間に関する能力(N1)について、信頼度、遅延要求又はユースケース(またはサービス)の種類に応じた２つ以上の能力を有する。端末２００は、２つ以上の能力（N1）を基地局１００へ報告する。

【0209】

一例として、端末２００は、eMBBに対するN1(以下、「N1_X」又は「N1_eMBB」と表す)、及び、URLLCに対するN1(以下、「N1_Y」又は「N1_URLLC」と表す)の２つの端末能力(UE capability)を有してもよい。例えば、URLLCでは、eMBBよりも低遅延が要求される可能性が高いので、URLLCに対するN1は、eMBBに対するN1よりも小さい値が設定されてもよい。

【0210】

実施の形態２のバリエーションで説明したように、下りリンクデータに対する応答信号を送信するためのPUCCHのスロット位置（PDSCH-to-HARQ-ACK timing）の特定に関して、基地局１００が端末固有の上位レイヤ信号（例えば、RRCシグナリング）によって準静的なスロット位置の集合を通知し、下りリンクデータを割り当てるDCIによって、集合の中のどのPDSCH-to-HARQ-ACK timingを実際に用いるかを通知する。

【0211】

同一スロット内において、信頼度、遅延要求又はユースケース(またはサービス)の種類が異なるデータ伝送に対応する応答信号の送信が同時に発生する場合、端末２００は、各応答信号に対するPDSCH-to-HARQ-ACK timingの値と、端末２００が有する能力（N1）とに基づいて、応答信号に対する処理を決定する。

【0212】

例えば、図１３に示すように、各応答信号に対するPDSCH-to-HARQ-ACK timingの値の最小値（図１３では、PDSCH-to-HARQ-ACK timing for URLLC）が、eMBBに対するN1（N1_X又はN1_eMBB）以上である場合、端末２００は、eMBBに対応する応答信号及びURLLCに対応する応答信号に対して共通の符号化処理（joint encoding）を行い、HARQ-ACKビットを生成する。

【0213】

具体的には、図１３では、端末２００がURLLC用のPDSCHを受信してから、PDSCH-to-HARQ-ACK timing for URLLCに相当する時間が経過するまでの間に、端末２００は、eMBBに対応する応答信号を生成し、当該応答信号を含むPUCCHを送信するまでの処理を完了できる（換言すると、N1_X/N1_eMBB ≦ PDSCH-to-HARQ-ACK timing for URLLC）。よって、端末２００は、端末２００がURLLC用のPDSCHを受信してから、PDSCH-to-HARQ-ACK timing for URLLCに相当する時間が経過するまでの間に、URLLCの応答信号とeMBBの応答信号とに対して共通の符号化処理を行うことができる。

【0214】

一方、図１４に示すように、高い信頼度又は低遅延が要求される応答信号、又は、URLLCに対応する応答信号に対するPDSCH-to-HARQ-ACK timingの値（図１４ではPDSCH-to-HARQ-ACK timing for URLLC）が、eMBBに対応するN1（N1_X又はN1_eMBB）未満である場合、端末２００は、eMBBに対応する応答信号及びURLLCに対応する応答信号に対して共通の符号化処理を行うことができない。

【0215】

具体的には、図１４では、端末２００がURLLC用のPDSCHを受信してから、PDSCH-to-HARQ-ACK timing for URLLCに相当する時間が経過するまでの間に、端末２００は、eMBBに対応する応答信号を生成し、当該応答信号を含むPUCCHを送信するまでの処理を完了できない（換言すると、N1_X/N1_eMBB ＞ PDSCH-to-HARQ-ACK timing for URLLC）。

【0216】

よって、端末２００は、端末２００がURLLC用のPDSCHを受信してから、PDSCH-to-HARQ-ACK timing for URLLCに相当する時間が経過するまでの間に、URLLCのACK/NACKと、eMBBのACK/NACKをまとめて符号化処理できない。この場合、端末２００は、実施の形態３又は実施の形態１の何れかの方法を用いる。

【0217】

例えば、実施の形態３の方法を用いる場合、信頼度、遅延要求又はユースケース(またはサービス)の種類が異なる応答信号に対して、符号化処理を全体で１つに抑えることができるため、端末２００の実装を簡易にできる利点がある。また、実施の形態１の方法を用いる場合、端末２００は、図１４に示すように、応答信号の信頼度、遅延要求又はユースケース(またはサービス)の種類に応じた適切な符号化(または符号化率)によりHARQ-ACKビットを生成できるため、リソース利用効率の観点から効率的なPUCCH送信が可能になる。

【0218】

このように、本実施の形態によれば、端末２００の処理能力に応じて、符号処理をできる限り共通化することができるため、端末２００の処理量の増大又は実装の複雑さを軽減できる。

【0219】

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

【0220】

（１）上記実施の形態では、応答信号の信頼度、遅延要求又はユースケース(またはサービス)の種類に応じて、応答信号又はPUCCHの送信方法、及びパラメータに差異を生じさせた。

【0221】

ここで、応答信号又はPUCCHの送信方法、及びパラメータに差異を生じさせる例としては、応答信号の信頼度が異なる場合がある。例えば、URLLCにおいて、１回目のデータ送信の目標誤り率が高い（例えば、BLER=10^-1）下りリンクデータに対する応答信号と、１回目のデータ送信の目標誤り率が低い（例えば、BLER=10^-5）下りリンクデータに対する応答信号とで、応答信号又はPUCCHの送信方法、及びパラメータに差異を生じさせることができる。前者の応答信号には高い信頼度が要求される一方、後者の応答信号にはそれほど高い信頼度が要求されない。

【0222】

また、応答信号又はPUCCHの送信方法、及びパラメータに差異を生じさせる例として、応答信号の遅延要求が異なる場合又はユースケース(またはサービス)が異なる場合がある。例えば、URLLCに対応する応答信号とeMBBに対応する応答信号とで、応答信号又はPUCCHの送信方法、及びパラメータに差異を生じさせることもできる。前者の応答信号には高い信頼度又は低遅延が要求される一方、後者の応答信号にはそれほど高い信頼度又は低遅延が要求されない。また、URLLCには、上述したように、１回目のデータ送信の目標誤り率が高い(例えば、BLER=10^-1)下りリンクデータに対する応答信号と、１回目のデータ送信の目標誤り率が低い(例えば、BLER=10^-5)下りリンクデータに対する応答信号とが含まれる場合がある。

【0223】

また、応答信号又はPUCCHの送信方法の差異を生じさせる例としては、信頼度、遅延要求又はユースケース(サービス)の種類に限らず、例えば、物理層のパラメータが異なる場合でもよい。例えば、eMBBを「スロット単位の送信」と置き換え、URLLCを「非スロット単位の送信」と置き換えてもよい。また、eMBBを「PDSCH mapping type A」又は「PUSCH mapping type A」と置き換え、URLLCを「PDSCH mapping type B」又は「PUSCH mapping type B」と置き換えてもよい。また、eMBB及びURLLCに対応する送信に限定されず、例えば、eMBBを送信区間(例えば、スロット長又はシンボル長)が長い送信と置き換え、URLLCを前述の送信区間よりも送信区間が短い送信と置き換えてもよい。

【0224】

また、本開示において、目標誤り率は、上述したように１回目のデータ送信の目標誤り率でもよく、再送が発生する場合は、再送における目標誤り率でもよい。また、目標誤り率は、１回目及び再送の各々の目標誤り率という意味で「瞬時目標誤り率」と呼んでもよい。

【0225】

（２）上記実施の形態において説明した、応答信号の「信頼度、遅延要求又はユースケース(またはサービス)の種類」（換言すると、要求条件）を判断する方法には、例えば、以下の例１～例５のような方法がある。

【0226】

[例１：スクランブル系列]
例１では、端末２００は、各応答信号に対応する下りリンクデータ伝送をスケジューリングするDCIに用いられる端末固有のスクランブリング系列に基づいて、応答信号の信頼度、遅延要求又はユースケース(サービス)の種類を判断する。

【0227】

例えば、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であると判断する。

【0228】

例えば、基地局１００の制御部１０１（例えば、図２を参照）は、端末２００の下りリンクデータの信頼度、遅延要求又はユースケース(サービス)の種類に関する情報を決定する。決定した情報は、基地局１００の下り制御信号生成部１０９へ出力される。下り制御信号生成部１０９は、上述したように、端末２００の下りリンクデータの信頼度、遅延要求又はユースケース(またはサービス)の種類に応じたスクランブリング系列を用いてDCIのビット列を生成する。

【0229】

一方、端末２００の復号部２０６（例えば、図３を参照）は、検出したスクランブリング系列を制御部２１１へ出力する。制御部２１１は、得られたスクランブリング系列に基づいて、下りリンクデータの信頼度、遅延要求又はユースケース(サービス)の種類に関する情報を判断する。

【0230】

[例２：MCSテーブル]
例２では、端末２００は、各応答信号に対応する下りリンクデータ伝送のスケジューリングに用いられるMCSテーブルに基づいて、応答信号の信頼度、遅延要求又はユースケース（サービス）の種類を判断する。

【0231】

例えば、Release 15 NRでは、目標BLER=10^-1を達成するためのMCSテーブル、及び、目標BLER=10^-5を達成するためのMCSテーブルの何れを用いるかを設定できる。

【0232】

例えば、端末２００は、URLLCにおいて設定されたMCSテーブルが目標BLER=10^-1を達成するためのMCSテーブルである場合、応答信号に要求される信頼度が高いと判断する。一方、端末２００は、URLLCにおいて設定されたMCSテーブルが目標BLER=10^-5を達成するためのMCSテーブルである場合、応答信号に要求される信頼度は高くないと判断する。

【0233】

例えば、基地局１００の制御部１０１は、端末２００の下りリンクデータの信頼度、遅延要求又はユースケース(サービス)の種類に関する情報を決定する。決定した情報は、基地局１００の下り制御信号生成部１０９、符号化部１０３及び変調部１０５へ出力される。下り制御信号生成部１０９は、下りリンクデータ伝送に用いられるMCSテーブルに関する情報をDCIのビット列に含める。また、符号化部１０３及び変調部１０５は、制御部１０１から入力されるMCSテーブルに関する情報を用いて、下りリンクデータを符号化及び変調する。

【0234】

一方、端末２００の復号部２０６は、DCIを復号し、復号結果を制御部２１１へ出力する。制御部２１１は、DCIから得られるMCSテーブルに関する情報に基づいて、下りリンクデータの信頼度、遅延要求又はユースケース(サービス)の種類に関する情報を判断する。

【0235】

[例３：PDSCH-to-HARQ-ACK timing又はPDSCHの送信シンボル数]
例３では、端末２００は、各応答信号に対応する下りリンクデータ伝送をスケジューリングするDCIによって通知された「PDSCH-to-HARQ-ACK timing」又はPDSCHの送信シンボル数に基づいて、応答信号の信頼度、遅延要求又はユースケース(サービス)の種類を判断する。

【0236】

例えば、端末２００は、PDSCH-to-HARQ-ACK timingが所定の値以下、又は、PDSCHの送信シンボル数が所定のシンボル数以下である場合、応答信号の遅延要求が厳しい又はURLLCのための応答信号であると判断する。一方、端末２００は、PDSCH-to-HARQ-ACK timingが所定の値より大きい、又は、PDSCHの送信シンボル数が所定のシンボル数より多い場合、応答信号の遅延要求が厳しくない又はeMBBのための応答信号であると判断する。

【0237】

なお、上記所定の値又は所定のシンボル数は、規格において予め決まった値でもよく、基地局１００が上位レイヤ信号によって端末２００へ設定可能な値でもよい。

【0238】

例えば、基地局１００の制御部１０１は、端末２００の下りリンクデータに対する応答信号を送信するスロット位置を示すPDSCH-to-HARQ-ACK timing又はPDSCHの送信シンボル数を決定する。決定した情報は、基地局１００の下り制御信号生成部１０９、信号割当部１１２及び抽出部１１８へ出力される。下り制御信号生成部１０９は、PDSCH-to-HARQ-ACK timing又はPDSCHの送信シンボル数に関する情報をDCIのビット列に含める。

【0239】

一方、端末２００の復号部２０６は、DCIを復号し、復号結果を制御部２１１へ出力する。制御部２１１は、DCIから得られるPDSCH-to-HARQ-ACK timing又はPDSCHの送信シンボル数に関する情報に基づいて、下りリンクデータの信頼度、遅延要求又はユースケース(サービス)の種類に関する情報を判断する。

【0240】

[例４：CQIテーブル]
例４では、端末２００は、各応答信号に対応する下りリンクデータ伝送用に設定されるCQIテーブルに基づいて、応答信号の信頼度、遅延要求又はユースケース(サービス)の種類を判断する。

【0241】

例えば、Release 15 NRでは、目標BLER=10^-1を達成するためのCQIテーブル、及び、目標BLER=10^-5を達成するためのCQIテーブルの何れを用いるかを設定できる。

【0242】

例えば、端末２００は、URLLCにおいて設定されたCQIテーブルが目標BLER=10^-1を達成するためのCQIテーブルである場合、応答信号に要求される信頼度が高いと判断する。一方、URLLCにおいて設定されたCQIテーブルが目標BLER=10^-5を達成するためのCQIテーブルである場合、応答信号に要求される信頼度は高くないと判断する。

【0243】

例えば、基地局１００の制御部１０１は、端末２００の下りリンクデータ伝送用に設定されるCQIテーブルに関する情報を決定する。決定した情報は、上位制御信号生成部１０６へ出力される。上位制御信号生成部１０６は、CQIテーブルに関する情報を上位制御信号に含める。

【0244】

一方、端末２００の復号部２０８は、上位制御信号を復号し、復号結果を制御部２１１へ出力する。制御部２１１は、上位制御信号から得られるCQIテーブルに関する情報に基づいて、下りリンクデータの信頼度、遅延要求又はユースケース(サービス)の種類に関する情報を判断する。

【0245】

[例５：DCIによる明示的な通知]
例５では、端末２００は、各応答信号に対応する下りリンクデータ伝送をスケジューリングするDCI内の数ビットによる明示的な通知により、応答信号の信頼度、遅延要求又はユースケース(サービス)の種類を判断する。

【0246】

明示的な通知は、応答信号自体の信頼度、遅延要求又はユースケース(サービス)の種類に関する情報でもよく、PDSCHの信頼度(例えば目標BLER)、遅延要求又はユースケース(サービス)の種類に関する情報でもよい。

【0247】

例えば、基地局１００の制御部１０１は、端末２００の下りリンクデータに対する応答信号の信頼度、遅延要求又はユースケース(サービス)の種類に関する情報を決定する。決定された情報は、下り制御信号生成部１０９へ出力される。下り制御信号生成部１０９は、応答信号の信頼度、遅延要求又はユースケース(サービス)の種類に関する情報をDCIのビット列に含める。

【0248】

一方、端末２００の復号部２０６は、DCIを復号し、復号結果を制御部２１１へ出力する。制御部２１１は、DCIから応答信号の信頼度、遅延要求又はユースケース(サービス)の種類に関する情報を得る。

【0249】

以上、応答信号の「信頼度、遅延要求又はユースケース(またはサービス)の種類」を判断する方法について説明した。なお、「応答信号の信頼度、遅延要求又はユースケース(またはサービス)の種類」を判断する方法は、上述した例１～例５に限定されず、要求条件に関する他の情報に基づく判断方法でもよい。

【0250】

（３）また、上記実施の形態では、下りリンクデータ伝送に対する応答信号がPUCCHを用いて送信される場合を一例として説明した。しかし、本開示においてPUCCHを用いて送信されるUCIは応答信号に限らない。例えば、上記実施の形態において、「応答信号（ACK/NACK又はHARQ-ACK）」をチャネル状態情報（CSI)に置き換えてもよく、応答信号とCSIとを含むUCIに置き換えてもよい。

【0251】

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

【0252】

本開示は、通信機能を持つあらゆる種類の装置、デバイス、システム（通信装置と総称）において実施可能である。通信装置の、非限定的な例としては、電話機（携帯電話、スマートフォン等）、タブレット、パーソナル・コンピューター（ＰＣ）（ラップトップ、デスクトップ、ノートブック等）、カメラ（デジタル・スチル／ビデオ・カメラ等）、デジタル・プレーヤー（デジタル・オーディオ／ビデオ・プレーヤー等）、着用可能なデバイス（ウェアラブル・カメラ、スマートウオッチ、トラッキングデバイス等）、ゲーム・コンソール、デジタル・ブック・リーダー、テレヘルス・テレメディシン（遠隔ヘルスケア・メディシン処方）デバイス、通信機能付きの乗り物又は移動輸送機関（自動車、飛行機、船等）、及び上述の各種装置の組み合わせがあげられる。

【0253】

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

【0254】

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

【0255】

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

【0256】

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

【0257】

本開示の一実施例における端末は、上りリンク制御情報に対する要求条件に応じて、前記上りリンク制御情報又は前記上りリンク制御情報の送信に用いる上りリンク制御チャネルに対する処理態様を決定する回路と、前記決定された処理態様に基づいて、前記上りリンク制御チャネルを用いて前記上りリンク制御情報を送信する送信機と、を具備する。

【0258】

本開示の一実施例における端末において、前記回路は、前記要求条件の異なる前記上りリンク制御情報に対して、異なる符号化方法を適用し、前記送信機は、前記上り制御チャネルにおいて、符号化後の前記上りリンク制御情報を多重して送信する。

【0259】

本開示の一実施例における端末において、前記要求条件には、信頼度又は遅延要求が含まれ、より高い前記信頼度が要求される前記上りリンク制御情報の順に、又は、前記遅延要求においてより低遅延が要求される前記上りリンク制御情報の順に、前記上り制御チャネルにマッピングされる。

【0260】

本開示の一実施例における端末において、前記上りリンク制御情報は、前記上り制御チャネルにおいて、周波数方向から時間方向の順にマッピングされる。

【0261】

本開示の一実施例における端末において、前記上りリンク制御情報は、周波数方向において分散してマッピングされる。

【0262】

本開示の一実施例における端末において、より高い前記信頼度が要求される前記上りリンク制御情報ほど、前記上り制御チャネルにおいて参照信号がマッピングされたシンボルにより近いシンボルにマッピングされる。

【0263】

本開示の一実施例における端末において、前記遅延要求においてより低遅延が要求される前記上りリンク制御情報ほど、前記上り制御チャネルのより早いシンボルにマッピングされる。

【0264】

本開示の一実施例における端末において、前記上り制御チャネルに多重される前記上りリンク制御情報の符号化後のビット数の合計に基づいて、前記上り制御チャネルのリソースセットが決定される。

【0265】

本開示の一実施例における端末において、前記上りリンク制御情報に対する前記要求条件毎に、最大符号化率が設定される。

【0266】

本開示の一実施例における端末において、前記上りリンク制御情報の符号化率が所定の閾値を超える場合、前記上り制御チャネルにおいて前記上りリンク制御情報の少なくとも一部がドロップされる。

【0267】

本開示の一実施例における端末において、前記所定の閾値は、前記最大符号化率である。

【0268】

本開示の一実施例における端末において、前記所定の閾値は、基地局から前記端末へ通知される。

【0269】

本開示の一実施例における端末において、前記ドロップされる上りリンク制御情報は、前記要求条件毎に設定される優先度に応じて決定される。

【0270】

本開示の一実施例における端末において、前記上りリンク制御情報のビット数と前記最大符号化率とから算出されるリソースブロック数が所定の閾値を超える場合、前記上り制御チャネルにおいて前記上りリンク制御情報の少なくとも一部がドロップされる。

【0271】

本開示の一実施例における端末において、前記上り制御チャネルにおいて、前記要求条件の異なる前記上りリンク制御情報間で共有するリソースの割合を示す情報が、基地局から前記端末へ通知される。

【0272】

本開示の一実施例における端末において、前記要求条件の異なる前記上りリンク制御情報に対して、前記上り制御チャネルにおいて異なるリソース決定方法を適用する。

【0273】

本開示の一実施例における端末において、１スロット内の前記上りリンク制御情報を送信する上り制御チャネルの数は１つ以上であり、前記送信機は、前記要求条件の異なる前記上りリンク制御情報を、前記１スロット内の異なる上り制御チャネルを用いてそれぞれ送信する。

【0274】

本開示の一実施例における端末において、前記回路は、前記要求条件の異なる前記上りリンク制御情報に対して、異なるグループに含まれるリソースセットをそれぞれ設定する。

【0275】

本開示の一実施例における端末において、前記回路は、前記要求条件の異なる前記上りリンク制御情報に対して、同一グループに含まれるリソースセットをそれぞれ設定する。

【0276】

本開示の一実施例における端末において、前記リソースセットに関するパラメータは、前記要求条件の異なる前記上りリンク制御情報毎に異なる。

【0277】

本開示の一実施例における端末において、前記パラメータは、前記上り制御チャネルのリソースブロック数又は系列長である。

【0278】

本開示の一実施例における端末において、前記パラメータは、前記上りリンク制御情報のレピティション回数である。

【0279】

本開示の一実施例における端末において、前記要求条件の異なる前記上りリンク制御情報毎に、前記上りリンク制御情報を送信するためのスロット位置が設定される。

【0280】

本開示の一実施例における端末において、前記回路は、前記要求条件の異なる前記上りリンク制御情報の送信が同一タイミングの場合、前記要求条件に基づく優先度がより低い前記上り制御チャネルの全てをドロップ又は一部をパンクチャする。

【0281】

本開示の一実施例における端末において、前記上りリンク制御情報は、下りリンクデータに対する応答信号であり、前記下りリンクデータの受信から前記応答信号の送信までに要する処理時間に関する前記端末の能力が、前記要求条件毎に規定され、前記下りリンクデータの受信から前記応答信号の送信までの時間を示すタイミング情報が、基地局から前記端末へ通知され、前記回路は、前記タイミング情報と前記能力とに基づいて、前記処理態様を決定する。

【0282】

本開示の一実施例における通信方法は、上りリンク制御情報に対する要求条件に応じて、前記上りリンク制御情報又は前記上りリンク制御情報の送信に用いる上りリンク制御チャネルに対する処理態様を決定し、前記決定された処理態様に基づいて、前記上りリンク制御チャネルを用いて前記上りリンク制御情報を送信する。

【0283】

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

【産業上の利用可能性】

【0284】

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

【符号の説明】

【0285】

１００ 基地局
１０１，２１１ 制御部
１０２ データ生成部
１０３，１０７，１１０，２１２ 符号化部
１０４ 再送制御部
１０５，１０８，１１１，２１３ 変調部
１０６ 上位制御信号生成部
１０９ 下り制御信号生成部
１１２，２１４ 信号割当部
１１３，２１５ IFFT部
１１４，２１６ 送信部
１１５，２０１ アンテナ
１１６，２０２ 受信部
１１７，２０３ FFT部
１１８，２０４ 抽出部
１１９ 復調部
１２０，２０６，２０８，２１０ 復号部
１２１ 判定部
２００ 端末
２０５ 下り制御信号復調部
２０７ 上位制御信号復調部
２０９ データ復調部

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10A】

【図10B】

【図11A】

【図11B】

【図12】

【図13】

【図14】