特許 7667256 端末及び無線通信方法

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

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

(11)【特許番号】

(24)【登録日】2025-04-14

(45)【発行日】2025-04-22

(54)【発明の名称】端末及び無線通信方法

(51)【国際特許分類】

   H04W 28/04 20090101AFI20250415BHJP

【ＦＩ】

H04W28/04 110

【請求項の数】 6

(21)【出願番号】P 2023518555

(86)(22)【出願日】2021-05-06

(86)【国際出願番号】 JP2021017401

(87)【国際公開番号】W WO2022234622

(87)【国際公開日】2022-11-10

【審査請求日】2024-05-01

(73)【特許権者】

【識別番号】392026693

【氏名又は名称】株式会社ＮＴＴドコモ

(74)【代理人】

【識別番号】100083806

【弁理士】

【氏名又は名称】三好 秀和

(74)【代理人】

【識別番号】100169797

【弁理士】

【氏名又は名称】橋本 浩幸

(72)【発明者】

【氏名】吉岡 翔平

(72)【発明者】

【氏名】松村 祐輝

(72)【発明者】

【氏名】永田 聡

【審査官】石田 信行

(56)【参考文献】

【文献】OPPO，UL feedback for RRC-CONNECTED UEs in MBS，3GPP TSG RAN WG1 #104b-e R1-2102415，Internet<URL:https://www.3gpp.org/ftp/tsg_ran/WG1_RL1/TSGR1_104b-e/Docs/R1-2102415.zip>，2021年04月07日

【文献】Convida Wireless，Discussion on reliability enhancement for RRC_CONNECTED UEs，3GPP TSG RAN WG1 #104b-e R1-2103420，Internet<URL:https://www.3gpp.org/ftp/tsg_ran/WG1_RL1/TSGR1_104b-e/Docs/R1-2103420.zip>，2021年04月07日

【文献】vivo，Discussion on mechanisms to support group scheduling for RRC_CONNECTED UEs，3GPP TSG RAN WG1 #104b-e R1-2102542，Internet<URL:https://www.3gpp.org/ftp/tsg_ran/WG1_RL1/TSGR1_104b-e/Docs/R1-2102542.zip>，2021年04月06日

【文献】ZTE，Discussion on mechanisms to Improve Reliability for RRC_CONNECTED UEs，3GPP TSG RAN WG1 #104b-e R1-2102502，Internet<URL:https://www.3gpp.org/ftp/tsg_ran/WG1_RL1/TSGR1_104b-e/Docs/R1-2102502.zip>，2021年04月07日

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

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

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

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

ＳＡ ＷＧ１－４，６

ＣＴ ＷＧ１，４

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

【請求項1】

複数の端末向けのデータ配信において、半固定的にスケジューリングされる端末グループに共通の下りデータチャネルを受信する受信部と、
下り制御チャネルの下りリンク制御情報に含まれる前記下りデータチャネルの受信に対するフィードバックの有効化または無効化の指示に基づいて、前記下りデータチャネルの受信に対するフィードバックを制御する制御部と
を備える端末。

【請求項2】

前記制御部は、上位レイヤのシグナリングに基づいて、前記下りリンク制御情報に含まれる前記下りデータチャネルの受信に対するフィードバックの有効化または無効化の指示を適用するのかを判定する請求項１に記載の端末。

【請求項3】

前記制御部は、前記下りデータチャネルの半固定的なスケジューリングのリリースに対するフィードバックの適用を有効にする請求項１に記載の端末。

【請求項4】

複数の端末向けのデータ配信において、半固定的にスケジューリングされる端末グループに共通の下りデータチャネルを受信するステップと、
下り制御チャネルの下りリンク制御情報に含まれる前記下りデータチャネルの受信に対するフィードバックの有効化または無効化の指示に基づいて、前記下りデータチャネルの受信に対するフィードバックを制御するステップ
を含む端末の通信方法。

【請求項5】

複数の端末向けのデータ配信において、半固定的にスケジューリングされる端末グループに共通の下りデータチャネルを送信する送信部と、
下り制御チャネルの下りリンク制御情報に、前記下りデータチャネルの受信に対するフィードバックの有効化または無効化の指示を含める制御部
を備える基地局。

【請求項6】

基地局と複数の端末を含む通信システムにおいて、
前記基地局は、
複数の端末向けのデータ配信において、半固定的にスケジューリングされる端末グループに共通の下りデータチャネルを送信する送信部と、
下り制御チャネルの下りリンク制御情報に、前記下りデータチャネルの受信に対するフィードバックの有効化または無効化の指示を含める制御部を備え、
前記端末は、
前記下りデータチャネルを受信する受信部と、
前記指示に基づいて、前記下りデータチャネルの受信に対するフィードバックを制御する制御部を備える
通信システム。

【発明の詳細な説明】

【技術分野】

【0001】

本開示は、マルチキャスト／ブロードキャスト・サービスに対応した端末及び無線通信方法に関する。

【背景技術】

【0002】

3rd Generation Partnership Project（3GPP）は、5th generation mobile communication system（5G、New Radio（NR）またはNext Generation（NG）とも呼ばれる）を仕様化し、さらに、Beyond 5G、5G Evolution或いは6Gと呼ばれる次世代の仕様化も進めている。

【0003】

3GPPのRelease 17では、NRにおける特定または不特定の複数の端末（User Equipment, UE）への同時データ送信（配信と呼ばれてもい）サービス（MBS：Multicast and Broadcast Services)（仮称）と呼ぶ）が対象となっている（非特許文献１）。

【0004】

MBSでは、例えば、サービスの対象となるUEグループのスケジューリング、及び信頼性向上（例えば、HARQ（Hybrid Automatic repeat request）の無線基地局（gNB）へのフィードバック）について検討が進められている。

【先行技術文献】

【非特許文献】

【0005】

【文献】"New Work Item on NR support of Multicast and Broadcast Services", RP-193248, 3GPP TSG RAN Meeting #86, 3GPP, 2019年12月

【発明の概要】

【0006】

MBSでは、HARQの肯定応答（ACK）及び否定応答（NACK）をgNBにフィードバックすることができる。

【0007】

しかしながら、UEは、このようなHARQ（自動再送要求）のフィードバックが有効化及び無効化（enable/disable）されるタイミングを迅速かつ確実に認識することが難しい問題がある。

【0008】

そこで、以下の開示は、このような状況に鑑みてなされたものであり、特定または不特定の複数の端末への同時データ送信サービスにおいて、自動再送要求のフィードバックの有効化及び無効化を迅速かつ確実に認識できる端末及び無線通信方法の提供を目的とする。

【0009】

本開示の一態様は、下りリンク制御情報を受信する受信部（制御信号・参照信号処理部240）と、複数の端末向けのデータ配信において、前記下りリンク制御情報に含まれる優先度に関するフィールドに基づいて、下りチャネルにおける自動再送要求のフィードバックの有効化または無効化の少なくとも何れかを実行する制御部（制御部270）とを備える端末（UE200）である。

【0010】

本開示の一態様は、複数の端末向けのデータ配信において、下りデータチャネルを受信する受信部（無線信号送受信部210）と、前記下りデータチャネルに半固定的なスケジューリングが適用される場合、端末グループに共通である下り制御チャネルを介した下りリンク制御情報による自動再送要求のフィードバックの有効化または無効化の指示が、前記下りリンク制御情報の直後の前記下りデータチャネルの受信と、後続の前記下りデータチャネルとの受信に適用されると想定する制御部（制御部270）とを備える端末（UE200）である。

【0011】

本開示の一態様は、複数の端末向けのデータ配信において、下りデータチャネルを受信する受信部（無線信号送受信部210）と、前記下りデータチャネルに半固定的なスケジューリングが適用される場合、端末グループに共通である下り制御チャネルを介した下りリンク制御情報による自動再送要求のフィードバックの有効化または無効化の指示が、前記下りリンク制御情報の直後の前記下りデータチャネルを除く、後続の前記下りデータチャネルの受信に適用されると想定する制御部（制御部270）とを備える端末（UE200）である。

【0012】

本開示の一態様は、複数の端末向けのデータ配信において、下りデータチャネルを受信する受信部（無線信号送受信部210）と、半固定的なスケジューリングが適用された前記下りデータチャネルを解放する場合、前記下りデータチャネルの受信時に適用された自動再送要求のフィードバックの有効化または無効化に基づいて、前記下りデータチャネルの解放時に適用される自動再送要求のフィードバックが有効または無効であるかを決定する制御部（制御部270）とを備える端末（UE200）である。

【0013】

本開示の一態様は、下りリンク制御情報を受信するステップと、複数の端末向けのデータ配信において、前記下りリンク制御情報に含まれる優先度に関するフィールドに基づいて、下りチャネルにおける自動再送要求のフィードバックの有効化または無効化の少なくとも何れかを実行するステップとを含む無線通信方法である。

【0014】

本開示の一態様は、複数の端末向けのデータ配信において、下りデータチャネルを受信するステップと、前記下りデータチャネルに半固定的なスケジューリングが適用される場合、端末グループに共通である下り制御チャネルを介した下りリンク制御情報による自動再送要求のフィードバックの有効化または無効化の指示が、前記下りリンク制御情報の直後の前記下りデータチャネルの受信と、後続の前記下りデータチャネルとの受信に適用されると想定するステップとを含む無線通信方法である。

【図面の簡単な説明】

【0015】

【図1】図１は、無線通信システム10の全体概略構成図である。

【図2】図２は、無線通信システム10において用いられる無線フレーム、サブフレーム及びスロットの構成例を示す図である。

【図3】図３は、PTM送信方式１及びPTM送信方式２の構成例を示す図である。

【図4】図４は、gNB100及びUE200の機能ブロック構成図である。

【図5】図５は、MBSにおけるPDCCH（DCIを含む）、PDSCH及びHARQフィードバックのシーケンス例を示す図である。

【図6】図６は、動作例１－２に係るPRIとPUCCHリソースセットとの対応例を示す図である。

【図7】図７は、動作例１－３に係るPUCCHリソースセットの切り替え動作の説明図である。

【図8】図８は、動作例３－１及び動作例３－２に係るPriority indicatorとHARQフィードバックとの対応例を示す図である。

【図9】図９は、動作例４に係るDCIとPDSCHとの対応関係の例を示す図である。

【図10】図１０は、動作例５に係るDCIとPDSCHとの対応関係の例を示す図である。

【図11】図１１は、gNB100及びUE200のハードウェア構成の一例を示す図である。

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

【0016】

以下、実施形態を図面に基づいて説明する。なお、同一の機能や構成には、同一または類似の符号を付して、その説明を適宜省略する。

【0017】

（１）無線通信システムの全体概略構成
（１．１）システム構成例
図１は、本実施形態に係る無線通信システム10の全体概略構成図である。無線通信システム10は、5G New Radio（NR）に従った無線通信システムであり、Next Generation-Radio Access Network 20（以下、NG-RAN20、及び複数の端末200（User Equipment 200、以下、UE200）を含む。

【0018】

なお、無線通信システム10は、Beyond 5G、5G Evolution或いは6Gと呼ばれる方式に従った無線通信システムでもよい。

【0019】

NG-RAN20は、無線基地局100（以下、gNB100）を含む。なお、gNB及びUEの数を含む無線通信システム10の具体的な構成は、図１に示した例に限定されない。

【0020】

NG-RAN20は、実際には複数のNG-RAN Node、具体的には、gNB（またはng-eNB）を含み、5Gに従ったコアネットワーク（5GC、不図示）と接続される。なお、NG-RAN20及び5GCは、単に「ネットワーク」と表現されてもよい。

【0021】

gNB100は、NRに従った無線基地局であり、UE200とNRに従った無線通信を実行する。gNB100及びUE200は、複数のアンテナ素子から送信される無線信号を制御することによって、より指向性の高いビームBMを生成するMassive MIMO、複数のコンポーネントキャリア（CC）を束ねて用いるキャリアアグリゲーション（CA）、及びUEと複数のNG-RAN Nodeそれぞれとの間において同時に通信を行うデュアルコネクティビティ（DC）などに対応することができる。

【0022】

無線通信システム10は、FR1及びFR2に対応する。各FR（Frequency Range）の周波数帯は、次のとおりである。

【0023】

・FR1：410 MHz～7.125 GHz
・FR2：24.25 GHz～52.6 GHz
FR1では、15, 30または60kHzのSub-Carrier Spacing（SCS）が用いられ、5～100MHzの帯域幅（BW）が用いられてもよい。FR2は、FR1よりも高周波数であり、60または120kHz（240kHzが含まれてもよい）のSCSが用いられ、50～400MHzの帯域幅（BW）が用いられてもよい。

