特許7401535 | 知財ポータル「IP Force」

知財求人 - 知財ポータルサイト「IP Force」

青山学院大学 (神奈川県相模原市中央区淵野辺)

▶ パナソニック　インテレクチュアル　プロパティ　コーポレーション　オブ　アメリカの特許一覧

特許7401535端末、通信方法及び集積回路

書誌要約請求の範囲詳細な説明課題実施例実施するための形態図面の説明

目に優しい文字サイズ小中大 PDF Top

< >

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

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

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

(11)【特許番号】

(24)【登録日】2023-12-11

(45)【発行日】2023-12-19

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

(51)【国際特許分類】

H04W 72/566 20230101AFI20231212BHJP

H04W 72/232 20230101ALI20231212BHJP

H04W 72/512 20230101ALI20231212BHJP

【ＦＩ】

H04W72/566

H04W72/232

H04W72/512

【請求項の数】 15

(21)【出願番号】P 2021515793

(86)(22)【出願日】2020-01-22

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

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

(87)【国際公開日】2020-10-29

【審査請求日】2022-11-02

(31)【優先権主張番号】62/839,128

(32)【優先日】2019-04-26

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

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

(32)【優先日】2019-05-09

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

(73)【特許権者】

【識別番号】514136668

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

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

(74)【代理人】

【識別番号】110002952

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

(72)【発明者】

【氏名】山本哲矢

(72)【発明者】

【氏名】鈴木秀俊

【審査官】松野吉宏

(56)【参考文献】

【文献】Ericsson，Physical Layer Enhancements for Intra-UE Prioritization and Multiplexing，3GPP TSG RAN WG1#96 R1-1901601，フランス，3GPP，2019年02月16日

【文献】InterDigital Communications, Inc.，L1/PHY Impacts for Intra-UE prioritization/multiplexing scenarios 6-7，3GPP TSG RAN WG1 adhoc_NR_AH_1901 R1-1900768，フランス，3GPP，2019年01月12日

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

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

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

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

ＳＡＷＧ１－４

ＣＴＷＧ１、４

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

【請求項1】

第１のチャネルの割当を指示する第１の下り制御情報および第２のチャネルの割当を指示する第２の下り制御情報に基づいて前記第１のチャネルおよび前記第２のチャネルの優先度の値を決定する制御回路と、
前記優先度の値に基づいて前記第１のチャネルおよび前記第２のチャネルの少なくとも１つの信号を送信または受信する通信回路と、を具備し、
前記第１の下り制御情報は前記優先度の値を示すパラメータを含み、前記第２の下り制御情報は前記パラメータを含まず、
前記パラメータが前記優先度の値が小さいことを示す場合、前記制御回路は前記第１のチャネルと前記第２のチャネルの優先度の値が同じであると判断する、
端末。

【請求項2】

前記優先度の値が大きい前記第１のチャネルの送信が前記優先度の値が小さい前記第２のチャネルの送信と時間軸上で重なる場合、前記通信回路は前記第２のチャネルの送信を停止する、
請求項１に記載の端末。

【請求項3】

前記第１の下り制御情報は前記優先度の値を示すパラメータを含み、前記第２の下り制御情報は前記パラメータを含まず、
前記パラメータが前記優先度の値が大きいことを示し、前記第１のチャネルの送信が前記第２のチャネルの送信と時間軸上で重なる場合、前記通信回路は前記第２のチャネルの送信を停止する、
請求項１に記載の端末。

【請求項4】

前記第１の下り制御情報および前記第２の下り制御情報が前記優先度の値を示すパラメータを含まない場合、前記制御回路は前記第１のチャネルおよび前記第２のチャネルの優先度の値が同じであると判断する、
請求項１に記載の端末。

【請求項5】

前記第１のチャネルは物理上り共有チャネル、前記第２のチャネルは物理上り制御チャネルであり、
前記優先度の値が大きい前記第１のチャネルの送信が前記優先度の値が小さい前記第２のチャネルの送信と時間軸上で重なる場合、前記通信回路は前記第２のチャネルの送信を停止する、
請求項１に記載の端末。

【請求項6】

前記第１のチャネルおよび前記第２のチャネルは物理上り制御チャネルであり、
前記優先度の値が大きい前記第１のチャネルの送信が前記優先度の値が小さい前記第２のチャネルの送信と時間軸上で重なる場合、前記通信回路は前記第２のチャネルの送信を停止する、
請求項１に記載の端末。

【請求項7】

前記第１のチャネル及び前記第２のチャネルの少なくとも１つの前記優先度の値が、前記第１の下り制御情報または前記第２の下り制御情報の１ビットで通知される、
請求項１に記載の端末。

【請求項8】

端末は、
第１のチャネルの割当を指示する第１の下り制御情報および第２のチャネルの割当を指示する第２の下り制御情報に基づいて前記第１のチャネルおよび前記第２のチャネルの優先度の値を決定し、
前記優先度の値に基づいて前記第１のチャネルおよび前記第２のチャネルの少なくとも１つの信号を送信または受信し、
前記第１の下り制御情報は前記優先度の値を示すパラメータを含み、前記第２の下り制御情報は前記パラメータを含まず、
前記パラメータが前記優先度の値が小さいことを示す場合、前記第１のチャネルと前記第２のチャネルの優先度の値が同じであると判断する、
通信方法。

【請求項9】

前記優先度の値が大きい前記第１のチャネルの送信が前記優先度の値が小さい前記第２のチャネルの送信と時間軸上で重なる場合、前記第２のチャネルの送信を停止する、
請求項８に記載の通信方法。

【請求項10】

前記第１の下り制御情報は前記優先度の値を示すパラメータを含み、前記第２の下り制御情報は前記パラメータを含まず、
前記パラメータが前記優先度の値が大きいことを示し、前記第１のチャネルの送信が前記第２のチャネルの送信と時間軸上で重なる場合、前記第２のチャネルの送信を停止する、
請求項８に記載の通信方法。

【請求項11】

前記第１の下り制御情報および前記第２の下り制御情報が前記優先度の値を示すパラメータを含まない場合、前記第１のチャネルおよび前記第２のチャネルの優先度の値が同じであると判断する、
請求項８に記載の通信方法。

【請求項12】

前記第１のチャネルは物理上り共有チャネル、前記第２のチャネルは物理上り制御チャネルであり、
前記優先度の値が大きい前記第１のチャネルの送信が前記優先度の値が小さい前記第２のチャネルの送信と時間軸上で重なる場合、前記第２のチャネルの送信を停止する、
請求項８に記載の通信方法。

【請求項13】

前記第１のチャネルおよび前記第２のチャネルは物理上り制御チャネルであり、
前記優先度の値が大きい前記第１のチャネルの送信が前記優先度の値が小さい前記第２のチャネルの送信と時間軸上で重なる場合、前記第２のチャネルの送信を停止する
請求項８に記載の通信方法。

【請求項14】

前記第１のチャネル及び前記第２のチャネルの少なくとも１つの前記優先度の値が、前記第１の下り制御情報または前記第２の下り制御情報の１ビットで通知される、
請求項８に記載の通信方法。

【請求項15】

第１のチャネルの割当を指示する第１の下り制御情報および第２のチャネルの割当を指示する第２の下り制御情報に基づいて前記第１のチャネルおよび前記第２のチャネルの優先度の値を決定する処理と、
前記優先度の値に基づいて前記第１のチャネルおよび前記第２のチャネルの少なくとも１つの信号を送信または受信する処理と、を制御し、
前記第１の下り制御情報は前記優先度の値を示すパラメータを含み、前記第２の下り制御情報は前記パラメータを含まず、
前記パラメータが前記優先度の値が小さいことを示す場合、前記優先度の値を決定する処理において、前記第１のチャネルと前記第２のチャネルの優先度の値が同じであると判断する、
集積回路。

【発明の詳細な説明】

【技術分野】

【0001】

本開示は、端末及び通信方法に関する。

【背景技術】

【0002】

3GPP（3rd Generation Partnership Project）では、第5世代移動通信システム（5G：5th Generation mobile communication sysmtems）の実現に向けて、Release 15 NR（New Radio access technology）の仕様策定が完了した。NRでは、モバイルブロードバンドの高度化（eMBB: enhanced Mobile Broadband）の基本的な要求条件である高速及び大容量と合わせ、超高信頼低遅延通信（URLLC: Ultra Reliable and Low Latency Communication）を実現する機能をサポートしている。

【先行技術文献】

【非特許文献】

【0003】

【文献】RP-190726, “New WID: Physical Layer Enhancements for NR Ultra-Reliable and Low Latency Communication (URLLC),” Huawei, HiSilicon, RAN#83

【文献】RP-190728, “New WID: Support of NR Industrial Internet of Things (IoT),” Nokia, Nokia Shanghai Bell, RAN#83

【文献】R1-1905092, “Discussion on UCI enhancement for URLLC,” Panasonic, RAN1#96bis, April 2019

【文献】R1-1905094, “Discussion on scheduling/HARQ enhancement for URLLC,” Panasonic, RAN1#96bis, April 2019

【文献】3GPP TS38.133 V15.5.0, “NR; Requirements for support of radio resource management (Release 15),” March 2019

【発明の概要】

【0004】

しかしながら、要求条件に応じた適切な無線通信処理については検討する余地がある。

【0005】

本開示の非限定的な実施例は、要求条件に応じて適切な無線通信処理を実現できる端末及び通信方法の提供に資する。

【0006】

本開示の一実施例に係る端末は、時間領域においてリソースの割り当てが互いに重複する第１チャネルおよび第２チャネルの優先度の決定方法を、前記第１チャネルおよび前記第２チャネルそれぞれの割当を示す制御情報に関するパラメータに基づいて決定する制御回路と、前記優先度に基づいて、前記第１チャネルおよび前記第２チャネルの少なくとも１つに対する信号の送信又は受信を行う通信回路と、を具備する。

【0007】

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

【0008】

本開示の一実施例によれば、要求条件に応じた適切な無線通信処理を実現できる。

【0009】

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

【図面の簡単な説明】

【0010】

【図1】異なる要求条件を有するサービスに対するリソースが時間領域において重複する場合の一例（Scenario 1）を示す図

【図2】異なる要求条件を有するサービスに対するリソースが時間領域において重複する場合の一例（Scenario 2）を示す図

【図3】異なる要求条件を有するサービスに対するリソースが時間領域において重複する場合の一例（Scenario 3）を示す図

【図4】異なる要求条件を有するサービスに対するリソースが時間領域において重複する場合の一例（Scenario 4）を示す図

