図面 (/)

技術 基地局装置、端末装置および通信方法

出願人 シャープ株式会社鴻穎創新有限公司
発明者 高橋宏樹山田昇平星野正幸坪井秀和劉麗清
出願日 2019年2月14日 (1年10ヶ月経過) 出願番号 2019-024511
公開日 2020年8月31日 (4ヶ月経過) 公開番号 2020-136763
状態 未査定
技術分野 移動無線通信システム
主要キーワード 洗濯機器 領域関係 ゼロパワー キッチン機器 ブロッケージ 最小インデックス 生活機器 サイドリンク
関連する未来課題
重要な関連分野

この項目の情報は公開日時点(2020年8月31日)のものです。
また、この項目は機械的に抽出しているため、正しく解析できていない場合があります

図面 (20)

課題

端末装置基地局装置が効率的に通信を行うこと。

解決手段

端末装置が、第1の設定情報を含むRRCメッセージを受信し、PDCCHでDCIを受信する受信部と、前記DCIの第1のフィールドが示すビット列に基づいて、PUSCHを送信する時間パラメータを決定する決定部と、前記時間パラメータに基づいて前記PUSCHを送信する送信部と、を備え、前記ビット列と前記時間パラメータの関係は、第1の条件を満たし、前記第1の設定情報に第1のパラメータ群が含まれる場合には、前記第1のパラメータ群によって定義され、第2の条件を満たし、前記第1の設定情報に第2のパラメータ群が含まれる場合には、前記第2のパラメータ群によって定義される。

概要

背景

現在、第5世代のセルラーシステムに向けた無線アクセス方式および無線ネットワーク技術として、第三世代パートナーシッププロジェクト(3GPP: The Third Generation Partnership Project)において、LTE(Long Term Evolution)-Advanced Pro及びNR(New Radio technology)の技術検討及び規格策定が行われている(非特許文献1)。

第5世代のセルラーシステムでは、高速・大容量伝送を実現するeMBB(enhanced Mobile BroadBand)、低遅延・高信頼通信を実現するURLLC(Ultra-Reliable and Low Latency Communication)、IoT(Internet of Things)などマシン型デバイスが多数接続するmMTC(massive Machine Type Communication)の3つがサービスの想定シナリオとして要求されている。

概要

端末装置基地局装置が効率的に通信を行うこと。端末装置が、第1の設定情報を含むRRCメッセージを受信し、PDCCHでDCIを受信する受信部と、前記DCIの第1のフィールドが示すビット列に基づいて、PUSCHを送信する時間パラメータを決定する決定部と、前記時間パラメータに基づいて前記PUSCHを送信する送信部と、を備え、前記ビット列と前記時間パラメータの関係は、第1の条件を満たし、前記第1の設定情報に第1のパラメータ群が含まれる場合には、前記第1のパラメータ群によって定義され、第2の条件を満たし、前記第1の設定情報に第2のパラメータ群が含まれる場合には、前記第2のパラメータ群によって定義される。

目的

本発明の目的は、上記のような無線通信システムにおいて、効率的な通信を可能とする端末装置、基地局装置および通信方法を提供する

効果

実績

技術文献被引用数
0件
牽制数
0件

この技術が所属する分野

ライセンス契約や譲渡などの可能性がある特許掲載中! 開放特許随時追加・更新中 詳しくはこちら

請求項1

端末装置であって、第1の設定情報を含むRRCメッセージを受信し、物理下りリンク制御チャネル下りリンク制御情報を受信する受信部と、前記下りリンク制御情報の第1のフィールドが示すビット列に基づいて、物理上りリンク共用チャネルを送信する時間パラメータを決定する決定部と、前記時間パラメータに基づいて前記物理上りリンク共用チャネルを送信する送信部と、を備え、前記ビット列と前記時間パラメータの関係は、第1の条件を満たし、前記第1の設定情報に第1のパラメータ群が含まれる場合には、前記第1のパラメータ群によって定義され、第2の条件を満たし、前記第1の設定情報に第2のパラメータ群が含まれる場合には、前記第2のパラメータ群によって定義される端末装置。

請求項2

前記第1の条件は、前記下りリンク制御情報に付加されたCRCスクランブルするRNTIの値が第1の範囲であることであり、前記第2の条件は、前記RNTIの値が前記第1の範囲とは異なる第2の範囲であることである請求項1記載の端末装置。

請求項3

前記第1の条件は、前記下りリンク制御情報の第2のフィールドが第1の値を示すことであり、前記第2の条件は、前記第2のフィールドが第1の値とは異なる第2の値を示すことである請求項1記載の端末装置。

請求項4

前記第1の条件は、前記下りリンク制御情報に用いられるフォーマットが第1のフォーマットであることであり、前記第2の条件は、前記下りリンク制御情報に用いられるフォーマットが前記第1のフォーマットと異なる第2のフォーマットであることである請求項1記載の端末装置。

請求項5

前記時間パラメータは前記物理下りリンク制御チャネルと前記物理上りリンク共用チャネルとの間のスロットオフセットである請求項1記載の端末装置。

請求項6

基地局装置であって、第1の設定情報を含むRRCメッセージを送信し、物理下りリンク制御チャネルで下りリンク制御情報を送信する送信部と、物理上りリンク共用チャネルの受信に使用する時間パラメータに基づいて前記下りリンク制御情報の第1のフィールドが示すビット列を決定する決定部と、前記時間パラメータに基づいて前記物理上りリンク共用チャネルを受信する受信部と、を備え、前記ビット列と前記時間パラメータの関係は、第1の条件を満たし、前記第1の設定情報に第1のパラメータ群が含まれる場合には、前記第1のパラメータ群によって定義され、第2の条件を満たし、前記第1の設定情報に第2のパラメータ群が含まれる場合には、前記第2のパラメータ群によって定義される基地局装置。

請求項7

前記第1の条件は、前記下りリンク制御情報に付加されたCRCをスクランブルするRNTIの値が第1の範囲であることであり、前記第2の条件は、前記RNTIの値が前記第1の範囲とは異なる第2の範囲であることである請求項6記載の基地局装置。

請求項8

前記第1の条件は、前記下りリンク制御情報の第2のフィールドが第1の値を示すことであり、前記第2の条件は、前記第2のフィールドが第1の値とは異なる第2の値を示すことである請求項6記載の基地局装置。

請求項9

前記第1の条件は、前記下りリンク制御情報に用いられるフォーマットが第1のフォーマットであることであり、前記第2の条件は、前記下りリンク制御情報に用いられるフォーマットが前記第1のフォーマットと異なる第2のフォーマットであることである請求項6記載の基地局装置。

請求項10

前記時間パラメータは前記物理下りリンク制御チャネルと前記物理上りリンク共用チャネルとの間のスロットオフセットである請求項6記載の基地局装置。

請求項11

端末装置の通信方法であって、第1の設定情報を含むRRCメッセージを受信し、物理下りリンク制御チャネルで下りリンク制御情報を受信し、前記下りリンク制御情報の第1のフィールドが示すビット列に基づいて、物理上りリンク共用チャネルを送信する時間パラメータを決定し、前記時間パラメータに基づいて前記物理上りリンク共用チャネルを送信し、前記ビット列と前記時間パラメータの関係は、第1の条件を満たし、前記第1の設定情報に第1のパラメータ群が含まれる場合には、前記第1のパラメータ群によって定義され、第2の条件を満たし、前記第1の設定情報に第2のパラメータ群が含まれる場合には、前記第2のパラメータ群によって定義される通信方法。

請求項12

基地局装置の通信方法であって、第1の設定情報を含むRRCメッセージを送信し、物理下りリンク制御チャネルで下りリンク制御情報を送信し、物理上りリンク共用チャネルの受信に使用する時間パラメータに基づいて前記下りリンク制御情報の第1のフィールドが示すビット列を決定し、前記時間パラメータに基づいて前記物理上りリンク共用チャネルを受信し、前記ビット列と前記時間パラメータの関係は、第1の条件を満たし、前記第1の設定情報に第1のパラメータ群が含まれる場合には、前記第1のパラメータ群によって定義され、第2の条件を満たし、前記第1の設定情報に第2のパラメータ群が含まれる場合には、前記第2のパラメータ群によって定義される通信方法。

技術分野

0001

本発明は、基地局装置端末装置および通信方法に関する。

背景技術

0002

現在、第5世代のセルラーシステムに向けた無線アクセス方式および無線ネットワーク技術として、第三世代パートナーシッププロジェクト(3GPP: The Third Generation Partnership Project)において、LTE(Long Term Evolution)-Advanced Pro及びNR(New Radio technology)の技術検討及び規格策定が行われている(非特許文献1)。

0003

第5世代のセルラーシステムでは、高速・大容量伝送を実現するeMBB(enhanced Mobile BroadBand)、低遅延・高信頼通信を実現するURLLC(Ultra-Reliable and Low Latency Communication)、IoT(Internet of Things)などマシン型デバイスが多数接続するmMTC(massive Machine Type Communication)の3つがサービスの想定シナリオとして要求されている。

先行技術

0004

RP-161214,NTTDOCOMO, “Revision of SI: Study on New Radio Access Technology”, 2016年6月

発明が解決しようとする課題

0005

本発明の目的は、上記のような無線通信システムにおいて、効率的な通信を可能とする端末装置、基地局装置および通信方法を提供することを目的とする。

課題を解決するための手段

0006

(1)上記の目的を達成するために、本発明の態様は、以下のような手段を講じた。すなわち、本発明の一態様における端末装置は、第1の設定情報を含むRRCメッセージを受信し、物理下りリンク制御チャネル下りリンク制御情報を受信する受信部と、前記下りリンク制御情報の第1のフィールドが示すビット列に基づいて、物理上りリンク共用チャネルを送信する時間パラメータを決定する決定部と、前記時間パラメータに基づいて前記物理上りリンク共用チャネルを送信する送信部と、を備え、前記ビット列と前記時間パラメータの関係は、第1の条件を満たし、前記第1の設定情報に第1のパラメータ群が含まれる場合には、前記第1のパラメータ群によって定義され、第2の条件を満たし、前記第1の設定情報に第2のパラメータ群が含まれる場合には、前記第2のパラメータ群によって定義される。

0007

(2)また、本発明の一態様における基地局装置は、第1の設定情報を含むRRCメッセージを送信し、物理下りリンク制御チャネルで下りリンク制御情報を送信する送信部と、物理上りリンク共用チャネルの受信に使用する時間パラメータに基づいて前記下りリンク制御情報の第1のフィールドが示すビット列を決定する決定部と、前記時間パラメータに基づいて前記物理上りリンク共用チャネルを受信する受信部と、を備え、前記ビット列と前記時間パラメータの関係は、第1の条件を満たし、前記第1の設定情報に第1のパラメータ群が含まれる場合には、前記第1のパラメータ群によって定義され、第2の条件を満たし、前記第1の設定情報に第2のパラメータ群が含まれる場合には、前記第2のパラメータ群によって定義される。

0008

(3)また、本発明の一態様における通信方法は、端末装置の通信方法であって、第1の設定情報を含むRRCメッセージを受信し、物理下りリンク制御チャネルで下りリンク制御情報を受信し、前記下りリンク制御情報の第1のフィールドが示すビット列に基づいて、物理上りリンク共用チャネルを送信する時間パラメータを決定し、前記時間パラメータに基づいて前記物理上りリンク共用チャネルを送信し、前記ビット列と前記時間パラメータの関係は、第1の条件を満たし、前記第1の設定情報に第1のパラメータ群が含まれる場合には、前記第1のパラメータ群によって定義され、第2の条件を満たし、前記第1の設定情報に第2のパラメータ群が含まれる場合には、前記第2のパラメータ群によって定義される。

0009

(4)また、本発明の一態様における通信方法は、基地局装置の通信方法であって、第1の設定情報を含むRRCメッセージを送信し、物理下りリンク制御チャネルで下りリンク制御情報を送信し、物理上りリンク共用チャネルの受信に使用する時間パラメータに基づいて前記下りリンク制御情報の第1のフィールドが示すビット列を決定し、前記時間パラメータに基づいて前記物理上りリンク共用チャネルを受信し、前記ビット列と前記時間パラメータの関係は、第1の条件を満たし、前記第1の設定情報に第1のパラメータ群が含まれる場合には、前記第1のパラメータ群によって定義され、第2の条件を満たし、前記第1の設定情報に第2のパラメータ群が含まれる場合には、前記第2のパラメータ群によって定義される。

発明の効果

0010

この発明によれば、基地局装置と端末装置が、効率的に通信することができる。

図面の簡単な説明

0011

本発明の実施形態に係る無線通信システムの概念を示す図である。
本発明の実施形態に係るSS/PBCHブロックおよびSSバーストセットの例を示す図である。
本発明の実施形態に係る上りリンクおよび下りリンクスロット概略構成の一例を示す図である。
本発明の実施形態に係るサブフレーム、スロット、ミニスロットの時間領域における関係を示した図である。
本発明の実施形態に係るスロットまたはサブフレームの一例を示す図である。
本発明の実施形態に係るビームフォーミングの一例を示した図である。
本発明の実施形態に係るPDSCHマッピングタイプの一例を示す図である。
本発明の実施形態に係る周波数ホッピングの一例を示す図である。
本発明の実施形態に係る繰り返し送信回数の決定と周波数ホッピングの他の一例を示す図である。
本発明の実施形態に係るどのリソース割り当てテーブルをPDSCH時間領域リソース割り当てに適用するかを定義する図である。
本発明の実施形態に係るPDSCHに適用するリソース割り当てテーブルの決定法を示すテーブルの一例である。
本発明の実施形態に係るPDSCHに適用するリソース割り当てテーブルの決定法を示すテーブルの別の一例である。
本発明の実施形態に係るデフォルトテーブルAの一例を示す図である。
本発明の実施形態に係るデフォルトテーブルBの一例を示す図である。
本発明の実施形態に係るデフォルトテーブルCの一例を示す図である。
本発明の実施形態に係るSLIVを算出する一例を示す図である。
本実施形態に係るどのリソース割り当てテーブルをPUSCH時間領域リソース割り当てに適用するかを定義する図である。
本実施形態に係るPUSCHデフォルトテーブルAの一例を示す図である。
本発明の実施形態に係るPUSCHに適用するリソース割り当てテーブルの決定法を示すテーブルの一例である。
本発明の実施形態に係るPUSCHに適用するリソース割り当てテーブルの決定法を示すテーブルの別の一例である。
本発明の実施形態に係る端末装置1の構成を示す概略ブロック図である。
本発明の実施形態に係る基地局装置3の構成を示す概略ブロック図である。

実施例

0012

以下、本発明の実施形態について説明する。

0013

図1は、本実施形態における無線通信システムの概念図である。図1において、無線通信システムは、端末装置1A、端末装置1B、および基地局装置3を具備する。以下、端末装置1A、および、端末装置1Bを、端末装置1とも称する。

0014

端末装置1は、ユーザ端末移動局装置通信端末移動機端末、UE(User Equipment)、MS(Mobile Station)とも称される。基地局装置3は、無線基地局装置基地局、無線基地局固定局、NB(Node B)、eNB(evolved Node B)、BTS(Base Transceiver Station)、BS(Base Station)、NR NB(NR Node B)、NNB、TRP(Transmission and Reception Point)、gNBとも称される。基地局装置3は、コアネットワーク装置を含んでも良い。また、基地局装置3は、1つまたは複数の送受信点4(transmission reception point)を具備しても良い。以下で説明する基地局装置3の機能/処理の少なくとも一部は、該基地局装置3が具備する各々の送受信点4における機能/処理であってもよい。基地局装置3は、基地局装置3によって制御される通信可能範囲(通信エリア)を1つまたは複数のセルとして端末装置1をサーブしてもよい。また、基地局装置3は、1つまたは複数の送受信点4によって制御される通信可能範囲(通信エリア)を1つまたは複数のセルとして端末装置1をサーブしてもよい。また、基地局装置3は、1つのセルを複数の部分領域(Beamed area)にわけ、それぞれの部分領域において端末装置1をサーブしてもよい。ここで、部分領域は、ビームフォーミングで使用されるビームインデックスあるいはプリコーディングのインデックスに基づいて識別されてもよい。

0015

基地局装置3から端末装置1への無線通信リンクを下りリンクと称する。端末装置1から基地局装置3への無線通信リンクを上りリンクと称する。

0016

図1において、端末装置1と基地局装置3の間の無線通信では、サイクリックプレフィックス(CP: Cyclic Prefix)を含む直交周波数分割多重(OFDM: Orthogonal Frequency Division Multiplexing)、シングルキャリア周波数多重(SC-FDM: Single-Carrier Frequency Division Multiplexing)、離散フーリエ変換拡散OFDM(DFT-S-OFDM: Discrete Fourier Transform Spread OFDM)、マルチキャリア符号分割多重(MC-CDM: Multi-Carrier Code Division Multiplexing)が用いられてもよい。

0017

また、図1において、端末装置1と基地局装置3の間の無線通信では、ユニバーサルフィルタマルチキャリア(UFMC: Universal-Filtered Multi-Carrier)、フィルタOFDM(F-OFDM: Filtered OFDM)、窓関数乗算されたOFDM(Windowed OFDM)、フィルタバンクマルチキャリア(FBMC: Filter-Bank Multi-Carrier)が用いられてもよい。

0018

なお、本実施形態ではOFDMを伝送方式としてOFDMシンボルで説明するが、上述の他の伝送方式の場合を用いた場合も本発明に含まれる。

0019

また、図1において、端末装置1と基地局装置3の間の無線通信では、CPを用いない、あるいはCPの代わりにゼロパディングをした上述の伝送方式が用いられてもよい。また、CPやゼロパディングは前方と後方の両方に付加されてもよい。

0020

本実施形態の一態様は、LTEやLTE−A/LTE−A Proといった無線アクセス技術(RAT: Radio Access Technology)とのキャリアアグリゲーションまたはデュアルコネクティビティにおいてオペレーションされてもよい。このとき、一部またはすべてのセルまたはセルグループキャリアまたはキャリアグループ(例えば、プライマリセル(PCell: Primary Cell)、セカンダリセル(SCell: Secondary Cell)、プライマリセカンダリセル(PSCell)、MCG(Master Cell Group)、SCG(Secondary Cell Group)など)で用いられてもよい。また、単独でオペレーションするスタンドアローンで用いられてもよい。デュアルコネクティビティオペレーションにおいては、SpCell(Special Cell)は、MAC(MAC: Medium Access Control)エンティティがMCGに関連付けられているか、SCGに関連付けられているかに応じて、それぞれ、MCGのPCellまたは、SCGのPSCellと称する。デュアルコネクティビティオペレーションでなければ、SpCell(Special Cell)は、PCellと称する。SpCell(Special Cell)は、PUCCH送信と、競合ベースランダムアクセスサポートする。

0021

本実施形態では、端末装置1に対して1つまたは複数のサービングセルが設定されてもよい。設定された複数のサービングセルは、1つのプライマリセルと1つまたは複数のセカンダリセルとを含んでもよい。プライマリセルは、初期コネクション確立(initial connection establishment)プロシージャが行なわれたサービングセル、コネクション確立(connection re-establishment)プロシージャを開始したサービングセル、または、ハンドオーバプロシージャにおいてプライマリセルと指示されたセルであってもよい。RRC(Radio Resource Control)コネクションが確立された時点、または、後に、1つまたは複数のセカンダリセルが設定されてもよい。ただし、設定された複数のサービングセルは、1つのプライマリセカンダリセルを含んでもよい。プライマリセカンダリセルは、端末装置1が設定された1つまたは複数のセカンダリセルのうち、上りリンクにおいて制御情報送信可能なセカンダリセルであってもよい。また、端末装置1に対して、マスターセルグループとセカンダリセルグループの2種類のサービングセルのサブセットが設定されてもよい。マスターセルグループは1つのプライマリセルと0個以上のセカンダリセルで構成されてもよい。セカンダリセルグループは1つのプライマリセカンダリセルと0個以上のセカンダリセルで構成されてもよい。