【0024】

さらに、無線通信システム10は、FR2の周波数帯域よりも高周波数帯域にも対応してもよい。具体的には、無線通信システム10は、52.6GHzを超え、114.25GHzまでの周波数帯域に対応し得る。また、無線通信システム10は、FR1とFR2との間の周波数帯域に対応してもよい。

【0025】

また、より大きなSub-Carrier Spacing（SCS）を有するCyclic Prefix-Orthogonal Frequency Division Multiplexing（CP-OFDM）／Discrete Fourier Transform - Spread（DFT-S-OFDM）を適用してもよい。さらに、DFT-S-OFDMは、上りリンク（UL）だけでなく、下りリンク（DL）にも適用されてもよい。

【0026】

図２は、無線通信システム10において用いられる無線フレーム、サブフレーム及びスロットの構成例を示す。

【0027】

図２に示すように、１スロットは、１４シンボルで構成され、SCSが大きく（広く）なる程、シンボル期間（及びスロット期間）は短くなる。なお、１スロットを構成するシンボル数は、必ずしも１４シンボルでなくてもよい（例えば、２８、５６シンボル）。また、サブフレーム当たりのスロット数は、SCSによって異なっていてよい。さらに、SCSは、240kHzよりも広くてもよい（例えば、図２に示すように、480kHz, 960kHz）。

【0028】

なお、図２に示す時間方向（t）は、時間領域、シンボル期間またはシンボル時間などと呼ばれてもよい。また、周波数方向は、周波数領域、リソースブロック、リソースブロックグループ、サブキャリア、BWP (Bandwidth part)、サブチャネル、共通周波数リソースなどと呼ばれてもよい。

【0029】

（１．２）MBSの提供
無線通信システム10では、マルチキャスト／ブロードキャスト・サービス（MBS：Multicast and Broadcast Services）が提供されてよい。

【0030】

例えば、スタジアムやホールなどでは、多数のUE200が一定の地理的エリア内に位置し、多数のUE200が同時に同一のデータを受信するケースが想定される。このような場合、ユニキャストではなく、MBSの利用が効果的である。

【0031】

なお、ユニキャストとは、特定の１つのUE200を指定（UE200固有の識別情報が指定されてもよい）して、ネットワークと１対１で行われる通信と解釈されてよい。

【0032】

マルチキャストとは、特定の複数のUE200を指定（マルチキャスト用の識別情報が指定されてもよい）して、ネットワークと１対複数（特定多数）で行われる通信と解釈されてよい。なお、受信マルチキャストのデータを受信するUE200の数は、結果的に１つでも構わない。

【0033】

ブロードキャストとは、全てのUE200に対して、ネットワークと１対不特定多数で行われる通信と解釈されてもよい。マルチキャスト／ブロードキャストされるデータは、コピーされた同一の内容であってもよいが、ヘッダなど一部の内容は異なっていてもよい。また、マルチキャスト／ブロードキャストされるデータは同時に送信（配信）されてよいが、必ずしも厳密な同時性を必要とせず、伝搬遅延及び／またはRANノード内の処理遅延などが含まれ得る。

【0034】

なお、対象となるUE200は、無線リソース制御レイヤ（RRC）の状態が、アイドル状態（RRC idle）、接続状態（RRC connected）、或いは他の状態（例えば、インアクティブ状態）の何れかであってもよい。インアクティブ状態とは、RRCの一部の設定が維持されている状態と解釈されてよい。

【0035】

MBSでは、マルチキャスト／ブロードキャストPDSCH（Physical Downlink Shared Channel）のスケジューリング、具体的には、MBSパケット（データと読み替えてよい）のスケジューリングについて、次の３種類の方法が想定されている。なお、RRC connected UEは、RRC idle UE、RRC inactive UEに読み替えられてもよい。

【0036】

・PTM送信方式１（PTM-1）：
・RRC connected UEのMBS groupに対して、グループ共通（group-common）PDCCH（Physical Downlink Control Channel）を用いてgroup-common PDSCHをスケジューリングする。

【0037】

・PDCCHのCRC及びPDSCHは、group-common RNTI（Radio Network Temporary Identifier、G-RNTIと呼ばれてもよい）によってスクランブリングされる。

【0038】

・PTM送信方式２（PTM-2）：
・RRC connected UEのMBS groupに対して、端末固有（UE-specific）PDCCHを用いてgroup-common PDSCHをスケジューリングする。

【0039】

・PDCCHのCRCは、UE-specific RNTIによってスクランブリングされる。

【0040】

・PDSCHは、group-common RNTIによってスクランブリングされる。

【0041】

・PTP送信方式：
・RRC connected UEに対して、UE-specific PDCCHを用いてUE-specific PDSCHをスケジューリングする。

【0042】

・PDCCHのCRC及びPDSCHは、UE-specific RNTIによってスクランブリングされる。つまり、ユニキャストによってMBSパケットが送信されることを意味してよい。

【0043】

図３は、PTM送信方式１及びPTM送信方式２の構成例を示す。なお、UE固有PDCCH/PDSCHは、ターゲットUEが識別できるが、同一MBSグループ内の他のUEによって識別できなくてよい。グループ共通PDCCH/PDSCHは、同一時間／周波数リソースにおいて送信され、同一MBSグループ内の全てのUEによって識別できる。また、PTM送信方式１，２の名称は、仮称であり、上述した動作が実行される限り、別の名称で呼ばれてもよい。

【0044】

なお、ポイントツーポイント（PTP）による配信では、RANノードは、MBSデータパケットの個別のコピーを無線で個々のUEに配信してよい。ポイントツーマルチポイント（PTM）配信では、RANノードは、MBSデータパケットの単一コピーを無線でUEのセットに配信してよい。

【0045】

また、MBSの信頼性向上を図るため、HARQ（Hybrid Automatic repeat request）のフィードバック、具体的には、マルチキャスト／ブロードキャストPDSCHに対するHARQフィードバックについて、次の２つのフィードバック方法が想定されている。

【0046】