【図5】CORESETが時間領域において重複して設定される例を示す図

【図6】送信ビームフォーミングの適用例を示す図

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

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

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

【図10】実施の形態１に係る端末の動作例を示すフローチャート

【図11】実施の形態２に係るCORESET及びチャネルの設定例を示す図

【図12】実施の形態３に係るCORESET及びチャネルの設定例を示す図

【図13】実施の形態４に係る端末の動作の一例を示すフローチャート

【図14】実施の形態６に係る端末の動作の一例を示すフローチャート

【図15】実施の形態６に係る端末の動作の他の例を示すフローチャート

【図16】異なるサブキャリア間隔のキャリアの一例を示す図

【図17】キャリア間の時間差補正の一例を示す図

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

【0011】

以下、本開示の実施の形態について図面を参照して詳細に説明する。

【0012】

NRでは、端末（又は、UE（User Equipment）とも呼ぶ）は、複数の異なる要求条件を有するサービス（例えば、eMBB及びURLLC等）に対応することが想定される。このとき、端末において、異なる要求条件を有するサービスにそれぞれ対する受信リソース（換言すると、下りリンクリソース又は受信期間）、又は、送信リソース（換言すると、上りリンクリソース又は送信期間）が時間領域において重複する場合があり得る（例えば、非特許文献１及び２を参照）。

【0013】

以下、端末において異なる要求条件を有するサービスに対応する送受信リソースが時間領域において重複するケース（例えば、シナリオ（scenario）とも呼ぶ）についてそれぞれ説明する。

【0014】

＜Scenario 1:Intra-UE DL prioritization (DL data/data resource conflicts)＞
Scenario 1では、例えば、図１に示すように、端末は、下りリンクにおいて、異なる要求条件を有するサービス（図１では、eMBB及びURLLC）に対するデータ信号（例えば、下りリンクデータ信号、又は、PDSCH：Physical Downlink Shared Channelとも呼ぶ）を受信する。

【0015】

このとき、各サービスに対する下りリンクデータ信号には、それぞれ異なる制御情報（例えば、下りリンクスケジューリング割当情報、又は、DL assignmentとも呼ぶ）によってリソースが割り当てられる。DL assignmentは、例えば、図１に示すように、下りリンク制御チャネル（例えば、PDCCH：Physical Downlink Control Channel）に含まれてよい。

【0016】

図１では、各サービスに対する下りリンクデータ信号に割り当てられたリソース（例えば、PDSCHのリソース）は時間領域において重複している。

【0017】

＜Scenario 2:Intra-UE UL prioritization (UL data/data resource collision)＞
Scenario 2では、例えば、図２に示すように、端末は、上りリンクにおいて、異なる要求条件を有するサービス（図２では、eMBB及びURLLC）に対するデータ信号（例えば、上りリンクデータ信号、又は、PUSCH：Physical Uplink Shared Channelとも呼ぶ）を送信する。

【0018】

このとき、各サービスに対する上りリンクデータ信号には、それぞれ異なる制御情報（例えば、上りリンクリソース割当情報、又は、UL grantとも呼ぶ）によってリソースが割り当てられる。UL grantは、例えば、図２に示すように、PDCCHに含まれてよい。

【0019】

図２では、各サービスに対する上りリンクデータ信号に割り当てられたリソース（例えば、PUSCHのリソース）は時間領域において重複している。

【0020】

＜Scenario 3:Intra-UE UL prioritization (UL control/control resource collision)＞
Scenario 3では、下りリンクの再送制御（例えば、HARQ：Hybrid Automatic Repeat Request）において、端末は、下りリンクデータ信号（例えば、PDSCH）の誤り検出結果を示す応答信号（例えば、ACK/NACK: Acknowledgement / Negative Acknowledgement）を基地局（例えば、gNBとも呼ぶ）へ送信する。

【0021】

例えば、図３に示すように、端末は、下りリンクにおいて、異なる要求条件を有するサービス（図３では、eMBB及びURLLC）に対するデータ信号（例えば、PDSCH）をそれぞれ受信する。また、端末は、各PDSCHに対するACK/NACKを上りリンク制御チャネル（例えば、PUCCH：Physical Uplink Control Channel）を用いて基地局へ送信する。

【0022】

このとき、各サービスに対する下りリンクデータ信号、及び、下りリンクデータ信号に対応するPUCCHには、それぞれ異なる制御情報（例えば、下りリンクスケジューリング割当情報、又は、DL assignment）によってリソースが割り当てられる。

【0023】

図３では、各サービスに対するPUCCHに割り当てられたリソースは時間領域において重複している。

【0024】

＜Scenario 4:Intra-UE UL prioritization (UL data/control resource collision)＞
Scenario 4では、例えば、図４に示すように、端末は、上りリンクにおいて、異なる要求条件を有するサービス（図４では、eMBB及びURLLC）のうちの一方（例えば、URLLC）に対するデータ信号（例えば、PUSCH）と、他方（例えば、eMBB）に対する制御信号(例えば、PDSCHに対するACK/NACK)とを送信する。

【0025】

このとき、上りリンクデータ信号には、上りリンクリソース割当情報（例えば、UL grant）によってリソースが割り当てられる。また、下りリンクデータ信号及び当該下りリンクデータ信号に対応するPUCCHには、それぞれ異なる下りリンクスケジューリング割当情報（例えば、DL assignment）によってリソースが割り当てられる。

【0026】

図４では、上りリンクデータ信号に割り当てられたリソース（例えば、PUSCHのリソース）と、PUCCHに割り当てられたリソースとが時間領域において重複している。

【0027】

以上、Scenario 1～4についてそれぞれ説明した。

【0028】

上述したシナリオにおいて、複数のチャネルの信号を同時に受信又は送信する能力が端末に有る場合、端末は、異なる要求条件を有するサービスに対する信号を、互いの影響を考慮することなく、同時に受信又は送信できる。

【0029】

一方、複数のチャネルの信号を同時に受信又は送信する能力が端末に無い場合、端末は、複数のチャネルの一部（上述したシナリオの場合、何れか一方）のチャネルを受信又は送信する。又は、端末は、複数のチャネルが上りリンクのチャネルである場合、複数のチャネルの送信電力を制御する。

【0030】

このとき、端末が複数のチャネルの信号を同時に受信又は送信できない場合には、端末がどのチャネルの信号を受信又は送信するかを決定する。換言すると、端末では、複数のチャネルにおける信号の受信又は送信の優先度が決定され得る。

【0031】

例えば、チャネルに対する優先度の決定方法の一例として、端末における、DL assignment又はUL grantを含む下りリンク制御情報（例えば、DCI：Downlink Control Information）の受信タイミング（換言すると、受信順序）に基づく方法がある。

【0032】

この方法では、例えば、端末は、各チャネル（換言すると、各サービス）に対する割当情報（例えば、DL assignment又はUL grant）を含むDCIを順次受信した場合、より遅く（換言すると、後に）受信したDCIによって割り当てられたチャネルの優先度が、より早く（換言すると、先に）受信したDCIによって割り当てられたチャネルの優先度よりも高いと判断する。

【0033】

これは、基地局が先に送信するDCI（DL assignment又はUL grant）によって割り当てたチャネルの優先度が高い場合、当該優先度の高いチャネルのリソースに、優先度の低いチャネルを後から重複して割り当てる動作は非合理的な動作であることに起因している。

【0034】

しかしながら、上述の優先度の決定方法では、例えば、以下の事項（１）、（２）及び（３）について検討する余地がある。

【0035】

（１）Scenario 4（例えば、図４を参照）において、例えば、端末がPUSCH（図４ではURLLCのPUSCH）を生成する処理時間と、端末がPDSCH（図４ではeMBBのPDSCH）を受信して、PDSCHを復調及び復号し、ACK/NACKを含むPUCCHを生成する処理時間とが異なる。

【0036】

このため、Scenario 4のように、PUSCH及びPUCCHのリソースが時間領域において重複する場合に、基地局は、優先度の高いチャネル（例えば、URLLCのチャネル）に対応するDCIを、優先度の低いチャネル（例えば、eMBBのチャネル）に対応するDCIの後に送信できるとは限らない。よって、例えば、端末において、優先度の高いチャネルに対応するDCIが、優先度の低いチャネルに対応するDCIよりも先に受信される場合もあり得るので、DCIの受信順序に基づいてチャネルの優先度が決定される方法では、端末は、チャネルの優先度を適切に決定できない場合があり得る。

【0037】

（２）NRでは、端末は、DL assignment及びUL grantの少なくとも一つを含むDCIを基地局から受信する。DCIが送信される制御チャネルであるPDCCHに対して、例えば、CORESET（Control Resource Set）及びサーチスペースが端末に設定される。例えば、端末は、CORESET内のPDCCH候補の位置であるサーチスペースをモニタ（換言すると、ブラインド復号）し、端末宛てのDCIを検出する。このとき、端末には、異なる要求条件を有するサービスに対して、異なるCORESET（又はサーチスペース）が設定され得る。また、例えば、図５に示すように、異なる要求条件を有するサービス（図５では、eMBB及びURLLC）に対してそれぞれ設定されるCORESETの少なくとも一部が、時間領域において重複して設定される可能性がある。

【0038】

この場合、端末は、各サービスに対応するDCIをそれぞれのCORESETから受信した場合、何れのDCIが後に受信したDCIであるか（換言すると、何れのサービスの優先度が高いか）を判断できない場合がある。換言すると、図５の場合、異なる要求条件を有するサービス（又はチャネル）間の優先度を決定できない場合がある（優先度の決定方法が不明瞭である）。

【0039】

（３）NRでは、例えば、6GHz以上の高周波数帯では、基地局において送信ビームフォーミングの適用が想定される。送信ビームフォーミングの適用により、基地局と端末との間の通信可能距離及びエリアを確保できる。例えば、基地局がスロット内においてビームを順次切り替えてPDCCHを送信する構成（例えば、beam sweepingとも呼ぶ）がある。また、PDCCHにビームフォーミングが適用される場合、例えば、図６に示すように、各ビーム（図６では４個のビーム）に対してCORESET（又は、サーチスペース）がそれぞれ設定され得る。

【0040】

この場合、DCIが割り当てられるCORESET（換言すると、サーチスペース又はPDCCH）は、端末に対して適切なビームに対応するCORESETであることが望ましい。例えば、図６に示すように、時間領域において、各ビームに対応するCORESETがそれぞれ設定される複数のリソースの中から、端末に対して適切なビームに対応するCORESETが設定されたリソースが端末に割り当てられる。このため、DCIの時間領域のスケジューリングが制限される。そのため、ビームフォーミングを適用した場合、上述したDCIの順序に基づく優先度の決定方法では、スケジューリングの制約により遅延が増加し得る。