0022

本実施形態の無線通信システムは、TDD(Time Division Duplex)および/またはFDD(Frequency Division Duplex)が適用されてよい。複数のセルの全てに対してTD
D(Time Division Duplex)方式またはFDD(Frequency Division Duplex)方式が適
用されてもよい。また、TDD方式が適用されるセルとFDD方式が適用されるセルが集約されてもよい。TDD方式はアンペアドスクトラムオペレーション(Unpaired spectrum operation)と称されてもよい。FDD方式はペアードスペクトラムオペレーション(Paired spectrum operation)と称されてもよい。

0023

下りリンクにおいて、サービングセルに対応するキャリアを下りリンクコンポーネントキャリア(あるいは下りリンクキャリア)と称する。上りリンクにおいて、サービングセルに対応するキャリアを上りリンクコンポーネントキャリア(あるいは上りリンクキャリア)と称する。サイドリンクにおいて、サービングセルに対応するキャリアをサイドリンクコンポーネントキャリア(あるいはサイドリンクキャリア)と称する。下りリンクコン
ポーネントキャリア、上りリンクコンポーネントキャリア、および/またはサイドリンクコンポーネントキャリアを総称してコンポーネントキャリア(あるいはキャリア)と称する。

0024

本実施形態の物理チャネルおよび物理信号について説明する。

0025

図1において、端末装置1と基地局装置3の無線通信では、以下の物理チャネルが用いられる。

0026

・PBCH(物理報知チャネル:Physical Broadcast CHannel)
・PDCCH(物理下りリンク制御チャネル:Physical Downlink Control CHannel)
・PDSCH(物理下りリンク共用チャネル:Physical Downlink Shared CHannel)
・PUCCH(物理上りリンク制御チャネル:Physical Uplink Control CHannel)
・PUSCH(物理上りリンク共用チャネル:Physical Uplink Shared CHannel)
・PRACH(物理ランダムアクセスチャネル:Physical Random Access CHannel)

0027

PBCHは、端末装置1が必要な重要なシステム情報を含む重要情報ブロックMIB: Master Information Block、EIB: Essential Information Block、BCH:Broadcast Channel)を報知するために用いられる。

0028

また、PBCHは、同期信号のブロック(SS/PBCHブロックとも称する)の周期内時間インデックスを報知するために用いられてよい。ここで、時間インデックスは、セル内の同期信号およびPBCHのインデックスを示す情報である。例えば、3つの送信ビーム送信フィルタ設定、受信空間パラメータに関する擬似同位置(QCL:Quasi Co-Location))の想定を用いてSS/PBCHブロックを送信する場合、予め定められた周期内または設定された周期内の時間順を示してよい。また、端末装置は、時間インデックスの違いを送信ビームの違いと認識してもよい。

0029

PDCCHは、下りリンクの無線通信(基地局装置3から端末装置1への無線通信)において、下りリンク制御情報(Downlink Control Information: DCI)を送信する(また
運ぶ)ために用いられる。ここで、下りリンク制御情報の送信に対して、1つまたは複数のDCI(DCIフォーマットと称してもよい)が定義される。すなわち、下りリンク制御情報に対するフィールドがDCIとして定義され、情報ビットマップされる。PDCCHは、PDCCH候補において送信される。端末装置1は、サービングセルにおいてPDCCH候補(candidate)のセットをモニタする。モニタすることは、あるDCIフ
ォーマットに応じてPDCCHのデコード試みることを意味する。

0030

例えば、以下のDCIフォーマットが定義されてよい。
・DCIフォーマット0_0
・DCIフォーマット0_1
・DCIフォーマット0_2
・DCIフォーマット1_0
・DCIフォーマット1_1
・DCIフォーマット1_2
・DCIフォーマット2_0
・DCIフォーマット2_1
・DCIフォーマット2_2
・DCIフォーマット2_3

0031

DCIフォーマット0_0は、あるサービングセルにおけるPUSCHのスケジューリ
ングのために用いられてもよい。DCIフォーマット0_0は、PUSCHのスケジューリング情報周波数領域リソース割り当て及び時間領域リソース割り当て)を示す情報を含んでよい。DCIフォーマット0_0は、識別子であるRadio Network Temporary Identifier(RNTI)のうち、Cell−RNTI(C−RNTI)、Configured Scheduling(CS)−RNTI)、MCS—C−RNTI、および/または、Temporary C−NRTI(TC−RNTI)の何れかによってスクランブルされるCRC(Cyclic Redundancy Check)が付加されてもよい。DCIフォーマット0_0は、コモンサーチスペースまたはUE固有サーチスペースにおいてモニタされてもよい。

0032

DCIフォーマット0_1は、あるサービングセルにおけるPUSCHのスケジューリングのために用いられてもよい。DCIフォーマット0_1は、PUSCHのスケジューリング情報(周波数領域リソース割り当て及び時間領域リソース割り当て)を示す情報、帯域部分(BWP:BandWidth Part)を示す情報、チャネル状態情報(CSI:Channel State Information)リクエストサウンディング参照信号SRS:Sounding Reference Signal)リクエスト、および/または、アンテナポートに関する情報を含んでよい。DCIフォーマット0_1は、RNTIのうち、C−RNTI、CS−RNTI、Semi Persistent(SP)−CSI−RNTI、および/または、MCS—C−RNTIの何れかによってスクランブルされるCRCが付加されてもよい。DCIフォーマット0_1は、UE固有サーチスペースにおいてモニタされてもよい。

0033

DCIフォーマット0_2は、あるサービングセルにおけるPUSCHのスケジューリングのために用いられてもよい。DCIフォーマット0_2は、PUSCHのスケジューリング情報(周波数領域リソース割り当て及び時間領域リソース割り当て)を示す情報、BWPを示す情報、CSIリクエスト、SRSリクエスト、および/または、アンテナポートに関する情報を含んでよい。DCIフォーマット0_2は、RNTIのうち、C−RNTI、CSI−RNTI、SP−CSI−RNTI、および/または、MCS−C−RNTIの何れかによってスクランブルされるCRCが付加されてもよい。DCIフォーマット0_2は、UE固有サーチスペースにおいてモニタされてもよい。DCIフォーマット0_2は、DCIフォーマット0_1A等と称されるかもしれない。

0034

DCIフォーマット1_0は、あるサービングセルにおけるPDSCHのスケジューリングのために用いられてもよい。DCIフォーマット1_0は、PDSCHのスケジューリング情報(周波数領域リソース割り当て及び時間領域リソース割り当て)を示す情報を含んでよい。DCIフォーマット1_0は、識別子のうち、C−RNTI、CS−RNTI、MCS—C−RNTI、Paging RNTI(P−RNTI)、System Information(SI)−RNTI、Random Access(RA)−RNTI、および/または、TC−RNTIの何れかによってスクランブルされるCRCが付加されてもよい。DCIフォーマット1_0は、コモンサーチスペースまたはUE固有サーチスペースにおいてモニタされてもよい。

0035

DCIフォーマット1_1は、あるサービングセルにおけるPDSCHのスケジューリングのために用いられてもよい。DCIフォーマット1_1は、PDSCHのスケジューリング情報(周波数領域リソース割り当て及び時間領域リソース割り当て)を示す情報、帯域部分(BWP)を示す情報、送信設定指示(TCI:Transmission Configuration Indication)、および/または、アンテナポートに関する情報を含んでよい。DCIフォ
ーマット1_1は、RNTIのうち、C−RNTI、CS−RNTI、および/または、MCS—C−RNTIの何れかによってスクランブルされるCRCが付加されてもよい。DCIフォーマット1_1は、UE固有サーチスペースにおいてモニタされてもよい。

0036

DCIフォーマット1_2は、あるサービングセルにおけるPDSCHのスケジューリングのために用いられてもよい。DCIフォーマット1_2は、PDSCHのスケジューリング情報(周波数領域リソース割り当て及び時間領域リソース割り当て)を示す情報、BWPを示す情報、TCI、および/または、アンテナポートに関する情報を含んでよい。DCIフォーマット1_2は、RNTIのうち、C−RNTI、CS−RNTI、および/または、MCS—C−RNTIの何れかによってスクランブルされるCRCが付加されてもよい。DCIフォーマット1_2は、UE固有サーチスペースにおいてモニタされてもよい。DCIフォーマット1_2は、DCIフォーマット1_1A等と称されるかもしれない。

0037

DCIフォーマット2_0は、1つまたは複数のスロットのスロットフォーマット通知するために用いられる。スロットフォーマットは、スロット内の各OFDMシンボルが下りリンク、フレキシブル、上りリンクのいずれかに分類されたものとして定義される。例えば、スロットフォーマットが28の場合、スロットフォーマット28が指示されたスロット内の14シンボルのOFDMシンボルに対してDDDDDDDDDDDDFUが適用される。ここで、Dが下りリンクシンボル、Fがフレキシブルシンボル、Uが上りリンクシンボルである。なお、スロットについては後述する。

0038

DCIフォーマット2_1は、端末装置1に対して、送信がないと想定してよい物理リソースブロックとOFDMシンボルを通知するために用いられる。なお、この情報はプリエンプション指示(間欠送信指示)と称してよい。

0039

DCIフォーマット2_2は、PUSCHおよびPUSCHのための送信電力制御TPC:Transmit Power Control)コマンドの送信のために用いられる。

0040

DCIフォーマット2_3は、1または複数の端末装置1によるサウンディング参照信号(SRS)送信のためのTPCコマンドのグループを送信するために用いられる。また、TPCコマンドとともに、SRSリクエストが送信されてもよい。また、DCIフォーマット2_3に、PUSCHおよびPUCCHのない上りリンク、またはSRSの送信電力制御がPUSCHの送信電力制御と紐付いていない上りリンクのために、SRSリクエストとTPCコマンドが定義されてよい。

0041

下りリンクに対するDCIを、下りリンクグラント(downlink grant)、または、下りリンクアサインメント(downlink assignment)とも称する。ここで、上りリンクに対す
るDCIを、上りリンクグラント(uplink grant)、または、上りリンクアサインメント(Uplink assignment)とも称する。DCIを、DCIフォーマットとも称してもよい。

0042

1つのPDCCHで送信されるDCIフォーマットに付加されるCRCパリティビットは、SI−RNTI、P−RNTI、C−RNTI、CS−RNTI、RA−RNTI、または、TC−RNTIでスクランブルされる。SI−RNTIはシステム情報のブロードキャストに使用される識別子であってもよい。P−RNTIは、ページングおよびシステム情報変更の通知に使用される識別子であってもよい。C−RNTI、MCS−C−RNTI、および、CS−RNTIは、セル内において端末装置を識別するための識別子である。TC−RNTIは、競合ベースランダムアクセス手順(contention based random access procedure)中に、ランダムアクセスプリアンブルを送信した端末装置1を識別するための識別子である。

0043

C−RNTIは、1つまたは複数のスロットにおけるPDSCHまたはPUSCHを制御するために用いられる。CS−RNTIは、PDSCHまたはPUSCHのリソース周期的に割り当てるために用いられる。MCS−C−RNTIは、グラントベース送信(
grant-based transmission)に対して所定のMCSテーブルの使用を示すために用いられる。TC−RNTIは、1つまたは複数のスロットにおけるPDSCH送信またはPUSCH送信を制御するために用いられる。TC−RNTIは、ランダムアクセスメッセージ3の再送信、およびランダムアクセスメッセージ4の送信をスケジュールするために用いられる。RA−RNTIは、ランダムアクセスプリアンブルを送信した物理ランダムアクセスチャネルの周波数および時間の位置情報に応じて決定される。

0044

C−RNTIおよび/またはその他のRNTIは、PDSCHまたはPUSCHのトラフィックのタイプに対応して異なる値が用いられてもよい。C−RNTIおよびその他のRNTIは、PDSCHまたはPUSCHで伝送されるデータのサービスタイプ(eMBB、URLLC、および/または、mMTC)に対応して異なる値が用いられてもよい。基地局装置3は、送信するデータのサービスタイプに対応して異なる値のRNTIを用いてもよい。端末装置1は、受信したDCIに適用された(スクランブルに用いられた)RNTIの値によって、関連するPDSCHまたはPUSCHで伝送されるデータのサービスタイプを識別してもよい。

0045

PUCCHは、上りリンクの無線通信(端末装置1から基地局装置3の無線通信)において、上りリンク制御情報(Uplink Control Information: UCI)を送信するために用い
られる。ここで、上りリンク制御情報には、下りリンクのチャネルの状態を示すために用いられるチャネル状態情報(CSI: Channel State Information)が含まれてもよい。また、上りリンク制御情報には、UL−SCHリソースを要求するために用いられるスケジューリング要求(SR: Scheduling Request)が含まれてもよい。また、上りリンク制御情報には、HARQACK(Hybrid Automatic Repeat request ACKnowledgement)が含まれてもよい。HARQ−ACKは、下りリンクデータ(Transport block, Medium Access Control Protocol Data Unit: MACPDU, Downlink-Shared Channel: DL-SCH)に対するHARQ−ACKを示してもよい。

0046

PDSCHは、媒介アクセス(MAC: Medium Access Control)層からの下りリンクデータ(DL-SCH: Downlink Shared CHannel)の送信に用いられる。また、下りリンクの場合
にはシステム情報(SI: System Information)やランダムアクセス応答(RAR: Random Access Response)などの送信にも用いられる。

0047

PUSCHは、MAC層からの上りリンクデータ(UL-SCH: Uplink Shared CHannel)
または上りリンクデータと共にHARQ−ACKおよび/またはCSIを送信するために用いられてもよい。また、CSIのみ、または、HARQ−ACKおよびCSIのみを送信するために用いられてもよい。すなわち、UCIのみを送信するために用いられてもよい。

0048

ここで、基地局装置3と端末装置1は、上位層(上位レイヤ:higher layer)において信号をやり取り(送受信)する。例えば、基地局装置3と端末装置1は、無線リソース制御(RRC: Radio Resource Control)層において、RRCシグナリング(RRC message: Radio Resource Control message、RRC information: Radio Resource Control informationとも称される)を送受信してもよい。また、基地局装置3と端末装置1は、MAC(Medium Access Control)層において、MACコントロールエレメントを送受信してもよい。また、端末装置1のRRC層は、基地局装置3から報知されるシステム情報を取得する。ここで、RRCシグナリング、システム情報、および/または、MACコントロールエレメントを、上位層の信号(上位レイヤ信号:higher layer signaling)または上位層のパラメータとも称する。ここでの上位層は、物理層から見た上位層を意味するため、MAC層、RRC層、RLC層PDCP層、NAS(Non Access Stratum)層などの1つまたは複数を含んでもよい。例えば、MAC層の処理において上位層とは、RRC層、RLC層、PDCP層、NAS層などの1つまたは複数を含んでもよい。以下、“Aは、上位層で与えられる”や“Aは、上位層によって与えられる”の意味は、端末装置1の上位層(主にRRC層やMAC層など)が、基地局装置3からAを受信し、その受信したAを端末装置1の上位層から端末装置1の物理層に与えることを意味してもよい。端末装置1には上位層のパラメータが設定されることは端末装置に対して上位層のパラメータが提供されることを意味してもよい。

0049

PDSCHまたはPUSCHは、RRCシグナリング、および、MACコントロールエレメントを送信するために用いられてもよい。ここで、PDSCHにおいて、基地局装置3から送信されるRRCシグナリングは、セル内における複数の端末装置1に対して共通のシグナリングであってもよい。また、基地局装置3から送信されるRRCシグナリングは、ある端末装置1に対して専用のシグナリング(dedicated signalingとも称する)で
あってもよい。すなわち、端末装置固有(UEスペフィック)の情報は、ある端末装置1に対して専用のシグナリングを用いて送信されてもよい。また、PUSCHは、上りリンクにおいてUEの能力(UE Capability)の送信に用いられてもよい。

0050

図1において、下りリンクの無線通信では、以下の下りリンク物理信号が用いられる。ここで、下りリンク物理信号は、上位層から出力された情報を送信するために使用されないが、物理層によって使用される。
・同期信号(Synchronization signal:SS)
参照信号(Reference Signal: RS)

0051

同期信号は、プライマリ同期信号(PSS:Primary Synchronization Signal)およびセカンダリ同期信号(SSS)を含んでよい。PSSとSSSを用いてセルIDが検出されてよい。

0052

同期信号は、端末装置1が下りリンクの周波数領域および時間領域の同期をとるために用いられる。ここで、同期信号は、端末装置1が基地局装置3によるプリコーディングまたはビームフォーミングにおけるプリコーディングまたはビームの選択に用いられて良い。なお、ビームは、送信または受信フィルタ設定、あるいは空間ドメイン送信フィルタまたは空間ドメイン受信フィルタと呼ばれてもよい。

0053

参照信号は、端末装置1が物理チャネルの伝搬路補償を行うために用いられる。ここで、参照信号は、端末装置1が下りリンクのCSIを算出するためにも用いられてよい。また、参照信号は、無線パラメータサブキャリア間隔などのヌメロロジーやFFTの窓同期などができる程度の細かい同期(Fine synchronization)に用いられて良い。

0054

本実施形態において、以下の下りリンク参照信号のいずれか1つまたは複数が用いられる。
・DMRS(Demodulation Reference Signal)
・CSI−RS(Channel State Information Reference Signal)
・PTRS(Phase Tracking Reference Signal)
・TRS(Tracking Reference Signal)

0055

DMRSは、変調信号復調するために使用される。なお、DMRSには、PBCHを復調するための参照信号と、PDSCHを復調するための参照信号の2種類が定義されてもよいし、両方をDMRSと称してもよい。CSI−RSは、チャネル状態情報(CSI:Channel State Information)の測定およびビームマネジメントに使用され、周期的またはセミパーシステントまたは非周期のCSI参照信号の送信方法が適用される。CSI−RSには、ノンゼロパワー(NZP:Non−Zero Power)CSI−RSと、送信電力(または受信電力)がゼロである(ゼロパワー(ZP:Zero Power)CSI−RSが定義されてよい。ここで、ZP CSI−RSは送信電力がゼロまたは送信されないCSI−RSリソースと定義されてよい。PTRSは、位相雑音に起因する周波数オフセット保証する目的で、時間軸位相トラックするために使用される。TRSは、高速移動時におけるドップラーシフトを保証するために使用される。なお、TRSはCSI−RSの1つの設定として用いられてよい。例えば、1ポートのCSI−RSがTRSとして無線リソースが設定されてもよい。

0056

本実施形態において、以下の上りリンク参照信号のいずれか1つまたは複数が用いられる。
・DMRS(Demodulation Reference Signal)
・PTRS(Phase Tracking Reference Signal)
・SRS(Sounding Reference Signal)

0057

DMRSは、変調信号を復調するために使用される。なお、DMRSには、PUCCHを復調するための参照信号と、PUSCHを復調するための参照信号の2種類が定義されてもよいし、両方をDMRSと称してもよい。SRSは、上りリンクのチャネル状態情報(CSI)の測定、チャネルサウンディング、およびビームマネジメントに使用される。PTRSは、位相雑音に起因する周波数オフセットを保証する目的で、時間軸で位相をトラックするために使用される。

0058

下りリンク物理チャネルおよび/または下りリンク物理シグナルを総称して、下りリンク信号と称する。上りリンク物理チャネルおよび/または上りリンク物理シグナルを総称して、上りリンク信号と称する。下りリンク物理チャネルおよび/または上りリンク物理チャネルを総称して、物理チャネルと称する。下りリンク物理シグナルおよび/または上りリンク物理シグナルを総称して、物理シグナルと称する。

0059

BCH、UL−SCHおよびDL−SCHは、トランスポートチャネルである。媒体アクセス制御(MAC:Medium Access Control)層で用いられるチャネルをトランスポ
トチネルと称する。MAC層で用いられるトランスポートチャネルの単位を、トランスポートブロック(TB:transport block)および/またはMACPDU(Protocol Data Unit)とも称する。MAC層においてトランスポートブロック毎にHARQ(Hybrid Automatic Repeat reQuest)の制御が行われる。トランスポートブロックは、MAC層が物理層に渡す(deliver)データの単位である。物理層において、トランスポートブロックはコードワードにマップされ、コードワード毎に符号化処理が行われる。

0060

図2は、本実施形態に係るSS/PBCHブロック(同期信号ブロック、SSブロック、SSBとも称される)およびSSバーストセット(同期信号バーストセットとも称される)の例を示す図である。図2は、周期的に送信されるSSバーストセット内に2つのSS/PBCHブロックが含まれ、SS/PBCHブロックは、連続する4OFDMシンボルで構成される例を示している。

0061

SS/PBCHブロックは、少なくとも同期信号(PSS、SSS)、および/またはPBCHを含む単位ブロックである。SS/PBCHブロックに含まれる信号/チャネルを送信することを、SS/PBCHブロックを送信すると表現する。基地局装置3はSSバーストセット内の1つまたは複数のSS/PBCHブロックを用いて同期信号および/またはPBCHを送信する場合に、SS/PBCHブロック毎に独立した下りリンク送信ビームを用いてもよい。

0062

図2において、1つのSS/PBCHブロックにはPSS、SSS、PBCHが時間/
周波数多重されている。ただし、PSS、SSSおよび/またはPBCHが時間領域で多重される順番図2に示す例と異なってもよい。

0063

SSバーストセットは、周期的に送信されてよい。例えば、初期アクセスに使用されるための周期と、接続されている(ConnectedまたはRRC_Connected)端末装置のために設定する周期が定義されてもよい。また、接続されている(ConnectedまたはRRC_Connected)端末装置のために設定する周期はRRC層で設定されてよい。また、接続されている(ConnectedまたはRRC_Connected)端末のために設定する周期は潜在的に送信する可能性がある時間領域の無線リソースの周期であって、実際には基地局装置3が送信するかどうかを決めてもよい。また、初期アクセスに使用されるための周期は、仕様書などに予め定義されてよい。

0064

SSバーストセットは、システムフレーム番号SFN:System Frame Number)に基
づいて決定されてよい。また、SSバーストセットの開始位置(バウンダリ)は、SFNと周期に基づいて決定されてよい。

