(57)【要約】  上りリンク制御情報を適切に送信することができる端末。端末（２００）において、制御部（２１１）は、下りデータの応答信号に対する要求条件に応じて、応答信号又は応答信号の送信に用いる上り制御チャネルに対する処理態様を決定する。送信部（２１６）は、決定された処理態様に基づいて、上り制御チャネルを用いて応答信号を送信する。
2020026518.tif 000002
【特許請求の範囲】
【請求項１】
上りリンク制御情報に対する要求条件に応じて、前記上りリンク制御情報又は前記上りリンク制御情報の送信に用いる上りリンク制御チャネルに対する処理態様を決定する回路と、
前記決定された処理態様に基づいて、前記上りリンク制御チャネルを用いて前記上りリンク制御情報を送信する送信機と、
を具備する端末。
【請求項２】
前記回路は、前記要求条件の異なる前記上りリンク制御情報に対して、異なる符号化方法を適用し、
前記送信機は、前記上り制御チャネルにおいて、符号化後の前記上りリンク制御情報を多重して送信する、
請求項１に記載の端末。
【請求項３】
前記要求条件には、信頼度又は遅延要求が含まれ、
より高い前記信頼度が要求される前記上りリンク制御情報の順に、又は、前記遅延要求においてより低遅延が要求される前記上りリンク制御情報の順に、前記上り制御チャネルにマッピングされる、
請求項２に記載の端末。
【請求項４】
前記上りリンク制御情報は、前記上り制御チャネルにおいて、周波数方向から時間方向の順にマッピングされる、
請求項３に記載の端末。
【請求項５】
前記上り制御チャネルに多重される前記上りリンク制御情報の符号化後のビット数の合計に基づいて、前記上り制御チャネルのリソースセットが決定される、
請求項２に記載の端末。
【請求項６】
前記上りリンク制御情報に対する前記要求条件毎に、最大符号化率が設定される、
請求項５に記載の端末。
【請求項７】
前記上り制御チャネルにおいて、前記要求条件の異なる前記上りリンク制御情報間で共有するリソースの割合を示す情報が、基地局から前記端末へ通知される、
請求項２に記載の端末。
【請求項８】
前記回路は、前記要求条件の異なる前記上りリンク制御情報に対して、前記上り制御チャネルにおいて異なるリソース決定方法を適用する、
請求項１に記載の端末。
【請求項９】
１スロット内の前記上りリンク制御情報を送信する上り制御チャネルの数は１つ以上であり、
前記送信機は、前記要求条件の異なる前記上りリンク制御情報を、前記１スロット内の異なる上り制御チャネルを用いてそれぞれ送信する、
請求項８に記載の端末。
【請求項１０】
前記回路は、前記要求条件の異なる前記上りリンク制御情報に対して、異なるグループに含まれるリソースセットをそれぞれ設定する、
請求項８に記載の端末。
【請求項１１】
前記回路は、前記要求条件の異なる前記上りリンク制御情報に対して、同一グループに含まれるリソースセットをそれぞれ設定する、
請求項８に記載の端末。
【請求項１２】
前記要求条件の異なる前記上りリンク制御情報毎に、前記上りリンク制御情報を送信するためのスロット位置が設定される、
請求項１に記載の端末。
【請求項１３】
前記回路は、前記要求条件の異なる前記上りリンク制御情報の送信が同一タイミングの場合、前記要求条件に基づく優先度がより低い前記上り制御チャネルの全てをドロップ又は一部をパンクチャする、
請求項１に記載の端末。
【請求項１４】
前記上りリンク制御情報は、下りリンクデータに対する応答信号であり、
前記下りリンクデータの受信から前記応答信号の送信までに要する処理時間に関する前記端末の能力が、前記要求条件毎に規定され、
前記下りリンクデータの受信から前記応答信号の送信までの時間を示すタイミング情報が、基地局から前記端末へ通知され、
前記回路は、前記タイミング情報と前記能力とに基づいて、前記処理態様を決定する、
請求項１に記載の端末。
【請求項１５】
上りリンク制御情報に対する要求条件に応じて、前記上りリンク制御情報又は前記上りリンク制御情報の送信に用いる上りリンク制御チャネルに対する処理態様を決定し、
前記決定された処理態様に基づいて、前記上りリンク制御チャネルを用いて前記上りリンク制御情報を送信する、
通信方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本開示は、端末及び通信方法に関する。
【背景技術】
【０００２】
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）をサポートしている（例えば、非特許文献１−４を参照）。【０００３】
3GPPが定義するRelease 15におけるURLLCへの要求条件として、片道0.5ms以下のユーザプレーン遅延、かつ、一定の信頼性を担保し、1ms以下の遅延を達成することが求められている。【０００４】
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）とが設定できる。
【先行技術文献】
【非特許文献】
【０００５】
【非特許文献１】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.
【発明の概要】
【０００６】
NRにおいて、上りリンク制御情報の送信方法について十分に検討されていない。
【０００７】
本開示の非限定的な実施例は、上りリンク制御情報を適切に送信できる端末及び通信方法の提供に資する。
【０００８】
本開示の一実施例に係る端末は、上りリンク制御情報に対する要求条件に応じて、前記上りリンク制御情報又は前記上りリンク制御情報の送信に用いる上りリンク制御チャネルに対する処理態様を決定する回路と、前記決定された処理態様に基づいて、前記上りリンク制御チャネルを用いて前記上りリンク制御情報を送信する送信機と、を具備する。
【０００９】
本開示の一実施例に係る通信方法は、上りリンク制御情報に対する要求条件に応じて、前記上りリンク制御情報又は前記上りリンク制御情報の送信に用いる上りリンク制御チャネルに対する処理態様を決定し、前記決定された処理態様に基づいて、前記上りリンク制御チャネルを用いて前記上りリンク制御情報を送信する。
【００１０】
なお、これらの包括的または具体的な態様は、システム、装置、方法、集積回路、コンピュータプログラム、または、記録媒体で実現されてもよく、システム、装置、方法、集積回路、コンピュータプログラムおよび記録媒体の任意な組み合わせで実現されてもよい。
【００１１】
本開示の一実施例によれば、上りリンク制御情報を適切に送信できる。
【００１２】
本開示の一実施例における更なる利点および効果は、明細書および図面から明らかにされる。かかる利点および／または効果は、いくつかの実施形態並びに明細書および図面に記載された特徴によってそれぞれ提供されるが、１つまたはそれ以上の同一の特徴を得るために必ずしも全てが提供される必要はない。
【図面の簡単な説明】
【００１３】
【図１】実施の形態１に係る端末の一部の構成を示すブロック図
【図２】実施の形態１に係る基地局の構成を示すブロック図
【図３】実施の形態１に係る端末の構成を示すブロック図
【図４】実施の形態１に係る基地局及び端末の処理を示すシーケンス図
【図５】実施の形態１に係るACK/NACKの送信処理の一例を示す図
【図６】実施の形態１のOption 1に係るACK/NACKのマッピング例を示す図
【図７】実施の形態１のOption 2に係るACK/NACKのマッピング例を示す図
【図８】実施の形態１のOption 3に係るACK/NACKのマッピング例を示す図
【図９】実施の形態１のOption 4に係るACK/NACKのマッピング例を示す図
【図１０Ａ】実施の形態２のOption 1に係るACK/NACK及の送信処理の一例を示す図
【図１０Ｂ】実施の形態２のOption 1に係るACK/NACK及の送信処理の一例を示す図
【図１１Ａ】実施の形態２のOption 2に係るACK/NACK及の送信処理の一例を示す図
【図１１Ｂ】実施の形態２のOption 2に係るACK/NACK及の送信処理の一例を示す図
【図１２】実施の形態３に係るACK/NACK及の送信処理の一例を示す図
【図１３】実施の形態４に係るACK/NACK及の送信処理の一例を示す図
【図１４】実施の形態４に係るACK/NACK及の送信処理の他の例を示す図
【発明を実施するための形態】
【００１４】
以下、本開示の実施の形態について図面を参照して詳細に説明する。
【００１５】
LTE（Long-Term Evolution）又はNRにおけるeMBBのユースケースでは、セルスループット又は周波数利用効率を最大化することが求められる。このような場合、データの目標誤り率を比較的高い値（例えば、BLER=10-1）に設定して運用されることが一般的である。これは、ハイブリッド自動再送要求（HARQ: Hybrid Automatic Repeat Request）を適用しているためである。eMBBでは、例えば、HARQによる数回の再送による合成利得を考慮した上で、最終的に高信頼のパケット伝送(例えば、BLER=10-5)を実現することを許容している。
【００１６】
一方、URLLCでは、高信頼のパケット伝送（例えば、BLER=10-5）を1ms以下の遅延で実現することが求められる。例えば、上述したHARQでは、データ伝送に誤りが発生した場合に再送要求が起こり、データが再送されるため、再送回数の増加に応じて遅延時間が長くなり、低遅延の要求条件を満たせなくなる。よって、URLLCでは、HARQによる再送無しで高信頼のパケット伝送を可能とするために、上述したような高信頼モード（データの目標誤り率を比較的低い値（例えば、BLER=10-5）に設定するモード）により１回目の送信においてデータを確実に伝送できるように運用することが考えられる。
【００１７】
低い目標誤り率を設定することは、高信頼のデータ伝送につながるものの、高い目標誤り率を設定する場合と比較して、無線リソースをより多く必要とする。Release 15 NRでは、URLLCのデータサイズは、比較的小さい32byteに制限されているため、低い目標誤り率の設定によるリソース利用効率への影響はそれほど大きくなかった。
【００１８】
一方で、Release 16又は今後のURLLCでは、Release 15 NRよりも大きなデータサイズを扱い、URLLCのユースケースを拡大していくことが期待される。この場合、低い目標誤り率を設定すると、１回の送信によって高信頼のパケット送信を実現するためには、膨大な無線リソースを必要とする可能性があり、リソース利用効率の観点から非効率である。
【００１９】
したがって、比較的大きなデータサイズを扱うURLLCのユースケースでは、例えば、高速なHARQ再送制御の適用が想定される。高速なHARQ再送制御では、例えば、１回目の送信において高い目標誤り率（例えば、BLER=10-1又はBLER=10-2等）を設定し、１回目の送信において誤りが発生しても次の再送（２回目の送信）においてデータを確実に伝送する運用が行われる。このように、高速なHARQ再送制御は、リソース利用効率を向上させつつ、低遅延で高信頼なパケット伝送を行うために有効である。
【００２０】
ここで、下りリンクにおけるHARQ伝送に着目すると、端末（UE：User Equipment）は、下りリンクデータに対する誤り検出結果を示す応答信号（ACK/NACK：Acknowledgement / Negative Acknowledgement。又は、HARQ-ACKと呼ぶ）を基地局（例えば、eNB又はgNB）へ送信する。
【００２１】
このとき、応答信号の伝送に必要とされる信頼度又は遅延要求は、下りリンクデータ伝送の信頼度、遅延要求、又は、ユースケース（またはサービス）の種類（又はusage scenario）によって異なる。
【００２２】
例えば、URLLCにおいて、１回目の送信において誤りが発生しても次の送信（再送）においてデータを確実に伝送できるような運用を想定する。この場合、１回目のデータ送信の目標誤り率が高いほど、より高い信頼度の応答信号の伝送（換言すると、目標誤り率がより低い応答信号の伝送）が求められる。例えば、１回目のデータ送信の目標誤り率がBLER=10-1である場合、応答信号にはBLER=10-4以下の誤り率が求められ、１回目のデータ送信の目標誤り率がBLER=10-3である場合、応答信号にはBLER=10-2以下の誤り率が求められる（例えば、非特許文献５を参照）。
【００２３】
また、eMBBとURLLCとでは、URLLCのデータ伝送に対する応答信号は、eMBBのデータ伝送に対する応答信号と比較してより低遅延が要求される。
【００２４】
しかしながら、Release 15 NRでは、端末からの応答信号のフィードバック機構において、信頼性、遅延要求又はユースケース（またはサービス）の種類が異なる応答信号に関する動作について十分に検討されていない。
【００２５】
また、端末は、上りリンク制御チャネル（PUCCH：Physical Uplink Control Channel）を用いて応答信号を基地局へ送信する。しかしながら、Release 15 NRでは、再送を許容するURLLCにおいて応答信号の伝送に要する信頼度に関する要求条件（例えば、BLER＝10-4以下の誤り率）を実現するようなPUCCHは設計されていない。
【００２６】
また、NRの端末は、複数のユースケース又はサービス（例えば、eMBB及びURLLC等）に対応することが想定される。また、NRの端末は、URLLCにおいて、目標誤り率の異なる複数のデータ伝送に対応することも想定される。このとき、上りリンクの同一スロット内において、端末が、信頼度、遅延要求又はユースケース（またはサービス）の種類が異なるデータ伝送にそれぞれ対応する応答信号を同時に送信する場合が発生する可能性がある。
【００２７】
Release 15 NRでは、１スロット内において応答信号を送信できるPUCCHの数は１つに制限されている。したがって、仮に、上述したように同一スロット内において信頼度、遅延要求又はユースケース(またはサービス)の種類が異なるデータ伝送に対応する応答信号が同時に送信される場合、これらの応答信号は、１つのPUCCHに多重して送信される。
【００２８】
例えば、Release 15 NRにおける方法では、要求される信頼度が異なる応答信号が多重される場合、高い信頼度が要求される応答信号の要求条件を満たすために、高い信頼度が要求される応答信号の信頼度に合わせてPUCCHに対する無線リソースを設定することが考えられる。しかし、この場合、当該高い信頼度が要求される応答信号と比較して低い信頼度が要求される応答信号（換言すると、高い信頼度が要求されない応答信号）に対しても、高い信頼度が要求される応答信号と同様にPUCCHに対する無線リソースが設定されるため、リソース利用効率の観点から非効率である。
【００２９】
また、要求される信頼度が異なる応答信号が多重される場合、応答信号を多重するためのHARQ-ACKコードブック（応答信号ビット列）では、信頼度、遅延要求又はユースケース(またはサービス)の種類に関係なく、時間的に早く受信した下りリンクデータに対応する応答信号から順に並べられる。例えば、遅延要求が異なる応答信号（例えば、eMBB及びURLLCに対応する応答信号）が１つのPUCCHに多重して送信される場合、低遅延を要求されない応答信号（例えば、eMBBの応答信号）の送信が遅延のボトルネックとなる場合がある。
【００３０】
そこで、本開示の一実施例では、信頼度、遅延要求、又は、ユースケース（またはサービス）の種類が異なる応答信号の送信方法について説明する。換言すると、信頼度、遅延要求又はユースケース（又はサービス）の種類等の「要求条件」に応じた応答信号の送信方法について説明する。
【００３１】
以下、各実施の形態について、詳細に説明する。
【００３２】
（実施の形態１）
［通信システムの概要］
本開示の各実施の形態に係る通信システムは、基地局１００及び端末２００を備える。
【００３３】
図１は、本開示の各実施の形態に係る端末２００の一部の構成を示すブロック図である。図１に示す端末２００において、制御部２１１は、上りリンク制御情報（UCI。例えば、下りリンクデータに対する応答信号）に対する要求条件（例えば、信頼度、遅延要求又はユースケース（サービス）の種類）に応じて、上りリンク制御情報又は上りリンク制御情報の送信に用いる上りリンク制御チャネル（例えば、PUCCH）に対する処理態様（例えば、送信方法又はパラメータ設定など）を決定する。送信部２１６は、決定された処理態様に基づいて、上りリンク制御チャネルを用いて上りリンク制御情報を送信する。
【００３４】
［基地局の構成］
図２は、本開示の実施の形態１に係る基地局１００の構成を示すブロック図である。図２において、基地局１００は、制御部１０１と、データ生成部１０２と、符号化部１０３と、再送制御部１０４と、変調部１０５と、上位制御信号生成部１０６と、符号化部１０７と、変調部１０８と、下り制御信号生成部１０９と、符号化部１１０と、変調部１１１と、信号割当部１１２と、IFFT（Inverse Fast Fourier Transform）部１１３と、送信部１１４と、アンテナ１１５と、受信部１１６と、FFT（Fast Fourier Transform）部１１７と、抽出部１１８と、復調部１１９と、復号部１２０と、判定部１２１と、を有する。
【００３５】
制御部１０１は、端末２００の下りリンクデータ送信に関する情報を決定し、決定した情報を符号化部１０３、変調部１０５及び信号割当部１１２に出力する。下りリンクデータ送信に関する情報には、例えば、PDSCHにおいて送信される下りリンクデータの変調符号化方法（例えば、MCS）、又は、PDSCHの無線リソース（以下、「PDSCHリソース」と呼ぶ）等が含まれる。また、制御部１０１は、決定した情報を下り制御信号生成部１０９に出力する。
【００３６】
また、制御部１０１は、端末２００の下りリンクデータの信頼度、遅延要求又はユースケース（又はサービス）の種類に関する情報（換言すると、応答信号の要求条件に関する情報）を決定し、決定した情報を上位制御信号生成部１０６又は下り制御信号生成部１０９へ出力する。この情報は、端末２００（例えば、制御部２１１）へ通知される。
【００３７】
また、制御部１０１は、端末２００の上りリンク制御情報（UCI：Uplink Control Information）の送信に関する情報を決定し、決定した情報を、抽出部１１８及び復号部１２０へ出力する。また、制御部１０１は、UCIの送信に関する情報を上位制御信号生成部１０６又は下り制御信号生成部１０９へ出力する。UCIの送信に関する情報には、例えば、UCI（例えば、応答信号又はCSI等）又はUCIの送信に用いるPUCCHの送信方法又はパラメータ等が含まれる。
【００３８】
また、上位制御信号生成部１０６に出力される情報には、例えば、PUCCH resource setに関する情報、準静的（Semi-static）に設定されるスロット位置（例えば、PDSCH-to-HARQ-ACK timing）の集合に関する情報、又は、UCIの最大符号化率に関する情報等が含まれる。また、下り制御情報生成部１０９に出力される情報には、例えば、PUCCH resource set内の実際に用いるPUCCHの無線リソース（以下、PUCCHリソース）を指示するための情報、準静的に設定されるスロット位置の集合内の実際に用いるPDSCH-to-HARQ-ACK timingを指示するための情報等が含まれる。
【００３９】
また、制御部１０１は、上位レイヤの制御信号（上位制御信号）又は下りリンク制御情報を送信するための下りリンク制御信号に対する無線リソース割当、及び、下りリンクデータに対する無線リソース割当を決定し、決定した情報を信号割当部１１２へ出力する。
【００４０】
データ生成部１０２は、端末２００に対する下りリンクデータを生成し、符号化部１０３へ出力する。
【００４１】
符号化部１０３は、データ生成部１０２から入力される下りリンクデータに対して、制御部１０１から入力される情報（例えば、符号化率に関する情報）に基づいて誤り訂正符号化を行い、符号化後のデータ信号を再送制御部１０４へ出力する。
【００４２】
再送制御部１０４は、初回送信時には、符号化部１０３から入力される符号化後のデータ信号を保持するとともに、変調部１０５へ出力する。また、再送制御部１０４は、後述する判定部１２１から、送信したデータ信号に対するNACKが入力されると、対応する保持データを変調部１０５へ出力する。一方、再送制御部１０４は、判定部１２１から、送信したデータ信号に対するACKが入力されると、対応する保持データを削除する。
【００４３】
変調部１０５は、制御部１０１から入力される情報（例えば、変調方式に関する情報）に基づいて、再送制御部１０４から入力されるデータ信号を変調して、データ変調信号を信号割当部１１２へ出力する。
【００４４】
上位制御信号生成部１０６は、制御部１０１から入力される制御情報を用いて、制御情報ビット列（上位制御信号）を生成し、生成した制御情報ビット列を符号化部１０７へ出力する。
【００４５】
符号化部１０７は、上位制御信号生成部１０６から入力される制御情報ビット列に対して誤り訂正符号化を行い、符号化後の制御信号を変調部１０８へ出力する。
【００４６】
変調部１０８は、符号化部１０７から入力される制御信号を変調して、変調後の制御信号を信号割当部１１２へ出力する。
【００４７】
下り制御信号生成部１０９は、制御部１０１から入力される制御情報を用いて、制御情報ビット列（下り制御信号。例えば、DCI）を生成し、生成した制御情報ビット列を符号化部１１０へ出力する。なお、制御情報が複数の端末向けに送信されることもあるため、下り制御信号生成部１０９は、各端末向けの制御情報に、各端末の端末IDを含めてビット列を生成してもよい。なお、端末IDには、後述するスクランブリング系列が用いられてもよい。
【００４８】
符号化部１１０は、下り制御信号生成部１０９から入力される制御情報ビット列に対して誤り訂正符号化を行い、符号化後の制御信号を変調部１１１へ出力する。
【００４９】
変調部１１１は、符号化部１１０から入力される制御信号を変調して、変調後の制御信号を信号割当部１１２へ出力する。
【００５０】
信号割当部１１２は、制御部１０１から入力される無線リソースを示す情報に基づいて、変調部１０５から入力されるデータ信号、変調部１０８から入力される上位制御信号、又は、変調部１１１から入力される下り制御信号を、無線リソースにマッピングする。信号割当部１１２は、信号がマッピングされた下りリンクの信号をIFFT部１１３へ出力する。
【００５１】
IFFT部１１３は、信号割当部１１２から入力される信号に対して、OFDM等の送信波形生成処理を施す。IFFT部１１３は、CP（Cyclic Prefix）を付加するOFDM伝送の場合には、CPを付加する（図示せず）。IFFT部１１３は、生成した送信波形を送信部１１４へ出力する。
【００５２】
送信部１１４は、IFFT部１１３から入力される信号に対してD/A（Digital-to-Analog）変換、アップコンバート等のRF（Radio Frequency）処理を行い、アンテナ１１５を介して端末２００に無線信号を送信する。
【００５３】
受信部１１６は、アンテナ１１５を介して受信された端末２００からの上りリンク信号波形に対して、ダウンコンバート又はA/D（Analog-to-Digital）変換などのRF処理を行い、受信処理後の上りリンク信号波形をFFT部１１７に出力する。
【００５４】
FFT部１１７は、受信部１１６から入力される上りリンク信号波形に対して、時間領域信号を周波数領域信号に変換するFFT処理を施す。FFT部１１７は、FFT処理により得られた周波数領域信号を抽出部１１８へ出力する。
【００５５】
抽出部１１８は、制御部１０１から入力される情報（例えば、UCIの送信に関する情報）に基づいて、FFT部１１７から入力される信号から、PUCCHが送信された無線リソース成分を抽出する。抽出部１１８は、抽出した無線リソース成分を復調部１１９へ出力する。
【００５６】
復調部１１９は、抽出部１１８から入力されるPUCCHに対応する無線リソース成分に対して、等化及び復調を行い、復調結果（復調系列）を復号部１２０へ出力する。
【００５７】
復号部１２０は、制御部１０１から入力されるUCIの送信に関する情報（例えば、UCIの符号化に関する情報）に基づいて、復調部１１９から入力される復調結果に対して誤り訂正復号を行い、復号後のビット系列を判定部１２１へ出力する。
【００５８】
判定部１２１は、復号部１２０から入力されるビット系列に基づいて、端末２００から送信された応答信号が、送信したデータ信号に対してACK（誤り有り）又はNACK（誤り無し）の何れを示しているかを判定する。判定部１２１は、判定結果を再送制御部１０４に出力する。
【００５９】
［端末の構成］
図３は、本開示の実施の形態１に係る端末２００の構成を示すブロック図である。図３において、端末２００は、アンテナ２０１と、受信部２０２と、FFT部２０３と、抽出部２０４と、下り制御信号復調部２０５と、復号部２０６と、上位制御信号復調部２０７と、復号部２０８と、データ復調部２０９と、復号部２１０と、制御部２１１と、符号化部２１２と、変調部２１３と、信号割当部２１４と、IFFT部２１５と、送信部２１６と、を有する。
【００６０】
受信部２０２は、アンテナ２０１を介して受信された基地局１００からの下りリンク信号（データ信号又は制御信号）の信号波形に対して、ダウンコンバート又はA/D（Analog-to-Digital）変換などのRF処理を行い、得られる受信信号（ベースバンド信号）をFFT部２０３に出力する。
【００６１】
FFT部２０３は、受信部２０２から入力される信号（時間領域信号）に対して、時間領域信号を周波数領域信号に変換するFFT処理を施す。FFT部２０３は、FFT処理により得られた周波数領域信号を抽出部２０４へ出力する。
【００６２】
抽出部２０４は、制御部２１１から入力される制御情報（例えば、下りリンクデータ又は制御信号の無線リソースに関する情報）に基づいて、FFT部２０３から入力される信号から、下り制御信号（例えば、DCI）、上位制御信号、又は、下りリンクデータを抽出する。抽出部２０４は、下り制御信号を下り制御信号復調部２０５へ出力し、上位制御信号を上位制御信号復調部２０７へ出力し、下りリンクデータをデータ復調部２０９へ出力する。
【００６３】
下り制御信号復調部２０５は、抽出部２０４から入力される下り制御信号を等化及び復調して、復調結果を復号部２０６へ出力する。
【００６４】
復号部２０６は、下り制御信号復調部２０５から入力される復調結果を用いて誤り訂正復号を行い、制御情報を得る。復号部２０６は、得られた制御情報を制御部２１１に出力する。
【００６５】
上位制御信号復調部２０７は、抽出部２０４から入力される上位制御信号を等化及び復調し、復調結果を復号部２０８へ出力する。
【００６６】
復号部２０８は、上位制御信号復調部２０７から入力される復調結果を用いて誤り訂正復号を行い、制御情報を得る。復号部２０８は、得られた制御情報を制御部２１１に出力する。
【００６７】
データ復調部２０９は、抽出部２０４から入力される下りリンクデータを等化及び復調し、復号結果を復号部２１０へ出力する。
【００６８】
復号部２１０は、データ復調部２０９から入力される復調結果を用いて誤り訂正復号を行う。また、復号部２１０は、下りリンクデータに対して誤り検出を行い、誤り検出結果を制御部２１１に出力する。また、復号部２１０は、誤り検出の結果、誤り無しと判定した下りリンクデータを受信データとして出力する。
【００６９】
制御部２１１は、復号部２０６又は復号部２０８から入力される制御情報に含まれる、端末２００のUCIの送信に関する情報に基づいて、UCI（例えば、ACK/NACK又はCSI）又はUCIの送信に用いるPUCCHの送信方法又はパラメータ（例えば、MCS又は無線リソース等）を決定する。制御部２１１は、決定した情報を符号化部２１２、変調部２１３及び信号割当部２１４へ出力する。
【００７０】
また、制御部２１１は、復号部２１０から入力される誤り検出結果を用いて応答信号（ACK/NACK）を生成し、符号化部２１２に出力する。
【００７１】
また、制御部２１１は、復号部２０６又は復号部２０８から入力される制御情報に含まれる、下りリンクデータ又は制御信号の無線リソースに関する情報を、抽出部２０４に出力する。
【００７２】
符号化部２１２は、制御部２１１から入力される情報に基づいて、応答信号（ACK/NACKのビット系列）を誤り訂正符号化し、符号化後の応答信号（ビット系列）を変調部２１３へ出力する。例えば、符号化部２１２は、後述するように、信頼度、遅延要求又はユースケース(またはサービス)の種類等の要求条件の異なる応答信号に対して、異なる符号化方法を適用して符号化ビット列を生成してもよい。
【００７３】
変調部２１３は、制御部２１１から入力される情報に基づいて、符号化部２１２から入力される応答信号を変調して、変調後の応答信号（変調シンボル列）を信号割当部２１４へ出力する。例えば、変調部２１３は、符号化部２１２から、異なる符号化方法が適用された符号化ビット列が入力される場合、各符号化ビット列に対して変調を行う。
【００７４】
信号割当部２１４は、変調部２１３から入力される応答信号（変調シンボル列）を、制御部２１１から指示されるPUCCHの無線リソースにマッピングする。信号割当部２１４は、応答信号がマッピングされた信号をIFFT部２１５へ出力する。
【００７５】
IFFT部２１５は、信号割当部２１４から入力される信号に対して、OFDM等の送信波形生成処理を施す。IFFT部２１５は、CP（Cyclic Prefix）を付加するOFDM伝送の場合には、CPを付加する（図示せず）。または、IFFT部２１５がシングルキャリア波形を生成する場合には、信号割当部２１４の前段にDFT（Discrete Fourier Transform）部が追加されてもよい（図示せず）。IFFT部２１５は、生成した送信波形を送信部２１６へ出力する。
【００７６】
送信部２１６は、IFFT部２１５から入力される信号に対してD/A（Digital-to-Analog）変換、アップコンバート等のRF（Radio Frequency）処理を行い、アンテナ２０１を介して基地局１００に無線信号を送信する。
【００７７】
［基地局１００及び端末２００の動作］
以上の構成を有する基地局１００及び端末２００における動作について詳細に説明する。
【００７８】
図４は、本実施の形態に係る基地局１００及び端末２００の処理のフローを示す。
【００７９】
基地局１００は、PUCCHに関する情報を端末２００へ送信する（ＳＴ１０１）。端末２００は、基地局１００から通知されるPUCCHに関する情報を取得する（ＳＴ１０２）。PUCCHに関する情報には、例えば、PUCCH resource setに関する情報、又は、PUCCHの符号化率に関する情報が含まれる。
【００８０】
基地局１００は、下りリンクデータに関する情報を含むDCIを、端末２００へ送信する（ＳＴ１０３）。端末２００は、例えば、基地局１００から通知されるDCIに基づいて、下りリンクデータのスケジューリング情報、又は、PUCCHに関する情報を取得する（ＳＴ１０４）。
【００８１】
基地局１００は、下りリンクデータを端末２００へ送信する（ＳＴ１０５）。端末２００は、例えば、基地局１００から通知されているDCIに基づいて、下りリンクデータ（PDSCH）を受信する（ＳＴ１０６）。
【００８２】
端末２００は、応答信号に対する要求条件（換言すると、信頼度、遅延要求又はユースケース（サービス）の種類）に応じて、応答信号又は応答信号の送信に関する動作を制御する（ＳＴ１０７）。例えば、端末２００は、応答信号に対する要求条件に応じて、応答信号又はPUCCHに対する処理態様を決定する。応答信号又はPUCCHに対する処理態様の決定では、例えば、応答信号の符号化方法、PUCCHリソースの決定方法、又は、PUCCH送信に関するパラメータ等が決定されてもよい。
【００８３】
端末２００は、決定した動作に基づいて、PUCCHを用いてUCI（例えば、応答信号を含む）を基地局１００へ送信する（ＳＴ１０８）。基地局１００は、端末２００から送信されるUCIを受信する（ＳＴ１０９）。
【００８４】
次に、端末２００におけるUCI送信に関する動作（例えば、図４のＳＴ１０７の処理）の制御方法について詳細に説明する。
【００８５】
［符号化方法］
端末２００は、信頼度、遅延要求、又は、ユースケース（またはサービス）の種類が異なる応答信号（換言すると、要求条件の異なる応答信号）に対して、異なる符号化方法を適用して、HARQ-ACKビットを生成する。
【００８６】
そして、端末２００は、異なる符号化方法を適用した符号化後の応答信号をPUCCHに多重して送信する。
【００８７】
例えば、端末２００は、信頼度、遅延要求、又は、ユースケース（またはサービス）の種類が異なる応答信号に対して、異なる符号化率による符号化処理を適用する。
【００８８】
例えば、端末２００は、高い信頼度が要求される応答信号に対して、低い符号化率（例えば、閾値以下の符号化率）を用いて応答信号を符号化して、HARQ-ACKビットを生成する。低い符号化率を適用することにより、応答信号の信頼度を向上できる。
【００８９】
一方、端末２００は、高い信頼度が要求されない応答信号に対して、高い符号化率（例えば、閾値より高い符号化率）を用いて応答信号を符号化して、HARQ-ACKビットを生成する。高い符号化率を適用することにより、応答信号のビット数の増加を抑えて、リソース利用効率を向上できる。
【００９０】
応答信号に対する符号化処理に差異を生じさせる例として、応答信号の信頼度が異なる場合について説明する。例えば、URLLCにおいて、１回目のデータ送信の目標誤り率が高い（例えば、BLER=10-1）下りリンクデータに対する応答信号と、１回目のデータ送信の目標誤り率が低い（例えば、BLER=10-5）下りリンクデータに対する応答信号と、で符号化処理に差異を生じさせてもよい。
【００９１】
具体的には、１回目のデータ送信の目標誤り率が高い場合、データを確実に再送させるために、応答信号には高い信頼度が要求されるため、応答信号に対して、低い符号化率の符号化方法が適用される。一方、１回目のデータ送信の目標誤り率が低い場合、データの誤りが発生しにくいので、応答信号にはそれほど高い信頼度が要求されないため、応答信号に対して高い符号化率の符号化方法が適用される。
【００９２】
また、応答信号に対する符号化処理に差異を生じさせる他の例として、応答信号の遅延要求が異なる場合、又は、応答信号のユースケース（またはサービス）の種類（例えば、URLLC又はeMBB等）が異なる場合がある。
【００９３】
一例として、図５は、URLLCとeMBBとで異なる符号化方法（符号化処理）が応答信号に適用される例を示す。図５では、端末２００は、eMBBの下りリンクデータ（eMBB PDSCH）に対する応答信号に対して符号化処理１（encoding process 1）を適用し、URLLCの下りリンクデータ（URLLC PDSCH）に対する応答信号に対して符号化処理２（encoding process 2）を適用する。
【００９４】
例えば、URLLCでは高い信頼度が要求されるため、応答信号に対する符号化処理２では、低い符号化率の符号化方法が適用される。一方、eMBBでは、URLLCと比較して高い信頼度が要求されないため、応答信号に対する符号化処理１では、高い符号化率の符号化方法が適用される。
【００９５】
図５において、端末２００は、URLLCの応答信号及びeMBBの応答信号に対してそれぞれ異なる符号化方法を適用してHARQ-ACKビットをそれぞれ生成し、生成したHARQ-ACKビットを１つのPUCCHに多重して基地局１００へ送信する。
【００９６】
このように、本実施の形態によれば、端末２００は、応答信号の信頼度、遅延要求又はユースケース(またはサービス)の種類に応じて、応答信号毎に適切な符号化方法（例えば、符号化率)を適用できる。これにより、１つのPUCCHに多重される応答信号の要求条件が異なる場合でも、各応答信号の要求条件に応じた符号化方法を用いて各応答信号が符号化されるので、リソース利用効率の観点から効率的なPUCCH送信が可能になる。
【００９７】
なお、ACK/NACK毎に異なる符号化処理は、上述した信頼度、又は、ユースケース（サービス）の種類に基づいて決定される場合に限定されず、例えば、信頼度、遅延要求又はユースケース（サービス）の種類の少なくとも１つに基づいて決定されればよい。
【００９８】
［マッピング方法］
次に、信頼度、遅延要求、又は、ユースケース（またはサービス）の種類が異なる応答信号（換言すると、要求条件の異なる応答信号）のPUCCHリソースへのマッピング方法について説明する。
【００９９】
例えば、端末２００は、より高い信頼度が要求される応答信号の順に、又は、遅延要求においてより低遅延が要求される応答信号の順に、PUCCHにマッピングする。具体的には、端末２００は、まず、より高い信頼度又はより低遅延が要求される応答信号をPUCCHリソースへマッピングする。次に、端末２００は、高い信頼度又は低遅延が要求されない応答信号をPUCCHリソースへマッピングする。
【０１００】
以下、一例として、１又は２シンボルで構成されるShort-PUCCH（例えば、PUCCH Format 2）及び４シンボル以上のシンボルで構成されるLong-PUCCH（例えば、PUCCH Format 3又はPUCCH Format 4）における応答信号のマッピング方法についてそれぞれ説明する。
【０１０１】
＜Short PUCCHの場合＞
Short PUCCHにおける応答信号のPUCCHリソースへのマッピングとしては、以下の２つの方法（Option 1及びOption 2）を適用できる。
【０１０２】
[Option 1]
図６は、Option 1における応答信号のRE（Resource Element）へのマッピング例を示す。
【０１０３】
図６に示すように、Option 1では、端末２００は、応答信号（HARQ-ACK）を変調した後の変調シンボル列を、「Frequency-first-time-second形式」に基づいて、参照信号（RS: Reference Signal。例えば、DMRS：Demodulation RS）がマッピングされるリソースエレメント（RE: Resource Element）を除いたREへマッピングする。換言すると、端末２００は、PUCCHにおいて、応答信号を、周波数方向から時間方向の順にマッピングする。
【０１０４】
具体的には、REへのマッピングにおいて、上述したように、高い信頼度又は低遅延が要求される応答信号（図６では、URLLCに対するHARQ-ACK）が最初にPUCCHリソースへマッピングされ、続いて、高い信頼度又は低遅延がそれほど要求されない応答信号（図６では、eMBBに対するHARQ-ACK）がPUCCHリソースへマッピングされる。
【０１０５】
Option 1のマッピング方法により、図６では、URLLCに対するHARQ-ACKは、PUCCHを構成する１シンボル目の全てのRE（ただし、DMRSがマッピングされたREを除く）と、２シンボル目の一部のREにマッピングされ、eMBBに対するHARQ-ACKは、２シンボル目の残りのREにマッピングされる。
【０１０６】
Option 1のマッピング方法によれば、例えば、より低遅延が要求される応答信号がPUCCHの先頭シンボルへマッピングされるので、２シンボルのShort PUCCHの場合に、遅延の削減効果が得られる。
【０１０７】
[Option 2]
図７は、Option 2における応答信号のREへのマッピング例を示す。
【０１０８】
図７に示すように、Option 2では、端末２００は、応答信号（HARQ-ACK）を変調した後の変調シンボル列を、Option 1と同様に「Frequency-first-time-second形式」に基づいて、参照信号がマッピングされるREを除いたREへマッピングする。更に、Option 2では、端末２００は、周波数方向において割当帯域内の応答信号が分散されるようにマッピングする。
【０１０９】
具体的には、REへのマッピングにおいて、上述したように、高い信頼度又は低遅延が要求される応答信号（図７では、URLLCに対するHARQ-ACK）が最初にPUCCHリソースへマッピングされ、続いて、高い信頼度又は低遅延がそれほど要求されない応答信号（図７では、eMBBに対するHARQ-ACK）がPUCCHリソースへマッピングされる。また、図７では、URLLCに対するACK/NACK及びeMBBに対応するACK/NACKは、周波数方向において分散してマッピングされる。
【０１１０】
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））において周波数方向に分散してそれぞれマッピングされている。
【０１１１】
Option 2のマッピング方法によれば、Option 1のマッピング方法と同様、より低遅延が要求される応答信号がPUCCHの先頭シンボルへマッピングされるので、２シンボルのShort PUCCHの場合に、遅延の削減効果が得られる。
【０１１２】
また、Option 2のマッピング方法によれば、周波数方向への分散的なマッピングにより、周波数ダイバーシチ効果を得ることができるので、より高品質な応答信号（換言すると、より高信頼度の応答信号）の伝送を実現できる。
【０１１３】
＜Long PUCCHの場合＞
Long-PUCCHにおける応答信号のPUCCHリソースへのマッピングとしては、以下の２つの方法（Option 3及びOption 4）を適用できる。
【０１１４】
[Option 3]
Option 3では、NRのPUCCH Format 3又はPUCCH Format 4におけるHARQ-ACKビットとCSI（CSI Part 1及びCSI Part 2）とのマッピング関係と同様の方法（例えば、非特許文献２を参照）を、信頼度、遅延要求又はユースケース(またはサービス)の種類が異なる応答信号に対するマッピングに適用する。
【０１１５】
図８は、Option 3における応答信号のREへのマッピング例を示す。
【０１１６】
図８に示すように、Option 3では、端末２００は、応答信号（HARQ-ACK）を変調した後の変調シンボル列を、「Frequency-first-time-second形式」に基づいて、RS（図８ではDMRS）がマッピングされるREを除いたREへマッピングする。また、図８に示すように、端末２００は、より高い信頼度が要求される応答信号ほど、PUCCHにおいて参照信号（例えば、DMRS）がマッピングされたシンボルにより近いシンボルにマッピングする。
【０１１７】
具体的には、図８に示すように、REへのマッピングにおいて、上述したように、最初に、高い信頼度が要求されるURLLCに対するHARQ-ACKが、DMRSがマッピングされたシンボルに近いシンボル（前後のシンボル）に順にマッピングされる。続いて、図８に示すように、高い信頼度がそれほど要求されないeMBBに対するHARQ-ACKビットが残りのPUCCHリソースへマッピングされる。
【０１１８】
Option 3のマッピング方法によれば、より高い信頼度が要求されるHARQ-ACKビットが、チャネル推定精度の高いシンボル（DMRSがマッピングされたシンボルに近いシンボル）へマッピングされる。このため、Option 3によれば、より高品質な応答信号（換言すると、より高信頼度の応答信号）の伝送を実現できる。
【０１１９】
[Option 4]
図９は、Option 4における応答信号のREへのマッピング例を示す。
【０１２０】
図９に示すように、Option 4では、端末２００は、応答信号（HARQ-ACK）を変調した後の変調シンボル列を、「Frequency-first-time-second形式」に基づいて、RSがマッピングされるREを除いたREへマッピングする。また、図９に示すように、端末２００は、遅延要求においてより低遅延が要求される応答信号ほど、PUCCHのより早いシンボルにマッピングする。
【０１２１】
具体的には、図９に示すように、REへのマッピングにおいて、上述したように、最初に、低遅延が要求されるURLLCに対するHARQ-ACKがより早いタイミングのシンボル（例えば、先頭シンボル）から順にマッピングされる。続いて、図９に示すように、低遅延がそれほど要求されないeMBBに対するHARQ-ACKが残りのPUCCHリソースへマッピングされる。
【０１２２】
Option 4のマッピング方法によれば、より低遅延が要求される応答信号がPUCCHの先頭シンボルへマッピングされるので、遅延の削減効果がある。
【０１２３】
以上、応答信号のPUCCHリソースへのマッピング方法について説明した。
【０１２４】
このように、端末２００は、高い信頼度又は低遅延が要求される応答信号、つまり、要求条件が厳しい応答信号を、PUCCHリソースへ優先的にマッピングする。これにより、端末２００は、例えば、PUCCHに多重される応答信号のうち、より高い信頼度又はより低遅延が要求される応答信号を、高い信頼度又は低遅延を実現できるPUCCHリソースへ優先的にマッピングできる。よって、本実施の形態によれば、端末２００は、応答信号に対する要求条件に適したPUCCHリソースを用いて、応答信号を送信できる。
【０１２５】
なお、Option 3及びOption 4では、４シンボル以上を用いるLong-PUCCHに対する応答信号のマッピング方法について説明した。一方で、例えば、URLLCでは、Long-PUCCHを用いることは遅延削減の観点から望ましくない。そこで、本実施の形態では、信頼度、遅延要求又はユースケース(又はサービス)の種類が異なる応答信号を１つのPUCCHに多重することを許容するのは、Short-PUCCHに限定してもよい。これにより、低遅延の要求条件を満たしつつ、複数のPUCCH formatに対する設計を省くことができる。
【０１２６】
また、応答信号のPUCCHリソースへのマッピング方法は、上述したOption 1〜4に限定されない。また、例えば、Option 1〜4の何れかを組み合わせてもよい。例えば、Option 3（図８を参照）又はOption 4（図９を参照）において、Option 2（図７を参照）のように、応答信号（HARQ-ACK）は、周波数方向において分散してマッピングされてもよい。
【０１２７】
［PUCCHリソースの決定方法］
次に、本実施の形態におけるPUCCHリソースの決定方法について説明する。
【０１２８】
NRでは、端末の下りリンクデータに対する応答信号を送信するためのPUCCHリソースの特定に関して、基地局が、端末固有の上位レイヤ信号（例えば、RRC（Radio Resource Control）シングナリング）によって、準静的なPUCCHリソースの集合（PUCCH resource set）を通知し、下りリンクデータを割り当てるDCI（Downlink Control Information)によって、PUCCH resource setの中の実際に用いるPUCCHリソースを通知する方法を採用する（例えば、非特許文献３を参照）。
【０１２９】
ここで、PUCCHリソースは、例えば、スロット内のシンボル位置、スロット内のシンボル数、周波数領域位置、周波数領域のリソース数（例えば、RB数又はPRB（Physical RB）数）、周波数ホッピングの適用の有無、又は、符号リソース（例えば、巡回シフト系列又は直交符号）の少なくとも１つからなるパラメータで構成される。
【０１３０】
また、基地局は、端末に対して複数のPUCCH resource setを通知できる。端末は、PUCCHを用いて送信する上りリンク制御情報（UCI: Uplink Control Information）のビット数に基づいて、通知された複数のPUCCH resource setのうちのどのPUCCH resource setを用いるかを決定できる。
【０１３１】
本実施の形態では、端末２００は、PUCCHに多重される応答信号（HARQ-ACK）の符号化後のビット数の合計に基づいて、PUCCH resource setを決定する。
【０１３２】
また、本実施の形態では、PUCCHリソースの決定に係るパラメータについて、信頼度、遅延要求又はユースケース（またはサービス）の種類が異なる応答信号（換言すると、要求条件の異なる応答信号）に対して、異なる値が設定されてもよい。
【０１３３】
例えば、NRでは、PUCCH format毎に最大符号化率が設定されている。端末は、PUCCHの送信に用いるRB数を、PUCCHを用いて送信するUCIのビット数と最大符号化率とから決定する。ただし、PUCCHの送信に用いるRB数について、上述したPUCCH resource setにより通知されるPUCCHリソースのRB数が上限となる。
【０１３４】
本実施の形態では、最大符号化率は、PUCCH format毎、かつ、応答信号の信頼度、遅延要求又はユースケース(またはサービス)の種類毎（換言すると応答信号の要求条件毎）にそれぞれ設定される。
【０１３５】
例えば、端末２００は、信頼度、遅延要求又はユースケース(またはサービス)の種類が異なる応答信号の各々に対して、応答信号の符号化後のビット数と、設定された最大符号化率とに基づいて、応答信号の送信に用いるリソース量（例えば、RE数）を算出する。そして、端末２００は、１つのPUCCHに多重される各応答信号の送信に用いるRE数に基づいて、当該PUCCHの送信に用いるRB数を決定する。
【０１３６】
これにより、端末２００は、例えば、上述したように、応答信号毎に設定される符号化方法による符号化後のビット数に基づいて、要求条件の異なる応答信号が多重されるPUCCHにおけるPUCCH resource setを決定できる。例えば、端末２００は、応答信号の信頼度、遅延要求またはユースケース(またはサービス)の種類に応じた適切なリソース量を算出できるため、リソース利用効率の観点から効率的なPUCCH送信が可能になる。
【０１３７】
なお、PUCCHの送信に用いるRB数については、上述したように、PUCCH resource setにより通知されるPUCCHリソースのRB数が上限となる。このため、例えば、応答信号のビット数と最大符号化率とから決定されるRB数が、PUCCH resource setにより通知される上限値を超える場合には、応答信号の実際の符号化率は、設定された最大符号化率を超える場合がある。この場合、PUCCHの送信において要求される品質を満たせない可能性がある。
【０１３８】
そこで、本実施の形態では、端末２００は、応答信号の実際の符号化率が所定の閾値を超える場合、PUCCHを用いて送信する応答信号の一部をドロップしてもよい。これにより、PUCCHリソースにおいて、応答信号の一部をドロップした分のリソースは、残りの応答信号に使用されるので、PUCCHの送信における品質を向上できる。
【０１３９】
ここで、閾値は、例えば、PUCCH format毎、かつ、応答信号の信頼度、遅延要求又はユースケース(またはサービス)の種類毎に設定される最大符号化率でもよい。また、最大符号化率とは別に、一部の応答信号をドロップするための閾値が基地局１００から端末２００へ新たに通知されてもよい。
【０１４０】
また、端末２００は、PUCCHを用いて送信される応答信号（又はUCI）のビット数と、最大符号化率とから算出されるRB数が所定の閾値（上限値）を超える場合、PUCCHを用いて送信する応答信号の少なくとも一部をドロップしてもよい。これにより、PUCCHリソースにおいて、応答信号の一部をドロップした分のリソースは、残りの応答信号に使用されるので、PUCCHの送信における品質を向上できる。
【０１４１】
また、ドロップする応答信号は、応答信号の信頼度、遅延要求又はユースケース（またはサービス）の種類に応じて設定される優先度（換言すると、要求条件毎に設定される優先度）に応じて決定されてもよい。例えば、端末２００は、優先度の高い要求条件の応答信号を優先的に送信してもよい。換言すると、端末２００は、優先度の低い要求条件の応答信号を優先的にドロップしてもよい。
【０１４２】
優先度の一例として、応答信号の信頼度が異なる場合、例えば、URLLCにおいて、１回目のデータ送信の目標誤り率が高い（例えば、BLER=10-1）下りリンクデータに対する応答信号の優先度は、１回目のデータ送信の目標誤り率が低い（例えば、BLER=10-5）下りリンクデータに対する応答信号の優先度よりも高く設定される。または、応答信号の遅延要求が異なる場合又はユースケース(またはサービス)の種類が異なる場合、例えば、URLLCの優先度は、eMBBの優先度よりも高く設定される。
【０１４３】
信頼度、遅延要求又はユースケース(またはサービス)の種類が異なる応答信号の少なくとも１つの符号化率が閾値を超えた場合、端末２００は、優先度の低い応答信号からドロップしてもよい。これにより、優先度の高い応答信号、つまり、より高い信頼度が要求される応答信号の伝送品質の劣化を抑えることができる。
【０１４４】
また、信頼度、遅延要求またはユースケース(またはサービス)の種類が異なる応答信号がある場合、異なる応答信号に対してPUCCH内のリソース（例えば、RE）をどのような割合で共有又は分割するかを示す情報（例えば、resource sharing factor又はresource splitting factor）を基地局１００から端末２００へ予め通知してもよい。
【０１４５】
以上、PUCCHリソースの決定方法について説明した。
【０１４６】
このように、本実施の形態では、端末２００は、下りリンクデータの応答信号に対する要求条件（例えば、信頼度、遅延要求又はユースケース（サービス）の種類）に応じて、応答信号又はPUCCHに対する処理態様を決定する。具体的には、端末２００は、要求条件の異なる応答信号に対して、異なる符号化方法を適用する。そして、端末２００は、符号化後の応答信号を、PUCCHに多重して送信する。
【０１４７】
これにより、本実施の形態によれば、要求条件が異なる応答信号がPUCCHに多重される場合でも、端末２００は、PUCCHに多重される応答信号に要求される要求条件に応じた処理（例えば、符号化処理）又は無線リソースの設定（例えば、マッピング方法又はPUCCHリソースの決定）をそれぞれ行うことができる。例えば、端末２００は、応答信号に要求される信頼度に応じたPUCCHリソースの位置又は量を設定することにより、PUCCHにおけるリソース利用効率を向上できる。また、例えば、端末２００は、応答信号に対する遅延要求に応じたPUCCHリソースの位置を設定することにより、応答信号の遅延を削減できる。
【０１４８】
以上より、本実施の形態によれば、端末２００は、応答信号を含むUCIを適切に送信できる。
【０１４９】
（実施の形態２）
本実施の形態に係る基地局及び端末は、実施の形態１に係る基地局１００及び端末２００と基本構成が共通するので、図２及び図３を援用して説明する。
【０１５０】
本実施の形態では、端末２００は、信頼度、遅延要求又はユースケース(またはサービス)の種類が異なる応答信号（換言すると、要求条件の異なる応答信号）に対して、PUCCHリソース又はPUCCHリソースセットの決定方法を異ならせる。
【０１５１】
また、本実施の形態では、１スロット内において端末２００が応答信号を送信できるPUCCHの数を１つに制限しない。換言すると、本実施の形態では、１スロット内において端末２００が応答信号を送信できるPUCCHの数は、１つ以上である。
【０１５２】
例えば、端末２００は、要求条件の異なる各応答信号を、スロット内の異なるPUCCHを用いてそれぞれ送信する。例えば、複数のPUCCHは、時間分割多重（TDM：Time Division Multiplexing）、周波数分割多重（FDM：Frequency Division Multiplexing）、又は、符号分割多重（CDM：Code Division Multiplexing）により同一スロット内に多重される。
【０１５３】
これにより、端末２００は、応答信号の信頼度、遅延要求又はユースケース(またはサービス)の種類に応じて、応答信号毎に適切なPUCCHリソースを割り当てることができる。換言すると、端末２００は、要求条件の異なる応答信号を、１つのPUCCHに多重せずに、個別のPUCCHを用いて送信できる。このため、リソース利用効率の観点から効率的なPUCCH送信が可能となる。
【０１５４】
また、本実施の形態によれば、端末２００は、例えば、遅延要求の異なる応答信号を、異なるPUCCHを用いて送信できる。このため、例えば、URLLCのように低遅延が要求される応答信号をShort-PUCCHを用いて送信し、eMBBのように低遅延がそれほど要求されない応答信号をLong-PUCCHを用いて送信することにより、遅延要求に対するボトルネックを解消できる。
【０１５５】
例えば、端末２００の下りリンクデータに対する応答信号を送信するためのPUCCHリソースの特定に関して、基地局１００は、端末固有の上位レイヤ信号（例えば、RRCシグナリング）によって、準静的なPUCCHリソースの集合（例えば、PUCCH resource set）を通知する。端末２００は、例えば、以下の２つの方法（Option 1及びOption 2）の何れかに基づいてPUCCH resource setを決定する。
【０１５６】
[Option 1]
Option 1では、信頼度、遅延要求又はユースケース(またはサービス)の種類が異なる応答信号（換言すると、要求条件の異なる応答信号）に対して、異なるPUCCH resource setのグループが設定される。よって、端末２００は、要求条件の異なる応答信号に対して、異なるグループに含まれるPUCCH resource setをそれぞれ設定する。
【０１５７】
図１０Ａは、Option 1におけるPUCCH resource setの設定例を示す。
【０１５８】
図１０Ａでは、eMBB及に対するPUCCH resource setのグループ（例えばグループＸ）、及び、URLLCに対するPUCCH resource setのグループ（例えば、グループＹ）が設定されている。例えば、図１０Ａでは、グループＸには、PUCCH resource set X0, X1, X2及びX3が含まれ、グループＹには、PUCCH resource set Y0, Y1, Y2及びY3が含まれる。
【０１５９】
端末２００は、例えば、信頼度、遅延要求又はユースケース(またはサービス)の種類が異なる応答信号毎に、PUCCHを用いて送信するUCIのビット数（例えば、HARQ-ACKビット数）に基づいて、各グループ内のどのPUCCH resource setを用いるかを決定する。
【０１６０】
例えば、図１０Ａでは、端末２００は、eMBBに対する応答信号のビット数に基づいて、グループＸ内のPUCCH resource setの中から、PUCCH resource set X1を選択する。また図１０Ａでは、端末２００は、URLLCに対する応答信号のビット数に基づいて、グループＹ内のPUCCH resource setの中から、PUCCH resource set Y0を選択する。
【０１６１】
また、端末２００には、信頼度、遅延要求又はユースケース(またはサービス)の種類が異なる応答信号の各々に対応する下りリンクデータを割り当てるDCI（例えば、図１０Ｂに示すDL assignment for eMBB又はDL assignment for URLLC）によって、選択したPUCCH resource setの中の実際に用いるPUCCHリソースが通知される。端末２００は、選択したPUCCH resource setのうち、DCIによって通知されたPUCCHリソースを用いて、応答信号を送信する。
【０１６２】
Option 1によれば、信頼度、遅延要求又はユースケース(またはサービス)の種類毎にPUCCH resource setが個別に設定されるので、信頼度、遅延要求又はユースケース(またはサービス)の種類が異なる応答信号に適したPUCCHリソースをより柔軟に割り当てることができる。
【０１６３】
なお、図１０Ａに示すPUCCH resource setの設定例は一例であって、限定されない。例えば、eMBB及びURLLCに対するPUCCH resource setのグループ内に含まれるPUCCH resource setの数は、４個に限定されず、他の個数でもよい。また、eMBB及びURLLCに対するPUCCH resource setの各グループ内に含まれるPUCCH resource setの数は同一でもよく、異なってもよい。また、図１０Ａでは、要求条件の異なる場合の一例として、eMBB及びURLLCについて説明したが、これに限定されず、例えば、異なる信頼度又は異なる遅延要求の少なくとも一方に応じてPUCCH resource setのグループが設定されてもよい。
【０１６４】
[Option 2]
Option 2では、信頼度、遅延要求又はユースケース(またはサービス)の種類が異なる応答信号（換言すると、要求条件の異なる応答信号）に対して、同一のPUCCH resource setのグループが設定される。よって、端末２００は、要求条件の異なる応答信号に対して、同一グループに含まれるPUCCH resource setをそれぞれ設定する。
【０１６５】
図１１Ａは、Option 2におけるPUCCH resource setの設定例を示す。
【０１６６】
図１１Ａでは、PUCCH resource set 0, 1, 2及び3を含むグループが設定されている。
【０１６７】
端末２００は、例えば、信頼度、遅延要求又はユースケース(またはサービス)の種類に依らず、PUCCHを用いて送信するUCIのビット数（例えば、HARQ-ACKビット数）に基づいて、同一グループ内のどのPUCCH resource setを用いるかを決定する。
【０１６８】
例えば、図１１Ａでは、端末２００は、eMBBに対する応答信号のビット数に基づいて、PUCCH resource set 0〜3の中から、PUCCH resource set 1を選択する。また、図１１Ａでは、端末２００は、URLLCに対する応答信号のビット数に基づいて、PUCCH resource set 0〜3の中から、PUCCH resource set 0を選択する。
【０１６９】
また、端末２００には、信頼度、遅延要求又はユースケース(またはサービス)の種類が異なる応答信号の各々に対応する下りリンクデータを割り当てるDCI（例えば、図１１Ｂに示すDL assignment for eMBB又はDL assignment for URLLC）によって、選択したPUCCH resource setの中の実際に用いるPUCCHリソースが通知される。端末２００は、選択したPUCCH resource setのうち、DCIによって通知されたPUCCHリソースを用いて、応答信号を送信する。
【０１７０】
Option 2によれば、信頼度、遅延要求又はユースケース(またはサービス)の種類に依らず、選択可能なPUCCH resource setは同一である。このため、PUCCH resource setの通知に係るオーバヘッドを削減できる。
【０１７１】
また、端末２００は、信頼度、遅延要求又はユースケース(またはサービス)の種類が異なる応答信号の各々のビット数に基づいて、実際に用いるPUCCH resource setを個別に決定できる。このため、端末２００は、信頼度、遅延要求又はユースケース(またはサービス)の種類が異なる応答信号に適したPUCCHリソースをそれぞれ用いることができる。
【０１７２】
以上、PUCCH resource setの決定方法について説明した。
【０１７３】
このように、本実施の形態では、端末２００は、要求条件（例えば、信頼度、遅延要求又はユースケース（サービス）の種類）の異なる応答信号に対して、異なるリソース決定方法を適用する。そして、端末２００は、各応答信号に対して設定したPUCCHリソースを用いて、当該応答信号を送信する。
【０１７４】
これにより、本実施の形態によれば、端末２００は、応答信号に要求される要求条件に応じた無線リソースをそれぞれ個別に設定できるので、リソース利用効率の向上、又は、応答信号の遅延を削減できる。以上より、本実施の形態によれば、端末２００は、応答信号を含むUCIを適切に送信できる。
【０１７５】
なお、本実施の形態では、信頼度、遅延要求又はユースケース(またはサービス)の種類が異なる応答信号に対して、異なるPUCCHリソース又は異なるPUCCHリソースセットを決定する方法について説明した。ただし、本実施の形態におけるリソース決定方法に基づいて各応答信号に対して決定されたPUCCHリソースが同一である場合、端末２００は、実施の形態１と同様の処理を適用してもよい。
【０１７６】
また、本実施の形態に係るOption 1では、信頼度、遅延要求又はユースケース（またはサービス）の種類毎に、異なるPUCCH resource setのグループが設定される場合について説明した。これに対して、さらに、PUCCH resource setに関するパラメータについて、信頼度、遅延要求又はユースケース（またはサービス）の種類毎に設定可能な値(または値の範囲)に差異を生じさせてもよい。
【０１７７】
例えば、NRのPUCCH Format 0では、Sequence selectionが用いられる（例えば、非特許文献１を参照）。また、Release 15 NRでは、PUCCH送信に割り当て可能な送信帯域幅は1RBであり、1RB=12サブキャリアに相当する系列長12の送信系列が用いられる。また、NRでは、１セル繰り返しの周波数割当が用いられる。１セル繰り返しでは、セル間干渉が特性劣化の主要因である。特に、Short-PUCCHでは、利用するシンボル数（１シンボル又は２シンボル）が少ないため、複数シンボルを利用することによる干渉の平均化効果によるセル間干渉の抑圧ができない。
【０１７８】
このため、応答信号に対して高い信頼度が要求される場合、セル間干渉の抑圧が必要である。セル間干渉を抑圧する方法として、送信帯域幅（系列長）の拡大が有効である（例えば、非特許文献６を参照）。
【０１７９】
そこで、例えば、PUCCH Format 0について、信頼度、遅延要求又はユースケース(またはサービス)の種類が異なる応答信号に応じて、PUCCHの設定可能なRB数または系列長を異ならせてもよい。
【０１８０】
例えば、高い信頼度が要求される応答信号に対するPUCCH resource setでは、可変のPRB数（例えば、1，2，および4PRBの何れか）を設定可能としてもよい。一方、高い信頼度が要求されない応答信号に対するPUCCH resource setでは、設定可能なPRB数を１PRBとしてもよい。なお、各要求条件に対して設定可能なPRB数は、上記例に限定されず、他の個数でもよい。
【０１８１】
これにより、PUCCH Format 0において、応答信号に対して高い信頼度が要求される場合でも、送信帯域幅（系列長）の拡大によってセル間干渉を抑圧できる。
【０１８２】
また、PUCCH Format 0については、時間領域の繰り返し送信（Repetition）も特性改善に有効な技術である。
【０１８３】
そこで、PUCCH Format 0について、信頼度、遅延要求又はユースケース(またはサービス)の種類が異なる応答信号に応じて、PUCCHの設定可能なRepetition回数を異ならせてもよい。
【０１８４】
例えば、高い信頼度が要求される応答信号に対するPUCCH resource setでは、Repetitionを設定可能とし、可変のRepetition回数（例えば、1，2，および4回の何れか）を設定可能としてもよい。一方、高い信頼度が要求されない応答信号に対するPUCCH resource setでは、Repetitionを設定可能としない。なお、各要求条件に対して設定可能なRepetition回数は、上記例に限定されず、他の回数でもよい。
【０１８５】
これにより、PUCCH Format 0において、応答信号に対して高い信頼度が要求される場合でも、Repetitionによって、特性改善の効果を得ることができる。
【０１８６】
なお、時間領域のRepetitionには、同一の系列を複数シンボルに渡り繰り返し送信する方法がある。この方法では、受信側（例えば、基地局１００）においてRepetition信号を同相合成することにより、受信信号の電力向上による特性改善効果が期待できる。また、時間領域のRepetitionには、系列長を拡大し、拡大した系列の一部を異なるシンボルで送信する方法がある。例えば、系列長を12から24に拡大し、系列長24の前半部分が最初のシンボルで送信され、後半部分が次のシンボルで送信される。この方法では、長い系列長を用いることによる干渉抑圧の効果が期待できる。
【０１８７】
上述したように、PUCCH format 0について、高い信頼度が要求される応答信号に対するPUCCH resource setに対して、Release 15 NRとは異なるパラメータを設定可能とすることにより、Release 15 NRでは考慮されていない再送を許容するURLLCの応答信号の信頼度に関す要求条件（例えば、BLER=10-4以下の誤り率）を実現するPUCCH送信が可能となる。
【０１８８】
（実施の形態２のバリエーション）
実施の形態２では、信頼度、遅延要求又はユースケース(またはサービス)の種類が異なる応答信号に対して、PUCCHリソース又はPUCCHリソースセットの決定方法を異ならせる場合について説明した。
【０１８９】
NRでは、端末は下りリンクデータに対する応答信号を送信するためのPUCCHのスロット位置（又は、下りリンクデータを受信したスロットからPUCCHを送信するスロットまでの時間）の特定に関して、基地局が端末固有の上位レイヤ信号（例えば、RRCシグナリング）によって準静的なスロット位置の集合を通知し、下りリンクデータを割り当てるDCIによって、スロット位置の集合の中の実際に用いるスロット位置を通知する方法が採用されている（例えば、非特許文献３を参照）。
【０１９０】
そこで、実施の形態２のバリエーションでは、応答信号を送信するためのPUCCHのスロット位置の集合についても同様に、信頼度、遅延要求又はユースケース(またはサービス)の種類が異なる応答信号（換言すると、要求条件の異なる応答信号）毎に設定可能とする。
【０１９１】
実施の形態２のバリエーションによれば、端末２００は、応答信号の信頼度、遅延要求又はユースケース(またはサービス)の種類に応じて、応答信号に対する適切な送信スロットを用いることができる。例えば、異なる遅延要求に対して異なるスロット位置の集合が設定されていれば、端末２００は、遅延要求の異なる応答信号を異なるPUCCHを用いてそれぞれ送信する場合でも、遅延要求の異なる応答信号の各々に対して、遅延要求に適したより柔軟なスロット割当が可能になる。
【０１９２】
（実施の形態３）
本実施の形態に係る基地局及び端末は、実施の形態１に係る基地局１００及び端末２００と基本構成が共通するので、図２及び図３を援用して説明する。
【０１９３】
本実施の形態では、端末２００は、同一スロット内に、信頼度、遅延要求又はユースケース(またはサービス)の種類が異なるデータ伝送に対する応答信号を同時に送信する場合、PUCCHの優先度に応じて、応答信号を送信するPUCCHの全てをドロップ、又は、一部をパンクチャする。
【０１９４】
ドロップ又は一部をパンクチャするPUCCHは、ACK/NACKの信頼度、遅延要求又はユースケース(またはサービス)の種類に応じて付与される優先度に基づいて決定されてもよい。
【０１９５】
具体的には、端末２００は、要求条件の異なる応答信号の送信タイミングが同一の場合、要求条件に基づく優先度がより低いPUCCHの全てをドロップ又は一部をパンクチャする。
【０１９６】
PUCCHの優先度の一例として、応答信号の信頼度が異なる場合について説明する。例えば、URLLCにおいて、１回目のデータ送信の目標誤り率が高い（例えば、BLER=10-1）下りリンクデータに対する応答信号を送信するPUCCHの優先度は、１回目のデータ送信の目標誤り率が低い（例えば、BLER=10-5）下りリンクデータに対する応答信号を送信するPUCCHの優先度よりも高く設定される。つまり、端末２００は、１回目のデータ送信の目標誤り率が低い（例えば、BLER=10-5）下りリンクデータに対する応答信号を送信するPUCCHの全てをドロップ又は一部をパンクチャする。
【０１９７】
また、応答信号の遅延要求又はユースケース(またはサービス)の種類が異なる場合について説明する。例えば、図１２は、URLLC及びeMBBの２つのサービスが存在する場合を示す。URLLCに対応するPUCCHの優先度は、eMBBに対応するPUCCHの優先度よりも高く設定される。つまり、端末２００は、eMBBに対応するPUCCHの全てをドロップ又は一部をパンクチャする。例えば、図１２では、端末２００は、URLLCに対応するPUCCH（URLLC PUCCH）を用いて、URLLCに対応する応答信号を送信し、eMBBに対応するPUCCH（eMBB PUCCH）の全てをドロップする。
【０１９８】
本実施の形態によれば、より高い信頼度又は低遅延が要求される応答信号のためのPUCCH送信に対して、別の応答信号のためのPUCCH送信が影響を与えることがなくなるため、より高い信頼度又は低遅延が要求される応答信号の品質を保証できる。
【０１９９】
なお、PUCCHの一部をパンクチャする場合、例えば、異なる応答信号のPUCCH送信において、時間的に重なるシンボルをパンクチャする方法、又は、時間及び周波数が重なるREをパンクチャする方法がある。
【０２００】
時間的に重なるシンボルをパンクチャする方法は、例えば、端末２００が複数の上りリンク信号を同時に送信できない場合、又は、端末２００に複数の上りリンク信号を同時送信できる能力があるものの、送信電力の総和が最大送信電力を超える場合において、何れか一方の信号を送信しなければならない場合に適用できる。
【０２０１】
また、時間及び周波数が重なるREをパンクチャする方法は、例えば、端末２００に複数の上りリンク信号を同時に送信できる能力があり、かつ、複数の上りリンク信号を同時に送信しても端末２００の最大送信電力を超えない場合に適用できる。
【０２０２】
（実施の形態４）
例えば、実施の形態１では、信頼度、遅延要求又はユースケース(またはサービス)の種類が異なる応答信号に対して異なる符号化処理を適用する場合について説明した。しかし、異なる符号化処理を行うことは、端末の処理量を増大させるため、実装を複雑にする恐れがある。
【０２０３】
そこで、本実施の形態では、信頼度、遅延要求又はユースケース(またはサービス)の種類が異なる応答信号に対して、１つの符号化処理を適用する方法について説明する。
【０２０４】
本実施の形態に係る基地局及び端末は、実施の形態１に係る基地局１００及び端末２００と基本構成が共通するので、図２及び図３を援用して説明する。
【０２０５】
端末２００は、下りリンクデータを受信してから、下りリンクデータの復号、応答信号の生成、及び、PUCCH送信までに要する処理時間に関する能力(UE capability。以下、「N1」と表す)を有する。NRでは、端末２００は、「N1」を基地局１００へ報告する。
【０２０６】
基地局１００は、端末２００が下りリンクデータに対する応答信号を送信するためのPUCCHのスロット位置（又は、下りリンクデータを受信したスロットからPUCCH（例えば、応答信号）を送信するスロットまでの時間：「PDSCH-to-HARQ-ACK timing」）を設定し、端末２００へ通知する。このとき、基地局１００は、PDSCH-to-HARQ-ACK timingについて、端末２００から報告された端末２００の処理能力(N1)を超える値（換言すると、N1より小さい値）を設定及び通知できない。
【０２０７】
本実施の形態では、端末２００は、信頼度、遅延要求又はユースケース(またはサービス)の種類が異なる応答信号の送信に対する能力（N1）をそれぞれ規定し、基地局１００へ報告する。また、端末２００は、基地局１００から設定及び通知されたPDSCH-to-HARQ-ACK timingの値と、規定したN1の値とに基づいて、応答信号又は応答信号の送信に用いるPUCCHの送信方法及びパラメータ（換言すると、応答信号又はPUCCHに対する処理態様）を決定する。
【０２０８】
例えば、端末２００は、下りリンクデータを受信してから、データを復号し、応答信号を生成し、PUCCHを送信するまでに必要な処理時間に関する能力(N1)について、信頼度、遅延要求又はユースケース(またはサービス)の種類に応じた２つ以上の能力を有する。端末２００は、２つ以上の能力（N1）を基地局１００へ報告する。
【０２０９】
一例として、端末２００は、eMBBに対するN1(以下、「N1_X」又は「N1_eMBB」と表す)、及び、URLLCに対するN1(以下、「N1_Y」又は「N1_URLLC」と表す)の２つの端末能力(UE capability)を有してもよい。例えば、URLLCでは、eMBBよりも低遅延が要求される可能性が高いので、URLLCに対するN1は、eMBBに対するN1よりも小さい値が設定されてもよい。
【０２１０】
実施の形態２のバリエーションで説明したように、下りリンクデータに対する応答信号を送信するためのPUCCHのスロット位置（PDSCH-to-HARQ-ACK timing）の特定に関して、基地局１００が端末固有の上位レイヤ信号（例えば、RRCシグナリング）によって準静的なスロット位置の集合を通知し、下りリンクデータを割り当てるDCIによって、集合の中のどのPDSCH-to-HARQ-ACK timingを実際に用いるかを通知する。
【０２１１】
同一スロット内において、信頼度、遅延要求又はユースケース(またはサービス)の種類が異なるデータ伝送に対応する応答信号の送信が同時に発生する場合、端末２００は、各応答信号に対するPDSCH-to-HARQ-ACK timingの値と、端末２００が有する能力（N1）とに基づいて、応答信号に対する処理を決定する。
【０２１２】
例えば、図１３に示すように、各応答信号に対するPDSCH-to-HARQ-ACK timingの値の最小値（図１３では、PDSCH-to-HARQ-ACK timing for URLLC）が、eMBBに対するN1（N1_X又はN1_eMBB）以上である場合、端末２００は、eMBBに対応する応答信号及びURLLCに対応する応答信号に対して共通の符号化処理（joint encoding）を行い、HARQ-ACKビットを生成する。
【０２１３】
具体的には、図１３では、端末２００が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の応答信号とに対して共通の符号化処理を行うことができる。
【０２１４】
一方、図１４に示すように、高い信頼度又は低遅延が要求される応答信号、又は、URLLCに対応する応答信号に対するPDSCH-to-HARQ-ACK timingの値（図１４ではPDSCH-to-HARQ-ACK timing for URLLC）が、eMBBに対応するN1（N1_X又はN1_eMBB）未満である場合、端末２００は、eMBBに対応する応答信号及びURLLCに対応する応答信号に対して共通の符号化処理を行うことができない。
【０２１５】
具体的には、図１４では、端末２００が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のACK/NACKと、eMBBのACK/NACKをまとめて符号化処理できない。この場合、端末２００は、実施の形態３又は実施の形態１の何れかの方法を用いる。
【０２１７】
例えば、実施の形態３の方法を用いる場合、信頼度、遅延要求又はユースケース(またはサービス)の種類が異なる応答信号に対して、符号化処理を全体で１つに抑えることができるため、端末２００の実装を簡易にできる利点がある。また、実施の形態１の方法を用いる場合、端末２００は、図１４に示すように、応答信号の信頼度、遅延要求又はユースケース(またはサービス)の種類に応じた適切な符号化(または符号化率)によりHARQ-ACKビットを生成できるため、リソース利用効率の観点から効率的なPUCCH送信が可能になる。
【０２１８】
このように、本実施の形態によれば、端末２００の処理能力に応じて、符号処理をできる限り共通化することができるため、端末２００の処理量の増大又は実装の複雑さを軽減できる。
【０２１９】
以上、本開示の各実施の形態について説明した。
【０２２０】
（１）上記実施の形態では、応答信号の信頼度、遅延要求又はユースケース(またはサービス)の種類に応じて、応答信号又はPUCCHの送信方法、及びパラメータに差異を生じさせた。
【０２２１】
ここで、応答信号又はPUCCHの送信方法、及びパラメータに差異を生じさせる例としては、応答信号の信頼度が異なる場合がある。例えば、URLLCにおいて、１回目のデータ送信の目標誤り率が高い（例えば、BLER=10-1）下りリンクデータに対する応答信号と、１回目のデータ送信の目標誤り率が低い（例えば、BLER=10-5）下りリンクデータに対する応答信号とで、応答信号又はPUCCHの送信方法、及びパラメータに差異を生じさせることができる。前者の応答信号には高い信頼度が要求される一方、後者の応答信号にはそれほど高い信頼度が要求されない。
【０２２２】
また、応答信号又はPUCCHの送信方法、及びパラメータに差異を生じさせる例として、応答信号の遅延要求が異なる場合又はユースケース(またはサービス)が異なる場合がある。例えば、URLLCに対応する応答信号とeMBBに対応する応答信号とで、応答信号又はPUCCHの送信方法、及びパラメータに差異を生じさせることもできる。前者の応答信号には高い信頼度又は低遅延が要求される一方、後者の応答信号にはそれほど高い信頼度又は低遅延が要求されない。また、URLLCには、上述したように、１回目のデータ送信の目標誤り率が高い(例えば、BLER=10-1)下りリンクデータに対する応答信号と、１回目のデータ送信の目標誤り率が低い(例えば、BLER=10-5)下りリンクデータに対する応答信号とが含まれる場合がある。
【０２２３】
また、応答信号又は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を前述の送信区間よりも送信区間が短い送信と置き換えてもよい。
【０２２４】
また、本開示において、目標誤り率は、上述したように１回目のデータ送信の目標誤り率でもよく、再送が発生する場合は、再送における目標誤り率でもよい。また、目標誤り率は、１回目及び再送の各々の目標誤り率という意味で「瞬時目標誤り率」と呼んでもよい。
【０２２５】
（２）上記実施の形態において説明した、応答信号の「信頼度、遅延要求又はユースケース(またはサービス)の種類」（換言すると、要求条件）を判断する方法には、例えば、以下の例１〜例５のような方法がある。
【０２２６】
[例１：スクランブル系列]
例１では、端末２００は、各応答信号に対応する下りリンクデータ伝送をスケジューリングするDCIに用いられる端末固有のスクランブリング系列に基づいて、応答信号の信頼度、遅延要求又はユースケース(サービス)の種類を判断する。
【０２２７】
例えば、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であると判断する。
【０２２８】
例えば、基地局１００の制御部１０１（例えば、図２を参照）は、端末２００の下りリンクデータの信頼度、遅延要求又はユースケース(サービス)の種類に関する情報を決定する。決定した情報は、基地局１００の下り制御信号生成部１０９へ出力される。下り制御信号生成部１０９は、上述したように、端末２００の下りリンクデータの信頼度、遅延要求又はユースケース(またはサービス)の種類に応じたスクランブリング系列を用いてDCIのビット列を生成する。
【０２２９】
一方、端末２００の復号部２０６（例えば、図３を参照）は、検出したスクランブリング系列を制御部２１１へ出力する。制御部２１１は、得られたスクランブリング系列に基づいて、下りリンクデータの信頼度、遅延要求又はユースケース(サービス)の種類に関する情報を判断する。
【０２３０】
[例２：MCSテーブル]
例２では、端末２００は、各応答信号に対応する下りリンクデータ伝送のスケジューリングに用いられるMCSテーブルに基づいて、応答信号の信頼度、遅延要求又はユースケース（サービス）の種類を判断する。
【０２３１】
例えば、Release 15 NRでは、目標BLER=10-1を達成するためのMCSテーブル、及び、目標BLER=10-5を達成するためのMCSテーブルの何れを用いるかを設定できる。
【０２３２】
例えば、端末２００は、URLLCにおいて設定されたMCSテーブルが目標BLER=10-1を達成するためのMCSテーブルである場合、応答信号に要求される信頼度が高いと判断する。一方、端末２００は、URLLCにおいて設定されたMCSテーブルが目標BLER=10-5を達成するためのMCSテーブルである場合、応答信号に要求される信頼度は高くないと判断する。
【０２３３】
例えば、基地局１００の制御部１０１は、端末２００の下りリンクデータの信頼度、遅延要求又はユースケース(サービス)の種類に関する情報を決定する。決定した情報は、基地局１００の下り制御信号生成部１０９、符号化部１０３及び変調部１０５へ出力される。下り制御信号生成部１０９は、下りリンクデータ伝送に用いられるMCSテーブルに関する情報をDCIのビット列に含める。また、符号化部１０３及び変調部１０５は、制御部１０１から入力されるMCSテーブルに関する情報を用いて、下りリンクデータを符号化及び変調する。
【０２３４】
一方、端末２００の復号部２０６は、DCIを復号し、復号結果を制御部２１１へ出力する。制御部２１１は、DCIから得られるMCSテーブルに関する情報に基づいて、下りリンクデータの信頼度、遅延要求又はユースケース(サービス)の種類に関する情報を判断する。
【０２３５】
[例３：PDSCH-to-HARQ-ACK timing又はPDSCHの送信シンボル数]
例３では、端末２００は、各応答信号に対応する下りリンクデータ伝送をスケジューリングするDCIによって通知された「PDSCH-to-HARQ-ACK timing」又はPDSCHの送信シンボル数に基づいて、応答信号の信頼度、遅延要求又はユースケース(サービス)の種類を判断する。
【０２３６】
例えば、端末２００は、PDSCH-to-HARQ-ACK timingが所定の値以下、又は、PDSCHの送信シンボル数が所定のシンボル数以下である場合、応答信号の遅延要求が厳しい又はURLLCのための応答信号であると判断する。一方、端末２００は、PDSCH-to-HARQ-ACK timingが所定の値より大きい、又は、PDSCHの送信シンボル数が所定のシンボル数より多い場合、応答信号の遅延要求が厳しくない又はeMBBのための応答信号であると判断する。
【０２３７】
なお、上記所定の値又は所定のシンボル数は、規格において予め決まった値でもよく、基地局１００が上位レイヤ信号によって端末２００へ設定可能な値でもよい。
【０２３８】
例えば、基地局１００の制御部１０１は、端末２００の下りリンクデータに対する応答信号を送信するスロット位置を示すPDSCH-to-HARQ-ACK timing又はPDSCHの送信シンボル数を決定する。決定した情報は、基地局１００の下り制御信号生成部１０９、信号割当部１１２及び抽出部１１８へ出力される。下り制御信号生成部１０９は、PDSCH-to-HARQ-ACK timing又はPDSCHの送信シンボル数に関する情報をDCIのビット列に含める。
【０２３９】
一方、端末２００の復号部２０６は、DCIを復号し、復号結果を制御部２１１へ出力する。制御部２１１は、DCIから得られるPDSCH-to-HARQ-ACK timing又はPDSCHの送信シンボル数に関する情報に基づいて、下りリンクデータの信頼度、遅延要求又はユースケース(サービス)の種類に関する情報を判断する。
【０２４０】
[例４：CQIテーブル]
例４では、端末２００は、各応答信号に対応する下りリンクデータ伝送用に設定されるCQIテーブルに基づいて、応答信号の信頼度、遅延要求又はユースケース(サービス)の種類を判断する。
【０２４１】
例えば、Release 15 NRでは、目標BLER=10-1を達成するためのCQIテーブル、及び、目標BLER=10-5を達成するためのCQIテーブルの何れを用いるかを設定できる。
【０２４２】
例えば、端末２００は、URLLCにおいて設定されたCQIテーブルが目標BLER=10-1を達成するためのCQIテーブルである場合、応答信号に要求される信頼度が高いと判断する。一方、URLLCにおいて設定されたCQIテーブルが目標BLER=10-5を達成するためのCQIテーブルである場合、応答信号に要求される信頼度は高くないと判断する。
【０２４３】
例えば、基地局１００の制御部１０１は、端末２００の下りリンクデータ伝送用に設定されるCQIテーブルに関する情報を決定する。決定した情報は、上位制御信号生成部１０６へ出力される。上位制御信号生成部１０６は、CQIテーブルに関する情報を上位制御信号に含める。
【０２４４】
一方、端末２００の復号部２０８は、上位制御信号を復号し、復号結果を制御部２１１へ出力する。制御部２１１は、上位制御信号から得られるCQIテーブルに関する情報に基づいて、下りリンクデータの信頼度、遅延要求又はユースケース(サービス)の種類に関する情報を判断する。
【０２４５】
[例５：DCIによる明示的な通知]
例５では、端末２００は、各応答信号に対応する下りリンクデータ伝送をスケジューリングするDCI内の数ビットによる明示的な通知により、応答信号の信頼度、遅延要求又はユースケース(サービス)の種類を判断する。
【０２４６】
明示的な通知は、応答信号自体の信頼度、遅延要求又はユースケース(サービス)の種類に関する情報でもよく、PDSCHの信頼度(例えば目標BLER)、遅延要求又はユースケース(サービス)の種類に関する情報でもよい。
【０２４７】
例えば、基地局１００の制御部１０１は、端末２００の下りリンクデータに対する応答信号の信頼度、遅延要求又はユースケース(サービス)の種類に関する情報を決定する。決定された情報は、下り制御信号生成部１０９へ出力される。下り制御信号生成部１０９は、応答信号の信頼度、遅延要求又はユースケース(サービス)の種類に関する情報をDCIのビット列に含める。
【０２４８】
一方、端末２００の復号部２０６は、DCIを復号し、復号結果を制御部２１１へ出力する。制御部２１１は、DCIから応答信号の信頼度、遅延要求又はユースケース(サービス)の種類に関する情報を得る。
【０２４９】
以上、応答信号の「信頼度、遅延要求又はユースケース(またはサービス)の種類」を判断する方法について説明した。なお、「応答信号の信頼度、遅延要求又はユースケース(またはサービス)の種類」を判断する方法は、上述した例１〜例５に限定されず、要求条件に関する他の情報に基づく判断方法でもよい。
【０２５０】
（３）また、上記実施の形態では、下りリンクデータ伝送に対する応答信号がPUCCHを用いて送信される場合を一例として説明した。しかし、本開示においてPUCCHを用いて送信されるUCIは応答信号に限らない。例えば、上記実施の形態において、「応答信号（ACK/NACK又はHARQ-ACK）」をチャネル状態情報（CSI)に置き換えてもよく、応答信号とCSIとを含むUCIに置き換えてもよい。
【０２５１】
（４）また、本開示はソフトウェア、ハードウェア、又は、ハードウェアと連携したソフトウェアで実現することが可能である。上記実施の形態の説明に用いた各機能ブロックは、部分的に又は全体的に、集積回路であるＬＳＩとして実現され、上記実施の形態で説明した各プロセスは、部分的に又は全体的に、一つのＬＳＩ又はＬＳＩの組み合わせによって制御されてもよい。ＬＳＩは個々のチップから構成されてもよいし、機能ブロックの一部または全てを含むように一つのチップから構成されてもよい。ＬＳＩはデータの入力と出力を備えてもよい。ＬＳＩは、集積度の違いにより、ＩＣ、システムＬＳＩ、スーパーＬＳＩ、ウルトラＬＳＩと呼称されることもある。集積回路化の手法はＬＳＩに限るものではなく、専用回路、汎用プロセッサ又は専用プロセッサで実現してもよい。また、ＬＳＩ製造後に、プログラムすることが可能なＦＰＧＡ（Field Programmable Gate Array）や、ＬＳＩ内部の回路セルの接続や設定を再構成可能なリコンフィギュラブル・プロセッサを利用してもよい。本開示は、デジタル処理又はアナログ処理として実現されてもよい。さらには、半導体技術の進歩または派生する別技術によりＬＳＩに置き換わる集積回路化の技術が登場すれば、当然、その技術を用いて機能ブロックの集積化を行ってもよい。バイオ技術の適用等が可能性としてありえる。
【０２５２】
本開示は、通信機能を持つあらゆる種類の装置、デバイス、システム（通信装置と総称）において実施可能である。通信装置の、非限定的な例としては、電話機（携帯電話、スマートフォン等）、タブレット、パーソナル・コンピューター（ＰＣ）（ラップトップ、デスクトップ、ノートブック等）、カメラ（デジタル・スチル／ビデオ・カメラ等）、デジタル・プレーヤー（デジタル・オーディオ／ビデオ・プレーヤー等）、着用可能なデバイス（ウェアラブル・カメラ、スマートウオッチ、トラッキングデバイス等）、ゲーム・コンソール、デジタル・ブック・リーダー、テレヘルス・テレメディシン（遠隔ヘルスケア・メディシン処方）デバイス、通信機能付きの乗り物又は移動輸送機関（自動車、飛行機、船等）、及び上述の各種装置の組み合わせがあげられる。
【０２５３】
通信装置は、持ち運び可能又は移動可能なものに限定されず、持ち運びできない又は固定されている、あらゆる種類の装置、デバイス、システム、例えば、スマート・ホーム・デバイス（家電機器、照明機器、スマートメーター又は計測機器、コントロール・パネル等）、自動販売機、その他ＩｏＴ（Ｉｎｔｅｒｎｅｔ  ｏｆ  Ｔｈｉｎｇｓ）ネットワーク上に存在し得るあらゆる「モノ（Things）」をも含む。
【０２５４】
通信には、セルラーシステム、無線ＬＡＮシステム、通信衛星システム等によるデータ通信に加え、これらの組み合わせによるデータ通信も含まれる。
【０２５５】
また、通信装置には、本開示に記載される通信機能を実行する通信デバイスに接続又は連結される、コントローラやセンサー等のデバイスも含まれる。例えば、通信装置の通信機能を実行する通信デバイスが使用する制御信号やデータ信号を生成するような、コントローラやセンサーが含まれる。
【０２５６】
また、通信装置には、上記の非限定的な各種装置と通信を行う、あるいはこれら各種装置を制御する、インフラストラクチャ設備、例えば、基地局、アクセスポイント、その他あらゆる装置、デバイス、システムが含まれる。
【０２５７】
本開示の一実施例における端末は、上りリンク制御情報に対する要求条件に応じて、前記上りリンク制御情報又は前記上りリンク制御情報の送信に用いる上りリンク制御チャネルに対する処理態様を決定する回路と、前記決定された処理態様に基づいて、前記上りリンク制御チャネルを用いて前記上りリンク制御情報を送信する送信機と、を具備する。
【０２５８】
本開示の一実施例における端末において、前記回路は、前記要求条件の異なる前記上りリンク制御情報に対して、異なる符号化方法を適用し、前記送信機は、前記上り制御チャネルにおいて、符号化後の前記上りリンク制御情報を多重して送信する。
【０２５９】
本開示の一実施例における端末において、前記要求条件には、信頼度又は遅延要求が含まれ、より高い前記信頼度が要求される前記上りリンク制御情報の順に、又は、前記遅延要求においてより低遅延が要求される前記上りリンク制御情報の順に、前記上り制御チャネルにマッピングされる。
【０２６０】
本開示の一実施例における端末において、前記上りリンク制御情報は、前記上り制御チャネルにおいて、周波数方向から時間方向の順にマッピングされる。
【０２６１】
本開示の一実施例における端末において、前記上りリンク制御情報は、周波数方向において分散してマッピングされる。
【０２６２】
本開示の一実施例における端末において、より高い前記信頼度が要求される前記上りリンク制御情報ほど、前記上り制御チャネルにおいて参照信号がマッピングされたシンボルにより近いシンボルにマッピングされる。
【０２６３】
本開示の一実施例における端末において、前記遅延要求においてより低遅延が要求される前記上りリンク制御情報ほど、前記上り制御チャネルのより早いシンボルにマッピングされる。
【０２６４】
本開示の一実施例における端末において、前記上り制御チャネルに多重される前記上りリンク制御情報の符号化後のビット数の合計に基づいて、前記上り制御チャネルのリソースセットが決定される。
【０２６５】
本開示の一実施例における端末において、前記上りリンク制御情報に対する前記要求条件毎に、最大符号化率が設定される。
【０２６６】
本開示の一実施例における端末において、前記上りリンク制御情報の符号化率が所定の閾値を超える場合、前記上り制御チャネルにおいて前記上りリンク制御情報の少なくとも一部がドロップされる。
【０２６７】
本開示の一実施例における端末において、前記所定の閾値は、前記最大符号化率である。
【０２６８】
本開示の一実施例における端末において、前記所定の閾値は、基地局から前記端末へ通知される。
【０２６９】
本開示の一実施例における端末において、前記ドロップされる上りリンク制御情報は、前記要求条件毎に設定される優先度に応じて決定される。
【０２７０】
本開示の一実施例における端末において、前記上りリンク制御情報のビット数と前記最大符号化率とから算出されるリソースブロック数が所定の閾値を超える場合、前記上り制御チャネルにおいて前記上りリンク制御情報の少なくとも一部がドロップされる。
【０２７１】
本開示の一実施例における端末において、前記上り制御チャネルにおいて、前記要求条件の異なる前記上りリンク制御情報間で共有するリソースの割合を示す情報が、基地局から前記端末へ通知される。
【０２７２】
本開示の一実施例における端末において、前記要求条件の異なる前記上りリンク制御情報に対して、前記上り制御チャネルにおいて異なるリソース決定方法を適用する。
【０２７３】
本開示の一実施例における端末において、１スロット内の前記上りリンク制御情報を送信する上り制御チャネルの数は１つ以上であり、前記送信機は、前記要求条件の異なる前記上りリンク制御情報を、前記１スロット内の異なる上り制御チャネルを用いてそれぞれ送信する。
【０２７４】
本開示の一実施例における端末において、前記回路は、前記要求条件の異なる前記上りリンク制御情報に対して、異なるグループに含まれるリソースセットをそれぞれ設定する。
【０２７５】
本開示の一実施例における端末において、前記回路は、前記要求条件の異なる前記上りリンク制御情報に対して、同一グループに含まれるリソースセットをそれぞれ設定する。
【０２７６】
本開示の一実施例における端末において、前記リソースセットに関するパラメータは、前記要求条件の異なる前記上りリンク制御情報毎に異なる。
【０２７７】
本開示の一実施例における端末において、前記パラメータは、前記上り制御チャネルのリソースブロック数又は系列長である。
【０２７８】
本開示の一実施例における端末において、前記パラメータは、前記上りリンク制御情報のレピティション回数である。
【０２７９】
本開示の一実施例における端末において、前記要求条件の異なる前記上りリンク制御情報毎に、前記上りリンク制御情報を送信するためのスロット位置が設定される。
【０２８０】
本開示の一実施例における端末において、前記回路は、前記要求条件の異なる前記上りリンク制御情報の送信が同一タイミングの場合、前記要求条件に基づく優先度がより低い前記上り制御チャネルの全てをドロップ又は一部をパンクチャする。
【０２８１】
本開示の一実施例における端末において、前記上りリンク制御情報は、下りリンクデータに対する応答信号であり、前記下りリンクデータの受信から前記応答信号の送信までに要する処理時間に関する前記端末の能力が、前記要求条件毎に規定され、前記下りリンクデータの受信から前記応答信号の送信までの時間を示すタイミング情報が、基地局から前記端末へ通知され、前記回路は、前記タイミング情報と前記能力とに基づいて、前記処理態様を決定する。
【０２８２】
本開示の一実施例における通信方法は、上りリンク制御情報に対する要求条件に応じて、前記上りリンク制御情報又は前記上りリンク制御情報の送信に用いる上りリンク制御チャネルに対する処理態様を決定し、前記決定された処理態様に基づいて、前記上りリンク制御チャネルを用いて前記上りリンク制御情報を送信する。
【０２８３】
２０１８年８月１日出願の特願２０１８−１４４９８２の日本出願に含まれる明細書、図面および要約書の開示内容は、すべて本願に援用される。
【産業上の利用可能性】
【０２８４】
本開示の一実施例は、移動通信システムに有用である。
【符号の説明】
【０２８５】
１００  基地局
１０１，２１１  制御部
１０２  データ生成部
１０３，１０７，１１０，２１２  符号化部
１０４  再送制御部
１０５，１０８，１１１，２１３  変調部
１０６  上位制御信号生成部
１０９  下り制御信号生成部
１１２，２１４  信号割当部
１１３，２１５  IFFT部
１１４，２１６  送信部
１１５，２０１  アンテナ
１１６，２０２  受信部
１１７，２０３  FFT部
１１８，２０４  抽出部
１１９  復調部
１２０，２０６，２０８，２１０  復号部
１２１  判定部
２００  端末
２０５  下り制御信号復調部
２０７  上位制御信号復調部
２０９  データ復調部
【図１】
2020026518.tif 000003
【図２】
2020026518.tif 000004
【図３】
2020026518.tif 000005
【図４】
2020026518.tif 000006
【図５】
2020026518.tif 000007
【図６】
2020026518.tif 000008
【図７】
2020026518.tif 000009
【図８】
2020026518.tif 000010
【図９】
2020026518.tif 000011
【図１０Ａ】
2020026518.tif 000012
【図１０Ｂ】
2020026518.tif 000013
【図１１Ａ】
2020026518.tif 000014
【図１１Ｂ】
2020026518.tif 000015
【図１２】
2020026518.tif 000016
【図１３】
2020026518.tif 000017
【図１４】
2020026518.tif 000018
【国際調査報告】
2020026518.tif 000019
2020026518.tif 000020
2020026518.tif 000021
2020026518.tif 000022