(57)【要約】  上りリンク信号を適切に送信することができる端末。端末（１００）において、PCパラメータ制御部（１０４）は、上りリンク信号の割り当ての送信に使用される制御チャネルに関する所定の条件を満たす場合、第１のサービスに対応する第１の電力制御パラメータを設定し、所定の条件を満たさない場合、第２のサービスに対応する第２の電力制御パラメータを設定する。送信部（１０９）は、第１の電力制御パラメータ又は第２の電力制御パラメータを用いて計算された送信電力を用いて上りリンク信号を送信する。
2019216073.tif 000002
【特許請求の範囲】
【請求項１】
上りリンク信号の割当情報の送信に使用される制御チャネルに関する所定の条件を満たす場合、第１のサービスに対応する第１の電力制御パラメータを設定し、前記所定の条件を満たさない場合、第２のサービスに対応する第２の電力制御パラメータを設定する回路と、
前記第１の電力制御パラメータ又は前記第２の電力制御パラメータを用いて計算された送信電力を用いて前記上りリンク信号を送信する送信回路と、
を具備する端末。
【請求項２】
前記所定の条件は、前記制御チャネルに用いられるフォーマットのペイロードサイズが所定のサイズと異なることである、
請求項１に記載の端末。
【請求項３】
前記所定の条件は、前記制御チャネルに用いられるフォーマットのペイロードサイズが所定のサイズ未満であることである、
請求項１に記載の端末。
【請求項４】
前記所定の条件は、前記制御チャネルに用いられるスクランブリング系列が所定の系列と異なることである、
請求項１に記載の端末。
【請求項５】
前記所定の条件は、前記制御チャネルが、前記第１のサービスのスケジューリングを要求する信号を前記端末から送信した後の所定期間内に前記端末において受信する制御チャネルであることである、
請求項１に記載の端末。
【請求項６】
前記所定の条件は、前記制御チャネルが、前記第１のサービスのスケジューリングを要求する信号を前記端末から送信した後に前記端末が最初に受信する制御チャネルであることである、
請求項１に記載の端末。
【請求項７】
前記所定の条件は、前記制御チャネルが、前記上りリンク信号の初回送信に使用されるリソースが予め設定された送信方法における再送を示すことである、
請求項１に記載の端末。
【請求項８】
前記所定の条件は、前記端末が前記制御チャネルを受信してから前記上りリンク信号を送信するまでの期間が所定時間以内であることである、
請求項１に記載の端末。
【請求項９】
前記所定の条件は、前記制御チャネルに示される前記上りリンク信号の送信シンボル数が所定値以下であることである、
請求項１に記載の端末。
【請求項１０】
前記所定の条件は、前記端末における前記制御チャネルの検出周期が所定値以下であることである、
請求項１に記載の端末。
【請求項１１】
前記所定の条件は、前記制御チャネルに用いられる、符号化及び変調方式を示すテーブルが所定のテーブルと異なることである、
請求項１に記載の端末。
【請求項１２】
前記所定の条件は、前記上りリンク信号に含まれる上りリンク制御情報が、前記第１のサービスの下りリンクデータに対する応答信号であることである、
請求項１に記載の端末。
【請求項１３】
前記所定の条件は、前記端末が下りリンクデータを受信してから、当該下りリンクデータに対する応答信号を含む前記上りリンク信号を送信するまでの期間が所定時間以内であることである、
請求項１に記載の端末。
【請求項１４】
前記所定の条件は、前記上りリンク信号に含まれる上りリンク制御情報が、所定の閾値以下の目標誤り率を用いて計算されたチャネル状態情報であることである、
請求項１に記載の端末。
【請求項１５】
下りリンクデータ及び当該下りリンクデータに対する応答信号の全体の誤り率が一定の値であり、
前記所定の条件は、前記上りリンク信号に含まれる上りリンク制御情報が、前記第２のサービスの下りリンクデータに対する応答信号であることである、
請求項１に記載の端末。
【請求項１６】
前記所定の条件は、前記上りリンク信号に含まれる上りリンク制御情報のリソース数が所定の閾値以上であることである、
請求項１２に記載の端末。
【請求項１７】
前記所定の条件は、前記上りリンク信号全体のリソース数に対する、前記上りリンク信号に含まれる上りリンク制御情報のリソース数の割合が所定の閾値より大きいことである、
請求項１２に記載の端末。
【請求項１８】
前記第１の電力制御パラメータを用いて計算される前記送信電力は、前記第２の電力制御パラメータを用いて計算される前記送信電力より大きい、
請求項１に記載の端末。
【請求項１９】
上りリンク信号の割当情報の送信に使用される制御チャネルに関する所定の条件を満たす場合、第１のサービスに対応する第１の電力制御パラメータを設定し、前記所定の条件を満たさない場合、第２のサービスに対応する第２の電力制御パラメータを設定し、
前記第１の電力制御パラメータ又は前記第２の電力制御パラメータを用いて計算された送信電力を用いて前記上りリンク信号を送信する、
送信方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本開示は、端末及び送信方法に関する。
【背景技術】
【０００２】
5Gの標準化において、LTE/LTE-Advancedとは必ずしも後方互換性を持たない新しい無線アクセス技術（NR：New Radio access technology）が3GPPで議論されている。【０００３】
NRでは、5Gの要件の1つであるURLLC（Ultra-Reliable and Low Latency Communications：超高信頼低遅延通信）をターゲットとした技術検討が進められている。URLLCは、32バイトのパケットデータ量を10-5以下のパケット送信誤り率（99.999%以上のパケット送信成功率）の「高信頼」と、無線区間1ms以下の「低遅延」とを同時に満たすことが求められる（例えば、非特許文献１を参照）。【０００４】
上述したURLLCの要求条件を満たすために、URLLCデータの上りチャネル（PUSCH：Physical Uplink Shared Channel）の送信では、他のデータの上りチャネルと比較して高い送信電力（例えば、パワーブースト）を用いてURLLCデータを送信することが検討されている（例えば、非特許文献２を参照）。
【先行技術文献】
【非特許文献】
【０００５】
【非特許文献１】3GPP TR 38.913 V14.3.0, "Study on Scenarios and Requirements for Next Generation Access TEchnologies (Release 14)" (2017-06)
【非特許文献２】R1-1803359, "Summary on handling UL multiplexing of transmission with different reliability requirements", vivo, February 2018
【非特許文献３】3GPP TS 38.213 V15.1.0, “NR; Physical layer procedures for control (Release 15)” (2018-03)
【非特許文献４】3GPP TS 38.212 V15.1.1, “NR; Multiplexing and channel coding (Release 15)” (2018-04)
【非特許文献５】R1-1805630, "Summary of 7.2.2 Study of necessity of a new DCI format", Huawei, April 2018
【非特許文献６】3GPP TS38.214 V15.2.0, " NR; Physical layer procedures for data (Release 15)" (2018-06)
【発明の概要】
【０００６】
しかしながら、URLLCのPUSCHを送信する方法については十分に検討されていない。
【０００７】
本開示の非限定的な実施例は、上りリンク信号を適切に送信することができる端末及び送信方法の提供に資する。
【０００８】
本開示の一実施例に係る端末は、上りリンク信号の割当情報の送信に使用される制御チャネルに関する所定の条件を満たす場合、第１のサービスに対応する第１の電力制御パラメータを設定し、前記所定の条件を満たさない場合、第２のサービスに対応する第２の電力制御パラメータを設定する回路と、前記第１の電力制御パラメータ又は前記第２の電力制御パラメータを用いて計算された送信電力を用いて前記上りリンク信号を送信する送信回路と、を具備する。
【０００９】
本開示の一実施例に係る送信方法は、上りリンク信号の割当情報の送信に使用される制御チャネルに関する所定の条件を満たす場合、第１のサービスに対応する第１の電力制御パラメータを設定し、前記所定の条件を満たさない場合、第２のサービスに対応する第２の電力制御パラメータを設定し、前記第１の電力制御パラメータ又は前記第２の電力制御パラメータを用いて計算された送信電力を用いて前記上りリンク信号を送信する。
【００１０】
なお、これらの包括的または具体的な態様は、システム、装置、方法、集積回路、コンピュータプログラム、または、記録媒体で実現されてもよく、システム、装置、方法、集積回路、コンピュータプログラムおよび記録媒体の任意な組み合わせで実現されてもよい。
【００１１】
本開示の一実施例によれば、上りリンク信号を適切に送信することができる。
【００１２】
本開示の一実施例における更なる利点および効果は、明細書および図面から明らかにされる。かかる利点および／または効果は、いくつかの実施形態並びに明細書および図面に記載された特徴によってそれぞれ提供されるが、１つまたはそれ以上の同一の特徴を得るために必ずしも全てが提供される必要はない。
【図面の簡単な説明】
【００１３】
【図１】PC parameter setの一例を示す図
【図２】実施の形態１に係る端末の一部の構成例を示すブロック図
【図３】実施の形態１に係る端末の構成例を示すブロック図
【図４】実施の形態１に係る基地局の構成例を示すブロック図
【図５】実施の形態１に係る端末及び基地局の動作例を示すシーケンス図
【図６】実施の形態１に係るPC parameter set番号A, Bの設定例を示す図
【図７Ａ】URLLC用MCSテーブルの一例を示す図
【図７Ｂ】eMBB用MCSテーブルの一例を示す図
【図７Ｃ】eMBB用MCSテーブルの一例を示す図
【図８】実施の形態１に係るPC parameter set番号A, Bの設定例を示す図
【図９】実施の形態１に係るURLLCとeMBBとの間において無線リソースが重なる例を示す図
【図１０】実施の形態２に係る端末の構成例を示すブロック図
【図１１】実施の形態２に係るPC parameter set番号の設定例を示す図
【図１２】実施の形態２に係るPC parameter set番号の設定例を示す図
【図１３】実施の形態２に係るPC parameter set番号の設定例を示す図
【図１４】実施の形態３に係る端末の構成例を示すブロック図
【発明を実施するための形態】
【００１４】
以下、本開示の実施の形態について図面を参照して詳細に説明する。
【００１５】
NR向けの端末（「UE（User Equipment）」と呼ぶこともある）のPUSCHの送信電力制御（TPC：Transmission Power Control）は、例えば、以下の式（１）に従って行われる（例えば、非特許文献３を参照）。
【数１】
2019216073.tif 000003
【００１６】
式（１）において、PPUSCH,f,c(i, j, qd, l)は、Carrier番号"f"、サービングセル番号"c"、Slot番号"i"、PC（power control）parameter set番号"j"、PL（pathloss）推定用RS(reference signal)番号"qd"、Closed loop process番号"l"におけるPUSCHの送信電力[dBm]を示す。PCMAX,f,c(i)は、Slot番号iにおける端末の最大送信電力[dBm]を示す。PO_PUSCH,f,c(j)は、PC parameter set番号jの目標受信電力[dBm]（Parameter値）を示す。2μ・MRB,f,cPUSCH(i)は、Slot番号iにおいてPUSCHに適用するSCS（subcarrier spacing）を、15kHz SCSを基準に正規化したPUSCHの送信帯域幅[PRB]を示す。αf,c(j)はPC parameter set番号jのパスロスの補償割合を示す重み係数（Parameter値）を示す。PLf,c(qd)は端末がRS番号qdのRSから測定したパスロス（Path Loss）[dB]を示す。ΔTF,f,c(i)はSlot番号iにおいて送信するデータのMCS（Modulation and Coding Scheme）に依存したオフセット[dB]を示す。ff,c(i,l)はSlot番号i、Closed loop process番号lにおけるClosed loop補正値[dB]を示す。
【００１７】
式（１）において、PO_PUSCH,f,c(j)及びαf,c(j)は、「PC parameter set」と呼ばれる。例えば、図１に示すように、PC parameter set番号j毎のPC parameter setの値が、基地局（「eNB」又は「gNB」と呼ぶこともある）から端末へ、例えば、RRC（Radio Resource Control）通知によって予め設定される。
【００１８】
URLLCデータの上り送信では、URLLCの信頼性に関する要求条件を満たすために、他のサービス種別（例えば、eMBB）と比較してより高い送信電力となるPC parameter set（PO_PUSCH,f,c(j)、αf,c(j)）を用いることが検討されている。例えば、URLLCデータにはパワーブーストが適用されることにより、URLLCデータをeMBBデータと比較してより高い送信電力で送信することが検討されている。
【００１９】
PUSCHのスケジューリング情報（例えば、周波数リソース割当情報、時間リソース割当情報、又は、MCS等)は、DCI（Downlink Control Information)と呼ばれ、PDCCH（Physical Downlink Control Channel）を用いて基地局から端末へ送信される。なお、PUSCHのスケジューリング情報を指示するために使用されるPDCCHは「上りグラント(UL grant)」と呼ばれる。
【００２０】
NRでは、UL grant用のDCIフォーマットとして「DCI format 0_0」及び「DCI format 0_1」の２種類のフォーマットが規定されている（例えば、非特許文献４を参照）。DCI format 0_0は、「フォールバック用DCI」とも呼ばれる。DCI format 0_0では、DCI format 0_1に含まれる情報の一部が含まれないため、DCI format 0_1と比較してPayloadサイズが小さい。
【００２１】
また、URLLCデータ（URLLC用PUSCHと呼ぶこともある）のスケジューリング情報を指示するPDCCH（例えば、UL grant）も、URLLCデータと同等又はURLLCデータ以上に高信頼性及び低遅延が要求される。ここで、Payloadサイズが小さいほど、符号化利得がより大きくなり、信頼性を向上できる。そこで、フォールバック用DCI（例えば、DCI format 0_0）をURLLCデータのスケジューリング情報を指示するPDCCHのDCIフォーマットに用いることが検討されている（例えば、非特許文献５を参照）。
【００２２】
例えば、DCI format 0_1には、SRI（SRS resource indicator）fieldが含まれる。UL grantのDCIフォーマットにDCI format 0_1を用いる場合、SRI fieldによりPC parameter set番号jを端末へ指示できる。このため、基地局は、DCI format 0_1を用いて、URLLC用PUSCHのパワーブースト送信を端末に指示できる。換言すると、基地局は、DCI format 0_1に含まれるSRI fieldを用いて、URLLC用PUSCHの送信電力に適したPC parameter set(PO_PUSCH,f,c(j)、αf,c(j))に対応するPC parameter set番号jを端末へ明示的に指示できる。
【００２３】
一方、フォールバック用DCI（例えば、DCI format 0_0）には、SRI fieldが含まれない。SRI fieldが含まれない場合、つまり、PC parameter set番号を明示的に指示する情報が含まれないUL grantが使用される場合、例えば、固定のPC parameter set値（例えば、j=0のPC parameter set値）が用いられる。
【００２４】
この場合、端末では、URLLC及びeMBB等のサービス種別（トラフィック種別とも呼ばれる）に依らず、固定のPC parameter set値が適用されるため、サービス種別に適した上りチャネルの送信電力が設定できない。例えば、eMBB用のパラメータ値を固定のPC parameter set値に設定した場合、URLLCデータをスケジューリングする場合には送信電力不足となり、URLLCの要求品質を満たせない。一方、URLLC用のパラメータ値を固定のPC parameter set値に設定した場合、eMBBデータをスケジューリングする場合には過剰な送信電力となり、与干渉が増加し、システム性能が劣化する懸念がある。
【００２５】
このように、例えば、PC parameter set番号を明示的に指示する情報を含まないUL grantにおいて、URLLC用PUSCHのパワーブーストを端末へ指示する方法については十分に議論されていない。
【００２６】
そこで、本開示の一実施例では、URLLC及びeMBB等のサービス種別に適した上りチャネルの送信電力を適切に設定する方法について説明する。
【００２７】
（実施の形態１）
［通信システムの概要］
本開示の一実施の形態に係る通信システムは、端末１００及び基地局２００を備える。端末１００は、基地局２００からのUL grantに含まれるDCIに基づいて所定の送信電力を用いてPUSCHを送信する。基地局２００は、UL grantを端末１００へ送信し、端末１００からのPUSCHを受信する。
【００２８】
図２は本開示の実施の形態に係る端末１００の一部の構成を示すブロック図である。図２に示す端末１００において、PCパラメータ制御部１０４は、上りリンク信号の割り当ての送信に使用される制御チャネル（例えば、UL grant）に関する所定の条件を満たす場合、第１のサービス（例えば、URLLC）に対応する第１の電力制御パラメータを設定し、所定の条件を満たさない場合、第２のサービス（例えば、eMBB）に対応する第２の電力制御パラメータを設定する。送信部１０９は、第１の電力制御パラメータ又は第２の電力制御パラメータを用いて計算された送信電力を用いて上りリンク信号を送信する。
【００２９】
［端末１００の構成］
図３は、本実施の形態に係る端末１００の構成例を示すブロック図である。
【００３０】
図３に示す端末１００は、アンテナ１０１、受信部１０２、復調・復号部１０３、PCパラメータ制御部１０４、送信電力計算部１０５、データ生成部１０６、符号化・変調部１０７、リソース割当部１０８、及び、送信部１０９を含む。
【００３１】
受信部１０２は、基地局２００から送信された信号をアンテナ１０１を介して受信し、受信信号に対してダウンコンバート又はA/D(Analog-to-Digital)変換などの受信処理を行い、受信処理後の受信信号を復調・復号部１０３へ出力する。
【００３２】
復調・復号部１０３は、受信部１０２から入力される受信信号に対して復調及び復号を行い、復号結果から、端末１００宛てのUL grant（PDCCH又はNR-PDCCH）を抽出（受信）し、抽出したUL grantに含まれる、PUSCHをスケジューリングするためのDCIを復号する。復調・復号部１０３は、復号後のDCIを、PCパラメータ制御部１０４、送信電力計算部１０５、符号化・変調部１０７及びリソース割当部１０８へ出力する。
【００３３】
DCIには、例えば、周波数リソース情報、時間リソース情報、MCS、送信電力情報、Payloadサイズ、DCIのスクランブリング系列、再送制御情報、又は、TPCコマンド情報等が含まれる。ここで、基地局２００から端末１００へ送信されるUL grantには、Payloadサイズが小さいDCI formatが用いられる。Payloadサイズが小さいDCI formatは、例えば、DCI format 0_0のPayloadサイズと同等又はDCI format 0_0のPayloadサイズ未満のサイズのDCI formatでもよい。換言すると、基地局２００から端末１００へ送信されるUL grantには、PC parameter set番号jを明示的に指示する情報は含まれていない。
【００３４】
なお、全ての制御情報を含むDCIが端末１００に対して同時に通知される必要はない。例えば、一部のDCIはセル共通情報として、又は、準静的な通知情報として端末１００に通知されてもよい。また、一部のDCIは、例えば、システム共通情報としてスペックで規定され、基地局２００から端末１００に通知されなくてもよい。
【００３５】
PCパラメータ制御部１０４は、復調・復号部１０３から入力されるDCIを用いて、スケジューリングされたPUSCHに適用するPC parameter set番号jを決定する。PCパラメータ制御部１０４は、決定したPC parameter set番号を送信電力計算部１０５へ出力する。
【００３６】
例えば、PCパラメータ制御部１０４は、PUSCHのスケジューリング情報（割当情報）の送信に使用されるUL grantに関して所定の条件を満たす場合、当該UL grantによってスケジューリングされたPUSCHがURLLC用PUSCHであると判断する。UL grantによってスケジューリングされたPUSCHがURLLC用PUSCHであると判断した場合、PCパラメータ制御部１０４は、URLLCに対応するPC parameter set番号j=Aを設定する。一方、UL grantに関して所定の条件を満たさない場合、当該UL grantによってスケジューリングされたPUSCHがURLLC以外のサービス種別のPUSCHであると判断する。UL grantによってスケジューリングされたPUSCHがURLLC以外のサービス種別のPUSCHであると判断した場合、PCパラメータ制御部１０４は、URLLC以外のサービス種別（例えば、eMBB）に対応するPC parameter set番号j=Bを設定する。
【００３７】
なお、PC parameter setのテーブル（例えば、図１を参照）は、基地局２００から端末１００へ事前に設定されている。また、j=AのPC parameter setには、URLLCを想定した送信電力値となるパラメータ値が設定され、j=BのPC parameter setには、URLLC以外のサービス種別（例えば、eMBB）を想定した送信電力となるパラメータ値が設定される。換言すると、j=AのPC parameter setを用いて計算される送信電力値は、j=BのPC parameter setを用いて計算される送信電力値より大きい。
【００３８】
なお、PCパラメータ制御部１０４におけるPC parameter set番号の選択方法の詳細については後述する。
【００３９】
送信電力計算部１０５は、復調・復号部１０３から入力されるDCIに含まれるClosed loop補正値の更新値（+1ｄB、−1dB等の制御値）、及び、PCパラメータ制御部１０４から入力されるPC parameter set番号jを用いて、例えば、式（１）に従って、slot番号iにおけるPUSCHの送信電力値を計算する。送信電力計算部１０５は、計算したPUSCHの送信電力値を送信部１０９へ出力する。
【００４０】
なお、送信電力計算部１０５において、式（１）に示すslot番号i及びPC parameter set番号j以外のパラメータであるPL推定用RS番号qd及びClosed loop process番号lに関して、PCパラメータ制御部１０４から明示的に指示がない場合、送信電力計算部１０５は、所定の固定値（例えば、qd=0、l=0）を適用してもよい。一方、PL推定用RS番号qd、及び、Closed loop process番号lに関して、PCパラメータ制御部１０４から明示的に指示がある場合、送信電力計算部１０５は、PCパラメータ制御部１０４から指示された値を設定する。
【００４１】
データ生成部１０６は、端末１００が送信するデータを生成し、生成した送信データを符号化・変調部１０７へ出力する。
【００４２】
符号化・変調部１０７は、復調・復号部１０３から入力されるDCIに基づいて、データ生成部１０６から入力される送信データに対して、符号化及び変調を行い、変調後のデータ信号をリソース割当部１０８へ出力する。
【００４３】
リソース割当部１０８は、復調・復号部１０３から入力されるDCIに基づいて、符号化・変調部１０７から入力される変調後のデータ信号を、所定の無線リソース（例えば、周波数リソース及び時間リソース）に割り当てる。リソース割当部１０８は、リソース割当後の信号を送信部１０９に出力する。
【００４４】
送信部１０９は、リソース割当部１０８から入力される信号に対してD/A(Digital-to-Analog)変換及びアップコンバート等の送信処理を行う。送信部１０９は、送信電力計算部１０５から入力される送信電力値を用いて、送信処理後の信号をアンテナ１０１を介して基地局２００へ送信する。
【００４５】
［基地局２００の構成］
図４は、本実施の形態に係る基地局２００の構成例を示すブロック図である。
【００４６】
図４に示す基地局２００は、スケジューリング部２０１、制御情報生成部２０２、符号化・変調部２０３、送信部２０４、アンテナ２０５、受信部２０６、及び、復調・復号部２０７を含む。
【００４７】
スケジューリング部２０１は、端末１００のPUSCHに対する無線リソース割当情報（例えば、周波数リソース割当情報、時間リソース割当情報、MCS、送信電力情報など）を決定する。例えば、スケジューリング部２０１は、端末１００から所定のタイミングで通知される品質情報に基づいて無線リソース割当情報を決定してもよい。スケジューリング部２０１は、決定した無線リソース割当情報、及び、対応するサービス種別（例えば、URLLC又はeMBB）を、制御情報生成部２０２へ出力する。
【００４８】
制御情報生成部２０２は、スケジューリング部２０１から入力される無線リソース割当情報及びサービス種別に基づいて、端末１００に通知するDCIを含むUL grantを生成する。制御情報生成部２０２は、生成したUL grantを符号化・変調部２０３へ出力する。ここで、UL grantは、例えば、Payloadサイズが小さいフォールバック用DCI（例えば、DCI format 0_0）であり、UL grantには、PC parameter set番号を明示的に指示する情報が含まれない。
【００４９】
符号化・変調部２０３は、制御情報生成部２０２から入力されるUL grantを符号化及び変調して、変調後のUL grantを送信部２０４へ出力する。
【００５０】
送信部２０４は、符号化・変調部２０３から入力される信号に対してD/A変換、アップコンバート、増幅等の送信処理を行い、送信後の信号をアンテナ２０５を介して端末１００へ送信する。
【００５１】
受信部２０６は、アンテナ２０５を介して受信された、端末１００から送信されたPUSCHに対してダウンコンバート又はA/D変換などの受信処理を行い、受信処理後の受信信号を復調・復号部２０７へ出力する。
【００５２】
復調・復号部２０７は、受信部２０６から入力される受信信号に対して、復調及び復号を行い、端末１００からの受信データを取得する。
【００５３】
［基地局及び端末の動作］
以上の構成を有する端末１００及び基地局２００の動作について詳細に説明する。
【００５４】
図５は端末１００（図３）及び基地局２００（図４）の動作例を示すシーケンス図である。
【００５５】
基地局２００は、端末１００に対する上りリンク信号（例えば、PUSCH）に関する無線リソース割当情報を決定し、DCIを生成する（ＳＴ１０１）。基地局２００は、生成したDCIを含むUL grantを端末１００へ送信する（ＳＴ１０２）。
【００５６】
端末１００は、基地局２００からのUL grantに含まれるDCIに示される無線リソース割当情報に基づいて、PUSCHの送信電力を計算する（ＳＴ１０３）。この際、端末１００は、UL grantに関する所定の条件を満たすか否かに応じて、URLLC用のPUSCHの送信電力を計算するためのPC parameter set番号jを決定する。
【００５７】
端末１００は、計算した送信電力を用いて、PUSCHを基地局２００へ送信する（ＳＴ１０４）。
【００５８】
［PC parameter setの選択方法］
次に、端末１００のPCパラメータ制御部１０４におけるPC parameter setの選択方法について説明する。
【００５９】
端末１００のPCパラメータ制御部１０４は、UL grantに関する所定の条件（詳細は後述する）を満たす場合、基地局２００からのUL grant（例えば、図５のＳＴ１０２を参照）が、URLLCデータをスケジューリングするUL grantであると判断し、URLLCに対応するPC parameter set番号j=AのPC parameter set値を設定する。
【００６０】
一方、端末１００のPCパラメータ制御部１０４は、UL grantに関する所定の条件を満たさない場合、基地局２００からのUL grantが、URLLC以外の他のサービス種別のデータをスケジューリングするUL grantであると判断し、URLLC以外の他のサービス種別に対応するPC parameter set番号j=BのPC parameter set値を設定する。
【００６１】
端末１００の送信電力計算部１０５は、設定したPC parameter set番号jを用いて、例えば、式（１）に従ってPUSCHの送信電力を計算する。
【００６２】
以下、URLLCデータをスケジューリングするUL grantであるか否かを判断するための「所定の条件」の例について説明する。
【００６３】
［例１：UL grantのPayloadサイズ］
例１では、所定の条件は、UL grantに用いられるDCI formatのPayloadサイズが所定のサイズと異なることである。または、例１では、所定の条件は、UL grantに用いられるDCI formatのPayloadサイズが所定のサイズ未満であることである。
【００６４】
上述したように、URLLCデータをスケジューリングするUL grantのPayloadサイズが小さいほど、符号化利得がより大きくなり、信頼性を向上できる。よって、URLLCデータのスケジューリングに用いるUL grantには、Payloadサイズの小さいフォーマットが設定されることが考えられる。
【００６５】
例えば、例１では、PCパラメータ制御部１０４は、基地局２００からのUL grantに用いられるDCI formatのPayloadサイズが所定のサイズと異なる場合、又は、所定のサイズ未満の場合、当該UL grantが、URLLCデータをスケジューリングするUL grantであると判断する。換言すると、PCパラメータ制御部１０４は、DCI formatのPayloadサイズが所定のサイズと異なる場合、又は、所定のサイズ未満の場合、当該UL grantによってスケジューリングされたPUSCHがURLLC用のPUSCH（URLLC PUSCH）であると判断する。
【００６６】
例えば、端末１００が検出したUL grantのPayloadサイズが、eMBBを想定したPUSCH用UL grantに規定されているDCI format 0_0及びDCI format 0_1の双方のPayloadサイズと異なる場合、PCパラメータ制御部１０４は、当該UL grantがURLLC用PUSCHをスケジューリングするUL grantであると判断してもよい。
【００６７】
または、端末１００が検出したUL grantのPayloadサイズが、フォールバック用DCIであるDCI format 0_0のPayloadサイズ未満の場合、PCパラメータ制御部１０４は、当該UL grantがURLLC用PUSCHをスケジューリングするUL grantであると判断してもよい。
【００６８】
PCパラメータ制御部１０４は、UL grantがURLLC用PUSCHをスケジューリングするUL grantであると判断した場合、URLLCに対応するPC parameter set番号j=AのPC parameter setを選択する。
【００６９】
一方、端末１００が検出したUL grantのPayloadサイズが、DCI format 0_0又はDCI format 0_1のPayloadサイズと同じ場合、PCパラメータ制御部１０４は、当該UL grantがURLLC以外のサービス種別（例えば、eMBB用PUSCH）のデータをスケジューリングするUL grantであると判断する。PCパラメータ制御部１０４は、UL grantがURLLC以外のサービス種別のデータをスケジューリングするUL grantであると判断した場合、URLLC以外のサービス種別に対応するPC parameter set番号j=BのPC parameter setを選択する。
【００７０】
このように、例１では、UL grantに用いられるDCI formatのPayloadサイズに応じて、PC parameter set番号が基地局２００から端末１００へ暗黙的に通知される。
【００７１】
［例２：UL grantで用いるスクランブリング系列］
例２では、所定の条件は、UL grantに用いられるスクランブリング系列が所定の系列と異なることである。
【００７２】
例えば、PCパラメータ制御部１０４は、UL grantのDCI formatで用いる端末固有のスクランブリング系列が所定の端末固有の系列と異なる場合、当該UL grantが、URLLCデータをスケジューリングするUL grantであると判断する。換言すると、PCパラメータ制御部１０４は、UL grantのDCI formatで用いる端末固有のスクランブリング系列が所定の端末固有の系列と異なる場合、当該UL grantによってスケジューリングされたPUSCHがURLLC用のPUSCH（URLLC PUSCH）であると判断する。
【００７３】
例えば、eMBBを想定したPUSCH用UL grantに規定されているDCI format 0_0又はDCI format 0_1では、端末固有のスクランブリング系列に、C-RNTI（Cell - Radio Network Temporary Identifier）又はCS-RNTI（Configured Scheduling - RNTI）等が用いられる。
【００７４】
例えば、端末１００が検出したUL grantで用いるスクランブリング系列がC-RNTI及びCS-RNTIと異なる場合、PCパラメータ制御部１０４は、当該UL grantがURLLC用PUSCHをスケジューリングするUL grantであると判断し、URLLCに対応するPC parameter set番号j=AのPC parameter setを選択する。
【００７５】
一方、端末１００が検出したUL grantで用いるスクランブリング系列がC-RNTI又はCS-RNTIである場合、PCパラメータ制御部１０４は、当該UL grantがURLLC以外のサービス種別のデータをスケジューリングするUL grantであると判断し、URLLC以外のサービス種別に対応するPC parameter set番号j=BのPC parameter setを選択する。
【００７６】
このように、例２では、UL grantに用いられるDCI formatのスクランブリング系列に応じて、PC parameter set番号が基地局２００から端末１００へ暗黙的に通知される。
【００７７】
［例３：URLLC用SR（Scheduling Request）送信後のUL grant］
例３では、所定の条件は、UL grantが、URLLCのスケジューリングを要求するSR（URLLC用SR）を端末１００から送信した後に受信するUL grantであることである。
【００７８】
ここで、「URLLC用SRを送信した後に受信するUL grant」とは、例えば、URLLC用SR送信してから所定期間X1[symbol]以内に受信したUL grantでもよく、URLLC用SR送信してから最初に受信したUL grantでもよい。
【００７９】
また、URLLC用SRは、例えば、基地局２００からのSRリソース設定の際にURLLC用であることを明示的に示されてもよい。また、eMBBデータの送信中に発生するSR送信であって、緊急度又は優先度の高いSR送信をURLLC用SR送信と定義してもよい。または、スペックにおいてURLLC用SR送信のための無線リソースが定義されてもよい。または、基地局２００から設定されたSRリソースの周期が所定値X2[symbol]以下の場合、低遅延が要求されるURLLC用SRとして定義されてもよい。
【００８０】
例えば、URLLC用SRを送信した後のUL grantを受信した場合、PCパラメータ制御部１０４は、当該UL grantがURLLC用PUSCHをスケジューリングするUL grantであると判断し、URLLCに対応するPC parameter set番号j=AのPC parameter setを選択する。
【００８１】
一方、URLLC用SRを送信した後の上記所定の条件を満たさないUL grantを受信した場合、PCパラメータ制御部１０４は、当該UL grantがURLLC以外のサービス種別のデータをスケジューリングするUL grantであると判断し、URLLC以外のサービス種別に対応するPC parameter set番号j=BのPC parameter setを選択する。
【００８２】
このように、例３では、URLLC用SR送信後に所定の条件を満たすUL grantを受信するか否かに応じて、PC parameter set番号が基地局２００から端末１００へ暗黙的に通知される。
【００８３】
なお、上述した閾値X1、X2の値は、スペックにおいて予め規定されてもよく、基地局２００から端末１００へ設定されてもよい。
【００８４】
［例４：Grant-free上り送信の再送を指示するUL grant］
例４では、所定の条件は、UL grantが、Grant-free上り送信（以下、単に「Grant-free送信」と呼ぶ）における再送を示すことである。
【００８５】
「Grant-free送信」とは、上りリンク信号の初回送信に使用される無線リソース（スケジューリング情報）が基地局２００から端末１００に予め設定されている送信方法である。Grant-free送信において、端末１００は、送信すべき送信データが発生した場合に、予め確保されている無線リソースを用いて送信データを送信する。
【００８６】
Grant-free送信によれば、端末１００において送信データが発生してから、基地局２００へSRを送信し、基地局２００からのUL grantによってPUSCHをスケジューリングされるまでの時間を削減できる。このため、Grant-free送信は、低遅延が要求されるURLLC用の初期送信に用いることが想定される。
【００８７】
なお、Grant-free送信の再送はUL grantによって指示される。
【００８８】
例えば、Grant-free送信の再送を指示するためのUL grantを受信した場合、PCパラメータ制御部１０４は、当該UL grantがURLLC用PUSCHをスケジューリングするUL grantであると判断し、URLLCに対応するPC parameter set番号j=AのPC parameter setを選択する。なお、PCパラメータ制御部１０４は、例えば、UL grant内のNDI（New data indicator）fieldの値に基づいて、Grant-free送信における再送であるか否かを判断してもよい。
【００８９】
一方、Grant-free送信が適用されていない場合、又は、Grant-free送信の再送を指示するためのUL grantを受信していない場合、PCパラメータ制御部１０４は、当該UL grantがURLLC以外のサービス種別のデータをスケジューリングするUL grantであると判断し、URLLC以外のサービス種別に対応するPC parameter set番号j=BのPC parameter setを選択する。
【００９０】
このように、例４では、UL grantによってGrant-free送信における再送が指示されるか否かに応じて、PC parameter set番号が基地局２００から端末１００へ暗黙的に通知される。
【００９１】
なお、URLLC用Grant-free送信リソースと、URLLC以外のサービス種別（例えばeMBB）用Grant-free送信リソースとは、基地局２００による設定、又は、スペックでの規定によって区別されてもよい。
【００９２】
例えば、Grant-free送信リソースを用いた上り送信時には、端末１００は、基地局２００から予め設定されたGrant-free送信用のPC parameter set値（UL grantベースの上り送信時に用いるPC parameter set（例えば、図１を参照）とは独立の固定値）を用いてもよい。また、URLLC用Grant-free送信リソースを定義する場合、URLLC用Grant-free送信リソースを用いた上り送信時と、URLLC以外のサービス種別用Grant-free送信リソースを用いた上り送信時とで、PC parameter set値を区別してもよい。
【００９３】
これにより、Grant-free送信リソースを用いたURLLCの初期送信における上り送信電力制御を適切に行うことができる。
【００９４】
また、Grant-free送信の再送を指示するためのUL grantは、例えば、CS-RNTIを用いてスクランブリングされてもよい。この場合、端末１００は、検出したUL grantがCS-RNTIでスクランブリングされる場合、当該UL grantでスケジューリングされたPUSCHがURLLC用であると判断してもよい。
【００９５】
［例５：UL grantが指示するPUSCHの送信タイミング又は送信シンボル数］
例５では、所定の条件は、端末１００がUL grantを受信してから上りリンク信号を送信するまでの期間が所定時間以内であることである。または、所定の条件は、UL grantに示される上りリンク信号の送信シンボル数が所定値以下であることである。
【００９６】
UL grantには、時間リソース情報（例えば、Time domain resource assignment field等）が含まれる。時間リソース情報には、UL grantを受信してからPUSCHを送信するまでの時間（例えば、PUSCH preparation time：N2とも呼ばれる）又はPUSCHのシンボル数（又は、時間長）が含まれる。URLLCデータがスケジューリングされる場合、低遅延の要求を満たすため、他のサービス種別と比較して、PUSCH preparation time又はシンボル長は短く設定される可能性が高い。
【００９７】
例えば、UL grantが指示するPUSCH preparation timeがX3[symbol]以下の場合、PCパラメータ制御部１０４は、当該UL grantがURLLC用PUSCHをスケジューリングするUL grantであると判断し、PC parameter set番号j=AのPC parameter setを選択する。一方、UL grantが指示するPUSCH preparation timeがX3[symbol]より大きい場合、PCパラメータ制御部１０４は、当該UL grantがURLLC以外のサービス種別のPUSCHをスケジューリングするUL grantであると判断し、PC parameter set番号j=BのPC parameter setを選択する。
【００９８】
または、UL grantが指示するPUSCHのシンボル数がX4[symbol]以下の場合、PCパラメータ制御部１０４は、当該UL grantがURLLC用PUSCHをスケジューリングするUL grantであると判断し、PC parameter set番号j=AのPC parameter setを選択する。一方、UL grantが指示するPUSCHのシンボル数がX4[symbol]より多い場合、PCパラメータ制御部１０４は、当該UL grantがURLLC以外のサービス種別のPUSCHをスケジューリングするUL grantであると判断し、PC parameter set番号j=BのPC parameter setを選択する。
【００９９】
このように、例５では、UL grantによって指示されるPUSCHの送信タイミング（又は送信シンボル数）に応じて、PC parameter set番号が基地局２００から端末１００へ暗黙的に通知される。
【０１００】
［例６：UL grantの検出周期］
例６では、所定の条件は、端末１００におけるUL grantの検出周期が所定値以下であることである。
【０１０１】
UL grantを含む各DCI formatには、端末１００毎の所定の検出周期が基地局２００から設定される。URLLCデータがスケジューリングされる場合、低遅延の要求を満たすため、UL grantに対して短い検出周期が設定される可能性が高い。
【０１０２】
例えば、UL grantの検出周期がX5[symbol]以下の場合、PCパラメータ制御部１０４は、当該UL grantがURLLC用PUSCHをスケジューリングするUL grantであると判断し、PC parameter set番号j=AのPC parameter setを選択する。
【０１０３】
一方、UL grantの検出周期がX5[symbol]より長い場合、PCパラメータ制御部１０４は、当該UL grantがURLLC以外のサービス種別のPUSCHをスケジューリングするUL grantであると判断し、PC parameter set番号j=BのPC parameter setを選択する。
【０１０４】
このように、例６では、UL grantの検出周期に応じて、PC parameter set番号が基地局２００から端末１００へ暗黙的に通知される。
【０１０５】
［例７：UL grantで用いるMCS（Modulation and coding scheme）テーブル］
例７では、所定の条件は、UL grantに用いられるMCSテーブルが所定のMCSテーブルと異なることである。
【０１０６】
NRでは、端末にMCS（符号化率及び変調方式）を指示するためにUL grantで用いるMCSテーブル（MCS番号と一意に対応するMCSのパターン表）には、「URLLC用MCSテーブル」と、「eMBB用MCSテーブル」とが定義されている。
【０１０７】
URLLC用MCSテーブルの一例を図７Ａに示し、eMBB用MCSテーブルの一例を図７Ｂ及び図７Ｃに示す（例えば、非特許文献６を参照）。図７Ａに示すURLLC用MCSテーブルは、図７Ｃに示すeMBB用MCSテーブルに含まれている256QAM(Modulation Order Qm = 8)が無く、図７Ｂ及び図７Ｃに示すeMBB用MCSテーブルよりコーディングレートが低いMCS（換言すると、Spectral efficiencyが低いMCS）が含まれる。
【０１０８】
例えば、DCI formatで用いる端末固有のスクランブリング系列（例えば、RNTI）、又は、PDCCHの割当リソースであるサーチスペースによって、端末１００がどのMCSテーブルを用いるかが予め決定される。
【０１０９】
例えば、PCパラメータ制御部１０４は、UL grantで用いるMCSテーブルがURLLC用MCSテーブルの場合、当該UL grantが、URLLCデータをスケジューリングするUL grantであると判断する。換言すると、PCパラメータ制御部１０４は、UL grantで用いるMCSテーブルがURLLC用MCSテーブルの場合、当該UL grantによってスケジューリングされたPUSCHがURLLC用のPUSCH（URLLC PUSCH）であると判断する。
【０１１０】
例えば、端末１００が検出したUL grantで用いるMCSテーブルがURLLC用MCSテーブルの場合、PCパラメータ制御部１０４は、当該UL grantがURLLC用PUSCHをスケジューリングするUL grantであると判断し、URLLCに対応するPC parameter set番号j=AのPC parameter setを選択する。
【０１１１】
一方、端末１００が検出したUL grantで用いるMCSテーブルがeMBB用MCSテーブル（あるいは、URLLC用MCSテーブル以外のMCSテーブル）の場合、PCパラメータ制御部１０４は、当該UL grantがURLLC以外のサービス種別（例えば、eMBB）のデータをスケジューリングするUL grantであると判断する。PCパラメータ制御部１０４は、UL grantがURLLC以外のサービス種別のデータをスケジューリングするUL grantであると判断した場合、URLLC以外のサービス種別に対応するPC parameter set番号j=BのPC parameter setを選択する。
【０１１２】
このように、例７では、UL grantに用いられるDCI formatのMCSテーブルに応じて、PC parameter set番号が基地局２００から端末１００へ暗黙的に通知される。
【０１１３】
以上、URLLCデータをスケジューリングするUL grantと判断できる「所定の条件」の例について説明した。
【０１１４】
なお、例１〜例７において説明した所定の条件を複数組み合わせてもよい。
【０１１５】
［PC parameter set番号j=A、Bの設定例］
次に、PCパラメータ制御部１０４において設定されるPC parameter set番号j=A及びBの設定例について説明する。
【０１１６】
例えば、URLLC PUSCHの送信電力は、少なくとも、URLLC以外のサービス種別（例えば、eMBB）のPUSCHの送信電力よりも大きく設定される。
【０１１７】
例えば、式（１）において、PC parameter setのうち、目標受信電力PO_PUSCH,f,c(j)が大きいほど、PUSCHの送信電力PPUSCH,f,c(i, j, qd, l)は大きくなる可能性が高い。また、PC parameter setのうち、パスロスの補償割合を示す重み係数αf,c(j)が大きいほど、パスロスの値がPUSCHの送信電力PPUSCH,f,c(i, j, qd, l)に反映されやすくなり、PUSCHの送信電力PPUSCH,f,c(i, j, qd, l)は大きくなる可能性が高い。
【０１１８】
そこで、例えば、図６に示すように、PC parameter set番号j（ｊ＝０〜Ｊ−１の何れか）の最も小さい番号0を、例えば、URLLC以外のサービス種別（例えば、eMBB用）のPC parameter set値（B=0）に設定し、PC parameter set番号jの最も大きい番号J-1を、URLLC用PC parameter set値（A=J-1）に設定してもよい。図６に示すように、PC parameter set番号j=0の場合、PO_PUSCH,f,c(0)=-80dBm及びαf,c(0)=0.6であり、PC parameter set番号j=J-1の場合、PO_PUSCH,f,c(J-1)=-50dBm及びαf,c(J-1)=1.0である。よって、PC parameter set番号j=J-1が設定される場合のPUSCHの送信電力PPUSCH,f,c(i, J-1, qd, l)は、PC parameter set番号j=0が設定される場合のPUSCHの送信電力PPUSCH,f,c(i, 0, qd, l)よりも大きくなる可能性が高い。
【０１１９】
なお、図６では、PC parameter set番号Aをｊの最大値J-1とし、PC parameter set番号Bをｊの最小値0とする場合について説明したが、PC parameter set番号A及びBは、これらの値に限定されない。例えば、PC parameter set番号Bが、PC parameter set番号Aより大きい値に設定されればよい。
【０１２０】
または、URLLC以外のサービス種別（例えば、eMBB）のPC parameter set番号Bに対して所定のオフセットΔを加えたPC parameter set番号を、URLLC用PC parameter set番号A（= B+Δ）としてもよい。
【０１２１】
または、URLLC以外のサービス種別（例えば、eMBB）のPC parameter set値に所定のオフセットΔ[dB]を加えたPC parameter set値（PO_PUSCH,f,c(B)＋Δ）を、URLLC用のPC parameter set値（PO_PUSCH,f,c(A)）として用いてもよい。つまり、PO_PUSCH,f,c(A)=PO_PUSCH,f,c(B)＋Δでもよい。
【０１２２】
なお、端末１００が複数の送受信ポイント（TRP（Transmission/ Reception Point））と送受信する場合、TRP毎にURLLC用PC parameter set番号A、および、URLLC以外のサービス種別のPC parameter set番号Bが定義されてもよい。図８は、TRP毎のPC parameter set値の設定例を示す。図８では、例えば、TRP#0に対して、URLLC用PC parameter set値としてPC parameter set番号j=J-2が設定され、URLLC以外のサービス種別のPC parameter set値としてPC parameter set番号j=0が設定されている。同様に、TRP#1に対して、URLLC用PC parameter set値としてPC parameter set番号j=J-1が設定され、URLLC以外のサービス種別のPC parameter set値としてPC parameter set番号j=1が設定されている。
【０１２３】
TRPが異なれば、パスロス等の伝搬環境が大きく異なる。このため、図８に示すように、各TRPに適したPC parameter setを定義し、選択可能としてもよい。これにより、端末１００は、PUSCHの送信電力をTRP毎に適切に設定できる。
【０１２４】
なお、図８に示すTRP毎のPC parameter setの設定は一例であり、これに限定されず、各TRPに対して、URLLC PUSCHの送信電力が、少なくとも、URLLC以外のサービス種別のPUSCHの送信電力よりも大きく設定されればよい。例えば、TRP#0及びTRP#1の伝搬環境によっては、TRP#0に対するURLLC用PC parameter set値が、URLLC以外のサービス種別のPC parameter set値より低く設定される場合もある。
【０１２５】
また、配置環境が異なる（換言すると、QCL（Quaisi-colocation）が異なる）複数アンテナパネルを持つ基地局２００と端末１００とが通信する場合、複数のTRPと端末１００とが通信する場合（例えば、図８を参照）と同様に、アンテナパネル毎にURLLC用PC parameter set番号AおよびURLLC以外のサービス種別のPC parameter set番号Bが定義されてもよい。
【０１２６】
なお、TRP番号およびアンテナパネル番号は、例えば、端末１００が受信した制御チャネル（例えば、PDCCH）が設定された制御チャネル用の送信リソース（例えば、CORESET（Control Resource Set）と呼ばれる）から判断できる。
【０１２７】
以上、PC parameter set番号j=A及びBの設定例について説明した。
【０１２８】
なお、PC parameter set番号jと、PC parameter set（例えば、PO_PUSCH,f,c(j)及びαf,c(j)）との対応関係は、図６に示す一例に限定されない。例えば、図６では、PC parameter set番号jの値の増加に伴い、PO_PUSCH,f,c(j)及びαf,c(j)が増加する場合（換言すると、PO_PUSCH,f,c(j)及びαf,c(j)が昇順の場合）について示した。しかし、PC parameter set番号jの値の増加に伴い、PO_PUSCH,f,c(j)又はαf,c(j)の値は増加しなくてもよい。
【０１２９】
このように、本実施の形態では、端末１００は、UL grantに関する所定の条件を満たす場合、URLLCに対応するPC parameter set（電力制御パラメータ）を設定し、上記所定の条件を満たさない場合、URLLC以外のサービス種別に対応するPC parameter setを設定する。そして、端末１００は、設定したPC parameter setを用いて計算された送信電力を用いて上りリンク信号を送信する。
【０１３０】
これにより、URLLC用PUSCHの送信電力制御（例えば、パワーブースト）のパラメータ（例えば、PC parameter set）を基地局２００から端末１００へ暗黙的に通知できる。よって、PC parameter set番号を明示的に指示する情報（またはフィールド）を含まないUL grantでも、URLLC及びeMBB等のサービス種別に適した上りチャネルの送信電力を適切に設定できる。また、UL grantに新たな情報を追加する必要がないため、PDCCHのオーバーヘッドの増加を防止できる。
【０１３１】
よって、本実施の形態によれば、端末１００は、サービス種別に応じた上りチャネルの送信電力を用いて、上りリンク信号を適切に送信できる。
【０１３２】
ここで、URLLCの上り送信には低遅延が要求される。このため、図９に示すように、URLLCデータ（URLLC PUSCH）は、eMBBデータ（eMBB PUSCH）用に他の端末へ既に割り当てられた無線リソースに重ねてスケジューリングされる場合がある。また、URLLCは周波数ダイバーシチゲインを得るために広帯域の無線リソースを割り当てることが検討されている。このため、URLLCとeMBBとの間において無線リソース（例えば、時間リソース又は周波数リソース）の一部が重なることが想定される。
【０１３３】
このように、異なる端末（例えば、図９ではUE#0及びUE#1）からのeMBBデータとURLLCデータとの間において、上り送信用の無線リソースの一部又は全てが衝突する（重なる）場合でも、本実施の形態によれば、端末１００は、URLLCデータの上り送信において、基地局２００においてURLLCデータを復号可能な上り送信電力を適切に設定できる。このため、URLLCの低遅延及び高信頼性の要求仕様を満たすことができる。
【０１３４】
（実施の形態２）
本実施の形態では、URLLC用の上りリンク制御情報（以下、UCI（Uplink Control Information））をPUSCHで送信する（「UCIをPiggybackする」とも呼ばれる）場合のPUSCHの送信電力の設定方法について説明する。
【０１３５】
例えば、UCI送信用の上りチャネルであるPUCCHの送信タイミングが、PUSCHの送信タイミングと重なる場合、マルチキャリア送信によるPAPR（Peak to Average Power Ratio）の増加を避けるために、端末は、UCIを、UL-SCH（Uplink Shared Channel。上りデータ情報）と多重し、PUSCHで送信する（「UCIをPiggybackする」とも呼ばれる）。
【０１３６】
ここで、端末が、URLLCデータと同様の高品質が要求されるUCI（以下、「URLLC用UCI」と呼ぶ）をPUSCHで送信する場合、UCIの品質を満たすためにパワーブーストが必要になる場合がある。換言すると、端末においてURLLC用UCIをPUSCHで送信する場合、URLLC以外のサービス種別（例えば、eMBB）を送信する場合と比較して、パワーブーストが必要となる場合がある。なお、URLLC用UCIとしては、例えば、URLLC用データに対するACK/NACK情報、又は、URLLC用の目標BLER（Block Error Rate）（例えば、BLER=10E-5）に対するチャネル状態情報（以下、CSI（Channel State Information））等が想定される（詳細は後述する）。
【０１３７】
しかしながら、PUSCHの送信電力制御は、UCIの有無に関わらず決定される。よって、フォールバック用DCI（例えば、DCI format 0_0）のようにSRI fieldが含まれない場合、つまり、PC parameter set番号を明示的に指示する情報が含まれないUL grantが使用される場合、PUSCHの送信電力は、URLLC用UCIの有無に依らずに決定される。このため、端末は、UCIを含むPUSCHの送信電力を適切にパワーブーストできない場合がある。例えば、端末がeMBB用のデータとURLLC用UCIとを1つのPUSCHで送信する場合にも、eMBB用データを単独で送信する場合(換言すると、UCI無しでeMBB用データを送信する場合）と同じ送信電力が適用される。よって、URLLC用UCIに対して送信電力不足となり、URLLCの要求品質を満たせない場合がある。
【０１３８】
そこで、本実施の形態では、PC parameter setの選択によって、UCI（特に、URLLC用UCI）を含むPUSCHの送信電力を適切にパワーブーストする方法について説明する。
【０１３９】
本実施の形態に係る通信システムは、端末３００（後述する図１０を参照）及び基地局２００（例えば、図４を参照）を備える。
【０１４０】
［端末３００の構成］
図１０は、本実施の形態に係る端末３００の構成例を示すブロック図である。なお、図１０において実施の形態１の端末１００（図３）と同様の構成には同一の符号を付し、その説明を省略する。具体的には、図１０に示す端末３００では、図３に示す端末１００に対し、UCI生成部３０１、符号化・変調部３０２、及び、多重部３０３が追加され、かつ、PCパラメータ制御部３０４の動作が異なる。
【０１４１】
UCI生成部３０１は、端末３００が送信するUCI（ACK/NACKあるいはCSI等の上りリンク制御情報）を生成し、生成したUCIを符号化・変調部３０２へ出力する。また、UCI生成部３０１は、送信するUCIに関する情報をPCパラメータ制御部３０４へ出力する。
【０１４２】
符号化・変調部３０２は、復調・復号部１０３から入力されるDCIに基づいて、UCI生成部３０１から入力されるUCIに対して、符号化及び変調を行い、変調後のUCI信号を多重部３０３へ出力する。
【０１４３】
多重部３０３は、符号化・変調部３０２から入力されるUCI信号と、符号化・変調部１０７から入力される変調後のデータ信号とを多重し、多重後のデータ信号をリソース割当部１０８へ出力する。多重部３０３は、UCIとデータ信号との多重方法として、例えば、データ信号の一部のRE（Resource Element）をパンクチャし、パンクチャした部分にUCI信号を入れてもよい。あるいは、多重部３０３は、UCI信号のREサイズを予め考慮し、データ信号のREサイズを決定（レートマッチ）してもよい。
【０１４４】
PCパラメータ制御部３０４は、復調・復号部１０３から入力されるDCIと、UCI生成部３０１から入力されるUCIに関する情報とを用いて、スケジューリングされたPUSCHに適用するPC parameter set番号jを決定する。PCパラメータ制御部３０４は、決定したPC parameter set番号を送信電力計算部１０５へ出力する。
【０１４５】
［基地局の構成］
本実施の形態に係る基地局は、実施の形態１に係る基地局２００と基本構成が共通するので、図４を援用して説明する。なお、本実施の形態に係る基地局２００における復号後の受信データには、端末３００（図１０を参照）からのデータに加えてUCIが含まれる。
【０１４６】
以下、UCI（特に、URLLC用UCI）を含む（多重する、あるいは、Piggybackする）PUSCHについて、PC parameter setの変更による送信電力のパワーブーストを適応する「所定の条件」の例について説明する。
【０１４７】
［例１：URLLC用PDSCH（下りデータチャネル）に対するACK/NACKを含む］
例１では、所定条件は、UL grantでスケジューリングするPUSCHに含まれるUCIがURLLC用PDSCHに対するACK/NACK（応答信号）であることである。URLLC用PDSCHに対するACK/NACKは、URLLC用PDSCHと同様に低遅延及び高信頼性が求められることが考えられる。
【０１４８】
なお、端末３００は、PDSCHをスケジューリングするDCIで用いるスクランブリング系列（例えば、RNTI）が所定の系列（例えば、eMBB用PDSCHをスケジューリングするC-RNTIあるいはCS-RNTI）と異なる場合に、当該PDSCHがURLLC用PDSCHであることを判断できる。例えば、端末３００は、PDSCHをスケジューリングするDCIで用いるスクランブリング系列がURLLC用のRNTIである場合に、当該PDSCHがURLLC用PDSCHであることを判断してもよい。
【０１４９】
あるいは、端末３００は、PDSCHをスケジューリングするDCIでURLLC用MCSテーブルを用いる場合に、当該PDSCHがURLLC用PDSCHであることを判断できる。
【０１５０】
例えば、端末３００が検出したUL grantでスケジューリングするPUSCHに、URLLC用PDSCHに対するACK/NACKが含まれる場合、PCパラメータ制御部３０４は、当該UL grantがURLLC用UCIを含むPUSCHをスケジューリングするUL grantであると判断し、URLLCに対応するPC parameter set番号j=AのPC parameter setを選択する。
【０１５１】
一方、端末３００が検出したUL grantでスケジューリングするPUSCHに、URLLC用PDSCHに対するACK/NACKが含まれない場合、PCパラメータ制御部３０４は、当該UL grantがURLLC用UCIを含まないPUSCHをスケジューリングするUL grantであると判断し、URLLC以外のサービス種別に対応するPC parameter set番号j=BのPC parameter setを選択する。
【０１５２】
このように、例１では、UL grantでスケジューリングするPUSCHに、URLLC用PDSCHに対するACK/NACKが含まれるか否かに応じて、PC parameter set番号が基地局２００から端末３００へ暗黙的に通知される。
【０１５３】
［例２：PDSCH受信からACK/NACK送信までの時間間隔が所定の閾値以下のACK/NACK］
例２では、所定条件は、UL grantでスケジューリングするPUSCHに含まれるUCIが、PDSCH受信からACK/NACK送信までの時間間隔（例えば、N1[symbol]と呼ばれることもある）が所定の閾値X6[symbol]以下のACK/NACKであることである。例えば、N1は、PDSCHをスケジューリングするDCIに含まれる。
【０１５４】
換言すると、所定の条件は、端末３００がPDSCHを受信してから、当該PDSCHに対するACK/NACKを含むUCIを送信するまでの期間N1［symbol］が所定時間X6以内であることである。
【０１５５】
端末３００は、N1が短い場合（換言すると、N1≦X6の場合）、UL grantでスケジューリングされたPUSCHに含まれるUCIが、低遅延が要求されるURLLC用UCIであると判断できる。
【０１５６】
例えば、端末３００が検出したUL grantでスケジューリングするPUSCHに、N1が短いACK/NACK（N1≦X6となるACK/NACK）が含まれる場合、PCパラメータ制御部３０４は、当該UL grantがURLLC用UCIを含むPUSCHをスケジューリングするUL grantであると判断し、URLLCに対応するPC parameter set番号j=AのPC parameter setを選択する。
【０１５７】
一方、上記以外の場合（例えば、PUSCHに、N1が長いACK/NACK（N1＞X6となるACK/NACK）が含まれる場合）、PCパラメータ制御部３０４は、当該UL grantがURLLC用UCIを含まないPUSCHをスケジューリングするUL grantであると判断し、URLLC以外のサービス種別に対応するPC parameter set番号j=BのPC parameter setを選択する。
【０１５８】
このように、例２では、UL grantでスケジューリングするPUSCHに、N1が短いACK/NACKが含まれるか否かに応じて、PC parameter set番号が基地局２００から端末３００へ暗黙的に通知される。
【０１５９】
［例３：所定の閾値以下の目標BLERで計算されたたCSI］
例３では、所定条件は、UL grantでスケジューリングするPUSCHに含まれるUCIが、所定閾値X7以下の目標誤り率（例えば、目標BLER）を用いて計算されたCSIであることである。
【０１６０】
CSI計算に用いる目標BLERは、基地局３００から端末２００に予め設定される。端末３００は、閾値X7以下の低い目標BLER（例えば、目標BLER=10E-5）で計算されたCSIが、URLLC用UCIであると判断できる。
【０１６１】
例えば、端末３００が検出したUL grantでスケジューリングするPUSCHに、所定閾値X7以下の目標BLER（例えば、目標BLER=10E-5）で計算されたCSIが含まれる場合、PCパラメータ制御部３０４は、当該UL grantがURLLC用UCIを含むPUSCHをスケジューリングするUL grantであると判断し、URLLCに対応するPC parameter set番号j=AのPC parameter setを選択する。
【０１６２】
一方、上記以外の場合（例えば、PUSCHに、閾値X7より大きい目標BLER（例えば、目標BLER=10E-1）で計算されたCSIが含まれる場合）、PCパラメータ制御部３０４は、当該UL grantがURLLC用UCIを含まないPUSCHをスケジューリングするUL grantであると判断し、URLLC以外のサービス種別に対応するPC parameter set番号j=BのPC parameter setを選択する。
【０１６３】
このように、例３では、UL grantでスケジューリングするPUSCHに、所定閾値X7以下の目標BLERで計算されたCSIが含まれるか否かに応じて、PC parameter set番号が基地局２００から端末３００へ暗黙的に通知される。
【０１６４】
［例４：eMBB用PDSCHに対するACK/NACKを含む］
例４では、所定条件は、UL grantでスケジューリングするPUSCHに含まれるUCIがeMBB用PDSCHに対するACK/NACKであることである。つまり、本実施の形態に係る例１の条件（URLLC用PDSCHに対するACK/NACKであること）と逆の条件となる。
【０１６５】
例えば、低遅延の優先度が低く、高信頼性の優先度がより高いサービスをスケジューリングする場合、基地局２００は、PDSCH、及び、当該PDSCHに対するACK/NACKのそれぞれの誤り率を乗算したトータルの誤り率が所定の品質になるように制御することが考えられる。
【０１６６】
例えば、PDSCH及びACK/NACKの全体の誤り率（各誤り率を乗算した値）が一定の値（例えば、10E-6）になる場合について説明する。この場合、基地局２００は、例えば、PDSCHの誤り率が10E-1（eMBB用PDSCH相当の品質）になり、ACK/NACKの誤り率が10E-5（URLLC用UCI相当の品質）になるように制御する。あるいは、基地局２００は、例えば、PDSCHの誤り率が10E-5（URLLC用PDSCH相当の品質）になり、ACK/NACKの誤り率が10E-1（eMBB用UCI相当の品質）になるように制御する。
【０１６７】
換言すると、誤り率が10E-1になるように制御されたPDSCH（eMBB用PDSCH）に対するACK/NACKは、誤り率が10E-5になるように制御されたURLLC用UCIである。一方、誤り率が10E-5になるように制御されたPDSCH（URLLC用PDSCH）に対するACK/NACKは、誤り率が10E-1になるように制御されたeMBB用UCIである。
【０１６８】
よって、基地局２００が上記のように制御する場合、例えば、端末３００が検出したUL grantでスケジューリングするPUSCHに、eMBB用PDSCHに対するACK/NACKが含まれる場合、PCパラメータ制御部３０４は、当該UL grantがURLLC用UCI（ACK/NACK）を含むPUSCHをスケジューリングするUL grantであると判断し、URLLCに対応するPC parameter set番号j=AのPC parameter setを選択する。
【０１６９】
一方、上記以外の場合には、PCパラメータ制御部３０４は、当該UL grantがURLLC用UCIを含まないPUSCH（例えば、eMBB用UCIを含むPUSCH）をスケジューリングするUL grantであると判断し、URLLC以外のサービス種別に対応するPC parameter set番号j=BのPC parameter setを選択する。
【０１７０】
このように、例４では、UL grantでスケジューリングするPUSCHにeMBB用PDSCHに対するACK/NACKが含まれるか否かに応じて、PC parameter set番号が基地局２００から端末３００へ暗黙的に通知される。
【０１７１】
なお、本実施の形態に係る例１と例４とで、PC parameter set値の制御方法が逆になるが、基地局２００が想定するスケジューリング方法に応じて適切な制御方法が選択されればよい。
【０１７２】
［例５：URLLC用UCIに要求されるRE数が上限に達する］
例５では、所定条件は、UL grantでスケジューリングするPUSCHに、本実施の形態に係る例１〜４の何れかに当てはまるURLLC用UCIが含まれ（Piggybackされ）、当該URLLC用UCIに要求されるRE数がPUSCHに配置可能なRE数の上限に達することである。
【０１７３】
NRでは、例えば、ACK/NACKの場合、以下の式（２）に従って、PUSCHに配置できるUCIのRE数が決定される。
【数２】
2019216073.tif 000004
【０１７４】
ここで、Q'ACKは実際にPUSCHで送信するACK/NACKのRE数（Actual RE数と呼ぶ）、OACKはACK/NACKビット数、LACKはCRC（Cyclic Redundancy Check）ビット数、βoffsetPUSCHはデータ(UL-SCH)に対するACK/NACKの符号化率の補正係数（パラメータ）、ΣMSCUCI(l)（ただし、l=0〜（Nsymb,allPUSCH-1））はPUSCHの送信に用いるRE数、ΣKr（ただし、r=0〜CUL-SCH-1）はPUSCHで送信するデータ(UL-SCH)のビット数を示す。また、αはPUSCHで送信するUCI（ACK/NACK）のRE数の割合を示す。換言すると、αは、UL-SCHの品質を確保するためにUCIのRE数の上限を決めるパラメータである。
【０１７５】
ここで、式（２）のmin関数の左辺（以下の式（３）のようにQ"ACKとおく）は、ACK/NACKに要求される品質を得るためにPUSCHの送信に用いるRE数（Required RE数と呼ぶ）を示す。
【数３】
2019216073.tif 000005
【０１７６】
URLLC用UCIに要求されるRE数（Required RE数）が上限に達する場合、つまり、αによってRE数が制限され、Q'ACK＜Q"ACKとなる場合、端末３００は、要求される品質を満たすためのRE数のUCIをPUSCHに配置できない。
【０１７７】
そこで、URLLC用UCIに要求されるRE数がPUSCHに配置できるRE数の上限に達する場合（つまり、Q'ACK＜Q"ACKとなる場合）、PCパラメータ制御部３０４は、URLLC用UCIの品質を改善するため、URLLCに対応するPC parameter set番号j=AのPC parameter setを選択する。
【０１７８】
一方、URLLC用UCIに要求されるRE数がPUSCHに配置できるRE数の上限に達していない場合（つまり、Q'ACK≧Q"ACKとなる場合）、PCパラメータ制御部３０４は、パワーブーストする必要無しと判断し、URLLC以外のサービス種別に対応するPC parameter set番号j=BのPC parameter setを選択する。
【０１７９】
このように、例５では、UL grantでスケジューリングするPUSCHに含まれるURLLC用UCIに要求されるRE数がPUSCHに配置できるRE数の上限に達するか否かに応じて、PC parameter set番号が基地局２００から端末３００へ暗黙的に通知される。
【０１８０】
なお、URLLC用UCIが、CSI（詳細にはCSI-1（CSI part1）とCSI-2（CSI part2））の場合にも端末３００は上述した処理と同様な処理を行う。つまり、端末３００は、αによってPUSCHに配置するCSIのRE数が制限される場合に、URLLC用UCIの品質を改善するため、URLLCに対応するPC parameter set番号j=AのPC parameter setを選択する。
【０１８１】
［例６：URLLC用UCIを含むUCIのRE数が所定割合より大きい］
例６では、所定条件は、UL grantでスケジューリングするPUSCHに、本実施の形態に係る例１〜４の何れかに当てはまるURLLC用UCIが含まれ、PUSCH全体において、当該URLLC用UCIを含むUCIのRE数が所定割合より大きいことである。
【０１８２】
例えば、端末３００は、以下の式（４）に示す条件を満たす場合にPUSCHをパワーブーストする。
【数４】
2019216073.tif 000006
【０１８３】
ここで、Q'ACK、Q'CSI-1、Q'CSI-2はそれぞれ、実際にPUSCHで送信するACK/NACK、CSI part1及びCSI part2のRE数（Actual RE数）を示す。また、ΣMSCUCI(l)（ただし、l=0〜（Nsymb,allPUSCH-1））はPUSCHの送信に用いるRE数、γはPUSCHで送信するURLLC用UCIを含むUCI（ACK/NACKとCSIを含めたトータルのUCI）のRE数の上限の割合である。例えば、PUSCH全体のRE数に対する、UCIのRE数の割合が、この割合γを超える場合、PUSCHの中において、UCIがUL-SCHよりも支配的であると想定される。
【０１８４】
例えば、URLLC用UCIを含むUCIのトータルのRequired RE数が上限に達する場合、つまり、式（４）の条件が成り立つ場合、PCパラメータ制御部３０４は、PUSCHの中でUCIがUL-SCHに比べて支配的と判断し、URLLCに対応するPC parameter set番号j=AのPC parameter setを選択する。
【０１８５】
一方、URLLC用UCIを含むUCIのトータルのRequired RE数が上限に達していない場合、つまり、式（４）の条件が成り立たない場合、PCパラメータ制御部３０４は、PUSCHの中でUL-SCHがUCIに比べて支配的と判断し、URLLC以外のサービス種別に対応するPC parameter set番号j=BのPC parameter setを選択する。
【０１８６】
このように、例６では、PUSCHの中でUCIがUL-SCHに比べて支配的か否かに応じて、PC parameter set番号が基地局２００から端末３００へ暗黙的に通知される。
【０１８７】
なお、以下の式（５）のように、PUSCHで送信するUCIのRE数の上限値（RE数）を示すδが定義されてもよい。つまり、端末３００は、式（５）の条件が成り立つ場合、PUSCHの中でUCIがUL-SCHに比べて支配的と判断し、URLLCに対応するPC parameter set番号j=AのPC parameter setを選択する。これにより、式（４）に示す割合γを用いた制御と同様の効果が得られる。
【数５】
2019216073.tif 000007
【０１８８】
以上、UCIを含むPUSCHについて、PC parameter setの変更による送信電力のパワーブーストを適応する「所定の条件」の例について説明した。
【０１８９】
なお、例１〜例６において説明した所定の条件を複数組み合わせてもよい。
【０１９０】
［PC parameter setの選択方法］
次に、端末３００のPCパラメータ制御部３０４における、PUSCHにUCIが含まれる場合のPC parameter setの選択方法について説明する。
【０１９１】
［例１：URLLC用UCIのUCI type毎のPC parameter setの選択］
例１では、PCパラメータ制御部３０４は、URLLC用UCIのUCI type（例えば、ACK/NACK、CSI part1又はCSI part2等）毎にPC parameter setを選択する。
【０１９２】
例えば、図１１に示すように、UCI typeがCSI（CSI part1又はCSI part2）の場合、PCパラメータ制御部３０４は、URLLCに対応するPC parameter set番号ｊ=J-2のPC parameter setを選択する。また、UCI typeがACK/NACKの場合、PCパラメータ制御部３０４は、URLLCに対応するPC parameter set番号ｊ=J-1のPC parameter setを選択する。
【０１９３】
これにより、CSIに比べてパケット伝送の遅延時間に影響が大きいと考えられるACK/NACKの送信電力をより大きくすることができる。
【０１９４】
なお、CSI part1はWideband CQI又はRank Indiatorを含み、CSI part2はSubband CQIを含む。CSI part1の方が、CSI part2に比べて、基地局のスケジューリングにおいてより使用頻度が高い重要情報と考えられる。そこで、PCパラメータ制御部３０４は、URLLC用UCIとしてCSI part1を含む場合、UCIとしてCSI part2のみを含む場合に比べて、より高い送信電力が設定されるようにPC parmeter setを定義してもよい。
【０１９５】
例えば、UCIにCSI part1が含まれる場合には、PCパラメータ制御部３０４は、PC parameter set番号ｊ=J-2のPC parameter set（例えば、Po_PUSCH,f,c(j)=-60dBm、αf,c(j)=0.9）を選択する。また、UCIにCSI part2のみが含まれる場合には、PCパラメータ制御部３０４は、PC parameter set番号ｊ=J-3で定義したPC parameter set（例えば、Po_PUSCH,f,c(j)=-55dBm、αf,c(j)=0.9）を選択する。
【０１９６】
これにより、CSIの情報の重要度に応じた適切な送信電力が設定できる。
【０１９７】
［例２：URLLC用UCIを含むUCIビット数に応じたPC parameter setの選択］
例２では、PCパラメータ制御部３０４は、URLLC用UCIを含むUCIビット数に応じてPC parameter setを選択する。
【０１９８】
例えば、図１２に示すように、URLLC用UCIを含むUCIビット数が所定閾値X8[bit]以下の場合、PCパラメータ制御部３０４は、URLLCに対応するPC parameter set番号ｊ=J-2のPC parameter setを選択する。また、URLLC用UCIを含むUCIビット数が所定閾値X8[bit]より大きい場合、PCパラメータ制御部３０４は、URLLCに対応するPC parameter set番号ｊ=J-1のPC parameter setを選択する。
【０１９９】
これにより、UCIビット数が多いほど、つまり、PUSCH全体においてUCIが支配的になるほど、PUSCHの送信電力をより大きくすることができる。
【０２００】
［例３：UL-SCHとURLLC用UCIとのサービス種別の組み合わせに応じたPC parameter setの選択］
例３では、PCパラメータ制御部３０４は、UL-SCHとURLLC用UCIとのサービス種別の組み合わせに応じてPC parameter setを選択する。
【０２０１】
図１３に示すように、UL-SCH（PUSCH）とURLLC用UCIとのサービス種別の組み合わせは４つある。図１３において、(1)はeMBB用UCIをeMBB用PUSCHで送信する組み合わせ、(2)はURLLC用UCIをURLLC用PUSCHで送信する組み合わせ、(3)はURLLC用UCIをeMBB用PUSCHで送信する組み合わせ、(4)はeMBB用UCIをURLLC用PUSCHで送信する組み合わせを示す。
【０２０２】
例えば、図１３に示すOption 1のように、PCパラメータ制御部３０４は、URLLC用UCI及びURLLC用PUSCHの少なくとも一方が含まれる組み合わせ（図１３の(2)、(3)又は(4)の組み合わせ）の場合、URLLCに対応するPC parameter set番号j=AのPC parameter setを選択してもよい。一方、図１３に示すOption 1のように、PCパラメータ制御部３０４は、URLLC用UCI及びURLLC用PUSCHの何れも含まない組み合わせ（図１３の(1)の組み合わせ）の場合、URLLCに対応するPC parameter set番号j=BのPC parameter setを選択してもよい。
【０２０３】
あるいは、図１３のOption 2のように、PCパラメータ制御部３０４は、各組み合わせに応じてPC parameter setを選択してもよい。図１３のOption 2では、PCパラメータ制御部３０４は、(1)の組み合わせの場合にはeMBBに対応するPC parameter set番号j=BのPC parameter setを選択し、(2)〜(4)の組み合わせの場合にはURLLCに対応するPC parameter set番号j=A1〜A3のPC parameter setをそれぞれ選択する。
【０２０４】
例えば、図１３のOption 2に示すように、URLLC用PUSCHよりもURLLC用UCIの品質を優先する場合、PCパラメータ制御部３０４は、(2)⇒(3)⇒(4)の順に送信電力が高くなるPC parameter setを設定する。なお、PC parameter setの設定方法は、図１３に示す例に限らない。例えば、URLLC用UCIよりもURLLC用PUSCHの品質を優先する場合、PCパラメータ制御部３０４は、(2)⇒(4)⇒(3)の順に送信電力が高くなるPC parameter setを設定してもよい。
【０２０５】
これにより、端末３００は、UL-SCH（PUSCH）とURLLC用UCIのサービス種別の組み合わせに応じた送信電力を設定できる。
【０２０６】
以上、PC parameter setの選択方法について説明した。なお、図１１〜図１３において設定されるPC parameter set値（例えば、j=0、J-3、J-2又はJ-1）は一例であり、他の値でもよい。
【０２０７】
このように、本実施の形態では、端末３００は、UL grantによってスケジューリングされるPUSCHに含まれるURLLC用UCIに関する所定の条件を満たす場合、URLLCに対応するPC parameter set（電力制御パラメータ）を設定し、上記所定の条件を満たさない場合、URLLC以外のサービス種別に対応するPC parameter setを設定する。そして、端末３００は、設定したPC parameter setを用いて計算された送信電力を用いて上りリンク信号を送信する。
【０２０８】
これにより、本実施の形態では、端末３００は、URLLC用UCIの有無に応じて、PUSCHの送信電力を制御できるので、UCI（特に、URLLC用UCI）を含むPUSCHの送信電力を適切にパワーブーストすることができる。
【０２０９】
なお、端末３００は、PUSCHに含めて送信するUCIの中に、上述した例１〜４の所定条件を満たすURLLC用UCIが少なくとも１つ含まれる場合、当該UCIに含まれる他の情報に依らず、URLLCに対応するPC parameter set番号j=AのPC parameter setを選択してもよい。
【０２１０】
また、DCI（例えば、C-RNTI又はCS-RNTIでスクランブリングされたDCI format 0_0、あるいは、DCI format 0_1）でスケジューリングされたeMBB用PUSCHに、上述した所定条件を満たすURLLC用UCIを含める場合、端末３００は、eMBB用PUSCHの場合でもURLLCに対応するPC parameter set番号j=AのPC parameter setを選択してもよい。
【０２１１】
また、本実施の形態は、Grant-free送信を行うPUSCHでURLLC用UCIを送信する場合の送信電力の設定方法にも同様に適用できる。
【０２１２】
また、端末３００は、PC parameter setを変更する場合、PUSCHに配置するUCIのRE数を変更する必要はない。つまり、端末３００は、UCIのRE数（Coding rate）を計算するためのパラメータ（α、βoffsetPUSCH）を変更する必要ない。このため、端末３００では、PC parameter setを変更する簡易な制御によって、UCIの要求品質に応じた送信電力を設定できる。
【０２１３】
あるいは、端末３００は、PC parameter setの変更に伴い、PUSCHに配置するUCIのRE数を変更してもよい。この場合、端末３００は、PC parameter setに応じて、UCIのCoding rateの計算に用いるパラメータを個別に設定するか、PC parameter setによる送信電力増減を考慮してCoding rate計算を変更する。これにより、端末３００では、PC parameter setの変更およびUCIのCoding rate計算の変更を行う制御によって、UCIの要求品質に応じた送信電力をより適切に設定できる。
【０２１４】
（実施の形態３）
本実施の形態では、実施の形態２と同様に、URLLC用UCIをPUSCHで送信する場合のPUSCHの上り送信電力の設定方法について説明する。
【０２１５】
本実施の形態では、サービス種別に依らずPC parameter setは固定とし、送信電力式（例えば、式（１）を参照）に対して、UCIに依存した電力調整パラメータを導入することによって、UCI（特に、URLLC用UCI）を含むPUSCHの送信電力を適切にパワーブーストする方法について説明する。
【０２１６】
本実施の形態に係る通信システムは、端末４００（後述する図１４を参照）及び基地局２００（例えば、図４を参照）を備える。
【０２１７】
［端末４００の構成］
図１４は、本実施の形態に係る端末４００の構成例を示すブロック図である。なお、図１４において、実施の形態１の端末１００（図３）又は実施の形態２の端末３００（図１０）と同様の構成には同一の符号を付し、その説明を省略する。具体的には、図１４に示す端末４００では、図１０に示す端末３００に対し、UCI生成部４０１及び送信電力計算部４０２の動作が異なる。
【０２１８】
PCパラメータ制御部１０４は、実施の形態１と同様の処理を行う。つまり、PCパラメータ制御部１０４は、UCIの有無に依らず、復調・復号部１０３から入力されるDCIを用いて、スケジューリングされたPUSCHに適用するPC parameter set番号jを決定する。
【０２１９】
UCI生成部４０１は、端末４００が送信するUCIを生成し、生成したUCIを符号化・変調部３０２へ出力する。また、UCI生成部４０１は、送信するUCIに関する情報を送信電力計算部４０２へ出力する。
【０２２０】
送信電力計算部４０２は、PCパラメータ制御部１０４において設定されたPC parameter set番号jを用いて、例えば、式（６）に従ってPUSCHの送信電力を計算する。式(６)は、式（１）に対してΔUCI（UCIに依存した電力調整パラメータ[dB]）が追加されている。
【数６】
2019216073.tif 000008
【０２２１】
［基地局の構成］
本実施の形態に係る基地局は、実施の形態１又は実施の形態２に係る基地局２００と基本構成が共通するので、図４を援用して説明する。なお、本実施の形態に係る基地局２００における復号後の受信データには、端末４００（図１４を参照）からの上りリンクデータに加えてUCIが含まれる。
【０２２２】
以下、UCIを含むPUSCHについて、UCIに依存した電力調整パラメータΔUCIによる送信電力のパワーブースト方法の例について説明する。
【０２２３】
ΔUCIは例えば、次式（７）のように算出される。
【数７】
2019216073.tif 000009
【０２２４】
ここで、Q"UCIは、UCIに要求される品質を得るためにPUSCHで送信するUCIのRE数（Required RE数）を示す。詳細には、次式（８）のように、Q"UCIは、ACK/NACK、CSI part1及びCSI part2のそれぞれのRequired RE数（Q"ACK、Q"CSI-1及びQ"CSI-2）のトータルのRE数を示す。
【数８】
2019216073.tif 000010
【０２２５】
また、式（７）において、Q'UCIは、PUSCHで実際に送信されるUCIのRE数（Actual RE数）を示す。詳細には、次式（９）のように、Q'UCIは、ACK/NACK、CSI part1及びCSI part2のそれぞれのActual RE数（Q'ACK、Q'CSI-1及びQ'CSI-2）のトータルのRE数を示す。
【数９】
2019216073.tif 000011
【０２２６】
よって、端末４００は、UCIに要求される品質を満たすためのUCIのRE数をPUSCHに配置できない場合（Q'UCI（Actual RE数） < Q"UCI（Required RE数）の場合）でも、ΔUCIの適用により、不足したRE数に応じたパワーブーストを適用できる。例えば、Q"UCIに対してQ'UCIが小さいほど、ΔUCIが大きくなり、送信電力計算部４０２は、PUSCHに対してより大きな送信電力を設定する。
【０２２７】
これにより、本実施の形態では、URLLC用UCIに応じて、PUSCHの送信電力を制御できるので、UCI（特に、URLLC用UCI）を含むPUSCHの送信電力を適切にパワーブーストすることができる。
【０２２８】
なお、本実施の形態において、端末４００がUCIをPUSCHで送信しない場合、式（６）において、ΔUCIは非適用（ΔUCI=0[dB]）とすればよい。
【０２２９】
また、本実施の形態は、Grant-free送信を行うPUSCHでURLLC用UCIを送信する場合の送信電力の設定方法にも同様に適用できる。
【０２３０】
また、本実施の形態は、URLLC用UCIが含まれる場合にのみΔUCIを適用し、URLLC用UCIが含まれない場合はΔUCIは非適用（ΔUCI=0[dB]）としてもよい。または、UCIのサービス種別に依らず（URLLC用UCIとeMBB用UCIに依らず）、ΔUCIを適用してもよい。
【０２３１】
以上、本開示の各実施の形態について説明した。
【０２３２】
（１）サービス種別又はトラフィック種別（例えば、URLLC及びeMBBの何れかを示す情報）をUL grantに含めてもよい。この場合、基地局２００はUL grantを用いてスケジューリングされたPUSCHのサービス種別を端末１００へ容易に指示でき、端末１００はサービス種別に適したPC parameter setを用いてPUSCHを送信できる。
【０２３３】
（２）上記実施の形態では、UL grantに関する所定の条件に応じてPC parameter set（例えば、PC parameter set番号j）を変更する場合について説明した。しかし、本実施の形態では、PC parameter set番号j以外のPCパラメータ（例えば、PL推定用RS番号qd、Closed loop process番号ｌ）についても、UL grantに関する所定の条件に応じて変更してもよい。
【０２３４】
例えば、UL grantに関する所定の条件に応じてURLLCとeMBBとの間で異なるClosed loop process（番号l）が設定されてもよい。また、UL grantに関する所定の条件に応じてURLLCとeMBBとの間で異なるClosed loop補正値が設定されてもよい。例えば、DCIに含まれるClosed loop補正値が2bits（4パターン）の場合、eMBBに対して{+3, -1, 0, +1}、URLLCに対して{+6, -2, 0, +2}のように、URLLCの方がeMBBよりも大きい補正値を適用してもよい。この場合、端末１００は、サービス種別の要求品質に応じたClosed loop送信電力制御を行うことができる。また、UL grantに関する所定の条件に応じて設定するパラメータは、Closed loop processに限らず、他のパラメータでもよい。
【０２３５】
（３）上記実施の形態では、PUSCHの送信電力制御について説明した。しかし、本開示の一実施例は、PUSCH以外の上りチャネル（例えば、PUCCH（Physical Uplink Control Channel））にも適用できる。
【０２３６】
PUCCHの送信電力制御は、例えば、以下の式（１０）に従って行われる（例えば、非特許文献３を参照）。
【数１０】
2019216073.tif 000012
【０２３７】
式（１０）において、PPUCCH,b,f,c(i, qu, qd, l)は、UL BWP（Bandwidth part）番号"b"、Carrier番号"f"、サービングセル番号"c"、Slot番号"i"、PC parameter番号"qu"、PL推定用RS番号"qd"、Closed loop process番号"l"におけるPUCCHの送信電力[dBm]を示す。PO_PUCCH,b,f,c(qu)は、PC parameter番号quの目標受信電力[dBm]（Parameter値）を示す。2μ・MRB,b,f,cPUCCH(i)は、Slot番号iにおけるPUCCHに適用するSCSを、15kHz SCSを基準に正規化したPUCCHの送信帯域幅[PRB]を示す。PLb,f,c(qd)は端末がRS番号qdのRSから測定したパスロス（Path Loss）[dB]を示す。ΔF_PUCCH(F)は、PUCCH formatに依存したオフセット[dB]を示す。ΔTF,b,f,c(i)はSlot番号iにおいて送信するデータのMCSに依存したオフセット[dB]を示す。gb,f,c(i,l)はSlot番号i、Closed loop process番号lにおけるClosed loop補正値[dB]を示す。
【０２３８】
例えば、下りデータチャネル（PDSCH：Physical Downlink Shared Channel）に対するACK/NACKを送信するためのPUCCHであれば、PDSCHのMAC-CE情報（詳細にはPUCCH-Spatial-relation-info）を用いて、PC parameter番号quが基地局２００から端末１００へ指示できる。しかしながら、SR送信を行うためのPUCCHについては、付随するPDSCHが無いため、基地局２００から端末１００への明示的なPC parameter値の指示はない。
【０２３９】
このようなPC parameter値の明示的な指示がないPUCCH送信に関しては、上記実施の形態と同様に、端末１００は、UL grantに関する所定の条件に応じてPC parameter値（例えば、PC parameter番号qu）を切り替えることができる。例えば、URLLC用SR送信を行うPUCCHに対して、URLLC以外のサービス種別のSR送信と比較して、より高い送信電力値となるPC parameter値が設定されてもよい。これにより、URLLC用SRを高品質に送信することができ、URLLCの要求を満たすことができる。このようにして、PUCCH送信についても、PUSCH送信と同様の効果が得られる。
【０２４０】
（４）本実施の形態において、信頼性又は低遅延性等の要求条件の異なるサービス種別（換言すると、サービス、トラフィック種別、ロジカルチャネル(Logical channel)種別、ユースケース又はusage scenario）は、URLLC又はeMBBに限定されない。例えば、mMTCの送信にも本開示の一実施例を適用でき、同様の効果を得ることができる。
【０２４１】
（５）本開示はソフトウェア、ハードウェア、又は、ハードウェアと連携したソフトウェアで実現することが可能である。上記実施の形態の説明に用いた各機能ブロックは、部分的に又は全体的に、集積回路であるＬＳＩとして実現され、上記実施の形態で説明した各プロセスは、部分的に又は全体的に、一つのＬＳＩ又はＬＳＩの組み合わせによって制御されてもよい。ＬＳＩは個々のチップから構成されてもよいし、機能ブロックの一部または全てを含むように一つのチップから構成されてもよい。ＬＳＩはデータの入力と出力を備えてもよい。ＬＳＩは、集積度の違いにより、ＩＣ、システムＬＳＩ、スーパーＬＳＩ、ウルトラＬＳＩと呼称されることもある。集積回路化の手法はＬＳＩに限るものではなく、専用回路、汎用プロセッサ又は専用プロセッサで実現してもよい。また、ＬＳＩ製造後に、プログラムすることが可能なＦＰＧＡ（Field Programmable Gate Array）や、ＬＳＩ内部の回路セルの接続や設定を再構成可能なリコンフィギュラブル・プロセッサを利用してもよい。本開示は、デジタル処理又はアナログ処理として実現されてもよい。さらには、半導体技術の進歩または派生する別技術によりＬＳＩに置き換わる集積回路化の技術が登場すれば、当然、その技術を用いて機能ブロックの集積化を行ってもよい。バイオ技術の適用等が可能性としてありえる。
【０２４２】
本開示は、通信機能を持つあらゆる種類の装置、デバイス、システム（通信装置と総称）において実施可能である。通信装置の、非限定的な例としては、電話機（携帯電話、スマートフォン等）、タブレット、パーソナル・コンピューター（ＰＣ）（ラップトップ、デスクトップ、ノートブック等）、カメラ（デジタル・スチル／ビデオ・カメラ等）、デジタル・プレーヤー（デジタル・オーディオ／ビデオ・プレーヤー等）、着用可能なデバイス（ウェアラブル・カメラ、スマートウオッチ、トラッキングデバイス等）、ゲーム・コンソール、デジタル・ブック・リーダー、テレヘルス・テレメディシン（遠隔ヘルスケア・メディシン処方）デバイス、通信機能付きの乗り物又は移動輸送機関（自動車、飛行機、船等）、及び上述の各種装置の組み合わせがあげられる。
【０２４３】
通信装置は、持ち運び可能又は移動可能なものに限定されず、持ち運びできない又は固定されている、あらゆる種類の装置、デバイス、システム、例えば、スマート・ホーム・デバイス（家電機器、照明機器、スマートメーター又は計測機器、コントロール・パネル等）、自動販売機、その他ＩｏＴ（Ｉｎｔｅｒｎｅｔ  ｏｆ  Ｔｈｉｎｇｓ）ネットワーク上に存在し得るあらゆる「モノ（Things）」をも含む。
【０２４４】
通信には、セルラーシステム、無線ＬＡＮシステム、通信衛星システム等によるデータ通信に加え、これらの組み合わせによるデータ通信も含まれる。
【０２４５】
また、通信装置には、本開示に記載される通信機能を実行する通信デバイスに接続又は連結される、コントローラやセンサー等のデバイスも含まれる。例えば、通信装置の通信機能を実行する通信デバイスが使用する制御信号やデータ信号を生成するような、コントローラやセンサーが含まれる。
【０２４６】
また、通信装置には、上記の非限定的な各種装置と通信を行う、あるいはこれら各種装置を制御する、インフラストラクチャ設備、例えば、基地局、アクセスポイント、その他あらゆる装置、デバイス、システムが含まれる。
【０２４７】
本開示の端末は、上りリンク信号の割当情報の送信に使用される制御チャネルに関する所定の条件を満たす場合、第１のサービスに対応する第１の電力制御パラメータを設定し、前記所定の条件を満たさない場合、第２のサービスに対応する第２の電力制御パラメータを設定する回路と、前記第１の電力制御パラメータ又は前記第２の電力制御パラメータを用いて計算された送信電力を用いて前記上りリンク信号を送信する送信回路と、を具備する。
【０２４８】
本開示の端末において、前記所定の条件は、前記制御チャネルに用いられるフォーマットのペイロードサイズが所定のサイズと異なることである。
【０２４９】
本開示の端末において、前記所定の条件は、前記制御チャネルに用いられるフォーマットのペイロードサイズが所定のサイズ未満であることである。
【０２５０】
本開示の端末において、前記所定の条件は、前記制御チャネルに用いられるスクランブリング系列が所定の系列と異なることである。
【０２５１】
本開示の端末において、前記所定の条件は、前記制御チャネルが、前記第１のサービスのスケジューリングを要求する信号を前記端末から送信した後の所定期間内に前記端末において受信する制御チャネルであることである。
【０２５２】
本開示の端末において、前記所定の条件は、前記制御チャネルが、前記第１のサービスのスケジューリングを要求する信号を前記端末から送信した後に前記端末が最初に受信する制御チャネルであることである。
【０２５３】
本開示の端末において、前記所定の条件は、前記制御チャネルが、前記上りリンク信号の初回送信に使用されるリソースが予め設定された送信方法における再送を示すことである。
【０２５４】
本開示の端末において、前記所定の条件は、前記端末が前記制御チャネルを受信してから前記上りリンク信号を送信するまでの期間が所定時間以内であることである。
【０２５５】
本開示の端末において、前記所定の条件は、前記制御チャネルに示される前記上りリンク信号の送信シンボル数が所定値以下であることである。
【０２５６】
本開示の端末において、前記所定の条件は、前記端末における前記制御チャネルの検出周期が所定値以下であることである。
【０２５７】
本開示の端末において、前記所定の条件は、前記制御チャネルに用いられる、符号化及び変調方式を示すテーブルが所定のテーブルと異なることである。
【０２５８】
本開示の端末において、前記所定の条件は、前記上りリンク信号に含まれる上りリンク制御情報が、前記第１のサービスの下りリンクデータに対する応答信号であることである。
【０２５９】
本開示の端末において、前記所定の条件は、前記端末が下りリンクデータを受信してから、当該下りリンクデータに対する応答信号を含む前記上りリンク信号を送信するまでの期間が所定時間以内であることである。
【０２６０】
本開示の端末において、前記所定の条件は、前記上りリンク信号に含まれる上りリンク制御情報が、所定の閾値以下の目標誤り率を用いて計算されたチャネル状態情報であることである。
【０２６１】
本開示の端末において、下りリンクデータ及び当該下りリンクデータに対する応答信号の全体の誤り率が一定の値であり、前記所定の条件は、前記上りリンク信号に含まれる上りリンク制御情報が、前記第２のサービスの下りリンクデータに対する応答信号であることである。
【０２６２】
本開示の端末において、前記所定の条件は、前記上りリンク信号に含まれる上りリンク制御情報のリソース数が所定の閾値以上であることである。
【０２６３】
本開示の端末において、前記所定の条件は、前記上りリンク信号全体のリソース数に対する、前記上りリンク信号に含まれる上りリンク制御情報のリソース数の割合が所定の閾値より大きいことである。
【０２６４】
本開示の端末において、前記第１の電力制御パラメータを用いて計算される前記送信電力は、前記第２の電力制御パラメータを用いて計算される前記送信電力より大きい。
【０２６５】
本開示の送信方法は、上りリンク信号の割当情報の送信に使用される制御チャネルに関する所定の条件を満たす場合、第１のサービスに対応する第１の電力制御パラメータを設定し、前記所定の条件を満たさない場合、第２のサービスに対応する第２の電力制御パラメータを設定し、前記第１の電力制御パラメータ又は前記第２の電力制御パラメータを用いて計算された送信電力を用いて前記上りリンク信号を送信する。
【０２６６】
２０１８年５月８日出願の特願２０１８−０９０１２０及び２０１８年７月１８日出願の特願２０１８−１３５０１１の日本出願に含まれる明細書、図面および要約書の開示内容は、すべて本願に援用される。
【産業上の利用可能性】
【０２６７】
本開示の一実施例は、移動通信システムに有用である。
【符号の説明】
【０２６８】
１００，３００，４００  端末
１０１，２０５  アンテナ
１０２，２０６  受信部
１０３，２０７  復調・復号部
１０４，３０４  PCパラメータ制御部
１０５，４０２  送信電力計算部
１０６  データ生成部
１０７，２０３，３０２  符号化・変調部
１０８  リソース割当部
１０９，２０４  送信部
２００  基地局
２０１  スケジューリング部
２０２  制御情報生成部
３０１，４０１  UCI生成部
３０３  多重部
【図１】
2019216073.tif 000013
【図２】
2019216073.tif 000014
【図３】
2019216073.tif 000015
【図４】
2019216073.tif 000016
【図５】
2019216073.tif 000017
【図６】
2019216073.tif 000018
【図７Ａ】
2019216073.tif 000019
【図７Ｂ】
2019216073.tif 000020
【図７Ｃ】
2019216073.tif 000021
【図８】
2019216073.tif 000022
【図９】
2019216073.tif 000023
【図１０】
2019216073.tif 000024
【図１１】
2019216073.tif 000025
【図１２】
2019216073.tif 000026
【図１３】
2019216073.tif 000027
【図１４】
2019216073.tif 000028
【国際調査報告】
2019216073.tif 000029
2019216073.tif 000030
2019216073.tif 000031
2019216073.tif 000032