0065

SS/PBCHブロックは、SSバーストセット内の時間的な位置に応じてSSBインデックス(SSB/PBCHブロックインデックスと称されてもよい)が割り当てられる。端末装置1は、検出したSS/PBCHブロックに含まれるPBCHの情報および/または参照信号の情報に基づいてSSBインデックスを算出する。

0066

複数のSSバーストセットにおける各SSバーストセット内における相対的な時間が同じSS/PBCHブロックは、同じSSBインデックスが割り当てられる。複数のSSバーストセットにおける各SSバーストセット内における相対的な時間が同じSS/PBCHブロックは、QCLである(あるいは同じ下りリンク送信ビームが適用されている)と想定されてもよい。また、複数のSSバーストセットにおける各SSバーストセット内における相対的な時間が同じSS/PBCHブロックにおけるアンテナポートは、平均遅延、ドップラーシフト、空間相関に関してQCLであると想定されてもよい。

0067

あるSSバーストセットの周期内で、同じSSBインデックスが割り当てられているSS/PBCHブロックは、平均遅延、平均ゲイン、ドップラースプレッド、ドップラーシフト、空間相関に関してQCLであると想定されてもよい。QCLである1つまたは複数のSS/PBCHブロック(あるいは参照信号であってもよい)に対応する設定をQCL設定と称してもよい。

0068

SS/PBCHブロック数(SSブロック数あるいはSSB数と称されてもよい)は、例えばSSバースト、またはSSバーストセット内、またはSS/PBCHブロックの周期の中のSS/PBCHブロック数(個数)として定義されてよい。また、SS/PBCHブロック数は、SSバースト内、またはSSバーストセット内、またはSS/PBCHブロックの周期の中のセル選択のためのビームグループの数を示してもよい。ここで、ビームグループは、SSバースト内、またはSSバーストセット内、またはSS/PBCHブロックの周期の中に含まれる異なるSS/PBCHブロックの数または異なるビームの数として定義されてよい。

0069

以下、本実施形態で説明する参照信号は、下りリンク参照信号、同期信号、SS/PBCHブロック、下りリンクDM−RS、CSI−RS、上りリンク参照信号、SRS、および/または、上りリンクDM−RSを含む。例えば、下りリンク参照信号、同期信号および/またはSS/PBCHブロックを参照信号と称してもよい。下りリンクで使用される参照信号は、下りリンク参照信号、同期信号、SS/PBCHブロック、下りリンクDM−RS、CSI−RSなどを含む。上りリンクで使用される参照信号は、上りリンク参
照信号、SRS、および/または、上りリンクDM−RSなどを含む。

0070

また、参照信号は、無線リソース測定(RRM:Radio Resource Measurement)に用いられてよい。また、参照信号は、ビームマネジメントに用いられてよい。

0071

ビームマネジメントは、送信装置(下りリンクの場合は基地局装置3であり、上りリンクの場合は端末装置1である)におけるアナログおよび/またはディジタルビームと、受信装置(下りリンクの場合は端末装置1、上りリンクの場合は基地局装置3である)におけるアナログおよび/またはディジタルビームの指向性を合わせ、ビーム利得を獲得するための基地局装置3および/または端末装置1の手続きであってよい。

0072

なお、ビームペアリンクを構成、設定または確立する手続きとして、下記の手続きを含んでよい。
ビーム選択(Beam selection)
・ビーム改善(Beam refinement)
・ビームリカバリ(Beam recovery)

0073

例えば、ビーム選択は、基地局装置3と端末装置1の間の通信においてビームを選択する手続きであってよい。また、ビーム改善は、さらに利得の高いビームの選択、あるいは端末装置1の移動によって最適な基地局装置3と端末装置1の間のビームの変更をする手続きであってよい。ビームリカバリは、基地局装置3と端末装置1の間の通信において遮蔽物や人の通過などにより生じるブロッケージにより通信リンク品質が低下した際にビームを再選択する手続きであってよい。

0074

ビームマネジメントには、ビーム選択、ビーム改善が含まれてよい。ビームリカバリには、下記の手続きを含んでよい。
・ビーム失敗(beam failure)の検出
・新しいビームの発見
・ビームリカバリリクエストの送信
・ビームリカバリリクエストに対する応答のモニタ

0075

例えば、端末装置1における基地局装置3の送信ビームを選択する際にCSI−RSまたはSS/PBCHブロックに含まれるSSSのRSRP(Reference Signal Received Power)を用いてもよいし、CSIを用いてもよい。また、基地局装置3への報告として
CSI−RSリソースインデックス(CRI:CSI-RS Resource Index)を用いてもよい
し、SS/PBCHブロックに含まれるPBCHおよび/またはPBCHの復調に用いられる復調用参照信号(DMRS)の系列で指示されるインデックスを用いてもよい。

0076

また、基地局装置3は、端末装置1へビームを指示する際にCRIまたはSS/PBCHの時間インデックスを指示し、端末装置1は、指示されたCRIまたはSS/PBCHの時間インデックスに基づいて受信する。このとき、端末装置1は指示されたCRIまたはSS/PBCHの時間インデックスに基づいて空間フィルタを設定し、受信してよい。また、端末装置1は、疑似同位置(QCL:Quasi Co-Location)の想定を用いて受信し
てもよい。ある信号(アンテナポート、同期信号、参照信号など)が別の信号(アンテナポート、同期信号、参照信号など)と「QCLである」または、「QCLの想定が用いられる」とは、ある信号が別の信号と関連付けられていると解釈できる。

0077

もしあるアンテナポートにおけるあるシンボルが搬送されるチャネルの長区間特性(Long Term Property)が他方のアンテナポートにおけるあるシンボルが搬送されるチャネルから推論されうるなら、2つのアンテナポートはQCLであるといわれる。チャネルの長区間特性は、遅延スプレッド、ドップラースプレッド、ドップラーシフト、平均利得、及び平均遅延の1つまたは複数を含む。例えば、アンテナポート1とアンテナポート2が平均遅延に関してQCLである場合、アンテナポート1の受信タイミングからアンテナポート2の受信タイミングが推論されうることを意味する。

0078

このQCLは、ビームマネジメントにも拡張されうる。そのために、空間に拡張したQCLが新たに定義されてもよい。例えば、空間ドメインのQCLの想定におけるチャネルの長区間特性(Long term property)として、無線リンクあるいはチャネルにおける到来角(AoA(Angle of Arrival), ZoA(Zenith angle of Arrival)など)および/または
角度広がり(Angle Spread、例えばASA(Angle Spread of Arrival)やZSA(Zenith angle Spread of Arrival))、送出角(AoD, ZoDなど)やその角度広がり(Angle Spread、例えばASD(Angle Spread of Departure)やZSD(Zenith angle Spread of Departure))、空間相関(Spatial Correlation)、受信空間パラメータであってもよい。

0079

例えば、アンテナポート1とアンテナポート2の間で受信空間パラメータに関してQCLであるとみなせる場合、アンテナポート1からの信号を受信する受信ビーム(受信空間フィルタ)からアンテナポート2からの信号を受信する受信ビームが推論されうることを意味する。

0080

QCLタイプとして、QCLであるとみなしてよい長区間特性の組み合わせが定義されてよい。例えば、以下のタイプが定義されてよい。
・タイプA:ドップラーシフト、ドップラースプレッド、平均遅延、遅延スプレッド
・タイプB:ドップラーシフト、ドップラースプレッド
・タイプC:平均遅延、ドップラーシフト
・タイプD:受信空間パラメータ

0081

上述のQCLタイプは、RRCおよび/またはMAC層および/またはDCIで1つまたは2つの参照信号とPDCCHやPDSCHDMRSとのQCLの想定を送信設定指示(TCI:Transmission Configuration Indication)として設定および/または指示
してもよい。例えば、端末装置1がPDCCHを受信する際のTCIの1つの状態として、SS/PBCHブロックのインデックス#2とQCLタイプA+QCLタイプBが設定および/または指示された場合、端末装置1は、PDCCH DMRSを受信する際、SS/PBCHブロックインデックス#2の受信におけるドップラーシフト、ドップラースプレッド、平均遅延、遅延スプレッド、受信空間パラメータとチャネルの長区間特性とみなしてPDCCHのDMRSを受信して同期や伝搬路推定をしてもよい。このとき、TCIにより指示される参照信号(上述の例ではSS/PBCHブロック)をソース参照信号、ソース参照信号を受信する際のチャネルの長区間特性から推論される長区間特性の影響を受ける参照信号(上述の例ではPDCCH DMRS)をターゲット参照信号と称してよい。また、TCIは、RRCで1つまたは複数のTCI状態と各状態に対してソース参照信号とQCLタイプの組み合わせが設定され、MAC層またはDCIにより端末装置1に指示されてよい。

0082

この方法により、ビームマネジメントおよびビーム指示/報告として、空間ドメインのQCLの想定と無線リソース(時間および/または周波数)によりビームマネジメントと等価な基地局装置3、端末装置1の動作が定義されてもよい。

0083

以下、サブフレームについて説明する。本実施形態ではサブフレームと称するが、リソースユニット無線フレーム時間区間時間間隔などと称されてもよい。

0084

図3は、本発明の第1の実施形態に係る上りリンクおよび下りリンクスロットの概略構
成の一例を示す図である。無線フレームのそれぞれは、10ms長である。また、無線フレームのそれぞれは10個のサブフレームおよびW個のスロットから構成される。また、1スロットは、X個のOFDMシンボルで構成される。つまり、1サブフレームの長さは1msである。スロットのそれぞれは、サブキャリア間隔によって時間長が定義される。例えば、OFDMシンボルのサブキャリア間隔が15kHz、NCP(Normal Cyclic Prefix)の場合、X=7あるいはX=14であり、それぞれ0.5msおよび1msである。また、サブキャリア間隔が60kHzの場合は、X=7あるいはX=14であり、それぞれ0.125msおよび0.25msである。また、例えば、X=14の場合、サブキャリア間隔が15kHzの場合はW=10であり、サブキャリア間隔が60kHzの場合はW=40である。図3は、X=7の場合を一例として示している。なお、X=14の場合にも同様に拡張できる。また、上りリンクスロットも同様に定義され、下りリンクスロットと上りリンクスロットは別々に定義されてもよい。また、図3のセルの帯域幅帯域の一部(BWP:BandWidth Part)として定義されてもよい。また、スロットは、送信時間間隔(TTI:Transmission Time Interval)と定義されてもよい。スロットは、TTIとして定義されなくてもよい。TTIは、トランスポートブロックの送信期間であってもよい。

0085

スロットのそれぞれにおいて送信される信号または物理チャネルは、リソースグリッドによって表現されてよい。リソースグリッドは、それぞれのヌメロロジー(サブキャリア間隔およびサイクリックプレフィックス長)およびそれぞれのキャリアに対して、複数のサブキャリアと複数のOFDMシンボルによって定義される。1つのスロットを構成する
サブキャリアの数は、セルの下りリンクおよび上りリンクの帯域幅にそれぞれ依存する。リソースグリッド内のエレメントのそれぞれをリソースエレメントと称する。リソースエレメントは、サブキャリアの番号とOFDMシンボルの番号とを用いて識別されてよい。

0086

リソースグリッドは、ある物理下りリンクチャネル(PDSCHなど)あるいは上りリンクチャネル(PUSCHなど)のリソースエレメントのマッピングを表現するために用いられる。例えば、サブキャリア間隔が15kHzの場合、サブフレームに含まれるOFDMシンボル数X=14で、NCPの場合には、1つの物理リソースブロックは、時間領域において14個の連続するOFDMシンボルと周波数領域において12*Nmax個の連続するサブキャリアとから定義される。Nmaxは、後述するサブキャリア間隔設定μにより決定されるリソースブロック最大数である。つまり、リソースグリッドは、(14*12*Nmax,μ)個のリソースエレメントから構成される。ECP(Extended CP)の場合、サブキャリア間隔60kHzにおいてのみサポートされるので、1つの物理リソースブロックは、例えば、時間領域において12(1スロットに含まれるOFDMシンボル数)*4(1サブフレームに含まれるスロット数)=48個の連続するOFDMシンボルと、周波数領域において12*Nmax,μ個の連続するサブキャリアとにより定義される。つまり、リソースグリッドは、(48*12*Nmax,μ)個のリソースエレメントから構成される。

0087

リソースブロックとして、参照リソースブロック、共通リソースブロック、物理リソースブロック、仮想リソースブロックが定義される。1リソースブロックは、周波数領域で連続する12サブキャリアとして定義される。参照リソースブロックは、全てのサブキャリアにおいて共通であり、例えば15kHzのサブキャリア間隔でリソースブロックを構成し、昇順に番号が付されてよい。参照リソースブロックインデックス0におけるサブキャリアインデックス0は、参照ポイントA(point A)と称されてよい(単に“参照ポイント”と称されてもよい)。共通リソースブロックは、参照ポイントAから各サブキャリア間隔設定μにおいて0から昇順で番号が付されるリソースブロックである。上述のリソースグリッドはこの共通リソースブロックにより定義される。物理リソースブロックは、後述する帯域部分(BWP)の中に含まれる0から昇順で番号が付されたリソースブロックであり、物理リソースブロックは、帯域部分(BWP)の中に含まれる0から昇順で番号が付されたリソースブロックである。ある物理上りリンクチャネルは、まず仮想リソースブロックにマップされる。その後、仮想リソースブロックは、物理リソースブロックにマップされる。以下、リソースブロックは仮想リソースブロックであってもよいし、物理リソースブロックであってもよいし、共通リソースブロックであってもよいし、参照リソースブロックであってもよい。

0088

次に、サブキャリア間隔設定μについて説明する。上述のようにNRでは、1つまたは複数のOFDMヌメロロジーがサポートされる。あるBWPにおいて、サブキャリア間隔設定μ(μ=0,1,...,5)と、サイクリックプレフィックス長は、下りリンクのBWPに対して上位層で与えられ、上りリンクのBWPにおいて上位層で与えられる。ここで、μが与えられると、サブキャリア間隔Δfは、Δf=2^μ・15(kHz)で与えられる。

0089

サブキャリア間隔設定μにおいて、スロットは、サブフレーム内で0からN^{subframe,μ}_{slot}−1に昇順に数えられ、フレーム内で0からN^{frame,μ}_{slot}−1に昇順に数えられる。スロット設定およびサイクリックプレフィックスに基づいてN^{slot}_{symb}の連続するOFDMシンボルがスロット内にある。N^{slot}_{symb}は14である。サブフレーム内のスロットn^{μ}_{s}のスタートは、同じサブフレーム内のn^{μ}_{s}*N^{slot}_{symb}番目のOFDMシンボルのスタートと時間でアラインされている。

0090

次に、サブフレーム、スロット、ミニスロットについて説明する。図4は、サブフレーム、スロット、ミニスロットの時間領域における関係を示した図である。同図のように、3種類の時間ユニットが定義される。サブフレームは、サブキャリア間隔によらず1msであり、スロットに含まれるOFDMシンボル数は7または14であり、スロット長はサブキャリア間隔により異なる。ここで、サブキャリア間隔が15kHzの場合、1サブフレームには14OFDMシンボル含まれる。下りリンクスロットはPDSCHマッピングタイプAと称されてよい。上りリンクスロットはPUSCHマッピングタイプAと称されてよい。

0091

ミニスロット(サブスロット(subslot)と称されてもよい)は、1つのスロットに含
まれるOFDMシンボル数よりも少ない数のOFDMシンボルで構成される時間ユニットである。同図はミニスロットが2OFDMシンボルで構成される場合を一例として示している。ミニスロット内のOFDMシンボルは、スロットを構成するOFDMシンボルタイミングに一致してもよい。なお、スケジューリングの最小単位はスロットまたはミニスロットでよい。また、ミニスロットを割り当てることを、ノンスロットベースのスケジューリングと称してもよい。また、ミニスロットをスケジューリングされることを参照信号とデータのスタート位置の相対的な時間位置が固定であるリソースがスケジュールされたと表現されてもよい。下りリンクミニスロットはPDSCHマッピングタイプBと称されてよい。上りリンクミニスロットはPUSCHマッピングタイプBと称されてよい。

0092

図5は、スロットフォーマットの一例を示す図である。ここでは、サブキャリア間隔15kHzにおいてスロット長が1msの場合を例として示している。同図において、Dは下りリンク、Uは上りリンクを示している。同図に示されるように、ある時間区間内(例えば、システムにおいて1つのUEに対して割り当てなければならない最小の時間区間)においては、
・下りリンクシンボル
・フレキシブルシンボル
・上りリンクシンボル
のうち1つまたは複数を含んでよい。なお、これらの割合はスロットフォーマットとして予め定められてもよい。また、スロット内に含まれる下りリンクのOFDMシンボル数またはスロット内のスタート位置および終了位置で定義されてもよい。また、スロット内に含まれる上りリンクのOFDMシンボル数またはDFT−S−OFDMシンボル数またはスロット内のスタート位置および終了位置で定義されてよい。なお、スロットをスケジューリングされることを参照信号とスロット境界の相対的な時間位置が固定であるリソースがスケジュールされたと表現されてもよい。

0093

端末装置1は、下りリンクシンボルまたはフレキシブルシンボルで下りリンク信号または下りリンクチャネルを受信してよい。端末装置1は、上りリンクシンボルまたはフレキシブルシンボルで上りリンク信号または下りリンクチャネルを送信してよい。

0094

