▶ パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカの特許一覧
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】
(24)【登録日】2024-08-21
(45)【発行日】2024-08-29
(54)【発明の名称】基地局、通信方法及び集積回路
(51)【国際特許分類】
H04W 52/18 20090101AFI20240822BHJP
H04W 72/512 20230101ALI20240822BHJP
H04W 72/1268 20230101ALI20240822BHJP
H04W 72/23 20230101ALI20240822BHJP
H04B 1/04 20060101ALI20240822BHJP
【ＦＩ】
H04W52/18
H04W72/512
H04W72/1268
H04W72/23
H04B1/04 E
【請求項の数】
16
(21)【出願番号】P 2023113212
(22)【出願日】2023-07-10
(62)【分割の表示】P 2020518195の分割
【原出願日】2019-04-05
(65)【公開番号】P2023130459
(43)【公開日】2023-09-20
【審査請求日】2023-07-10
(31)【優先権主張番号】P 2018090120
(32)【優先日】2018-05-08
(33)【優先権主張国・地域又は機関】JP
(31)【優先権主張番号】P 2018135011
(32)【優先日】2018-07-18
(33)【優先権主張国・地域又は機関】JP
(73)【特許権者】
【識別番号】514136668
【氏名又は名称】パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカ
【氏名又は名称原語表記】Ｐａｎａｓｏｎｉｃ Ｉｎｔｅｌｌｅｃｔｕａｌ Ｐｒｏｐｅｒｔｙ Ｃｏｒｐｏｒａｔｉｏｎ ｏｆ Ａｍｅｒｉｃａ
(74)【代理人】
【識別番号】110002952
【氏名又は名称】弁理士法人鷲田国際特許事務所
(72)【発明者】
【氏名】岩井 敬
(72)【発明者】
【氏名】鈴木 秀俊
(72)【発明者】
【氏名】山本 哲矢
(72)【発明者】
【氏名】布目 知也
(72)【発明者】
【氏名】高田 智史
【審査官】桑原 聡一
(56)【参考文献】
【文献】Ericsson，URLLC specific power control，3GPP TSG RAN WG2 adhoc_2018_07_NR R2-1810061，2018年07月02日
【文献】Qualcomm Incorporated，Considerations on differentiating eMBB and URLLC，3GPP TSG RAN WG1 #93 R1-1807367，2018年05月21日
【文献】Ericsson，DCI Contents and Formats for URLLC，3GPP TSG RAN WG1 #93 R1-1806020，2018年05月21日
【文献】Panasonic，Discussion on uplink power control for NR URLLC，3GPP TSG RAN WG1 #93 R1-1806179，2018年05月21日
(58)【調査した分野】(Int.Cl.，ＤＢ名)
Ｈ０４Ｂ ７／２４－７／２６
Ｈ０４Ｗ ４／００－９９／００
Ｈ０４Ｂ １／０４
３ＧＰＰ ＴＳＧ ＲＡＮ ＷＧ１－４
ＳＡ ＷＧ１－４
ＣＴ ＷＧ１、４
(57)【特許請求の範囲】
【請求項1】
上りリンク信号の割当情報の送信に使用される制御チャネルであって、SRS resource indicator（SRI）fieldを含まない、かつ、サービス種別及び電力制御パラメータを明示的に示す情報を含まない前記制御チャネルを、端末に送信する送信部と、前記制御チャネルに関する所定の条件に応じて動的に設定された電力制御パラメータを用いて計算された送信電力で前記端末から送信された、前記上りリンク信号を受信する受信部と、
を具備する基地局。
【請求項2】
前記所定の条件は、前記制御チャネルに用いられるフォーマットのペイロードサイズが所定のサイズと異なることである、請求項１に記載の基地局。
【請求項3】
前記所定の条件は、前記制御チャネルに用いられるフォーマットのペイロードサイズが所定のサイズ未満であることである、請求項１に記載の基地局。
【請求項4】
前記所定の条件は、前記制御チャネルに用いられるスクランブリング系列が所定の系列と異なることである、請求項１に記載の基地局。
【請求項5】
前記所定の条件は、前記制御チャネルが、Ultra-Reliable and Low Latency Communications (URLLC)のスケジューリングを要求する信号を前記端末から送信した後の所定期間内に前記端末において受信する制御チャネルであることである、請求項１に記載の基地局。
【請求項6】
前記所定の条件は、前記制御チャネルが、Ultra-Reliable and Low Latency Communications (URLLC)のスケジューリングを要求する信号を前記端末から送信した後に前記端末が最初に受信する制御チャネルであることである、請求項１に記載の基地局。
【請求項7】
前記所定の条件は、前記制御チャネルが、前記上りリンク信号の初回送信に使用されるリソースが予め設定された送信方法における再送を示すことである、請求項１に記載の基地局。
【請求項8】
前記所定の条件は、前記端末が前記制御チャネルを受信してから前記上りリンク信号を送信するまでの期間が所定時間以内であることである、請求項１に記載の基地局。
【請求項9】
前記所定の条件は、前記制御チャネルに示される前記上りリンク信号の送信シンボル数が所定値以下であることである、請求項１に記載の基地局。
【請求項10】
前記所定の条件は、前記端末における前記制御チャネルの検出周期が所定値以下であることである、請求項１に記載の基地局。
【請求項11】
前記所定の条件は、前記制御チャネルに用いられる、符号化及び変調方式を示すテーブルが所定のテーブルと異なることである、請求項１に記載の基地局。
【請求項12】
前記所定の条件は、前記端末が下りリンクデータを受信してから、当該下りリンクデータに対する応答信号を含む前記上りリンク信号を送信するまでの期間が所定時間以内であることである、請求項１に記載の基地局。
【請求項13】
少なくとも２つの電力制御パラメータが予め設けられ、前記所定の条件に応じて、前記少なくとも２つの電力制御パラメータのうちの一つが設定される、請求項１に記載の基地局。
【請求項14】
前記サービス種別は、Ultra-Reliable and Low Latency Communications (URLLC)又はeMBBを含む、請求項１に記載の基地局。
【請求項15】
上りリンク信号の割当情報の送信に使用される制御チャネルであって、SRS resource indicator（SRI）fieldを含まない、かつ、サービス種別及び電力制御パラメータを明示的に示す情報を含まない前記制御チャネルを端末に送信する工程と、前記制御チャネルに関する所定の条件に応じて動的に設定された電力制御パラメータを用いて計算された送信電力で前記端末から送信された、前記上りリンク信号を受信する工程と、
を具備する通信方法。
【請求項16】
上りリンク信号の割当情報の送信に使用される制御チャネルであって、SRS resource indicator（SRI）fieldを含まない、かつ、サービス種別及び電力制御パラメータを明示的に示す情報を含まない前記制御チャネルを端末に送信する処理と、前記制御チャネルに関する所定の条件に応じて動的に設定された電力制御パラメータを用いて計算された送信電力で前記端末から送信された、前記上りリンク信号を受信する処理と、
を制御する集積回路。
【発明の詳細な説明】
【技術分野】
【0001】
本開示は、端末及び送信方法に関する。
【背景技術】
【0002】
5Gの標準化において、LTE/LTE-Advancedとは必ずしも後方互換性を持たない新しい無線アクセス技術（NR：New Radio access technology）が3GPPで議論されている。
【0003】
NRでは、5Gの要件の1つであるURLLC（Ultra-Reliable and Low Latency Communications：超高信頼低遅延通信）をターゲットとした技術検討が進められている。URLLCは、32バイトのパケットデータ量を10-5以下のパケット送信誤り率（99.999%以上のパケット送信成功率）の「高信頼」と、無線区間1ms以下の「低遅延」とを同時に満たすことが求められる（例えば、非特許文献１を参照）。
【0004】
上述したURLLCの要求条件を満たすために、URLLCデータの上りチャネル（PUSCH：Physical Uplink Shared Channel）の送信では、他のデータの上りチャネルと比較して高い送信電力（例えば、パワーブースト）を用いてURLLCデータを送信することが検討されている（例えば、非特許文献２を参照）。
【先行技術文献】
【非特許文献】
【0005】
【文献】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)
【発明の概要】
【発明が解決しようとする課題】
【0006】
しかしながら、URLLCのPUSCHを送信する方法については十分に検討されていない。
【0007】
本開示の非限定的な実施例は、上りリンク信号を適切に送信することができる端末及び送信方法の提供に資する。
【課題を解決するための手段】
【0008】
本開示の一実施例に係る端末は、上りリンク信号の割当情報の送信に使用される制御チャネルに関する所定の条件を満たす場合、第１のサービスに対応する第１の電力制御パラメータを設定し、前記所定の条件を満たさない場合、第２のサービスに対応する第２の電力制御パラメータを設定する回路と、前記第１の電力制御パラメータ又は前記第２の電力制御パラメータを用いて計算された送信電力を用いて前記上りリンク信号を送信する送信回路と、を具備する。
【0009】
本開示の一実施例に係る送信方法は、上りリンク信号の割当情報の送信に使用される制御チャネルに関する所定の条件を満たす場合、第１のサービスに対応する第１の電力制御パラメータを設定し、前記所定の条件を満たさない場合、第２のサービスに対応する第２の電力制御パラメータを設定し、前記第１の電力制御パラメータ又は前記第２の電力制御パラメータを用いて計算された送信電力を用いて前記上りリンク信号を送信する。
【0010】
なお、これらの包括的または具体的な態様は、システム、装置、方法、集積回路、コンピュータプログラム、または、記録媒体で実現されてもよく、システム、装置、方法、集積回路、コンピュータプログラムおよび記録媒体の任意な組み合わせで実現されてもよい。
【発明の効果】
【0011】
本開示の一実施例によれば、上りリンク信号を適切に送信することができる。
【0012】
本開示の一実施例における更なる利点および効果は、明細書および図面から明らかにされる。かかる利点および／または効果は、いくつかの実施形態並びに明細書および図面に記載された特徴によってそれぞれ提供されるが、１つまたはそれ以上の同一の特徴を得るために必ずしも全てが提供される必要はない。
【図面の簡単な説明】
【0013】
【図1】PC parameter setの一例を示す図
【図2】実施の形態１に係る端末の一部の構成例を示すブロック図
【図3】実施の形態１に係る端末の構成例を示すブロック図
【図4】実施の形態１に係る基地局の構成例を示すブロック図
【図5】実施の形態１に係る端末及び基地局の動作例を示すシーケンス図
【図6】実施の形態１に係るPC parameter set番号A, Bの設定例を示す図
【図7A】URLLC用MCSテーブルの一例を示す図
【図7B】eMBB用MCSテーブルの一例を示す図
【図7C】eMBB用MCSテーブルの一例を示す図
【図8】実施の形態１に係るPC parameter set番号A, Bの設定例を示す図
【図9】実施の形態１に係るURLLCとeMBBとの間において無線リソースが重なる例を示す図
【図10】実施の形態２に係る端末の構成例を示すブロック図
【図11】実施の形態２に係るPC parameter set番号の設定例を示す図
【図12】実施の形態２に係るPC parameter set番号の設定例を示す図
【図13】実施の形態２に係るPC parameter set番号の設定例を示す図
【図14】実施の形態３に係る端末の構成例を示すブロック図
【発明を実施するための形態】
【0014】
以下、本開示の実施の形態について図面を参照して詳細に説明する。
【0015】
NR向けの端末（「UE（User Equipment）」と呼ぶこともある）のPUSCHの送信電力制御（TPC：Transmission Power Control）は、例えば、以下の式（１）に従って行われる（例えば、非特許文献３を参照）。
【数1】
【0016】
式（１）において、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,c
PUSCH(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]を示す。
【0017】
式（１）において、PO_PUSCH,f,c(j)及びαf,c(j)は、「PC parameter set」と呼ばれる。例えば、図１に示すように、PC parameter set番号j毎のPC parameter setの値が、基地局（「eNB」又は「gNB」と呼ぶこともある）から端末へ、例えば、RRC（Radio Resource Control）通知によって予め設定される。
【0018】
URLLCデータの上り送信では、URLLCの信頼性に関する要求条件を満たすために、他のサービス種別（例えば、eMBB）と比較してより高い送信電力となるPC parameter set（PO_PUSCH,f,c(j)、αf,c(j)）を用いることが検討されている。例えば、URLLCデータにはパワーブーストが適用されることにより、URLLCデータをeMBBデータと比較してより高い送信電力で送信することが検討されている。
【0019】
PUSCHのスケジューリング情報（例えば、周波数リソース割当情報、時間リソース割当情報、又は、MCS等)は、DCI（Downlink Control Information)と呼ばれ、PDCCH（Physical Downlink Control Channel）を用いて基地局から端末へ送信される。なお、PUSCHのスケジューリング情報を指示するために使用されるPDCCHは「上りグラント(UL grant)」と呼ばれる。
【0020】
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サイズが小さい。
【0021】
また、URLLCデータ（URLLC用PUSCHと呼ぶこともある）のスケジューリング情報を指示するPDCCH（例えば、UL grant）も、URLLCデータと同等又はURLLCデータ以上に高信頼性及び低遅延が要求される。ここで、Payloadサイズが小さいほど、符号化利得がより大きくなり、信頼性を向上できる。そこで、フォールバック用DCI（例えば、DCI format 0_0）をURLLCデータのスケジューリング情報を指示するPDCCHのDCIフォーマットに用いることが検討されている（例えば、非特許文献５を参照）。
【0022】
例えば、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を端末へ明示的に指示できる。
【0023】
一方、フォールバック用DCI（例えば、DCI format 0_0）には、SRI fieldが含まれない。SRI fieldが含まれない場合、つまり、PC parameter set番号を明示的に指示する情報が含まれないUL grantが使用される場合、例えば、固定のPC parameter set値（例えば、j=0のPC parameter set値）が用いられる。
【0024】
この場合、端末では、URLLC及びeMBB等のサービス種別（トラフィック種別とも呼ばれる）に依らず、固定のPC parameter set値が適用されるため、サービス種別に適した上りチャネルの送信電力が設定できない。例えば、eMBB用のパラメータ値を固定のPC parameter set値に設定した場合、URLLCデータをスケジューリングする場合には送信電力不足となり、URLLCの要求品質を満たせない。一方、URLLC用のパラメータ値を固定のPC parameter set値に設定した場合、eMBBデータをスケジューリングする場合には過剰な送信電力となり、与干渉が増加し、システム性能が劣化する懸念がある。
【0025】
このように、例えば、PC parameter set番号を明示的に指示する情報を含まないUL grantにおいて、URLLC用PUSCHのパワーブーストを端末へ指示する方法については十分に議論されていない。
【0026】
そこで、本開示の一実施例では、URLLC及びeMBB等のサービス種別に適した上りチャネルの送信電力を適切に設定する方法について説明する。
【0027】
（実施の形態１）
［通信システムの概要］
本開示の一実施の形態に係る通信システムは、端末１００及び基地局２００を備える。端末１００は、基地局２００からのUL grantに含まれるDCIに基づいて所定の送信電力を用いてPUSCHを送信する。基地局２００は、UL grantを端末１００へ送信し、端末１００からのPUSCHを受信する。
［通信システムの概要］
本開示の一実施の形態に係る通信システムは、端末１００及び基地局２００を備える。端末１００は、基地局２００からのUL grantに含まれるDCIに基づいて所定の送信電力を用いてPUSCHを送信する。基地局２００は、UL grantを端末１００へ送信し、端末１００からのPUSCHを受信する。
【0028】
図２は本開示の実施の形態に係る端末１００の一部の構成を示すブロック図である。図２に示す端末１００において、PCパラメータ制御部１０４は、上りリンク信号の割り当ての送信に使用される制御チャネル（例えば、UL grant）に関する所定の条件を満たす場合、第１のサービス（例えば、URLLC）に対応する第１の電力制御パラメータを設定し、所定の条件を満たさない場合、第２のサービス（例えば、eMBB）に対応する第２の電力制御パラメータを設定する。送信部１０９は、第１の電力制御パラメータ又は第２の電力制御パラメータを用いて計算された送信電力を用いて上りリンク信号を送信する。
【0029】
［端末１００の構成］
図３は、本実施の形態に係る端末１００の構成例を示すブロック図である。
図３は、本実施の形態に係る端末１００の構成例を示すブロック図である。
【0030】
図３に示す端末１００は、アンテナ１０１、受信部１０２、復調・復号部１０３、PCパラメータ制御部１０４、送信電力計算部１０５、データ生成部１０６、符号化・変調部１０７、リソース割当部１０８、及び、送信部１０９を含む。
【0031】
受信部１０２は、基地局２００から送信された信号をアンテナ１０１を介して受信し、受信信号に対してダウンコンバート又はA/D(Analog-to-Digital)変換などの受信処理を行い、受信処理後の受信信号を復調・復号部１０３へ出力する。
【0032】
復調・復号部１０３は、受信部１０２から入力される受信信号に対して復調及び復号を行い、復号結果から、端末１００宛てのUL grant（PDCCH又はNR-PDCCH）を抽出（受信）し、抽出したUL grantに含まれる、PUSCHをスケジューリングするためのDCIを復号する。復調・復号部１０３は、復号後のDCIを、PCパラメータ制御部１０４、送信電力計算部１０５、符号化・変調部１０７及びリソース割当部１０８へ出力する。
【0033】
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を明示的に指示する情報は含まれていない。
【0034】
なお、全ての制御情報を含むDCIが端末１００に対して同時に通知される必要はない。例えば、一部のDCIはセル共通情報として、又は、準静的な通知情報として端末１００に通知されてもよい。また、一部のDCIは、例えば、システム共通情報としてスペックで規定され、基地局２００から端末１００に通知されなくてもよい。
【0035】
PCパラメータ制御部１０４は、復調・復号部１０３から入力されるDCIを用いて、スケジューリングされたPUSCHに適用するPC parameter set番号jを決定する。PCパラメータ制御部１０４は、決定したPC parameter set番号を送信電力計算部１０５へ出力する。
【0036】
例えば、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を設定する。
【0037】
なお、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を用いて計算される送信電力値より大きい。
【0038】
なお、PCパラメータ制御部１０４におけるPC parameter set番号の選択方法の詳細については後述する。
【0039】
送信電力計算部１０５は、復調・復号部１０３から入力されるDCIに含まれるClosed loop補正値の更新値（+1ｄB、－1dB等の制御値）、及び、PCパラメータ制御部１０４から入力されるPC parameter set番号jを用いて、例えば、式（１）に従って、slot番号iにおけるPUSCHの送信電力値を計算する。送信電力計算部１０５は、計算したPUSCHの送信電力値を送信部１０９へ出力する。
【0040】
なお、送信電力計算部１０５において、式（１）に示す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パラメータ制御部１０４から指示された値を設定する。
【0041】
データ生成部１０６は、端末１００が送信するデータを生成し、生成した送信データを符号化・変調部１０７へ出力する。
【0042】
符号化・変調部１０７は、復調・復号部１０３から入力されるDCIに基づいて、データ生成部１０６から入力される送信データに対して、符号化及び変調を行い、変調後のデータ信号をリソース割当部１０８へ出力する。
【0043】
リソース割当部１０８は、復調・復号部１０３から入力されるDCIに基づいて、符号化・変調部１０７から入力される変調後のデータ信号を、所定の無線リソース（例えば、周波数リソース及び時間リソース）に割り当てる。リソース割当部１０８は、リソース割当後の信号を送信部１０９に出力する。
【0044】
送信部１０９は、リソース割当部１０８から入力される信号に対してD/A(Digital-to-Analog)変換及びアップコンバート等の送信処理を行う。送信部１０９は、送信電力計算部１０５から入力される送信電力値を用いて、送信処理後の信号をアンテナ１０１を介して基地局２００へ送信する。
【0045】
［基地局２００の構成］
図４は、本実施の形態に係る基地局２００の構成例を示すブロック図である。
図４は、本実施の形態に係る基地局２００の構成例を示すブロック図である。
【0046】
図４に示す基地局２００は、スケジューリング部２０１、制御情報生成部２０２、符号化・変調部２０３、送信部２０４、アンテナ２０５、受信部２０６、及び、復調・復号部２０７を含む。
【0047】
スケジューリング部２０１は、端末１００のPUSCHに対する無線リソース割当情報（例えば、周波数リソース割当情報、時間リソース割当情報、MCS、送信電力情報など）を決定する。例えば、スケジューリング部２０１は、端末１００から所定のタイミングで通知される品質情報に基づいて無線リソース割当情報を決定してもよい。スケジューリング部２０１は、決定した無線リソース割当情報、及び、対応するサービス種別（例えば、URLLC又はeMBB）を、制御情報生成部２０２へ出力する。
【0048】
制御情報生成部２０２は、スケジューリング部２０１から入力される無線リソース割当情報及びサービス種別に基づいて、端末１００に通知するDCIを含むUL grantを生成する。制御情報生成部２０２は、生成したUL grantを符号化・変調部２０３へ出力する。ここで、UL grantは、例えば、Payloadサイズが小さいフォールバック用DCI（例えば、DCI format 0_0）であり、UL grantには、PC parameter set番号を明示的に指示する情報が含まれない。
【0049】
符号化・変調部２０３は、制御情報生成部２０２から入力されるUL grantを符号化及び変調して、変調後のUL grantを送信部２０４へ出力する。
【0050】
送信部２０４は、符号化・変調部２０３から入力される信号に対してD/A変換、アップコンバート、増幅等の送信処理を行い、送信後の信号をアンテナ２０５を介して端末１００へ送信する。
【0051】
受信部２０６は、アンテナ２０５を介して受信された、端末１００から送信されたPUSCHに対してダウンコンバート又はA/D変換などの受信処理を行い、受信処理後の受信信号を復調・復号部２０７へ出力する。
【0052】
復調・復号部２０７は、受信部２０６から入力される受信信号に対して、復調及び復号を行い、端末１００からの受信データを取得する。
【0053】
［基地局及び端末の動作］
以上の構成を有する端末１００及び基地局２００の動作について詳細に説明する。
以上の構成を有する端末１００及び基地局２００の動作について詳細に説明する。
【0054】
【0055】
基地局２００は、端末１００に対する上りリンク信号（例えば、PUSCH）に関する無線リソース割当情報を決定し、DCIを生成する（ＳＴ１０１）。基地局２００は、生成したDCIを含むUL grantを端末１００へ送信する（ＳＴ１０２）。
【0056】
端末１００は、基地局２００からのUL grantに含まれるDCIに示される無線リソース割当情報に基づいて、PUSCHの送信電力を計算する（ＳＴ１０３）。この際、端末１００は、UL grantに関する所定の条件を満たすか否かに応じて、URLLC用のPUSCHの送信電力を計算するためのPC parameter set番号jを決定する。
【0057】
端末１００は、計算した送信電力を用いて、PUSCHを基地局２００へ送信する（ＳＴ１０４）。
【0058】
［PC parameter setの選択方法］
次に、端末１００のPCパラメータ制御部１０４におけるPC parameter setの選択方法について説明する。
次に、端末１００のPCパラメータ制御部１０４におけるPC parameter setの選択方法について説明する。
【0059】
端末１００のPCパラメータ制御部１０４は、UL grantに関する所定の条件（詳細は後述する）を満たす場合、基地局２００からのUL grant（例えば、図５のＳＴ１０２を参照）が、URLLCデータをスケジューリングするUL grantであると判断し、URLLCに対応するPC parameter set番号j=AのPC parameter set値を設定する。
【0060】
一方、端末１００のPCパラメータ制御部１０４は、UL grantに関する所定の条件を満たさない場合、基地局２００からのUL grantが、URLLC以外の他のサービス種別のデータをスケジューリングするUL grantであると判断し、URLLC以外の他のサービス種別に対応するPC parameter set番号j=BのPC parameter set値を設定する。
【0061】
端末１００の送信電力計算部１０５は、設定したPC parameter set番号jを用いて、例えば、式（１）に従ってPUSCHの送信電力を計算する。
【0062】
以下、URLLCデータをスケジューリングするUL grantであるか否かを判断するための「所定の条件」の例について説明する。
【0063】
［例１：UL grantのPayloadサイズ］
例１では、所定の条件は、UL grantに用いられるDCI formatのPayloadサイズが所定のサイズと異なることである。または、例１では、所定の条件は、UL grantに用いられるDCI formatのPayloadサイズが所定のサイズ未満であることである。
例１では、所定の条件は、UL grantに用いられるDCI formatのPayloadサイズが所定のサイズと異なることである。または、例１では、所定の条件は、UL grantに用いられるDCI formatのPayloadサイズが所定のサイズ未満であることである。
【0064】
上述したように、URLLCデータをスケジューリングするUL grantのPayloadサイズが小さいほど、符号化利得がより大きくなり、信頼性を向上できる。よって、URLLCデータのスケジューリングに用いるUL grantには、Payloadサイズの小さいフォーマットが設定されることが考えられる。
【0065】
例えば、例１では、PCパラメータ制御部１０４は、基地局２００からのUL grantに用いられるDCI formatのPayloadサイズが所定のサイズと異なる場合、又は、所定のサイズ未満の場合、当該UL grantが、URLLCデータをスケジューリングするUL grantであると判断する。換言すると、PCパラメータ制御部１０４は、DCI formatのPayloadサイズが所定のサイズと異なる場合、又は、所定のサイズ未満の場合、当該UL grantによってスケジューリングされたPUSCHがURLLC用のPUSCH（URLLC PUSCH）であると判断する。
【0066】
例えば、端末１００が検出したUL grantのPayloadサイズが、eMBBを想定したPUSCH用UL grantに規定されているDCI format 0_0及びDCI format 0_1の双方のPayloadサイズと異なる場合、PCパラメータ制御部１０４は、当該UL grantがURLLC用PUSCHをスケジューリングするUL grantであると判断してもよい。
【0067】
または、端末１００が検出したUL grantのPayloadサイズが、フォールバック用DCIであるDCI format 0_0のPayloadサイズ未満の場合、PCパラメータ制御部１０４は、当該UL grantがURLLC用PUSCHをスケジューリングするUL grantであると判断してもよい。
【0068】
PCパラメータ制御部１０４は、UL grantがURLLC用PUSCHをスケジューリングするUL grantであると判断した場合、URLLCに対応するPC parameter set番号j=AのPC parameter setを選択する。
【0069】
一方、端末１００が検出した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を選択する。
【0070】
このように、例１では、UL grantに用いられるDCI formatのPayloadサイズに応じて、PC parameter set番号が基地局２００から端末１００へ暗黙的に通知される。
【0071】
［例２：UL grantで用いるスクランブリング系列］
例２では、所定の条件は、UL grantに用いられるスクランブリング系列が所定の系列と異なることである。
例２では、所定の条件は、UL grantに用いられるスクランブリング系列が所定の系列と異なることである。
【0072】
例えば、PCパラメータ制御部１０４は、UL grantのDCI formatで用いる端末固有のスクランブリング系列が所定の端末固有の系列と異なる場合、当該UL grantが、URLLCデータをスケジューリングするUL grantであると判断する。換言すると、PCパラメータ制御部１０４は、UL grantのDCI formatで用いる端末固有のスクランブリング系列が所定の端末固有の系列と異なる場合、当該UL grantによってスケジューリングされたPUSCHがURLLC用のPUSCH（URLLC PUSCH）であると判断する。
【0073】
例えば、eMBBを想定したPUSCH用UL grantに規定されているDCI format 0_0又はDCI format 0_1では、端末固有のスクランブリング系列に、C-RNTI（Cell - Radio Network Temporary Identifier）又はCS-RNTI（Configured Scheduling - RNTI）等が用いられる。
【0074】
例えば、端末１００が検出したUL grantで用いるスクランブリング系列がC-RNTI及びCS-RNTIと異なる場合、PCパラメータ制御部１０４は、当該UL grantがURLLC用PUSCHをスケジューリングするUL grantであると判断し、URLLCに対応するPC parameter set番号j=AのPC parameter setを選択する。
【0075】
一方、端末１００が検出したUL grantで用いるスクランブリング系列がC-RNTI又はCS-RNTIである場合、PCパラメータ制御部１０４は、当該UL grantがURLLC以外のサービス種別のデータをスケジューリングするUL grantであると判断し、URLLC以外のサービス種別に対応するPC parameter set番号j=BのPC parameter setを選択する。
【0076】
このように、例２では、UL grantに用いられるDCI formatのスクランブリング系列に応じて、PC parameter set番号が基地局２００から端末１００へ暗黙的に通知される。
【0077】
［例３：URLLC用SR（Scheduling Request）送信後のUL grant］
例３では、所定の条件は、UL grantが、URLLCのスケジューリングを要求するSR（URLLC用SR）を端末１００から送信した後に受信するUL grantであることである。
例３では、所定の条件は、UL grantが、URLLCのスケジューリングを要求するSR（URLLC用SR）を端末１００から送信した後に受信するUL grantであることである。
【0078】
ここで、「URLLC用SRを送信した後に受信するUL grant」とは、例えば、URLLC用SR送信してから所定期間X1[symbol]以内に受信したUL grantでもよく、URLLC用SR送信してから最初に受信したUL grantでもよい。
【0079】
また、URLLC用SRは、例えば、基地局２００からのSRリソース設定の際にURLLC用であることを明示的に示されてもよい。また、eMBBデータの送信中に発生するSR送信であって、緊急度又は優先度の高いSR送信をURLLC用SR送信と定義してもよい。または、スペックにおいてURLLC用SR送信のための無線リソースが定義されてもよい。または、基地局２００から設定されたSRリソースの周期が所定値X2[symbol]以下の場合、低遅延が要求されるURLLC用SRとして定義されてもよい。
【0080】
例えば、URLLC用SRを送信した後のUL grantを受信した場合、PCパラメータ制御部１０４は、当該UL grantがURLLC用PUSCHをスケジューリングするUL grantであると判断し、URLLCに対応するPC parameter set番号j=AのPC parameter setを選択する。
【0081】
一方、URLLC用SRを送信した後の上記所定の条件を満たさないUL grantを受信した場合、PCパラメータ制御部１０４は、当該UL grantがURLLC以外のサービス種別のデータをスケジューリングするUL grantであると判断し、URLLC以外のサービス種別に対応するPC parameter set番号j=BのPC parameter setを選択する。
【0082】
このように、例３では、URLLC用SR送信後に所定の条件を満たすUL grantを受信するか否かに応じて、PC parameter set番号が基地局２００から端末１００へ暗黙的に通知される。
【0083】
なお、上述した閾値X1、X2の値は、スペックにおいて予め規定されてもよく、基地局２００から端末１００へ設定されてもよい。
【0084】
［例４：Grant-free上り送信の再送を指示するUL grant］
例４では、所定の条件は、UL grantが、Grant-free上り送信（以下、単に「Grant-free送信」と呼ぶ）における再送を示すことである。
例４では、所定の条件は、UL grantが、Grant-free上り送信（以下、単に「Grant-free送信」と呼ぶ）における再送を示すことである。
【0085】
「Grant-free送信」とは、上りリンク信号の初回送信に使用される無線リソース（スケジューリング情報）が基地局２００から端末１００に予め設定されている送信方法である。Grant-free送信において、端末１００は、送信すべき送信データが発生した場合に、予め確保されている無線リソースを用いて送信データを送信する。
【0086】
Grant-free送信によれば、端末１００において送信データが発生してから、基地局２００へSRを送信し、基地局２００からのUL grantによってPUSCHをスケジューリングされるまでの時間を削減できる。このため、Grant-free送信は、低遅延が要求されるURLLC用の初期送信に用いることが想定される。
【0087】
なお、Grant-free送信の再送はUL grantによって指示される。
【0088】
例えば、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送信における再送であるか否かを判断してもよい。
【0089】
一方、Grant-free送信が適用されていない場合、又は、Grant-free送信の再送を指示するためのUL grantを受信していない場合、PCパラメータ制御部１０４は、当該UL grantがURLLC以外のサービス種別のデータをスケジューリングするUL grantであると判断し、URLLC以外のサービス種別に対応するPC parameter set番号j=BのPC parameter setを選択する。
【0090】
このように、例４では、UL grantによってGrant-free送信における再送が指示されるか否かに応じて、PC parameter set番号が基地局２００から端末１００へ暗黙的に通知される。
【0091】
なお、URLLC用Grant-free送信リソースと、URLLC以外のサービス種別（例えばeMBB）用Grant-free送信リソースとは、基地局２００による設定、又は、スペックでの規定によって区別されてもよい。
【0092】
例えば、Grant-free送信リソースを用いた上り送信時には、端末１００は、基地局２００から予め設定されたGrant-free送信用のPC parameter set値（UL grantベースの上り送信時に用いるPC parameter set（例えば、図１を参照）とは独立の固定値）を用いてもよい。また、URLLC用Grant-free送信リソースを定義する場合、URLLC用Grant-free送信リソースを用いた上り送信時と、URLLC以外のサービス種別用Grant-free送信リソースを用いた上り送信時とで、PC parameter set値を区別してもよい。
【0093】
これにより、Grant-free送信リソースを用いたURLLCの初期送信における上り送信電力制御を適切に行うことができる。
【0094】
また、Grant-free送信の再送を指示するためのUL grantは、例えば、CS-RNTIを用いてスクランブリングされてもよい。この場合、端末１００は、検出したUL grantがCS-RNTIでスクランブリングされる場合、当該UL grantでスケジューリングされたPUSCHがURLLC用であると判断してもよい。
【0095】
［例５：UL grantが指示するPUSCHの送信タイミング又は送信シンボル数］
例５では、所定の条件は、端末１００がUL grantを受信してから上りリンク信号を送信するまでの期間が所定時間以内であることである。または、所定の条件は、UL grantに示される上りリンク信号の送信シンボル数が所定値以下であることである。
例５では、所定の条件は、端末１００がUL grantを受信してから上りリンク信号を送信するまでの期間が所定時間以内であることである。または、所定の条件は、UL grantに示される上りリンク信号の送信シンボル数が所定値以下であることである。
【0096】
UL grantには、時間リソース情報（例えば、Time domain resource assignment field等）が含まれる。時間リソース情報には、UL grantを受信してからPUSCHを送信するまでの時間（例えば、PUSCH preparation time：N2とも呼ばれる）又はPUSCHのシンボル数（又は、時間長）が含まれる。URLLCデータがスケジューリングされる場合、低遅延の要求を満たすため、他のサービス種別と比較して、PUSCH preparation time又はシンボル長は短く設定される可能性が高い。
【0097】
例えば、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を選択する。
【0098】
または、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を選択する。
【0099】
このように、例５では、UL grantによって指示されるPUSCHの送信タイミング（又は送信シンボル数）に応じて、PC parameter set番号が基地局２００から端末１００へ暗黙的に通知される。
【0100】
［例６：UL grantの検出周期］
例６では、所定の条件は、端末１００におけるUL grantの検出周期が所定値以下であることである。
例６では、所定の条件は、端末１００におけるUL grantの検出周期が所定値以下であることである。
【0101】
UL grantを含む各DCI formatには、端末１００毎の所定の検出周期が基地局２００から設定される。URLLCデータがスケジューリングされる場合、低遅延の要求を満たすため、UL grantに対して短い検出周期が設定される可能性が高い。
【0102】
例えば、UL grantの検出周期がX5[symbol]以下の場合、PCパラメータ制御部１０４は、当該UL grantがURLLC用PUSCHをスケジューリングするUL grantであると判断し、PC parameter set番号j=AのPC parameter setを選択する。
【0103】
一方、UL grantの検出周期がX5[symbol]より長い場合、PCパラメータ制御部１０４は、当該UL grantがURLLC以外のサービス種別のPUSCHをスケジューリングするUL grantであると判断し、PC parameter set番号j=BのPC parameter setを選択する。
【0104】
このように、例６では、UL grantの検出周期に応じて、PC parameter set番号が基地局２００から端末１００へ暗黙的に通知される。
【0105】
［例７：UL grantで用いるMCS（Modulation and coding scheme）テーブル］
例７では、所定の条件は、UL grantに用いられるMCSテーブルが所定のMCSテーブルと異なることである。
例７では、所定の条件は、UL grantに用いられるMCSテーブルが所定のMCSテーブルと異なることである。
【0106】
NRでは、端末にMCS（符号化率及び変調方式）を指示するためにUL grantで用いるMCSテーブル（MCS番号と一意に対応するMCSのパターン表）には、「URLLC用MCSテーブル」と、「eMBB用MCSテーブル」とが定義されている。
【0107】
URLLC用MCSテーブルの一例を図７Ａに示し、eMBB用MCSテーブルの一例を図７Ｂ及び図７Ｃに示す（例えば、非特許文献６を参照）。図７Ａに示すURLLC用MCSテーブルは、図７Ｃに示すeMBB用MCSテーブルに含まれている256QAM(Modulation Order Qm = 8)が無く、図７Ｂ及び図７Ｃに示すeMBB用MCSテーブルよりコーディングレートが低いMCS（換言すると、Spectral efficiencyが低いMCS）が含まれる。
【0108】
例えば、DCI formatで用いる端末固有のスクランブリング系列（例えば、RNTI）、又は、PDCCHの割当リソースであるサーチスペースによって、端末１００がどのMCSテーブルを用いるかが予め決定される。
【0109】
例えば、PCパラメータ制御部１０４は、UL grantで用いるMCSテーブルがURLLC用MCSテーブルの場合、当該UL grantが、URLLCデータをスケジューリングするUL grantであると判断する。換言すると、PCパラメータ制御部１０４は、UL grantで用いるMCSテーブルがURLLC用MCSテーブルの場合、当該UL grantによってスケジューリングされたPUSCHがURLLC用のPUSCH（URLLC PUSCH）であると判断する。
【0110】
例えば、端末１００が検出したUL grantで用いるMCSテーブルがURLLC用MCSテーブルの場合、PCパラメータ制御部１０４は、当該UL grantがURLLC用PUSCHをスケジューリングするUL grantであると判断し、URLLCに対応するPC parameter set番号j=AのPC parameter setを選択する。
【0111】
一方、端末１００が検出した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を選択する。
【0112】
このように、例７では、UL grantに用いられるDCI formatのMCSテーブルに応じて、PC parameter set番号が基地局２００から端末１００へ暗黙的に通知される。
【0113】
以上、URLLCデータをスケジューリングするUL grantと判断できる「所定の条件」の例について説明した。
【0114】
なお、例１～例７において説明した所定の条件を複数組み合わせてもよい。
【0115】
［PC parameter set番号j=A、Bの設定例］
次に、PCパラメータ制御部１０４において設定されるPC parameter set番号j=A及びBの設定例について説明する。
次に、PCパラメータ制御部１０４において設定されるPC parameter set番号j=A及びBの設定例について説明する。
【0116】
例えば、URLLC PUSCHの送信電力は、少なくとも、URLLC以外のサービス種別（例えば、eMBB）のPUSCHの送信電力よりも大きく設定される。
【0117】
例えば、式（１）において、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)は大きくなる可能性が高い。
【0118】
そこで、例えば、図６に示すように、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)よりも大きくなる可能性が高い。
【0119】
なお、図６では、PC parameter set番号Aをｊの最大値J-1とし、PC parameter set番号Bをｊの最小値0とする場合について説明したが、PC parameter set番号A及びBは、これらの値に限定されない。例えば、PC parameter set番号Bが、PC parameter set番号Aより大きい値に設定されればよい。
【0120】
または、URLLC以外のサービス種別（例えば、eMBB）のPC parameter set番号Bに対して所定のオフセットΔを加えたPC parameter set番号を、URLLC用PC parameter set番号A（= B+Δ）としてもよい。
【0121】
または、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)＋Δでもよい。
【0122】
なお、端末１００が複数の送受信ポイント（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が設定されている。
【0123】
TRPが異なれば、パスロス等の伝搬環境が大きく異なる。このため、図８に示すように、各TRPに適したPC parameter setを定義し、選択可能としてもよい。これにより、端末１００は、PUSCHの送信電力をTRP毎に適切に設定できる。
【0124】
なお、図８に示すTRP毎のPC parameter setの設定は一例であり、これに限定されず、各TRPに対して、URLLC PUSCHの送信電力が、少なくとも、URLLC以外のサービス種別のPUSCHの送信電力よりも大きく設定されればよい。例えば、TRP#0及びTRP#1の伝搬環境によっては、TRP#0に対するURLLC用PC parameter set値が、URLLC以外のサービス種別のPC parameter set値より低く設定される場合もある。
【0125】
また、配置環境が異なる（換言すると、QCL（Quaisi-colocation）が異なる）複数アンテナパネルを持つ基地局２００と端末１００とが通信する場合、複数のTRPと端末１００とが通信する場合（例えば、図８を参照）と同様に、アンテナパネル毎にURLLC用PC parameter set番号AおよびURLLC以外のサービス種別のPC parameter set番号Bが定義されてもよい。
【0126】
なお、TRP番号およびアンテナパネル番号は、例えば、端末１００が受信した制御チャネル（例えば、PDCCH）が設定された制御チャネル用の送信リソース（例えば、CORESET（Control Resource Set）と呼ばれる）から判断できる。
【0127】
以上、PC parameter set番号j=A及びBの設定例について説明した。
【0128】
なお、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)の値は増加しなくてもよい。
【0129】
このように、本実施の形態では、端末１００は、UL grantに関する所定の条件を満たす場合、URLLCに対応するPC parameter set（電力制御パラメータ）を設定し、上記所定の条件を満たさない場合、URLLC以外のサービス種別に対応するPC parameter setを設定する。そして、端末１００は、設定したPC parameter setを用いて計算された送信電力を用いて上りリンク信号を送信する。
【0130】
これにより、URLLC用PUSCHの送信電力制御（例えば、パワーブースト）のパラメータ（例えば、PC parameter set）を基地局２００から端末１００へ暗黙的に通知できる。よって、PC parameter set番号を明示的に指示する情報（またはフィールド）を含まないUL grantでも、URLLC及びeMBB等のサービス種別に適した上りチャネルの送信電力を適切に設定できる。また、UL grantに新たな情報を追加する必要がないため、PDCCHのオーバーヘッドの増加を防止できる。
【0131】
よって、本実施の形態によれば、端末１００は、サービス種別に応じた上りチャネルの送信電力を用いて、上りリンク信号を適切に送信できる。
【0132】
ここで、URLLCの上り送信には低遅延が要求される。このため、図９に示すように、URLLCデータ（URLLC PUSCH）は、eMBBデータ（eMBB PUSCH）用に他の端末へ既に割り当てられた無線リソースに重ねてスケジューリングされる場合がある。また、URLLCは周波数ダイバーシチゲインを得るために広帯域の無線リソースを割り当てることが検討されている。このため、URLLCとeMBBとの間において無線リソース（例えば、時間リソース又は周波数リソース）の一部が重なることが想定される。
【0133】
このように、異なる端末（例えば、図９ではUE#0及びUE#1）からのeMBBデータとURLLCデータとの間において、上り送信用の無線リソースの一部又は全てが衝突する（重なる）場合でも、本実施の形態によれば、端末１００は、URLLCデータの上り送信において、基地局２００においてURLLCデータを復号可能な上り送信電力を適切に設定できる。このため、URLLCの低遅延及び高信頼性の要求仕様を満たすことができる。
【0134】
（実施の形態２）
本実施の形態では、URLLC用の上りリンク制御情報（以下、UCI（Uplink Control Information））をPUSCHで送信する（「UCIをPiggybackする」とも呼ばれる）場合のPUSCHの送信電力の設定方法について説明する。
本実施の形態では、URLLC用の上りリンク制御情報（以下、UCI（Uplink Control Information））をPUSCHで送信する（「UCIをPiggybackする」とも呼ばれる）場合のPUSCHの送信電力の設定方法について説明する。
【0135】
例えば、UCI送信用の上りチャネルであるPUCCHの送信タイミングが、PUSCHの送信タイミングと重なる場合、マルチキャリア送信によるPAPR（Peak to Average Power Ratio）の増加を避けるために、端末は、UCIを、UL-SCH（Uplink Shared Channel。上りデータ情報）と多重し、PUSCHで送信する（「UCIをPiggybackする」とも呼ばれる）。
【0136】
ここで、端末が、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））等が想定される（詳細は後述する）。
【0137】
しかしながら、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の要求品質を満たせない場合がある。
【0138】
そこで、本実施の形態では、PC parameter setの選択によって、UCI（特に、URLLC用UCI）を含むPUSCHの送信電力を適切にパワーブーストする方法について説明する。
【0139】
【0140】
［端末３００の構成］
図１０は、本実施の形態に係る端末３００の構成例を示すブロック図である。なお、図１０において実施の形態１の端末１００（図３）と同様の構成には同一の符号を付し、その説明を省略する。具体的には、図１０に示す端末３００では、図３に示す端末１００に対し、UCI生成部３０１、符号化・変調部３０２、及び、多重部３０３が追加され、かつ、PCパラメータ制御部３０４の動作が異なる。
図１０は、本実施の形態に係る端末３００の構成例を示すブロック図である。なお、図１０において実施の形態１の端末１００（図３）と同様の構成には同一の符号を付し、その説明を省略する。具体的には、図１０に示す端末３００では、図３に示す端末１００に対し、UCI生成部３０１、符号化・変調部３０２、及び、多重部３０３が追加され、かつ、PCパラメータ制御部３０４の動作が異なる。
【0141】
UCI生成部３０１は、端末３００が送信するUCI（ACK/NACKあるいはCSI等の上りリンク制御情報）を生成し、生成したUCIを符号化・変調部３０２へ出力する。また、UCI生成部３０１は、送信するUCIに関する情報をPCパラメータ制御部３０４へ出力する。
【0142】
符号化・変調部３０２は、復調・復号部１０３から入力されるDCIに基づいて、UCI生成部３０１から入力されるUCIに対して、符号化及び変調を行い、変調後のUCI信号を多重部３０３へ出力する。
【0143】
多重部３０３は、符号化・変調部３０２から入力されるUCI信号と、符号化・変調部１０７から入力される変調後のデータ信号とを多重し、多重後のデータ信号をリソース割当部１０８へ出力する。多重部３０３は、UCIとデータ信号との多重方法として、例えば、データ信号の一部のRE（Resource Element）をパンクチャし、パンクチャした部分にUCI信号を入れてもよい。あるいは、多重部３０３は、UCI信号のREサイズを予め考慮し、データ信号のREサイズを決定（レートマッチ）してもよい。
【0144】
PCパラメータ制御部３０４は、復調・復号部１０３から入力されるDCIと、UCI生成部３０１から入力されるUCIに関する情報とを用いて、スケジューリングされたPUSCHに適用するPC parameter set番号jを決定する。PCパラメータ制御部３０４は、決定したPC parameter set番号を送信電力計算部１０５へ出力する。
【0145】
［基地局の構成］
本実施の形態に係る基地局は、実施の形態１に係る基地局２００と基本構成が共通するので、図４を援用して説明する。なお、本実施の形態に係る基地局２００における復号後の受信データには、端末３００（図１０を参照）からのデータに加えてUCIが含まれる。
本実施の形態に係る基地局は、実施の形態１に係る基地局２００と基本構成が共通するので、図４を援用して説明する。なお、本実施の形態に係る基地局２００における復号後の受信データには、端末３００（図１０を参照）からのデータに加えてUCIが含まれる。
【0146】
以下、UCI（特に、URLLC用UCI）を含む（多重する、あるいは、Piggybackする）PUSCHについて、PC parameter setの変更による送信電力のパワーブーストを適応する「所定の条件」の例について説明する。
【0147】
［例１：URLLC用PDSCH（下りデータチャネル）に対するACK/NACKを含む］
例１では、所定条件は、UL grantでスケジューリングするPUSCHに含まれるUCIがURLLC用PDSCHに対するACK/NACK（応答信号）であることである。URLLC用PDSCHに対するACK/NACKは、URLLC用PDSCHと同様に低遅延及び高信頼性が求められることが考えられる。
例１では、所定条件は、UL grantでスケジューリングするPUSCHに含まれるUCIがURLLC用PDSCHに対するACK/NACK（応答信号）であることである。URLLC用PDSCHに対するACK/NACKは、URLLC用PDSCHと同様に低遅延及び高信頼性が求められることが考えられる。
【0148】
なお、端末３００は、PDSCHをスケジューリングするDCIで用いるスクランブリング系列（例えば、RNTI）が所定の系列（例えば、eMBB用PDSCHをスケジューリングするC-RNTIあるいはCS-RNTI）と異なる場合に、当該PDSCHがURLLC用PDSCHであることを判断できる。例えば、端末３００は、PDSCHをスケジューリングするDCIで用いるスクランブリング系列がURLLC用のRNTIである場合に、当該PDSCHがURLLC用PDSCHであることを判断してもよい。
【0149】
あるいは、端末３００は、PDSCHをスケジューリングするDCIでURLLC用MCSテーブルを用いる場合に、当該PDSCHがURLLC用PDSCHであることを判断できる。
【0150】
例えば、端末３００が検出したUL grantでスケジューリングするPUSCHに、URLLC用PDSCHに対するACK/NACKが含まれる場合、PCパラメータ制御部３０４は、当該UL grantがURLLC用UCIを含むPUSCHをスケジューリングするUL grantであると判断し、URLLCに対応するPC parameter set番号j=AのPC parameter setを選択する。
【0151】
一方、端末３００が検出したUL grantでスケジューリングするPUSCHに、URLLC用PDSCHに対するACK/NACKが含まれない場合、PCパラメータ制御部３０４は、当該UL grantがURLLC用UCIを含まないPUSCHをスケジューリングするUL grantであると判断し、URLLC以外のサービス種別に対応するPC parameter set番号j=BのPC parameter setを選択する。
【0152】
このように、例１では、UL grantでスケジューリングするPUSCHに、URLLC用PDSCHに対するACK/NACKが含まれるか否かに応じて、PC parameter set番号が基地局２００から端末３００へ暗黙的に通知される。
【0153】
［例２：PDSCH受信からACK/NACK送信までの時間間隔が所定の閾値以下のACK/NACK］
例２では、所定条件は、UL grantでスケジューリングするPUSCHに含まれるUCIが、PDSCH受信からACK/NACK送信までの時間間隔（例えば、N1[symbol]と呼ばれることもある）が所定の閾値X6[symbol]以下のACK/NACKであることである。例えば、N1は、PDSCHをスケジューリングするDCIに含まれる。
例２では、所定条件は、UL grantでスケジューリングするPUSCHに含まれるUCIが、PDSCH受信からACK/NACK送信までの時間間隔（例えば、N1[symbol]と呼ばれることもある）が所定の閾値X6[symbol]以下のACK/NACKであることである。例えば、N1は、PDSCHをスケジューリングするDCIに含まれる。
【0154】
換言すると、所定の条件は、端末３００がPDSCHを受信してから、当該PDSCHに対するACK/NACKを含むUCIを送信するまでの期間N1［symbol］が所定時間X6以内であることである。
【0155】
端末３００は、N1が短い場合（換言すると、N1≦X6の場合）、UL grantでスケジューリングされたPUSCHに含まれるUCIが、低遅延が要求されるURLLC用UCIであると判断できる。
【0156】
例えば、端末３００が検出した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を選択する。
【0157】
一方、上記以外の場合（例えば、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を選択する。
【0158】
このように、例２では、UL grantでスケジューリングするPUSCHに、N1が短いACK/NACKが含まれるか否かに応じて、PC parameter set番号が基地局２００から端末３００へ暗黙的に通知される。
【0159】
［例３：所定の閾値以下の目標BLERで計算されたたCSI］
例３では、所定条件は、UL grantでスケジューリングするPUSCHに含まれるUCIが、所定閾値X7以下の目標誤り率（例えば、目標BLER）を用いて計算されたCSIであることである。
例３では、所定条件は、UL grantでスケジューリングするPUSCHに含まれるUCIが、所定閾値X7以下の目標誤り率（例えば、目標BLER）を用いて計算されたCSIであることである。
【0160】
CSI計算に用いる目標BLERは、基地局３００から端末２００に予め設定される。端末３００は、閾値X7以下の低い目標BLER（例えば、目標BLER=10E-5）で計算されたCSIが、URLLC用UCIであると判断できる。
【0161】
例えば、端末３００が検出した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を選択する。
【0162】
一方、上記以外の場合（例えば、PUSCHに、閾値X7より大きい目標BLER（例えば、目標BLER=10E-1）で計算されたCSIが含まれる場合）、PCパラメータ制御部３０４は、当該UL grantがURLLC用UCIを含まないPUSCHをスケジューリングするUL grantであると判断し、URLLC以外のサービス種別に対応するPC parameter set番号j=BのPC parameter setを選択する。
【0163】
このように、例３では、UL grantでスケジューリングするPUSCHに、所定閾値X7以下の目標BLERで計算されたCSIが含まれるか否かに応じて、PC parameter set番号が基地局２００から端末３００へ暗黙的に通知される。
【0164】
［例４：eMBB用PDSCHに対するACK/NACKを含む］
例４では、所定条件は、UL grantでスケジューリングするPUSCHに含まれるUCIがeMBB用PDSCHに対するACK/NACKであることである。つまり、本実施の形態に係る例１の条件（URLLC用PDSCHに対するACK/NACKであること）と逆の条件となる。
例４では、所定条件は、UL grantでスケジューリングするPUSCHに含まれるUCIがeMBB用PDSCHに対するACK/NACKであることである。つまり、本実施の形態に係る例１の条件（URLLC用PDSCHに対するACK/NACKであること）と逆の条件となる。
【0165】
例えば、低遅延の優先度が低く、高信頼性の優先度がより高いサービスをスケジューリングする場合、基地局２００は、PDSCH、及び、当該PDSCHに対するACK/NACKのそれぞれの誤り率を乗算したトータルの誤り率が所定の品質になるように制御することが考えられる。
【0166】
例えば、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相当の品質）になるように制御する。
【0167】
換言すると、誤り率が10E-1になるように制御されたPDSCH（eMBB用PDSCH）に対するACK/NACKは、誤り率が10E-5になるように制御されたURLLC用UCIである。一方、誤り率が10E-5になるように制御されたPDSCH（URLLC用PDSCH）に対するACK/NACKは、誤り率が10E-1になるように制御されたeMBB用UCIである。
【0168】
よって、基地局２００が上記のように制御する場合、例えば、端末３００が検出した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を選択する。
【0169】
一方、上記以外の場合には、PCパラメータ制御部３０４は、当該UL grantがURLLC用UCIを含まないPUSCH（例えば、eMBB用UCIを含むPUSCH）をスケジューリングするUL grantであると判断し、URLLC以外のサービス種別に対応するPC parameter set番号j=BのPC parameter setを選択する。
【0170】
このように、例４では、UL grantでスケジューリングするPUSCHにeMBB用PDSCHに対するACK/NACKが含まれるか否かに応じて、PC parameter set番号が基地局２００から端末３００へ暗黙的に通知される。
【0171】
なお、本実施の形態に係る例１と例４とで、PC parameter set値の制御方法が逆になるが、基地局２００が想定するスケジューリング方法に応じて適切な制御方法が選択されればよい。
【0172】
［例５：URLLC用UCIに要求されるRE数が上限に達する］
例５では、所定条件は、UL grantでスケジューリングするPUSCHに、本実施の形態に係る例１～４の何れかに当てはまるURLLC用UCIが含まれ（Piggybackされ）、当該URLLC用UCIに要求されるRE数がPUSCHに配置可能なRE数の上限に達することである。
例５では、所定条件は、UL grantでスケジューリングするPUSCHに、本実施の形態に係る例１～４の何れかに当てはまるURLLC用UCIが含まれ（Piggybackされ）、当該URLLC用UCIに要求されるRE数がPUSCHに配置可能なRE数の上限に達することである。
【0173】
NRでは、例えば、ACK/NACKの場合、以下の式（２）に従って、PUSCHに配置できるUCIのRE数が決定される。
【数2】
【0174】
ここで、Q'ACKは実際にPUSCHで送信するACK/NACKのRE数（Actual RE数と呼ぶ）、OACKはACK/NACKビット数、LACKはCRC（Cyclic Redundancy Check）ビット数、βoffset
PUSCHはデータ(UL-SCH)に対するACK/NACKの符号化率の補正係数（パラメータ）、ΣMSC
UCI(l)（ただし、l=0～（Nsymb,all
PUSCH-1））はPUSCHの送信に用いるRE数、ΣKr（ただし、r=0～CUL-SCH-1）はPUSCHで送信するデータ(UL-SCH)のビット数を示す。また、αはPUSCHで送信するUCI（ACK/NACK）のRE数の割合を示す。換言すると、αは、UL-SCHの品質を確保するためにUCIのRE数の上限を決めるパラメータである。
【0175】
ここで、式（２）のmin関数の左辺（以下の式（３）のようにQ"ACKとおく）は、ACK/NACKに要求される品質を得るためにPUSCHの送信に用いるRE数（Required RE数と呼ぶ）を示す。
【数3】
【0176】
URLLC用UCIに要求されるRE数（Required RE数）が上限に達する場合、つまり、αによってRE数が制限され、Q'ACK＜Q"ACKとなる場合、端末３００は、要求される品質を満たすためのRE数のUCIをPUSCHに配置できない。
【0177】
そこで、URLLC用UCIに要求されるRE数がPUSCHに配置できるRE数の上限に達する場合（つまり、Q'ACK＜Q"ACKとなる場合）、PCパラメータ制御部３０４は、URLLC用UCIの品質を改善するため、URLLCに対応するPC parameter set番号j=AのPC parameter setを選択する。
【0178】
一方、URLLC用UCIに要求されるRE数がPUSCHに配置できるRE数の上限に達していない場合（つまり、Q'ACK≧Q"ACKとなる場合）、PCパラメータ制御部３０４は、パワーブーストする必要無しと判断し、URLLC以外のサービス種別に対応するPC parameter set番号j=BのPC parameter setを選択する。
【0179】
このように、例５では、UL grantでスケジューリングするPUSCHに含まれるURLLC用UCI
に要求されるRE数がPUSCHに配置できるRE数の上限に達するか否かに応じて、PC parameter set番号が基地局２００から端末３００へ暗黙的に通知される。
に要求されるRE数がPUSCHに配置できるRE数の上限に達するか否かに応じて、PC parameter set番号が基地局２００から端末３００へ暗黙的に通知される。
【0180】
なお、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を選択する。
【0181】
［例６：URLLC用UCIを含むUCIのRE数が所定割合より大きい］
例６では、所定条件は、UL grantでスケジューリングするPUSCHに、本実施の形態に係る例１～４の何れかに当てはまるURLLC用UCIが含まれ、PUSCH全体において、当該URLLC用UCIを含むUCIのRE数が所定割合より大きいことである。
例６では、所定条件は、UL grantでスケジューリングするPUSCHに、本実施の形態に係る例１～４の何れかに当てはまるURLLC用UCIが含まれ、PUSCH全体において、当該URLLC用UCIを含むUCIのRE数が所定割合より大きいことである。
【0182】
例えば、端末３００は、以下の式（４）に示す条件を満たす場合にPUSCHをパワーブーストする。
【数4】
【0183】
ここで、Q'ACK、Q'CSI-1、Q'CSI-2はそれぞれ、実際にPUSCHで送信するACK/NACK、CSI part1及びCSI part2のRE数（Actual RE数）を示す。また、ΣMSC
UCI(l)（ただし、l=0～（Nsymb,all
PUSCH-1））はPUSCHの送信に用いるRE数、γはPUSCHで送信するURLLC用UCIを含むUCI（ACK/NACKとCSIを含めたトータルのUCI）のRE数の上限の割合である。例えば、PUSCH全体のRE数に対する、UCIのRE数の割合が、この割合γを超える場合、PUSCHの中において、UCIがUL-SCHよりも支配的であると想定される。
【0184】
例えば、URLLC用UCIを含むUCIのトータルのRequired RE数が上限に達する場合、つまり、式（４）の条件が成り立つ場合、PCパラメータ制御部３０４は、PUSCHの中でUCIがUL-SCHに比べて支配的と判断し、URLLCに対応するPC parameter set番号j=AのPC parameter setを選択する。
【0185】
一方、URLLC用UCIを含むUCIのトータルのRequired RE数が上限に達していない場合、つまり、式（４）の条件が成り立たない場合、PCパラメータ制御部３０４は、PUSCHの中でUL-SCHがUCIに比べて支配的と判断し、URLLC以外のサービス種別に対応するPC parameter set番号j=BのPC parameter setを選択する。
【0186】
このように、例６では、PUSCHの中でUCIがUL-SCHに比べて支配的か否かに応じて、PC parameter set番号が基地局２００から端末３００へ暗黙的に通知される。
【0187】
なお、以下の式（５）のように、PUSCHで送信するUCIのRE数の上限値（RE数）を示すδが定義されてもよい。つまり、端末３００は、式（５）の条件が成り立つ場合、PUSCHの中でUCIがUL-SCHに比べて支配的と判断し、URLLCに対応するPC parameter set番号j=AのPC parameter setを選択する。これにより、式（４）に示す割合γを用いた制御と同様の効果が得られる。
【数5】
【0188】
以上、UCIを含むPUSCHについて、PC parameter setの変更による送信電力のパワーブーストを適応する「所定の条件」の例について説明した。
【0189】
なお、例１～例６において説明した所定の条件を複数組み合わせてもよい。
【0190】
［PC parameter setの選択方法］
次に、端末３００のPCパラメータ制御部３０４における、PUSCHにUCIが含まれる場合のPC parameter setの選択方法について説明する。
次に、端末３００のPCパラメータ制御部３０４における、PUSCHにUCIが含まれる場合のPC parameter setの選択方法について説明する。
【0191】
［例１：URLLC用UCIのUCI type毎のPC parameter setの選択］
例１では、PCパラメータ制御部３０４は、URLLC用UCIのUCI type（例えば、ACK/NACK、CSI part1又はCSI part2等）毎にPC parameter setを選択する。
例１では、PCパラメータ制御部３０４は、URLLC用UCIのUCI type（例えば、ACK/NACK、CSI part1又はCSI part2等）毎にPC parameter setを選択する。
【0192】
例えば、図１１に示すように、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を選択する。
【0193】
これにより、CSIに比べてパケット伝送の遅延時間に影響が大きいと考えられるACK/NACKの送信電力をより大きくすることができる。
【0194】
なお、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を定義してもよい。
【0195】
例えば、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）を選択する。
【0196】
これにより、CSIの情報の重要度に応じた適切な送信電力が設定できる。
【0197】
［例２：URLLC用UCIを含むUCIビット数に応じたPC parameter setの選択］
例２では、PCパラメータ制御部３０４は、URLLC用UCIを含むUCIビット数に応じてPC parameter setを選択する。
例２では、PCパラメータ制御部３０４は、URLLC用UCIを含むUCIビット数に応じてPC parameter setを選択する。
【0198】
例えば、図１２に示すように、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を選択する。
【0199】
これにより、UCIビット数が多いほど、つまり、PUSCH全体においてUCIが支配的になるほど、PUSCHの送信電力をより大きくすることができる。
【0200】
［例３：UL-SCHとURLLC用UCIとのサービス種別の組み合わせに応じたPC parameter setの選択］
例３では、PCパラメータ制御部３０４は、UL-SCHとURLLC用UCIとのサービス種別の組み合わせに応じてPC parameter setを選択する。
例３では、PCパラメータ制御部３０４は、UL-SCHとURLLC用UCIとのサービス種別の組み合わせに応じてPC parameter setを選択する。
【0201】
図１３に示すように、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で送信する組み合わせを示す。
【0202】
例えば、図１３に示す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を選択してもよい。
【0203】
あるいは、図１３の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をそれぞれ選択する。
【0204】
例えば、図１３の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を設定してもよい。
【0205】
これにより、端末３００は、UL-SCH（PUSCH）とURLLC用UCIのサービス種別の組み合わせに応じた送信電力を設定できる。
【0206】
以上、PC parameter setの選択方法について説明した。なお、図１１～図１３において設定されるPC parameter set値（例えば、j=0、J-3、J-2又はJ-1）は一例であり、他の値でもよい。
【0207】
このように、本実施の形態では、端末３００は、UL grantによってスケジューリングされるPUSCHに含まれるURLLC用UCIに関する所定の条件を満たす場合、URLLCに対応するPC parameter set（電力制御パラメータ）を設定し、上記所定の条件を満たさない場合、URLLC以外のサービス種別に対応するPC parameter setを設定する。そして、端末３００は、設定したPC parameter setを用いて計算された送信電力を用いて上りリンク信号を送信する。
【0208】
これにより、本実施の形態では、端末３００は、URLLC用UCIの有無に応じて、PUSCHの送信電力を制御できるので、UCI（特に、URLLC用UCI）を含むPUSCHの送信電力を適切にパワーブーストすることができる。
【0209】
なお、端末３００は、PUSCHに含めて送信するUCIの中に、上述した例１～４の所定条件を満たすURLLC用UCIが少なくとも１つ含まれる場合、当該UCIに含まれる他の情報に依らず、URLLCに対応するPC parameter set番号j=AのPC parameter setを選択してもよい。
【0210】
また、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を選択してもよい。
【0211】
また、本実施の形態は、Grant-free送信を行うPUSCHでURLLC用UCIを送信する場合の送信電力の設定方法にも同様に適用できる。
【0212】
また、端末３００は、PC parameter setを変更する場合、PUSCHに配置するUCIのRE数を変更する必要はない。つまり、端末３００は、UCIのRE数（Coding rate）を計算するためのパラメータ（α、βoffset
PUSCH）を変更する必要ない。このため、端末３００では、PC parameter setを変更する簡易な制御によって、UCIの要求品質に応じた送信電力を設定できる。
【0213】
あるいは、端末３００は、PC parameter setの変更に伴い、PUSCHに配置するUCIのRE数を変更してもよい。この場合、端末３００は、PC parameter setに応じて、UCIのCoding rateの計算に用いるパラメータを個別に設定するか、PC parameter setによる送信電力増減を考慮してCoding rate計算を変更する。これにより、端末３００では、PC parameter setの変更およびUCIのCoding rate計算の変更を行う制御によって、UCIの要求品質に応じた送信電力をより適切に設定できる。
【0214】
（実施の形態３）
本実施の形態では、実施の形態２と同様に、URLLC用UCIをPUSCHで送信する場合のPUSCHの上り送信電力の設定方法について説明する。
本実施の形態では、実施の形態２と同様に、URLLC用UCIをPUSCHで送信する場合のPUSCHの上り送信電力の設定方法について説明する。
【0215】
本実施の形態では、サービス種別に依らずPC parameter setは固定とし、送信電力式（例えば、式（１）を参照）に対して、UCIに依存した電力調整パラメータを導入することによって、UCI（特に、URLLC用UCI）を含むPUSCHの送信電力を適切にパワーブーストする方法について説明する。
【0216】
【0217】
［端末４００の構成］
図１４は、本実施の形態に係る端末４００の構成例を示すブロック図である。なお、図１４において、実施の形態１の端末１００（図３）又は実施の形態２の端末３００（図１０）と同様の構成には同一の符号を付し、その説明を省略する。具体的には、図１４に示す端末４００では、図１０に示す端末３００に対し、UCI生成部４０１及び送信電力計算部４０２の動作が異なる。
図１４は、本実施の形態に係る端末４００の構成例を示すブロック図である。なお、図１４において、実施の形態１の端末１００（図３）又は実施の形態２の端末３００（図１０）と同様の構成には同一の符号を付し、その説明を省略する。具体的には、図１４に示す端末４００では、図１０に示す端末３００に対し、UCI生成部４０１及び送信電力計算部４０２の動作が異なる。
【0218】
PCパラメータ制御部１０４は、実施の形態１と同様の処理を行う。つまり、PCパラメータ制御部１０４は、UCIの有無に依らず、復調・復号部１０３から入力されるDCIを用いて、スケジューリングされたPUSCHに適用するPC parameter set番号jを決定する。
【0219】
UCI生成部４０１は、端末４００が送信するUCIを生成し、生成したUCIを符号化・変調部３０２へ出力する。また、UCI生成部４０１は、送信するUCIに関する情報を送信電力計算部４０２へ出力する。
【0220】
送信電力計算部４０２は、PCパラメータ制御部１０４において設定されたPC parameter set番号jを用いて、例えば、式（６）に従ってPUSCHの送信電力を計算する。式(６)は、式（１）に対してΔUCI（UCIに依存した電力調整パラメータ[dB]）が追加されている。
【数6】
【0221】
［基地局の構成］
本実施の形態に係る基地局は、実施の形態１又は実施の形態２に係る基地局２００と基本構成が共通するので、図４を援用して説明する。なお、本実施の形態に係る基地局２００における復号後の受信データには、端末４００（図１４を参照）からの上りリンクデータに加えてUCIが含まれる。
本実施の形態に係る基地局は、実施の形態１又は実施の形態２に係る基地局２００と基本構成が共通するので、図４を援用して説明する。なお、本実施の形態に係る基地局２００における復号後の受信データには、端末４００（図１４を参照）からの上りリンクデータに加えてUCIが含まれる。
【0222】
以下、UCIを含むPUSCHについて、UCIに依存した電力調整パラメータΔUCIによる送信電力のパワーブースト方法の例について説明する。
【0223】
ΔUCIは例えば、次式（７）のように算出される。
【数7】
【0224】
ここで、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数を示す。
【数8】
【0225】
また、式（７）において、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数を示す。
【数9】
【0226】
よって、端末４００は、UCIに要求される品質を満たすためのUCIのRE数をPUSCHに配置できない場合（Q'UCI（Actual RE数） < Q"UCI（Required RE数）の場合）でも、ΔUCIの適用により、不足したRE数に応じたパワーブーストを適用できる。例えば、Q"UCIに対してQ'UCIが小さいほど、ΔUCIが大きくなり、送信電力計算部４０２は、PUSCHに対してより大きな送信電力を設定する。
【0227】
これにより、本実施の形態では、URLLC用UCIに応じて、PUSCHの送信電力を制御できるので、UCI（特に、URLLC用UCI）を含むPUSCHの送信電力を適切にパワーブーストすることができる。
【0228】
なお、本実施の形態において、端末４００がUCIをPUSCHで送信しない場合、式（６）において、ΔUCIは非適用（ΔUCI=0[dB]）とすればよい。
【0229】
また、本実施の形態は、Grant-free送信を行うPUSCHでURLLC用UCIを送信する場合の送信電力の設定方法にも同様に適用できる。
【0230】
また、本実施の形態は、URLLC用UCIが含まれる場合にのみΔUCIを適用し、URLLC用UCIが含まれない場合はΔUCIは非適用（ΔUCI=0[dB]）としてもよい。または、UCIのサービス種別に依らず（URLLC用UCIとeMBB用UCIに依らず）、ΔUCIを適用してもよい。
【0231】
以上、本開示の各実施の形態について説明した。
【0232】
（１）サービス種別又はトラフィック種別（例えば、URLLC及びeMBBの何れかを示す情報）をUL grantに含めてもよい。この場合、基地局２００はUL grantを用いてスケジューリングされたPUSCHのサービス種別を端末１００へ容易に指示でき、端末１００はサービス種別に適したPC parameter setを用いてPUSCHを送信できる。
【0233】
（２）上記実施の形態では、UL grantに関する所定の条件に応じてPC parameter set（例えば、PC parameter set番号j）を変更する場合について説明した。しかし、本実施の形態では、PC parameter set番号j以外のPCパラメータ（例えば、PL推定用RS番号qd、Closed loop process番号ｌ）についても、UL grantに関する所定の条件に応じて変更してもよい。
【0234】
例えば、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に限らず、他のパラメータでもよい。
【0235】
（３）上記実施の形態では、PUSCHの送信電力制御について説明した。しかし、本開示の一実施例は、PUSCH以外の上りチャネル（例えば、PUCCH（Physical Uplink Control Channel））にも適用できる。
【0236】
PUCCHの送信電力制御は、例えば、以下の式（１０）に従って行われる（例えば、非特許文献３を参照）。
【数10】
【0237】
式（１０）において、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,c
PUCCH(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]を示す。
【0238】
例えば、下りデータチャネル（PDSCH：Physical Downlink Shared Channel）に対するACK/NACKを送信するためのPUCCHであれば、PDSCHのMAC-CE情報（詳細にはPUCCH-Spatial-relation-info）を用いて、PC parameter番号quが基地局２００から端末１００へ指示できる。しかしながら、SR送信を行うためのPUCCHについては、付随するPDSCHが無いため、基地局２００から端末１００への明示的なPC parameter値の指示はない。
【0239】
このようなPC parameter値の明示的な指示がないPUCCH送信に関しては、上記実施の形態と同様に、端末１００は、UL grantに関する所定の条件に応じてPC parameter値（例えば、PC parameter番号qu）を切り替えることができる。例えば、URLLC用SR送信を行うPUCCHに対して、URLLC以外のサービス種別のSR送信と比較して、より高い送信電力値となるPC parameter値が設定されてもよい。これにより、URLLC用SRを高品質に送信することができ、URLLCの要求を満たすことができる。このようにして、PUCCH送信についても、PUSCH送信と同様の効果が得られる。
【0240】
（４）本実施の形態において、信頼性又は低遅延性等の要求条件の異なるサービス種別（換言すると、サービス、トラフィック種別、ロジカルチャネル(Logical channel)種別、ユースケース又はusage scenario）は、URLLC又はeMBBに限定されない。例えば、mMTCの送信にも本開示の一実施例を適用でき、同様の効果を得ることができる。
【0241】
（５）本開示はソフトウェア、ハードウェア、又は、ハードウェアと連携したソフトウェアで実現することが可能である。上記実施の形態の説明に用いた各機能ブロックは、部分的に又は全体的に、集積回路であるＬＳＩとして実現され、上記実施の形態で説明した各プロセスは、部分的に又は全体的に、一つのＬＳＩ又はＬＳＩの組み合わせによって制御されてもよい。ＬＳＩは個々のチップから構成されてもよいし、機能ブロックの一部または全てを含むように一つのチップから構成されてもよい。ＬＳＩはデータの入力と出力を備えてもよい。ＬＳＩは、集積度の違いにより、ＩＣ、システムＬＳＩ、スーパーＬＳＩ、ウルトラＬＳＩと呼称されることもある。集積回路化の手法はＬＳＩに限るものではなく、専用回路、汎用プロセッサ又は専用プロセッサで実現してもよい。また、ＬＳＩ製造後に、プログラムすることが可能なＦＰＧＡ（Field Programmable Gate Array）や、ＬＳＩ内部の回路セルの接続や設定を再構成可能なリコンフィギュラブル・プロセッサを利用してもよい。本開示は、デジタル処理又はアナログ処理として実現されてもよい。さらには、半導体技術の進歩または派生する別技術によりＬＳＩに置き換わる集積回路化の技術が登場すれば、当然、その技術を用いて機能ブロックの集積化を行ってもよい。バイオ技術の適用等が可能性としてありえる。
【0242】
本開示は、通信機能を持つあらゆる種類の装置、デバイス、システム（通信装置と総称）において実施可能である。通信装置の、非限定的な例としては、電話機（携帯電話、スマートフォン等）、タブレット、パーソナル・コンピューター（ＰＣ）（ラップトップ、デスクトップ、ノートブック等）、カメラ（デジタル・スチル／ビデオ・カメラ等）、デジタル・プレーヤー（デジタル・オーディオ／ビデオ・プレーヤー等）、着用可能なデバイス（ウェアラブル・カメラ、スマートウオッチ、トラッキングデバイス等）、ゲーム・コンソール、デジタル・ブック・リーダー、テレヘルス・テレメディシン（遠隔ヘルスケア・メディシン処方）デバイス、通信機能付きの乗り物又は移動輸送機関（自動車、飛行機、船等）、及び上述の各種装置の組み合わせがあげられる。
【0243】
通信装置は、持ち運び可能又は移動可能なものに限定されず、持ち運びできない又は固定されている、あらゆる種類の装置、デバイス、システム、例えば、スマート・ホーム・デバイス（家電機器、照明機器、スマートメーター又は計測機器、コントロール・パネル等）、自動販売機、その他ＩｏＴ（Ｉｎｔｅｒｎｅｔ ｏｆ Ｔｈｉｎｇｓ）ネットワーク上に存在し得るあらゆる「モノ（Things）」をも含む。
【0244】
通信には、セルラーシステム、無線ＬＡＮシステム、通信衛星システム等によるデータ通信に加え、これらの組み合わせによるデータ通信も含まれる。
【0245】
また、通信装置には、本開示に記載される通信機能を実行する通信デバイスに接続又は連結される、コントローラやセンサー等のデバイスも含まれる。例えば、通信装置の通信機能を実行する通信デバイスが使用する制御信号やデータ信号を生成するような、コントローラやセンサーが含まれる。
【0246】
また、通信装置には、上記の非限定的な各種装置と通信を行う、あるいはこれら各種装置を制御する、インフラストラクチャ設備、例えば、基地局、アクセスポイント、その他あらゆる装置、デバイス、システムが含まれる。
【0247】
本開示の端末は、上りリンク信号の割当情報の送信に使用される制御チャネルに関する所定の条件を満たす場合、第１のサービスに対応する第１の電力制御パラメータを設定し、前記所定の条件を満たさない場合、第２のサービスに対応する第２の電力制御パラメータを設定する回路と、前記第１の電力制御パラメータ又は前記第２の電力制御パラメータを用いて計算された送信電力を用いて前記上りリンク信号を送信する送信回路と、を具備する。
【0248】
本開示の端末において、前記所定の条件は、前記制御チャネルに用いられるフォーマットのペイロードサイズが所定のサイズと異なることである。
【0249】
本開示の端末において、前記所定の条件は、前記制御チャネルに用いられるフォーマットのペイロードサイズが所定のサイズ未満であることである。
【0250】
本開示の端末において、前記所定の条件は、前記制御チャネルに用いられるスクランブリング系列が所定の系列と異なることである。
【0251】
本開示の端末において、前記所定の条件は、前記制御チャネルが、前記第１のサービスのスケジューリングを要求する信号を前記端末から送信した後の所定期間内に前記端末において受信する制御チャネルであることである。
【0252】
本開示の端末において、前記所定の条件は、前記制御チャネルが、前記第１のサービスのスケジューリングを要求する信号を前記端末から送信した後に前記端末が最初に受信する制御チャネルであることである。
【0253】
本開示の端末において、前記所定の条件は、前記制御チャネルが、前記上りリンク信号の初回送信に使用されるリソースが予め設定された送信方法における再送を示すことである。
【0254】
本開示の端末において、前記所定の条件は、前記端末が前記制御チャネルを受信してから前記上りリンク信号を送信するまでの期間が所定時間以内であることである。
【0255】
本開示の端末において、前記所定の条件は、前記制御チャネルに示される前記上りリンク信号の送信シンボル数が所定値以下であることである。
【0256】
本開示の端末において、前記所定の条件は、前記端末における前記制御チャネルの検出周期が所定値以下であることである。
【0257】
本開示の端末において、前記所定の条件は、前記制御チャネルに用いられる、符号化及び変調方式を示すテーブルが所定のテーブルと異なることである。
【0258】
本開示の端末において、前記所定の条件は、前記上りリンク信号に含まれる上りリンク制御情報が、前記第１のサービスの下りリンクデータに対する応答信号であることである。
【0259】
本開示の端末において、前記所定の条件は、前記端末が下りリンクデータを受信してから、当該下りリンクデータに対する応答信号を含む前記上りリンク信号を送信するまでの期間が所定時間以内であることである。
【0260】
本開示の端末において、前記所定の条件は、前記上りリンク信号に含まれる上りリンク制御情報が、所定の閾値以下の目標誤り率を用いて計算されたチャネル状態情報であることである。
【0261】
本開示の端末において、下りリンクデータ及び当該下りリンクデータに対する応答信号の全体の誤り率が一定の値であり、前記所定の条件は、前記上りリンク信号に含まれる上りリンク制御情報が、前記第２のサービスの下りリンクデータに対する応答信号であることである。
【0262】
本開示の端末において、前記所定の条件は、前記上りリンク信号に含まれる上りリンク制御情報のリソース数が所定の閾値以上であることである。
【0263】
本開示の端末において、前記所定の条件は、前記上りリンク信号全体のリソース数に対する、前記上りリンク信号に含まれる上りリンク制御情報のリソース数の割合が所定の閾値より大きいことである。
【0264】
本開示の端末において、前記第１の電力制御パラメータを用いて計算される前記送信電力は、前記第２の電力制御パラメータを用いて計算される前記送信電力より大きい。
【0265】
本開示の送信方法は、上りリンク信号の割当情報の送信に使用される制御チャネルに関する所定の条件を満たす場合、第１のサービスに対応する第１の電力制御パラメータを設定し、前記所定の条件を満たさない場合、第２のサービスに対応する第２の電力制御パラメータを設定し、前記第１の電力制御パラメータ又は前記第２の電力制御パラメータを用いて計算された送信電力を用いて前記上りリンク信号を送信する。
【0266】
２０１８年５月８日出願の特願２０１８－０９０１２０及び２０１８年７月１８日出願の特願２０１８－１３５０１１の日本出願に含まれる明細書、図面および要約書の開示内容は、すべて本願に援用される。
【産業上の利用可能性】
【0267】
本開示の一実施例は、移動通信システムに有用である。
【符号の説明】
【0268】
１００，３００，４００ 端末
１０１，２０５ アンテナ
１０２，２０６ 受信部
１０３，２０７ 復調・復号部
１０４，３０４ PCパラメータ制御部
１０５，４０２ 送信電力計算部
１０６ データ生成部
１０７，２０３，３０２ 符号化・変調部
１０８ リソース割当部
１０９，２０４ 送信部
２００ 基地局
２０１ スケジューリング部
２０２ 制御情報生成部
３０１，４０１ UCI生成部
３０３ 多重部
１０１，２０５ アンテナ
１０２，２０６ 受信部
１０３，２０７ 復調・復号部
１０４，３０４ PCパラメータ制御部
１０５，４０２ 送信電力計算部
１０６ データ生成部
１０７，２０３，３０２ 符号化・変調部
１０８ リソース割当部
１０９，２０４ 送信部
２００ 基地局
２０１ スケジューリング部
２０２ 制御情報生成部
３０１，４０１ UCI生成部
３０３ 多重部
【図1】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7A】
【図7B】
【図7C】
【図8】
【図9】
【図10】
【図11】
【図12】
【図13】
【図14】