JPWO2020066232A1 - 端末及び受信方法 - Google Patents

Abstract

参照信号を適切に配置することができる端末。端末（２００）において、受信部（２０１）は、下りリンク信号を受信し、DCI受信部（２０３）は、下りリンク信号において、制御チャネルの候補位置をモニタして、端末宛ての制御情報を検出する。第１の制御チャネルの前記候補位置をモニタする回数は、第２の制御チャネルの前記候補位置をモニタする回数よりも少ない。

Description

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

第５世代移動通信システム（5G）と呼ばれる通信システムが検討されている。5Gでは、高速な通信トラフィックの増大、接続する端末数の増大、高信頼性、低遅延が必要とされるユースケース毎に機能を柔軟に提供することが検討されている。これらのユースケースに対応する代表的なサービスとして、拡張モバイルブロードバンド（eMBB：enhanced Mobile Broadband）、大規模コミュニケーション/多数接続（mMTC：massive Machine Type Communications）、超信頼性・低遅延コミュニケーション（URLLC：Ultra Reliable and Low Latency Communications)がある。国際標準化団体である3GPP（3rd Generation Partnership Project）では、LTEシステムの高度化と、New RAT（Radio Access Technology）の両面から、通信システムの高度化を検討している（例えば、非特許文献１を参照）。

New RAT（又は、NRと呼ぶ）では、下りリンク制御情報（例えば、DCI：Downlink Control Information）を配置する制御信号チャネル（例えば、PDCCH：Physical Downlink Control Channel）領域として、control resource set（CORESET）が端末（UE：User Equipmentと呼ばれることもある）に設定される。UEは、CORESET内のPDCCH候補の位置を含むサーチスペース（SS：Search Space）をモニタ（又は、ブラインド復号と呼ぶ）し、DCIを検出することが検討されている。

RP-161596, "Revision of SI: Study on New Radio Access Technology", NTT DOCOMO, September 2016 R1-1809951, "Offline discussion summary of 7.2.6.1 Layer 1 enhancements", Huawei, HiSilicon, August 2018 R1-1700523, "Discussion on polar code for control channel", LG Electronics, January 2017

しかしながら、New RATにおいて、下り制御情報を検出する方法について十分に検討されていない。

本開示の非限定的な実施例は、下り制御情報を適切に検出することができる端末及び受信方法の提供に資する。

本開示の一実施例に係る端末は、下りリンク信号を受信する受信機と、前記下りリンク信号において、制御チャネルの候補位置をモニタして、端末宛ての制御情報を検出する回路と、を具備し、第１の制御チャネルの前記候補位置をモニタする回数は、第２の制御チャネルの前記候補位置をモニタする回数よりも少ない。

本開示の一実施例に係る端末は、下りリンク用に設定される第１のシンボル、上りリンク用に設定される第２のシンボル、及び、下りリンク用及び上りリンク用の双方に使用可能な第３のシンボルの何れかを示す指示情報を受信する受信機と、複数のシンボルのうち、前記指示情報によって前記第１のシンボルに設定されたシンボルにおいて、制御チャネルの候補位置をモニタする回路と、を具備する。

本開示の一実施例に係る受信方法は、下りリンク信号を受信し、前記下りリンク信号において、制御チャネルの候補位置をモニタして、端末宛ての制御情報を検出し、第１の制御チャネルの前記候補位置をモニタする回数は、第２の制御チャネルの前記候補位置をモニタする回数よりも少ない。

本開示の一実施例に係る受信方法は、下りリンクに設定される第１のシンボル、上りリンクに設定される第２のシンボル、及び、下りリンク及び上りリンクの双方に使用可能な第３のシンボルの何れかを示す指示情報を受信し、複数のシンボルのうち、前記指示情報によって前記第１のシンボルに設定されたシンボルにおいて、制御チャネルの候補位置をモニタする。

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

本開示の一実施例によれば、下り制御情報を適切に検出することができる。

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

SCSとPDCCH候補の最大モニタ回数との関係の一例を示す図 実施の形態１に係る端末の一部の構成例を示すブロック図 実施の形態１に係る基地局の構成例を示すブロック図 実施の形態１に係る端末の構成例を示すブロック図 実施の形態１に係る基地局及び端末の動作例を示すシーケンス図 サーチスペースの設定例を示す図 実施の形態１の動作例１−１に係るPDCCH候補のモニタ回数の一例を示す図 実施の形態１の動作例１−２に係るPDCCH候補のモニタ回数の一例を示す図 SFIの一例を示す図

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

URLLCでは、超信頼性及び低遅延が求められている。例えば、端末が制御信号を誤って受信（誤検出：False detection）すると、データ信号の送受信を誤る可能性がある。よって、URLLCでは、データ信号の誤り率の低減のみではなく、制御信号（例えば、PDCCH）及びデータ信号の双方の誤り率を低減することが求められている。

例えば、Release 15のNRでは、URLLCの信頼性として、1E-5の誤り率をターゲットとしている。一方、Release 16以降では、例えば、配電（power distribution）システム又は工場の自動化等のシナリオにおいて、Release 15のURLLCにおけるターゲットの誤り率（1E-5）よりも低い誤り率（例えば、1E-6）もターゲットに含まれている（例えば、非特許文献２を参照）。1E-6の誤り率を実現するためには、データ信号に加え、制御信号も1E-6を満たすことが望ましい。

また、端末は、PDCCH領域（例えば、CORESET）内の複数のPDCCH候補位置（例えば、サーチスペース）をモニタし、端末宛ての制御信号を検出する（ブラインドディコーディングとも呼ばれる）。

NRでは、端末がスロットあたりのPDCCH候補位置をモニタする回数（換言すると、モニタされるPDCCH候補数）が、例えば、図１に示す値（最大値）以下の値になるように規定されている。図１に示すように、サブキャリア間隔（SCS：subcarrier spacing。例えば、μで表される）が長いほど、スロット長が短くなるので、１スロットあたりのPDCCH候補位置をモニタする回数は少なくなる。

また、PDCCH（例えば、DCI）には、CRC（Cyclic Redundancy Check）と呼ばれるビットが付加される。さらに、CRCには、制御信号に割り当てられる識別子であるRNTI（Radio Network Temporary Identifier）の値が乗算（又は、マスクと呼ぶ）されている。端末は、RNTIの値及びCRCの結果（OK又はNG）に基づいて、端末宛ての制御信号であるか否かを判断する。

しかしながら、端末は、端末宛ての制御信号が送信されていないPDCCH候補位置であっても、CRCが誤ってOKとなり、端末宛ての制御信号を受信したと誤って判断（誤検出）することがある。CRCの系列長（ビット数）が長ければ、端末での誤検出の確率が低減するが、スループットが劣化してしまう、又は、処理量が増大してしまう。

そこで、本開示の一実施例では、CRCの系列長を増やすことなく、端末における誤検出確率を低減する方法について説明する。

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