【0041】

以上、事項（１）、（２）及び（３）についてそれぞれ説明した。

【0042】

チャネルに対する優先度の決定方法の他の例として、非特許文献３及び４には、例えば、チャネルの優先度を示す情報（以下、優先度情報又はPriority indicationとも呼ぶ）を基地局から端末へ通知する方法が開示されている。Priority indicationは、例えば、DL assignment又はUL grantによって通知される。

【0043】

非特許文献３及び４では、例えば、PUSCHとPUCCHとの間でリソースが時間領域において重複するScenario 4（例えば、図４を参照）の場合、端末は、UL grant及びDL assignmentにそれぞれ含まれるPriority indicationに基づいて、PUSCH及びPUCCHのうち優先するチャネルを決定する。

【0044】

また、非特許文献３及び４では、例えば、Scenario 1、2及び3（例えば、図１、図２及び図３を参照）において、端末は、DCI（例えば、DL assignment又はUL grantを含む）を順次受信し、複数のDCIのうち、より後に受信したDCIによって割り当てられたチャネルの優先度が高いと判断する。また、例えば、DCIにPriority indicationが含まれている場合、端末は、複数のDCIのうち、より後に受信したDCIによって割り当てられるチャネルの優先度が、より先に受信したDCIによって割り当てられるチャネルの優先度より低く設定されることを想定しない。

【0045】

これらの方法により、例えば、端末が送信又は受信するチャネルが時間領域において重複する場合でも、Priority indicationによって、端末は、チャネル間の優先度を適切に判断できる。しかしながら、この方法では、上述した事項（２）及び（３）について検討されていない。例えば、上述した事項（２）のように、時間領域において重複するチャネルのそれぞれの割当を示す制御情報（例えば、DL assignment及びUL grant）を含むリソース領域（例えば、CORESET、サーチスペース又はPDCCH）が時間領域において重複する場合におけるチャネルの優先度の決定方法について検討する余地がある。また、上述した事項（３）のように、時間領域において重複するチャネルの少なくとも一方の割当を示す制御情報を含むリソース領域（例えば、CORESET、サーチスペース又はPDCCH）が、例えば、複数のビームがそれぞれ設定されたリソース領域である場合におけるチャネルの優先度の決定方法について検討する余地がある。

【0046】

そこで、本開示の一実施例では、異なる要求条件を有するサービスに対応するチャネルが時間領域において重複した場合の端末の動作について説明する。

【0047】

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

【0048】

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

【0049】

図７は、本開示の一実施例に係る端末２００の一部の構成例を示すブロック図である。図７に示す端末２００において、制御部２０５（例えば、制御回路に相当）は、時間領域においてリソースの割り当てが互いに重複する第１チャネルおよび第２チャネルの優先度の決定方法を、第１チャネルおよび第２チャネルそれぞれの割当を示す制御情報（例えば、DCI）に関するパラメータに基づいて決定する。受信部２０１及び送信部２０９（例えば、通信回路に相当）は、優先度に基づいて、第１チャネルおよび第２チャネルの少なくとも１つに対する信号の受信又は送信を行う。

【0050】

［基地局の構成］
図８は、実施の形態１に係る基地局１００の構成例を示すブロック図である。図８において、基地局１００は、制御部１０１と、上位制御信号生成部１０２と、下りリンク制御情報生成部１０３と、符号化部１０４と、変調部１０５と、信号割当部１０６と、送信部１０７と、受信部１０８と、抽出部１０９と、復調部１１０と、復号部１１１と、を有する。

【0051】

制御部１０１は、端末２００のDCI受信のための情報を決定し、例えば、決定した情報を上位制御信号生成部１０２及び抽出部１０９へ出力する。DCI受信のための情報には、例えば、CORESET、サーチスペース設定、及び、DCI fieldに関する情報等が含まれてもよい。

【0052】

また、制御部１０１は、下りリンクデータ信号（例えば、PDSCH）、上位制御信号、又は、下りリンク制御情報（例えば、DCI）を送信するための下りリンク信号に関する情報（例えば、符号化・変調方式（MCS：Modulation and Coding Scheme）、及び、無線リソース割当等）を決定する。制御部１０１は、例えば、決定した情報を符号化部１０４、変調部１０５、及び信号割当部１０６へ出力する。また、制御部１０１は、下りリンク信号に関する情報を下りリンク制御情報生成部１０３へ出力する。

【0053】

また、制御部１０１は、端末２００が下りリンクデータ信号に対するACK/NACKを送信するための情報を決定し、決定した情報を下りリンク制御情報生成部１０３及び抽出部１０９へ出力する。ACK/NACKを送信するための情報には、例えば、PUCCHリソースに関する情報等が含まれてもよい。

【0054】

また、制御部１０１は、端末２００が上りリンクデータ信号を送信するための情報（例えば、符号化・変調方式及び無線リソース割当）を決定し、決定した情報を下りリンク制御情報生成部１０３、抽出部１０９及び復号部１１１へ出力する。

【0055】

また、制御部１０１は、Priority indicaitonを適用する場合、複数のチャネル（例えば、PDSCH、PUSCH又はPUCCH）の優先度を決定し、決定した優先度情報（例えば、Priority indication）を下りリンク制御情報生成部１０３へ出力する。また、制御部１０１は、決定した優先度情報を抽出部１０９へ出力する。

【0056】

上位制御信号生成部１０２は、制御部１０１から入力される情報に基づいて、上位レイヤ制御信号ビット列を生成し、上位レイヤ制御信号ビット列を符号化部１０４へ出力する。

【0057】

下りリンク制御情報生成部１０３は、制御部１０１から入力される情報に基づいて、下りリンク制御情報（例えば、DCI）ビット列を生成し、生成したDCIビット列を符号化部１０４へ出力する。なお、制御情報が複数の端末向けに送信されることもある。このため、下りリンク制御情報生成部１０３は、DCIを送信するPDCCHに、端末固有の識別情報によってスクランブルしてもよい。端末固有の識別情報は、例えば、C-RNTI(Cell Radio Network Temporary Identifier)、MCS-C-RNTI（Modulation and Coding Scheme C-RNTI）、及び、URLLC向けに導入されるRNTI等でもよく、他のRNTIでもよい。

【0058】

符号化部１０４は、例えば、制御部１０１から入力される情報（例えば、符号化率に関する情報）に基づいて、下りリンクデータ信号、上位制御信号生成部１０２から入力されるビット列、又は、下りリンク制御情報生成部１０３から入力されるDCIビット列を符号化し、符号化ビット列を変調部１０５へ出力する。

【0059】

変調部１０５は、例えば、制御部１０１から入力される情報（例えば、変調方式に関する情報）に基づいて、符号化部１０４から入力される符号化ビット列を変調して、変調後の信号（例えば、シンボル列）を信号割当部１０６へ出力する。

【0060】

信号割当部１０６は、制御部１０１から入力される無線リソースを示す情報に基づいて、変調部１０５から入力されるシンボル列（例えば、下りリンクデータ信号又は制御信号を含む）を無線リソースにマッピングする。信号割当部１０６は、信号がマッピングされた下りリンクの信号を送信部１０７に出力する。

【0061】

送信部１０７は、信号割当部１０６から入力される信号に対して、例えば、OFDM（Orthogonal Frequency Division Multiplexing）等の送信波形生成処理を行う。また、送信部１０７は、CPを付加するOFDM伝送の場合には信号に対してIFFT（Inverse Fast Fourier Transform）処理を行い、IFFT後の信号にCPを付加する。また、送信部１０７は、信号に対して、D/A変換、アップコンバート等のRF処理を行い、アンテナを介して端末２００に無線信号を送信する。

【0062】

受信部１０８は、アンテナを介して受信された端末２００からの上りリンク信号に対して、ダウンコバート又はA/D変換等のRF処理を行う。また、受信部１０８は、OFDM伝送の場合、受信信号に対してFFT（Fast Fourier Transform）処理を行い、得られる周波数領域信号を抽出部１０９へ出力する。

【0063】

抽出部１０９は、制御部１０１から入力される情報に基づいて、端末２００が送信した信号のチャネルに関する情報（例えば、優先度の高いチャネルに関する情報）を決定する。抽出部１０９は、決定した情報に基づいて、受信部１０８から入力される受信信号から、例えば、上りリンクデータ信号又はACK/NACK信号、若しくは両方が送信された無線リソース部分を抽出し、抽出した無線リソース部分を復調部１１０へ出力する。

【0064】

復調部１１０は、抽出部１０９から入力される信号（無線リソース部分）に基づいて、上りリンクデータ信号及びACK/NACK信号の少なくとも一つを復調し、復調結果を復号部１１１へ出力する。

【0065】

復号部１１１は、制御部１０１から入力される情報、及び、復調部１１０から入力される復調結果に基づいて、上りリンクデータ信号及びACK/NACK信号の少なくとも一つの誤り訂正復号を行い、復号後の受信ビット系列を得る。

【0066】

［端末の構成］
図９は、本実施の形態に係る端末２００の構成例を示すブロック図である。図９において、端末２００は、受信部２０１と、抽出部２０２と、復調部２０３と、復号部２０４と、制御部２０５と、符号化部２０６と、変調部２０７と、信号割当部２０８と、送信部２０９と、を有する。

【0067】

受信部２０１は、基地局１００からの下りリンク信号（例えば、下りリンクデータ信号又は下りリンク制御情報）をアンテナを介して受信し，無線受信信号に対してダウンコバート又はA/D変換等のRF処理を行い、受信信号（ベースバンド信号）を得る。また、受信部２０１は、OFDM信号を受信する場合、受信信号に対してFFT処理を行い、受信信号を周波数領域に変換する。受信部２０１は、受信信号を抽出部２０２へ出力する。

【0068】

抽出部２０２は、制御部２０５から入力される、下りリンク制御情報の無線リソースに関する情報に基づいて、受信部２０１から入力される受信信号から、下りリンク制御情報が含まれ得る無線リソース部分を抽出し、復調部２０３へ出力する。また、抽出部２０２は、制御部２０５から入力されるデータ信号の無線リソースに関する情報に基づいて、下りリンクデータ信号が含まれる無線リソース部分を抽出し、復調部２０３へ出力する。

【0069】