図5(a)は、ある時間区間(例えば、1UEに割当可能な時間リソースの最小単位、またはタイムユニットなどとも称されてよい。また、時間リソースの最小単位を複数束ねてタイムユニットと称されてもよい。)で、全て下りリンク送信に用いられている例であり、図5(b)は、最初の時間リソースで例えばPDCCHを介して上りリンクのスケジューリングを行い、PDCCHの処理遅延及び下りから上り切り替え時間、送信信号の生成を含むフレキシブルシンボルを介して上りリンク信号を送信する。図5(c)は、最初の時間リソースでPDCCHおよび/または下りリンクのPDSCHの送信に用いられ、処理遅延及び下りから上りの切り替え時間、送信信号の生成のためのギャップを介してPUSCHまたはPUCCHの送信に用いられる。ここで、一例としては、上りリンク信号はHARQ−ACKおよび/またはCSI、すなわちUCIの送信に用いられてよい。図5(d)は、最初の時間リソースでPDCCHおよび/またはPDSCHの送信に用いられ、処理遅延及び下りから上りの切り替え時間、送信信号の生成のためのギャップを介して上りリンクのPUSCHおよび/またはPUCCHの送信に用いられる。ここで、一例としては、上りリンク信号は上りリンクデータ、すなわちUL−SCHの送信に用いられてもよい。図5(e)は、全て上りリンク送信(PUSCHまたはPUCCH)に用いられている例である。

0095

上述の下りリンクパート、上りリンクパートは、LTEと同様に複数のOFDMシンボルで構成されてよい。

0096

図6は、ビームフォーミングの一例を示した図である。複数のアンテナエレメントは1つの送信ユニット(TXRU: Transceiver unit)50に接続され、アンテナエレメント毎の位相シフタ51によって位相を制御し、アンテナエレメント52から送信することで送信信号に対して任意の方向にビームを向けることができる。典型的には、TXRUがアンテナポートとして定義されてよく、端末装置1においてはアンテナポートのみが定義されてよい。位相シフタ51を制御することで任意の方向に指向性を向けることができるため、基地局装置3は端末装置1に対して利得の高いビームを用いて通信することができる。

0097

以下、帯域部分(BWP, Bandwidth part)について説明する。BWPは、キャリアBWPとも称される。BWPは、下りリンクと上りリンクのそれぞれに設定されてよい。BWPは、共通リソースブロックの連続するサブセットから選択された連続する物理リソース集合として定義される。端末装置1は、ある時間に1つの下りリンクキャリアBWP(DL BWP)が活性化される4つまでのBWPを設定されうる。端末装置1は、ある時間に1つの上りリンクキャリアBWP(UL BWP)が活性化される4つまでのBWPを設定されうる。キャリアアグリゲーションの場合には、BWPは各サービングセルで設定されてもよい。このとき、あるサービングセルにおいてBWPが1つ設定されていることを、BWPが設定されていないと表現されてもよい。また、BWPが2つ以上設定さ
れていることをBWPが設定されていると表現されてもよい。

0098

<MAC entity動作>
活性化されたサービングセルにおいて、常に一つのアクティブな(活性化された)BWPがある。あるサービングセルに対するBWP切り替え(BWP switching)は、インアク
ティブな(非活性化された)BWPを活性化(activate)し、アクティブな(活性化された)BWPを非活性化(deactivate)するために使用される。あるサービングセルに対するBWP切り替え(BWP switching)は、下りリンク割り当てまたは上りリンクグラント
を示すPDCCHによって制御される。あるサービングセルに対するBWP切り替え(BWP switching)は、さらに、BWPインアクティブタイマー(BWP inactivity timer)や、RRCシグナリングによってや、ランダムアクセスプロシージャの開始時にMACエンティティ自身によって制御されてもよい。SpCell(PCellまたはPSCell)の追加または、SCellの活性化において、一つのBWPが、下りリンク割り当てまたは上りリンクグラントを示すPDCCHを受信することなしに第一にアクティブである。第一にアクティブなDL BWP(first active DL BWP)およびUL BWP(first active UL BWP)は、基地局装置3から端末装置1に送られるRRCメッセージで指定されるかもしれない。あるサービングセルに対するアクティブなBWPは、基地局装置3から端末装置1に送られるRRCまたはPDCCHで指定される。また、第一にアクティブなDL BWP(first active DL BWP)およびUL BWP(first active UL BWP)は、メッセージ4に含まれてもよい。アンペアードスペクトラム(Unpaired spectrum)(TDDバンドなど)では、DL BWPとUL BWPはペアされていて、BWP切り替えは、ULとDLに対して共通である。BWPが設定されているアクティベートされたサービングセルのそれぞれに対する、アクティブなBWPにおいて、端末装置1のMACエンティティは、ノーマル処理を適用する。ノーマル処理には、UL−SCHを送信する、RACHを送信する、PDCCHをモニタする、PUCCHを送信する、SRSを送信する、およびDL−SCHを受信することを含む。BWPが設定されているアクティベートされたサービングセルのそれぞれに対する、インアクティブなBWPにおいて、端末装置1のMACエンティティは、UL−SCHを送信しない、RACHを送信しない、PDCCHをモニタしない、PUCCHを送信しない、SRSを送信しない、およびDL−SCHを受信しない。あるサービングセルが非活性化された場合、アクティブなBWPは、存在しないようにしてもよい(例えば、アクティブなBWPは非活性化される)。

0099

<RRC動作>
RRCメッセージ(報知されるシステム情報や、専用RRCメッセージで送られる情報)に含まれるBWPインフォメーションエレメント(IE)は、BWPを設定するために使われる。基地局装置3から送信されたRRCメッセージは、端末装置1によって受信される。それぞれのサービングセルに対して、ネットワーク(基地局装置3など)は、少なくとも下りリンクのBWPと1つ(もしサービングセルが上りリンクの設定された場合など)または2つ(付録アップリンク(supplementary uplink)が使われる場合など)の上りリンクBWPを含む少なくとも初期BWP(initial BWP)を、端末装置1に対して、設定する。さらに、ネットワークは、追加の上りリンクBWPや下りリンクBWPをあるサービングセルに対して設定するかもしれない。BWP設定は、上りリンクパラメータと下りリンクパラメータに分けられる。また、BWP設定は、共通(common)パラメータと専用(dedicated)パラメータに分けられる。共通パラメータ(BWP上りリンク共通IEやBWP下りリンク共通IEなど)は、セル特有である。プライマリセルの初期BWPの共通パラメータは、システム情報でも提供される。他のすべてのサービングセルに対しては、ネットワークは専用信号で共通パラメータを提供する。BWPは、BWP IDで識別される。初期BWPは、BWP IDが0である。他のBWPのBWP IDは、1から4までの値を取る。

0100

端末装置1に対して上位層のパラメータinitialDownlinkBWPが設定(提供)されない場合、初期DL BWP(初期アクティブなDL BWP、initial active DL BWP)は、タイプ0PDCCHコモンサーチスペースのためのコントロールリソースセット(CORESET)でのPDCCH受信のために、連続的なPRBの位置と数、サブキャリア間隔、および、サイクリックプレフィックスによって定義されてもよい。該連続的なPRBの位置は、タイプ0PDCCHコモンサーチスペースのためのコントロールリソースセットのPRBの間で、最小インデックスのPRBから始まり、最大インデックスのPRBで終わる。端末装置1に対して上位層のパラメータinitialDownlinkBWPが設定(提供)されている場合、初期DL BWPは上位層のパラメータinitialDownlinkBWPによって示されてもよい。上位層のパラメータinitialDownlinkBWPは、SIB1(systemInformationBlockType1、ServingCellConfigCommonSIB)またはServingCellConfigCommonに含まれてもよい。インフォメーションエレメントServingCellConfigCommonSIBは、SIB1内で端末装置1に対するサービングセルのセル固有パラメータを設定するために使われる。

0101