図２は、本実施の形態に係る端末２００の一部の構成例を示すブロック図である。図２に示す端末２００において、受信部２０１は、下りリンク信号を受信する。DCI受信部２０３は、下りリンク信号において、制御チャネル（例えば、PDCCH）の候補位置（例えば、サーチスペース）をモニタして、端末２００宛ての制御情報（例えば、DCI）を検出する。このとき、第１の制御チャネル（例えば、URLLCに対応するPDCCH）をモニタする回数は、第２の制御チャネル（例えば、URLLC以外のユースケースに対応するPDCCH）をモニタする回数よりも少ない。

［基地局の構成］
図３は、本実施の形態に係る基地局１００の構成例を示すブロック図である。図３において、基地局１００は、CORESET設定部１０１と、RNTI設定部１０２と、サーチスペース設定部１０３と、DCI生成部１０４と、誤り訂正符号化部１０５と、変調部１０６と、信号割当部１０７と、送信部１０８と、受信部１０９と、信号分離部１１０と、復調部１１１と、誤り訂正復号部１１２と、を有する。

CORESET設定部１０１は、端末２００に設定されるCORESETに関するパラメータを決定する。CORESETの設定には、例えば、CORESETのリソース（例えば、PRB：Physical Resource Block）の位置、シンボル数、インタリーブの有無、又は、プリコーディングがある。CORESET設定部１０１は、決定したCORESETに関するパラメータを示すCORESET設定情報をサーチスペース設定部１０３に出力する。

RNTI設定部１０２は、端末２００がサーチスペース内のPDCCH候補位置をモニタする際に用いるRNTIを設定する。RNTI設定部１０２は、設定したRNTIを示すRNTI設定情報を、サーチスペース設定部１０３及びDCI生成部１０４に出力する。また、RNTI設定部１０２は、RNTI設定情報を、上位レイヤのシグナリング（又は、上位レイヤパラメータ、RRC（Radio Resource Control）パラメータと呼ぶこともある）として、誤り訂正符号化部１０５に出力する。

例えば、RNTI設定部１０２は、上位レイヤからの情報（図示せず）に基づいて、端末２００が扱うデータの種類を判別し、判別したデータ種別に対応するRNTIを設定する。例えば、RNTI設定部１０２は、通常のデータの送受信には「C-RNTI（Cell-RNTI）」を設定し、Configured Schedulingのデータには「CS-RNTI（Configured Scheduling RNTI）」を設定し、Release 15のURLLCには「MCS-C-RNTI（Modulation and Coding Scheme-C-RNTI）」を設定する。また、RNTI設定部１０２は、release 15のURLLCよりもさらに高信頼性が求められるデータには、新たなRNTI（以下、一例として「URLLC-C-RNTI」と呼ぶ）を設定する。なお、データ種別と、設定されるRNTIとの関係はこれらに限定されない。

サーチスペース設定部１０３は、端末２００に対するサーチスペースを設定する。サーチスペース設定部１０３は、CORESET設定情報、及び、設定したサーチスペースを示すサーチスペース設定情報を、上位レイヤのシグナリングとして、誤り訂正符号化部１０５に出力する。また、サーチスペース設定部１０３は、DCIをマッピングする位置を示すために、CORESET設定情報及びサーチスペース設定情報を信号割当部１０７に出力する。

例えば、サーチスペース設定部１０３は、各サーチスペースのサーチスペースIDと、CORESET設定部１０１から入力されるCORESET設定情報に示されるCORESETのCORESET IDとを対応付ける。また、サーチスペース設定部１０３は、例えば、DCIが配置されるリソース数（例えば、CCE（Control Channel Element）数）を表すAggregation level毎のサーチスペースをモニタする回数、サーチスペースの種別（例えば、CSS（Common Search Space）及びUSS（UE specific Search Space）の何れか）、サーチスペースが配置されるスロット間隔、及び、シンボル位置等を設定する。

また、サーチスペース設定部１０３は、RNTI設定部１０２から入力されるRNTI設定情報に基づいて、端末２００が「URLLC-C-RNTI」を用いてサーチスペースをモニタするように設定されている場合、設定したサーチスペースに対応するCORESETにおいて、URLLC-C-RNTIを用いたモニタを行うことを設定する。端末２００に設定されるサーチスペース（CSS又はUSS）には、URLLC-C-RNTI以外の他のRNTIについても端末２００におけるモニタの有無が設定されている。

DCI生成部１０４は、下りリンクデータ（DLデータ）又は上りリンクデータ（ULデータ）の割り当て（例えば、DL割り当て又はUL割り当て）を示す制御信号であるDCIを生成する。DCI生成部１０４は、DL割り当てを示すDL割当情報又はUL割り当てを示すUL割当情報を含むDCIを信号割当部１０７へ送信データとして出力する。なお、DCIに付加されるCRCビット列のうち一部（例えば、下位16ビット）については、RNTI設定部１０２から入力されるRNTI設定情報に基づいて、データ種別に対応するRNTIによってマスクされる。また、DCI生成部１０４は、DL割当情報を信号割当部１０７に出力し、UL割当情報を信号分離部１１０に出力する。

誤り訂正符号化部１０５は、送信データ信号（DLデータ信号）、及び、RNTI設定部１０２又はサーチスペース設定部１０３から入力される上位レイヤのシグナリングを入力とし、入力信号を誤り訂正符号化し、符号化後の信号を変調部１０６に出力する。

変調部１０６は、誤り訂正符号化部１０５から入力される信号に対して変調処理を施し、変調後のデータ信号を信号割当部１０７に出力する。

信号割当部１０７は、変調部１０６から入力されるデータ信号（例えば、DLデータ信号又は上位レイヤシグナリング）、又は、DCI生成部１０４から入力されるDCIを、リソースに割り当てる。例えば、信号割当部１０７は、サーチスペース設定部１０３から入力されるCORESET情報及びサーチスペース設定情報に従ってDCIを割り当てるリソースを決定し、決定したリソースにDCIを配置する。また、DCI（例えば、CRC）がURLLC-C-RNTIでマスクされている場合、信号割当部１０７は、サーチスペース設定情報に示される、URLLC-C-RNTIが設定されたUSSに当該DCIを配置する。また、信号割当部１０７は、DCI生成部１０４から入力されるDL割当情報に基づいて、DLデータ信号を配置する。形成された送信信号は、送信部１０８へ出力される。

送信部１０８は、信号割当部１０７から入力される信号に対してアップコンバート等の無線送信処理を施し、アンテナを介して端末２００へ送信する。

受信部１０９は、端末２００から送信された信号をアンテナを介して受信し、ダウンコンバート等の無線受信処理を施し、信号分離部１１０へ出力する。

信号分離部１１０は、DCI生成部１０４から入力されるUL割当情報に基づいて、受信部１０９から入力される信号を分離する。信号分離部１１０は、分離された信号を復調部１１１に出力する。

復調部１１１は、信号分離部１１０から入力される信号に対して復調処理を施し、得られた信号を誤り訂正復号部１１２に出力する。

誤り訂正復号部１１２は、復調部１１１から入力される信号を復号し、端末２００からの受信データ信号（ULデータ信号）を得る。