また、抽出部２０２は、例えば、Scneario 1（換言すると、下りリンクデータ信号の受信時。例えば、図１を参照）の場合、制御部２０５から入力される優先度に関する情報に基づいて、受信信号から下りリンクデータ信号を抽出する。

【0070】

復調部２０３は、抽出部２０２から入力される信号を復調し、復調結果を復号部２０４へ出力する。

【0071】

復号部２０４は、復調部２０３から入力される復調結果に対して誤り訂正復号を行い、例えば、下りリンク受信データ、上位レイヤ制御信号、又は、下りリンク制御情報を得る。復号部２０４は、上位レイヤ制御信号及び下りリンク制御情報を制御部２０５へ出力し、下りリンク受信データを出力する。

【0072】

制御部２０５は、例えば、復号部２０４から入力される上位レイヤ制御信号に含まれるDCI受信のための情報（例えば、CORESET、サーチスペース設定又はDCI fieldに関する情報）、及び、下りリンク制御情報に示される無線リソース割当情報に基づいて、チャネルの優先度を決定する。制御部２０５は、決定した優先度に関する情報を抽出部２０２（例えば、Scenario 1の場合）、及び、符号化部２０６と信号割当部（例えば、Scenario 2, 3, 4の場合）へ出力する。なお、チャネルの優先度決定方法の一例については後述する。

【0073】

また、制御部２０５は、上りリンク信号の送信に関する情報を決定し、決定した情報を、符号化部２０６及び信号割当部２０８へ出力する。また、制御部２０５は、下りリンク信号の受信に関する情報を決定し、決定した情報を抽出部２０２に出力する。

【0074】

符号化部２０６は、制御部２０５から入力される情報に基づいて、上りリンクデータ信号、又は、下りリンクデータ信号に対するACK/NACK信号を符号化し、符号化ビット列を変調部２０７へ出力する。

【0075】

変調部２０７は、符号化部２０６から入力される符号化ビット列を変調し、変調後の信号（シンボル列）を信号割当部２０８へ出力する。

【0076】

信号割当部２０８は、制御部２０５から入力される情報に基づいて、変調部２０７から入力される信号を無線リソースへマッピングし、信号がマッピングされた上りリンク信号を送信部２０９へ出力する。

【0077】

また、信号割当部２０８は、例えば、Scenario 2，3及び4の場合（換言すると、上りリンク信号の送信時。例えば、図２、図３又は図４を参照）、制御部２０５から入力される優先度に関する情報に基づいて、送信部２０９へ信号を出力する上りリンクのチャネルを決定する。

【0078】

送信部２０９は、信号割当部２０８から入力される信号に対して、OFDM等の送信信号波形生成を行う。また、送信部２０９は、CPを用いるOFDM伝送の場合、信号に対してIFFT処理を行い、IFFT後の信号にCPを付加する。または、送信部２０９は、シングルキャリア波形を生成する場合には、変調部２０７の後段又は信号割当部２０８の前段にDFT（Discrete Fourier Transform）部が追加されてもよい（図示せず）。また、送信部２０９は、送信信号に対してD/A変換及びアップコンバート等のRF処理を行い、アンテナを介して基地局１００に無線信号を送信する。

【0079】

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

【0080】

図１０は、本実施の形態に係る端末２００の送受信処理に関するフローの一例を示す。

【0081】

図１０において、端末２００は、DL assignment又はUL grantを含むDCIを基地局１００から受信する（ＳＴ１０１）。図１０では、一例として、端末２００は、異なる要求条件を有するサービスにそれぞれ対応するDCI#1及びDCI#2を受信する。

【0082】

DCIが送信される制御チャネルであるPDCCHには、例えば、CORESET及びサーチスペースが端末２００に設定される。端末２００は、例えば、CORESET内のPDCCH候補の位置であるサーチスペースをモニタし、端末２００宛てのDCIを検出する。また、異なる要求条件を有するサービスに対して、異なるCORESET（又は、サーチスペース）が設定され得る。また、例えば、図５に示すように、異なる要求条件を有するサービスにそれぞれ対応するCORESETは、時間領域において重複して設定され得る。よって、端末２００は、例えば、異なるCORESET（又は、サーチスペース）において、DCI#1及びDCI#2をそれぞれ検出する。

【0083】

端末２００は、検出したDCI#1及びDCI#2の各々に含まれるDL assignment又はUL grantに基づいて、端末２００に対して割り当てられたチャネルのリソースを示すリソース割当情報を取得する（ＳＴ１０２）。

【0084】

端末２００は、取得したリソース割当情報に基づいて、例えば、異なる要求条件を有するサービスにそれぞれ対応するチャネル（例えば、PDSCH、PUSCH又はPUCCH）の割当リソース間の関係が、上述したScenario 1, 2, 3又は4の何れかに対応するか否かを判断する（ＳＴ１０３）。換言すると、端末２００は、異なる要求条件を有するサービスにそれぞれ対応するチャネルの割当リソースが時間領域において重複するか否かを判断する。

【0085】

Scenario 1, 2, 3又は4の何れかに対応する場合（ＳＴ１０３：Ｙｅｓ）、端末２００は、或る条件（condition）を満たすか否かを判断する（ＳＴ１０４）。

【0086】

実施の形態１における条件（以下、「Condition A」と呼ぶ）は、端末２００が受信（換言すると、検出）したDCI#1及びDCI#2が含まれるリソース領域（例えば、CORESET、サーチスペース又はPDCCH。以下では、一例としてCORESETについて説明する）が時間領域において重複して設定されている場合である。

【0087】

端末２００は、Condition Aを満たす場合、つまり、DCI#1及びDCI#2のそれぞれが含まれるCORESETが時間領域において重複して設定されている場合（ＳＴ１０４：Ｙｅｓ）、各DCIに含まれる優先度情報（Priority indication）に基づいて、送信又は受信を優先するチャネル（換言すると、チャネルの優先度）を決定する（ＳＴ１０５）。換言すると、端末２００は、Condition Aを満たす場合、DCI#1及びDCI#2に対して、受信（又は検出）したタイミング（又は順序）に基づいてチャネルの優先度を決定しない。例えば、端末２００は、Condition Aを満たす場合、各DCIの受信したタイミングが同一であると判断してよい。

【0088】

このように、端末２００は、DCI#1及びDCI#2のそれぞれが含まれるCORESETが時間領域において重複する場合、Priority indicationに従ってチャネルの優先度を決定する決定方法を選択する。ここで、Priority indicationの一例として、DCIの1ビット（例えば、0又は1）によって示される優先度が設定され得る。

【0089】

例えば、Priority indicationにおいて、“1”が高い優先度を示し、“0”が低い優先度を示してもよい。例えば、端末２００は、異なる要求条件を有するサービスに対するDCI#1及びDCI#2において、DCI#1のPriority indicationが1、かつ、DCI#2のPriority indicationが0の場合、DCI#1によって割り当てられるチャネルの方がDCI#2によって割り当てられるチャネルよりも優先度が高いと判断する。一方、端末２００は、DCI#1のPriority indicationが0、かつ、DCI#2のPriority indicationが1の場合、DCI#2によって割り当てられるチャネルの方がDCI#1によって割り当てられるチャネルよりも優先度が高いと判断する。

【0090】

なお、Priority indicationのビット数は１ビットに限定されず、複数のビットでもよい。また、Priority indicationの値（例えば、0及び1）と優先度との対応付けは、上述した例に限定されない。また、上述したPriority indicationの一例は、他の実施の形態においても適用できる。

【0091】

図１０において、端末２００は、Condition Aを満たさない場合、例えば、DCI#1及びDCI#2のそれぞれが含まれるCORESETが時間領域において重複せずに設定されている場合（ＳＴ１０４：Ｎｏ）、DCI#1及びDCI#2に対して、受信（又は検出）した順序に基づいてチャネルの優先度を決定する（ＳＴ１０６）。例えば、端末２００は、DCI#1及びDCI#2のうち、後から受信したDCIによって割り当てられるチャネルの優先度を、先に受信したDCIによって割り当てられるチャネルの優先度よりも高いと判断する。

【0092】

このように、端末２００は、DCI#1及びDCI#2のそれぞれが含まれるCORESETが時間領域において重複しない場合、DCIの受信順序に従ってチャネルの優先度を決定する決定方法を選択する。

【0093】

端末２００は、各チャネルのリソース割当情報、及び、決定した各チャネルの優先度に基づいて、DCI#1及びDCI#2の少なくとも一つのDCIによって割り当てられたチャネルの信号を受信又は送信する（ＳＴ１０７）。

【0094】

一方、ＳＴ１０３の処理において、Scenario 1, 2, 3及び4の何れかにも対応しない場合（ＳＴ１０３：Ｎｏ）、すなわち、異なる要求条件を有するサービスにそれぞれ対応するチャネルの割当リソースが時間領域において重複しない場合、端末２００は、各チャネルのリソース割当情報に基づいて、DCI#1及びDCI#2によって割り当てられたチャネルの信号を受信又は送信する（ＳＴ１０８）。

【0095】

以上のように、本実施の形態では、端末２００は、時間領域においてリソースの割り当てが重複するチャネル（例えば、URLLCに対応する第１チャネル及びeMBBに対応する第２チャネル）の優先度の決定方法を、第１チャネル及び第２チャネルそれぞれの割当を示すDCIに対応するCORESET、サーチスペース又はPDCCH等のリソースを示す情報（換言すると、制御情報に関するパラメータ）に基づいて決定する。

【0096】

例えば、本実施の形態では、端末２００は、異なる要求条件を有するサービスに対応するDCIそれぞれに対応するCORESETが時間領域において重複するか否かに基づいて、Priority indicationに基づく優先度の決定方法（例えば、第１の決定方法）、及び、DCIの受信順序に基づく優先度の決定方法（例えば、第２の決定方法）の何れか一方を選択する。

【0097】

これにより、端末２００は、複数のDCIがそれぞれ含まれるCORESETが時間領域において重複して設定されていない場合には、各DCIの受信順序に基づいて、チャネルの優先度を適切に決定できる。換言すると、端末２００は、Priority indication等の通知無しで、チャネルの優先度をより簡易に決定できる。

【0098】

また、端末２００は、複数のDCIがそれぞれ含まれるCORESETが時間領域において重複して設定される場合、例えば、DCIの各受信タイミングが同様である場合でも、Priority indicationに基づいて、優先するチャネルを明確に決定できる。

【0099】