・オプション１：ACK/NACKの両方をフィードバック（ACK/NACK feedback）
・PDSCH受信・復号に成功したUEは、ACKを送信する
・PDSCH受信・復号に失敗したUEは、NACKを送信する
・PUCCH(Physical Uplink Control Channel）リソース設定：マルチキャスト向けにPUCCH-Configを設定できる
・PUCCHリソース：UE間の共有／直交（shared/orthogonal）は、ネットワークの設定による
・HARQ-ACK CB (codebook)：type-1及びtype-2（CB決定アルゴリズム（3GPP TS38.213において規定））をサポート
・多重化：ユニキャストまたはマルチキャストを適用可
・オプション２：NACKのみをフィードバック（NACK-only feedback）
・PDSCH受信・復号に成功したUEは、ACKを送信しない（応答を送信しない）
・PDSCH受信・復号に失敗したUEは、NACKを送信する
・所定のUEにおいて、PUCCHリソース設定は、ユニキャストまたはグループキャスト（マルチキャスト）によって別々に設定できる
なお、ACKは、positive acknowledgement（肯定応答）、NACKは、negative acknowledgement（否定応答）と呼ばれてもよい。HARQは、自動再送要求と呼ばれてもよい。

【0047】

オプション１またはオプション２の有効化及び無効化（enable/disable）は、次の何れかが適用されてよい。

【0048】

・RRC及び下りリンク制御情報（DCI：Downlink Control Information）
・RRCのみ
また、マルチキャスト／ブロードキャストPDSCHのSPS（Semi-persistent Scheduling）について、次のような内容が想定されている。

【0049】

・SPS group-common PDSCHを採用
・UE能力（capability）として、複数のSPS group-common PDSCHが設定できる
・SPS group-common PDSCHに対するHARQフィードバックが可能
・少なくともgroup-common PDCCH（下り制御チャネル）によるアクティブ化／非アクティブ化（activation/deactivation）が可能
なお、非アクティブ化（deactivation）は、解放（release）などの他の同義の用語に読み替えられてもよい。例えば、アクティブ化は、起動、開始、トリガーなど、非アクティブ化は、さらに、終了、停止などに読み替えられてもよい。

【0050】

SPSは、動的（dynamic）なスケジューリングとの対比として用いられるスケジューリングであり、半固定、半持続的或いは半永続的なスケジューリングなどと呼ばれてもよく、Configured Scheduling（CS）と解釈されてもよい。

【0051】

スケジューリングとは、データを送信するためのリソースを割り当てるプロセスと解釈されてよい。動的なスケジューリングでは、全てのPDSCHがDCI（例えば、DCI 1_0、DCI 1_1またはDCI 1_2）によってスケジュールされるメカニズムと解釈されてもよい。SPSは、PDSCH送信がRRCメッセージなどの上位レイヤシグナリングによってスケジュールされるメカニズムと解釈されてもよい。

【0052】

また、物理レイヤに関しては、時間領域のスケジューリングと周波数領域のスケジューリングのスケジューリングカテゴリが存在してよい。

【0053】

また、マルチキャスト、グループキャスト、ブロードキャスト、MBSは互いに読み替えられてもよい。マルチキャストPDSCH、グループ共通RNTIによってスクランブルされたPDSCHは互いに読み替えられてもよい。

【0054】

さらに、データ及びパケットの用語は、相互に読み替えられてもよく、信号、データユニットなどの用語に同義と解釈されてもよい。また、送信、受信、伝送及び配信は、相互に読み替えられてもよい。

【0055】

（２）無線通信システムの機能ブロック構成
次に、無線通信システム10の機能ブロック構成について説明する。具体的には、gNB100及びUE200の機能ブロック構成について説明する。

【0056】

図４は、gNB100及びUE200の機能ブロック構成図である。以下では、UE200について説明する。図４に示すように、UE200は、無線信号送受信部210、アンプ部220、変復調部230、制御信号・参照信号処理部240、符号化/復号部250、データ送受信部260及び制御部270を備える。

【0057】

なお、図４では、実施形態の説明に関連する主な機能ブロックのみが示されており、UE200は、他の機能ブロック（例えば、電源部など）を有することに留意されたい。また、図４は、UE200（gNB100）の機能的なブロック構成について示しており、ハードウェア構成については、図８を参照されたい。

【0058】

無線信号送受信部210は、NRに従った無線信号を送受信する。無線信号送受信部210は、Massive MIMO、複数のCCを束ねて用いるCA、及びUEと２つのNG-RAN Nodeそれぞれとの間において同時に通信を行うDCなどに対応する。

【0059】

また、無線信号送受信部210は、MBSに対応しており、複数のUE200向けのデータ配信において、端末グループに共通（group common）である下りチャネルを受信できる。本実施形態において、無線信号送受信部210は、受信部を構成してよい。

【0060】

具体的には、無線信号送受信部210は、MBS、つまり、複数の端末向けのデータ配信において、下りデータチャネル（PDSCH）を受信できる。

【0061】

また、無線信号送受信部210は、端末グループに共通の下りデータチャネル（PDSCH）、具体的には、group-common PDSCH（SPS group-common PDSCHを含んでよい）を受信できる。また、無線信号送受信部210は、端末グループに共通の下り制御チャネル、具体的には、group-common PDCCHを受信できる。

【0062】

アンプ部220は、PA (Power Amplifier)/LNA (Low Noise Amplifier)などによって構成される。アンプ部220は、変復調部230から出力された信号を所定の電力レベルに増幅する。また、アンプ部220は、無線信号送受信部210から出力されたRF信号を増幅する。

【0063】

変復調部230は、所定の通信先（gNB100など）毎に、データ変調／復調、送信電力設定及びリソースブロック割当などを実行する。変復調部230では、Cyclic Prefix-Orthogonal Frequency Division Multiplexing（CP-OFDM）／Discrete Fourier Transform - Spread（DFT-S-OFDM）が適用されてもよい。また、DFT-S-OFDMは、上りリンク（UL）だけでなく、下りリンク（DL）にも用いられてもよい。

【0064】

制御信号・参照信号処理部240は、UE200が送受信する各種の制御信号に関する処理、及びUE200が送受信する各種の参照信号に関する処理を実行する。

【0065】

具体的には、制御信号・参照信号処理部240は、gNB100から所定の制御チャネルを介して送信される各種の制御信号、例えば、無線リソース制御レイヤ（RRC）の制御信号（メッセージ）を受信する。また、制御信号・参照信号処理部240は、gNB100に向けて、所定の制御チャネルを介して各種の制御信号を送信する。

【0066】

制御信号・参照信号処理部240は、Demodulation Reference Signal（DMRS）、及びPhase Tracking Reference Signal （PTRS）などの参照信号（RS）を用いた処理を実行する。

【0067】

DMRSは、データ復調に用いるフェージングチャネルを推定するための端末個別の基地局～端末間において既知の参照信号（パイロット信号）である。PTRSは、高い周波数帯で課題となる位相雑音の推定を目的した端末個別の参照信号である。

【0068】

なお、参照信号には、DMRS及びPTRS以外に、Channel State Information-Reference Signal（CSI-RS）、Sounding Reference Signal（SRS）、及び位置情報用のPositioning Reference Signal（PRS）などが含まれてもよい。

【0069】

また、チャネルには、制御チャネルとデータチャネルとが含まれる。制御チャネルには、PDCCH、PUCCH（Physical Uplink Control Channel）、RACH（Random Access Channel、Random Access Radio Network Temporary Identifier(RA-RNTI)を含むDownlink Control Information (DCI)）、及びPhysical Broadcast Channel（PBCH）などが含まれてよい。

【0070】

また、データチャネルには、PDSCH、及びPUSCH（Physical Uplink Shared Channel）などが含まれる。データとは、データチャネルを介して送信されるデータを意味してよい。

【0071】

本実施形態において、制御信号・参照信号処理部240は、下りリンク制御情報（DCI）を受信する受信部を構成してよい。また、制御信号・参照信号処理部240は、RRCにおいて、HARQフィードバックの有効化または無効化がDCIで指示される機能の有効化または無効化を示すメッセージを受信してよい。

【0072】

符号化/復号部250は、所定の通信先（gNB100または他のgNB）毎に、データの分割／連結及びチャネルコーディング／復号などを実行する。

【0073】

具体的には、符号化/復号部250は、データ送受信部260から出力されたデータを所定のサイズに分割し、分割されたデータに対してチャネルコーディングを実行する。また、符号化/復号部250は、変復調部230から出力されたデータを復号し、復号したデータを連結する。

【0074】

データ送受信部260は、Protocol Data Unit (PDU)ならびにService Data Unit (SDU)の送受信を実行する。具体的には、データ送受信部260は、複数のレイヤ（媒体アクセス制御レイヤ（MAC）、無線リンク制御レイヤ（RLC）、及びパケット・データ・コンバージェンス・プロトコル・レイヤ（PDCP）など）におけるPDU/SDUの組み立て／分解などを実行する。また、データ送受信部260は、ハイブリッドARQ（Hybrid automatic repeat request）に基づいて、データの誤り訂正及び再送制御を実行する。

【0075】

制御部270は、UE200を構成する各機能ブロックを制御する。特に、本実施形態では、制御部270は、MBSに関する下りチャネルのスケジューリング及び当該チャネルのHARQフィードバックに関する制御を実行する。

【0076】

制御部270は、MBS、つまり、複数のUE200に向けのデータ配信において、端末グループに共通（group common）である下りデータチャネルのスケジューリングに対応した制御を実行する。具体的には、制御部270は、group-common PDCCH及びgroup-common PDSCHのスケジューリングに対応した制御を実行できる。

【0077】

制御部270は、MBS、つまり、複数のUE200に向けのデータ配信において、DCI（下りリンク制御情報）に含まれる特定のフィールドに基づいて、下りチャネルにおけるHARQ（自動再送要求）のフィードバックの有効化または無効化（enable/disable）の少なくとも何れかを実行してよい。

【0078】

具体的には、DCIのフォーマット（3GPP TS38.212など参照）において規定されるフィールドのうち、HARQフィードバックに関するフィールドを使用して、HARQフィードバックのenable/disableが指定されてよい。

【0079】

次の少なくとも何れかのフィールドが使用されてよい。

【0080】

・TPC command for scheduled PUCCH
・PUCCH resource indicator（PRI）
・PDSCH-to-HARQ_feedback timing indicator
当該フィールドは、DCI format 1_0, 1_1, 1_2などにおいて規定されてよい。

【0081】

制御部270は、DCIに含まれるPUCCH（上り制御チャネル）用のリソース指示フィールド、具体的には、PUCCH resource indicator（PRI）のフィールドに基づいて、HARQフィードバックのenable/disableの何れかを実行してもよい。

【0082】

例えば、PRIの特定の値（例えば、000）がHARQフィードバックなしと対応付けられてよい。また、HARQフィードバックなしと対応付けられたPRIを含まないPUCCHリソースセットと、HARQフィードバックなしと対応付けられたPRIを含むPUCCHリソースセットとが切り替えられもよい。

【0083】

制御部270は、上位レイヤ（例えば、RRC）のシグナリングなどによって、DCIによるHARQフィードバックのenable/disableが指定されることを認識してよい。制御部270は、このようなシグナリングを受信した場合、HARQフィードバックなしと対応付けられたPRIを含むPUCCHリソースセットに切り替えてよい。また、制御部270は、DCIによるHARQフィードバックのenable/disableが指定を解除するシグナリングを受信した場合、HARQフィードバックなしと対応付けられたPRIを含まないPUCCHリソースセットに切り替え（復帰）してもよい。

【0084】

制御部270は、DCIによってHARQフィードバックなしが指示された場合、PUCCHリソースを送信せず、HARQフィードバックを実行しなくてよい。なお、当該PUCCHリソースセットの切り替えに関するより具体的な動作については、さらに後述する。

【0085】

制御部270は、RRCレイヤのメッセージ（シグナリングと読み替えてもよい）に基づいて、上述したDCIに含まれる特定のフィールドに基づいたHARQフィードバックのenable/disableが適用されるか否かを判定してよい。

【0086】

具体的には、制御部270は、当該メッセージがDCIによって示される機能の有効化であった場合は、DCIにおいてHARQフィードバックの有効化または無効化の指示を受信すると想定してよい。また、制御部270は、当該メッセージがDCIによって示される機能の無効化であった場合は、DCIにおいてHARQフィードバックの有効化または無効化の指示を受信せず、フィードバックを無効化してよい。

【0087】

例えば、制御部270は、当該RRCのシグナリングの設定に応じて、次の何れかの動作を適用してよい。

【0088】

・HARQフィードバックの無効（disable）が設定された場合：DCIによるHARQフィードバックのenable/disableは、常に指示されないと想定する。

【0089】

・HARQフィードバックの有効（enable）：DCIによるHARQフィードバックのenable/disableは、常に指示されると想定する。

【0090】

なお、HARQフィードバックのenable/disableは、RNTI（C (Cell)-RNTI/G (Group)-RNTI毎に設定されてもよいし、DCIによってHARQフィードバックのenable/disableを指示する方法が、RRCのシグナリングによって切り替えられてもよい。例えば、上述したDCIに含まれる特定のフィールドによって指示する方法と、当該フィールドを複数組み合わせて指示する方法とが、RRCのシグナリングによって切り替えられてもよい。

【0091】

また、制御部270は、DCIに関連するフォーマット、識別情報、リソースまたはサーチスペースの少なくとも何れかに基づいて、下りチャネルにおけるHARQフィードバックのenable/disableの少なくとも何れかを実行してもよい。

【0092】

例えば、DCI format（例えば、上述した特定のフィールドを含むDCI format 1_0, 1_1, 1_2など）、DCIのCRCのスクランブリングに用いられるRNTI（識別情報）、CORESET（control resource sets）、サーチスペース、及びPDSCHリソース（時間／周波数／符号／空間）の少なくとも何れかに基づいて、HARQフィードバックのenable/disableが実行されてもよい。

【0093】

制御部270は、複数のUE200向けのデータ配信において、DCIに含まれる優先度に関するフィールドに基づいて、下りチャネルにおけるHARQのフィードバックの有効化または無効化の少なくとも何れかを実行してもよい。ここで、下りチャネルとは、下りデータチャネル（PDSCH）を想定するが、下り制御チャネル（PDCCH）であってもよい。

【0094】

DCIとは、MBS用のPDSCHをスケーリングするためのDCI（またはDCIフォーマット）でよく、当該DCIに含まれるフィールドのうち、HARQに関する優先度を示すフィールドであればよい。例えば、当該フィールドは、Priority indicator fieldと呼ばれてもよく、優先度（Priority）の指示に係る別のフィールドであってもよい。

【0095】

制御部270は、当該優先度が高い場合、HARQフィードバックを有効化し、当該優先度が低い場合、HARQフィードバックを無効化してもよい。或いは、制御部270は、Priority indicator fieldの値毎に、HARQフィードバックの有効化または無効化を想定してもよい。なお、制御部270は、DCIにPriority indicator fieldが含まれない場合には、RRCによってHARQフィードバックの有効化または無効化が指定されると想定してもよい。

【0096】

また、制御部270は、下りデータチャネル（PDSCH）に半固定的なスケジューリング（SPS）が適用される場合、端末グループに共通である下り制御チャネル（group-common PDCCH）を介したDCIによるHARQのフィードバックの有効化または無効化の指示が、当該DCIの直後のPDSCHの受信と、後続のPDSCHとの受信に適用されると想定してよい。

【0097】

具体的には、制御部270は、Multicast SPS PDSCH受信の場合、group-common PDCCHのactivation DCIにおけるHARQフィードバックのenable/disable指示が、group-common PDCCHのactivation DCIの直後のPDSCH受信、及び後続のSPS PDSCH受信に適用されると想定してよい。

【0098】

なお、Multicast SPS PDSCH受信は、group-common SPS PDSCH受信を意味してもよく、複数の端末が受信するSPS PDSCHであってもよく、G-RNTIまたはG-CS-RNTI（すなわち、複数の端末に関連付けられたRNTI）に関連付けられたSPS PDSCH受信であってもよい。また、MulticastはBroadcastに読み替えられてもよい。

【0099】

或いは、制御部270は、下りデータチャネル（PDSCH）に半固定的なスケジューリング（SPS）が適用される場合、端末グループに共通である下り制御チャネル（group-common PDCCH）介したDCIによるHARQのフィードバックの有効化または無効化の指示が、当該DCIの直後のPDSCHを除く、後続のPDSCHの受信に適用されると想定してもよい。

【0100】

具体的には、制御部270は、Multicast SPS PDSCH受信の場合、group-common PDCCHのactivation DCIにおけるHARQ feedback enable/disable指示が、後続のSPS PDSCH受信にのみ適用され、group-common PDCCHのactivation DCIの直後のPDSCH受信に対するHARQフィードバックには所定値（例えば、enable）が適用されると想定してもよい。

【0101】

また、制御部270は、半固定的なスケジューリング（SPS）が適用された下りデータチャネル（PDSCH）を解放する場合、当該PDSCHの受信時に適用されたHARQのフィードバックの有効化または無効化に基づいて、当該PDSCHの解放時に適用されるHARQのフィードバックが有効または無効であるかを決定してよい。

【0102】

なお、PDSCHの解放（Release）は、非活性化（deactivation）などと読み替えられてもよい。制御部270は、Multicast SPS PDSCHのrelease (deactivation)に対するHARQフィードバックがenableまたはdisableの何れであるかが、上述した何れかの方法によって設定または指示されると想定してよい。或いは、制御部270は、Multicast SPS PDSCHのreleaseについては、対応するSPS PDSCH受信時または活性化（activation）時に適用されたHARQフィードバック（enableまたはdisable）と同じと想定してもよいし、必ず所定値（例えば、enable）であると想定してもよい。

【0103】

また、gNB100は、上述した下りチャネルのスケジューリング、及びHARQに関する制御を実行することがきる。

【0104】

（３）無線通信システムの動作
次に、無線通信システム10の動作について説明する。具体的には、MBSに関する下りチャネルのスケジューリング及び当該チャネルのHARQフィードバックに関する動作について説明する。

【0105】

図５は、MBSにおけるPDCCH（DCIを含む）、PDSCH及びHARQフィードバックのシーケンス例を示す。図５に示すように、group-common PDSCHなどのHARQフィードバックは、enable/disableされてもよい。なお、enable/disableは、on/off、開始／終了（停止）などの別の用語で読み替えられてもよい。

【0106】

例えば、HARQフィードバックのenable/disableは、RRCのシグナリングとDCIのフィールドによる指示との組合せによって実現できるが、以下では、具体的なHARQフィードバックのenable/disableに関する動作例について説明する。

【0107】

なお、HARQフィードバックのenable/disableの指示用に新たなフィールドを追加することは、DCIのオーバーヘッド増大の観点から望ましくない。また、MBS（マルチキャスト／ブロードキャスト）のスケジューリングに、例えば、DCI format 1_0を使用する場合、ペイロードサイズは、ユニキャスト用と同一にする必要があり、可能な限り専用のフィールドを増やさないなどの配慮が必要となる。

【0108】

（３．１）動作例１
本動作例では、DCI formatにおけるフィールドのうち、HARQフィードバックに係るフィールドを使用して、HARQフィードバックのenable/disableが指定されてよい。HARQフィードバックに係るフィールドとは、HARQフィードバックに何らかの影響がある、または関連するフィールドと解釈されてよい。

【0109】

HARQフィードバックのenable/disableは、特定のトランスポート・ブロック（TB）の受信（例えば、HARQフィードバックのenable/disable通知を含むDCIが割り当てるTB）を対象として指定されてもよいし、特定のTBを対象とせず、当該特定のTB以外のTB（例えば、SPS group-common PDSCHを介したTB）に適用されてもよい。すなわち、HARQフィードバックのenable/disableの通知受信後は、所定の条件が満たされるまで（例えば再度通知を受信するまで）、通知されたenable/disableに従って動作してもよい。

【0110】

利用されるDCI formatは、1_0でよく、1_1または1_2であってもよい。或いは、group-common PDSCHのスケジューリング用に定義された別のDCI format（例えば、1_3）であってもよい。

【0111】

（動作例１－１）
具体的には、以下の何れかのフィールドに基づいてHARQフィードバックのenable/disableが指定されてもよい。なお、フィールド名及びビット数はこれに限られない。

【0112】

（i）TPC command for scheduled PUCCH：２ビット（3GPP TS38.213 7.2.1章）
（ii）PUCCH resource indicator：３ビット（3GPP TS38.213 9.2.3章）
（iii）PDSCH-to-HARQ_feedback timing indicator：３ビット（3GPP TS38.213 9.2.3章）

【0113】

（動作例１－２）
PUCCH resource indicator (PRI)を使用する場合、UE200は、次のように動作してよい。UE200は、HARQフィードバックのenable/disableがDCIによって指定されることが、上位レイヤ（例えば、RRCのシグナリング）によって設定されると、PRIとPUCCHリソースセットとの対応を変更してもよい。

【0114】

図６は、動作例１－２に係るPRIとPUCCHリソースセットとの対応例を示す。図６の上側は、従来、つまり、HARQフィードバックのenable/disableが適用されない場合のPRIとPUCCHリソースセットとの対応例を示す。図６の下側は、HARQフィードバックのenable/disableが適用される場合のPRIとPUCCHリソースセットとの対応例（実施例）を示す。

【0115】

なお、図６の下側では、PRI=000にHARQフィードバックなしを対応させているが、一例であり、これに限られない。何れのPRIの値がHARQフィードバックなしを意味するかについては、3GPPの仕様で規定されてもよいし、上位レイヤによって設定されてもよい。また、本動作例では、PRIのフィールドが用いられているが、上述した他のフィールドが用いられる場合も同様でよい（以下同）。

【0116】

また、図６の上側におけるPUCCH resource#0と、図６の下側におけるPUCCH resource#0とは同じであってもよく、異なっていてもよい。例えば、PRI=000を除いて、図６の上側と下側とで同じPUCCH resourceが指示されてもよく、この場合、例えば図６の上側におけるPUCCH resource#1と、図６の下側におけるPUCCH resource#0とが同じであってもよい。

【0117】

UE200は、PRIによってHARQフィードバックなしが指示されたら、PUCCHリソースによって送信されるHARQフィードバック（ACK/NACK）送信を停止してよい。または、HARQフィードバック送信に係る動作を開始しなくてよい。UE200は、同一PUCCHリソースに載せるはずのユニキャストPDSCHのHARQ-ACKを含めて送信しないとしてよい。または、UE200は、同一PUCCHリソースに載せるはずのマルチキャストPDSCHのHARQ-ACKを送信しないとしてよい。或いは、UE200は、HARQフィードバックなしが指示されたDCIによってスケジュールしたMBS PDSCH（group-common PDSCH及びSPS group-common PDSCHを含んでよい）のみについてHARQ-ACKを送信しないとしてもよい。

【0118】

（動作例１－３）
UE200は、図６上側に示した従来のPRIとPUCCHリソースセットとの対応と、図６下側に示したHARQフィードバックのenable/disableが適用されない場合のPRIとPUCCHリソースセットとの対応例とを、動的に切り替えてもよい。

【0119】

図７は、動作例１－３に係るPUCCHリソースセットの切り替え動作の説明図である。MBS PDSCHの受信時のHARQフィードバックと、ユニキャストPDSCH受信時のHARQフィードバックとで、PUCCHリソースセットが動的に切り替えられてもよい。

【0120】

図７に示すように、UE200は、PDSCHに関連付けられるRNTIに基づいて、HARQフィードバックなし（disabled）を含むPUCCHリソースセット（実施例）と、HARQフィードバックなしを含まないPUCCHリソースセット（従来）を切り替えてよい。

【0121】

（動作例１－３－１）
MBS PDSCHのHARQフィードバック用として、ユニキャストのHARQフィードバック用とは別でPUCCH-Config（PUCCHリソース／リソースセットなど）が設定される場合、UE200は、次のように動作してよい。

【0122】

・MBS PDSCHに対するHARQフィードバック用のPUCCHリソースセットは、図６下側に示した例が設定される。

【0123】

MBS PDSCHに対するHARQ-ACK送信（DCI with CRC scrambled by G-RNTIによってスケジュールされたPDSCHのHARQ-ACK送信）は、図６下側のPUCCHリソースセットに従ってPUCCHリソースが決定されてよい。

【0124】

・MBS PDSCHに対するHARQフィードバック用のPUCCHリソースセットが従来または実施例であるか否かは、HARQフィードバックのenable/disableのDCIによる指定が、上位レイヤによって設定されるか否かに基づいて決定される。

【0125】

HARQフィードバックのenable/disableがDCIでのDCIによる指定が、上位レイヤによって設定された場合、実施例のPUCCHリソースセット（図６下側）が設定されてよい。この場合、MBS PDSCHに対するHARQ-ACK送信（DCI with CRC scrambled by G-RNTIによってスケジュールされたPDSCHのHARQ-ACK送信）は、図６下側のPUCCHリソースセットに従ってPUCCHリソースが決定されてよい。

【0126】

HARQフィードバックのenable/disableがDCIでのDCIによる指定が、上位レイヤによって設定されない場合、従来のPUCCHリソースセット（図６上側）が設定されてよい。この場合、MBS PDSCHに対するHARQ-ACK送信（DCI with CRC scrambled by G-RNTIによってスケジュールされたPDSCHのHARQ-ACK送信）は、図６上側のPUCCHリソースセットに従ってPUCCHリソースが決定されてよい。

【0127】

・ユニキャストPDSCHに対するHARQ-ACK用のPUCCHリソースセットは、従来、つまり、HARQフィードバックなしを含まないPRIとPUCCHリソースセットとの対応（図６上側、MBS用とは別のPRIとPUCCHリソースセットとの対応例でもよい）に従って設定されてよい。

【0128】

ユニキャストPDSCHに対するHARQ-ACK送信（DCI with CRC scrambled by other than G-RNTIによってスケジュールされたPDSCHのHARQ-ACK送信）は、図６上側のPUCCHリソースセットに従ってPUCCHリソースが決定されてよい。

【0129】

（動作例１－３－２）
MBS PDSCHのHARQフィードバック用として、ユニキャストのHARQフィードバック用とは別でPUCCH-Config（PUCCHリソース／リソースセットなど）が設定されない場合、UE200は、次のように動作してよい。

【0130】

・MBS PDSCHに対するHARQ-ACK送信（DCI with CRC scrambled by G-RNTIによってスケジュールされたPDSCHのHARQ-ACK送信）については、次のとおりでよい。

【0131】

・HARQフィードバックのenable/disableがDCIでのDCIによる指定が、上位レイヤによって設定された場合、設定されたPUCCHリソースセットを実施例（図６下側）として扱い、実施例のPUCCHリソースセットを用いてPUCCHリソースを決定する。

【0132】

・HARQフィードバックのenable/disableがDCIでのDCIによる指定が、上位レイヤによって設定されない場合、設定されたPUCCHリソースセットを従来（図６上側）として扱い、従来のPUCCHリソースセットを用いてPUCCHリソースを決定する。

【0133】

・ユニキャストPDSCHに対するHARQ-ACK送信（DCI with CRC scrambled by other than G-RNTIによってスケジュールされたPDSCHのHARQ-ACK送信）は、設定された従来（図６上側）のPUCCHリソースセットを用いてPUCCHリソースを決定する。

【0134】

（動作例１－４）
動作例１－１において示した以下のフィールドのうち、少なくとも２つを組み合わせてHARQフィードバックのenable/disableが指定されてもよい。なお、フィールド名及びビット数はこれに限られない。

【0135】

（i）TPC command for scheduled PUCCH：２ビット（3GPP TS38.213 7.2.1章）
（ii）PUCCH resource indicator：３ビット（3GPP TS38.213 9.2.3章）
（iii）PDSCH-to-HARQ_feedback timing indicator：３ビット（3GPP TS38.213 9.2.3章）
例えば、（ii）と（iii）とが所定値（例えば、両方とも0（zero））である場合、或いは（i）と（ii）と（iii）とが所定値（例えば、全て0（zero））である場合、HARQフィードバックのdisableが指定されると解釈されてよい。

【0136】

このように複数のフィールドを組み合わせることによって、動作例１－１と比較して、HARQフィードバックに関する指示の柔軟性（確実性）を高め得る。

【0137】

（動作例１－５）
例えば、上述した（ii）と（iii）とが所定値（例えば、両方とも0（zero））である場合に、HARQフィードバックのdisableが指定されるケースでは、HARQフィードバックのenable/disableがDCIによって指定されることが、上位レイヤによって設定され、（iii）PDSCH-to-HARQ_feedback timing indicatorによって「0」が通知された場合、HARQフィードバックなし（disabled）を含むPUCCHリソースセット（実施例、図６下側）が適用されてよい。そして（ii）PUCCH resource indicatorによって「0」が通知された場合、UE200は、HARQフィードバックのdisableが指定されたと判断してもよい。

【0138】

UE200は、PRIによってHARQフィードバックなしが指示された場合、PUCCHリソースによって送信されるHARQフィードバック（ACK/NACK）送信を停止してよい。または、HARQフィードバック送信に係る動作を開始しなくてよい。動作例１－２と同様に、UE200は、同一PUCCHリソースに載せるはずのユニキャストPDSCHのHARQ-ACKを含めて送信しないとしてよい。または、UE200は、同一PUCCHリソースに載せるはずのマルチキャストPDSCHのHARQ-ACKを送信しないとしてよい。或いは、UE200は、HARQフィードバックなしが指示されたDCIによってスケジュールしたMBS PDSCH（group-common PDSCH及びSPS group-common PDSCHを含んでよい）のみについてHARQ-ACKを送信しないとしてもよい。

【0139】

（動作例１－６）
図７に示したHARQフィードバックなし（disabled）を含むPUCCHリソースセット（実施例）と、HARQフィードバックなしを含まないPUCCHリソースセット（従来）との切り替えが動的に実行される場合、UE200は、PDSCHに関連付けられるRNTIと、(iii) PDSCH-to-HARQ_feedback timing indicator fieldとに基づいて、HARQフィードバックなしを含むPUCCHリソースセットと、HARQフィードバックなしを含まないPUCCHリソースセットとを動的に切り替えてよい。

【0140】

（動作例１－６－１）
MBS PDSCHのHARQフィードバック用として、ユニキャストのHARQフィードバック用とは別でPUCCH-Config（PUCCHリソース／リソースセットなど）が設定される場合、UE200は、次のように動作してよい。

【0141】

・MBS PDSCHに対するHARQフィードバック用のPUCCHリソースセットが従来または実施例であるか否かは、HARQフィードバックのenable/disableのDCIによる指定が、上位レイヤによって設定されるか否かに基づいて決定される。

【0142】

HARQフィードバックのenable/disableがDCIでのDCIによる指定が、上位レイヤによって設定された場合、PDSCH-to-HARQ_feedback timing indicator fieldが所定値（例えば、全て0（zero））であれば、実施例のPUCCHリソースセットが設定されてよい。そうでない場合、従来のPUCCHリソースセットが設定されてよい。

【0143】

HARQフィードバックのenable/disableがDCIでのDCIによる指定が、上位レイヤによって設定されない場合、従来のPUCCHリソースセット（図６上側）が設定されてよい。この場合、MBS PDSCHに対するHARQ-ACK送信（DCI with CRC scrambled by G-RNTIによってスケジュールされたPDSCHのHARQ-ACK送信）は、従来（図６上側）のPUCCHリソースセットに従ってPUCCHリソースが決定されてよい。

【0144】

・ユニキャストPDSCHに対するHARQ-ACK用のPUCCHリソースセットは、従来のPUCCHリソースセット（図６上側、MBS用とは別のPRIとPUCCHリソースセットとの対応例でもよい）に従って設定されてよい。

【0145】

ユニキャストPDSCHに対するHARQ-ACK送信（DCI with CRC scrambled by other than G-RNTIによってスケジュールされたPDSCHのHARQ-ACK送信）は、従来のPUCCHリソースセットに従ってPUCCHリソースが決定されてよい。

【0146】

（動作例１－６－２）
MBS PDSCHのHARQフィードバック用として、ユニキャストのHARQフィードバック用とは別でPUCCH-Config（PUCCHリソース／リソースセットなど）が設定されない場合、UE200は、次のように動作してよい。

【0147】

・MBS PDSCHに対するHARQ-ACK送信（DCI with CRC scrambled by G-RNTIによってスケジュールされたPDSCHのHARQ-ACK送信）については、次のとおりでよい。

【0148】

・HARQフィードバックのenable/disableがDCIでのDCIによる指定が、上位レイヤによって設定された場合、PDSCH-to-HARQ_feedback timing indicator fieldが所定値（例えば、全て0（zero））であれば、設定されたPUCCHリソースセットを実施例（図６下側）として扱い、実施例のPUCCHリソースセットを用いてPUCCHリソースを決定する。そうでない場合、設定されたPUCCHリソースセットを従来として扱い、従来のPUCCHリソースセットを用いてPUCCH リソースを決定する。

【0149】

・HARQフィードバックのenable/disableがDCIでのDCIによる指定が、上位レイヤによって設定されない場合、設定されたPUCCHリソースセットを従来として扱い、従来のPUCCH リソースセットを用いてPUCCHリソースを決定する。

【0150】

・ユニキャストPDSCHに対するHARQ-ACK送信（DCI with CRC scrambled by other than G-RNTIによってスケジュールされたPDSCHのHARQ-ACK送信）は、設定された従来のPUCCHリソースセットを用いてPUCCHリソースを決定する。

【0151】

（動作例１－７）
RRCのシグナリングを用いて、次のような設定がなされてよい。例えば、RRCのシグナリングによって、HARQフィードバックの無効（disable）が設定された場合、UE200は、DCIによるHARQフィードバックのenable/disableは、常に指示されないと想定してよい。

【0152】

一方、HARQフィードバックの有効（enable）が設定された場合、UE200は、DCIによるHARQフィードバックのenable/disableは、常に指示されると想定してよい。

【0153】

なお、HARQフィードバックの有効（enable）が設定された場合における、DCIによるHARQフィードバックのenable/disableの指示方法は、特に限定されず、上述したDCIのフィールドによる指定の方法であってもよく、異なっていてもよい。また、DCI formatまたはDCIにおけるフィールドのサイズは、HARQフィードバックの無効の場合と、HARQフィードバックの有効の場合とで、同じであってもよいし、異なっていてもよい。

【0154】

（動作例１－８）
HARQフィードバックのenable/disableは、RNTI毎に設定されてもよい。例えば、複数のG-RNTIが設定可能で、それぞれに対してHARQフィードバックのenable/disable が設定されてもよい。例えば、二つのG-RNTIが設定され、これらをそれぞれG-RNTI-1、G-RNTI-2とした場合、G-RNTI-1に対してHARQフィードバックがenableとして設定され、G-RNTI-2に対してHARQフィードバックがdisableとして設定されてもよい。UE200は、受信したPDSCHに関連付けられたRNTIがG-RNTI-1かG-RNTI-2かに基づいてHARQフィードバックを実行するか否かを判断してもよい。なお、RNTIは特に限定されず、C-RNTIまたはG-RNTIでもよい。

【0155】

（動作例１－９）
DCIによってHARQフィードバックのenable/disableを指示する方法は、RRCのシグナリングによって切り替えられてもよい。

【0156】

例えば、動作例１－１と、動作例１－４との指示方法が、RRCのシグナリングによって切り替えられてよい。

【0157】

（３．２）動作例２
本動作例では、DCIの受信に係る信号及び／または情報のうち、以下の少なくとも何れかに基づいて、HARQフィードバックのenable/disableが指定されてもよい。このような指定は、明示的ではなく、暗黙的な指示であってよい。

【0158】

（動作例２－１）
UE200は、DCI formatに基づいて、HARQフィードバックのenable/disableを想定してよい。例えば、UE200は、次のように動作してよい。

【0159】

・HARQフィードバックのenable/disableは、異なる別個のDCI formatとする
UE200は、所定のDCI formatによってスケジュールされたMBS PDSCHについてHARQフィードバックを実行し、当該所定DCI format以外のDCI formatによってスケジュールされたMBS PDSCHについてHARQフィードバックを実行しなくてもよい。

【0160】

・HARQフィードバックのenable用のformatには、動作例１－１などで示した（i）～（iii）の少なくとも何れかのフィールドが含まれてもよい。

【0161】

・HARQフィードバックのdisable用のformatには、動作例１－１などで示した（i）～（iii）のフィールドが含まれていなくてもよい。

【0162】

・ペイロードサイズ或いはformat indicatorによって、上述したDCI formatが区別されてもよい。

【0163】

（動作例２－２）
UE200は、DCIのCRCをスクランブルするRNTIに基づいて、HARQフィードバックのenable/disableを想定してよい。例えば、UE200は、次のように動作してよい。

【0164】

・G1-RNTI（G-RNTIの１つ、仮称）が定義され、HARQフィードバックが実行されるgroup-common PDSCH（group-common PDSCH with HARQ）のスケジューリングに用いられる。

【0165】

・G2-RNTI（G-RNTIの１つ、仮称）が定義され、HARQフィードバックが実行されないgroup-common PDSCH（group-common PDSCH without HARQ）のスケジューリングに用いられる。

【0166】

（動作例２－３）
UE200は、DCIの送信に用いられるCORESET及び／またはサーチスペースに基づいて、HARQフィードバックのenable/disableを想定してよい。

【0167】

（動作例２－４）
UE200は、DCIによって通知されるPDSCHリソース（時間／周波数／符号／空間）に基づいて、HARQフィードバックのenable/disableを想定してよい。

【0168】

（３．３）動作例３
本動作例では、複数のUE200向けのデータ配信（MBS）において、DCIに含まれる優先度に関するフィールドに基づいて、下りチャネルにおけるHARQのフィードバックの有効化または無効化が指定されてよい。

【0169】

具体的には、MBS PDSCHをスケジュールするDCI（またはDCI formatでもよい）におけるフィールドのうち、優先度（Priority）に係るフィールドに基づいてMBS PDSCH receptionに対応するHARQ feedback = {enable/disable}が指定されてよい。

【0170】

（動作例３－０）：優先度（Priority）に係るフィールドは，Priority indicator field（仮称でもよい）であってもよいし、Priorityの指示に係る別のフィールドであってもよい。Priority indicator fieldは、HARQに関する優先度の高さを示すことができれば、よく、１ビットを用いて優先度の高低が示されてもよいし、複数ビットを用いて優先度がより詳細に示されてもよい。HARQに関する優先度とは、例えば、HARQ自体の優先度或いはHARQフィードバックの優先度を示すものでもよい。

【0171】

Priority indicator fieldまたはPriorityの指示に係る別のフィールドによって指示される優先度は、スケーリングされたPDSCH（scheduled PDSCH）に対応するHARQフィードバックまたはPDCCHの優先度であってもよい。

【0172】

このような優先度に基づいて、動作例３－１～３－４の少なくとも何れかの方法によって、MBS PDSCH receptionに対応するHARQ feedback = {enable/disable}が指定されてもよい。

【0173】

（動作例３－１）
優先度が高い場合（例えば、priority indicator = 1）、HARQ feedback enableとする。

【0174】

（動作例３－２）
優先度が低い場合（例えば、priority indicator = 0）、HARQ feedback disableとする。

【0175】

図８は、動作例３－１及び動作例３－２に係るPriority indicatorとHARQフィードバックとの対応例を示す。図８に示すように、priority indicator = 1の場合、HARQ feedback enableとし、priority indicator = 0の場合、HARQ feedback disableとしてよい。

【0176】

（動作例３－３）
Priority indicatorの値（３値以上でもよい）毎に、HARQ feedbackがenableまたはdisableであるかが設定される。

【0177】

（動作例３－４）
Priority indicatorの値毎に（少なくとも0, 1の何れかについて）、DCIによってHARQ feedback enable/disable指示が行われるか否かが設定される。

【0178】

この場合、当該指示は、動作例１または動作例２の何れかに従って行われてもよい。

【0179】

また、DCI/DCI formatにPriority indicator fieldが含まれない場合、動作例３－５または３－６の少なくとも何れかの方法によって、MBS PDSCH receptionに対応するHARQ feedback = {enable/disable}が指定されてもよい。

【0180】

（動作例３－５）
RRC parameterによって設定されたHARQ feedbackのenable/disableが適用される。RRC parameterによってもenable/disableが設定されない場合には、所定値（例えば、enableまたはdisable）を想定してもよい。

【0181】

（動作例３－６）
RRC parameterによって設定されたHARQ feedback/PUCCHの優先度に基づいてenable/disableが適用される。RRC parameterによっても当該Priorityが設定されない場合、所定値（例えば、enableまたはdisable）を想定してもよい。

【0182】

本動作例によれば、UE200は、優先度に応じて適切なHARQ feedbackの有無を決定できる。

【0183】

なお、DCI/DCI formatにPriority indicator fieldが含まれない場合に限らず、RRC parameterによって設定されたHARQ feedback/PUCCHの優先度に基づいてenable/disableが適用されてもよい。この場合にも、RRC parameterによってもenable/disableが設定されない場合には、所定値（例えば、enableまたはdisable）を想定してもよい。

【0184】

（３．４）動作例４
本動作例では、下りデータチャネル（PDSCH）に半固定的なスケジューリング（SPS）が適用される場合、端末グループに共通である下り制御チャネル（group-common PDCCH）を介したDCIによるHARQのフィードバックの有効化または無効化の指示が、当該DCIの直後のPDSCHの受信と、後続のPDSCHとの受信に適用されると想定してよい。

【0185】

図９は、動作例４に係るDCIとPDSCHとの対応関係の例を示す。Multicast SPS PDSCH receptionの場合、group-common PDCCHのactivation DCIにおけるHARQ feedback enable/disable指示が、group-common PDCCHのactivation DCIの直後のPDSCH reception、及び後続のSPS PDSCH receptionに適用されてよい。

【0186】

（動作例４－１）
group-common PDCCHのactivation DCIによる当該指示は、動作例１～３の何れに従って行われてもよい。

【0187】

（動作例４－２）
group-common PDCCHのactivation DCIによる当該指示は、activationの特別なフィールド（special fields）に使われないDCIのフィールドを用いて行われてもよい。

【0188】

（動作例４－３）
UE-specific PDCCHのDCIによってmulticast SPS PDSCHのactivationが行われる場合、後続のSPS PDSCH receptionに対するHARQ feedbackのenable/disableが、当該UE-specific PDCCHのactivation DCIにおいて指示されてもよい。

【0189】

当該指示は、動作例１～３の何れに従って行われてもよい。また、当該UE-specific PDCCHのactivation DCIの直後のPDSCH receptionは、HARQ feedback enableとしてもよく、SPS PDSCH receptionに対するHARQ feedbackのenable/disable指示に従ってもよい。

【0190】

なお、multicast SPS PDSCHのHARQ enable/disableの指示は、group-common PDCCHのactivation DCIのみによって行われてもよいし、group-common/UE-specific PDCCHのactivation DCIの何れによって行われてもよい。

【0191】

また、「直後のPDSCH reception」は、SPS PDSCH reception with corresponding PDCCHを意味してもよく、「後続のSPS PDSCH reception」は、SPS PDSCH reception without corresponding PDCCHを意味してもよい。

【0192】

本動作例によれば、信頼性が高い周期送信に対してはHARQ feedbackを要求し、信頼性が低い送信にはHARQ feedbackを要求しない構成を容易に設定できる。また、SPS receptionの全てに対して共通の設定にでき、UE200の実装を簡素化し得る。

【0193】

（３．５）動作例５
本動作例では、下りデータチャネル（PDSCH）に半固定的なスケジューリング（SPS）が適用される場合、端末グループに共通である下り制御チャネル（group-common PDCCH）介したDCIによるHARQのフィードバックの有効化または無効化の指示が、当該DCIの直後のPDSCHを除く、後続のPDSCHの受信に適用されると想定してよい。

【0194】

図１０は、動作例５に係るDCIとPDSCHとの対応関係の例を示す。Multicast SPS PDSCH receptionの場合、group-common PDCCHのactivation DCIにおけるHARQ feedback enable/disable指示が、後続のSPS PDSCH receptionにのみ適用され、group-common PDCCHのactivation DCIの直後のPDSCH receptionについては、HARQ feedbackを所定値（例えば、enable）としてよい。

【0195】

（動作例５－１）
group-common PDCCHのactivation DCIによる当該指示は、動作例１～３の何れに従って行われてもよい。

【0196】

（動作例５－２）
group-common PDCCHのactivation DCIによる当該指示は、activationの特別なフィールド（special fields）に使われないDCIのフィールドを用いて行われてもよい。

【0197】

（動作例５－３）
UE-specific PDCCHのDCIによってmulticast SPS PDSCHのactivationが行われる場合、後続のSPS PDSCH receptionに対するHARQ feedbackのenable/disableが，当該UE-specific PDCCHのactivation DCIにおいて指示されてもよい。

【0198】

当該指示は、動作例１～３の何れに従って行われてもよい。また、当該UE-specific PDCCHのactivation DCIの直後のPDSCH receptionは、HARQ feedback enableとしてもよく、SPS PDSCH receptionに対するHARQ feedbackのenable/disable指示に従ってもよい。

【0199】

なお、multicast SPS PDSCHのHARQ enable/disableの指示は、group-common PDCCHのactivation DCIのみによって行われてもよいし、group-common/UE-specific PDCCHのactivation DCIの何れかによって行われてもよい。

【0200】

また、「直後のPDSCH reception」は、SPS PDSCH reception with corresponding PDCCHを意味してもよく、「後続のSPS PDSCH reception」は、SPS PDSCH reception without corresponding PDCCHを意味してもよい。

【0201】

本動作例によれば、gNB100は、PDSCHのactivationの成功または失敗を必ず把握できるため、通信品質の向上を図り得る。

【0202】

（３．６）動作例６
本動作例では、半固定的なスケジューリング（SPS）が適用された下りデータチャネル（PDSCH）を解放する場合、当該PDSCHの受信時に適用されたHARQのフィードバックの有効化または無効化に基づいて、当該PDSCHの解放時に適用されるHARQのフィードバックが有効または無効であるかを決定してよい。

【0203】

具体的には、Multicast SPS PDSCHのrelease (deactivation)に対するHARQ feedbackがenable/disableの何れであるかは、以下の何れかの動作例によって決定されてよい。

【0204】

（動作例６－１）
deactivationに対するHARQ feedbackのenable/disableは、動作例１～５の何れに従って行われる。

【0205】

（動作例６－２）
Multicast SPS PDSCHのrelease (deactivation)と対応するSPS PDSCH receptionに係るHARQ feedbackのenable/disableと同じとする。

【0206】

（動作例６－３）
必ず所定値（例えば、enable）とする。

【0207】

（動作例６－４）
Multicast SPS PDSCHのrelease (deactivation)と対応するSPS PDSCH activationに係るHARQ feedbackのenable/disableと同じとする。

【0208】

なお、DCIは、Group-commonのrelease (deactivation) DCIであってもよいし、UE-specificのrelease (deactivation) DCIであってもよい。

【0209】

本動作例によれば、Multicast SPS PDSCHのrelease (deactivation)に対するHARQ feedback動作をUE200に対して明確に指示できる。また、必ずenableとなる場合、gNB100は、PDSCHのactivationの成功または失敗を必ず把握できるため、通信品質の向上を図り得る。一方、enable/disableが条件によって決定する場合、状況に応じた適切なフィードバックを実現し得る。

【0210】

（３．７）動作例７
本動作例では、HARQ feedback enable/disableの指定に併せて、ACK/NACK feedbackまたはNACK-only feedbackが指定されてもよい。

【0211】

具体的には、当該指定は、動作例１～６の何れに従って行われてもよい。

【0212】

（３．８）変更例
上述した動作例は、矛盾が生じない限り、組み合わせて複合的に適用されてもよい。また、上述したように、スロットなどの時間領域を示す用語は、サブスロットなど、他の時間領域を示す用語に読み替えられてよい。

【0213】

上述した動作例は、複数のUEへの同時送信（配信）を対象としたMBSに関連していたが、MBSの対象となるUEは、必ずしも常に複数でなくてもよく、group-common PDSCHを用いるなど、MBSに従った動作が実行されていれば、特定または不特定の複数のUEとは、実質的に１つとなる場合を含んでよく、複数でなくてもよい。

【0214】

（４）作用・効果
上述した実施形態によれば、以下の作用効果が得られる。具体的には、動作例１～動作例７に係るUE200によれば、MBSに係る下りチャネル、具体的には、group-common PDSCHなどに対するHARQフィードバックを効率的に有効化／無効化（enable/disable）できる。

【0215】

これにより、UE200は、HARQフィードバックを有効化及び／または無効化されるタイミングを迅速かつ確実に認識し得る。

【0216】

本実施形態では、UE200は、DCIに含まれる特定のフィールド、例えば、PUCCH resource indicator（PRI）フィールドに基づいて、下りチャネルにおけるHARQのフィードバックのenable/disableの少なくとも何れかを実行してよい。このため、既存のDCIを用いつつ、確実にHARQフィードバックのenable/disableを実現し得る。

【0217】

本実施形態では、UE200は、上位レイヤ（例えば、RRC）のシグナリングなどによって、DCIによるHARQフィードバックのenable/disableが指定されることを認識してよい。このため、柔軟かつ確実にHARQフィードバックのenable/disableを実現し得る。

【0218】

本実施形態では、UE200は、DCIに関連するフォーマット、識別情報、リソースまたはサーチスペースの少なくとも何れかに基づいて、下りチャネルにおけるHARQフィードバックのenable/disableの少なくとも何れかを実行してもよい。このため、より柔軟かつ確実にHARQフィードバックのenable/disableを実現し得る。

【0219】

本実施形態では、複数のUE200向けのデータ配信（MBS）において、DCIに含まれる優先度に関するフィールドに基づいて、下りチャネルにおけるHARQのフィードバックの有効化または無効化が指定されてよい。このため、UE200は、優先度に応じて適切なHARQ feedbackの有無を決定できる。

【0220】

本実施形態では、下りデータチャネル（PDSCH）に半固定的なスケジューリング（SPS）が適用される場合、端末グループに共通である下り制御チャネル（group-common PDCCH）を介したDCIによるHARQのフィードバックの有効化または無効化の指示が、当該DCIの直後のPDSCHの受信と、後続のPDSCHとの受信に適用されると想定してよい。このため、信頼性が高い周期送信に対してはHARQ feedbackを要求し、信頼性が低い送信にはHARQ feedbackを要求しない構成を容易に設定できる。

【0221】

本実施形態では、下りデータチャネル（PDSCH）に半固定的なスケジューリング（SPS）が適用される場合、端末グループに共通である下り制御チャネル（group-common PDCCH）介したDCIによるHARQのフィードバックの有効化または無効化の指示が、当該DCIの直後のPDSCHを除く、後続のPDSCHの受信に適用されると想定してよい。このため、gNB100は、PDSCHのactivationの成功または失敗を必ず把握できるため、通信品質の向上を図り得る。

【0222】

本実施形態では、半固定的なスケジューリング（SPS）が適用された下りデータチャネル（PDSCH）を解放する場合、当該PDSCHの受信時に適用されたHARQのフィードバックの有効化または無効化に基づいて、当該PDSCHの解放時に適用されるHARQのフィードバックが有効または無効であるかを決定してよい。このため、Multicast SPS PDSCHのrelease (deactivation)に対するHARQ feedback動作をUE200に対して明確に指示できる。

【0223】

（５）その他の実施形態
以上、実施形態について説明したが、当該実施形態の記載に限定されるものではなく、種々の変形及び改良が可能であることは、当業者には自明である。

【0224】

例えば、上述した実施形態では、下りチャネルとして、PDCCH及びPDSCHの名称が用いられていたが、下り制御チャネルまたは下りデータチャネル（共有チャネルでもよい）であれば、別の名称で呼ばれてもよい。

【0225】

また、上述した記載において、設定（configure）、アクティブ化（activate）、更新（update）、指示（indicate）、有効化（enable）、指定（specify）、選択（select）、は互いに読み替えられてもよい。同様に、リンクする（link）、関連付ける（associate）、対応する（correspond）、マップする（map）、は互いに読み替えられてもよく、配置する（allocate）、割り当てる（assign）、モニタする（monitor）、マップする（map）、も互いに読み替えられてもよい。

【0226】

さらに、固有（specific）、個別（dedicated）、UE固有、UE個別、は互いに読み替えられてもよい。同様に、共通（common）、共有（shared）、グループ共通（group-common）、ＵＥ共通、ＵＥ共有、は互いに読み替えられてもよい。

【0227】

また、上述した実施形態の説明に用いたブロック構成図（図４）は、機能単位のブロックを示している。これらの機能ブロック（構成部）は、ハードウェア及びソフトウェアの少なくとも一方の任意の組み合わせによって実現される。また、各機能ブロックの実現方法は特に限定されない。すなわち、各機能ブロックは、物理的または論理的に結合した１つの装置を用いて実現されてもよいし、物理的または論理的に分離した２つ以上の装置を直接的または間接的に（例えば、有線、無線などを用いて）接続し、これら複数の装置を用いて実現されてもよい。機能ブロックは、上記１つの装置または上記複数の装置にソフトウェアを組み合わせて実現されてもよい。

【0228】

機能には、判断、決定、判定、計算、算出、処理、導出、調査、探索、確認、受信、送信、出力、アクセス、解決、選択、選定、確立、比較、想定、期待、見做し、報知（broadcasting）、通知（notifying）、通信（communicating）、転送（forwarding）、構成（configuring）、再構成（reconfiguring）、割り当て（allocating、mapping）、割り振り（assigning）などがあるが、これらに限られない。例えば、送信を機能させる機能ブロック（構成部）は、送信部（transmitting unit）や送信機（transmitter）と呼称される。何れも、上述したとおり、実現方法は特に限定されない。

【0229】

さらに、上述したgNB100及びUE200は、本開示の無線通信方法の処理を行うコンピュータとして機能してもよい。図１１は、当該装置のハードウェア構成の一例を示す図である。図１１に示すように、当該装置は、プロセッサ1001、メモリ1002、ストレージ1003、通信装置1004、入力装置1005、出力装置1006及びバス1007などを含むコンピュータ装置として構成されてもよい。

【0230】

なお、以下の説明では、「装置」という文言は、回路、デバイス、ユニットなどに読み替えることができる。当該装置のハードウェア構成は、図に示した各装置を１つまたは複数含むように構成されてもよいし、一部の装置を含まずに構成されてもよい。

【0231】

当該装置の各機能ブロック（図４参照）は、当該コンピュータ装置の何れかのハードウェア要素、または当該ハードウェア要素の組み合わせによって実現される。

【0232】

また、当該装置における各機能は、プロセッサ1001、メモリ1002などのハードウェア上に所定のソフトウェア（プログラム）を読み込ませることによって、プロセッサ1001が演算を行い、通信装置1004による通信を制御したり、メモリ1002及びストレージ1003におけるデータの読み出し及び書き込みの少なくとも一方を制御したりすることによって実現される。

【0233】

プロセッサ1001は、例えば、オペレーティングシステムを動作させてコンピュータ全体を制御する。プロセッサ1001は、周辺装置とのインタフェース、制御装置、演算装置、レジスタなどを含む中央処理装置（CPU）によって構成されてもよい。

【0234】

また、プロセッサ1001は、プログラム（プログラムコード）、ソフトウェアモジュール、データなどを、ストレージ1003及び通信装置1004の少なくとも一方からメモリ1002に読み出し、これらに従って各種の処理を実行する。プログラムとしては、上述の実施の形態において説明した動作の少なくとも一部をコンピュータに実行させるプログラムが用いられる。さらに、上述の各種処理は、１つのプロセッサ1001によって実行されてもよいし、２つ以上のプロセッサ1001により同時または逐次に実行されてもよい。プロセッサ1001は、１以上のチップによって実装されてもよい。なお、プログラムは、電気通信回線を介してネットワークから送信されてもよい。

【0235】

メモリ1002は、コンピュータ読み取り可能な記録媒体であり、例えば、Read Only Memory（ROM）、Erasable Programmable ROM（EPROM）、Electrically Erasable Programmable ROM（EEPROM）、Random Access Memory（RAM）などの少なくとも１つによって構成されてもよい。メモリ1002は、レジスタ、キャッシュ、メインメモリ（主記憶装置）などと呼ばれてもよい。メモリ1002は、本開示の一実施形態に係る方法を実行可能なプログラム（プログラムコード）、ソフトウェアモジュールなどを保存することができる。

【0236】

ストレージ1003は、コンピュータ読み取り可能な記録媒体であり、例えば、Compact Disc ROM（CD-ROM）などの光ディスク、ハードディスクドライブ、フレキシブルディスク、光磁気ディスク（例えば、コンパクトディスク、デジタル多用途ディスク、Blu-ray（登録商標）ディスク）、スマートカード、フラッシュメモリ（例えば、カード、スティック、キードライブ）、フロッピー（登録商標）ディスク、磁気ストリップなどの少なくとも１つによって構成されてもよい。ストレージ1003は、補助記憶装置と呼ばれてもよい。上述の記録媒体は、例えば、メモリ1002及びストレージ1003の少なくとも一方を含むデータベース、サーバその他の適切な媒体であってもよい。

【0237】

通信装置1004は、有線ネットワーク及び無線ネットワークの少なくとも一方を介してコンピュータ間の通信を行うためのハードウェア（送受信デバイス）であり、例えばネットワークデバイス、ネットワークコントローラ、ネットワークカード、通信モジュールなどともいう。

【0238】

通信装置1004は、例えば周波数分割複信（Frequency Division Duplex：FDD）及び時分割複信（Time Division Duplex：TDD）の少なくとも一方を実現するために、高周波スイッチ、デュプレクサ、フィルタ、周波数シンセサイザなどを含んで構成されてもよい。

【0239】

入力装置1005は、外部からの入力を受け付ける入力デバイス（例えば、キーボード、マウス、マイクロフォン、スイッチ、ボタン、センサなど）である。出力装置1006は、外部への出力を実施する出力デバイス（例えば、ディスプレイ、スピーカー、LEDランプなど）である。なお、入力装置1005及び出力装置1006は、一体となった構成（例えば、タッチパネル）であってもよい。

【0240】

また、プロセッサ1001及びメモリ1002などの各装置は、情報を通信するためのバス1007で接続される。バス1007は、単一のバスを用いて構成されてもよいし、装置間ごとに異なるバスを用いて構成されてもよい。

【0241】

さらに、当該装置は、マイクロプロセッサ、デジタル信号プロセッサ（Digital Signal Processor： DSP）、Application Specific Integrated Circuit（ASIC）、Programmable Logic Device（PLD）、Field Programmable Gate Array（FPGA）などのハードウェアを含んで構成されてもよく、当該ハードウェアにより、各機能ブロックの一部または全てが実現されてもよい。例えば、プロセッサ1001は、これらのハードウェアの少なくとも１つを用いて実装されてもよい。

【0242】

また、情報の通知は、本開示において説明した態様／実施形態に限られず、他の方法を用いて行われてもよい。例えば、情報の通知は、物理レイヤシグナリング（例えば、Downlink Control Information（DCI）、Uplink Control Information（UCI）、上位レイヤシグナリング（例えば、RRCシグナリング、Medium Access Control（MAC）シグナリング、報知情報（Master Information Block（MIB）、System Information Block（SIB））、その他の信号またはこれらの組み合わせによって実施されてもよい。また、RRCシグナリングは、RRCメッセージと呼ばれてもよく、例えば、RRC接続セットアップ（RRC Connection Setup）メッセージ、RRC接続再構成（RRC Connection Reconfiguration）メッセージなどであってもよい。

【0243】

本開示において説明した各態様／実施形態は、Long Term Evolution（LTE）、LTE-Advanced（LTE-A）、SUPER 3G、IMT-Advanced、4th generation mobile communication system（4G）、5th generation mobile communication system（5G）、Future Radio Access（FRA）、New Radio（NR）、W-CDMA（登録商標）、GSM（登録商標）、CDMA2000、Ultra Mobile Broadband（UMB）、IEEE 802.11（Wi-Fi（登録商標））、IEEE 802.16（WiMAX（登録商標））、IEEE 802.20、Ultra-WideBand（UWB）、Bluetooth（登録商標）、その他の適切なシステムを利用するシステム及びこれらに基づいて拡張された次世代システムの少なくとも一つに適用されてもよい。また、複数のシステムが組み合わされて（例えば、LTE及びLTE-Aの少なくとも一方と5Gとの組み合わせなど）適用されてもよい。

【0244】

本開示において説明した各態様／実施形態の処理手順、シーケンス、フローチャートなどは、矛盾の無い限り、順序を入れ替えてもよい。例えば、本開示において説明した方法については、例示的な順序を用いて様々なステップの要素を提示しており、提示した特定の順序に限定されない。

【0245】

本開示において基地局によって行われるとした特定動作は、場合によってはその上位ノード（upper node）によって行われることもある。基地局を有する１つまたは複数のネットワークノード（network nodes）からなるネットワークにおいて、端末との通信のために行われる様々な動作は、基地局及び基地局以外の他のネットワークノード（例えば、MMEまたはS-GWなどが考えられるが、これらに限られない）の少なくとも１つによって行われ得ることは明らかである。上記において基地局以外の他のネットワークノードが１つである場合を例示したが、複数の他のネットワークノードの組み合わせ（例えば、MME及びS-GW）であってもよい。

【0246】

情報、信号（情報等）は、上位レイヤ（または下位レイヤ）から下位レイヤ（または上位レイヤ）へ出力され得る。複数のネットワークノードを介して入出力されてもよい。

【0247】

入出力された情報は、特定の場所（例えば、メモリ）に保存されてもよいし、管理テーブルを用いて管理してもよい。入出力される情報は、上書き、更新、または追記され得る。出力された情報は削除されてもよい。入力された情報は他の装置へ送信されてもよい。

【0248】

判定は、１ビットで表される値（０か１か）によって行われてもよいし、真偽値（Boolean：trueまたはfalse）によって行われてもよいし、数値の比較（例えば、所定の値との比較）によって行われてもよい。

【0249】

本開示において説明した各態様／実施形態は単独で用いてもよいし、組み合わせて用いてもよいし、実行に伴って切り替えて用いてもよい。また、所定の情報の通知（例えば、「Ｘであること」の通知）は、明示的に行うものに限られず、暗黙的（例えば、当該所定の情報の通知を行わない）ことによって行われてもよい。

【0250】

ソフトウェアは、ソフトウェア、ファームウェア、ミドルウェア、マイクロコード、ハードウェア記述言語と呼ばれるか、他の名称で呼ばれるかを問わず、命令、命令セット、コード、コードセグメント、プログラムコード、プログラム、サブプログラム、ソフトウェアモジュール、アプリケーション、ソフトウェアアプリケーション、ソフトウェアパッケージ、ルーチン、サブルーチン、オブジェクト、実行可能ファイル、実行スレッド、手順、機能などを意味するよう広く解釈されるべきである。

【0251】

また、ソフトウェア、命令、情報などは、伝送媒体を介して送受信されてもよい。例えば、ソフトウェアが、有線技術（同軸ケーブル、光ファイバケーブル、ツイストペア、デジタル加入者回線（Digital Subscriber Line：DSL）など）及び無線技術（赤外線、マイクロ波など）の少なくとも一方を使用してウェブサイト、サーバ、または他のリモートソースから送信される場合、これらの有線技術及び無線技術の少なくとも一方は、伝送媒体の定義内に含まれる。

【0252】

本開示において説明した情報、信号などは、様々な異なる技術の何れかを使用して表されてもよい。例えば、上記の説明全体に渡って言及され得るデータ、命令、コマンド、情報、信号、ビット、シンボル、チップなどは、電圧、電流、電磁波、磁界若しくは磁性粒子、光場若しくは光子、またはこれらの任意の組み合わせによって表されてもよい。

【0253】

なお、本開示において説明した用語及び本開示の理解に必要な用語については、同一のまたは類似する意味を有する用語と置き換えてもよい。例えば、チャネル及びシンボルの少なくとも一方は信号（シグナリング）であってもよい。また、信号はメッセージであってもよい。また、コンポーネントキャリア（Component Carrier：CC）は、キャリア周波数、セル、周波数キャリアなどと呼ばれてもよい。

【0254】

本開示において使用する「システム」及び「ネットワーク」という用語は、互換的に使用される。

【0255】

また、本開示において説明した情報、パラメータなどは、絶対値を用いて表されてもよいし、所定の値からの相対値を用いて表されてもよいし、対応する別の情報を用いて表されてもよい。例えば、無線リソースはインデックスによって指示されるものであってもよい。

【0256】

上述したパラメータに使用する名称はいかなる点においても限定的な名称ではない。さらに、これらのパラメータを使用する数式等は、本開示で明示的に開示したものと異なる場合もある。様々なチャネル（例えば、PUCCH、PDCCHなど）及び情報要素は、あらゆる好適な名称によって識別できるため、これらの様々なチャネル及び情報要素に割り当てている様々な名称は、いかなる点においても限定的な名称ではない。

【0257】

本開示においては、「基地局（Base Station：BS）」、「無線基地局」、「固定局（fixed station）」、「NodeB」、「eNodeB（eNB）」、「gNodeB（gNB）」、「アクセスポイント（access point）」、「送信ポイント（transmission point）」、「受信ポイント（reception point）、「送受信ポイント（transmission/reception point）」、「セル」、「セクタ」、「セルグループ」、「キャリア」、「コンポーネントキャリア」などの用語は、互換的に使用され得る。基地局は、マクロセル、スモールセル、フェムトセル、ピコセルなどの用語で呼ばれる場合もある。

【0258】

基地局は、１つまたは複数（例えば、３つ）のセル（セクタとも呼ばれる）を収容することができる。基地局が複数のセルを収容する場合、基地局のカバレッジエリア全体は複数のより小さいエリアに区分でき、各々のより小さいエリアは、基地局サブシステム（例えば、屋内用の小型基地局（Remote Radio Head：RRH）によって通信サービスを提供することもできる。

【0259】

「セル」または「セクタ」という用語は、このカバレッジにおいて通信サービスを行う基地局、及び基地局サブシステムの少なくとも一方のカバレッジエリアの一部または全体を指す。

【0260】

本開示においては、「移動局（Mobile Station：MS）」、「ユーザ端末（user terminal）」、「ユーザ装置（User Equipment：UE）」、「端末」などの用語は、互換的に使用され得る。

【0261】

移動局は、当業者によって、加入者局、モバイルユニット、加入者ユニット、ワイヤレスユニット、リモートユニット、モバイルデバイス、ワイヤレスデバイス、ワイヤレス通信デバイス、リモートデバイス、モバイル加入者局、アクセス端末、モバイル端末、ワイヤレス端末、リモート端末、ハンドセット、ユーザエージェント、モバイルクライアント、クライアント、またはいくつかの他の適切な用語で呼ばれる場合もある。

【0262】

基地局及び移動局の少なくとも一方は、送信装置、受信装置、通信装置などと呼ばれてもよい。なお、基地局及び移動局の少なくとも一方は、移動体に搭載されたデバイス、移動体自体などであってもよい。当該移動体は、乗り物（例えば、車、飛行機など）であってもよいし、無人で動く移動体（例えば、ドローン、自動運転車など）であってもよいし、ロボット（有人型または無人型）であってもよい。なお、基地局及び移動局の少なくとも一方は、必ずしも通信動作時に移動しない装置も含む。例えば、基地局及び移動局の少なくとも一方は、センサなどのInternet of Things（IoT）機器であってもよい。

【0263】

また、本開示における基地局は、移動局（ユーザ端末、以下同）として読み替えてもよい。例えば、基地局及び移動局間の通信を、複数の移動局間の通信（例えば、Device-to-Device（D2D）、Vehicle-to-Everything（V2X）などと呼ばれてもよい）に置き換えた構成について、本開示の各態様／実施形態を適用してもよい。この場合、基地局が有する機能を移動局が有する構成としてもよい。また、「上り」及び「下り」などの文言は、端末間通信に対応する文言（例えば、「サイド（side）」）で読み替えられてもよい。例えば、上りチャネル、下りチャネルなどは、サイドチャネル（またはサイドリンク）で読み替えられてもよい。

【0264】

同様に、本開示における移動局は、基地局として読み替えてもよい。この場合、移動局が有する機能を基地局が有する構成としてもよい。
無線フレームは時間領域において１つまたは複数のフレームによって構成されてもよい。時間領域において１つまたは複数の各フレームはサブフレームと呼ばれてもよい。サブフレームはさらに時間領域において１つまたは複数のスロットによって構成されてもよい。サブフレームは、ニューメロロジー（numerology）に依存しない固定の時間長（例えば、1ms）であってもよい。

【0265】

ニューメロロジーは、ある信号またはチャネルの送信及び受信の少なくとも一方に適用される通信パラメータであってもよい。ニューメロロジーは、例えば、サブキャリア間隔（SubCarrier Spacing：SCS）、帯域幅、シンボル長、サイクリックプレフィックス長、送信時間間隔（Transmission Time Interval：TTI）、TTIあたりのシンボル数、無線フレーム構成、送受信機が周波数領域において行う特定のフィルタリング処理、送受信機が時間領域において行う特定のウィンドウイング処理などの少なくとも１つを示してもよい。

【0266】

スロットは、時間領域において１つまたは複数のシンボル（Orthogonal Frequency Division Multiplexing（OFDM））シンボル、Single Carrier Frequency Division Multiple Access（SC-FDMA）シンボルなど）で構成されてもよい。スロットは、ニューメロロジーに基づく時間単位であってもよい。

【0267】

スロットは、複数のミニスロットを含んでもよい。各ミニスロットは、時間領域において１つまたは複数のシンボルによって構成されてもよい。また、ミニスロットは、サブスロットと呼ばれてもよい。ミニスロットは、スロットよりも少ない数のシンボルによって構成されてもよい。ミニスロットより大きい時間単位で送信されるPDSCH（またはPUSCH）は、PDSCH（またはPUSCH）マッピングタイプＡと呼ばれてもよい。ミニスロットを用いて送信されるPDSCH（またはPUSCH）は、PDSCH（またはPUSCH）マッピングタイプＢと呼ばれてもよい。

【0268】

無線フレーム、サブフレーム、スロット、ミニスロット及びシンボルは、何れも信号を伝送する際の時間単位を表す。無線フレーム、サブフレーム、スロット、ミニスロット及びシンボルは、それぞれに対応する別の呼称が用いられてもよい。

【0269】

例えば、１サブフレームは送信時間間隔（TTI）と呼ばれてもよいし、複数の連続したサブフレームがTTIと呼ばれてよいし、１スロットまたは１ミニスロットがTTIと呼ばれてもよい。つまり、サブフレーム及びTTIの少なくとも一方は、既存のLTEにおけるサブフレーム（1ms）であってもよいし、1msより短い期間（例えば、１－１３シンボル）であってもよいし、1msより長い期間であってもよい。なお、TTIを表す単位は、サブフレームではなくスロット、ミニスロットなどと呼ばれてもよい。

【0270】

ここで、TTIは、例えば、無線通信におけるスケジューリングの最小時間単位のことをいう。例えば、LTEシステムでは、基地局が各ユーザ端末に対して、無線リソース（各ユーザ端末において使用することが可能な周波数帯域幅、送信電力など）を、TTI単位で割り当てるスケジューリングを行う。なお、TTIの定義はこれに限られない。

【0271】

TTIは、チャネル符号化されたデータパケット（トランスポートブロック）、コードブロック、コードワードなどの送信時間単位であってもよいし、スケジューリング、リンクアダプテーションなどの処理単位となってもよい。なお、TTIが与えられたとき、実際にトランスポトランスポートブロックロック、コードワードなどがマッピングされる時間区間（例えば、シンボル数）は、当該TTIよりも短くてもよい。

【0272】

なお、１スロットまたは１ミニスロットがTTIと呼ばれる場合、１以上のTTI（すなわち、１以上のスロットまたは１以上のミニスロット）が、スケジューリングの最小時間単位となってもよい。また、当該スケジューリングの最小時間単位を構成するスロット数（ミニスロット数）は制御されてもよい。

【0273】

1msの時間長を有するTTIは、通常TTI（LTE Rel.8-12におけるTTI）、ノーマルTTI、ロングTTI、通常サブフレーム、ノーマルサブフレーム、ロングサブフレーム、スロットなどと呼ばれてもよい。通常TTIより短いTTIは、短縮TTI、ショートTTI、部分TTI（partialまたはfractional TTI）、短縮サブフレーム、ショートサブフレーム、ミニスロット、サブスロット、スロットなどと呼ばれてもよい。

【0274】

なお、ロングTTI（例えば、通常TTI、サブフレームなど）は、1msを超える時間長を有するTTIで読み替えてもよいし、ショートTTI（例えば、短縮TTIなど）は、ロングTTIのTTI長未満かつ1ms以上のTTI長を有するTTIで読み替えてもよい。

【0275】

リソースブロック（RB）は、時間領域及び周波数領域のリソース割当単位であり、周波数領域において、１つまたは複数個の連続した副搬送波（subcarrier）を含んでもよい。RBに含まれるサブキャリアの数は、ニューメロロジーに関わらず同じであってもよく、例えば１２であってもよい。RBに含まれるサブキャリアの数は、ニューメロロジーに基づいて決定されてもよい。

【0276】

また、RBの時間領域は、１つまたは複数個のシンボルを含んでもよく、１スロット、１ミニスロット、１サブフレーム、または１TTIの長さであってもよい。１TTI、１サブフレームなどは、それぞれ１つまたは複数のリソースブロックで構成されてもよい。

【0277】

なお、１つまたは複数のRBは、物理リソースブロック（Physical RB：PRB）、サブキャリアグループ（Sub-Carrier Group：SCG）、リソースエレメントグループ（Resource Element Group：REG）、PRBペア、RBペアなどと呼ばれてもよい。

【0278】

また、リソースブロックは、１つまたは複数のリソースエレメント（Resource Element：RE）によって構成されてもよい。例えば、１REは、１サブキャリア及び１シンボルの無線リソース領域であってもよい。

【0279】

帯域幅部分（Bandwidth Part：BWP）（部分帯域幅などと呼ばれてもよい）は、あるキャリアにおいて、あるニューメロロジー用の連続する共通RB（common resource blocks）のサブセットのことを表してもよい。ここで、共通RBは、当該キャリアの共通参照ポイントを基準としたRBのインデックスによって特定されてもよい。PRBは、あるBWPで定義され、当該BWP内で番号付けされてもよい。

【0280】

BWPには、UL用のBWP（UL BWP）と、DL用のBWP（DL BWP）とが含まれてもよい。UEに対して、１キャリア内に１つまたは複数のBWPが設定されてもよい。

【0281】

設定されたBWPの少なくとも１つがアクティブであってもよく、UEは、アクティブなBWPの外で所定の信号／チャネルを送受信することを想定しなくてもよい。なお、本開示における「セル」、「キャリア」などは、「BWP」で読み替えられてもよい。

【0282】

上述した無線フレーム、サブフレーム、スロット、ミニスロット及びシンボルなどの構造は例示に過ぎない。例えば、無線フレームに含まれるサブフレームの数、サブフレームまたは無線フレームあたりのスロットの数、スロット内に含まれるミニスロットの数、スロットまたはミニスロットに含まれるシンボル及びRBの数、RBに含まれるサブキャリアの数、並びにTTI内のシンボル数、シンボル長、サイクリックプレフィックス（Cyclic Prefix：CP）長などの構成は、様々に変更することができる。

【0283】

「接続された（connected）」、「結合された(coupled)」という用語、またはこれらのあらゆる変形は、２またはそれ以上の要素間の直接的または間接的なあらゆる接続または結合を意味し、互いに「接続」または「結合」された２つの要素間に１またはそれ以上の中間要素が存在することを含むことができる。要素間の結合または接続は、物理的なものであっても、論理的なものであっても、或いはこれらの組み合わせであってもよい。例えば、「接続」は「アクセス」で読み替えられてもよい。本開示で使用する場合、２つの要素は、１またはそれ以上の電線、ケーブル及びプリント電気接続の少なくとも一つを用いて、並びにいくつかの非限定的かつ非包括的な例として、無線周波数領域、マイクロ波領域及び光（可視及び不可視の両方）領域の波長を有する電磁エネルギーなどを用いて、互いに「接続」または「結合」されると考えることができる。

【0284】

参照信号は、Reference Signal（RS）と略称することもでき、適用される標準によってパイロット（Pilot）と呼ばれてもよい。

【0285】

本開示において使用する「に基づいて」という記載は、別段に明記されていない限り、「のみに基づいて」を意味しない。言い換えれば、「に基づいて」という記載は、「のみに基づいて」と「に少なくとも基づいて」の両方を意味する。

【0286】

上記の各装置の構成における「手段」を、「部」、「回路」、「デバイス」等に置き換えてもよい。

【0287】

本開示において使用する「第１」、「第２」などの呼称を使用した要素へのいかなる参照も、それらの要素の量または順序を全般的に限定しない。これらの呼称は、２つ以上の要素間を区別する便利な方法として本開示において使用され得る。したがって、第１及び第２の要素への参照は、２つの要素のみがそこで採用され得ること、または何らかの形で第１の要素が第２の要素に先行しなければならないことを意味しない。

【0288】

本開示において、「含む（include）」、「含んでいる（including）」及びそれらの変形が使用されている場合、これらの用語は、用語「備える（comprising）」と同様に、包括的であることが意図される。さらに、本開示において使用されている用語「または（or）」は、排他的論理和ではないことが意図される。

【0289】

本開示において、例えば、英語でのa, an及びtheのように、翻訳により冠詞が追加された場合、本開示は、これらの冠詞の後に続く名詞が複数形であることを含んでもよい。

【0290】

本開示で使用する「判断(determining)」、「決定(determining)」という用語は、多種多様な動作を包含する場合がある。「判断」、「決定」は、例えば、判定(judging)、計算(calculating)、算出(computing)、処理(processing)、導出(deriving)、調査(investigating)、探索(looking up、search、inquiry)（例えば、テーブル、データベース又は別のデータ構造での探索）、確認(ascertaining)した事を「判断」「決定」したとみなす事などを含み得る。また、「判断」、「決定」は、受信(receiving)（例えば、情報を受信すること）、送信(transmitting)(例えば、情報を送信すること)、入力(input)、出力(output)、アクセス(accessing)（例えば、メモリ中のデータにアクセスすること）した事を「判断」「決定」したとみなす事などを含み得る。また、「判断」、「決定」は、解決(resolving)、選択(selecting)、選定(choosing)、確立(establishing)、比較(comparing)などした事を「判断」「決定」したとみなす事を含み得る。つまり、「判断」「決定」は、何らかの動作を「判断」「決定」したとみなす事を含み得る。また、「判断（決定）」は、「想定する（assuming）」、「期待する（expecting）」、「みなす（considering）」などで読み替えられてもよい。

【0291】

本開示において、「AとBが異なる」という用語は、「AとBが互いに異なる」ことを意味してもよい。なお、当該用語は、「AとBがそれぞれCと異なる」ことを意味してもよい。「離れる」、「結合される」などの用語も、「異なる」と同様に解釈されてもよい。

【0292】

以上、本開示について詳細に説明したが、当業者にとっては、本開示が本開示中に説明した実施形態に限定されるものではないということは明らかである。本開示は、請求の範囲の記載により定まる本開示の趣旨及び範囲を逸脱することなく修正及び変更態様として実施することができる。したがって、本開示の記載は、例示説明を目的とするものであり、本開示に対して何ら制限的な意味を有するものではない。

【符号の説明】

【0293】

10 無線通信システム
20 NG-RAN
100 gNB
200 UE
210 無線信号送受信部
220 アンプ部
230 変復調部
240 制御信号・参照信号処理部
250 符号化/復号部
260 データ送受信部
270 制御部
1001 プロセッサ
1002 メモリ
1003 ストレージ
1004 通信装置
1005 入力装置
1006 出力装置
1007 バス

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】