［端末の構成］
図４は、本実施の形態に係る端末２００の構成例を示すブロック図である。図４において、端末２００は、受信部２０１と、信号分離部２０２と、DCI受信部２０３と、復調部２０４と、誤り訂正復号部２０５と、RNTI設定受信部２０６と、サーチスペース設定受信部２０７と、CORESET設定部２０８と、誤り訂正符号化部２０９と、変調部２１０と、信号割当部２１１と、送信部２１２と、を有する。

受信部２０１は、受信信号をアンテナを介して受信し、ダウンコンバート等の受信処理を施した後に信号分離部２０２に出力する。

信号分離部２０２は、サーチスペース設定受信部２０７から入力されるサーチスペース設定情報、及び、CORESET設定部２０８から入力されるCORESET設定情報に基づいて、分離すべきCORESET内のサーチスペースを特定する。信号分離部２０２は、受信部２０１から入力される信号から、特定したサーチスペースに対応する信号成分を分離し、DCI受信部２０３へ出力する。また、信号分離部２０２は、DCI受信部２０３から入力されるDL割当情報に基づいて、受信部２０１から入力される信号から、DLデータ信号を分離し、DLデータ信号を復調部２０４へ出力する。また、信号分離部２０２は、受信部２０１から入力される信号から、上りレイヤシグナリングを分離し、上りレイヤシグナリングを復調部２０４へ出力する。

DCI受信部２０３は、RNTI設定受信部２０６から入力されるRNTI設定情報に基づいて、DCI（例えば、CRC）をマスクしているRNTIを設定する。また、DCI受信部２０３は、設定したRNTIを用いて、信号分離部２０２から入力される信号成分（例えば、PDCCH候補位置に対応する成分）をモニタする（ブラインドディコーディングとも呼ぶ)。

また、DCI受信部２０３は、サーチスペース設定受信部２０７から入力されるサーチスペース設定情報に基づいて、URLLC-C-RNTIを用いてモニタするように設定されているサーチスペースに対応するCORESETに対して、URLLC-C-RNTIを用いてPDCCH候補位置をモニタする。

DCI受信部２０３は、モニタによって検出されたDCIを復号し受信する。DCI受信部２０３は、復号されたDCIのうち、DL割当情報を信号分離部２０２に出力し、UL割当情報を信号割当部２１１に出力する。

復調部２０４は、信号分離部２０２から入力される信号に対して、復調処理を施し、得られた復調信号を誤り訂正復号部２０５に出力する。

誤り訂正復号部２０５は、復調部２０４から入力される復調信号を復号し、得られた上位レイヤシグナリングをRNTI設定受信部２０６及びサーチスペース設定受信部２０７に出力し、得られた受信データ信号を出力する。

RNTI設定受信部２０６は、誤り訂正復号部２０５から入力される上位レイヤシグナリングに含まれるRNTI設定情報を受信し、端末２００がサーチスペースのPDCCH候補位置のモニタに用いるRNTIの設定を取得する。RNTI設定受信部２０６は、PDCCH候補位置のモニタに用いるRNTIの設定を示すRNTI設定情報をDCI受信部２０３に出力する。

サーチスペース設定受信部２０７は、誤り訂正復号部２０５から入力される上位レイヤシグナリングに含まれるサーチスペース設定情報を受信し、例えば、サーチスペースID、Aggregation level毎にサーチスペースをモニタする回数、サーチスペースの種別（CSS又はUSS）、サーチスペースが配置されるスロット間隔、及び、シンボル位置等の設定を取得する。サーチスペース設定受信部２０７は、取得した設定を示すサーチスペース設定情報を信号分離部２０２に出力する。

また、サーチスペース設定受信部２０７は、上位レイヤのシグナリングに含まれるCORESET設定情報を受信し、CORESET設定情報をCORESET設定部２０８に出力する。

また、サーチスペース設定受信部２０７は、端末２００に対して、URLLC-C-RNTIを用いてモニタするCORESETに対応するサーチスペースが設定されている場合、URLLC-C-RNTIを用いてモニタするCORESETに対応するサーチスペース（例えば、サーチスペースID）を示す情報をDCI受信部２０３に出力する。

CORESET設定部２０８は、サーチスペース設定受信部２０７から入力されるCORESET設定情報に基づいて、端末２００に設定されたCORESETに関するパラメータ（例えば、PRBの位置、シンボル数、インタリーブの有無、プリコーディングの設定等）を示すCORESET設定情報を信号分離部２０２に出力する。

誤り訂正符号化部２０９は、送信データ信号（ULデータ信号）を入力とし、送信データ信号を誤り訂正符号化し、符号化後の信号を変調部２１０に出力する。

変調部２１０は、誤り訂正符号化部２０９から入力される信号を変調し、変調信号を信号割当部２１１に出力する。

信号割当部２１１は、DCI受信部２０３から入力される情報（例えば、UL割当情報）に基づいて、ULデータ信号を割り当てるリソースを特定し、特定したリソースに、変調部２１０から入力される信号（例えば、ULデータ信号）を割り当てて、送信部２１２に出力する。

送信部２１２は、信号割当部２１１から入力される信号に対してアップコンバート等の無線送信処理を施し、送信する。

［基地局１００及び端末２００の動作］
次に、基地局１００（図３を参照）及び端末２００（図４を参照）の動作について詳細に説明する。

図５は基地局１００及び端末２００の処理の一例を示すシーケンス図である。

図５において、基地局１００は、端末２００に対して、CORESET、RNTI及びサーチスペースを設定する（ＳＴ１０１）。基地局１００は、CORESET、RNTI及びサーチスペースの設定を示す上位レイヤシグナリングを端末２００へ通知する（ＳＴ１０２）。端末２００は、基地局１００から通知される上位レイヤシグナリングから、CORESET、RNTI及びサーチスペースの設定を取得する（ＳＴ１０３）。

基地局１００は、端末２００に対するスケジューリングを行い（ＳＴ１０４）、スケジューリング結果（例えば、DL割当情報又はUL割当情報）を含むDCIを生成する。なお、DCIは、例えば、端末２００に対してスケジューリングしたデータの種別に応じたRNTIを用いてマスクされる。

基地局１００は、例えば、ＳＴ１０１で設定したサーチスペースに対応するCORESETを用いて、生成したDCIを端末２００へ送信する（ＳＴ１０５）。

端末２００は、ＳＴ１０３で取得した設定に基づいて、サーチスペースに対応するCORESETをモニタし、端末２００宛てのPDCCH（又はDCI）を検出する（ＳＴ１０６）。なお、端末２００におけるサーチスペースのモニタ方法の詳細については後述する。

基地局１００及び端末２００は、DCIによって通知された内容に基づいて、データ（DLデータ又はULデータ）の送受信を行う（ＳＴ１０７）。

次に、端末２００におけるサーチスペース（PDCCH候補位置）のモニタ方法について詳細に説明する。