よって、本実施の形態によれば、異なる要求条件を有するサービスに対応するチャネルが時間領域において重複し、かつ、時間領域において重複するチャネルのそれぞれの割当を示す制御情報を含むCORESET（又は、サーチスペース又はPDCCH）が時間領域において重複する場合でも、端末２００は、チャネルの優先度を適切に決定し、優先度に応じたチャネルの信号を送受信できる。これにより、本実施の形態では、要求条件に応じた適切な無線通信処理を実現できる。

【0100】

なお、実施の形態１では、端末２００は、DCIを受信（又は検出）した際に、各DCIが含まれるCORESET（又は、サーチスペース又はPDCCH）が時間領域において重複して設定されている場合、DCIによって通知されるPriority indicationに基づいて、優先するチャネルを決定する。ここで、例えば、URLLC向けに導入されるDCIでは、DCIによって通知される制御情報を柔軟に設定可能である。よって、URLLC向けに導入されるDCIでは、例えば、Priority indicationの有無についての設定も可能である。

【0101】

そこで、例えば、基地局１００は、CORESET（又は、サーチスペース又はPDCCH）が時間領域において重複して設定される場合に、Priority indicationをDCIに含めて送信してもよい。換言すると、基地局１００は、CORESET（又は、サーチスペース又はPDCCH）が時間領域において重複しない場合、Priority indicationをDCIに含めない。これにより、例えば、端末２００においてPriority indicationに基づいてチャネルの優先度を決定しない場合、DCIサイズを低減できる。

【0102】

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

【0103】

本実施の形態では、基地局１００は、送信ビームフォーミングを適用する。例えば、図１１に示すように、スロット内の連続するX個のOFDMシンボル内に複数のCORESET（又はサーチスペース）が設定され得る。例えば、図１１では、異なる４個のビーム（Beam 1, Beam 2, Beam 3及びBeam 4）にそれぞれ対応する４個のCORESETが設定されている。

【0104】

本実施の形態に係る端末２００の送受信処理に関するフローは、例えば、実施の形態１（例えば、図１０を参照）と同様である。本実施の形態では、図１０に示すＳＴ１０４の処理が実施の形態１と異なる。

【0105】

図１０に示すＳＴ１０４において、端末２００は、或る条件（condition）を満たすか否かを判断する（ＳＴ１０４）。

【0106】

実施の形態２における条件（以下、「Condition B」と呼ぶ）は、端末２００が受信（換言すると、検出）したDCI#1及びDCI#2の少なくとも一方が含まれるリソース領域（例えば、CORESET、サーチスペース又はPDCCH。以下では、一例としてCORESETについて説明する）がスロット内の連続するX OFDMシンボル内に設定された複数のCORESETのうちの一つである場合である。換言すると、Condition Bは、DCI#1及びDCI#2の少なくとも一つがX OFDMシンボル内に設定された複数のCORESETの何れかに配置される場合である。

【0107】

端末２００は、Condition Bを満たす場合、つまり、DCI#1及びDCI#2の少なくとも一方が含まれるCORESETがX OFDMシンボル内に設定された複数のCORESETの一つである場合（ＳＴ１０４：Ｙｅｓ）、各DCIに含まれる優先度情報（Priority indication）に基づいて、送信又は受信を優先するチャネル（換言すると、チャネルの優先度）を決定する（ＳＴ１０５）。換言すると、端末２００は、Condition Bを満たす場合、DCI#1及びDCI#2に対して、受信（又は検出）したタイミング（又は順序）に基づいてチャネルの優先度を決定しない。例えば、端末２００は、Condition Bを満たす場合、各DCIの受信したタイミングが同一であると判断してよい。

【0108】

このように、端末２００は、DCI#1及びDCI#2の少なくとも一つがX OFDMシンボル内に設定されたCORESETの何れか一つに配置される場合、Priority indicationに従ってチャネルの優先度を決定する決定方法を選択する。

【0109】

一方、端末２００は、Condition Bを満たさない場合、例えば、DCI#1及びDCI#2が含まれるCORESETがX OFDMシンボル内に設定された複数のCORESETではない場合（ＳＴ１０４：Ｎｏ）、DCI#1及びDCI#2に対して、受信（又は検出）した順序に基づいてチャネルの優先度を決定する（ＳＴ１０６）。例えば、端末２００は、DCI#1及びDCI#2のうち、後から受信したDCIによって割り当てられるチャネルの優先度を、先に受信したDCIによって割り当てられるチャネルの優先度よりも高いと判断する。

【0110】

このように、端末２００は、DCI#1及びDCI#2の少なくとも一つがX OFDMシンボル内に設定されたCORESETの何れか一つに配置されない場合、DCIの受信順序に従ってチャネルの優先度を決定する決定方法を選択する。

【0111】

例えば、図１１において、URLLC用のDCIを含むPDCCHは、eMBB用のDCIを含むPDCCHよりも時間領域において先のリソースに割り当てられている。よって、仮に、端末２００がDCIの受信順序に基づいてチャネルの優先度を決定する場合には、eMBB用のDCIによって割り当てられるチャネルの優先度は、URLLC用のDCIによって割り当てられるチャネルの優先度よりも高く設定される。しかし、上述したように、図１１において、URLLC用のDCIには、送信ビームフォーミング（例えば、Beam 1～4）が適用され、URLLC用のDCIを含むPDCCHは、当該PDCCHに対して適切なビーム（図１１ではBeam 2）に対応付けられたCORESET内に配置される。このように、Condition Bを満たす場合、送信ビームフォーミングが適用されるDCI（又はPDCCH）に対して時間領域のスケジューリングが制限されている。

【0112】

これに対して、本実施の形態では、Condition Bを満たす場合、例えば、DCI（又はPDCCH）に対してビームフォーミングが適用されている場合には、端末２００は、DCIの受信（又は、検出）のタイミングに依らず、Priority indicationに基づいて、チャネルの優先度を適切に決定できる。例えば、図１１において、Priority indicationに基づいて、URLLC用のDCIによって割り当てられるチャネルの優先度が、eMBB用のDCIによって割り当てられるチャネルの優先度よりも高く設定されてよい。

【0113】

このように、本実施の形態では、端末２００は、時間領域においてリソースの割り当てが重複するチャネル（例えば、URLLCに対応する第１チャネル及びeMBBに対応する第２チャネル）の優先度の決定方法を、DCIに設定可能な複数のビームにそれぞれ対応するリソースを示す情報（例えば、X OFDMシンボル）に基づいて決定する。

【0114】

例えば、本実施の形態では、端末２００は、異なる要求条件を有するサービスに対応するDCIの少なくとも一つが、複数のビームにそれぞれ対応するCORESETに配置されるか否かに基づいて、Priority indicationに基づく優先度の決定方法、及び、DCIの受信順序に基づく優先度の決定方法の何れか一方を選択する。

【0115】

これにより、本実施の形態によれば、異なる要求条件を有するサービスに対応するチャネルが時間領域において重複し、かつ、ビームフォーミングの適用によってDCIの時間領域のスケジューリングが制限される場合でも、端末２００は、チャネルの優先度を適切に決定し、優先度に応じたチャネルの信号を送受信できる。これにより、本実施の形態では、要求条件に応じた適切な無線通信処理を実現できる。

【0116】

なお、本実施の形態において、Xシンボルはスロット内のシンボル数（例えば、14シンボル）の範囲で設定されてよい。また、Xの値は、規格において決定された値でもよく、セル固有、グループ固有又は端末固有の上位レイヤ信号によって静的に設定されてもよい。

【0117】

また、例えば、URLLCではスロットよりも短い時間単位（例えば、サブスロットとも呼ぶ）の導入が検討されている。例えば、サブスロットは、7シンボルで構成される時間単位でもよい（7シンボルに限らない）。例えば、本実施の形態において説明したスロットは、サブスロットに置き換えられてもよい。

【0118】

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

【0119】

本実施の形態では、基地局１００は、送信ビームフォーミングを適用する。例えば、図１２に示すように、空間的な受信パラメータの異なる複数のリソース領域（例えば、CORESET、サーチスペース又はPDCCH。以下では、一例としてCORESETについて説明する）が設定され得る。なお、空間的な受信パラメータは、例えば、QCL（Quasi Co-Location）-TypeDと呼ばれることもある。異なるQCL-TypeDは、例えば、異なるビームの設定を示す。例えば、図１２では、４種類の空間的な受信パラメータ（例えば、Beam 1, Beam 2, Beam 3及びBeam 4のそれぞれに対応）にそれぞれ対応する４個のCORESETが設定されている。

【0120】

本実施の形態では、例えば、図１２に示すように、異なるQCL-TypeDを有するCORESETの集合が定義される。

【0121】

【0122】

図１０に示すＳＴ１０４において、端末２００は、或る条件（condition）を満たすか否かを判断する（ＳＴ１０４）。

【0123】

実施の形態３における条件（以下、「Condition C」と呼ぶ）は、端末２００が受信（換言すると、検出）したDCI#1及びDCI#2の少なくとも一方が含まれるCORESETが、上述したCORESETの集合に含まれる場合である。換言すると、Condition Cは、DCI#1及びDCI#2の少なくとも一つがCORESETの集合内のCORESETに配置される場合である。

【0124】

端末２００は、Condition Cを満たす場合、つまり、DCI#1及びDCI#2の少なくとも一方が含まれるCORESETがCORESETの集合に含まれる場合（ＳＴ１０４：Ｙｅｓ）、各DCIに含まれる優先度情報（Priority indication）に基づいて、送信又は受信を優先するチャネル（換言すると、チャネルの優先度）を決定する（ＳＴ１０５）。換言すると、端末２００は、Condition Cを満たす場合、DCI#1及びDCI#2に対して、受信（又は検出）したタイミング（又は順序）に基づいてチャネルの優先度を決定しない。例えば、端末２００は、Condition Cを満たす場合、各DCIの受信したタイミングが同一であると判断してよい。

【0125】

このように、端末２００は、DCI#1及びDCI#2の少なくとも一つが、複数のQCL-TypeDにそれぞれ対応するリソース（例えば、CORESETの集合）の何れか一つに配置される場合、Priority indicationに従ってチャネルの優先度を決定する決定方法を選択する。

【0126】

一方、端末２００は、Condition Cを満たさない場合、例えば、DCI#1及びDCI#2が含まれるCORESETがCORESETの集合に含まれない場合（ＳＴ１０４：Ｎｏ）、DCI#1及びDCI#2に対して、受信（又は検出）した順序に基づいてチャネルの優先度を決定する（ＳＴ１０６）。例えば、端末２００は、DCI#1及びDCI#2のうち、後から受信したDCIによって割り当てられるチャネルの優先度を、先に受信したDCIによって割り当てられるチャネルの優先度よりも高いと判断する。

