(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】
(24)【登録日】2024-06-19
(45)【発行日】2024-06-27
(54)【発明の名称】端末及び受信方法
(51)【国際特許分類】
H04W 72/232 20230101AFI20240620BHJP
H04W 72/512 20230101ALI20240620BHJP
H04W 72/0446 20230101ALI20240620BHJP
H04W 72/0453 20230101ALI20240620BHJP
【FI】
H04W72/232
H04W72/512
H04W72/0446
H04W72/0453 110
(21)【出願番号】P 2020548034
(86)(22)【出願日】2019-07-16
(86)【国際出願番号】 JP2019027938
(87)【国際公開番号】W WO2020066232
(87)【国際公開日】2020-04-02
【審査請求日】2022-07-08
(31)【優先権主張番号】P 2018181867
(32)【優先日】2018-09-27
(33)【優先権主張国・地域又は機関】JP
【前置審査】
(73)【特許権者】
【識別番号】514136668
【氏名又は名称】パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカ
【氏名又は名称原語表記】Panasonic Intellectual Property Corporation of America
(74)【代理人】
【識別番号】110002952
【氏名又は名称】弁理士法人鷲田国際特許事務所
(72)【発明者】
【氏名】堀内 綾子
(72)【発明者】
【氏名】鈴木 秀俊
【審査官】野村 潔
(56)【参考文献】
【文献】ZTE,PDCCH monitoring for slots and mini-slots,3GPP TSG RAN WG1 #89 R1-1707162,Internet<URL:http://www.3gpp.org/ftp/tsg_ran/WG1_RL1/TSGR1_89/Docs/R1-1707162.zip>,2017年05月06日
【文献】Huawei, HiSilicon,Summary of 7.2.2 Study of necessity of a new DCI format,3GPP TSG RAN WG1 #92b R1-1805630,Internet<URL:http://www.3gpp.org/ftp/tsg_ran/WG1_RL1/TSGR1_92b/Docs/R1-1805630.zip>,2018年04月19日
【文献】LG Electronics,Discussion on differentiation of eMBB and URLLC services,3GPP TSG RAN WG1 #94 R1-1808534,Internet<URL:http://www.3gpp.org/ftp/tsg_ran/WG1_RL1/TSGR1_94/Docs/R1-1808534.zip>,2018年08月11日
【文献】LG Electronics,Discussion on layer 1 enhancements,3GPP TSG RAN WG1 #94 R1-1808531,Internet<URL:http://www.3gpp.org/ftp/tsg_ran/WG1_RL1/TSGR1_94/Docs/R1-1808531.zip>,2018年08月11日
【文献】Ericsson,On Compact DCI for URLLC,3GPP TSG RAN WG1 #92b R1-1803920,Internet<URL:http://www.3gpp.org/ftp/tsg_ran/WG1_RL1/TSGR1_92b/Docs/R1-1803920.zip>,2018年04月07日
(58)【調査した分野】(Int.Cl.,DB名)
H04B 7/24- 7/26
H04W 4/00-99/00
3GPP TSG RAN WG1-4
SA WG1-4
CT WG1、4
(57)【特許請求の範囲】
【請求項1】
下りリンク信号を受信する受信機と、
前記下りリンク信号において、制御チャネルの候補位置をモニタして、端末宛ての制御情報を検出する回路と、
を具備し、
Ultra Reliable and Low Latency Communications(URLLC)に対応する第1の制御チャネルの前記候補位置をモニタする第1の回数は、URLLC以外のユースケースに対応する第2の制御チャネルの前記候補位置をモニタする第2の回数よりも少なく、
前記第1の回数は、1スロット内における複数のサーチスペースのうち、前記第1の制御チャネルが設定されたサーチスペースにおけるモニタ数の合計であり、
前記第2の回数は、前記複数のサーチスペースのうち、前記第2の制御チャネルが設定されたサーチスペースにおけるモニタ数の合計であ
り、
前記第1の制御チャネルについてモニタするチャネル領域は、前記第2の制御チャネルについてモニタするチャネル領域よりも小さい、
端末。
【請求項2】
前記第1の制御チャネルのマスクに用いる識別子と、前記第2の制御チャネルのマスクに用いる識別子とは異なる、
請求項1に記載の端末。
【請求項3】
下りリンク信号を受信し、
前記下りリンク信号において、制御チャネルの候補位置をモニタして、端末宛ての制御情報を検出し、
Ultra Reliable and Low Latency Communications(URLLC)に対応する第1の制御チャネルの前記候補位置をモニタする第1の回数は、URLLC以外のユースケースに対応する第2の制御チャネルの前記候補位置をモニタする第2の回数よりも少なく、
前記第1の回数は、1スロット内における複数のサーチスペースのうち、前記第1の制御チャネルが設定されたサーチスペースにおけるモニタ数の合計であり、
前記第2の回数は、前記複数のサーチスペースのうち、前記第2の制御チャネルが設定されたサーチスペースにおけるモニタ数の合計であ
り、
前記第1の制御チャネルについてモニタするチャネル領域は、前記第2の制御チャネルについてモニタするチャネル領域よりも小さい、
受信方法。
【発明の詳細な説明】
【技術分野】
【0001】
本開示は、端末及び受信方法に関する。
【背景技術】
【0002】
第5世代移動通信システム(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)の両面から、通信システムの高度化を検討している(例えば、非特許文献1を参照)。
【0003】
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を検出することが検討されている。
【先行技術文献】
【非特許文献】
【0004】
【文献】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
【発明の概要】
【0005】
しかしながら、New RATにおいて、下り制御情報を検出する方法について十分に検討されていない。
【0006】
本開示の非限定的な実施例は、下り制御情報を適切に検出することができる端末及び受信方法の提供に資する。
【0007】
本開示の一実施例に係る端末は、下りリンク信号を受信する受信機と、前記下りリンク信号において、制御チャネルの候補位置をモニタして、端末宛ての制御情報を検出する回路と、を具備し、第1の制御チャネルの前記候補位置をモニタする回数は、第2の制御チャネルの前記候補位置をモニタする回数よりも少ない。
【0008】
本開示の一実施例に係る端末は、下りリンク用に設定される第1のシンボル、上りリンク用に設定される第2のシンボル、及び、下りリンク用及び上りリンク用の双方に使用可能な第3のシンボルの何れかを示す指示情報を受信する受信機と、複数のシンボルのうち、前記指示情報によって前記第1のシンボルに設定されたシンボルにおいて、制御チャネルの候補位置をモニタする回路と、を具備する。
【0009】
本開示の一実施例に係る受信方法は、下りリンク信号を受信し、前記下りリンク信号において、制御チャネルの候補位置をモニタして、端末宛ての制御情報を検出し、第1の制御チャネルの前記候補位置をモニタする回数は、第2の制御チャネルの前記候補位置をモニタする回数よりも少ない。
【0010】
本開示の一実施例に係る受信方法は、下りリンクに設定される第1のシンボル、上りリンクに設定される第2のシンボル、及び、下りリンク及び上りリンクの双方に使用可能な第3のシンボルの何れかを示す指示情報を受信し、複数のシンボルのうち、前記指示情報によって前記第1のシンボルに設定されたシンボルにおいて、制御チャネルの候補位置をモニタする。
【0011】
なお、これらの包括的または具体的な態様は、システム、装置、方法、集積回路、コンピュータプログラム、または、記録媒体で実現されてもよく、システム、装置、方法、集積回路、コンピュータプログラムおよび記録媒体の任意な組み合わせで実現されてもよい。
【0012】
本開示の一実施例によれば、下り制御情報を適切に検出することができる。
【0013】
本開示の一態様における更なる利点および効果は、明細書および図面から明らかにされる。かかる利点および/または効果は、いくつかの実施形態並びに明細書および図面に記載された特徴によってそれぞれ提供されるが、1つまたはそれ以上の同一の特徴を得るために必ずしも全てが提供される必要はない。
【図面の簡単な説明】
【0014】
【
図1】SCSとPDCCH候補の最大モニタ回数との関係の一例を示す図
【
図2】実施の形態1に係る端末の一部の構成例を示すブロック図
【
図3】実施の形態1に係る基地局の構成例を示すブロック図
【
図4】実施の形態1に係る端末の構成例を示すブロック図
【
図5】実施の形態1に係る基地局及び端末の動作例を示すシーケンス図
【
図7】実施の形態1の動作例1-1に係るPDCCH候補のモニタ回数の一例を示す図
【
図8】実施の形態1の動作例1-2に係るPDCCH候補のモニタ回数の一例を示す図
【発明を実施するための形態】
【0015】
以下、本開示の実施の形態について図面を参照して詳細に説明する。
【0016】
URLLCでは、超信頼性及び低遅延が求められている。例えば、端末が制御信号を誤って受信(誤検出:False detection)すると、データ信号の送受信を誤る可能性がある。よって、URLLCでは、データ信号の誤り率の低減のみではなく、制御信号(例えば、PDCCH)及びデータ信号の双方の誤り率を低減することが求められている。
【0017】
例えば、Release 15のNRでは、URLLCの信頼性として、1E-5の誤り率をターゲットとしている。一方、Release 16以降では、例えば、配電(power distribution)システム又は工場の自動化等のシナリオにおいて、Release 15のURLLCにおけるターゲットの誤り率(1E-5)よりも低い誤り率(例えば、1E-6)もターゲットに含まれている(例えば、非特許文献2を参照)。1E-6の誤り率を実現するためには、データ信号に加え、制御信号も1E-6を満たすことが望ましい。
【0018】
また、端末は、PDCCH領域(例えば、CORESET)内の複数のPDCCH候補位置(例えば、サーチスペース)をモニタし、端末宛ての制御信号を検出する(ブラインドディコーディングとも呼ばれる)。
【0019】
NRでは、端末がスロットあたりのPDCCH候補位置をモニタする回数(換言すると、モニタされるPDCCH候補数)が、例えば、
図1に示す値(最大値)以下の値になるように規定されている。
図1に示すように、サブキャリア間隔(SCS:subcarrier spacing。例えば、μで表される)が長いほど、スロット長が短くなるので、1スロットあたりのPDCCH候補位置をモニタする回数は少なくなる。
【0020】
また、PDCCH(例えば、DCI)には、CRC(Cyclic Redundancy Check)と呼ばれるビットが付加される。さらに、CRCには、制御信号に割り当てられる識別子であるRNTI(Radio Network Temporary Identifier)の値が乗算(又は、マスクと呼ぶ)されている。端末は、RNTIの値及びCRCの結果(OK又はNG)に基づいて、端末宛ての制御信号であるか否かを判断する。
【0021】
しかしながら、端末は、端末宛ての制御信号が送信されていないPDCCH候補位置であっても、CRCが誤ってOKとなり、端末宛ての制御信号を受信したと誤って判断(誤検出)することがある。CRCの系列長(ビット数)が長ければ、端末での誤検出の確率が低減するが、スループットが劣化してしまう、又は、処理量が増大してしまう。
【0022】
そこで、本開示の一実施例では、CRCの系列長を増やすことなく、端末における誤検出確率を低減する方法について説明する。
【0023】
(実施の形態1)
[通信システムの概要]
本実施の形態に係る通信システムは、基地局100、及び、端末200を備える。
【0024】
図2は、本実施の形態に係る端末200の一部の構成例を示すブロック図である。
図2に示す端末200において、受信部201は、下りリンク信号を受信する。DCI受信部203は、下りリンク信号において、制御チャネル(例えば、PDCCH)の候補位置(例えば、サーチスペース)をモニタして、端末200宛ての制御情報(例えば、DCI)を検出する。このとき、第1の制御チャネル(例えば、URLLCに対応するPDCCH)をモニタする回数は、第2の制御チャネル(例えば、URLLC以外のユースケースに対応するPDCCH)をモニタする回数よりも少ない。
【0025】
[基地局の構成]
図3は、本実施の形態に係る基地局100の構成例を示すブロック図である。
図3において、基地局100は、CORESET設定部101と、RNTI設定部102と、サーチスペース設定部103と、DCI生成部104と、誤り訂正符号化部105と、変調部106と、信号割当部107と、送信部108と、受信部109と、信号分離部110と、復調部111と、誤り訂正復号部112と、を有する。
【0026】
CORESET設定部101は、端末200に設定されるCORESETに関するパラメータを決定する。CORESETの設定には、例えば、CORESETのリソース(例えば、PRB:Physical Resource Block)の位置、シンボル数、インタリーブの有無、又は、プリコーディングがある。CORESET設定部101は、決定したCORESETに関するパラメータを示すCORESET設定情報をサーチスペース設定部103に出力する。
【0027】
RNTI設定部102は、端末200がサーチスペース内のPDCCH候補位置をモニタする際に用いるRNTIを設定する。RNTI設定部102は、設定したRNTIを示すRNTI設定情報を、サーチスペース設定部103及びDCI生成部104に出力する。また、RNTI設定部102は、RNTI設定情報を、上位レイヤのシグナリング(又は、上位レイヤパラメータ、RRC(Radio Resource Control)パラメータと呼ぶこともある)として、誤り訂正符号化部105に出力する。
【0028】
例えば、RNTI設定部102は、上位レイヤからの情報(図示せず)に基づいて、端末200が扱うデータの種類を判別し、判別したデータ種別に対応するRNTIを設定する。例えば、RNTI設定部102は、通常のデータの送受信には「C-RNTI(Cell-RNTI)」を設定し、Configured Schedulingのデータには「CS-RNTI(Configured Scheduling RNTI)」を設定し、Release 15のURLLCには「MCS-C-RNTI(Modulation and Coding Scheme-C-RNTI)」を設定する。また、RNTI設定部102は、release 15のURLLCよりもさらに高信頼性が求められるデータには、新たなRNTI(以下、一例として「URLLC-C-RNTI」と呼ぶ)を設定する。なお、データ種別と、設定されるRNTIとの関係はこれらに限定されない。
【0029】
サーチスペース設定部103は、端末200に対するサーチスペースを設定する。サーチスペース設定部103は、CORESET設定情報、及び、設定したサーチスペースを示すサーチスペース設定情報を、上位レイヤのシグナリングとして、誤り訂正符号化部105に出力する。また、サーチスペース設定部103は、DCIをマッピングする位置を示すために、CORESET設定情報及びサーチスペース設定情報を信号割当部107に出力する。
【0030】
例えば、サーチスペース設定部103は、各サーチスペースのサーチスペースIDと、CORESET設定部101から入力されるCORESET設定情報に示されるCORESETのCORESET IDとを対応付ける。また、サーチスペース設定部103は、例えば、DCIが配置されるリソース数(例えば、CCE(Control Channel Element)数)を表すAggregation level毎のサーチスペースをモニタする回数、サーチスペースの種別(例えば、CSS(Common Search Space)及びUSS(UE specific Search Space)の何れか)、サーチスペースが配置されるスロット間隔、及び、シンボル位置等を設定する。
【0031】
また、サーチスペース設定部103は、RNTI設定部102から入力されるRNTI設定情報に基づいて、端末200が「URLLC-C-RNTI」を用いてサーチスペースをモニタするように設定されている場合、設定したサーチスペースに対応するCORESETにおいて、URLLC-C-RNTIを用いたモニタを行うことを設定する。端末200に設定されるサーチスペース(CSS又はUSS)には、URLLC-C-RNTI以外の他のRNTIについても端末200におけるモニタの有無が設定されている。
【0032】
DCI生成部104は、下りリンクデータ(DLデータ)又は上りリンクデータ(ULデータ)の割り当て(例えば、DL割り当て又はUL割り当て)を示す制御信号であるDCIを生成する。DCI生成部104は、DL割り当てを示すDL割当情報又はUL割り当てを示すUL割当情報を含むDCIを信号割当部107へ送信データとして出力する。なお、DCIに付加されるCRCビット列のうち一部(例えば、下位16ビット)については、RNTI設定部102から入力されるRNTI設定情報に基づいて、データ種別に対応するRNTIによってマスクされる。また、DCI生成部104は、DL割当情報を信号割当部107に出力し、UL割当情報を信号分離部110に出力する。
【0033】
誤り訂正符号化部105は、送信データ信号(DLデータ信号)、及び、RNTI設定部102又はサーチスペース設定部103から入力される上位レイヤのシグナリングを入力とし、入力信号を誤り訂正符号化し、符号化後の信号を変調部106に出力する。
【0034】
変調部106は、誤り訂正符号化部105から入力される信号に対して変調処理を施し、変調後のデータ信号を信号割当部107に出力する。
【0035】
信号割当部107は、変調部106から入力されるデータ信号(例えば、DLデータ信号又は上位レイヤシグナリング)、又は、DCI生成部104から入力されるDCIを、リソースに割り当てる。例えば、信号割当部107は、サーチスペース設定部103から入力されるCORESET情報及びサーチスペース設定情報に従ってDCIを割り当てるリソースを決定し、決定したリソースにDCIを配置する。また、DCI(例えば、CRC)がURLLC-C-RNTIでマスクされている場合、信号割当部107は、サーチスペース設定情報に示される、URLLC-C-RNTIが設定されたUSSに当該DCIを配置する。また、信号割当部107は、DCI生成部104から入力されるDL割当情報に基づいて、DLデータ信号を配置する。形成された送信信号は、送信部108へ出力される。
【0036】
送信部108は、信号割当部107から入力される信号に対してアップコンバート等の無線送信処理を施し、アンテナを介して端末200へ送信する。
【0037】
受信部109は、端末200から送信された信号をアンテナを介して受信し、ダウンコンバート等の無線受信処理を施し、信号分離部110へ出力する。
【0038】
信号分離部110は、DCI生成部104から入力されるUL割当情報に基づいて、受信部109から入力される信号を分離する。信号分離部110は、分離された信号を復調部111に出力する。
【0039】
復調部111は、信号分離部110から入力される信号に対して復調処理を施し、得られた信号を誤り訂正復号部112に出力する。
【0040】
誤り訂正復号部112は、復調部111から入力される信号を復号し、端末200からの受信データ信号(ULデータ信号)を得る。
【0041】
[端末の構成]
図4は、本実施の形態に係る端末200の構成例を示すブロック図である。
図4において、端末200は、受信部201と、信号分離部202と、DCI受信部203と、復調部204と、誤り訂正復号部205と、RNTI設定受信部206と、サーチスペース設定受信部207と、CORESET設定部208と、誤り訂正符号化部209と、変調部210と、信号割当部211と、送信部212と、を有する。
【0042】
受信部201は、受信信号をアンテナを介して受信し、ダウンコンバート等の受信処理を施した後に信号分離部202に出力する。
【0043】
信号分離部202は、サーチスペース設定受信部207から入力されるサーチスペース設定情報、及び、CORESET設定部208から入力されるCORESET設定情報に基づいて、分離すべきCORESET内のサーチスペースを特定する。信号分離部202は、受信部201から入力される信号から、特定したサーチスペースに対応する信号成分を分離し、DCI受信部203へ出力する。また、信号分離部202は、DCI受信部203から入力されるDL割当情報に基づいて、受信部201から入力される信号から、DLデータ信号を分離し、DLデータ信号を復調部204へ出力する。また、信号分離部202は、受信部201から入力される信号から、上りレイヤシグナリングを分離し、上りレイヤシグナリングを復調部204へ出力する。
【0044】
DCI受信部203は、RNTI設定受信部206から入力されるRNTI設定情報に基づいて、DCI(例えば、CRC)をマスクしているRNTIを設定する。また、DCI受信部203は、設定したRNTIを用いて、信号分離部202から入力される信号成分(例えば、PDCCH候補位置に対応する成分)をモニタする(ブラインドディコーディングとも呼ぶ)。
【0045】
また、DCI受信部203は、サーチスペース設定受信部207から入力されるサーチスペース設定情報に基づいて、URLLC-C-RNTIを用いてモニタするように設定されているサーチスペースに対応するCORESETに対して、URLLC-C-RNTIを用いてPDCCH候補位置をモニタする。
【0046】
DCI受信部203は、モニタによって検出されたDCIを復号し受信する。DCI受信部203は、復号されたDCIのうち、DL割当情報を信号分離部202に出力し、UL割当情報を信号割当部211に出力する。
【0047】
復調部204は、信号分離部202から入力される信号に対して、復調処理を施し、得られた復調信号を誤り訂正復号部205に出力する。
【0048】
誤り訂正復号部205は、復調部204から入力される復調信号を復号し、得られた上位レイヤシグナリングをRNTI設定受信部206及びサーチスペース設定受信部207に出力し、得られた受信データ信号を出力する。
【0049】
RNTI設定受信部206は、誤り訂正復号部205から入力される上位レイヤシグナリングに含まれるRNTI設定情報を受信し、端末200がサーチスペースのPDCCH候補位置のモニタに用いるRNTIの設定を取得する。RNTI設定受信部206は、PDCCH候補位置のモニタに用いるRNTIの設定を示すRNTI設定情報をDCI受信部203に出力する。
【0050】
サーチスペース設定受信部207は、誤り訂正復号部205から入力される上位レイヤシグナリングに含まれるサーチスペース設定情報を受信し、例えば、サーチスペースID、Aggregation level毎にサーチスペースをモニタする回数、サーチスペースの種別(CSS又はUSS)、サーチスペースが配置されるスロット間隔、及び、シンボル位置等の設定を取得する。サーチスペース設定受信部207は、取得した設定を示すサーチスペース設定情報を信号分離部202に出力する。
【0051】
また、サーチスペース設定受信部207は、上位レイヤのシグナリングに含まれるCORESET設定情報を受信し、CORESET設定情報をCORESET設定部208に出力する。
【0052】
また、サーチスペース設定受信部207は、端末200に対して、URLLC-C-RNTIを用いてモニタするCORESETに対応するサーチスペースが設定されている場合、URLLC-C-RNTIを用いてモニタするCORESETに対応するサーチスペース(例えば、サーチスペースID)を示す情報をDCI受信部203に出力する。
【0053】
CORESET設定部208は、サーチスペース設定受信部207から入力されるCORESET設定情報に基づいて、端末200に設定されたCORESETに関するパラメータ(例えば、PRBの位置、シンボル数、インタリーブの有無、プリコーディングの設定等)を示すCORESET設定情報を信号分離部202に出力する。
【0054】
誤り訂正符号化部209は、送信データ信号(ULデータ信号)を入力とし、送信データ信号を誤り訂正符号化し、符号化後の信号を変調部210に出力する。
【0055】
変調部210は、誤り訂正符号化部209から入力される信号を変調し、変調信号を信号割当部211に出力する。
【0056】
信号割当部211は、DCI受信部203から入力される情報(例えば、UL割当情報)に基づいて、ULデータ信号を割り当てるリソースを特定し、特定したリソースに、変調部210から入力される信号(例えば、ULデータ信号)を割り当てて、送信部212に出力する。
【0057】
送信部212は、信号割当部211から入力される信号に対してアップコンバート等の無線送信処理を施し、送信する。
【0058】
[基地局100及び端末200の動作]
次に、基地局100(
図3を参照)及び端末200(
図4を参照)の動作について詳細に説明する。
【0059】
図5は基地局100及び端末200の処理の一例を示すシーケンス図である。
【0060】
図5において、基地局100は、端末200に対して、CORESET、RNTI及びサーチスペースを設定する(ST101)。基地局100は、CORESET、RNTI及びサーチスペースの設定を示す上位レイヤシグナリングを端末200へ通知する(ST102)。端末200は、基地局100から通知される上位レイヤシグナリングから、CORESET、RNTI及びサーチスペースの設定を取得する(ST103)。
【0061】
基地局100は、端末200に対するスケジューリングを行い(ST104)、スケジューリング結果(例えば、DL割当情報又はUL割当情報)を含むDCIを生成する。なお、DCIは、例えば、端末200に対してスケジューリングしたデータの種別に応じたRNTIを用いてマスクされる。
【0062】
基地局100は、例えば、ST101で設定したサーチスペースに対応するCORESETを用いて、生成したDCIを端末200へ送信する(ST105)。
【0063】
端末200は、ST103で取得した設定に基づいて、サーチスペースに対応するCORESETをモニタし、端末200宛てのPDCCH(又はDCI)を検出する(ST106)。なお、端末200におけるサーチスペースのモニタ方法の詳細については後述する。
【0064】
基地局100及び端末200は、DCIによって通知された内容に基づいて、データ(DLデータ又はULデータ)の送受信を行う(ST107)。
【0065】
次に、端末200におけるサーチスペース(PDCCH候補位置)のモニタ方法について詳細に説明する。
【0066】
例えば、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
【0067】
具体的には、CSSは、用途(換言すると、データ種別)毎に複数のタイプがある。UEは、CSSにおいて用途毎に異なるRNTIを用いてマスクされているPDCCH(DCI)を検出する。
【0068】
一方、USSでは、UEは、UEに対してモニタするように設定されたRNTI(例えば、C-RNTI, MCS-C-RNTI及びCS-RNTI)を用いて、UEに設定されたUSS用の何れのCORESETでもモニタし、更に、Type 3 CSSでもモニタすることが規定されている。これは、データ信号のスケジューリングのフレキシビリティを向上させるためである。
【0069】
例えば、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に変更される。
【0070】
なお、同一サイズのPDCCHに対して異なる複数のRNTIを用いてモニタすることは、モニタ回数としては1回とカウントされる。よって、複数のRNTIを用いたUSS及びType 3 CSSのモニタに要するUEの処理量はそれほど増大しない。
【0071】
上述したように、UEでは、UE宛ての制御信号が送信されていないPDCCH候補位置であってもCRCが誤ってOKとなり、UE宛ての制御信号を受信したと誤って判断(誤検出)することがある。
【0072】
例えば、各制御信号(例えば、PDCCH)に付加されているCRCは24ビットである。ここで、24ビットのCRCにおいて、例えば、L=8のSCリストデコーダを制御信号の誤り訂正符号であるポーラ符号に適用することを考慮すると、誤検出確率(例えば、FAR:False Alarm Rate)は、おおよそ(1/2)^(21)=4.7E-7程度になると予想される(例えば、非特許文献3を参照)。したがって、UEが複数のPDCCH候補位置をモニタするほど、誤検出確率は高くなり、例えば、Release 16以降において要求される1E-6(換言すると、Release 15 URLLCにおいて要求される誤り率よりも低い誤り率)を超えてしまう可能性がある。
【0073】
そこで、本実施の形態では、端末200において超信頼性が求められるデータを割り当てるPDCCH(例えば、URLLC用のPDCCH)候補位置をモニタする回数は、URLLC以外のユースケース用のPDCCH候補位置をモニタする回数よりも少なく設定される。超信頼性が求められるPDCCHのモニタする回数が制限されることで、超信頼性が求められるPDCCHを誤検出する確率を低減することができる。
【0074】
以下、本実施の形態における基地局100及び端末200の動作例1-1、1-2及び1-3についてそれぞれ説明する。
【0075】
[動作例1-1]
動作例1-1では、超信頼性が求められるデータを割り当てるPDCCHに対して、新たなRNTIを割り当てる。換言すると、超信頼性が求められるデータを割り当てるPDCCHのマスクに用いるRNTIと、その他のPDCCHのマスクに用いるRNTIとを異ならせる。
【0076】
ここでは、新たなRNTIの一例としてRNTI名を「URLLC-C-RNTI」とする。
【0077】
また、動作例1-1では、端末200がURLLC-C-RNTIを用いてモニタするPDCCHを配置するサーチスペースを制限する。例えば、端末200がURLLC-C-RNTIを用いてPDCCHをモニタする領域は、端末200に設定されたサーチスペースに対応するCORESETの一部の領域に制限される。
【0078】
基地局100は、端末200にサーチスペースを設定する際、端末200がURLLC-C-RNTIを用いてモニタするサーチスペース(又はCORESET)を指定する。
【0079】
例えば、基地局100は、サーチスペース設定の際にサーチスペースIDを設定する。また、基地局100は、設定したサーチスペースIDに対応するサーチスペースがどのCORESET(CORESET ID)に配置されるか、時間的にモニタする周期、モニタするAggregation level、及び、サーチスペース種別(CSS又はUSS)等を設定する。
【0080】
また、基地局100は、上記サーチスペース設定に加え、サーチスペースにおいて端末200が「URLLC-C-RNTI」を用いてモニタするか否かを決定する。
【0081】
なお、動作例1-1において、端末200は、URLLC-C-RNTIとMCS-C-RNTIとを併用できる。端末200は、MCS-C-RNTIを用いてモニタするように設定された場合、例えば、CSS PDCCH type 3及び全てのUSSにおいてサーチスペースをモニタする。
【0082】
また、動作例1-1では、端末200に対してCS-RNTIは設定されていない。ただし、端末200に対してCS-RNTIが設定されていてもよい。
【0083】
図6は、1スロット内のサーチスペースの設定例を示す。
【0084】
図6において、Type 3 PDCCH CSSであるサーチスペースID#1が、CORESET #1に設定されている。また、
図6において、USSであるサーチスペースID#2がCORESET#2に設定され、サーチスペースID#3がCORSET#3に設定されている。
【0085】
サーチスペースID#1(CSS#1)及びサーチスペースID#2(USS#2)では、端末200は、1スロットあたり1つのタイミングでCORESETをモニタする。また、サーチスペースID#3(USS#3)では、端末200は、1スロットあたり3つのタイミングでCORESETをモニタする。
【0086】
また、
図6では、端末200は、USSであるサーチスペースID#3において新たなRNTI「URLLC-C-RNTI」を用いてPDCCHをモニタするように設定されている。
【0087】
この場合、端末200は、サーチスペース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をモニタする。
【0088】
また、端末200は、サーチスペースID#2(USS)であるCORESET #2では、USSにおいてモニタするように予め定められているRNTI(C-RNTI及びMCS-C-RNTI(rel.15))を用いてPDCCHをモニタする。
【0089】
また、端末200は、サーチスペースID#3(URLLC-C-RNTIでモニタするように設定されたUSS)であるCORESET #3では、USSにおいてモニタするように予め定められているRNTI(C-RNTI及びMCS-C-RNTI(rel.15))に加え、URLLC-C-RNTIを用いてPDCCHをモニタする。
【0090】
図7は、一例として、C-RNTI、MCS-C-RNTI(rel.15)、及び、URLLC-C-RNTIの各々を用いた1スロットあたりのPDCCHのモニタ回数を示す。
【0091】
以下では、一例として、サーチスペースID#1(CSS#1)におけるPDCCHのモニタ回数が「5回」に設定され、サーチスペースID#2(USS#2)におけるPDCCHのモニタ回数が「20回」に設定され、サーチスペースID#3(USS#3)におけるPDCCHのモニタ回数が、3つのタイミングの合計で「12回」に設定される。
【0092】
図6に示すように、C-RNTI及びMCS-C-RNTI(rel.15)は、CSS#1(CORESET#1)、USS#2(CORESET#2)及びUSS#3(CORESET#3)の全てに定められている。よって、
図7に示すように、C-RNTI及びMCS-C-RNTI(rel.15)を用いた1スロットあたりのPDCCHモニタ回数は、各サーチスペース(CSS#1、USS#2及びUSS#3)に設定されたモニタ回数(5回、20回及び12回)の合計37回となる。
【0093】
一方、
図6に示すように、URLLC-C-RNTIは、USS#3(CORESET#3)に定められ、他のサーチスペースには定められていない。よって、
図7に示すように、URLLC-C-RNTIを用いた1スロットあたりのPDCCHモニタ回数は、USS#3に設定されたモニタ回数の12回となる。
【0094】
このように、動作例1-1では、端末200がURLLC-C-RNTIを用いてモニタするサーチスペースは、一部のサーチスペース(
図6ではUSS#3)に制限される。換言すると、URLLC-C-RNTIに対応するPDCCHについてモニタするチャネル領域は、他のRNTIに対応するPDCCHについてモニタするチャネル領域よりも小さい。URLLC-C-RNTIを用いてモニタするサーチスペースID及びCORESET IDを制限することで、
図7に示すように、URLLC-C-RNTIを用いてサーチスペースをモニタする回数は、他のRNTIを用いてサーチスペースをモニタする回数よりも少なくなる。換言すると、URLLC-C-RNTIに対応するPDCCHについて、端末200のモニタ回数を削減し、URLLC-C-RNTIに対応する超信頼性が求められるPDCCHの誤検出率を低減することができる。
【0095】
また、C-RNTI及びMCS-C-RNTI(rel.15)については、端末200は、全てのサーチスペース(例えば、全てのUSS及びType 3 CSS)においてPDCCHをモニタするので、リソース割り当てのフレキシビリティを維持できる。
【0096】
例えば、基地局100は、Release 15 URLLCよりも低い誤り率が求められるURLLCに対して、URLLC-C-RNTIを割り当てることにより、所望の誤り率特性に応じて、MCS-C-RNTIとURLLC-C-RNTIとを使い分けてもよく、併用してもよい。
【0097】
なお、動作例1-1では、
図7に示すように、全てのUSSにおいてC-RNTI及びMCS-C-RNTIを用いてPDCCHをモニタする場合について説明した。しかし、C-RNTI、MCS-C-RNTI又は、CS-RNTIについても、サーチスペース毎にPDCCHをモニタするか否かを個別に設定してもよい。これにより、URLLC-C-RNTI以外の他のRNTIについても端末200がモニタするPDCCHが制限されるので、当該RNTIに対応するPDCCHの誤検出率を低減することができる。
【0098】
[動作例1-2]
動作例1-2では、端末200が、URLLC-C-RNTIについても、他のRNTIと同様の領域(例えば、Type 3 CSS及びUSS)においてPDCCHをモニタする点が動作例1-1と異なる。
【0099】
ただし、URLLC-C-RNTIを用いてサーチスペースをモニタする回数(換言すると、PDCCHのモニタ回数)は、他のRNTI(例えば、C-RNTI等)を用いてサーチスペースをモニタする回数よりも少ない値に設定される。
【0100】
例えば、基地局100は、端末200に対して、URLLC-C-RNTIを用いてサーチスペースをモニタする回数を通知する。
【0101】
URLLC-C-RNTIを用いたPDCCHのモニタ回数は、例えば、全体(換言すると、他のRNTIを用いたPDCCHのモニタ回数)からの比率(又は差分)で表されてもよく、又は、数値で表されてもよい。
【0102】
または、URLLC-C-RNTIを用いたPDCCHのモニタ回数の上限値が定められてもよい。端末200に通知されるURLLC-C-RNTIを用いたPDCCHのモニタ回数が、上限値を超える場合、端末200は、URLLC-C-RNTIを用いたPDCCHのモニタ回数を、上限値に制限する。
【0103】
図8は、動作例1-2の一例として、C-RNTI、MCS-C-RNTI(rel.15)、及び、URLLC-C-RNTIの各々を用いた1スロットあたりのPDCCHのモニタ回数を示す。
【0104】
図8では、URLLC-C-RNTIを用いたPDCCHのモニタ回数は、C-RNTI(又はMCS-C-RNTI)を用いたPDCCHのモニタ数の半分である。
【0105】
例えば、端末200は、C-RNTIに対するPDCCHのモニタ回数を取得した後、URLLC-C-RNTIに対するPDCCHのモニタ回数を、取得したモニタ回数の半数に設定する。なお、
図8では、C-RNTIに対するPDCCHのモニタ数が割り切れない場合に、値を切り上げる例を示すが、これに限らず、値を切り捨ててもよい。
【0106】
このように、動作例1-2では、URLLC-C-RNTIを用いたPDCCHについてモニタするチャネル領域(例えば、CORESET)は、URLLC-C-RNTI以外の他のRNTIを用いたPDCCHについてモニタするチャネル領域と同一である。ただし、動作例1-2では、端末200に設定されるCORESETの各々において、URLLC-C-RNTIを用いてPDCCHをモニタする回数は、他のRNTIを用いてPDCCHをモニタする回数よりも少なく設定される。
【0107】
これにより、端末200は、URLLC-C-RNTIを用いてPDCCHをモニタするサーチスペースに対応するCORESETを制限することなく、端末200のモニタ回数を削減し、URLLC-C-RTNIに対応する超信頼性が求められるPDCCHの誤検出率を低減することができる。
【0108】
なお、端末200に設定された各サーチスペースにおいて、端末200がURLLC-C-RNTIを用いてモニタするPDCCH候補位置は、例えば、サーチスペース内のPDCCH候補番号の低い順、高い順、奇数番号、又は、偶数番号などで定めてもよい。
【0109】
また、端末200がURLLC-C-RNTIを用いてモニタするPDCCH候補位置のCCE Aggregation levelを制限してもよい。例えば、端末200は、PDCCHをモニタするように定められたAggregation levelのうち、大きいAggregation levelを優先的にモニタしてもよい。大きいAggregation levelを優先的にモニタすることで、基地局100は、端末200に対して、URLLC用のDCIを大きいAggregation levelで送信できる。よって、大きいAggregation levelを優先的にモニタすることにより、小さいAggregation levelでDCIを送信する場合と比較して、誤り率特性を改善できる。
【0110】
また、基地局100は、端末200に対して、どのAggregation levelを想定してURLLC用のPDCCH候補位置をモニタするかを別途通知してもよい。通知には、例えば、DCIが使用されてもよい。通知に使われるDCIには、例えば、グループ共通(group common)DCIが考えらえる。グループ共通DCIには、複数の端末宛てのAggregation levelの指示を含むことができる。端末200は、受信したグループ共通DCIから、端末200宛ての指示が含まれるビットを取り出し、端末200のURLLC用PDCCH候補位置のAggregation levelを設定する。
【0111】
[動作例1-3]
動作例1-3では、動作例1-1及び1-2と異なり、1E-6の誤り率をターゲットとする場合でも、URLLCに対応する「MCS-C-RNTI」を使用し、MCS-C-RNTIを用いてPDCCHをモニタする回数を制限する。
【0112】
例えば、基地局100は、端末200に対して、MCS-C-RNTIを、Type 3 CSS及び全てのUSSにおけるPDCCHのモニタに用いるか、又は、動作例1-1における「URLLC-C-RNTI」のように、特定のUSSに制限されたPDCCHのモニタに用いるか、又は、動作例1-2における「URLLC-C-RNTI」のように、各サーチスペースにおいて回数を制限されたPDCCHのモニタに用いるかを通知する。
【0113】
また、端末200に対してMCS-C-RNTIを用いてPDCCHをモニタするように設定する際に、基地局100は、Type 3 CSS及び全てのUSSにおいてPDCCHをモニタするか、PDCCHをモニタするUSSを制限するかを通知してもよい。また、動作例1-2のように、MCS-C-RNTIを用いてPDCCHをモニタするサーチスペースを制限せずに、サーチスペース内でMCS-C-RNTIを用いてPDCCHをモニタする回数を制限してもよい。
【0114】
以上、動作例1-1、1-2及び1-3についてそれぞれ説明した。
【0115】
なお、例えば、動作例1-1及び動作例1-2を組み合わせてもよい。例えば、URLLC-C-RNTIを用いたサーチスペースのモニタを、動作例1-1のように、端末200に設定されるサーチスペースの一部に制限し、かつ、動作例1-2のように、一部のサーチスペースにおけるURLLC-C-RNTIを用いたPDCCHのモニタ回数は、他のRNTIを用いたPDCCHのモニタ回数より少なく設定されてもよい。
【0116】
本実施の形態では、端末200において、サーチスペース内のPDCCH候補位置をモニタして、端末200宛てのDCIを検出する際、より低い信頼性が求められるPDCCHをモニタする回数は、他のPDCCHをモニタする回数よりも少なく設定される。
【0117】
これにより、より低い信頼性が求められるPDCCHのモニタ回数が低減する分、誤検出確率も低減される。よって、CRCの系列長を増やすことなく、端末200における誤検出の確率を低減することができる。よって、本実施の形態によれば、端末200は、PDCCH(DCI)を適切に検出できるので、例えば、制御信号及びデータ信号の双方の誤り率の低減を実現できる。
【0118】
なお、より低い信頼性が求められるPDCCH(例えば、URLLC用PDCCH)のモニタ回数を、他のPDCCHのモニタ回数よりも少なくすることで、URLLC用PDCCHを割当可能なリソース領域が小さくなる。しかし、URLLCは、他のユースケースと比較して、高信頼かつ低遅延が求められるため、優先度が高くなることが考えられる。よって、URLLC用PDCCHは、他のユースケースのPDCCHと比較して、リソースに優先的に割り当てられる可能性が高い。このため、URLLC用PDCCHを割当可能なリソース領域が小さくなっても、URLLC用PDCCHの割当に与える影響は小さい。
【0119】
また、CS-RNTIでは、CRC以外にも、UEが既知のビット列が定められている。UEは、既知のビット列が正しく受信できているか否かに応じて、DCIを正しく受信できたか否かを検出できる。URLLC用のDCIに関しても、既知ビット列を挿入することが考えらえる。既知ビット列の長さが長いほど、誤検出の確率は低減する。したがって、既知ビット列が長いほど、URLLC用RNTIを用いたPDCCHのモニタ数を増加させ、既知ビット列が短いほど、URLLC用RNTIを用いたPDCCHのモニタ数を減少させてもよい。このようにすると、誤検出率に合わせて、URLLC用RNTIを用いたPDCCHのモニタ回数を設定することができる。
【0120】
また、URLLCをモニタするサーチスペースは、1スロット内で複数回モニタするサーチスペースに限定してもよい。これは、URLLCでは、遅延時間の低減も求められているので、1スロット内で複数回モニタすることで、遅延量を低減できるからである。
【0121】
(実施の形態2)
実施の形態2に係る基地局及び端末は、実施の形態1に係る基地局100及び端末200と基本構成が共通するので、
図3及び
図4を援用して説明する。
【0122】
NRでは、スロットフォーマットインディケータ(SFI:Slot Format Indicator)が導入される。SFIは、例えば、上位レイヤのシグナリングであるRRC(Radio Resource Control)又は物理レイヤのシグナリングであるDCI format 2_0を用いて通知される。また、SFIは、例えば、
図9に示すように、スロット内のシンボルが、DL用に設定されたシンボル(「D」。DLシンボルと呼ぶ)、UL用に設定されたシンボル(「U」。ULシンボルと呼ぶ)、及び、フレキシブルシンボル(「F」)の何れであるかを通知する。
【0123】
フレキシブルシンボルは、DLシンボル及びULシンボルの双方に使用可能である。また、フレキシブルシンボルは、リソース割り当てをしないシンボル(例えば、ブランクシンボル又はUnknownシンボルと呼ぶこともある)として使用可能である。
【0124】
NRでは、RRCのSFIにおいてフレキシブルシンボルに設定されたシンボルに対して、DCI format 2_0のSFIを用いてULシンボル(「U」)又はDLシンボル(「D」)を指定できる。
【0125】
なお、NRでは、RRCのSFIにおいてフレキシブルシンボルに設定され、かつ、DCI format 2_0のSFIにおいてフレキシブルシンボルに設定されたシンボルでは、UEがPDCCH候補位置をモニタしないことが定められている。
【0126】
一方、RRCのSFIにおいてフレキシブルシンボルに設定され、DCI format 2_0のSFIによる設定がない場合、UEは、当該シンボルでもPDCCH候補位置をモニタすることができる。ただし、当該シンボルに対して、他のDCIによってPUSCH、PUCCH、RACH又はSRSの場所が指定され、当該シンボルがULシンボルとして使用されることが通知されている場合、UEは、当該シンボルをULシンボルとして使用し、PDCCH候補位置をモニタしない。
【0127】
ここで、例えば、RRCのSFIによってフレキシブルシンボルが設定され、DCI format 2_0のSFIによる設定が無い場合、UEは、当該フレキシブルシンボルに対してUL送信を行うことを通知する他のDCIを検出すると、当該フレキシブルシンボルにおいてPDCCH候補位置をモニタしない。
【0128】
しかしながら、UEが検出した、UL送信を通知する他のDCIが誤検出であり、実際には、基地局がフレキシブルシンボルにおいてPDCCH候補位置にDCIを送信していた場合、UEは、当該シンボルにおいてPDCCH候補位置をモニタしないので、DCIを検出することができない。UEがDCIの検出を誤るとデータを送受信できない。特に1E-6の誤り率をターゲットとするようなシナリオ(例えば、超信頼性が求められるユースケース)では、DCIの誤検出により、所望の誤り率を達成できなくなる可能性がある。また、誤検出により、再送が起こり、遅延量が増大するという問題がある。
【0129】
そこで、本実施の形態では、端末200は、低い誤り率が求められるURLLC用のRNTIを用いてマスクされたPDCCH候補位置を、DLに設定されたシンボルにおいてモニタする。換言すると、端末200は、URLLC用のRNTIを用いてマスクされたPDCCH候補位置を、DL以外の用途に設定されたシンボル(例えば、ULシンボル又はフレキシブルシンボル)においてモニタしない。
【0130】
このようにすると、端末200は、フレキシブルシンボルにおいてPDCCH候補位置をモニタしない。よって、端末200では、他のDCIを誤検出して、フレキシブルシンボルをULシンボルと誤って認識した場合に、PDCCHを受信できなくなることを防ぐことができる。
【0131】
以下、本実施の形態における基地局100及び端末200の動作例2-1及び2-2についてそれぞれ説明する。
【0132】
[動作例2-1]
動作例2-1では、DCIの誤検出によって、端末200がフレキシブルシンボルをULシンボルと誤認識することを防ぐために、端末200が低い誤り率が求められるURLLC用のRNTIを用いてPDCCHをモニタする場合、RRCのSFIに加え、DCI format 2_0のSFIを併用する。
【0133】
例えば、実施の形態1の動作例1-1又は動作例1-2のように新たなRNTI「URLLC-C-RNTI」を用いてPDCCHをモニタするように設定されたスロットでは、基地局100は、端末200に対して、DCI format 2_0のSFIを通知する。
【0134】
端末200は、RRCのSFIによってフレキシブルシンボルと通知されたシンボルでは、DCI format 2_0のSFIによってDLシンボルと通知される場合、URLLC-C-RNTIを用いてPDCCH候補位置をモニタする。換言すると、端末200は、RRCのSFIによってフレキシブルシンボルと通知されたシンボルにおいて、DCI format 2_0のSFIによってDLシンボル「D」と通知されない場合、URLLC-C-RNTIを用いてPDCCH候補位置をモニタしない。
【0135】
これにより、端末200は、DCI format 2_0のSFIによってDLシンボルと通知されているシンボルに対して、他のDCIによってULデータ、上りリンク制御信号(UCI:Uplink Control INformation)又は参照信号の送信が設定された場合でも、当該他のDCIを誤検出したと認識できる。よって、端末200は、UL送信を止めて、基地局100が実際に送信しているDCIについて、PDCCH候補位置をモニタすることができる。
【0136】
このようにすると、DCIの誤検出による、PDCCH候補位置の検出ミスの確率を減らし、URLLCの誤検出に与える影響を軽減することができる。したがって、動作例2-1では、C-RNTIによりマスクされるDCIによって割り当てられるデータのように、リソース割当のフレキシビリティが求められるデータに関しても、PDCCH候補数を制限せずに、誤検出確率を低減できる。
【0137】
[動作例2-2]
動作例2-2では、端末200は、低い誤り率が求められるURLLC用のRNTIをモニタする場合に、RRCのSFIが設定され、DCI format 2_0のSFIが設定されない場合、RRCのSFIにおいてフレキシブルシンボルと通知されたシンボルでは、URLLC用のRNTIをモニタしない。
【0138】
例えば、実施の形態1の動作例1-1又は動作例1-2のように、端末200は、新たなRNTI「URLLC-C-RNTI」を用いてPDCCHをモニタするように指示されると、RRCのSFIにおいてフレキシブルシンボルと通知されたシンボルでは、URLLC-C-RNTIを用いてPDCCH候補位置をモニタせずに、他のRNTI(例えば、C-RNTI、CS-RNTI又はMCS-C-RNTI(rel.15)等)を用いてPDCCH候補位置をモニタする。
【0139】
このようにすると、URLLC-C-RNTIによってマスクされるPDCCH(DCI)は、フレキシブルシンボルでは送信されない。よって、端末200がフレキシブルシンボルをULシンボルと誤認識していても、URLLCの割り当てに関しては影響がない。
【0140】
また、URLLC-C-RNTIによってマスクされるDCIがフレキシブルシンボルでは送信されず、他のRNTIでマスクされるDCIは、フレキシブルシンボルでも送信されるので、所望誤り率が1E-6のように低くないデータに対応するDCIに関しては、リソース割り当てのフレキシビリティを保つことができる。
【0141】
以上、動作例2-1及び2-2についてそれぞれ説明した。
【0142】
このように、本実施の形態では、端末200は、スロット内の複数のシンボルのうち、SFIによってDLシンボルに設定されたシンボルにおいて、より低い信頼性が求められるPDCCHをモニタする。
【0143】
例えば、端末200は、RRCのSFIによってフレキシブルシンボルに設定されたシンボルのうち、DCI format 2_0のSFIによってDLシンボルに設定されたシンボルにおいて、より低い信頼性が求められるPDCCHをモニタする。換言すると、基地局100は、RRCのSFIによってフレキシブルシンボルに設定したシンボルのうち、DCI format 2_0のSFIによってDLシンボルに設定したシンボルにおいて、より低い信頼性が求められるPDCCH(又はDCI)を割り当てる。
【0144】
このように、より低い信頼性が求められるPDCCHが割り当てられるシンボル(換言すると、モニタ対象のシンボル)が制限されることにより、端末200は、より低い信頼性が求められるPDCCHを確実に検出できるので、誤検出確率が低減される。よって、CRCの系列長を増やすことなく、端末200における誤検出の確率を低減することができる。
【0145】
よって、本実施の形態によれば、端末200は、PDCCH(DCI)を適切に検出できるので、例えば、制御信号及びデータ信号の双方の誤り率の低減を実現できる。
【0146】
なお、動作例2-1及び動作例2-2は、実施の形態1の動作例1-1及び動作例1-2のように新たなRNTI「URLLC-C-RNTI」が使用される前提で説明しているが、実施の形態1の動作例1-3のように、「MCS-C-RNTI」を使用する場合にも適用できる。この場合、動作例2-1では、端末200がMCS-C-RNTIをモニタするスロットでは、DCI format 2_0のSFIが送信される。また、動作例2-2では、RRCのSFIで指示されたフレキシブルシンボルでは、端末200は、MCS-C-RNTIを用いてPDCCH候補位置をモニタしない。
【0147】
以上、本開示の各実施の形態について説明した。
【0148】
(他の実施の形態)
なお、上記実施の形態では、上位レイヤのシグナリングには、RRCシグナリングを想定しているが、MACのシグナリング、及び、物理レイヤのシグナリングであるDCIでの通知に置き換えてもよい。MACのシグナリングおよび物理レイヤのシグナリングの場合、RRCのシグナリングと比較して、変更の頻度を上げることができる。
【0149】
また、URLLC-C-RNTIという名称は一例であり、他の名前のRNTIに対して、上記実施例を適用することもできる。
【0150】
また、上記実施の形態では、より低い信頼性が求められるデータ種別(又は用途)の一例にURLLCを用いたが、より低い信頼性が求められるデータ種別はURLLCに限らない。URLLCの用途以外のRNTIについても、C-RNTI等の他のRNTIと比較して、PDCCH候補位置のモニタ回数を変更したい場合(例えば、少なくしたい場合)、上記実施の形態を適用できる。
【0151】
また、本開示はソフトウェア、ハードウェア、又は、ハードウェアと連携したソフトウェアで実現することが可能である。上記実施の形態の説明に用いた各機能ブロックは、部分的に又は全体的に、集積回路であるLSIとして実現され、上記実施の形態で説明した各プロセスは、部分的に又は全体的に、一つのLSI又はLSIの組み合わせによって制御されてもよい。LSIは個々のチップから構成されてもよいし、機能ブロックの一部または全てを含むように一つのチップから構成されてもよい。LSIはデータの入力と出力を備えてもよい。LSIは、集積度の違いにより、IC、システムLSI、スーパーLSI、ウルトラLSIと呼称されることもある。集積回路化の手法はLSIに限るものではなく、専用回路、汎用プロセッサ又は専用プロセッサで実現してもよい。また、LSI製造後に、プログラムすることが可能なFPGA(Field Programmable Gate Array)や、LSI内部の回路セルの接続や設定を再構成可能なリコンフィギュラブル・プロセッサを利用してもよい。本開示は、デジタル処理又はアナログ処理として実現されてもよい。さらには、半導体技術の進歩または派生する別技術によりLSIに置き換わる集積回路化の技術が登場すれば、当然、その技術を用いて機能ブロックの集積化を行ってもよい。バイオ技術の適用等が可能性としてありえる。
【0152】
本開示は、通信機能を持つあらゆる種類の装置、デバイス、システム(通信装置と総称)において実施可能である。通信装置の、非限定的な例としては、電話機(携帯電話、スマートフォン等)、タブレット、パーソナル・コンピューター(PC)(ラップトップ、デスクトップ、ノートブック等)、カメラ(デジタル・スチル/ビデオ・カメラ等)、デジタル・プレーヤー(デジタル・オーディオ/ビデオ・プレーヤー等)、着用可能なデバイス(ウェアラブル・カメラ、スマートウオッチ、トラッキングデバイス等)、ゲーム・コンソール、デジタル・ブック・リーダー、テレヘルス・テレメディシン(遠隔ヘルスケア・メディシン処方)デバイス、通信機能付きの乗り物又は移動輸送機関(自動車、飛行機、船等)、及び上述の各種装置の組み合わせがあげられる。
【0153】
通信装置は、持ち運び可能又は移動可能なものに限定されず、持ち運びできない又は固定されている、あらゆる種類の装置、デバイス、システム、例えば、スマート・ホーム・デバイス(家電機器、照明機器、スマートメーター又は計測機器、コントロール・パネル等)、自動販売機、その他IoT(Internet of Things)ネットワーク上に存在し得るあらゆる「モノ(Things)」をも含む。
【0154】
通信には、セルラーシステム、無線LANシステム、通信衛星システム等によるデータ通信に加え、これらの組み合わせによるデータ通信も含まれる。
【0155】
また、通信装置には、本開示に記載される通信機能を実行する通信デバイスに接続又は連結される、コントローラやセンサー等のデバイスも含まれる。例えば、通信装置の通信機能を実行する通信デバイスが使用する制御信号やデータ信号を生成するような、コントローラやセンサーが含まれる。
【0156】
また、通信装置には、上記の非限定的な各種装置と通信を行う、あるいはこれら各種装置を制御する、インフラストラクチャ設備、例えば、基地局、アクセスポイント、その他あらゆる装置、デバイス、システムが含まれる。
【0157】
本開示の一実施例における端末は、下りリンク信号を受信する受信機と、前記下りリンク信号において、制御チャネルの候補位置をモニタして、端末宛ての制御情報を検出する回路と、を具備し、第1の制御チャネルの前記候補位置をモニタする回数は、第2の制御チャネルの前記候補位置をモニタする回数よりも少ない。
【0158】
本開示の一実施例における端末において、前記第1の制御チャネルについてモニタするチャネル領域は、前記第2の制御チャネルについてモニタするチャネル領域よりも小さい。
【0159】
本開示の一実施例における端末において、前記第1の制御チャネルについてモニタするチャネル領域は、前記第2の制御チャネルについてモニタするチャネル領域と同一であり、前記チャネル領域の各々において、前記第1の制御チャネルの前記候補位置をモニタする回数は、前記第2の制御チャネルの前記候補位置をモニタする回数よりも少ない。
【0160】
本開示の一実施例における端末において、前記第1の制御チャネルのマスクに用いる識別子と、前記第2の制御チャネルのマスクに用いる識別子とは異なる。
【0161】
本開示の一実施例における端末は、下りリンク用に設定される第1のシンボル、上りリンク用に設定される第2のシンボル、及び、下りリンク用及び上りリンク用の双方に使用可能な第3のシンボルの何れかを示す指示情報を受信する受信機と、複数のシンボルのうち、前記指示情報によって前記第1のシンボルに設定されたシンボルにおいて、制御チャネルの候補位置をモニタする回路と、を具備する。
【0162】
本開示の一実施例における端末において、前記指示情報は、物理レイヤで通知される。
【0163】
本開示の一実施例における端末において、前記受信機は、上位レイヤで通知される第1の指示情報、及び、物理レイヤで通知される第2の指示情報を受信し、前記回路は、前記第1の指示情報によって前記第3のシンボルに設定され、前記第2の指示情報によって前記第1のシンボルに設定されたシンボルにおいて、前記制御チャネルの候補位置をモニタし、前記第1の指示情報によって前記第3のシンボルに設定され、前記第2の指示情報が無い場合、前記制御チャネルの候補位置をモニタしない。
【0164】
本開示の一実施例における受信方法は、下りリンク信号を受信し、前記下りリンク信号において、制御チャネルの候補位置をモニタして、端末宛ての制御情報を検出し、第1の制御チャネルの前記候補位置をモニタする回数は、第2の制御チャネルの前記候補位置をモニタする回数よりも少ない。
【0165】
本開示の一実施例における受信方法は、下りリンクに設定される第1のシンボル、上りリンクに設定される第2のシンボル、及び、下りリンク及び上りリンクの双方に使用可能な第3のシンボルの何れかを示す指示情報を受信し、複数のシンボルのうち、前記指示情報によって前記第1のシンボルに設定されたシンボルにおいて、制御チャネルの候補位置をモニタする。
【0166】
2018年9月27日出願の特願2018-181867の日本出願に含まれる明細書、図面および要約書の開示内容は、すべて本願に援用される。
【産業上の利用可能性】
【0167】
本開示の一実施例は、移動通信システムに有用である。
【符号の説明】
【0168】
100 基地局
101,208 CORESET設定部
102 RNTI設定部
103 サーチスペース設定部
104 DCI生成部
105,209 誤り訂正符号化部
106,210 変調部
107,211 信号割当部
108,212 送信部
109,201 受信部
110,202 信号分離部
111,204 復調部
112,205 誤り訂正復号部
200 端末
203 DCI受信部
206 RNTI設定受信部
207 サーチスペース設定受信部