例えば、NRでは、以下のように、CSS及びUSS用に複数のサーチスペースが設定されている。
Type 0/0A CSS : SI-RNTI（System Information-RNTI）
Type 1 CSS : RA-RNTI（Random Access-RNTI）, TC-RNTI（Temporary C-RNTI）
Type 2 CSS : P-RNTI（Paging RNTI）
Type 3 CSS :INT-RNTI（Interruption RNTI）, SFI-RNTI（Slot Format Indication RNTI）, TPC-PUSCH-RNTI（Transmit Power Control-PUSCH-RNTI）, TPC-PUCCH-RNTI（TPC-Physical Uplink Control Channel-RNTI）, TPC-SRS-RNTI（TPC-Sounding Reference Symbols-RNTI）, C-RNTI, MCS-C-RNTI, CS-RNTI
USS: C-RNTI, MCS-C-RNTI, CS-RNTI

具体的には、CSSは、用途（換言すると、データ種別）毎に複数のタイプがある。UEは、CSSにおいて用途毎に異なるRNTIを用いてマスクされているPDCCH（DCI）を検出する。

一方、USSでは、UEは、UEに対してモニタするように設定されたRNTI（例えば、C-RNTI, MCS-C-RNTI及びCS-RNTI）を用いて、UEに設定されたUSS用の何れのCORESETでもモニタし、更に、Type 3 CSSでもモニタすることが規定されている。これは、データ信号のスケジューリングのフレキシビリティを向上させるためである。

例えば、Release 15では、MCS-C-RNTIをURLLC用のRNTIとして使用することができる。UEは、MCS-C-RNTIをモニタするように設定されると、USSにおいて、C-RNTI及びCS-RNTI（ただし、設定された場合）に加えて、MCS-C-RNTIでPDCCHをモニタする。また、UEがMCS-C-RNTIを用いてマスクされたPDCCHを検出した場合、データに使用されるMCS（変調方式及び符号化方法の組み合わせ）はURLLC用のMCSに変更される。

なお、同一サイズのPDCCHに対して異なる複数のRNTIを用いてモニタすることは、モニタ回数としては１回とカウントされる。よって、複数のRNTIを用いたUSS及びType 3 CSSのモニタに要するUEの処理量はそれほど増大しない。

上述したように、UEでは、UE宛ての制御信号が送信されていないPDCCH候補位置であってもCRCが誤ってOKとなり、UE宛ての制御信号を受信したと誤って判断（誤検出）することがある。

例えば、各制御信号（例えば、PDCCH）に付加されているCRCは24ビットである。ここで、24ビットのCRCにおいて、例えば、L=8のSCリストデコーダを制御信号の誤り訂正符号であるポーラ符号に適用することを考慮すると、誤検出確率（例えば、FAR：False Alarm Rate）は、おおよそ(1/2)^(21)=4.7E-7程度になると予想される（例えば、非特許文献３を参照）。したがって、UEが複数のPDCCH候補位置をモニタするほど、誤検出確率は高くなり、例えば、Release 16以降において要求される1E-6（換言すると、Release 15 URLLCにおいて要求される誤り率よりも低い誤り率）を超えてしまう可能性がある。

そこで、本実施の形態では、端末２００において超信頼性が求められるデータを割り当てるPDCCH（例えば、URLLC用のPDCCH）候補位置をモニタする回数は、URLLC以外のユースケース用のPDCCH候補位置をモニタする回数よりも少なく設定される。超信頼性が求められるPDCCHのモニタする回数が制限されることで、超信頼性が求められるPDCCHを誤検出する確率を低減することができる。

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

［動作例１−１］
動作例１−１では、超信頼性が求められるデータを割り当てるPDCCHに対して、新たなRNTIを割り当てる。換言すると、超信頼性が求められるデータを割り当てるPDCCHのマスクに用いるRNTIと、その他のPDCCHのマスクに用いるRNTIとを異ならせる。

ここでは、新たなRNTIの一例としてRNTI名を「URLLC-C-RNTI」とする。

また、動作例１−１では、端末２００がURLLC-C-RNTIを用いてモニタするPDCCHを配置するサーチスペースを制限する。例えば、端末２００がURLLC-C-RNTIを用いてPDCCHをモニタする領域は、端末２００に設定されたサーチスペースに対応するCORESETの一部の領域に制限される。

基地局１００は、端末２００にサーチスペースを設定する際、端末２００がURLLC-C-RNTIを用いてモニタするサーチスペース（又はCORESET）を指定する。

例えば、基地局１００は、サーチスペース設定の際にサーチスペースIDを設定する。また、基地局１００は、設定したサーチスペースIDに対応するサーチスペースがどのCORESET（CORESET ID）に配置されるか、時間的にモニタする周期、モニタするAggregation level、及び、サーチスペース種別（CSS又はUSS）等を設定する。

また、基地局１００は、上記サーチスペース設定に加え、サーチスペースにおいて端末２００が「URLLC-C-RNTI」を用いてモニタするか否かを決定する。

なお、動作例１−１において、端末２００は、URLLC-C-RNTIとMCS-C-RNTIとを併用できる。端末２００は、MCS-C-RNTIを用いてモニタするように設定された場合、例えば、CSS PDCCH type 3及び全てのUSSにおいてサーチスペースをモニタする。

また、動作例１−１では、端末２００に対してCS-RNTIは設定されていない。ただし、端末２００に対してCS-RNTIが設定されていてもよい。

図６は、１スロット内のサーチスペースの設定例を示す。

図６において、Type 3 PDCCH CSSであるサーチスペースID#1が、CORESET #1に設定されている。また、図６において、USSであるサーチスペースID#2がCORESET#2に設定され、サーチスペースID#3がCORSET#3に設定されている。

サーチスペースID#1（CSS#1）及びサーチスペースID#2(USS#2)では、端末２００は、１スロットあたり１つのタイミングでCORESETをモニタする。また、サーチスペースID#3（USS#3）では、端末２００は、１スロットあたり３つのタイミングでCORESETをモニタする。

また、図６では、端末２００は、USSであるサーチスペースID#3において新たなRNTI「URLLC-C-RNTI」を用いてPDCCHをモニタするように設定されている。

この場合、端末２００は、サーチスペースID#1（Type 3 PDCCH CSS）であるCORESET#1では、Type 3 PDCCH CSSにおいてモニタするように予め定められているRNTI（例えば、INT-RNTI, SFI-RNTI, TPC-PUSCH-RNTI, TPC-PUCCH-RNTI, TPC-SRS-RNTI, C-RNTI, MCS-C-RNTI（rel.15））を用いてPDCCHをモニタする。

また、端末２００は、サーチスペースID#2（USS）であるCORESET #2では、USSにおいてモニタするように予め定められているRNTI（C-RNTI及びMCS-C-RNTI(rel.15)）を用いてPDCCHをモニタする。

また、端末２００は、サーチスペースID#3（URLLC-C-RNTIでモニタするように設定されたUSS）であるCORESET #3では、USSにおいてモニタするように予め定められているRNTI（C-RNTI及びMCS-C-RNTI(rel.15)）に加え、URLLC-C-RNTIを用いてPDCCHをモニタする。