【0127】

このように、端末２００は、DCI#1及びDCI#2の少なくとも一つが、複数のQCL-TypeDにそれぞれ対応するリソース（例えば、CORESETの集合）の何れか一つに配置されない場合、DCIの受信順序に従ってチャネルの優先度を決定する決定方法を選択する。

【0128】

例えば、図１２において、URLLC用のDCIを含むPDCCHは、eMBB用のDCIを含むPDCCHよりも時間領域において先のリソースに割り当てられている。よって、仮に、端末２００がDCIの受信順序に基づいてチャネルの優先度を決定する場合には、eMBB用のDCIによって割り当てられるチャネルの優先度は、URLLC用のDCIによって割り当てられるチャネルの優先度よりも高く設定される。しかし、図１２において、URLLC用のDCIには、送信ビームフォーミング（例えば、Beam 1～4）が適用され、URLLC用のDCIを含むPDCCHは、当該PDCCHに対して適切なQCL-TypeD（空間的な受信パラメータ）に対応付けられたCORESET内に配置される。このように、Condition Cを満たす場合、送信ビームフォーミングが適用されるDCI（又はPDCCH）に対して時間領域のスケジューリングが制限されている。

【0129】

これに対して、本実施の形態では、Condition Cを満たす場合、例えば、DCI（又はPDCCH）に対してビームフォーミングが適用されている場合には、端末２００は、DCIの受信（又は、検出）のタイミングに依らず、Priority indicationに基づいて、チャネルの優先度を適切に決定できる。例えば、図１２において、Priority indicationに基づいて、URLLC用のDCIによって割り当てられるチャネルの優先度が、eMBB用のDCIによって割り当てられるチャネルの優先度よりも高く設定されてよい。

【0130】

このように、本実施の形態では、端末２００は、時間領域においてリソースの割り当てが重複するチャネル（例えば、URLLCに対応する第１チャネル及びeMBBに対応する第２チャネル）の優先度の決定方法を、DCIに設定可能な複数の空間パラメータ（例えば、QCL-TypeD）にそれぞれ対応するリソースを示す情報（例えば、CORESETの集合）に基づいて決定する。

【0131】

例えば、本実施の形態では、端末２００は、異なる要求条件を有するサービスに対応するDCIの少なくとも一つが、上記集合内のCORESETに配置されるか否かに基づいて、Priority indicationに基づく優先度の決定方法、及び、DCIの受信順序に基づく優先度の決定方法の何れか一方を選択する。

【0132】

【0133】

なお、本実施の形態おいて、異なるQCL-TypeDが設定されたCORESETの集合の設定方法について、例えば、上位レイヤ信号によって、CORESET又はサーチスペースの番号を含む集合が設定されてもよい。また、CORESETの集合に対する時間区間を導入し、時間区間に含まれる異なるQCL-TypeDが設定されたCORESET（又は、サーチスペース又はPDCCH）を1つの集合と見なしてもよい。時間区間は、例えば、１スロットでもよく、１スロットと異なる時間長でもよい。

【0134】

【0135】

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

【0136】

本実施の形態では、例えば、端末２００がDCIを受信（又は、検出）した際に、各DCIが含まれるリソース領域（例えば、CORESET、サーチスペース又はPDCCH。以下では、一例としてCORESETについて説明する）が時間領域において重複して設定されている場合（換言すると、Condition Aの場合）に、チャネルの優先度を決定するための「参照タイミング」が導入される。

【0137】

参照タイミングは、例えば、CORESETの設定における先頭シンボル位置でもよく、最後のシンボル位置でもよい。

【0138】

図１３は、本実施の形態に係る端末２００の送受信処理に関するフローの一例を示す。なお、図１３において、実施の形態１（例えば、図１０）と同様の処理には同一の符号を付し、その説明を省略する。例えば、図１３では、ＳＴ２０１の処理が実施の形態１（例えば、図１０のＳＴ１０５の処理）と異なる。

【0139】

図１３において、端末２００は、Condition Aを満たす場合、つまり、DCI#1及びDCI#2のそれぞれが含まれるCORESETが時間領域において重複して設定されている場合（ＳＴ１０４：Ｙｅｓ）、各DCIが含まれるCORESETに対応する参照タイミングに基づいて、送信又は受信を優先するチャネル（換言すると、チャネルの優先度）を決定する（ＳＴ２０１）。例えば、端末２００は、DCI#1及びDCI#2のうち、参照タイミングが時間領域において遅いDCIによって割り当てられたチャネルの優先度がより高いと判断する。

【0140】

このように、端末２００は、DCI#1及びDCI#2のそれぞれが含まれるCORESETが時間領域において重複する場合、DCI#1及びDCI#2それぞれに対応するリソース（例えば、CORESET、サーチスペース又はPDCCH）の時間領域における位置に関する情報に基づいてチャネルの優先度を決定する決定方法を選択する。

【0141】

一方、端末２００は、DCI#1及びDCI#2のそれぞれが含まれるCORESETが時間領域において重複しない場合、DCIの受信順序に従ってチャネルの優先度を決定する決定方法を選択する（図１３のＳＴ１０６）。

【0142】

【0143】

例えば、本実施の形態では、端末２００は、異なる要求条件を有するサービスに対応するDCIそれぞれに対応するCORESETが時間領域において重複するか否かに基づいて、DCIそれぞれに対応するCORESETの参照タイミングに基づく優先度の決定方法、及び、DCIの受信順序に基づく優先度の決定方法の何れか一方を選択する。

【0144】

これにより、端末２００は、複数のDCIがそれぞれ含まれるCORESETが時間領域において重複しない場合には、各DCIの受信順序に基づいて、チャネルの優先度を適切に決定できる。また、端末２００は、複数のDCIがそれぞれ含まれるCORESETが時間領域において重複する場合でも、CORESETの参照タイミングに基づいて、優先するチャネルを明確に決定できる。換言すると、端末２００は、基地局１００からの通知無しで、チャネルの優先度をより簡易に決定できる。

【0145】

よって、本実施の形態によれば、異なる要求条件を有するサービスに対応するチャネルが時間領域において重複した場合でも、端末２００は、チャネルの優先度を適切に決定し、優先度に応じたチャネルの信号を送受信できる。これにより、本実施の形態では、要求条件に応じた適切な無線通信処理を実現できる。

【0146】

（実施の形態4のバリエーション）
チャネルの優先度を決定するパラメータは、参照タイミング（例えば、DCIが含まれるリソース領域の時間領域における位置）に限定されない。

【0147】

複数のリソース領域（例えば、CORESET、サーチスペース又はPDCCH。ここでは、一例としてCORESETについて説明する)が時間領域において重複して設定される場合、例えば、図５に示すように、各CORESET設定における先頭シンボル位置（又は、最後のシンボル位置）が同一に設定される場合もあり得る。そこで、例えば、CORESETの設定における時間長又はシンボル数（換言すると、CORESETの時間領域における長さ）が、チャネルの優先度を決定するためのパラメータに設定されてもよい。

【0148】

端末２００は、例えば、CORESETの時間長又はシンボル数がより短いCORESETにおいて送信されたDCIによって割り当てられるチャネルの優先度をより高く設定してもよい。例えば、図５に示す例では、URLLC用のCORESETの時間長は、eMBB用のCORESETの時間長よりも短い。よって、図５に示す例では、URLLC用のCORESETにおいて送信されたDCIによって割り当てられるチャネルの優先度は、eMBB用のCORESETにおいて送信されたDCIによって割り当てられるチャネルの優先度よりも高く設定されてよい。

【0149】

また、チャネルの優先度を決定するパラメータは、参照タイミング、及び、CORESETの時間長（例えば、シンボル数）の双方を含んでもよい。

【0150】

例えば、端末２００は、DCIを受信（又は検出）した際、各DCIが含まれるCORESETが時間領域において重複して設定されている場合、まず、参照タイミングに基づいてチャネルの優先度を判断する。この際、端末２００は、参照タイミング（又は優先度）が同一である場合、CORESETの時間長（又はシンボル数）が短いDCIによって割り当てられたチャネルの優先度がより高いと判断してもよい。

【0151】

または、端末２００は、DCIを受信（又は検出）した際、各DCIが含まれるCORESETが時間領域において重複して設定されている場合、まず、CORESETの時間長に基づいてチャネルの優先度を判断する。この際、端末２００は、時間長（又は優先度）が同一である場合、参照タイミングが遅いDCIによって割り当てられたチャネルの優先度がより高いと判断してもよい。

【0152】

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

【0153】

上述したように、端末２００には、例えば、DCIを送信する制御チャネルであるPDCCHに対して、例えば、CORESET又はサーチスペースが設定される。端末２００は、CORESET内のPDCCH候補の位置であるサーチスペースをモニタし、端末２００宛てのDCIを検出する。また、端末２００には、異なる要求条件を有するサービスに対して異なるCORESET（又は、サーチスペース又はPDCCH）が設定され得る。

【0154】

本実施の形態では、端末２００に対して、複数のCORESETが時間領域において重複して設定されることが禁止される。換言すると、端末２００に設定される複数のCORESETは、時間領域において重複せずに設定される。

【0155】

本実施の形態によれば、端末２００は、DCIを受信（又は、検出）した際、各DCIが含まれるCORESET（又は、サーチスペース又はPDCCH）が時間領域において重複して設定されないので、各DCIを順次受信できる。よって、端末２００は、例えば、DCIの受信タイミング（換言すると、受信順序）に基づいて、各DCIによって割り当てられるチャネルの優先度を決定できる。例えば、端末２００は、CORESETが時間領域において重複して設定されないので、各DCIの受信タイミングを明確に区別でき、優先するチャネルを明確に決定できる。

【0156】

【0157】

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

【0158】

例えば、実施の形態１～３の各々においては、或る条件（例えば、Condition A, B又はC）下において、端末２００は、DCIによって通知されるPriority indicationに基づいてチャネルの優先度を決定する。

【0159】

ここで、端末２００に対して時間領域において重複して割り当てられるチャネルの優先度が同一になる場合もあり得る。例えば、Priority indicationにおいて、“1”が高い優先度を示し、“0”が低い優先度を示す場合について説明する。この場合、異なる要求条件を有するサービスに対するDCI（DCI#1及びDCI#2)において、DCI#1及びDCI#2の双方のPriority indicationが1又は0の同一値である場合、端末２００は、DCI#1及びDCI#2のそれぞれによって割り当てられるチャネルの優先度が同一であると判断する。