即ち、端末装置1に対して上位層のパラメータinitialDownlinkBWPが設定(提供)されない場合、初期DL BWPのサイズは、タイプ0PDCCHコモンサーチスペースのためのコントロールリソースセット(CORESET#0)のリソースブロックの数であってもよい。端末装置1に対して上位層のパラメータinitialDownlinkBWPが設定(提供)されている場合、初期DL BWPのサイズは、上位層のパラメータinitialDownlinkBWPに含まれるlocationAndBandwidthによって与えられてもよい。上位層のパラメータlocationAndBandwidthは初期DL BWPの周波数領域の位置と帯域幅を示してもよい。

0102

前述のように、端末装置1に対して複数のDL BWPが設定されていてもよい。そして、端末装置1に対して設定されているDL BWPの内、上位層のパラメータdefaultDownlinkBWP−IdによりデフォルトDL BWPが設定されることができる。端末装置1に対して上位層のパラメータdefaultDownlinkBWP−Idが提供されない場合、デフォルトDL BWPは初期DL BWPである。

0103

端末装置1には、初期UL BWPがSIB1(systemInformationBlockType1)また
はinitialUplinkBWPによって提供されてもよい。インフォメーションエレメントinitialUplinkBWPは、初期UL BWPを設定するために使われる。SpCellまたはセカンダリセルでのオペレーションに対して、端末装置1には、上位層のパラメータinitialUplinkBWPによって初期UL BWP(初期アクティブなUL BWP)が設定(提供)されてもよい。端末装置1に対して補足的な上りリンクキャリア(supplementary UL carrier)が設定される場合、端末装置1には、上位層のパラメータsupplementaryUplinkに含まれるinitialUplinkBWPによって、補足的な上りリンクキャリアでの初期UL BWPが設定されてもよい。

0104

以下、本実施形態におけるコントロールリソースセット(CORESET)について説明する。

0105

コントロールリソースセット(CORESET, Control resource set)は下りリンク制御情
報をサーチするための時間および周波数リソースである。CORESETの設定情報には、CORESETの識別子(ControlResourceSetId、CORESET−ID)とCORESETの周波数リソースを特定する情報が含まれる。インフォメーションエレメントControlResourceSetId(CORESETの識別子)は、あるサービングセルにおけるコントロールリソースセットを特定するために使われる。CORESETの識別子は、あるサービングセルにおけるBWP間で使われる。CORESETの識別子は、サービングセルにおけるBWP間でユニークである。各BWPのCORESETの数は、初期CORESETを含めて、3に制限される。あるサービングセルにおいて、CORESETの識別子の値は、0から11までの値を取る。

0106

CORESETの識別子0(ControlResourceSetId 0)で特定されるコントロールリソースセットはCORESET#0と称する。CORESET#0は、MIBに含まれるpdcch−ConfigSIB1、または、ServingCellConfigCommonに含まれるPDCCH−ConfigCommonによって設定されてもよい。即ち、CORESET#0の設定情報は、MIBに含まれるpdcch−ConfigSIB1、または、ServingCellConfigCommonに含まれるPDCCH−ConfigCommonであってもよい。CORESET#0の設定情報は、PDCCH−ConfigSIB1またはPDCCH−ConfigCommonに含まれるcontrolResourceSetZeroによって設定されてもよい。つまり、インフォメーションエレメントcontrolResourceSetZeroは、初期DL BWPのCORESET#0(コモンCORESET)を示すために用いられる。pdcch−ConfigSIB1で示されるCORESETは、CORESET#0である。MIBまたは専用コンフィギュレーション内のインフォメーションエレメントpdcch−ConfigSIB1は、初期DL BWPを設定するために用いられる。CORESET#0に対するCORESETの設定情報pdcch−ConfigSIB1には、CORESETの識別子とCORESETの周波数リソース(例えば、連続的なリソースブロックの数)および時間リソース(連続的なシンボルの数)を明示的に特定する情報は含まれないが、CORESET#0に対するCORESETの周波数リソース(例えば、連続的なリソースブロックの数)および時間リソース(連続的なシンボルの数)は、pdcch−ConfigSIB1に含まれる情報によって暗示的に特定できる。インフォメーションエレメントPDCCH−ConfigCommonは、SIBで提供されるセル固有のPDCCHパラメータを設定するために用いられる。また、PDCCH−ConfigCommonはハンドオーバ、および、PSCellおよび/またはSCellの追加時にも提供されてもよい。CORESET#0の設定情報は、初期BWPの設定の中に含まれる。即ち、CORESET#0の設定情報は、初期BWP以外のBWPの設定の中に含まれなくてもよい。controlResourceSetZeroは、pdcch−ConfigSIB1の内4ビット(例えば、MSB 4ビット、最上位ビットの4ビット)に対応する。CORESET#0はタイプ0PDCCHコモンサーチスペースのためのコントロールリソースセットである。

0107

追加のコモンCORESET(additional common control resource set)の設定情報は、PDCCH−ConfigCommonに含まれるcommonControlResourceSetによって設定されてもよい。また、追加のコモンCORESETの設定情報は、システム情報および/またはページング手順のための追加のコモンCORESETを指定するために使用されてもよい。追加のコモンCORESETの設定情報は、ランダムアクセス手順に使われる追加のコモンCORESETを指定するために使用されてもよい。追加のコモンCORESETの設定情報は、各BWPの設定の中に含まれてもよい。commonControlResourceSetに示されるCORESETの識別子は0以外の値を取る。

0108

コモンCORESETは、ランダムアクセス手順に使われるCORESET(例えば、追加のコモンCORESET)であってもよい。また、本実施形態において、コモンCORESETには、CORESET#0および/または追加のコモンCORESETの設定
情報で設定されたCORESETが含まれてもよい。つまり、コモンCORESETはCORESET#0および/または追加のコモンCORESETを含んでもよい。CORESET#0はコモンCORESET#0と称してもよい。端末装置1、コモンCORESETが設定されているBWP以外のBWPにおいても、コモンCORESETの設定情報を参照(取得)してもよい。

0109

1つまたは複数のCORESETの設定情報は、PDCCH−Configによって設定されてもよい。インフォメーションエレメントPDCCH−Configは、あるBWPに対してUE固有のPDCCHパラメータ(例えば、CORSET、サーチスペースなど)を設定するために用いられる。PDCCH−Configは、各BWPの設定の中に含まれてもよい。

0110

即ち、本実施形態において、MIBで示されるコモンCORESETの設定情報はpdcch−ConfigSIB1であり、PDCCH−ConfigCommonで示されるコモンCORESETの設定情報はcontrolResourceSetZeroであり、PDCCH−ConfigCommonで示されるコモンCORESET(追加のコモンCORESET)の設定情報はcommonControlResourceSetである。また、PDCCH−Configで示される1つまたは複数のCORESET(UE specifically configured Control Resource Sets、UE固有CORESET)の設定情報はcontrolResourceSetToAddModListである。

0111

サーチスペースはPDCCH候補(PDCCH candidates)をサーチするために定義される。サーチスペースの設定情報に含まれるsearchSpaceTypeは、該サーチスペースがコモンサーチスペース(Common Search Space, CSS)であるかUE固有サーチスペース(UE-specific Search Space, USS)であるかを示す。UE固有サーチスペースは、少なくとも、端末装置1がセットしているC−RNTIの値から導き出される。すなわち、UE固有サーチスペースは、端末装置1毎に個別に導き出される。コモンサーチスペースは、複数の端末装置1の間で共通のサーチスペースであり、予め定められたインデックスのCCE(Control Channel Element)から構成される。CCEは、複数のリソースエレメントから構成される。サーチスペースの設定情報には、該サーチスペースでモニタされるDCIフォーマットの情報が含まれる。

0112

サーチスペースの設定情報には、CORESETの設定情報で特定されるCORESETの識別子が含まれる。サーチスペースの設定情報の中に含まれるCORESETの識別子で特定されるCORESETは、該サーチスペースと関連付けられる。言い換えると、該サーチスペースに関連付けられるCORESETは、該サーチスペースに含まれるCORESETの識別子で特定するCORESETである。該サーチスペースの設定情報で示されるDCIフォーマットは、関連付けられるCORESETでモニタされる。各サーチスペースは一つのCORESETに関連付けられる。例えば、ランダムアクセス手順のためのサーチスペースの設定情報はra−SearchSpaceによって設定されてもよい。即ち、ra−SearchSpaceと関連付けられるCORESETでRA−RNTIまたはTC−RNTIによってスクランブルされるCRCが付加されたDCIフォーマットがモニタされる。

0113

端末装置1は、PDCCHをモニタリングするように設定されているそれぞれのアクティブなサービングセルに配置される、1つまたは複数のCORESETにおいて、PDCCHの候補のセットをモニタする。PDCCHの候補のセットは、1つまたは複数のサーチスペースセットに対応している。モニタリングすることは、モニタされる1つまたは複数のDCIフォーマットに応じてそれぞれのPDCCHの候補をデコードすることを意味する。端末装置1がモニタするPDCCHの候補のセットは、PDCCHサーチスペースセット(PDCCH search space sets)で定義される。一つのサーチスペースセットは、コモンサーチスペースセットまたはUE固有サーチスペースセットである。上記では、サーチスペースセットをサーチスペース、コモンサーチスペースセットをコモンサーチスペース、UE固有サーチスペースセットをUE固有サーチスペースと称している。端末装置1は、1つまたは複数の以下のサーチスペースセットでPDCCH候補をモニタする。
- タイプ0PDCCHコモンサーチスペースセット(a Type0-PDCCH common search
space set、タイプ0コモンサーチスペース): このサーチスペースセットは、上位層
のパラメータである、MIBで示されるpdcch−ConfigSIB1またはPDCCH−ConfigCommonで示されるサーチスペースSIB1(searchSpaceSIB1
)またはPDCCH−ConfigCommonに含まれるサーチスペースゼロ(searchSpaceZero)によって設定される。このサーチスペースは、プライマリセルにおけるSI−RNRIでスクランブルされたCRCのDCIフォーマットのモニタリングのためのものである。
- タイプ0APDCCHコモンサーチスペースセット(a Type0A-PDCCH common search space set、タイプ0Aコモンサーチスペース): このサーチスペースセットは、上位層のパラメータである、PDCCH−ConfigCommonで示されるサーチスペース(searchSpaceOtherSystemInformation)によって設定される。このサーチスペースは、プライマリセルにおけるSI−RNRIでスクランブルされたCRCのDCIフォーマットのモニタリングのためのものである。
- タイプ1PDCCHコモンサーチスペースセット(a Type1-PDCCH common search
space set、タイプ1コモンサーチスペース): このサーチスペースセットは、上位層
のパラメータである、PDCCH−ConfigCommonで示されるランダムアクセス手順のためのサーチスペース(ra-SearchSpace)によって設定される。このサーチスペースは、プライマリセルにおけるRA−RNRIまたはTC−RNTIでスクランブルされたCRCのDCIフォーマットのモニタリングのためのものである。タイプ1PDCCHコモンサーチスペースセットはランダムアクセス手順のためのサーチスペースセットである。
- タイプ2PDCCHコモンサーチスペースセット(a Type2-PDCCH common search
space set、タイプ2コモンサーチスペース): このサーチスペースセットは、上位層
のパラメータである、PDCCH−ConfigCommonで示されるページング手順のためのサーチスペース(pagingSearchSpace)によって設定される。このサーチスペー
スは、プライマリセルにおけるP−RNTIでスクランブルされたCRCのDCIフォーマットのモニタリングのためのものである。
- タイプ3PDCCHコモンサーチスペースセット(a Type3-PDCCH common search
space set、タイプ3コモンサーチスペース): このサーチスペースセットは、上位層
のパラメータである、PDCCH−Configで示されるサーチスペースタイプがコモンのサーチスペース(SearchSpace)によって設定される。このサーチスペースは、IN
T−RNTI、SFI−RNTI、TPC−PUSCH−RNTI、TPC−PUCCH−RNTI、またはTPC−SRS−RNTIでスクランブルされたCRCのDCIフォーマットのモニタリングのためのものである。プライマリライセルに対しては、C−RNTI、CS−RNTI(s)、またはMCS−C−RNTIでスクランブルされたCRCのDCIフォーマットのモニタリングのためのものである。
- UE固有サーチスペースセット(a UE-specific search space set): このサーチスペースセットは、上位層のパラメータである、PDCCH−Configで示されるサーチスペースタイプがUE固有のサーチスペース(SearchSpace)によって設定される
。このサーチスペースは、C−RNTI、CS−RNTI(s)、またはMCS−C−RNTIでスクランブルされたCRCのDCIフォーマットのモニタリングのためのものである。

0114

もし、端末装置1が、対応する上位層パラメータ(searchSpaceZero、searchSpaceSIB1
、searchSpaceOtherSystemInformation、 pagingSearchSpace, ra-SearchSpaceなど) によって、1つまたは複数のサーチスペースセットを提供されて、端末装置1が、C−RNTIまたはCS−RNTIを提供されている場合、端末装置1は、C−RNTIまたはCS−RNTIを持つDCIformat 0_0とDCI format 1_0のためのPDCCH候補を、その1つまたは複数のサーチスペースセットでモニタしてもよい。

0115

BWPの設定情報はDL BWPの設定情報とUL BWPの設定情報に分けられる。BWPの設定情報には、インフォメーションエレメントbwp−Id(BWPの識別子)が含まれる。DL BWPの設定情報に含まれるBWPの識別子は、あるサービングセルにおけるDL BWPを特定(参照)するために使われる。UL BWPの設定情報に含まれるBWPの識別子は、あるサービングセルにおけるUL BWPを特定(参照)するために使われる。BWPの識別子はDL BWPとUL BWPのそれぞれに対して付与される。例えば、DL BWPに対応するBWPの識別子はDL BWPインデックス(DL BWP index)と称してもよい。UL BWPに対応するBWPの識別子はUL BWP インデックス(UL BWP index)と称してもよい。初期DL BWPは、DL BWPの識別子0によって参照される。初期UL BWPは、UL BWPの識別子0によって参照される。他のDL BWPまたは他のUL BWPのそれぞれは、BWPの識別子 1からmaxNrofBWPsまでに参照されてもよい。つまり、0にセットしたBWPの識別子(bwp−Id=0)は、初期BWPに関連つけられ、他のBWPに使われることができない。maxNrofBWPsはサービングセルあたりのBWPの最大数であり、4である。即ち、他のBWPの識別子の値は、1から4までの値を取る。他の上位層の設定情報は、BWPの識別子を利用して特定のBWPに関連付けられる。DL BWPとUL BWPが同じBWPの識別子を有することは、DL BWPとUL BWPがペアされていることを意味してもよい。

0116

端末装置1は、1つのプライマリセルと15までのセカンダリセルが設定されてよい。

0117

以下では、PDSCHを受信する手順について説明する。

0118

端末装置1は、DCIフォーマット1_0、DCIフォーマット1_1またはDCIフォーマット1_2を含むPDCCHの検出によって、対応するPDSCHをデコード(受信)してもよい。対応するPDSCHは、そのDCIフォーマット(DCI)によってスケジュールされる(示される)。そのスケジュールされるPDSCHの開始位置(開始シンボル)をSと称する。PDSCHの開始シンボルSはあるスロット内でPDSCHが送信(マップ)される最初のシンボルであってもよい。開始シンボルSはスロットの始まりに対応する。例えば、Sの値が0である場合、端末装置1は、あるスロット内の1番目のシンボルからPDSCHを受信してもよい。また、例えば、Sの値が2である場合、端末装置1は、あるスロットの3番目のシンボルからPDSCHを受信してもよい。そのスケジュールされるPDSCHの連続的な(Consecutive)シンボルの数をLと称する。連続的なシンボルの数Lは開始シンボルSから数える。PDSCHに対して割り当てられたSとLの決定は後述する。

0119

PDSCHマッピングのタイプはPDSCHマッピングタイプAとPDSCHマッピングタイプBを有する。PDSCHマッピングタイプAでは、Sは0から3までの値を取る。Lは3から14までの値を取る。ただし、SとLの和は3から14までの値を取る。PDSCHマッピングタイプBでは、Sは0から12までの値を取る。Lは{2、4、7}から1つの値を取る。ただし、SとLの和は2から14までの値を取る。

0120

PDSCHためのDMRSシンボルの位置は、PDSCHマッピングのタイプに依存す
る。PDSCHための最初のDMRSシンボル(firstDM-RS symbol)の位置は、PDSCHマッピングのタイプに依存する。PDSCHマッピングタイプAでは、最初のDMRSシンボルの位置は、上位層のパラメータdmrs−TypeA−Positionに示されてもよい。つまり、上位層のパラメータdmrs−TypeA−PositionはPDSCHまたはPUSCHのための最初のDMRSの位置を示すために用いられる。dmrs−TypeA−Positionは、‘pos2’または‘pos3’のいずれかにセットされてもよい。例えば、dmrs−TypeA−Positionが‘pos2’にセットされている場合、PDSCHための最初のDMRSシンボルの位置は、スロット内の3番目のシンボルであってもよい。例えば、dmrs−TypeA−Positionが‘pos3’にセットされている場合、PDSCHための最初のDMRSシンボルの位置は、スロット内の4番目のシンボルであってもよい。ここで、Sは、dmrs−TypeA−Positionが‘pos3’にセットされている場合のみに、3の値をとれる。つまり、dmrs−TypeA−Positionが‘pos2’にセットされている場合、Sは0から2までの値をとる。PDSCHマッピングタイプBでは、最初のDMRSシンボルの位置は、割り当てられるPDSCHの最初のシンボルである。

0121

図7は本実施形態に係るPDSCHマッピングタイプの一例を示す図である。図7(A)はPDSCHマッピングタイプAの一例を示す図である。図7(A)において、割り当てられるPDSCHのSは3である。割り当てられるPDSCHのLは7である。図7(A)において、PDSCHための最初のDMRSシンボルの位置は、スロット内の4番目のシンボルである。即ち、dmrs−TypeA−Positionが‘pos3’にセットされている。図7(B)はPDSCHマッピングタイプAの一例を示す図である。図7(B)において、割り当てられるPDSCHのSは4である。割り当てられるPDSCHのLは4である。図7(B)において、PDSCHための最初のDMRSシンボルの位置は、PDSCHが割り当てられる最初のシンボルである。

0122

以下、PDSCH時間領域リソース割り当ての特定方法について説明する。

0123

基地局装置3は、DCIによって端末装置1にPDSCHを受信させるようにスケジュールしてもよい。端末装置1は、自装置宛てのDCIの検出によってPDSCHを受信してもよい。端末装置1は、PDSCH時間領域リソース割り当てを特定する時に、最初にPDSCHに適用するリソース割り当てテーブルを決定する。リソース割り当てテーブルは、1つまたは複数のPDSCH時間領域リソース割り当てコンフィギュレーションを含む。端末装置1は、PDSCHをスケジュールするDCIに含まれる‘Time domain resource assignment’フィールドに示される値に基づき、決定したリソース割り当てテーブル内の1つのPDSCH時間領域リソース割り当て設定を選んでもよい。つまり、基地局装置3は、端末装置1に対するPDSCHのリソース割り当てを決定し、決定したリソース割り当てに基づく値の‘Time domain resource assignment’フィールドを生成し、その‘Time domain resource assignment’フィールドを含むDCIを端末装置1に送信する。端末装置1は、‘Time domain resource assignment’フィールドの値に基づき、PDSCHの時間方向のリソース割り当てを特定する。

0124

図10は、PDSCH時間領域リソース割り当てに適用するリソース割り当てテーブルを定義する図である。端末装置1は、図10に示されるテーブルに基づいて、PDSCH時間領域リソース割り当てに適用するリソース割り当てテーブルを決定してもよい。リソース割り当てテーブルは、1つまたは複数のPDSCH時間領域リソース割り当ての設定(configuration)を含む。本実施形態において、リソース割り当てテーブルは、(I)事前に定義されるリソース割り当てテーブル、および、(II)上位層のRRC信号から設定されるリソース割り当てテーブルと分類される。事前に定義されるリソース割り当てテーブルは、例えば、デフォルトPDSCH時間領域リソース割り当てA、デフォルトPDSCH時間領域リソース割り当てB、および、デフォルトPDSCH時間領域リソース割り当てCとして定義される。また、デフォルトPDSCH時間領域リソース割り当てAとは異なるデフォルトPDSCH時間領域リソース割り当てDが定義されてもよい。以下では、それぞれ、デフォルトPDSCH時間領域リソース割り当てAをデフォルトテーブルA、デフォルトPDSCH時間領域リソース割り当てBをデフォルトテーブルB、デフォルトPDSCH時間領域リソース割り当てCをデフォルトテーブルC、デフォルトPDSCH時間領域リソース割り当てDをデフォルトテーブルDと称する。

0125

図13は本実施形態に係るデフォルトテーブルAの一例を示す図である。図14は本実施形態に係るデフォルトテーブルBの一例を示す図である。図15は本実施形態に係るデフォルトテーブルCの一例を示す図である。図13の例では、デフォルトテーブルAの行数は16であり、各行はPDSCH時間領域リソース割り当ての設定を示す。図13において、各行は、PDSCHマッピングタイプ、DCIを含むPDCCHとそのPDSCHとの間のスロットオフセットK0、スロット内のPDSCHのスタートシンボルS、および、連続的な割当シンボル数Lを定義する。

0126

上位層のRRC信号で設定されるリソース割り当てテーブルは、上位層の信号pdsch−TimeDomainAllocationListによって与えられる。pdsch−TimeDomainAllocationListは1つまたは複数のインフォメーションエレメントPDSCH−TimeDomainResourceAllocationを含む。PDSCH−TimeDomainResourceAllocationは、PDSCH時間領域リソース割り当ての設定を示す。PDSCH−TimeDomainResourceAllocationは、DCIを含むPDCCHとPDSCHの間の時間領域の関係を設定するために用いられてよい。つまり、pdsch−TimeDomainAllocationListは1つまたは複数のインフォメーションエレメントを含むリストである。1つのPDSCH−TimeDomainResourceAllocationを1つのエントリ(または1つの行)と称してもよい。例えば、pdsch−TimeDomainAllocationListは最大16個のエントリを含み、DCIに含まれる4ビットのフィールドによっていずれか1つのエントリが用いられてよい。ただし、pdsch−TimeDomainAllocationListに含まれるエントリの数は異なる数であってもよく、関連してDCIに含まれるフィールドのビット数が異なる値であってもよい。pdsch−TimeDomainAllocationListの各エントリにおいて、K0、mappingType、および/または、startSymbolAndLengthが示されてよい。K0はDCIを含むPDCCHとそのPDSCHとの間のスロットオフセットを示す。PDSCH−TimeDomainResourceAllocationによってK0を示されない場合、端末装置1はK0の値が所定の値(例えば0)であると想定してもよい。mappingTypeは、対応するPDSCHのマッピングタイプがPDSCHマッピングタイプAであるか、またはPDSCHマッピングタイプBであるかを示す。startSymbolAndLengthは対応するPDSCHのスタートシンボルS、および、連続的な割り当てシンボル数Lの有効な組み合わせを与えるインデックスである。startSymbolAndLengthをスタート位置と長さのインジケータ(SLIV:start and length indicator)と称してもよい。SLIVが適用される場合は、デフォルトテーブルを用いる場合と異なり、対応するPDSCHの開始シンボルSと連続的なシンボル数Lは、SLIVに基づいて与えられる。基地局装置3は、PDSCHの時間領域リソース割り当てがスロット境界を超えないようにSLIVの値をセットしてもよい。スロットオフセットK0とSLIVについては後述する。

0127

上位層の信号pdsch−TimeDomainAllocationListはセル固有のRRCパラメータpdsch−ConfigCommonおよび/または端末装置1(UE)固有のRRCパラメータpdsch−Configに含まれてもよい。pdsch−ConfigCommonはあるBWPに対するPDSCHのためのセル固有パラメータを設定するために用いられる。pdsch−ConfigはあるBWPに対するPDSCHのための端末装置1(UE)固有パラメータを設定するために用いられる。

0128

端末装置1は、第1のPDSCHを受信する場合と第2のPDSCHを受信する場合とで、PDSCH時間領域リソース割り当てに対して、異なるリソース割り当てテーブルを適用してもよい。基地局装置3は、第1のPDSCHを送信する場合と第2のPDSCHを送信する場合とで、PDSCH時間領域リソース割り当てに対して、異なるリソース割り当てテーブルを適用してもよい。

0129

第1のPDSCHと第2のPDSCHは異なるサービスのデータを伝送するPDSCHであってよい。例えば、第1のPDSCHはeMBBのデータを伝送するPDSCHであり、第2のPDSCHはURLLCのデータを伝送するPDSCHであってもよい。第1のPDSCHは、第1のDCIによってスケジュールされるPDSCHであってよい。第2のPDSCHは、第2のDCIによってスケジュールされるPDSCHであってよい。第1のDCIと第2のDCIは異なるサービスのデータをスケジュールするDCIであってよい。例えば、第1のDCIはeMBBのデータを送信するPDSCHをスケジュールするDCIであり、第2のDCIはURLLCのデータを送信するPDSCHをスケジュールするDCIであってもよい。

0130

第1のDCIと第2のDCIは、異なるRNTIでスクランブルされたCRCを付加されたDCIであってもよい。例えば、第1のDCIは第1の値の範囲であるC−RNTIでスクランブルされたCRCを付加されたDCIであり、第2のDCIは第1の値の範囲とは異なる第2の値の範囲であるC−RNTIでスクランブルされたCRCを付加されたDCIであってもよい。例えば、第1のDCIは第3の値の範囲である任意の種類のRNTIでスクランブルされたCRCを付加されたDCIであり、第2のDCIは第3の値の範囲とは異なる第4の値の範囲である任意の種類のRNTIでスクランブルされたCRCを付加されたDCIであってもよい。例えば、第1のDCIはC−RNTI、MCS−C−RNTI,CS−RNTI、SI−RNTI、RA−RNTI、TC−RNTIおよび/またはP−RNTIでスクランブルされたCRCを付加されたDCIであり、第2のDCIはUC−RNTIでスクランブルされたCRCを付加されたDCIであってもよい。ただし、UC−RNTIはC−RNTI、MCS−C−RNTI,CS−RNTI、SI−RNTI、RA−RNTI、TC−RNTIおよびP−RNTIで利用可能な値とは異なる値を用いるRNTIであってよい。ただし、UC−RNTIは1つまたは複数のスロットにおける所定のサービスのデータのPDSCHまたはPUSCHを制御するために用いられるRNTIであってよい。

0131

第1のDCIと第2のDCIは、異なるDCIフォーマットを用いたDCIであってもよい。例えば、第1のDCIはDCIフォーマット1_1を用いたDCIであり、第2のDCIはDCIフォーマット1_2を用いたDCIであってもよい。

0132

第1のDCIと第2のDCIは、異なるサイズのDCIフォーマットを用いたDCIであってもよい。例えば、第1のDCIは第1のサイズのDCIフォーマットを用いたDCIであり、第2のDCIは第1のサイズとは異なる第2のサイズのDCIフォーマットを用いたDCIであってもよい。

0133

第1のDCIと第2のDCIは、それぞれのDCIフォーマット内の所定のフィールド
で、対応するPDSCHのデータに適用されるサービスが示されてもよい。例えば、第1のDCIのDCIフォーマット内のフィールドで、対応するPDSCHがeMBBのデータを伝送することが特定されてもよい。例えば、第2のDCIのDCIフォーマット内のフィールドで、対応するPDSCHがURLLCのデータを伝送することが特定されてもよい。

0134

第1のDCIと第2のDCIは、異なるサーチスペースおよび/または異なるCORESETで伝送されるDCIであってもよい。

0135

第1のDCIと第2のDCIは、異なるコードブックのPDSCHをスケジュールするDCIであってもよい。

0136

上位層のRRC信号で設定されるリソース割り当てテーブルは、上位層の信号pdsch−TimeDomainAllocationListとは異なる上位層の信号(インフォメーションエレメントあるいはRRCパラメータであってよい)で与えられてもよい。例えば、上位層の信号pdsch−TimeDomainAllocationList2によって与えられてもよい。基地局装置3は、上位層の信号でpdsch−TimeDomainAllocationListおよび/またはpdsch−TimeDomainAllocationList2を通知してもよい。端末装置1は、上位層の信号でpdsch−TimeDomainAllocationListおよび/またはpdsch−TimeDomainAllocationList2を受信してもよい。

0137

pdsch−TimeDomainAllocationList2はpdsch−TimeDomainAllocationListと同様に、最大16個のエントリを含み、DCIに含まれる4ビットのフィールドによっていずれか1つのエントリが用いられてよい。pdsch−TimeDomainAllocationList2に含まれる各エントリにおいて、K0、mappingType、および/または、startSymbolAndLengthが示されてよい。pdsch−TimeDomainAllocationList2の各エントリにおけるK0、mappingType、および/または、startSymbolAndLengthにおいて利用可能な値は、pdsch−TimeDomainAllocationListにおいて利用可能な値と異なってもよい。例えば、pdsch−TimeDomainAllocationListにおいて利用可能なK0の値は0〜32であり、pdsch−TimeDomainAllocationList2において利用可能なK0の値は0〜4であってもよい。例えば、pdsch−TimeDomainAllocationListにおいて利用可能なmappinngTypeはマッピングタイプAとマッピングタイプBであり、pdsch−TimeDomainAllocationList2において利用可能なmappinngTypeはマッピングタイプBのみであってもよい。例えば、pdsch−TimeDomainAllocationList2ではmappinngTypeが示されなくてもよい。

0138

端末装置1は、上位層の信号pdsch−Configにpdsch−TimeDomainAllocationListが含まれており、かつ第1のDCIでPDSCHがスケジュールされている場合に、PDSCHのリソース割り当てテーブルにpdsch−Configに含まれるpdsch−TimeDomainAllocationListを適用してもよい。端末装置1は、上位層の信号pdsch−Configにpdsch−TimeDomainAllocationList2が含まれており、かつ第2のDCIでPDSCHがスケジュールされている場合に、PDSCHのリソース割り当てテーブルにpdsch−Configに含まれるpdsch−TimeDomainAllocationList2を適用してもよい。

0139

端末装置1は、上位層の信号pdsch−Configおよびpdsch−ConfigCommonにpdsch−TimeDomainAllocationListが含まれておらず、かつ第1のDCIでPDSCHがスケジュールされている場合に、PDSCHのリソース割り当てテーブルにデフォルトテーブルAを適用してもよい。端末装置1は、上位層の信号pdsch−Configおよびpdsch−ConfigCommonにpdsch−TimeDomainAllocationList2が含まれておらず、かつ第2のDCIでPDSCHがスケジュールされている場合に、PDSCHのリソース割り当てテーブルにデフォルトテーブルDを適用してもよい。端末装置1は、上位層の信号でpdsch−TimeDomainAllocationListおよび/またはpdsch−TimeDomainAllocationList2が設定されていない場合に、第1のDCIと第2のDCIで異なるデフォルトテーブルを用いてもよい。端末装置1は、上位層の信号でpdsch−TimeDomainAllocationListおよび/またはpdsch−TimeDomainAllocationList2が設定されていない場合に、第1のDCIと第2のDCIで同一のデフォルトテーブルを用いてもよい。

0140

図16は、SLIVを算出する一例を示す図である。

0141

図16において、14は1つのスロットに含まれるシンボルの数である。図16は、NCP(Normal Cyclic Prefix)の場合にSLIVを算出する一例を示す。SLIVの値は、スロットに含まれるシンボルの数、開始シンボルS、および、連続的なシンボル数Lに基づいて、算出される。ここで、Lの値は1以上であり、(14−S)を超えない。ECPでSLIVを算出する場合には、図16における値7と14には代わりに6と12が使われる。

0142

以下、スロットオフセットK0について説明する。

0143

前述のように、サブキャリア間隔設定μにおいて、スロットは、サブフレーム内で0からN^{subframe,μ}_{slot}−1まで昇順に数えられ、フレーム内で0からN^{frame,μ}_{slot}−1まで昇順に数えられる。K0はPDSCHのサブキャリア間隔に基づくスロットの数である。K0は0から32までの値を取り得る。あるサブフレームまたはフレームにおいて、スロットの番号は0からに昇順に数えられる。サブキャリア間隔設定15kHzのスロット番号nは、サブキャリア間隔設定30kHzのスロット番号2nと2n+1に対応する。

0144

端末装置1がPDSCHをスケジュールするDCIを検出した場合に、そのPDSCHに割り当てられるスロットはfloor(n*2μPDSCH/2μPDCCH)+K0によって与えられる。関数floor(A)は、Aを上回らない最大の整数を出力する。nは、PDSCHをスケジュールするPDCCHが検出されたスロットである。μPDSCHはPDSCHに対するサブキャリア間隔設定である。μPDCCHはPDCCHに対するサブキャリア間隔設定である。

0145

端末装置1は、図10に示されるように、複数の要素に基づいてPDSCH時間領域リソース割り当てに適用するリソース割り当てテーブルを決定してもよい。端末装置1は、以下の要素(A)から要素(F)の一部または全部に少なくとも基づいて、DCIによってスケジュールされるPDSCHに適用するリソース割り当てテーブルを決定してもよい。
要素(A):DCIに付加されるCRCをスクランブルするRNTIのタイプ
要素(B):DCIが検出されるサーチスペースのタイプ
要素(C):そのサーチスペースと関連付けられるCORESETがCORESET#0であるかどうか
要素(D):pdsch−ConfigCommonがpdsch−TimeDomainAllocationListを含むかどうか
要素(E):pdsch−Configがpdsch−TimeDomainAllocationListを含むかどうか
要素(F):SS/PBCHとCORESET多重パターン

0146

要素(A)において、DCIに付加されるCRCをスクランブルするRNTIのタイプは、SI−RNTI、RA−RNTI、TC−RNTI、P−RNTI、C−RNTI、MCS−C−RNTI、または、CS−RNTIのうち何れかである。

0147

要素(B)において、DCIが検出されるサーチスペースのタイプは、コモンサーチスペース、または、UE固有サーチスペースである。コモンサーチスペースは、タイプ0コモンサーチスペース、タイプ1コモンサーチスペース、タイプ2コモンサーチスペースを含む。

0148

例Aとして、端末装置1は、CORESET#0に関連付けられる任意のコモンサーチスペースにおいてDCIを検出してもよい。検出したDCIは、C−RNTI、MCS−C−RNTI、または、CS−RNTIのうち、何れかによってスクランブルされるCRCが付加される。そして、端末装置1は、そのDCIによってスケジュールされるPDSCHに適用するリソース割り当てテーブルを決定してもよい。端末装置1に対してpdsch−ConfigCommonがpdsch−TimeDomainAllocationListを含む場合、端末装置1は、上位層のRRC信号から設定されるリソース割り当てテーブルを決定してもよい。そのリソース割り当てテーブルは、pdsch−ConfigCommonに含まれるpdsch−TimeDomainAllocationListによって与えられる。また、端末装置1に対してpdsch−ConfigCommonがpdsch−TimeDomainAllocationListを含まない場合、端末装置1は、デフォルトテーブルAを決定してもよい。つまり、端末装置1は、PDSCH時間領域リソース割り当てのコンフィギュレーションを示すデフォルトテーブルAを用いて、PDSCH時間領域リソース割り当ての決定に適用してもよい。

0149

例Bとして、端末装置1は、CORESET#0に関連付けられない任意のコモンサーチスペースにおいてDCIを検出してもよい。検出したDCIは、C−RNTI、MCS−C−RNTI、または、CS−RNTIの内、何れかによってスクランブルされるCRCが付加される。そして、端末装置1は、そのDCIによってスケジュールされるPDSCHに適用するリソース割り当てテーブルを決定してもよい。端末装置1に対してpdsch−Configがpdsch−TimeDomainAllocationListを含む場合、端末装置1は、PDSCH時間領域リソース割り当てに適用するリソース割り当てテーブルを、pdsch−Configで提供されるpdsch−TimeDomainAllocationListから与えられるリソース割り当てテーブルに決定してもよい。つまり、pdsch−Configがpdsch−TimeDomainAllocationListを含む場合、端末装置1は、pdsch−ConfigCommonがpdsch−TimeDomainAllocationListを含むか含まないかと関わらず、pdsch−Configで提供されるpdsch−TimeDomainAllocationListを用いて、PDSCH時間領域リソース割り当ての決定に適用してもよい。また、pdsch−Configがpdsch−TimeDomainAllocationListを含んでおらず、且つ、pdsch−ConfigCommonがpdsch−TimeDomainAllocationListを含む場合、端末装置1は、PDSCH時間領域リソース割り当てに適用するリソース割り当て
テーブルを、pdsch−ConfigCommonで提供されるpdsch−TimeDomainAllocationListから与えられるリソース割り当てテーブルに決定してもよい。つまり、端末装置1は、pdsch−ConfigCommonで提供されるpdsch−TimeDomainAllocationListを用いて、PDSCH時間領域リソース割り当ての決定に適用する。また、pdsch−Configがpdsch−TimeDomainAllocationListを含んでおらず、且つ、pdsch−ConfigCommonがpdsch−TimeDomainAllocationListを含まない場合、端末装置1は、PDSCH時間領域リソース割り当てに適用するリソース割り当てテーブルをデフォルトテーブルAに決定してもよい。

0150

例Cとして、端末装置1は、UE固有サーチスペースにおいてDCIを検出してもよい。検出したDCIは、C−RNTI、MCS−C−RNTI、または、CS−RNTIの内、何れかによってスクランブルされるCRCが付加される。そして、端末装置1は、そのDCIによってスケジュールされるPDSCHに適用するリソース割り当てテーブルを決定してもよい。端末装置1に対してpdsch−Configがpdsch−TimeDomainAllocationListを含む場合、端末装置1は、PDSCH時間領域リソース割り当てに適用するリソース割り当てテーブルを、pdsch−Configで提供されるpdsch−TimeDomainAllocationListから与えられるリソース割り当てテーブルに決定してもよい。つまり、pdsch−Configがpdsch−TimeDomainAllocationListを含む場合、端末装置1は、pdsch−ConfigCommonがpdsch−TimeDomainAllocationListを含むか含まないかと関わらず、pdsch−Configで提供されるpdsch−TimeDomainAllocationListを用いて、PDSCH時間領域リソース割り当ての決定に適用してもよい。また、pdsch−Configがpdsch−TimeDomainAllocationListを含んでおらず、且つ、pdsch−ConfigCommonがpdsch−TimeDomainAllocationListを含む場合、端末装置1は、PDSCH時間領域リソース割り当てに適用するリソース割り当てテーブルを、pdsch−ConfigCommonで提供されるpdsch−TimeDomainAllocationListから与えられるリソース割り当てテーブルに決定してもよい。つまり、端末装置1は、pdsch−ConfigCommonで提供されるpdsch−TimeDomainAllocationListを用いて、PDSCH時間領域リソース割り当ての決定に適用する。また、pdsch−Configがpdsch−TimeDomainAllocationListを含んでおらず、且つ、pdsch−ConfigCommonがpdsch−TimeDomainAllocationListを含まない場合、端末装置1は、PDSCH時間領域リソース割り当てに適用するリソース割り当てテーブルをデフォルトテーブルAに決定してもよい。

0151

例Bと例Cからみると、UE固有サーチスペースにおいて検出されるPDSCHに適用するリソース割り当てテーブルの決定方法は、CORESET#0に関連付けられない任意のコモンサーチスペースにおいて検出されるPDSCHに適用するリソース割り当てテーブルの決定方法と同様である。

0152

図11は、本実施形態に係るPDSCHに適用するリソース割り当てテーブルの決定法を示すテーブルの一例である。端末装置1は、図10の最後の行(CORESET#0に関連付けられない任意のコモンサーチスペースまたはUE固有サーチスペースにおいてDCIを検出し、かつRNTIが所定のタイプのRNTIである場合)において図11のようにリソース割り当てケーブルを決定してもよい。端末装置1は、要素(A)から要素(F)の一部または全部に加えて、下記の要素(G)から要素(I)の少なくとも一部に基づいて、DCIによってスケジュールされるPDSCHに適用するリソース割り当てテーブルを決定してもよい。
要素(G):DCIが上記の第1のDCI(1st DCI)であるか第2のDCI(2nd DCI)であるか
要素(H):pdsch−ConfigCommonがpdsch−TimeDomainAllocationList2を含むかどうか
要素(I):pdsch−Configがpdsch−TimeDomainAllocationList2を含むかどうか

0153

ただし、第1のDCIの場合と第2のDCIの場合とで同一のデフォルトテーブル(例えばデフォルトテーブルA)が用いられてもよい。ただし、pdsch−TimeDomainAllocationList2は、pdsch−ConfigCommonには含まれないパラメータでありpdsch−Configにのみ含まれるパラメータであってもよい。

0154

図11に示すテーブルでは、端末装置1および/または基地局装置3は、要素(A)〜要素(I)に基づいてPDSCHに適用するリソース割り当てテーブルをデフォルトテーブルA、デフォルトテーブルD、pdsch−ConfigCommonに含まれるpdsch−TimeDomainAllocationList、pdsch−Configに含まれるpdsch−TimeDomainAllocationList、pdsch−ConfigCommonに含まれるpdsch−TimeDomainAllocationList2およびpdsch−Configに含まれるpdsch−TimeDomainAllocationList2の中から決定する。
図12は、本実施形態に係るPDSCHに適用するリソース割り当てテーブルの決定法を示すテーブルの別の一例である。図12に示すテーブルでは、端末装置1および/または基地局装置3は、要素(A)〜要素(G)と要素(I)に基づいてPDSCHに適用するリソース割り当てテーブルをデフォルトテーブルA、pdsch−ConfigCommonに含まれるpdsch−TimeDomainAllocationList、pdsch−Configに含まれるpdsch−TimeDomainAllocationListおよびpdsch−Configに含まれるpdsch−TimeDomainAllocationList2の中から決定する。図12に示すテーブルの例では、DCIが第2のDCIであり、pdsch−Configにpdsch−TimeDomainAllocationList2が含まれず、pdsch−ConfigCommonにpdsch−TimeDomainAllocationListが含まれる場合には、PDSCHに適用するリソース割り当てテーブルはpdsch−ConfigCommonに含まれるpdsch−TimeDomainAllocationListである。ただし、DCIが第2のDCIであり、pdsch−Configにpdsch−TimeDomainAllocationList2が含まれない場合には、PDSCHに適用するリソース割り当てテーブルはデフォルトテーブルAまたはデフォルトテーブルDであってもよい。

0155

続いて、端末装置1は、そのPDSCHをスケジュールするDCIに含まれる‘Time domain resource assignment’フィールドに示される値に基づき、決定したリソース割り当てテーブル内の1つのPDSCH時間領域リソース割り当てコンフィギュレーションを選んでもよい。例えば、PDSCH時間領域リソース割り当てに適用するリソース割り当てテーブルがデフォルトテーブルAである場合、‘Time domain resource assignment’フィールドに示される値mは、デフォルトテーブルAの行インデックス(row index)m+1を示してもよい。この時、PDSCH時間領域リソース割り当ては、行インデックスm+1から示される時間領域リソース割り当てのコンフィギュレーションである。端末装置1は、行インデックスm+1から示される時間領域リソース割り当てのコンフィギュレーションを想
定し、PDSCHを受信する。例えば、‘Time domain resource assignment’フィールドに示される値mが0である場合、端末装置1は、デフォルトテーブルAの行インデックス1のPDSCH時間領域リソース割り当てのコンフィギュレーションを用いて、そのDCIによってスケジュールされるPDSCHの時間方向のリソース割り当てを特定する。

0156

また、PDSCH時間領域リソース割り当てに適用するリソース割り当てテーブルがpdsch−TimeDomainAllocationListから与えられるリソース割り当てテーブルである場合、‘Time domain resource assignment’フィールドに示される値mは、リストpdsch−TimeDomainAllocationListにおける(m+1)番目のエレメント(エントリ、行)に対応する。例えば、‘Time domain resource assignment’フィールドに示される値mが0である場合、端末装置1は、リストpdsch−TimeDomainAllocationListにおける1番目のエレメント(エントリ)を参照してもよい。例えば、‘Time domain resource assignment’フィールドに示される値mが1である場合、端末装置1は、リストpdsch−TimeDomainAllocationListにおける2番目のエレメント(エントリ)を参照してもよい。

0157

また、PDSCH時間領域リソース割り当てに適用するリソース割り当てテーブルがpdsch−TimeDomainAllocationList2から与えられるリソース割り当てテーブルである場合、‘Time domain resource assignment’フィールドに示される値mは、リストpdsch−TimeDomainAllocationList2における(m+1)番目のエレメント(エントリ、行)に対応する。例えば、‘Time domain resource assignment’フィールドに示される値mが0である場合、端末装置1は、リストpdsch−TimeDomainAllocationList2における1番目のエレメント(エントリ)を参照してもよい。例えば、‘Time domain resource assignment’フィールドに示される値mが1である場合、端末装置1は、リストpdsch−TimeDomainAllocationList2における2番目のエレメント(エントリ)を参照してもよい。

0158

以下、DCIに含まれる‘Time domain resource assignment’フィールドのビット数(サイズ)について説明する。

0159

端末装置1は、DCIフォーマット1_0、DCIフォーマット1_1またはDCIフォーマット1_2を含むPDCCHの検出によって、対応するPDSCHをデコード(受信)してもよい。DCIフォーマット1_0に含まる‘Time domain resource assignment’フィールドのビット数は固定のビット数であってもよい。例えば、この固定のビット数は4であってもよい。つまり、DCIフォーマット1_0に含まれる‘Time domain resource assignment’フィールドのサイズは4ビットである。また、DCIフォーマット1_1およびDCIフォーマット1_2に含まれる‘Time domain resource assignment’フィールドのサイズは可変のビット数であってもよい。例えば、DCIフォーマット1_1およびDCIフォーマット1_2に含まれる‘Time domain resource assignment’フィールドのビット数は0、1、2、3、4の内何れかであってもよい。

0160

以下、DCIフォーマット1_1およびDCIフォーマット1_2に含まれる‘Time domain resource assignment’フィールドのビット数の
決定について説明する。

0161

DCIフォーマット1_1およびDCIフォーマット1_2に含まれる‘Time domain resource assignment’フィールドのビット数は、(I)pdsch−ConfigCommonがpdsch−TimeDomainAllocationList(またはpdsch−TimeDomainAllocationList2)を含むかどうか、および/または、(II)pdsch−Configがpdsch−TimeDomainAllocationList(またはpdsch−TimeDomainAllocationList2)を含むかどうか、および/または、(III)事前に定義したデフォルトテーブルに含まれる行の数に少なくとも基づいて、与えられてもよい。本実施形態において、DCIフォーマット1_1およびDCIフォーマット1_2は、C−RNTI、MCS−C−RNTI、および、CS−RNTIの内、何れかによってスクランブルされるCRCが付加される。DCIフォーマット1_1は、UE固有サーチスペースにおいて検出されてもよい。本実施形態において、‘pdsch−Configがpdsch−TimeDomainAllocationList(またはpdsch−TimeDomainAllocationList2)を含む’の意味は、‘pdsch−Configでpdsch−TimeDomainAllocationList(またはpdsch−TimeDomainAllocationList2)が提供される’の意味であってもよい。‘pdsch−ConfigCommonがpdsch−TimeDomainAllocationList(またはpdsch−TimeDomainAllocationList2)を含む’の意味は、‘pdsch−ConfigCommonでpdsch−TimeDomainAllocationList(またはpdsch−TimeDomainAllocationList2)が提供される’の意味であってもよい。

0162

‘Time domain resource assignment’フィールドのビット数は、ceiling(log2(I))として与えられてもよい。関数ceiling(A)は、Aを下回らない最小の整数を出力する。端末装置1に対してpdsch−TimeDomainAllocationList(またはpdsch−TimeDomainAllocationList2)が設定(提供)される場合、Iの値はpdsch−TimeDomainAllocationList(またはpdsch−TimeDomainAllocationList2)に含まれるエントリの数であってもよい。端末装置1に対してpdsch−TimeDomainAllocationList(またはpdsch−TimeDomainAllocationList2)が設定(提供)されない場合、Iの値はデフォルトテーブル(デフォルトテーブルA(またはデフォルトテーブルD))の行の数であってもよい。つまり、端末装置1に対してpdsch−TimeDomainAllocationList(またはpdsch−TimeDomainAllocationList2)が設定される場合、‘Time domain resource assignment’フィールドのビット数は、pdsch−TimeDomainAllocationList(またはpdsch−TimeDomainAllocationList2)に含まれるエントリの数に基づいて与えられてもよい。端末装置1に対してpdsch−TimeDomainAllocationList(またはpdsch−TimeDomainAllocationList2)が設定されない場合、‘Time domain resource assignment’フィールドのビット数は、デフォルトテーブル(デフォルトテーブルA)の行の数に基づいて与えられてもよい。具体的に言うと、pdsch−Configがpdsch−TimeDomainAllocationList(またはpdsch−TimeDomainAllocationList2)を含む場合、Iの値はpdsch−Configで提供されるpdsch−TimeDomainAllocationList(またはpdsch−TimeDomainAllocationList2)に含
まれるエントリの数であってもよい。また、pdsch−Configがpdsch−TimeDomainAllocationList(またはpdsch−TimeDomainAllocationList2)を含んでおらず、且つ、pdsch−ConfigCommonがpdsch−TimeDomainAllocationList(またはpdsch−TimeDomainAllocationList2)を含む場合、Iの値はpdsch−ConfigCommonで提供されるpdsch−TimeDomainAllocationList(またはpdsch−TimeDomainAllocationList2)に含まれるエントリの数であってもよい。また、pdsch−Configがpdsch−TimeDomainAllocationList(またはpdsch−TimeDomainAllocationList2)を含んでおらず、且つ、pdsch−ConfigCommonがpdsch−TimeDomainAllocationList(またはpdsch−TimeDomainAllocationList2)を含まない場合、Iの値はデフォルトテーブル(例えば、デフォルトテーブルAまたはデフォルトテーブルD)に含まれる行の数であってもよい。

0163

また、別の言い方で言えば、端末装置1に対してpdsch−TimeDomainAllocationList(またはpdsch−TimeDomainAllocationList2)が設定(提供)される場合、‘Time domain resource assignment’フィールドのビット数は、ceiling(log2(I))として与えられてもよい。端末装置1に対してpdsch−TimeDomainAllocationList(またはpdsch−TimeDomainAllocationList2)が設定(提供)されない場合、‘Time domain resource assignment’フィールドのビット数は、固定のビット数であってもよい。例えば、固定のビット数は4ビットであってもよい。
ここで、Iはpdsch−TimeDomainAllocationList(またはpdsch−TimeDomainAllocationList2)に含まれるエントリの数であってもよい。具体的に言うと、pdsch−Configがpdsch−TimeDomainAllocationList(またはpdsch−TimeDomainAllocationList2)を含む場合、Iの値はpdsch−Configで提供されるpdsch−TimeDomainAllocationList(またはpdsch−TimeDomainAllocationList2)に含まれるエントリの数であってもよい。また、pdsch−Configがpdsch−TimeDomainAllocationList(またはpdsch−TimeDomainAllocationList2)を含んでおらず、且つ、pdsch−ConfigCommonがpdsch−TimeDomainAllocationList(またはpdsch−TimeDomainAllocationList2)を含む場合、Iの値はpdsch−ConfigCommonで提供されるpdsch−TimeDomainAllocationList(またはpdsch−TimeDomainAllocationList2)に含まれるエントリの数であってもよい。

0164

これにより、端末装置1は、基地局装置3が生成する‘Time domain resource assignment’フィールドのビット数を特定することができる。つまり、端末装置1は、基地局装置3がスケジュールした端末装置1宛てのPDSCHを正しく受信することができる。

0165

以下では、PUSCHを受信する手順について説明する。

0166

端末装置1は、DCIフォーマット0_0、DCIフォーマット0_1、または、DCIフォーマット0_2を含むPDCCHの検出によって、対応するPUSCHを送信してもよい。つまり、対応するPUSCHは、そのDCIフォーマット(DCI)によってス
ジュールされてもよい(示される)。また、PUSCHは、RARメッセージに含まれるRARULグラントによってスケジュールされてもよい。そのスケジュールされるPUSCHの開始位置(開始シンボル)をSと称する。PUSCHの開始シンボルSはあるスロット内でPUSCHが送信(マップ)される最初のシンボルであってもよい。開始シンボルSはスロットの始まりに対応する。例えば、Sの値が0である場合、端末装置1は、あるスロット内の1番目のシンボルからPUSCHを送信してもよい。また、例えば、Sの値が2である場合、端末装置1は、あるスロットの3番目のシンボルからPUSCHを送信してもよい。そのスケジュールされるPUSCHの連続的なシンボルの数をLと称する。連続的なシンボルの数Lは開始シンボルSから数える。PUSCHに対して割り当てられたSとLの決定は後述する。

0167

PUSCHマッピングのタイプはPUSCHマッピングタイプAおよびPUSCHマッピングタイプBを有する。PUSCHマッピングタイプAでは、Sの値は0である。Lは4から14までの値を取る。ただし、SとLの和は4から14までの値を取る。PUSCHマッピングタイプBでは、Sは0から13までの値を取る。Lは1から14までの値を取る。ただし、SとLの和は1から14までの値を取る。

0168

PUSCHためのDMRSシンボルの位置は、PUSCHマッピングのタイプに依存する。PUSCHための最初のDMRSシンボル(firstDM-RS symbol)の位置は、PUSCHマッピングのタイプに依存する。PUSCHマッピングタイプAでは、最初のDMRSシンボルの位置は、上位層のパラメータdmrs−TypeA−Positionに示されてもよい。dmrs−TypeA−Positionは、‘pos2’または‘pos3’のいずれかにセットされる。例えば、dmrs−TypeA−Positionが‘pos2’にセットされている場合、PUSCHための最初のDMRSシンボルの位置は、スロット内の3番目のシンボルであってもよい。例えば、dmrs−TypeA−Positionが‘pos3’にセットされている場合、PUSCHための最初のDMRSシンボルの位置は、スロット内の4番目のシンボルであってもよい。PUSCHマッピングタイプBでは、最初のDMRSシンボルの位置は、割り当てられるPUSCHの最初のシンボルであってもよい。

0169

以下、PUSCH時間領域リソース割り当ての特定方法について説明する。

0170

基地局装置3は、DCIによって端末装置1にPUSCHを送信させるようにスケジュールしてもよい。そして、端末装置1は、自装置宛てのDCIの検出によってPUSCHを送信してもよい。端末装置1は、PUSCH時間領域リソース割り当てを特定する時に、該PUSCHに適用するリソース割り当てテーブルを決定する。リソース割り当てテーブルは、1つまたは複数のPUSCH時間領域リソース割り当て設定を含む。端末装置1は、該PUSCHをスケジュールするDCIに含まれる‘Time domain resource assignment’フィールドに示される値に基づき、決定したリソース割り当てテーブル内の1つのPUSCH時間領域リソース割り当て設定を選んでもよい。つまり、基地局装置3は、端末装置1にPUSCHのリソース割り当てを決定し、‘Time domain resource assignment’フィールドの値を生成し、その‘Time domain resource assignment’フィールドを含むDCIを端末装置1に送信する。端末装置1は、‘Time domain resource assignment’フィールドにセットされる値に基づき、PUSCHの時間領域のリソース割り当てを特定する。

0171

図17はどのリソース割り当てテーブルをPUSCH時間領域リソース割り当てに適用するかを定義する図である。端末装置1は、図17を参照して、PUSCH時間領域リソース割り当てに適用するリソース割り当てテーブルを決定してもよい。リソース割り当てテーブルは、1つまたは複数のPUSCH時間領域リソース割り当てのコンフィギュレーションを含む。本実施形態において、リソース割り当てテーブルは、(I)事前に定義されるリソース割り当てテーブル、および、(II)上位層のRRC信号から設定されるリソース割り当てテーブルと分類される。事前に定義されるリソース割り当てテーブルは、デフォルトPUSCH時間領域リソース割り当てAおよび/またはデフォルトPUDSCH時間領域リソース割り当てBとして定義される。以下、デフォルトPUSCH時間領域リソース割り当てAをPUSCHデフォルトテーブルA、デフォルトPUDSCH時間領域リソース割り当てBをPUSCHデフォルトテーブルBと称する。

0172

図18はNCP(Normal Cyclic Prefix)に対してPUSCHデフォルトテーブルAの一例を示す図である。図18において、PUSCHデフォルトテーブルAの行数は16であり、各行はPUSCH時間領域リソース割り当ての設定(configuration)を示す。図
18において、インデックス付きの行(indexed row)は、PUSCHマッピングタイプ
、DCIを含むPDCCHとそのPUSCHとの間のスロットオフセットK2、スロット内のPUSCHのスタートシンボルS、および、連続的な割り当てられるシンボル数Lを定義する。PUSCHデフォルトテーブルBもPUSCHデフォルトテーブルと同様の構成であるが、各行におけるPUSCHマッピングタイプ、K2、S、および/または、Lの値は異なってもよい。

0173

上位層のRRC信号から設定されるリソース割り当てテーブルは、上位層の信号pusch−TimeDomainAllocationListによって与えられる。インフォメーションエレメントPUSCH−TimeDomainResourceAllocationは、PUSCH時間領域リソース割り当ての設定を示す。PUSCH−TimeDomainResourceAllocationは、DCIを含むPDCCHとPUSCHの間の時間領域関係を設定するために用いられてもよい。pusch−TimeDomainAllocationListは1つまたは複数のインフォメーションエレメントPUSCH−TimeDomainResourceAllocationを含む。つまり、pusch−TimeDomainAllocationListは1つまたは複数のエレメント(インフォメーションエレメント)を含むリストである。1つのインフォメーションエレメントPUSCH−TimeDomainResourceAllocationを1つのエントリ(または1つの行)とも称してもよい。pusch−TimeDomainAllocationListは最大16までのエントリを含んでもよい。エントリごとは、K2、mappingType、および、startSymbolAndLengthによって定義されてもよい。K2はDCIを含むPDCCHとそのスケジュールされるPUSCHとの間のスロットオフセットを示す。PUSCH−TimeDomainResourceAllocationがK2を示さないならば、端末装置1は、PUSCHのサブキャリア間隔が15kHzまたは30kHzである場合に、K2の値が1であることを想定し、PUSCHのサブキャリア間隔が60kHzである場合に、K2の値が2であることを想定し、PUSCHのサブキャリア間隔が120kHzである場合に、K2の値が3であることを想定してもよい。mappingTypeは、PUSCHマッピングタイプAまたはPUSCHマッピングタイプAのいずれかを示す。startSymbolAndLengthはPUSCHのスタートシンボルS、および、連続的な割り当てられるシンボル数Lの有効な組み合わせを与えるインデックスである。startSymbolAndLengthをスタートと長さインジケータSLIV(start and length indicator)と称してもよい。つまり、開始シンボルSと連続的なシンボルLを直接に定義するデフォルトテーブルと異なって、開始シンボルSと連続的なシンボルLは、SLIVに基づき与えられる。基地局装置3は、PUSCHの時間領域リソース割り当てがスロット境界を超えないよう、SLIVの値をセットすることができる。SLIVの値は、図16における式のように、スロットに含まれるシンボルの数、開始シンボルS、および、連続的なシンボルの数Lに基づいて、算出される。

0174

上位層の信号pusch−TimeDomainAllocationListはセル固有のRRCパラメータpusch−ConfigCommonおよび/または端末装置1(UE)固有のRRCパラメータpusch−Configに含まれてもよい。pusch−ConfigCommonはあるBWPに対するPUSCHのためのセル固有パラメータを設定するために用いられる。pusch−ConfigはあるBWPに対するPUSCHのための端末装置1(UE)固有パラメータを設定するために用いられる。

0175

端末装置1は、第1のPUSCHを送信する場合と第2のPUSCHを送信する場合とで、PUSCH時間領域リソース割り当てに対して、異なるリソース割り当てテーブルを適用してもよい。基地局装置3は、第1のPUSCHを受信する場合と第2のPUSCHを受信する場合とで、PUSCH時間領域リソース割り当てに対して、異なるリソース割り当てテーブルを適用してもよい。

0176

第1のPUSCHと第2のPUSCHは異なるサービスのデータを伝送するPUSCHであってよい。例えば、第1のPUSCHはeMBBのデータを伝送するPUSCHであり、第2のPUSCHはURLLCのデータを伝送するPUSCHであってもよい。第1のPUSCHは、第3のDCIによってスケジュールされるPUSCHであってよい。第2のPDSCHは、第4のDCIによってスケジュールされるPUSCHであってよい。第3のDCIと第4のDCIは異なるサービスのデータをスケジュールするDCIであってよい。例えば、第3のDCIはeMBBのデータを送信するPUSCHをスケジュールするDCIであり、第4のDCIはURLLCのデータを送信するPUSCHをスケジュールするDCIであってもよい。

0177

第3のDCIと第4のDCIは、異なるRNTIでスクランブルされたCRCを付加されたDCIであってもよい。例えば、第3のDCIは第1の値の範囲であるC−RNTIでスクランブルされたCRCを付加されたDCIであり、第4のDCIは第1の値とは異なる第2の値の範囲であるC−RNTIでスクランブルされたCRCを付加されたDCIであってもよい。例えば、第3のDCIは第3の値の範囲である任意の種類のRNTIでスクランブルされたCRCを付加されたDCIであり、第4のDCIは第3の値の範囲とは異なる第4の値の範囲である任意の種類のRNTIでスクランブルされたCRCを付加されたDCIであってもよい。例えば、第3のDCIはC−RNTI、MCS−C−RNTI,CS−RNTI、SI−RNTI、RA−RNTI、TC−RNTIおよび/またはP−RNTIでスクランブルされたCRCを付加されたDCIであり、第4のDCIはUC−RNTIでスクランブルされたCRCを付加されたDCIであってもよい。ただし、UC−RNTIはC−RNTI、MCS−C−RNTI,CS−RNTI、SI−RNTI、RA−RNTI、TC−RNTIおよびP−RNTIで利用可能な値とは異なる値を用いるRNTIであってよい。ただし、UC−RNTIは1つまたは複数のスロットにおける所定のサービスのデータのPDSCHまたはPUSCHを制御するために用いられるRNTIであってよい。

0178

第3のDCIと第4のDCIは、異なるDCIフォーマットを用いたDCIであってもよい。例えば、第1のDCIはDCIフォーマット0_1を用いたDCIであり、第2のDCIはDCIフォーマット0_2を用いたDCIであってもよい。

0179

第3のDCIと第4のDCIは、異なるサイズのDCIフォーマットを用いたDCIであってもよい。例えば、第3のDCIは第3のサイズのDCIフォーマットを用いたDCIであり、第4のDCIは第3のサイズとは異なる第4のサイズのDCIフォーマットを用いたDCIであってもよい。

0180

第3のDCIと第4のDCIは、それぞれのDCIフォーマット内の所定のフィールドで、対応するPUSCHのデータに適用されるサービスが示されてもよい。例えば、第3のDCIのDCIフォーマット内のフィールドで、対応するPUSCHがeMBBのデータを伝送することが特定されてもよい。例えば、第4のDCIのDCIフォーマット内のフィールドで、対応するPUSCHがURLLCのデータを伝送することが特定されてもよい。

0181

第3のDCIと第4のDCIは、異なるサーチスペースおよび/または異なるCORESETで伝送されるDCIであってもよい。

0182

第3のDCIと第4のDCIは、異なるコードブックのPUSCHをスケジュールするDCIであってもよい。

0183

上位層のRRC信号で設定されるリソース割り当てテーブルは、上位層の信号pusch−TimeDomainAllocationListとは異なる上位層の信号(インフォメーションエレメントあるいはRRCパラメータであってよい)で与えられてもよい。例えば、上位層の信号pusch−TimeDomainAllocationList2によって与えられてもよい。基地局装置3は、上位層の信号でpusch−TimeDomainAllocationListおよび/またはpusch−TimeDomainAllocationList2を通知してもよい。端末装置1は、上位層の信号でpusch−TimeDomainAllocationListおよび/またはpusch−TimeDomainAllocationList2を受信してもよい。

0184

pusch−TimeDomainAllocationList2はpusch−TimeDomainAllocationListと同様に、最大16個のエントリを含み、DCIに含まれる4ビットのフィールドによっていずれか1つのエントリが用いられてよい。pusch−TimeDomainAllocationList2に含まれる各エントリにおいて、K2、mappingType、および/または、startSymbolAndLengthが示されてよい。pusch−TimeDomainAllocationList2の各エントリにおけるK2、mappingType、および/または、startSymbolAndLengthにおいて利用可能な値は、pusch−TimeDomainAllocationListにおいて利用可能な値と異なってもよい。例えば、pusch−TimeDomainAllocationListにおいて利用可能なK2の値は0〜32であり、pusch−TimeDomainAllocationList2において利用可能なK2の値は0〜4であってもよい。例えば、pusch−TimeDomainAllocationListにおいて利用可能なmappinngTypeはマッピングタイプAとマッピングタイプBであり、pusch−TimeDomainAllocationList2において利用可能なmappinngTypeはマッピングタイプBのみであってもよい。例えば、pusch−TimeDomainAllocationList2ではmappinngTypeが示されなくてもよい。

0185

端末装置1は、上位層の信号pusch−Configにpusch−TimeDomainAllocationListが含まれており、かつ第3のDCIでPUSCHがスケジュールされている場合に、PUSCHのリソース割り当てテーブルにpusch−Configに含まれるpusch−TimeDomainAllocationListを適用してもよい。端末装置1は、上位層の信号pusch−Configにpusch−TimeDomainAllocationList2が含まれており、かつ第4のDCIでPUSCHがスケジュールされている場合に、PUSCHのリソース割り当てテ
ーブルにpusch−Configに含まれるpusch−TimeDomainAllocationList2を適用してもよい。

0186

端末装置1は、上位層の信号pusch−Configおよびpusch−ConfigCommonにpusch−TimeDomainAllocationListが含まれておらず、かつ第3のDCIでPUSCHがスケジュールされている場合に、PUSCHのリソース割り当てテーブルにPUSCHデフォルトテーブルAを適用してもよい。端末装置1は、上位層の信号pusch−Configおよびpusch−ConfigCommonにpusch−TimeDomainAllocationList2が含まれておらず、かつ第4のDCIでPUSCHがスケジュールされている場合に、PUSCHのリソース割り当てテーブルにPUSCHデフォルトテーブルBを適用してもよい。端末装置1は、上位層の信号でpusch−TimeDomainAllocationListおよび/またはpusch−TimeDomainAllocationList2が設定されていない場合に、第3のDCIと第4のDCIで異なるデフォルトテーブルを用いてもよい。端末装置1は、上位層の信号でpusch−TimeDomainAllocationListおよび/またはpusch−TimeDomainAllocationList2が設定されていない場合に、第3のDCIと第4のDCIで同一のデフォルトテーブルを用いてもよい。

0187

端末装置1は、PUSCHをスケジュールするDCIを検出する。そのPUSCHが送信されるスロットは、(式4)floor(n*2μPUSCH/2μPDCCH)+K2によって与えられる。nは、PUSCHをスケジュールするPDCCHが検出されるスロットである。μPUSCHはPUSCHに対するサブキャリア間隔設定である。μPDCCHはPDCCHに対するサブキャリア間隔設定である。

0188

図18において、K2の値はj、j+1、j+2、または、j+3の内、何れかである。jの値は、PUSCHのサブキャリア間隔に対して特定される値である。例えば、PUSCHが適用されるサブキャリア間隔が15kHzまたは30kHzである場合、jの値は1スロットであってもよい。例えば、PUSCHが適用されるサブキャリア間隔が60kHzである場合、jの値は2スロットであってもよい。例えば、PUSCHが適用されるサブキャリア間隔が120kHzである場合、jの値は3スロットであってもよい。

0189

K2の値はPUSCHデフォルトテーブルAとPUSCHデフォルトテーブルBで異なる値が用いられてもよい。例えば、PUSCHデフォルトテーブルBではjとは異なる値iが用いられてもよい。iの値もjの値と同様にPUSCHが適用されるサブキャリア間隔に対応してスロット数を定める値であってよい。

0190

前述のように、端末装置1は、図17に示されるようなテーブルに基づいて、どのリソース割り当てテーブルをPUSCH時間領域リソース割り当てに適用するかを決定してもよい。

0191

例Dとして、端末装置1は、RARULグラントによってスケジュールされるPUSCHに適用するリソース割り当てテーブルを決定してもよい。端末装置1に対してpusch−ConfigCommonがpusch−TimeDomainAllocationListを含む場合、端末装置1は、上位層のRRC信号から設定されるリソース割り当てテーブルを決定してもよい。そのリソース割り当てテーブルは、pusch−ConfigCommonに含まれるpusch−TimeDomainAllocationListによって与えられる。また、端末装置1に対してpusch−ConfigCommonがpusch−TimeDomainAllocationListを含まない場合、端末装置1は、PUSCHデフォルトテーブルAを決定してもよい。つまり、端
末装置1は、PUSCH時間領域リソース割り当てのコンフィギュレーションを示すデフ
ォルトテーブルAを用いて、PUSCH時間領域リソース割り当ての決定に適用してもよ
い。

0192

例Eとして、端末装置1は、CORESET#0に関連付けられる任意のコモンサーチ
スペースにおいてDCIを検出してもよい。検出したDCIは、C−RNTI、MCS−C−RNTI、TC−RNTI、または、CS−RNTIの内、何れかによってスクランブルされるCRCが付加される。そして、端末装置1は、そのDCIによってスケジュールされるPUSCHに適用するリソース割り当てテーブルを決定してもよい。端末装置1に対してpusch−ConfigCommonがpusch−TimeDomainAllocationListを含む場合、端末装置1は、PUSCH時間領域リソース割り当てに適用するリソース割り当てテーブルを、pusch−ConfigCommonで提供されるpusch−TimeDomainAllocationListから与えられるリソース割り当てテーブルに決定してもよい。また、pusch−ConfigCommonがpusch−TimeDomainAllocationListを含まない場合、端末装置1は、PUSCH時間領域リソース割り当てに適用するリソース割り当てテーブルをPUSCHデフォルトテーブルAに決定してもよい。

0193

例Fとして、端末装置1は、(I)CORESET#0に関連付けられる任意のコモンサーチスペースまたは(II)UE固有サーチスペースにおいてDCIを検出してもよい。検出したDCIは、C−RNTI、MCS−C−RNTI、TC−RNTI、または、CS−RNTIの内、何れかによってスクランブルされるCRCが付加される。そして、端末装置1は、そのDCIによってスケジュールされるPUSCHに適用するリソース割り当てテーブルを決定してもよい。端末装置1に対してpusch−Configがpusch−TimeDomainAllocationListを含む場合、端末装置1は、PUSCH時間領域リソース割り当てに適用するリソース割り当てテーブルを、pusch−Configで提供されるpusch−TimeDomainAllocationListから与えられるリソース割り当てテーブルに決定してもよい。つまり、pusch−Configがpusch−TimeDomainAllocationListを含む場合、端末装置1は、pusch−ConfigCommonがpusch−TimeDomainAllocationListを含むか含まないかと関わらず、pusch−Configで提供されるpusch−TimeDomainAllocationListを用いて、PUSCH時間領域リソース割り当ての決定に適用してもよい。また、pusch−Configがpusch−TimeDomainAllocationListを含んでおらず、且つ、pusch−ConfigCommonがpusch−TimeDomainAllocationListを含む場合、端末装置1は、PUSCH時間領域リソース割り当てに適用するリソース割り当てテーブルを、pusch−ConfigCommonで提供されるpusch−TimeDomainAllocationListから与えられるリソース割り当てテーブルに決定してもよい。つまり、端末装置1は、pusch−ConfigCommonで提供されるpusch−TimeDomainAllocationListを用いて、PUSCH時間領域リソース割り当ての決定に適用する。また、pusch−Configがpusch−TimeDomainAllocationListを含んでおらず、且つ、pusch−ConfigCommonがpusch−TimeDomainAllocationListを含まない場合、端末装置1は、PUSCH時間領域リソース割り当てに適用するリソース割り当てテーブルをPUSCHデフォルトテーブルAに決定してもよい。

0194

端末装置1は、図17の最後の行(CORESET#0に関連付けられない任意のコモンサーチスペースまたはUE固有サーチスペースにおいてDCIを検出し、かつRNTIが所定のタイプのRNTIである場合)において図19のようにリソース割り当てテーブ
ルを決定してもよい。端末装置1は、下記の要素(J)から要素(L)の少なくとも一部に基づいて、DCIによってスケジュールされるPUSCHに適用するリソース割り当てテーブルを決定してもよい。
要素(J):DCIが上記の第3のDCI(3rd DCI)であるか第4のDCI(4th DCI)であるか
要素(K):pusch−ConfigCommonがpusch−TimeDomainAllocationList2を含むかどうか
要素(L):pusch−Configがpusch−TimeDomainAllocationList2を含むかどうか

0195

ただし、第3のDCIの場合と第4のDCIの場合とで同一のデフォルトテーブル(例えばデフォルトテーブルA)が用いられてもよい。ただし、pusch−TimeDomainAllocationList2は、pusch−ConfigCommonには含まれないパラメータでありpusch−Configにのみ含まれるパラメータであってもよい。

0196

図19に示すテーブルでは、端末装置1および/または基地局装置3は、PUSCHに適用するリソース割り当てテーブルをデフォルトテーブルA、デフォルトテーブルB、pusch−ConfigCommonに含まれるpusch−TimeDomainAllocationList、pusch−Configに含まれるpusch−TimeDomainAllocationList、pusch−ConfigCommonに含まれるpusch−TimeDomainAllocationList2およびpusch−Configに含まれるpusch−TimeDomainAllocationList2の中から決定する。
図20は、本実施形態に係るPDSCHに適用するリソース割り当てテーブルの決定法を示すテーブルの別の一例である。図20に示すテーブルでは、端末装置1および/または基地局装置3は、PUSCHに適用するリソース割り当てテーブルをPUSCHデフォルトテーブルA、pusch−ConfigCommonに含まれるpusch−TimeDomainAllocationList、pusch−Configに含まれるpusch−TimeDomainAllocationListおよびpusch−Configに含まれるpusch−TimeDomainAllocationList2の中から決定する。図20に示すテーブルの例では、DCIが第4のDCIであり、pusch−Configにpusch−TimeDomainAllocationList2が含まれず、pusch−ConfigCommonにpusch−TimeDomainAllocationListが含まれる場合には、PUSCHに適用するリソース割り当てテーブルはpusch−ConfigCommonに含まれるpusch−TimeDomainAllocationListである。ただし、DCIが第4のDCIであり、pusch−Configにpusch−TimeDomainAllocationList2が含まれない場合には、PUSCHに適用するリソース割り当てテーブルはPUSCHデフォルトテーブルAまたはPUSCHデフォルトテーブルBであってもよい。

0197

端末装置1は、PUSCHをスケジュールするDCIに含まれる‘Time domain resource assignment’フィールドに示される値に基づき、決定したリソース割り当てテーブル内の1つのPUSCH時間領域リソース割り当て設定を選んでもよい。例えば、PUSCH時間領域リソース割り当てに適用するリソース割り当てテーブルがPUSCHデフォルトテーブルA(またはPUSCHデフォルトテーブルB)である場合、‘Time domain resource assignment’フィールドに示される値mは、PUSCHデフォルトテーブルA(またはPUSCHデフォルトテーブルB)の行インデックス(row index)m+1を示してもよい。この時、PUSCH時間領域リソース割り当ては、行インデックスm+1から示される時間領域リソース割り当ての設定である。端末装置1は、行インデックスm+1から示される時間領域リソース割り当ての設定を想定し、PUSCHを送信する。例えば、‘Time domain resource assignment’フィールドに示される値mが0である場合、端末装置1は、PUSCHデフォルトテーブルA(またはPUSCHデフォルトテーブルB)の行インデックス1のPUSCH時間領域リソース割り当ての設定を用いて、そのDCIによってスケジュールされるPUSCHの時間方向のリソース割り当てを特定する。

0198

また、PUSCH時間領域リソース割り当てに適用するリソース割り当てテーブルがpusch−TimeDomainAllocationListから与えられるリソース割り当てテーブルである場合、‘Time domain resource assignment’フィールドに示される値mは、リストpusch−TimeDomainAllocationListにおける(m+1)番目のエレメント(エントリ、行)に対応する。例えば、‘Time domain resource assignment’フィールドに示される値mが0である場合、端末装置1は、リストpusch−TimeDomainAllocationListにおける1番目のエレメント(エントリ)を参照してもよい。例えば、‘Time domain resource assignment’フィールドに示される値mが1である場合、端末装置1は、リストpusch−TimeDomainAllocationListにおける2番目のエレメント(エントリ)を参照してもよい。

0199

また、PDSCH時間領域リソース割り当てに適用するリソース割り当てテーブルがpusch−TimeDomainAllocationList2から与えられるリソース割り当てテーブルである場合、‘Time domain resource assignment’フィールドに示される値mは、リストpusch−TimeDomainAllocationList2における(m+1)番目のエレメント(エントリ、行)に対応する。例えば、‘Time domain resource assignment’フィールドに示される値mが0である場合、端末装置1は、リストpusch−TimeDomainAllocationList2における1番目のエレメント(エントリ)を参照してもよい。例えば、‘Time domain resource assignment’フィールドに示される値mが1である場合、端末装置1は、リストpusch−TimeDomainAllocationList2における2番目のエレメント(エントリ)を参照してもよい。

0200

以下、DCIに含まれる‘Time domain resource assignment’フィールドのビット数(サイズ)について説明する。

0201

端末装置1は、DCIフォーマット0_0、DCIフォーマット0_1またはDCIフォーマット0_2を含むPDCCHの検出によって、対応するPUSCHを送信してもよい。DCIフォーマット0_0に含まれる‘Time domain resource assignment’フィールドのビット数は固定のビット数であってもよい。例えば、この固定のビット数は4であってもよい。つまり、DCIフォーマット0_0に含まれる‘Time domain resource assignment’フィールドのサイズは4ビットである。また、DCIフォーマット0_1またはDCIフォーマット0_2に含まれる‘Time domain resource assignment’フィールドのサイズは可変のビット数であってもよい。例えば、DCIフォーマット0_1またはDCIフォーマット0_2に含まれる‘Time domain resource assignment’フィールドのビット数は0、1、2、3、4のうち何れかであってもよい。

0202

以下、DCIフォーマット0_1またはDCIフォーマット0_2に含まれる‘Time domain resource assignment’フィールドのビット数の決定について説明する。

0203

‘Time domain resource assignment’フィールドのビット数は、ceiling(log2(I))として与えられてもよい。端末装置1に対してpusch−TimeDomainAllocationList(またはpusch−TimeDomainAllocationList2)が設定(提供)される場合、Iの値はpusch−TimeDomainAllocationList(またはpusch−TimeDomainAllocationList2)に含まれるエントリの数であってもよい。端末装置1に対してpusch−TimeDomainAllocationList(またはpusch−TimeDomainAllocationList2)が設定(提供)されない場合、Iの値はPUSCHデフォルトテーブルA(またはPUSCHデフォルトテーブルB)の行の数であってもよい。つまり、端末装置1に対してpusch−TimeDomainAllocationList(またはpusch−TimeDomainAllocationList2)が設定される場合、‘Time domain resource assignment’フィールドのビット数は、pusch−TimeDomainAllocationList(またはpusch−TimeDomainAllocationList2)に含まれるエントリの数に基づいて与えられてもよい。端末装置1に対してpusch−TimeDomainAllocationList(またはpusch−TimeDomainAllocationList2)が設定されない場合、‘Time domain resource assignment’フィールドのビット数は、デフォルトテーブル(PUSCHデフォルトテーブルAまたはPUSCHデフォルトテーブルB)の行の数に基づいて与えられてもよい。具体的に言うと、pusch−Configがpusch−TimeDomainAllocationList(またはpusch−TimeDomainAllocationList2)を含む場合、Iの値はpusch−Configで提供されるpusch−TimeDomainAllocationList(またはpusch−TimeDomainAllocationList2)に含まれるエントリの数であってもよい。また、pusch−Configがpusch−TimeDomainAllocationList(またはpusch−TimeDomainAllocationList2)を含んでおらず、且つ、pusch−ConfigCommonがpusch−TimeDomainAllocationList(またはpusch−TimeDomainAllocationList2)を含む場合、Iの値はpusch−ConfigCommonで提供されるpusch−TimeDomainAllocationList(またはpusch−TimeDomainAllocationList2)に含まれるエントリの数であってもよい。また、pusch−Configがpusch−TimeDomainAllocationList(またはpusch−TimeDomainAllocationList2)を含んでおらず、且つ、pusch−ConfigCommonがpusch−TimeDomainAllocationList(またはpusch−TimeDomainAllocationList2)を含まない場合、Iの値はPUSCHデフォルトテーブルA(またはPUSCHデフォルトテーブルB)に含まれる行の数であってもよい。

0204

以下、本実施形態における装置の構成について説明する。

0205

図21は、本実施形態の端末装置1の構成を示す概略ブロック図である。図示するように、端末装置1は、無線送受信部10、および、上位層処理部14を含んで構成される。無線送受信部10は、アンテナ部11、RF(Radio Frequency)部12、および、ベー
スバンド部13を含んで構成される。上位層処理部14は、媒体アクセス制御層処理部15、無線リソース制御層処理部16を含んで構成される。無線送受信部10を送信部、受信部、モニタ部、または、物理層処理部とも称する。上位層処理部14を測定部14、選択部14、決定部14または制御部14とも称する。

0206

上位層処理部14は、ユーザの操作等により生成された上りリンクデータ(トランスポートブロックと称されてもよい)を、無線送受信部10に出力する。上位層処理部14は、媒体アクセス制御(MAC: Medium Access Control)層、パケットデータ統合プロトコル(Packet Data Convergence Protocol: PDCP)層、無線リンク制御(Radio Link Control: RLC)層、無線リソース制御(Radio Resource Control:RRC)層の一部あるいはすべての処理を行なう。上位層処理部14は、基地局装置3から受信した上位層の信号および/または下りリンク制御情報に基づいて、物理上りリンク共用チャネルを送信するための時間パラメータを決定する機能を備えてもよい。

0207

上位層処理部14が備える媒体アクセス制御層処理部15は、MACレイヤ(媒体アクセス制御層)の処理を行なう。媒体アクセス制御層処理部15は、無線リソース制御層処理部16によって管理されている各種設定情報/パラメータに基づいて、スケジューリング要求の伝送の制御を行う。

0208

上位層処理部14が備える無線リソース制御層処理部16は、RRCレイヤ(無線リソース制御層)の処理を行なう。無線リソース制御層処理部16は、自装置の各種設定情報/パラメータの管理をする。無線リソース制御層処理部16は、基地局装置3から受信した上位層の信号に基づいて各種設定情報/パラメータをセットする。すなわち、無線リソース制御層処理部16は、基地局装置3から受信した各種設定情報/パラメータを示す情報に基づいて各種設定情報/パラメータをセットする。無線リソース制御層処理部16は、基地局装置3から受信した下りリンク制御情報に基づいてリソース割り当てを制御(特定)する。

0209

無線送受信部10は、変調、復調、符号化、復号化などの物理層の処理を行う。無線送受信部10は、基地局装置3から受信した信号を、分離、復調、復号し、復号した情報を上位層処理部14に出力する。無線送受信部10は、データを変調、符号化することによって送信信号を生成し、基地局装置3等に送信する。無線送受信部10は、基地局装置3から受信した上位層の信号(RRCメッセージ)、DCIなどを上位層処理部14に出力する。また、無線送受信部10は、上位層処理部14からの指示に基づいて、上りリンク信号(物理上りリンク制御チャネルおよび/または物理上りリンク共用チャネルを含む)を生成して送信する。無線送受信部10は、物理下りリンク制御チャネルおよび/または物理下りリンク共用チャネルを受信する機能を備えてもよい。無線送受信部10は、物理上りリンク制御チャネルおよび/または物理上りリンク共用チャネルを送信する機能を備えてもよい。無線送受信部10は、物理下りリンク制御チャネルで下りリンク制御情報を受信する機能を備えてもよい。無線送受信部10は、物理下りリンク制御チャネルで受信した下りリンク制御情報を上位層処理部14に出力する機能を備えてもよい。

0210

RF部12は、アンテナ部11を介して受信した信号を、直交復調によりベースバンド信号に変換し(ダウンコンバート: down covert)、不要な周波数成分を除去する。RF
部12は、処理をしたアナログ信号ベースバンド部に出力する。

0211

ベースバンド部13は、RF部12から入力されたアナログ信号を、アナログ信号をデジタル信号に変換する。ベースバンド部13は、変換したデジタル信号からCP(Cyclic
Prefix)に相当する部分を除去し、CPを除去した信号に対して高速フーリエ変換(Fast Fourier Transform:FFT)を行い、周波数領域の信号を抽出する。

0212

ベースバンド部13は、データを逆高速フーリエ変換(Inverse Fast Fourier Transform:IFFT)して、OFDMシンボルを生成し、生成されたOFDMシンボルにCPを付加し、ベースバンドのデジタル信号を生成し、ベースバンドのデジタル信号をアナログ信号に変換する。ベースバンド部13は、変換したアナログ信号をRF部12に出力する。

0213

RF部12は、ローパスフィルタを用いてベースバンド部13から入力されたアナログ信号から余分な周波数成分を除去し、アナログ信号を搬送波周波数アップコンバート(up convert)し、アンテナ部11を介して送信する。また、RF部12は、電力増幅する。また、RF部12は在圏セルにおいて送信する上りリンク信号および/または上りリンクチャネルの送信電力を決定する機能を備えてもよい。RF部12を送信電力制御部とも称する。

0214

図22は、本実施形態の基地局装置3の構成を示す概略ブロック図である。図示するように、基地局装置3は、無線送受信部30、および、上位層処理部34を含んで構成される。無線送受信部30は、アンテナ部31、RF部32、および、ベースバンド部33を含んで構成される。上位層処理部34は、媒体アクセス制御層処理部35、無線リソース制御層処理部36を含んで構成される。無線送受信部30を送信部、受信部、モニタ部、または、物理層処理部とも称する。また様々な条件に基づき各部の動作を制御する制御部を別途備えてもよい。上位層処理部34を、決定部34または制御部34とも称する。

0215

上位層処理部34は、媒体アクセス制御(MAC: Medium Access Control)層、パケットデータ統合プロトコル(Packet Data Convergence Protocol: PDCP)層、無線リンク制御(Radio Link Control: RLC)層、無線リソース制御(Radio Resource Control:RRC)層の一部あるいはすべての処理を行なう。上位層処理部34は、端末装置1に送信した上位層の信号に基づいて、物理上りリンク共用チャネルを送信するための時間パラメータに基づいて下りリンク制御情報を生成する機能を備えてもよい。上位層処理部34は、生成した下りリンク制御情報などを無線送受信部30に出力する機能を備えてもよい。

0216

上位層処理部34が備える媒体アクセス制御層処理部35は、MACレイヤの処理を行なう。媒体アクセス制御層処理部35は、無線リソース制御層処理部36によって管理されている各種設定情報/パラメータに基づいて、スケジューリングリクエストに関する処理を行う。

0217

上位層処理部34が備える無線リソース制御層処理部36は、RRCレイヤの処理を行なう。無線リソース制御層処理部36は、端末装置1にリソースの割当情報を含む下りリンク制御情報(上りリンクグラント、下りリンクグラント)を生成する。無線リソース制御層処理部36は、下りリンク制御情報、物理下りリンク共用チャネルに配置される下りリンクデータ(トランスポートブロック、ランダムアクセス応答)、システム情報、RRCメッセージ、MAC CE(Control Element)などを生成し、又は上位ノードから取
得し、無線送受信部30に出力する。また、無線リソース制御層処理部36は、端末装置1各々の各種設定情報/パラメータの管理をする。無線リソース制御層処理部36は、上位層の信号を介して端末装置1各々に対して各種設定情報/パラメータをセットしてもよい。すなわち、無線リソース制御層処理部36は、各種設定情報/パラメータを示す情報を送信/報知する。無線リソース制御層処理部36は、あるセルにおける1つまたは複数の参照信号の設定を特定するための情報を送信/報知してもよい。

0218

基地局装置3から端末装置1にRRCメッセージ、MAC CE、および/またはPDCCHを送信し、端末装置1がその受信に基づいて処理を行う場合、基地局装置3は、端末装置が、その処理を行っていることを想定して処理(端末装置1やシステムの制御)を
行う。すなわち、基地局装置3は、端末装置にその受信に基づく処理を行わせるようにするRRCメッセージ、MAC CE、および/またはPDCCHを端末装置1に送っている。

0219

無線送受信部30は、端末装置1に上位層の信号(RRCメッセージ)、DCIなどを送信する。また、無線送受信部30は、上位層処理部34からの指示に基づいて、端末装置1から送信した上りリンク信号を受信する。無線送受信部30は、物理下りリンク制御チャネルおよび/または物理下りリンク共用チャネルを送信する機能を備えてもよい。無線送受信部30は、物理上りリンク制御チャネルおよび/または物理上りリンク共用チャネルを受信する機能を備えてもよい。無線送受信部30は、物理下りリンク制御チャネルで下りリンク制御情報を送信する機能を備えてもよい。無線送受信部30は、上位層処理部34が出力した下りリンク制御情報を物理下りリンク制御チャネルで送信する機能を備えてもよい。その他、無線送受信部30の一部の機能は、無線送受信部10と同様であるため説明を省略する。なお、基地局装置3が1つまたは複数の送受信点4と接続している場合、無線送受信部30の機能の一部あるいは全部が、各送受信点4に含まれてもよい。

ページトップへ

この技術を出願した法人

この技術を発明した人物

ページトップへ

関連する挑戦したい社会課題

関連する公募課題

ページトップへ

おススメ サービス

おススメ astavisionコンテンツ

新着 最近 公開された関連が強い技術

  • 株式会社NTTドコモの「 ユーザ端末及び無線通信方法」が 公開されました。( 2020/10/29)

    【課題・解決手段】ビーム回復手順の実施が想定される場合に、RLMを適切に制御すること。本発明の一態様に係るユーザ端末は、仮想の下り制御チャネルに関する情報を受信する受信部と、前記情報に基づいて、下り制... 詳細

  • 株式会社NTTドコモの「 ユーザ端末及び無線通信方法」が 公開されました。( 2020/10/29)

    【課題・解決手段】同期信号ブロックを利用する無線通信システムにおいて制御チャネルの設定領域の情報を適切に通知するために、本発明のユーザ端末の一態様は、制御リソースセットの構成を示す所定ビット情報を含む... 詳細

  • 株式会社NTTドコモの「 端末、無線通信方法及び基地局」が 公開されました。( 2020/10/29)

    【課題・解決手段】マルチキャリア波形を有するUL信号を適切に送信するために、ユーザ端末は、連続する周波数リソースにわたるマルチキャリア波形を有する上り信号を、上り共有チャネルを用いて送信する送信部と、... 詳細

この 技術と関連性が強い技術

関連性が強い 技術一覧

この 技術と関連性が強い人物

関連性が強い人物一覧

この 技術と関連する社会課題

関連する挑戦したい社会課題一覧

この 技術と関連する公募課題

関連する公募課題一覧

astavision 新着記事

サイト情報について

本サービスは、国が公開している情報(公開特許公報、特許整理標準化データ等)を元に構成されています。出典元のデータには一部間違いやノイズがあり、情報の正確さについては保証致しかねます。また一時的に、各データの収録範囲や更新周期によって、一部の情報が正しく表示されないことがございます。当サイトの情報を元にした諸問題、不利益等について当方は何ら責任を負いかねることを予めご承知おきのほど宜しくお願い申し上げます。

主たる情報の出典

特許情報…特許整理標準化データ(XML編)、公開特許公報、特許公報、審決公報、Patent Map Guidance System データ