図７は、一例として、C-RNTI、MCS-C-RNTI(rel.15)、及び、URLLC-C-RNTIの各々を用いた１スロットあたりのPDCCHのモニタ回数を示す。

以下では、一例として、サーチスペースID#1（CSS#1）におけるPDCCHのモニタ回数が「５回」に設定され、サーチスペースID#2（USS#2）におけるPDCCHのモニタ回数が「２０回」に設定され、サーチスペースID#3（USS#3）におけるPDCCHのモニタ回数が、３つのタイミングの合計で「１２回」に設定される。

図６に示すように、C-RNTI及びMCS-C-RNTI(rel.15)は、CSS#1（CORESET#1）、USS#2（CORESET#2）及びUSS#3（CORESET#3）の全てに定められている。よって、図７に示すように、C-RNTI及びMCS-C-RNTI(rel.15)を用いた１スロットあたりのPDCCHモニタ回数は、各サーチスペース（CSS#1、USS#2及びUSS#3）に設定されたモニタ回数（５回、２０回及び１２回）の合計３７回となる。

一方、図６に示すように、URLLC-C-RNTIは、USS#3（CORESET#3）に定められ、他のサーチスペースには定められていない。よって、図７に示すように、URLLC-C-RNTIを用いた１スロットあたりのPDCCHモニタ回数は、USS#3に設定されたモニタ回数の１２回となる。

このように、動作例１−１では、端末２００がURLLC-C-RNTIを用いてモニタするサーチスペースは、一部のサーチスペース（図６ではUSS#3）に制限される。換言すると、URLLC-C-RNTIに対応するPDCCHについてモニタするチャネル領域は、他のRNTIに対応するPDCCHについてモニタするチャネル領域よりも小さい。URLLC-C-RNTIを用いてモニタするサーチスペースID及びCORESET IDを制限することで、図７に示すように、URLLC-C-RNTIを用いてサーチスペースをモニタする回数は、他のRNTIを用いてサーチスペースをモニタする回数よりも少なくなる。換言すると、URLLC-C-RNTIに対応するPDCCHについて、端末２００のモニタ回数を削減し、URLLC-C-RNTIに対応する超信頼性が求められるPDCCHの誤検出率を低減することができる。

また、C-RNTI及びMCS-C-RNTI（rel.15）については、端末２００は、全てのサーチスペース（例えば、全てのUSS及びType 3 CSS）においてPDCCHをモニタするので、リソース割り当てのフレキシビリティを維持できる。

例えば、基地局１００は、Release 15 URLLCよりも低い誤り率が求められるURLLCに対して、URLLC-C-RNTIを割り当てることにより、所望の誤り率特性に応じて、MCS-C-RNTIとURLLC-C-RNTIとを使い分けてもよく、併用してもよい。

なお、動作例１−１では、図７に示すように、全てのUSSにおいてC-RNTI及びMCS-C-RNTIを用いてPDCCHをモニタする場合について説明した。しかし、C-RNTI、MCS-C-RNTI又は、CS-RNTIについても、サーチスペース毎にPDCCHをモニタするか否かを個別に設定してもよい。これにより、URLLC-C-RNTI以外の他のRNTIについても端末２００がモニタするPDCCHが制限されるので、当該RNTIに対応するPDCCHの誤検出率を低減することができる。

［動作例１−２］
動作例１−２では、端末２００が、URLLC-C-RNTIについても、他のRNTIと同様の領域（例えば、Type 3 CSS及びUSS）においてPDCCHをモニタする点が動作例１−１と異なる。

ただし、URLLC-C-RNTIを用いてサーチスペースをモニタする回数（換言すると、PDCCHのモニタ回数）は、他のRNTI（例えば、C-RNTI等）を用いてサーチスペースをモニタする回数よりも少ない値に設定される。

例えば、基地局１００は、端末２００に対して、URLLC-C-RNTIを用いてサーチスペースをモニタする回数を通知する。

URLLC-C-RNTIを用いたPDCCHのモニタ回数は、例えば、全体（換言すると、他のRNTIを用いたPDCCHのモニタ回数）からの比率（又は差分）で表されてもよく、又は、数値で表されてもよい。

または、URLLC-C-RNTIを用いたPDCCHのモニタ回数の上限値が定められてもよい。端末２００に通知されるURLLC-C-RNTIを用いたPDCCHのモニタ回数が、上限値を超える場合、端末２００は、URLLC-C-RNTIを用いたPDCCHのモニタ回数を、上限値に制限する。

図８は、動作例１−２の一例として、C-RNTI、MCS-C-RNTI(rel.15)、及び、URLLC-C-RNTIの各々を用いた１スロットあたりのPDCCHのモニタ回数を示す。

図８では、URLLC-C-RNTIを用いたPDCCHのモニタ回数は、C-RNTI（又はMCS-C-RNTI）を用いたPDCCHのモニタ数の半分である。

例えば、端末２００は、C-RNTIに対するPDCCHのモニタ回数を取得した後、URLLC-C-RNTIに対するPDCCHのモニタ回数を、取得したモニタ回数の半数に設定する。なお、図８では、C-RNTIに対するPDCCHのモニタ数が割り切れない場合に、値を切り上げる例を示すが、これに限らず、値を切り捨ててもよい。

このように、動作例１−２では、URLLC-C-RNTIを用いたPDCCHについてモニタするチャネル領域（例えば、CORESET）は、URLLC-C-RNTI以外の他のRNTIを用いたPDCCHについてモニタするチャネル領域と同一である。ただし、動作例１−２では、端末２００に設定されるCORESETの各々において、URLLC-C-RNTIを用いてPDCCHをモニタする回数は、他のRNTIを用いてPDCCHをモニタする回数よりも少なく設定される。

これにより、端末２００は、URLLC-C-RNTIを用いてPDCCHをモニタするサーチスペースに対応するCORESETを制限することなく、端末２００のモニタ回数を削減し、URLLC-C-RTNIに対応する超信頼性が求められるPDCCHの誤検出率を低減することができる。

なお、端末２００に設定された各サーチスペースにおいて、端末２００がURLLC-C-RNTIを用いてモニタするPDCCH候補位置は、例えば、サーチスペース内のPDCCH候補番号の低い順、高い順、奇数番号、又は、偶数番号などで定めてもよい。

また、端末２００がURLLC-C-RNTIを用いてモニタするPDCCH候補位置のCCE Aggregation levelを制限してもよい。例えば、端末２００は、PDCCHをモニタするように定められたAggregation levelのうち、大きいAggregation levelを優先的にモニタしてもよい。大きいAggregation levelを優先的にモニタすることで、基地局１００は、端末２００に対して、URLLC用のDCIを大きいAggregation levelで送信できる。よって、大きいAggregation levelを優先的にモニタすることにより、小さいAggregation levelでDCIを送信する場合と比較して、誤り率特性を改善できる。