【0160】

または、端末２００に対して時間領域において重複して割り当てられるチャネルには、Priority indicationを含まないDCIによって割り当てられたチャネルが含まれる場合もあり得る。

【0161】

例えば、端末２００が複数の異なる要求条件を有するサービス（例えば、eMBB及びURLLC）に対応する場合、URLLCについては、Priority indicaitonを含むDCI（換言すると、新たに導入されるDCI）が設定され得る。一方、eMBBについては、Priority indicationを含まないDCI（換言すると、既存のNRのDCI）が設定される場合も想定される。この場合、複数の異なる要求条件を有するサービスに対するチャネルのうち、少なくとも一つのチャネルを割り当てるDCIにPriority indicationが含まれないケースが発生し得る。

【0162】

そこで、本実施の形態では、これらの場合におけるチャネルの優先度を決定する方法について説明する。

【0163】

以下、本実施の形態における端末２００の動作例１及び動作例２についてそれぞれ説明する。

【0164】

＜動作例１＞
動作例１では、同一の優先度を有するチャネルが時間領域において重複した場合の端末２００の動作例について説明する。

【0165】

図１４は、本実施の形態に係る端末２００の送受信処理に関するフローの一例を示す。なお、図１４において、実施の形態１（例えば、図１０）又は実施の形態４（例えば、図１３）と同様の処理には同一の符号を付し、その説明を省略する。

【0166】

図１４において、端末２００は、或る条件（例えば、Condition A、Condition B又はCondition C）を満たす場合（ＳＴ１０４：Ｙｅｓ）、各DCIに含まれるPriority indicationに基づいて、送信又は受信を優先するチャネルを決定する（ＳＴ１０５）。

【0167】

ここで、端末２００は、各DCIによって通知されるPriority indicationによって各チャネルについて決定した優先度が同一であるか否かを判断する（ＳＴ３０１）。換言すると、端末２００は、ＳＴ１０５の処理によってチャネルの優先度を明確に判断できるか否かを判断する。各DCIによって通知されるPriority indication（優先度）が同一ではない場合（ＳＴ３０１：Ｎｏ）、端末２００は、ＳＴ１０７の処理を行う。

【0168】

一方、各DCIによって通知されるPriority indication（優先度）が同一である場合（ＳＴ３０１：Ｙｅｓ）、端末２００は、例えば、実施の形態４と同様、DCIそれぞれに対応するリソース（例えば、CORESET、サーチスペース又はPDCCH）の時間領域における位置（例えば、参照タイミング。又は、時間長（又はシンボル数））に基づいてチャネルの優先度を決定する（ＳＴ２０１）。

【0169】

換言すると、端末２００は、例えば、図１４に示すように、実施の形態１～３の何れかのようにPriority indicationに基づいて各チャネルについて決定される優先度が同一の場合、実施の形態４のように参照タイミングに基づく優先度の決定処理に移行してよい。

【0170】

図１５は、本実施の形態に係る端末２００の送受信処理に関するフローの他の例を示す。なお、図１５において、図１４と同様の処理には同一の符号を付し、その説明を省略する。

【0171】

例えば、図１５では、各DCIによって通知されるPriority indicationによって各チャネルについて決定した優先度が同一である場合（ＳＴ３０１：Ｙｅｓ）の動作が、図１４に示す動作と異なる。

【0172】

図１５において、端末２００は、各DCIによって通知されるPriority indication（優先度）が同一である場合（ＳＴ３０１：Ｙｅｓ）、Condition B及びCondition Cの何れかと、Condition Aとのうち、何れの条件を満たすかを判断する（ＳＴ４０１）。換言すると、端末２００は、DCIそれぞれに対応するCORESET（又は、サーチスペース又はPDCCH）が時間領域において重複するか否かを判断する。

【0173】

DCIそれぞれに対応するCORESET（又は、サーチスペース又はPDCCH）が時間領域において重複する場合、例えば、Condition Aの場合（ＳＴ４０１：Ｙｅｓ）、端末２００は、例えば、実施の形態４と同様、参照タイミングに基づいてチャネルの優先度を決定してよい（ＳＴ２０１）。換言すると、端末２００は、例えば、実施の形態１～３の何れかのようにPriority indicationに基づいて決定される各チャネルの優先度が同一の場合、かつ、各DCIが含まれるCORESET（又は、サーチスペース又はPDCCH）が時間領域において重複して設定されている場合、実施の形態４のように参照タイミングに基づく優先度の決定処理に移行してよい。

【0174】

一方、図１５において、DCIそれぞれに対応するCORESET（又は、サーチスペース又はPDCCH）が時間領域において重複しない場合、例えば、Condition B又はCondition Cの場合（ＳＴ４０１：Ｎｏ）、端末２００は、例えば、DCIの受信順序に基づいてチャネルの優先度を決定してよい。

【0175】

＜動作例２＞
動作例２では、複数の異なる要求条件を有するサービスに対するチャネルのうち少なくとも一つのチャネルを割り当てるDCIにPriority indicationが含まれない場合の端末２００の動作例について説明する。

【0176】

例えば、端末２００は、異なる要求条件を有するサービスに対するDCI（例えば、DCI#1及びDCI#2とする）をそれぞれ受信（又は、検出）する。

【0177】

このとき、DCI#1及びDCI#2のうち何れか一方のDCI（例えば、DCI#1）にPriority indicationが含まれ、他方のDCI（例えば、DCI#2）にPriority indicationが含まれない場合があり得る。

【0178】

この場合、端末２００は、例えば、DCI#1のPriority indicationが1の場合（例えば、高い優先度を示す場合）、DCI#1によって割り当てられるチャネルの優先度が、DCI#2によって割り当てられるチャネルの優先度よりも高いと判断してよい。

【0179】

一方、端末２００は、例えば、DCI#1のPriority indicationが0の場合（例えば、低い優先度を示す場合）、DCI#2によって割り当てられるチャネルの優先度が、DCI#1によって割り当てられるチャネルの優先度よりも高いと判断してもよい。または、端末２００は、この場合、DCI#1及びDCI#2のそれぞれによって割り当てられるチャネルの優先度が同一と判断してもよい。

【0180】

また、端末２００は、DCI#1及びDCI#2の双方ともPriority indicationが含まれない場合、DCI#1及びDCI#2のそれぞれによって割り当てられるチャネルの優先度が同一と判断してもよい。

【0181】

なお、端末２００は、DCI#1及びDCI#2のそれぞれによって割り当てられるチャネルの優先度が同一と判断した場合には、例えば、上述したように、図１４又は図１５に示す動作を行ってもよい。

【0182】

以上、動作例１及び動作例２について説明した。

【0183】

このように、本実施の形態によれば、Priority indicationによって決定されるチャネルの優先度が同一である場合、又は、端末２００に通知される複数のDCIの少なくとも一つにPriority indicationが含まれない場合でも、端末２００は、チャネルの優先度を適切に決定し、優先度に応じたチャネルの信号を送受信できる。これにより、本実施の形態では、要求条件に応じた適切な無線通信処理を実現できる。

【0184】

以上、本開示の一実施例について説明した。

【0185】

（他の実施の形態）
（１）NRでは、例えば、キャリアアグリゲーション（Carrier Aggregation）がサポートされる。

【0186】

キャリアアグリゲーションでは、例えば、PDCCHが送信されるキャリアと、当該PDCCHによって割り当てられるPDSCHが送信されるキャリアとが異なる運用（例えば、「クロスキャリアスケジューリング」と呼ばれる）が可能である。

【0187】

また、キャリアアグリゲーションでは、例えば、異なるNumerology（換言すると、サブキャリア間隔（SCS：subcarrier spacing））を有するキャリア間でのクロスキャリアスケジューリングがサポートされる。

【0188】

図１６は、異なるNumerologyを有するキャリア間でのクロスキャリアスケジューリングの一例を示す。

【0189】

図１６に示す例では、何れのキャリア（例えば、SCS=15kHzのCarrier 1及びSCS=30kHzのCarrier 2）でも同一のシンボル数（例えば、3シンボル）のCORESET（又は、サーチスペース又はPDCCH）が設定されている。図１６に示すように、異なるNumerologyを有するキャリア間では、CORESET（又は、サーチスペース又はPDCCH）のシンボル数が同一でも、CORESET長（時間長）は異なる。図１６では、Carrier 2におけるCORESET（例えば、3シンボル）の時間長は、Carrier 1におけるCORESET（例えば、3シンボル）の時間長よりも短い。

【0190】

ここで、図１６に示す２つのCORESETの状況は、例えば、図５に示す複数のCORESETが時間領域において重複して設定される状況に相当する。そこで、例えば、異なるNumerologyを有するキャリア間でのクロスキャリアスケジューリングにおいて、各キャリアからスケジューリングされたPDSCHが同一キャリア内において時間領域において重複した場合、端末２００は、例えば、実施の形態１、実施の形態４及び実施の形態６の少なくとも一つに基づいて動作してもよい。

【0191】

（２）NRでは、例えば、キャリアアグリゲーションがサポートされる。NRにおけるInter-bandキャリアグリゲーションでは、例えば、端末２００は異なるキャリア間における受信スロットタイミング差（換言すると、時間差）がある場合を許容する（例えば、非特許文献５を参照）。例えば、周波数レンジ１(FR（Frequency Range）1、例えば、6GHz以下)では、最大で33usの受信スロットタイミング差を許容する。

【0192】

例えば、端末２００がDCIの受信タイミングにおいて、チャネルの優先度を判断する際に、キャリア間の受信スロットタイミング差が有る場合、図１７に示すように、絶対時間におけるDCIの受信タイミングではなく、受信スロットタイミング差（換言すると、時間差）を補正して受信スロットタイミングを合わせた後に、DCIの受信タイミングを判断してもよい。

【0193】

（３）上述した各実施の形態では、異なる要求条件を有するサービスに対するチャネル（換言すると、受信リソース又は送信リソース）が時間領域において重複する場合に、端末２００がチャネルの優先度を決定する方法について説明した。

【0194】

端末２００は、チャネルの優先度を決定後、例えば、上述したシナリオ（Scenario 1～4の各々）において以下の動作を行ってもよい。

【0195】