また、基地局１００は、端末２００に対して、どのAggregation levelを想定してURLLC用のPDCCH候補位置をモニタするかを別途通知してもよい。通知には、例えば、DCIが使用されてもよい。通知に使われるDCIには、例えば、グループ共通（group common）DCIが考えらえる。グループ共通DCIには、複数の端末宛てのAggregation levelの指示を含むことができる。端末２００は、受信したグループ共通DCIから、端末２００宛ての指示が含まれるビットを取り出し、端末２００のURLLC用PDCCH候補位置のAggregation levelを設定する。

［動作例１−３］
動作例１−３では、動作例１−１及び１−２と異なり、1E-6の誤り率をターゲットとする場合でも、URLLCに対応する「MCS-C-RNTI」を使用し、MCS-C-RNTIを用いてPDCCHをモニタする回数を制限する。

例えば、基地局１００は、端末２００に対して、MCS-C-RNTIを、Type 3 CSS及び全てのUSSにおけるPDCCHのモニタに用いるか、又は、動作例１−１における「URLLC-C-RNTI」のように、特定のUSSに制限されたPDCCHのモニタに用いるか、又は、動作例１−２における「URLLC-C-RNTI」のように、各サーチスペースにおいて回数を制限されたPDCCHのモニタに用いるかを通知する。

また、端末２００に対してMCS-C-RNTIを用いてPDCCHをモニタするように設定する際に、基地局１００は、Type 3 CSS及び全てのUSSにおいてPDCCHをモニタするか、PDCCHをモニタするUSSを制限するかを通知してもよい。また、動作例１−２のように、MCS-C-RNTIを用いてPDCCHをモニタするサーチスペースを制限せずに、サーチスペース内でMCS-C-RNTIを用いてPDCCHをモニタする回数を制限してもよい。

以上、動作例１−１、１−２及び１−３についてそれぞれ説明した。

なお、例えば、動作例１−１及び動作例１−２を組み合わせてもよい。例えば、URLLC-C-RNTIを用いたサーチスペースのモニタを、動作例１−１のように、端末２００に設定されるサーチスペースの一部に制限し、かつ、動作例１−２のように、一部のサーチスペースにおけるURLLC-C-RNTIを用いたPDCCHのモニタ回数は、他のRNTIを用いたPDCCHのモニタ回数より少なく設定されてもよい。

本実施の形態では、端末２００において、サーチスペース内のPDCCH候補位置をモニタして、端末２００宛てのDCIを検出する際、より低い信頼性が求められるPDCCHをモニタする回数は、他のPDCCHをモニタする回数よりも少なく設定される。

これにより、より低い信頼性が求められるPDCCHのモニタ回数が低減する分、誤検出確率も低減される。よって、CRCの系列長を増やすことなく、端末２００における誤検出の確率を低減することができる。よって、本実施の形態によれば、端末２００は、PDCCH（DCI）を適切に検出できるので、例えば、制御信号及びデータ信号の双方の誤り率の低減を実現できる。

なお、より低い信頼性が求められるPDCCH（例えば、URLLC用PDCCH）のモニタ回数を、他のPDCCHのモニタ回数よりも少なくすることで、URLLC用PDCCHを割当可能なリソース領域が小さくなる。しかし、URLLCは、他のユースケースと比較して、高信頼かつ低遅延が求められるため、優先度が高くなることが考えられる。よって、URLLC用PDCCHは、他のユースケースのPDCCHと比較して、リソースに優先的に割り当てられる可能性が高い。このため、URLLC用PDCCHを割当可能なリソース領域が小さくなっても、URLLC用PDCCHの割当に与える影響は小さい。

また、CS-RNTIでは、CRC以外にも、UEが既知のビット列が定められている。UEは、既知のビット列が正しく受信できているか否かに応じて、DCIを正しく受信できたか否かを検出できる。URLLC用のDCIに関しても、既知ビット列を挿入することが考えらえる。既知ビット列の長さが長いほど、誤検出の確率は低減する。したがって、既知ビット列が長いほど、URLLC用RNTIを用いたPDCCHのモニタ数を増加させ、既知ビット列が短いほど、URLLC用RNTIを用いたPDCCHのモニタ数を減少させてもよい。このようにすると、誤検出率に合わせて、URLLC用RNTIを用いたPDCCHのモニタ回数を設定することができる。

また、URLLCをモニタするサーチスペースは、１スロット内で複数回モニタするサーチスペースに限定してもよい。これは、URLLCでは、遅延時間の低減も求められているので、１スロット内で複数回モニタすることで、遅延量を低減できるからである。

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

NRでは、スロットフォーマットインディケータ（SFI：Slot Format Indicator）が導入される。SFIは、例えば、上位レイヤのシグナリングであるRRC（Radio Resource Control）又は物理レイヤのシグナリングであるDCI format 2_0を用いて通知される。また、SFIは、例えば、図９に示すように、スロット内のシンボルが、DL用に設定されたシンボル（「D」。DLシンボルと呼ぶ）、UL用に設定されたシンボル（「U」。ULシンボルと呼ぶ）、及び、フレキシブルシンボル（「F」）の何れであるかを通知する。

フレキシブルシンボルは、DLシンボル及びULシンボルの双方に使用可能である。また、フレキシブルシンボルは、リソース割り当てをしないシンボル（例えば、ブランクシンボル又はUnknownシンボルと呼ぶこともある）として使用可能である。

NRでは、RRCのSFIにおいてフレキシブルシンボルに設定されたシンボルに対して、DCI format 2_0のSFIを用いてULシンボル（「U」）又はDLシンボル（「D」）を指定できる。

なお、NRでは、RRCのSFIにおいてフレキシブルシンボルに設定され、かつ、DCI format 2_0のSFIにおいてフレキシブルシンボルに設定されたシンボルでは、UEがPDCCH候補位置をモニタしないことが定められている。

一方、RRCのSFIにおいてフレキシブルシンボルに設定され、DCI format 2_0のSFIによる設定がない場合、UEは、当該シンボルでもPDCCH候補位置をモニタすることができる。ただし、当該シンボルに対して、他のDCIによってPUSCH、PUCCH、RACH又はSRSの場所が指定され、当該シンボルがULシンボルとして使用されることが通知されている場合、UEは、当該シンボルをULシンボルとして使用し、PDCCH候補位置をモニタしない。

ここで、例えば、RRCのSFIによってフレキシブルシンボルが設定され、DCI format 2_0のSFIによる設定が無い場合、UEは、当該フレキシブルシンボルに対してUL送信を行うことを通知する他のDCIを検出すると、当該フレキシブルシンボルにおいてPDCCH候補位置をモニタしない。

しかしながら、UEが検出した、UL送信を通知する他のDCIが誤検出であり、実際には、基地局がフレキシブルシンボルにおいてPDCCH候補位置にDCIを送信していた場合、UEは、当該シンボルにおいてPDCCH候補位置をモニタしないので、DCIを検出することができない。UEがDCIの検出を誤るとデータを送受信できない。特に１E-6の誤り率をターゲットとするようなシナリオ（例えば、超信頼性が求められるユースケース）では、DCIの誤検出により、所望の誤り率を達成できなくなる可能性がある。また、誤検出により、再送が起こり、遅延量が増大するという問題がある。

そこで、本実施の形態では、端末２００は、低い誤り率が求められるURLLC用のRNTIを用いてマスクされたPDCCH候補位置を、DLに設定されたシンボルにおいてモニタする。換言すると、端末２００は、URLLC用のRNTIを用いてマスクされたPDCCH候補位置を、DL以外の用途に設定されたシンボル（例えば、ULシンボル又はフレキシブルシンボル）においてモニタしない。

このようにすると、端末２００は、フレキシブルシンボルにおいてPDCCH候補位置をモニタしない。よって、端末２００では、他のDCIを誤検出して、フレキシブルシンボルをULシンボルと誤って認識した場合に、PDCCHを受信できなくなることを防ぐことができる。

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

［動作例２−１］
動作例２−１では、DCIの誤検出によって、端末２００がフレキシブルシンボルをULシンボルと誤認識することを防ぐために、端末２００が低い誤り率が求められるURLLC用のRNTIを用いてPDCCHをモニタする場合、RRCのSFIに加え、DCI format 2_0のSFIを併用する。

例えば、実施の形態１の動作例１−１又は動作例１−２のように新たなRNTI「URLLC-C-RNTI」を用いてPDCCHをモニタするように設定されたスロットでは、基地局１００は、端末２００に対して、DCI format 2_0のSFIを通知する。

端末２００は、RRCのSFIによってフレキシブルシンボルと通知されたシンボルでは、DCI format 2_0のSFIによってDLシンボルと通知される場合、URLLC-C-RNTIを用いてPDCCH候補位置をモニタする。換言すると、端末２００は、RRCのSFIによってフレキシブルシンボルと通知されたシンボルにおいて、DCI format 2_0のSFIによってDLシンボル「D」と通知されない場合、URLLC-C-RNTIを用いてPDCCH候補位置をモニタしない。

これにより、端末２００は、DCI format 2_0のSFIによってDLシンボルと通知されているシンボルに対して、他のDCIによってULデータ、上りリンク制御信号（UCI：Uplink Control INformation）又は参照信号の送信が設定された場合でも、当該他のDCIを誤検出したと認識できる。よって、端末２００は、UL送信を止めて、基地局１００が実際に送信しているDCIについて、PDCCH候補位置をモニタすることができる。

このようにすると、DCIの誤検出による、PDCCH候補位置の検出ミスの確率を減らし、URLLCの誤検出に与える影響を軽減することができる。したがって、動作例２−１では、C-RNTIによりマスクされるDCIによって割り当てられるデータのように、リソース割当のフレキシビリティが求められるデータに関しても、PDCCH候補数を制限せずに、誤検出確率を低減できる。

［動作例２−２］
動作例２−２では、端末２００は、低い誤り率が求められるURLLC用のRNTIをモニタする場合に、RRCのSFIが設定され、DCI format 2_0のSFIが設定されない場合、RRCのSFIにおいてフレキシブルシンボルと通知されたシンボルでは、URLLC用のRNTIをモニタしない。

例えば、実施の形態１の動作例１−１又は動作例１−２のように、端末２００は、新たなRNTI「URLLC-C-RNTI」を用いてPDCCHをモニタするように指示されると、RRCのSFIにおいてフレキシブルシンボルと通知されたシンボルでは、URLLC-C-RNTIを用いてPDCCH候補位置をモニタせずに、他のRNTI（例えば、C-RNTI、CS-RNTI又はMCS-C-RNTI(rel.15)等）を用いてPDCCH候補位置をモニタする。

このようにすると、URLLC-C-RNTIによってマスクされるPDCCH（DCI）は、フレキシブルシンボルでは送信されない。よって、端末２００がフレキシブルシンボルをULシンボルと誤認識していても、URLLCの割り当てに関しては影響がない。

また、URLLC-C-RNTIによってマスクされるDCIがフレキシブルシンボルでは送信されず、他のRNTIでマスクされるDCIは、フレキシブルシンボルでも送信されるので、所望誤り率が1E-6のように低くないデータに対応するDCIに関しては、リソース割り当てのフレキシビリティを保つことができる。

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

このように、本実施の形態では、端末２００は、スロット内の複数のシンボルのうち、SFIによってDLシンボルに設定されたシンボルにおいて、より低い信頼性が求められるPDCCHをモニタする。

例えば、端末２００は、RRCのSFIによってフレキシブルシンボルに設定されたシンボルのうち、DCI format 2_0のSFIによってDLシンボルに設定されたシンボルにおいて、より低い信頼性が求められるPDCCHをモニタする。換言すると、基地局１００は、RRCのSFIによってフレキシブルシンボルに設定したシンボルのうち、DCI format 2_0のSFIによってDLシンボルに設定したシンボルにおいて、より低い信頼性が求められるPDCCH（又はDCI）を割り当てる。

このように、より低い信頼性が求められるPDCCHが割り当てられるシンボル（換言すると、モニタ対象のシンボル）が制限されることにより、端末２００は、より低い信頼性が求められるPDCCHを確実に検出できるので、誤検出確率が低減される。よって、CRCの系列長を増やすことなく、端末２００における誤検出の確率を低減することができる。

よって、本実施の形態によれば、端末２００は、PDCCH（DCI）を適切に検出できるので、例えば、制御信号及びデータ信号の双方の誤り率の低減を実現できる。

なお、動作例２−１及び動作例２−２は、実施の形態１の動作例１−１及び動作例１−２のように新たなRNTI「URLLC-C-RNTI」が使用される前提で説明しているが、実施の形態１の動作例１−３のように、「MCS-C-RNTI」を使用する場合にも適用できる。この場合、動作例２−１では、端末２００がMCS-C-RNTIをモニタするスロットでは、DCI format 2_0のSFIが送信される。また、動作例２−２では、RRCのSFIで指示されたフレキシブルシンボルでは、端末２００は、MCS-C-RNTIを用いてPDCCH候補位置をモニタしない。

以上、本開示の各実施の形態について説明した。

（他の実施の形態）
なお、上記実施の形態では、上位レイヤのシグナリングには、RRCシグナリングを想定しているが、MACのシグナリング、及び、物理レイヤのシグナリングであるDCIでの通知に置き換えてもよい。MACのシグナリングおよび物理レイヤのシグナリングの場合、RRCのシグナリングと比較して、変更の頻度を上げることができる。

また、URLLC-C-RNTIという名称は一例であり、他の名前のRNTIに対して、上記実施例を適用することもできる。

また、上記実施の形態では、より低い信頼性が求められるデータ種別（又は用途）の一例にURLLCを用いたが、より低い信頼性が求められるデータ種別はURLLCに限らない。URLLCの用途以外のRNTIについても、C-RNTI等の他のRNTIと比較して、PDCCH候補位置のモニタ回数を変更したい場合（例えば、少なくしたい場合）、上記実施の形態を適用できる。

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