＜Scenario 1（例えば、図１を参照）＞
端末２００が複数のPDSCHを同時に受信（又は、復調及び復号処理）できない場合、端末２００は、優先度の高いPDSCHを受信（又は、復調及び復号処理）する。一方、端末２００は、優先度の低いPDSCHの受信（又は、復調及び復号処理）を行わない。また、端末２００は、受信（又は、復調及び復号処理）を行わない優先度の低いPDSCHに対してNACKを生成して、基地局１００へフィードバックしてもよい。

【0196】

＜Scenario 2（例えば、図２を参照）＞
端末２００が複数のPUSCHを同時に送信できない場合、端末２００は、優先度の高いPUSCHを送信し、優先度の低いPUSCHを送信しない。

【0197】

または、端末２００は、複数のPUSCHを同時に送信できるものの、送信電力の総和が最大送信電力を超える場合、優先度の低いPUSCHの送信電力を制御（スケーリング）してもよい。

【0198】

＜Scenario 3（例えば、図３を参照）＞
端末２００が複数のPUCCHを同時に送信できない場合、端末２００は、優先度の高いチャネルに対するACK/NACKを含むPUCCHを送信する。一方、端末２００は、優先度の低いチャネルに対するACK/NACKをドロップしてもよい（換言すると、送信しなくてよい)。

【0199】

または、端末２００は、優先度の低いチャネルに対するACK/NACKを優先度の高いチャネルに対するACK/NACKに多重して、１つのPUCCHにおいて各ACK/NACKを送信してもよい。このとき、端末２００は、優先度の高いチャネルに対するACK/NACKから順にPUCCHへ多重してもよい。また、端末２００は、PUCCHに設定されたリソースに余裕がある場合、優先度の低いチャネルに対するACK/NACKを当該PUCCHへ多重してもよい。

【0200】

または、端末２００は、複数のPUCCHを同時に送信できるものの、送信電力の総和が最大送信電力を超える場合、優先度の低いPUCCHの送信電力を制御（スケーリング）してもよい。

【0201】

＜Scenario 4（例えば、図４を参照）＞
端末２００がPUSCH及びPUCCHを同時に送信できない場合、端末２００は、優先度の高いチャネル（PUSCH又はPUCCH）を送信し、優先度の低いチャネル（PUSCH又はPUCCH）をドロップしてもよい（換言すると、送信しなくてもよい）。

【0202】

または、端末２００は、ACK/NACKをPUSCHに多重して送信してもよい。

【0203】

または、端末２００が複数のPUSCH及びPUCCHを同時に送信できるものの、送信電力の総和が最大送信電力を超える場合、優先度の低いチャネル（PUSCH又はPUCCH）の送信電力を制御（スケーリング）してもよい。

【0204】

（４）Priority indicationは、DCIによって明示的に通知される場合に限定されず、暗示的に通知されてもよい。

【0205】

例えば、Priority indicationは、DCI format、RNTI又はサーチスペースによって暗示的に通知され、端末２００は、DCI format、RNTI又はサーチスペースに基づいて、チャネルの優先度を決定してもよい。

【0206】

例えば、DCI formatの場合、端末２００は、URLLC用に導入されるDCI formatのDCIを受信した場合、当該DCIによって割り当てられるチャネルの優先度を、他のDCI formatのDCIによって割り当てられるチャネルよりも高い優先度と判断してもよい。

【0207】

また、例えば、RNTIの場合、端末２００は、検出したRNTIがC-RNTIと異なる場合、例えば、Rel.15においてURLLC用に導入されたMCS-C-RNTI又は新たにURLLC向けに導入されるRNTIである場合、対応するDCIによって割り当てられるチャネルの優先度を、他のDCIによって割り当てられるチャネルよりも高い優先度と判断してもよい。

【0208】

また、サーチスペースの場合、端末２００は、DCIを検出したサーチスペースに設定されたサーチスペース番号に基づいて、当該DCIによって割り当てられるチャネルの優先度を判断してもよい。

【0209】

Priority indication（例えば、チャネルの優先度）が暗示的に通知されることにより、シグナリング量を低減できる。

【0210】

なお、Priority indicationの暗示的な通知方法は、これらに限定されない。例えば、端末２００がチャネル（例えば、eMBB及びURLLC）の優先度を判断可能なパラメータと、チャネルの優先度とが関連付けられればよい。

【0211】

（５）上記各実施の形態において、下りリンク制御チャネル、下りリンクデータチャネル、上りリンク制御チャネル、及び、上りリンクデータチャネルは、それぞれ、PDCCH、PDSCH、PUCCH、及び、PUSCHに限らず、他の名称の制御チャネルでもよい。

【0212】

（６）時間リソースの単位は、上記各実施の形態において説明した時間リソース（例えば、スロット又はサブスロット）に限定されず、他の時間リソース単位（例えば、サブフレーム又はフレーム等）でもよい。

【0213】

（７）異なる要求条件を有するサービスは、eMBB及びURLLCに限定されず、他のサービスでもよい。

【0214】

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

【0215】

本開示は、通信機能を持つあらゆる種類の装置、デバイス、システム（通信装置と総称）において実施可能である。通信装置は無線送受信機（トランシーバー）と処理／制御回路を含んでもよい。無線送受信機は受信部と送信部、またはそれらを機能として、含んでもよい。無線送受信機（送信部、受信部）は、ＲＦ（ＲａｄｉｏＦｒｅｑｕｅｎｃｙ）モジュールと１または複数のアンテナを含んでもよい。ＲＦモジュールは、増幅器、ＲＦ変調器／復調器、またはそれらに類するものを含んでもよい。通信装置の、非限定的な例としては、電話機（携帯電話、スマートフォン等）、タブレット、パーソナル・コンピューター（ＰＣ）（ラップトップ、デスクトップ、ノートブック等）、カメラ（デジタル・スチル／ビデオ・カメラ等）、デジタル・プレーヤー（デジタル・オーディオ／ビデオ・プレーヤー等）、着用可能なデバイス（ウェアラブル・カメラ、スマートウオッチ、トラッキングデバイス等）、ゲーム・コンソール、デジタル・ブック・リーダー、テレヘルス・テレメディシン（遠隔ヘルスケア・メディシン処方）デバイス、通信機能付きの乗り物又は移動輸送機関（自動車、飛行機、船等）、及び上述の各種装置の組み合わせがあげられる。

【0216】

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

【0217】

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

【0218】

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

【0219】

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

【0220】

【0221】

本開示の一実施例に係る端末において、前記制御回路は、前記パラメータに基づいて、基地局から受信した前記優先度を示す通知情報に従って前記優先度を決定する第１の決定方法、及び、前記制御情報の受信順序に従って前記優先度を決定する第２の決定方法の何れか一方を選択する。

【0222】

本開示の一実施例に係る端末において、前記パラメータは、前記制御情報に対応するリソースを示す情報を含み、前記制御回路は、前記制御情報に対応するリソースが時間領域において重複する場合、前記第１の決定方法を選択する。

【0223】

本開示の一実施例に係る端末において、前記制御回路は、前記制御情報に対応するリソースが時間領域において重複しない場合、前記第２の決定方法を選択する。

【0224】

本開示の一実施例に係る端末において、前記パラメータは、前記制御情報に設定可能な複数のビームにそれぞれ対応するリソースを示す情報を含み、前記制御回路は、前記制御情報の少なくとも一つが前記複数のビームにそれぞれ対応するリソースの何れか一つに配置される場合、前記第１の決定方法を選択する。

【0225】

本開示の一実施例に係る端末において、前記制御回路は、前記制御情報の少なくとも一つが前記複数のビームにそれぞれ対応するリソースの何れか一つに配置されない場合、前記第２の決定方法を選択する。

【0226】

本開示の一実施例に係る端末において、前記パラメータは、前記制御情報に設定可能な複数の空間パラメータにそれぞれ対応するリソースを示す情報を含み、前記制御回路は、前記制御情報の少なくとも一つが前記複数の空間パラメータにそれぞれ対応するリソースの何れか一つに配置される場合、前記第１の決定方法を選択する。

【0227】

本開示の一実施例に係る端末において、前記制御回路は、前記制御情報の少なくとも一つが前記複数の空間パラメータにそれぞれ対応するリソースの何れか一つに配置されない場合、前記第２の決定方法を選択する。

【0228】

本開示の一実施例に係る端末において、前記パラメータは、前記制御情報に対応するリソースを示す情報を含み、前記制御回路は、前記制御情報に対応するリソースが時間領域において重複する場合、前記制御情報それぞれに対応するリソースの時間領域における位置及び長さの少なくとも一つに関する情報に基づいて前記優先度を決定する。

【0229】

本開示の一実施例に係る端末において、前記制御回路は、前記制御情報に対応するリソースが時間領域において重複しない場合、前記制御情報の受信順序に基づいて前記優先度を決定する。

【0230】

本開示の一実施例に係る端末において、前記制御回路は、前記第１チャネルおよび前記第２チャネルについて決定した前記優先度が同一の場合、前記制御情報それぞれに対応するリソースの時間領域における位置及び長さの少なくとも一つに関する情報に基づいて、前記優先度を決定する。

【0231】

本開示の一実施例に係る端末において、前記制御回路は、前記第１チャネルおよび前記第２チャネルについて決定した前記優先度が同一の場合、かつ、前記制御情報それぞれに対応するリソースが時間領域において重複する場合、前記制御情報それぞれに対応するリソースの時間領域における位置及び長さの少なくとも一つに関する情報に基づいて、前記優先度を決定する。

【0232】

本開示の一実施例に係る端末において、前記制御回路は、前記第１チャネルおよび前記第２チャネルについて決定した前記優先度が同一の場合、かつ、前記制御情報それぞれに対応するリソースが時間領域において重複しない場合、前記制御情報の受信順序に基づいて、前記優先度を決定する。

【0233】

本開示の一実施例に係る通信方法は、時間領域においてリソースの割り当てが互いに重複する第１チャネルおよび第２チャネルの優先度の決定方法を、前記第１チャネルおよび前記第２チャネルそれぞれの割当を示す制御情報に関するパラメータに基づいて決定し、前記優先度に基づいて、前記第１チャネルおよび前記第２チャネルの少なくとも１つに対する信号の送信又は受信を行う。

【0234】

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

【産業上の利用可能性】

【0235】

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

【符号の説明】

【0236】

１００基地局
１０１，２０５制御部
１０２上位制御信号生成部
１０３下りリンク制御情報生成部
１０４，２０６符号化部
１０５，２０７変調部
１０６，２０８信号割当部
１０７，２０９送信部
１０８，２０１受信部
１０９，２０２抽出部
１１０，２０３復調部
１１１，２０４復号部
２００端末

【図1】