本開示は、通信機能を持つあらゆる種類の装置、デバイス、システム（通信装置と総称）において実施可能である。通信装置の、非限定的な例としては、電話機（携帯電話、スマートフォン等）、タブレット、パーソナル・コンピューター（ＰＣ）（ラップトップ、デスクトップ、ノートブック等）、カメラ（デジタル・スチル／ビデオ・カメラ等）、デジタル・プレーヤー（デジタル・オーディオ／ビデオ・プレーヤー等）、着用可能なデバイス（ウェアラブル・カメラ、スマートウオッチ、トラッキングデバイス等）、ゲーム・コンソール、デジタル・ブック・リーダー、テレヘルス・テレメディシン（遠隔ヘルスケア・メディシン処方）デバイス、通信機能付きの乗り物又は移動輸送機関（自動車、飛行機、船等）、及び上述の各種装置の組み合わせがあげられる。

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

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

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

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

本開示の一実施例における端末は、下りリンク信号を受信する受信機と、前記下りリンク信号において、制御チャネルの候補位置をモニタして、端末宛ての制御情報を検出する回路と、を具備し、第１の制御チャネルの前記候補位置をモニタする回数は、第２の制御チャネルの前記候補位置をモニタする回数よりも少ない。

本開示の一実施例における端末において、前記第１の制御チャネルについてモニタするチャネル領域は、前記第２の制御チャネルについてモニタするチャネル領域よりも小さい。

本開示の一実施例における端末において、前記第１の制御チャネルについてモニタするチャネル領域は、前記第２の制御チャネルについてモニタするチャネル領域と同一であり、前記チャネル領域の各々において、前記第１の制御チャネルの前記候補位置をモニタする回数は、前記第２の制御チャネルの前記候補位置をモニタする回数よりも少ない。

本開示の一実施例における端末において、前記第１の制御チャネルのマスクに用いる識別子と、前記第２の制御チャネルのマスクに用いる識別子とは異なる。

本開示の一実施例における端末は、下りリンク用に設定される第１のシンボル、上りリンク用に設定される第２のシンボル、及び、下りリンク用及び上りリンク用の双方に使用可能な第３のシンボルの何れかを示す指示情報を受信する受信機と、複数のシンボルのうち、前記指示情報によって前記第１のシンボルに設定されたシンボルにおいて、制御チャネルの候補位置をモニタする回路と、を具備する。

本開示の一実施例における端末において、前記指示情報は、物理レイヤで通知される。

本開示の一実施例における端末において、前記受信機は、上位レイヤで通知される第１の指示情報、及び、物理レイヤで通知される第２の指示情報を受信し、前記回路は、前記第１の指示情報によって前記第３のシンボルに設定され、前記第２の指示情報によって前記第１のシンボルに設定されたシンボルにおいて、前記制御チャネルの候補位置をモニタし、前記第１の指示情報によって前記第３のシンボルに設定され、前記第２の指示情報が無い場合、前記制御チャネルの候補位置をモニタしない。

本開示の一実施例における受信方法は、下りリンク信号を受信し、前記下りリンク信号において、制御チャネルの候補位置をモニタして、端末宛ての制御情報を検出し、第１の制御チャネルの前記候補位置をモニタする回数は、第２の制御チャネルの前記候補位置をモニタする回数よりも少ない。

本開示の一実施例における受信方法は、下りリンクに設定される第１のシンボル、上りリンクに設定される第２のシンボル、及び、下りリンク及び上りリンクの双方に使用可能な第３のシンボルの何れかを示す指示情報を受信し、複数のシンボルのうち、前記指示情報によって前記第１のシンボルに設定されたシンボルにおいて、制御チャネルの候補位置をモニタする。

２０１８年９月２７日出願の特願２０１８−１８１８６７の日本出願に含まれる明細書、図面および要約書の開示内容は、すべて本願に援用される。

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

１００ 基地局
１０１，２０８ CORESET設定部
１０２ RNTI設定部
１０３ サーチスペース設定部
１０４ DCI生成部
１０５，２０９ 誤り訂正符号化部
１０６，２１０ 変調部
１０７，２１１ 信号割当部
１０８，２１２ 送信部
１０９，２０１ 受信部
１１０，２０２ 信号分離部
１１１，２０４ 復調部
１１２，２０５ 誤り訂正復号部
２００ 端末
２０３ DCI受信部
２０６ RNTI設定受信部
２０７ サーチスペース設定受信部

Claims (9)

1. 下りリンク信号を受信する受信機と、
   前記下りリンク信号において、制御チャネルの候補位置をモニタして、端末宛ての制御情報を検出する回路と、
   を具備し、
   第１の制御チャネルの前記候補位置をモニタする回数は、第２の制御チャネルの前記候補位置をモニタする回数よりも少ない、
   端末。
2. 前記第１の制御チャネルについてモニタするチャネル領域は、前記第２の制御チャネルについてモニタするチャネル領域よりも小さい、
   請求項１に記載の端末。
3. 前記第１の制御チャネルについてモニタするチャネル領域は、前記第２の制御チャネルについてモニタするチャネル領域と同一であり、
   前記チャネル領域の各々において、前記第１の制御チャネルの前記候補位置をモニタする回数は、前記第２の制御チャネルの前記候補位置をモニタする回数よりも少ない、
   請求項１に記載の端末。
4. 前記第１の制御チャネルのマスクに用いる識別子と、前記第２の制御チャネルのマスクに用いる識別子とは異なる、
   請求項１に記載の端末。
5. 下りリンク用に設定される第１のシンボル、上りリンク用に設定される第２のシンボル、及び、下りリンク用及び上りリンク用の双方に使用可能な第３のシンボルの何れかを示す指示情報を受信する受信機と、
   複数のシンボルのうち、前記指示情報によって前記第１のシンボルに設定されたシンボルにおいて、制御チャネルの候補位置をモニタする回路と、
   を具備する端末。
6. 前記指示情報は、物理レイヤで通知される、
   請求項５に記載の端末。
7. 前記受信機は、上位レイヤで通知される第１の指示情報、及び、物理レイヤで通知される第２の指示情報を受信し、
   前記回路は、
   前記第１の指示情報によって前記第３のシンボルに設定され、前記第２の指示情報によって前記第１のシンボルに設定されたシンボルにおいて、前記制御チャネルの候補位置をモニタし、
   前記第１の指示情報によって前記第３のシンボルに設定され、前記第２の指示情報が無い場合、前記制御チャネルの候補位置をモニタしない、
   請求項５に記載の端末。
8. 下りリンク信号を受信し、
   前記下りリンク信号において、制御チャネルの候補位置をモニタして、端末宛ての制御情報を検出し、
   第１の制御チャネルの前記候補位置をモニタする回数は、第２の制御チャネルの前記候補位置をモニタする回数よりも少ない、
   受信方法。
9. 下りリンクに設定される第１のシンボル、上りリンクに設定される第２のシンボル、及び、下りリンク及び上りリンクの双方に使用可能な第３のシンボルの何れかを示す指示情報を受信し、
   複数のシンボルのうち、前記指示情報によって前記第１のシンボルに設定されたシンボルにおいて、制御チャネルの候補位置をモニタする、
   受信方法。

Images