図面 (/)

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

出願人 シャープ株式会社鴻穎創新有限公司
発明者 劉麗清山田昇平高橋宏樹星野正幸坪井秀和
出願日 2019年1月10日 (1年11ヶ月経過) 出願番号 2019-002867
公開日 2020年7月27日 (5ヶ月経過) 公開番号 2020-113882
状態 未査定
技術分野 時分割方式以外の多重化通信方式 移動無線通信システム
主要キーワード 洗濯機器 トータル回数 領域関係 キッチン機器 ゼロパワー ブロッケージ 最小インデックス 生活機器
関連する未来課題
重要な関連分野

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

図面 (20)

課題

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

解決手段

端末装置が、上りリンクグラントを受信し、上りリンクグラントがスケジュールされる周波数ホッピングを伴うPUSCHを送信し、PUSCHは1つのスロット内でNrep回の同じトランスポートブロックの繰り返し送信を含み、PUSCHは1つのスロット内で第1の周波数ホップと第2の周波数ホップからなり、Nrepが1の場合、第1の周波数ホップはFloor(L/2)シンボルを有し、第2の周波数ホップはL−Floor(L/2)シンボルを有し、Lは1回の繰り返し送信に対応するシンボルの数であり、Nrepが1より多い場合、第1の周波数ホップは最初のFloor(Nrep/2)回の前記繰り返し送信に対応するシンボルを有し、第2の周波数ホップはNrep-Floor(Nrep/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つがサービスの想定シナリオとして要求されている。

概要

端末装置基地局装置が効率的に通信を行うこと。端末装置が、上りリンクグラントを受信し、上りリンクグラントがスケジュールされる周波数ホッピングを伴うPUSCHを送信し、PUSCHは1つのスロット内でNrep回の同じトランスポートブロックの繰り返し送信を含み、PUSCHは1つのスロット内で第1の周波数ホップと第2の周波数ホップからなり、Nrepが1の場合、第1の周波数ホップはFloor(L/2)シンボルを有し、第2の周波数ホップはL−Floor(L/2)シンボルを有し、Lは1回の繰り返し送信に対応するシンボルの数であり、Nrepが1より多い場合、第1の周波数ホップは最初のFloor(Nrep/2)回の前記繰り返し送信に対応するシンボルを有し、第2の周波数ホップはNrep-Floor(Nrep/2)回の繰り返し送信に対応するシンボルを有する。

目的

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

効果

実績

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

この技術が所属する分野

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

請求項1

上りリンクグラントを受信する受信部と、前記上りリンクグラントがスケジュールされる周波数ホッピングを伴うPUSCHを送信する送信部と、を備え、前記PUSCHは1つのスロット内でNrep回の同じトランスポートブロックの繰り返し送信を含み、前記PUSCHは1つのスロット内で第1の周波数ホップと第2の周波数ホップからなり、前記Nrepが1の場合、前記第1の周波数ホップはFloor(L/2)シンボルを有し、前記第2の周波数ホップはL−Floor(L/2)シンボルを有し、前記Lは1回の前記繰り返し送信に対応するシンボルの数であり、前記Nrepが1より多い場合、前記第1の周波数ホップは最初のFloor(Nrep/2)回の前記繰り返し送信に対応するシンボルを有し、前記第2の周波数ホップはNrep-Floor(Nrep/2)回の前記繰り返し送信に対応するシンボルを有する端末装置

請求項2

1つのスロット内での同じトランスポートブロックの繰り返し送信のそれぞれに対応するシンボルの数は同一でもよいし、異なってもよい請求項1に記載する端末装置。

請求項3

前記Nrep回の前記繰り返し送信が1つのスロット内で連続的に送信され、または、非連続的に送信される請求項1に記載する端末装置。

請求項4

上りリンクグラントを送信する送信部と、前記上りリンクグラントがスケジュールされる周波数ホッピングを伴うPUSCHを受信する受信部と、を備え、前記PUSCHは1つのスロット内でNrep回の同じトランスポートブロックの繰り返し送信を含み、前記PUSCHは1つのスロット内で第1の周波数ホップと第2の周波数ホップからなり、前記Nrepが1の場合、前記第1の周波数ホップはFloor(L/2)シンボルを有し、前記第2の周波数ホップはL−Floor(L/2)シンボルを有し、前記Lは1回の前記繰り返し送信に対応するシンボルの数であり、前記Nrepが1より多い場合、前記第1の周波数ホップは最初のFloor(Nrep/2)回の前記繰り返し送信に対応するシンボルを有し、前記第2の周波数ホップはNrep-Floor(Nrep/2)回の前記繰り返し送信に対応するシンボルを有する基地局装置

請求項5

1つのスロット内での同じトランスポートブロックの繰り返し送信のそれぞれに対応するシンボルの数は同一でもよいし、異なってもよい請求項4に記載する基地局装置。

請求項6

前記Nrep回の前記繰り返し送信が1つのスロット内で連続的に送信され、または、非連続的に送信される請求項4に記載する基地局装置。

請求項7

端末装置の通信方法であって、上りリンクグラントを受信し、前記上りリンクグラントがスケジュールされる周波数ホッピングを伴うPUSCHを送信し、前記PUSCHは1つのスロット内でNrep回の同じトランスポートブロックの繰り返し送信を含み、前記PUSCHは1つのスロット内で第1の周波数ホップと第2の周波数ホップからなり、前記Nrepが1の場合、前記第1の周波数ホップはFloor(L/2)シンボルを有し、前記第2の周波数ホップはL−Floor(L/2)シンボルを有し、前記Lは1回の前記繰り返し送信に対応するシンボルの数であり、前記Nrepが1より多い場合、前記第1の周波数ホップは最初のFloor(Nrep/2)回の前記繰り返し送信に対応するシンボルを有し、前記第2の周波数ホップはNrep-Floor(Nrep/2)回の前記繰り返し送信に対応するシンボルを有する通信方法。

請求項8

基地局装置の通信方法であって、上りリンクグラントを送信し、前記上りリンクグラントがスケジュールされる周波数ホッピングを伴うPUSCHを受信し、前記PUSCHは1つのスロット内でNrep回の同じトランスポートブロックの繰り返し送信を含み、前記PUSCHは1つのスロット内で第1の周波数ホップと第2の周波数ホップからなり、前記Nrepが1の場合、前記第1の周波数ホップはFloor(L/2)シンボルを有し、前記第2の周波数ホップはL−Floor(L/2)シンボルを有し、前記Lは1回の前記繰り返し送信に対応するシンボルの数であり、前記Nrepが1より多い場合、前記第1の周波数ホップは最初のFloor(Nrep/2)回の前記繰り返し送信に対応するシンボルを有し、前記第2の周波数ホップはNrep-Floor(Nrep/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)上記の目的を達成するために、本発明の態様は、以下のような手段を講じた。すなわち、本発明の一態様における端末装置は、上りリンクグラントを受信する受信部と、前記上りリンクグラントがスケジュールされる周波数ホッピングを伴うPUSCHを送信する送信部と、を備え、前記PUSCHは1つのスロット内でNrep回の同じトランスポート
ロックの繰り返し送信を含み、前記PUSCHは1つのスロット内で第1の周波数ホップと第
2の周波数ホップからなり、前記Nrepが1の場合、前記第1の周波数ホップはFloor(L/2)シンボルを有し、前記第2の周波数ホップはL−Floor(L/2)シンボルを有し、前記Lは1回の前記繰り返し送信に対応するシンボルの数であり、前記Nrepが1より多い場合、前記第1の周波数ホップは最初のFloor(Nrep/2)回の前記繰り返し送信に対応するシンボルを有
し、前記第2の周波数ホップはNrep-Floor(Nrep/2)回の前記繰り返し送信に対応するシンボルを有する。

0007

(2)また、本発明の一態様における基地局装置は、上りリンクグラントを送信する送信部と、前記上りリンクグラントがスケジュールされる周波数ホッピングを伴うPUSCHを受信する受信部と、を備え、前記PUSCHは1つのスロット内でNrep回の同じトランス
ポートブロックの繰り返し送信を含み、前記PUSCHは1つのスロット内で第1の周波数
ップと第2の周波数ホップからなり、前記Nrepが1の場合、前記第1の周波数ホップはFloor(L/2)シンボルを有し、前記第2の周波数ホップはL−Floor(L/2)シンボルを有し、前記Lは1回の前記繰り返し送信に対応するシンボルの数であり、前記Nrepが1より多い場合、前記第1の周波数ホップは最初のFloor(Nrep/2)回の前記繰り返し送信に対応するシンボルを有し、前記第2の周波数ホップはNrep-Floor(Nrep/2)回の前記繰り返し送信に対応するシンボルを有する。

0008

(3)また、本発明の一態様における通信方法は、端末装置の通信方法であって、上りリンクグラントを受信し、前記上りリンクグラントがスケジュールされる周波数ホッピングを伴うPUSCHを送信し、前記PUSCHは1つのスロット内でNrep回の同じトランスポ
トブロックの繰り返し送信を含み、前記PUSCHは1つのスロット内で第1の周波数ホッ
プと第2の周波数ホップからなり、前記Nrepが1の場合、前記第1の周波数ホップはFloor(L/2)シンボルを有し、前記第2の周波数ホップはL−Floor(L/2)シンボルを有し、前記Lは1回の前記繰り返し送信に対応するシンボルの数であり、前記Nrepが1より多い場合、前記第1の周波数ホップは最初のFloor(Nrep/2)回の前記繰り返し送信に対応するシンボルを有し、前記第2の周波数ホップはNrep-Floor(Nrep/2)回の前記繰り返し送信に対応するシンボルを有する通信方法。

0009

(4)また、本発明の一態様における通信方法は、基地局装置の通信方法であって、上りリンクグラントを送信し、前記上りリンクグラントがスケジュールされる周波数ホッピングを伴うPUSCHを受信し、前記PUSCHは1つのスロット内でNrep回の同じトランス
ポートブロックの繰り返し送信を含み、前記PUSCHは1つのスロット内で第1の周波数ホ
ップと第2の周波数ホップからなり、前記Nrepが1の場合、前記第1の周波数ホップはFloor(L/2)シンボルを有し、前記第2の周波数ホップはL−Floor(L/2)シンボルを有し、前記Lは1回の前記繰り返し送信に対応するシンボルの数であり、前記Nrepが1より多い場合、前記第1の周波数ホップは最初のFloor(Nrep/2)回の前記繰り返し送信に対応するシンボルを有し、前記第2の周波数ホップはNrep-Floor(Nrep/2)回の前記繰り返し送信に対応するシンボルを有する通信方法。

発明の効果

0010

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

図面の簡単な説明

0011

本発明の実施形態に係る無線通信システムの概念を示す図である。
本発明の実施形態に係るSS/PBCHブロックおよびSSバーストセットの例を示す図である。
本発明の実施形態に係る上りリンクおよび下りリンクスロットの概略構成の一例を示す図である。
本発明の実施形態に係るサブフレーム、スロット、ミニスロットの時間領域における関係を示した図である。
本発明の実施形態に係るスロットまたはサブフレームの一例を示す図である。
本発明の実施形態に係るビームフォーミングの一例を示した図である。
本発明の実施形態に係るPDSCHマッピングタイプの一例を示す図である。。
本発明の実施形態に係る周波数ホッピングの一例を示す図である。。
本発明の実施形態に係る繰り返し送信回数の決定と周波数ホッピングの他の一例を示す図である。
本発明の実施形態に係るどのリソース割り当てテーブルをPDSCH時間領域リソース割り当てに適用するかを定義する図である。
本発明の実施形態に係るデフォルトテーブルAの一例を示す図である。
本発明の実施形態に係るデフォルトテーブルBの一例を示す図である。
本発明の実施形態に係るデフォルトテーブルCの一例を示す図である。
本発明の実施形態に係るSLIVを算出する一例を示す図である。
本実施形態に係るトランスミッションオケージョンに適用される冗長バージョンの一例を示す図。
本実施形態に係るどのリソース割り当てテーブルをPUSCH時間領域リソース割り当てに適用するかを定義する図である。
本実施形態に係るPUSCHデフォルトテーブルAの一例を示す図である。
本実施形態における繰り返し送信回数の決定と周波数ホッピングの他の一例を示す図である。
本発明の実施形態における繰り返し送信回数の決定と周波数ホッピングの他の一例を示す図である。
本実施形態における繰り返し送信の回数と周波数ホッピングの他の一例を示す図である。
本発明の実施形態に係るスロットアグリゲーション送信の一例を示す図である。
本発明の実施形態に係る端末装置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をサーブしてもよい。また、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の無線通信では、以下の物理チャネルが用いられる。
・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)
PBCHは、端末装置1が必要な重要なシステム情報を含む重要情報ブロックMIB: Master Information Block、EIB: Essential Information Block、BCH:Broadcast Channel)を報知するために用いられる。

0026

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

0027

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

0028

例えば、以下のDCIフォーマットが定義されてよい。

0029

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

0030

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

0031

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

0032

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

0033

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

0034

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

0035

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

0036

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

0037

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

0038

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

0039

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

0040

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を示してもよい。

0041

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

0042

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

0043

ここで、基地局装置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には上位層のパラメータが設定されることは端末装置に対して上位層のパラメータが提供されることを意味してもよい。

0044

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

0045

図1において、下りリンクの無線通信では、以下の下りリンク物理信号が用いられる。ここで、下りリンク物理信号は、上位層から出力された情報を送信するために使用されないが、物理層によって使用される。
・同期信号(Synchronization signal:SS)
参照信号(Reference Signal: RS)
同期信号は、プライマリ同期信号(PSS:Primary Synchronization Signal)およびセカンダリ同期信号(SSS)を含んでよい。PSSとSSSを用いてセルIDが検出されてよい。

0046

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

0047

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

0048

本実施形態において、以下の下りリンク参照信号のいずれか1つまたは複数が用いられる。

0049

・DMRS(Demodulation Reference Signal)
・CSI−RS(Channel State Information Reference Signal)
・PTRS(Phase Tracking Reference Signal)
・TRS(Tracking Reference Signal)
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として無線リソースが設定されてもよい。

0050

本実施形態において、以下の上りリンク参照信号のいずれか1つまたは複数が用いられる。

0051

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

0052

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

0053

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)データの単位である。物理層において、トランスポートブロックはコードワードにマップされ、コードワード毎に符号化処理が行われる。

0054

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

0055

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

0056

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

0057

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

0058

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

0059

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

0060

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

0061

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

0062

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

0063

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

0064

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

0065

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

0066

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

0067

ビームマネジメントには、ビーム選択、ビーム改善が含まれてよい。ビームリカバリには、下記の手続きを含んでよい。
・ビーム失敗(beam failure)の検出
・新しいビームの発見
・ビームリカバリリクエストの送信
・ビームリカバリリクエストに対する応答のモニタ
例えば、端末装置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)の系列で指示されるインデックスを用いてもよい。

0068

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

0069

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

0070

この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)、受信空間パラメータであってもよい。

0071

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

0072

QCLタイプとして、QCLであるとみなしてよい長区間特性の組み合わせが定義されてよい。例えば、以下のタイプが定義されてよい。

0073

・タイプA:ドップラーシフト、ドップラースプレッド、平均遅延、遅延スプレッド
・タイプB:ドップラーシフト、ドップラースプレッド
・タイプC:平均遅延、ドップラーシフト
・タイプD:受信空間パラメータ
上述の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に指示されてよい。

0074

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

0075

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

0076

図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は、トランスポートブロックの送信期間であってもよい。

0077

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

0078

リソースグリッドは、ある物理下りリンクチャネル(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,μ)個のリソースエレメントから構成される。

0079

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

0080

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

0081

サブキャリア間隔設定μにおいて、スロットは、サブフレーム内で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シンボルのスタートと時間でアラインされている。

0082

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

0083

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

0084

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

0085

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

0086

図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)に用いられている例である。

0087

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

0088

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

0089

以下、帯域部分(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が設定されていると表現されてもよい。
<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は非活性化される)。
<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までの値を取る。

0090

端末装置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に対するサービングセルのセル固有パラメータを設定するために使われる。

0091

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

0092

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

0093

端末装置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が設定されてもよい。

0094

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

0095

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

0096

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コモンサーチスペースのためのコントロールリソースセットである。

0097

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

0098

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

0099

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

0100

即ち、本実施形態において、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である。

0101

サーチスペースは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フォーマットの情報が含まれる。

0102

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

0103

端末装置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)、またはMSC-C-RNTIでスクランブルされたCRCのDCIフォーマットのモニタリングのためのものである。

0104

-UE固有サーチスペースセット(a UE-specific search space set): このサーチスペースセットは、上位層のパラメータである、PDCCH−Configで示されるサーチスペースタイプがUE固有のサーチスペース(SearchSpace)によって設定される。このサーチスペースは、C−RNTI、CS−RNTI(s)、またはMSC-C-RNTIでスクランブルされたCRCのDCIフォーマットのモニタリングのためのものである。

0105

もし、端末装置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つまたは複数のサーチスペースセットでモニタしてもよい。

0106

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がペアされていることを意味してもよい。

0107

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

0108

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

0109

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

0110

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までの値を取る。

0111

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の最初のシンボルである。

0112

図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が割り当てられる最初のシンボルである。

0113

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

0114

基地局装置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の時間方向のリソース割り当てを特定する。

0115

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

0116

図11は本実施形態に係るデフォルトテーブルAの一例を示す図である。図12は本実施形態に係るデフォルトテーブルBの一例を示す図である。図13は本実施形態に係るデフォルトテーブルCの一例を示す図である。図11を参照すると、デフォルトテーブルAは16行を含む。デフォルトテーブルAにおける行ごとはPDSCH時間領域リソース割り当てのコンフィギュレーションを示す。具体的に説明すると、図11において、インデックス付き行(indexed row)は、PDSCHマッピングタイプ、DCIを含むPDCCHとそのPDSCHとの間のスロットオフセットK0、スロット内のPDSCHのスタートシンボルS、および、連続的な割り当てられるシンボル数Lを定義する。上位層のRRC信号から設定されるリソース割り当てテーブルは、上位層の信号pdsch-TimeDomainAllocationListによって与えられる。インフォメーションエレメントPDSCH-TimeDomainResourceAllocationは、PDSCH時間領域リソース割り当てのコンフィギュレーションを示す。PDSCH-TimeDomainResourceAllocationは、DCIを含むPDCCHとPDSCHの間の時間領域関係を設定するために用いられてもよい。pdsch-TimeDomainAllocationListは1つまたは複数のインフォメーションエレメントPDSCH-TimeDomainResourceAllocationを含む。つまり、pdsch-TimeDomainAllocationListは1つまたは複数のエレメント(インフォメーションエレメント)を含むリストである。1つのインフォメーションエレメントPDSCH-TimeDomainResourceAllocationを1つのエントリ(または1つの行)とも称してもよい。pdsch-TimeDomainAllocationListは最大16までのエントリを含んでもよい。エントリごとは、K0、mappingType、および、startSymbolAndLengthによって定義されてもよい。K0はDCIを含むPDCCHとそのPDSCHとの間のスロットオフセットを示す。PDSCH-TimeDomainResourceAllocationがK0を示さない場合、端末装置1はK0の値が0であることを想定してもよい。mappingTypeは、PDSCHマッピングタイプAまたはPDSCHマッピングタイプAのいずれかを示す。startSymbolAndLengthはPDSCHのスタートシンボルS、および、連続的な割り当てられるシンボル数Lの有効な組み合わせを与えるインデックスである。startSymbolAndLengthをスタートと長さインジケータSLIV(start and length indicator)と称してもよい。つまり、開始シンボルSと連続的なシンボルLを直接に定義するデフォルトテーブルと異なって、開始シンボルSと連続的なシンボルLは、SLIVに基づき与えられる。基地局装置3は、PDSCHの時間領域リソース割り当てがスロット境界を超えないよう、SLIVの値をセットすることができる。スロットオフセットK0とSLIVについて後述する。

0117

上位層の信号pdsch-TimeDomainAllocationListはpdsch-ConfigCommonおよび/またはpdsch-Configに含まれてもよい。インフォメーションエレメントpdsch-ConfigCommonはあるBWPに対するPDSCHのためのセル固有パラメータを設定するために用いられる。インフォメーションエレメントpdsch-ConfigはあるBWPに対するPDSCHのためのUE固有パラメータを設定するために用いられる。

0118

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

0119

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

0120

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

0121

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

0122

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

0123

端末装置1は、図10を参照して、何れかのリソース割り当てテーブルをPDSCH時間領域リソース割り当てに適用するかを決定してもよい。つまり、端末装置1は、以下の要素(A)から要素(F)の一部または全部に少なくとも基づいて、DCIによってスケジュールされるPDSCHに適用するリソース割り当てテーブルを決定してもよい。

0124

要素A:DCIに付加されるCRCをスクランブルするRNTIのタイプ
要素B:DCIが検出されるサーチスペースのタイプ
要素C:そのサーチスペースと関連付けられるCORESETがCORESET#0であるかどうか
要素D:pdsch-ConfigCommonがpdsch-TimeDomainAllocationListを含むかどうか
要素E:pdsch-Configがpdsch-TimeDomainAllocationListを含むかどうか
要素F:SS/PBCHとCORESET多重パータ
要素Aにおいて、DCIに付加されるCRCをスクランブルするRNTIのタイプは、SI−RNTI、RA−RNTI、TC−RNTI、P−RNTI、C−RNTI、MCS−C−RNTI、または、CS−RNTIの内、何れかである。

0125

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

0126

例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時間領域リソース割り当ての決定に適用してもよい。

0127

また、例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に決定してもよい。

0128

また、例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に決定してもよい。

0129

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

0130

続いて、端末装置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の時間方向のリソース割り当てを特定する。

0131

また、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番目のエレメント(エントリ)を参照してもよい。

0132

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

0133

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

0134

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

0135

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

0136

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

0137

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

0138

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

0139

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

0140

端末装置1は、DCIフォーマット0_0、または、DCIフォーマット0_1を含む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の決定は後述する。

0141

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までの値を取る。

0142

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の最初のシンボルであってもよい。

0143

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

0144

基地局装置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の時間方向のリソース割り当てを特定する。

0145

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

0146

図17はNCP(Normal Cyclic Prefix)に対してPUSCHデフォルトテーブルAの一例を示す図である。図17を参照すると、PUSCHデフォルトテーブルAは16行を含む。PUSCHデフォルトテーブルAにおける行ごとはPUSCH時間領域リソース割り当てのコンフィギュレーションを示す。具体的に説明すると、図17において、インデックス付き行(indexed row)は、PUSCHマッピングタイプ、DCIを含むPDCCHとそのPUSCHとの間のスロットオフセットK2、スロット内のPUSCHのスタートシンボルS、および、連続的な割り当てられるシンボル数Lを定義する。上位層のRRC信号から設定されるリソース割り当てテーブルは、上位層の信号pusch-TimeDomainAllocationListによって与えられる。インフォメーションエレメントPUSCH-TimeDomainResourceAllocationは、PUSCH時間領域リソース割り当てのコンフィギュレーションを示す。PUSCH-TimeDomainResourceAllocationは、DCIを含むPDCCHとPUSCHの間の時間領域関係を設定するために用いられてもよい。pusch-TimeDomainAllocationListは1つまたは複数のインフォメーションエレメントPUSCH-TimeDomainResourceAllocationを含む。つまり、pusch-TimeDomainAllocationListは1つまたは複数のエレメント(インフォメーションエレメント)を含むリストである。1つのインフォメーションエレメントPDSCH-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の値は、図14における式のように、スロットに含まれるシンボルの数、開始シンボルS、および、連続的なシンボルの数Lに基づいて、算出される。

0147

上位層の信号pusch-TimeDomainAllocationListはpusch-ConfigCommonおよび/またはpusch-Configに含まれてもよい。インフォメーションエレメントpusch-ConfigCommonはあるBWPに対するPUSCHのためのセル固有パラメータを設定するために用いられる。インフォメーションエレメントpusch-ConfigはあるBWPに対するPUSCHのためのUE固有パラメータを設定するために用いられる。

0148

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

0149

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

0150

前述したのよう、端末装置1は、図16を参照して、何れかのリソース割り当てテーブルをPUSCH時間領域リソース割り当てに適用するかを決定してもよい。

0151

例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時間領域リソース割り当ての決定に適用してもよい。

0152

また、例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に決定してもよい。

0153

また、例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に決定してもよい。

0154

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

0155

また、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番目のエレメント(エントリ)を参照してもよい。

0156

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

0157

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

0158

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

0159

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

0160

以下、本実施形態におけるスロットアグリゲーション送信(slot aggregation transmission、multi-slot transmission)について説明する。

0161

上位層のパラメータpusch-AggregationFactorは、データ(トランスポートブロック)
の繰り返し送信(repetition transmission)の回数を示すために用いられる。上位層の
パラメータpusch-AggregationFactorは2、4、8の内何れかの値を示す。基地局装置3
は、データ送信の繰り返しの回数を示す上位層のパラメータpusch-AggregationFactorを
端末装置1に送信してもよい。基地局装置3は、pusch-AggregationFactorを用いて、端
末装置1にトランスポートブロックの送信を所定の回数に繰り返させることができる。端末装置1は、基地局装置3から上位層のパラメータpusch-AggregationFactorを受信し、
該pusch-AggregationFactorに示される繰り返しの回数を用いて、トランスポートブロッ
クの送信を繰り返してもよい。ただし、端末装置1は、基地局装置からpusch-AggregationFactorを受信しない場合に、トランスポートブロックの繰り返し送信の回数が1とみなしてもよい。つまり、この場合に、端末装置1は、PDCCHがスケジュールするそのトランスポートブロックを1回送信してもよい。つまり、端末装置1は、基地局装置からpusch-AggregationFactorを受信しない場合に、PDCCHがスケジュールするそのトランスポートブロックに対して、スロットアグリゲーション送信(マルチスロット送信)を行わなくてもよい。

0162

具体的に言うと、端末装置1は、C-RNTI、MCS-C-RNTIでスクランブルされたCRCが付加
されるDCIフォーマットを含むPDCCHを受信し、該PDCCHによってスケジュールさ
れるPUSCHを送信してもよい。端末装置1にはpusch-AggregationFactorが設定され
ている場合、端末装置1は、PUSCHが最初に送信されるスロットからの連続的なN個のス
ロットでPUSCHをN回送信してもよい。スロットごとで一回のPUSCH送信(トランスポートブロックの送信)が行われてもよい。つまり、同じトランスポートブロックの送信(繰り返し送信)は1スロット内で1回しか行われない。Nの値はpusch-AggregationFactorから示される。端末装置1にpusch-AggregationFactorが設定されていない場合、Nの値は1であってもよい。PUSCHが最初に送信されるスロットは、前述のような(式4)によって与えられてもよい。PUSCHをスケジュールするPDCCHに基づき与えられたPUSCH時間領域リソース割り当ては連続的なN個のスロットに適用されてもよい。つまり、同じシンボル割り当て(同じスタートシンボルSと同じ連続的な割り当てられるシンボル数L)が連続的なN個のスロットに適用されてもよい。端末装置1は、PUSCHが最初に送信されるスロットからの連続的なN個のスロットにわたってトランスポートブロックを繰り返して送信してもよい。端末装置1は、各スロットにおいて同じシンボル割り当て(シンボルアロゲーション)を用いてトランスポートブロックを繰り返して送信してもよい。上位層のパラメータpusch-AggregationFactorが設定されている場合に端末装置1が行うスロットアグリゲーション送信は、第1のアグリゲーション送信と称してもよい。つまり、上位層のパラメータpusch-AggregationFactorは、第1のアグリゲーション送信のための繰り返し送信(repetition transmission)の回数を示すために用いられる。上位層のパラメータpusch-AggregationFactorは、第1のアグリゲーション送信パラメータとも呼ぶ。

0163

第1のアグリゲーション送信では、第1回のトランスミッションオケージョン(0th transmission occasion、送信機会)がPUSCHが最初に送信されるスロットにあってもよい。第2回のトランスミッションオケージョン(1st transmission occasion)がPUSCHが最初に送信されるスロットからの次のスロットにあってもよい。第N回のトランスミッションオケージョン((N-1)th transmission occasion)がPUSCHが最初に送信されるスロットからのN番目のスロットにあってもよい。トランスポートブロックの送信に適用される冗長バージョン(Redundancy Version)は、そのトランスポートブロックの第n回のトランスミッションオケージョン((n-1)th transmission occasion)、および、PUSCHをスケジュールするDCIから示されるrvidに基づいて決定されてもよい。冗長バージョンのシーケンスは{0、2,3,1}である。変数rvidは、冗長バージョンのシーケンスへのインデックスである。該変数は4でモジュロして更新されている。冗長バージョンは、PUSCHで送信されるトランスポートブロックの符号化(レートマッチング)のために用いられる。冗長バージョンは、0、2、3、1の順にインクリメントされてもよい。トランスポートブロックの繰り返しの送信は、冗長バージョン(Redundancy Version)の順に行われてもよい。

0164

図15はトランスミッションオケージョンに適用される冗長バージョンの一例を示す図である。

0165

図15の示すように、第1回のトランスミッションオケージョンに適用される冗長バージョンrvidは、該PUSCH(トランスポートブロック)をスケジュールするDCIによって示される値である。例えば、端末装置1は、PUSCHをスケジュールするDCIがrvidの値を0に示した場合、図15の1行目を参照して、トランスミッションオケージョンに提供される冗長バージョンrvidを決定してもよい。トランスミッションオケージョンに適用される冗長バージョンは、0、2,3,1の順にインクリメントされてもよい。例えば、端末装置1は、PUSCHをスケジュールするDCIがrvidの値を2に示した場合、図15の2行目を参照して、トランスミッションオケージョンに提供される冗長バージョンrvidを決定してもよい。トランスミッションオケージョンに適用される冗長バージョンは、2,3,1,0の順にインクリメントされてもよい。

0166

あるトランスミッションオケージョンに対するシンボル割り当て内の少なくとも1つのシンボルが上位層のパラメータから下りリンクシンボルに示された場合、端末装置1は、該トランスミッションオケージョンにあるスロットにおいて、トランスポートブロックを送信しなくてもよい。

0167

本実施形態において、基地局装置3は、端末装置1に対して上位層のパラメータpusch-AggregationFactor-r16を送信してもよい。上位層のパラメータpusch-AggregationFactor-r16は、データ(トランスポートブロック)の繰り返し送信(repetition transmission)の回数を示すために用いられてもよい。上位層のパラメータpusch-AggregationFactor-r16は、スロットアグリゲーション送信、および/または、ミニスロットアグリゲーション送信のための繰り返し送信の回数を示すために用いられてもよい。スロットアグリゲーション送信とミニスロットアグリゲーション送信は後述する。

0168

本実施形態において、pusch-AggregationFactor-r16は、例えば、n1, n2, n3の内何れ
かの値に設定される。n1, n2, n3それぞれの値は、2、4、8であってもよいし、他の値であってもよい。n1, n2, n3は、トランスポートブロックの繰り返し送信の回数を示す。つまり、pusch-AggregationFactor-r16は、1つの繰り返し送信の回数の値を示してもよ
い。トランスポートブロックの繰り返し送信の回数は、スロット内の繰り返し送信回数(Nrepなど)かもしれないし、スロット内およびスロット間を含めた繰り返し送信回数(Ntotalなど)かもしれないし、スロット間の繰り返し送信回数(Ntotalなど)かもしれない。または、基地局装置3は、端末装置1に繰り返し送信の回数をもっと柔軟に設定できるように、1つより多いエレメントを含むpusch-AggregationFactor-r16を端末装置1
に送信してもよい。エレメント(インフォメーションエレメント、エントリ)ごとは、トランスポートブロックの繰り返し送信の回数を示すために用いられてもよい。つまり、pusch-AggregationFactor-r16は、1つより多い複数の繰り返し送信の回数の値を示してもよい。本実施形態において、上位層のパラメータpusch-AggregationFactor-r16が設定されている場合に端末装置1が行うスロットアグリゲーション送信は、第2のアグリゲーション送信と称してもよい。つまり、上位層のパラメータpusch-AggregationFactor-r16は、少なくとも第2のアグリゲーション送信のための繰り返し送信(repetition transmission)の回数を示すために用いられてもよい。上位層のパラメータpusch-AggregationFactor-r16は、第2のアグリゲーション送信パラメータとも呼ぶ。そして、基地局装置3は、トランスポートブロックをスケジュールするDCIに含まれるフィールドを介して、何れかのエレメントを示し、そのトランスポートブロックの繰り返し送信の回数を端末装置1に通知してもよい。具体的手順は後述する。また、基地局装置3は、MAC CE(MAC Control Element)を介して、何れかのエレメントを示し、そのトランスポートブロックの繰り返し送信の回数を端末装置1に通知してもよい。即ち、基地局装置3は、そのDCIに含まれるフィールドおよび/またはMAC CEを介して、何れかのエレメントを示し、動的に繰り返し送信の回数を端末装置1に通知してもよい。端末装置1に動的繰り返し回数の機能が適用されることは、端末装置1が動的に繰り返し送信の回数を基地局装置3から通知されることを意味してもよい。

0169

第1の例として、基地局装置3は、端末装置1に対してpusch-AggregationFactorとpusch-AggregationFactor-r16を送信しなくてもよい。つまり、端末装置1にはpusch-AggregationFactorとpusch-AggregationFactor-r16が設定されなくてもよい。別の言い方で言えば、端末装置1はpusch-AggregationFactorとpusch-AggregationFactor-r16を含まない(を設定しない)RRCメッセージを基地局装置3から受信してもよい。この場合に、端末装置1は、前述のような(式4)によって与えられるスロットでPUSCHを送信してもよい。別の言い方で言うと、トランスポートブロックの繰り返し送信の回数は1であってもよい。つまり、端末装置1は、スロットアグリゲーション送信および/またはミニスロットアグリゲーション送信を行わなくてもよい。

0170

また、第2の例として、基地局装置3は、端末装置1に対してpusch-AggregationFactorを送信し、pusch-AggregationFactor-r16を送信しなくてもよい。つまり、端末装置1にはpusch-AggregationFactorが設定され、pusch-AggregationFactor-r16が設定されなくてもよい。別の言い方で言えば、端末装置1はpusch-AggregationFactorを含み(を設定し)、pusch-AggregationFactor-r16を含まない(を設定しない)RRCメッセージを基地局装置3から受信してもよい。この場合に、端末装置1は、前述のような(式4)によって与えられるスロットからの連続的なN個のスロットでPUSCHをN回送信してもよい。つまり、トランスポートブロックの繰り返し送信の回数は、pusch-AggregationFactorによって示されるNであってもよい。端末装置1は、DCIがスケジュールするPUSCHに対して、第1のアグリゲーション送信を行ってもよい。該PUSCHをスケジュールするDCIを含むPDCCHがCSSで送信されてもよいし、USSで送信されてもよい。同じシンボル割り当てが連続的なN個のスロットに適用されてもよい。

0171

また、第3の例として、基地局装置3は、端末装置1に対してpusch-AggregationFactorを送信しなく、pusch-AggregationFactor-r16を送信してもよい。つまり、端末装置1にはpusch-AggregationFactorが設定されなく、pusch-AggregationFactor-r16が設定されてもよい。別の言い方で言えば、端末装置1はpusch-AggregationFactorを含まず(を設定せず)、pusch-AggregationFactor-r16を含む(を設定する)RRCメッセージを基地局装置3から受信してもよい。この場合に、端末装置1は、前述のような(式4)によって与えられるスロットからの1つまたは複数のスロットでPUSCHをM回送信してもよい。第1のアグリゲーション送信と異なって、複数のスロットが連続してもよいし、非連続になってもよい。つまり、トランスポートブロックの繰り返し送信の回数Mは、pusch-AggregationFactor-r16によって示されてもよい。該PUSCHをスケジュールするDCIを含むPDCCHがCSSで送信されてもよいし、USSで送信されてもよい。同じシンボル割り当てが複数のスロットに適用されなくてもよい。つまり、第1回のトランスポートブロックの繰り返し送信に適用されるPUSCH時間領域リソース割り当て(シンボル割り当て)は、そのトランスポートブロックをスケジュールするDCIに基づいて与えられてもよい。ただし、第2回からのトランスポートブロックの繰り返し送信に適用されるPUSCHシンボル割り当ては、PUSCHをスケジュールするPDCCH(DCIなど)に基づいて与えられるシンボル割り当てと異なってもよい。これをシンボル割り当て拡張と呼ぶ。具体的に言うと、第2回からのトランスポートブロックの繰り返し送信に適用されるスタートシンボルSは、そのPDCCHに基づいて与えられるスタートシンボルSと異なってもよい(スタートシンボル拡張)。例えば、第2回からのトランスポートブロックの繰り返し送信に適用されるスタートシンボルSは、スロットの先頭である0番目のシンボルであってよい。また、第2回からのトランスポートブロックの繰り返し送信に適用されるスタートシンボルSは、PDCCHに基づいて与えられるスタートシンボルSと同じであってもよい。例えば、第2回からのトランスポートブロックの繰り返し送信に適用されるスタートシンボルSは、スロットの先頭からの最初の利用可能なシンボルであってよい。また、第2回からのトランスポートブロックの繰り返し送信に適用されるPUSCHの連続的な割り当てられるシンボル数Lは、そのPDCCHに基づいて与えられる連続的な割り当てられるシンボル数Lと異なってもよい(シンボル数拡張)。また、第2回からのトランスポートブロックの繰り返し送信に適用されるPUSCHの連続的な割り当てられるシンボル数Lは、そのPDCCHに基づいて与えられる連続的な割り当てられるシンボル数Lと同じでもよい。各繰り返し送信におけるスタートシンボルおよび/またはシンボル数は、利用可能なシンボルに基づいて決定されてもよい。X番目のPUSCHのシンボル数Lを、PDCCHに基づいて与えられるスタートシンボルS、PDCCHに基づいて与えられるシンボル数L、スロットのシンボル数、スロット内の利用可能なシンボル、Ntotal、NrepおよびNslotsの1つ、複数、または全部に基づいて決定してもよい。

0172

また、第3の例において、pusch-AggregationFactor-r16が1つおよび/または1つよ
り多いエレメントを含む場合に、端末装置1は、DCIに含まれる‘Repetition Number
’フィールドを用いて、複数のエレメントの中から1つを選択してもよい(動的繰り返し回数)。DCIに含まれる‘Repetition Number’フィールドは、pusch-AggregationFactor-r16が1つおよび/または1つより多いエレメントを含む場合には、存在し、そうでない場合は、存在しないようにしてもよい。DCIに含まれる‘Repetition Number’フィールドは、pusch-AggregationFactor-r16が設定されていない場合には、存在しないようにしてもよい。そして、選択されたエレメントに示される値は、DCIがスケジュールするトランスポートブロックの繰り返し送信の回数である。そして、端末装置1は、トランスポートブロックを通知された回数に繰り返し送信してもよい。‘Repetition Number’フィールドのビット数は、ceiling(log2(X+1))またはceiling(log2(X))として与えられてもよい。Xは、pusch-AggregationFactor-r16に含まれるエレメントの数である。‘Repetition Number’フィールドのビット数がceiling(log2(X))として与えられた場合に、‘Repetition Number’フィールドに示される値mは、pusch-AggregationFactor-r16に含まれる(m+1)番目のエレメントに対応してもよい。そして、トランスポートブロックの繰り返し送信の回数は、(m+1)番目のエレメントから示される値であってもよい。例えば、‘Repetition Number’フィールドに示される値mが0である場合、端末装置1は、pusch-AggregationFactor-r16に含まれる1番目のエレメントを参照してもよい。エレメントが示す値は、1より大きい値であってもよい。エレメントが示す値は、1と等しい値であってもよい。また、‘Repetition Number’フィールドのビット数がceiling(log2(X+1))として与えられた場合に、‘Repetition Number’フィールドに示される値mは、pusch-AggregationFactor-r16に含まれるm番目のエレメントに対応してもよい。ただし、ここで、mの値は非ゼロの値である。‘Repetition Number’フィールドに示される値mが0の場合、端末装置1は、繰り返し送信の回数を1としてみなしてもよい。各エレメントが示す値は、1より大きい値であってもよい。
pusch-AggregationFactor-r16が設定されている際には、アグリゲーション送信(第2の
アグリゲーション送信)に対して、シンボル割り当て拡張(スタートシンボル拡張および/またはシンボル数拡張)、動的繰り返し回数、および/またはミニスロットアグリゲーション送信の機能が適用される。

0173

また、第4の例として、基地局装置3は、端末装置1に対してpusch-AggregationFactorとpusch-AggregationFactor-r16を送信してもよい。つまり、端末装置1にはpusch-AggregationFactorとpusch-AggregationFactor-r16が設定されてもよい。別の言い方で言えば、端末装置1はpusch-AggregationFactorと、pusch-AggregationFactor-r16を含む(を設定する)RRCメッセージを基地局装置3から受信してもよい。基本的には、第3の例として説明したpusch-AggregationFactor-r16が設定されている際の動作である、シンボル割り当て拡張(スタートシンボル拡張および/またはシンボル数拡張)、動的繰り返し回数、および/またはミニスロットアグリゲーション送信の機能が適用される。

0174

以下、pusch-AggregationFactor-r16が設定されている端末装置1は、以下の要素(A
)から要素(D)の一部または全部に少なくとも基づいて、あるDCIに‘Repetition Number’フィールドが存在(present)するかどうかを決定してもよい。

0175

要素A:DCIに付加されるCRCをスクランブルするRNTIのタイプ
要素B:DCIが検出されるサーチスペースのタイプ
要素C:DCIフォーマットのタイプ
要素D:DCIのフィールドで示される情報
要素Aにおいて、DCIに付加されるCRCをスクランブルするRNTIのタイプが、SI−RNTI、RA−RNTI、TC−RNTI、P−RNTI、C−RNTI、MC
S−C−RNTI、または、CS−RNTIの内、何れかである場合、該DCIに‘Repetition Number’フィールドが存在しないようにしてもよい。また、DCIに付加されるCRCをスクランブルするRNTIのタイプがNEW−RNTIである場合、該DCIに含まれる‘Repetition Number’フィールドは、存在するようにしてもよい。

0176

要素Bにおいて、DCIを端末装置1がモニターするサーチスペースのタイプは、コモンサーチスペース、または、UE固有サーチスペースである。コモンサーチスペースは、タイプ0コモンサーチスペース、タイプ1コモンサーチスペース、タイプ2コモンサーチスペースを含む。DCIがモニターされるサーチスペースがコモンサーチスペースである場合に、該DCIに‘Repetition Number’フィールドが存在しないようにしてもよい。
DCIがモニターされるサーチスペースがUE固有サーチスペースである場合に、該DCIに‘Repetition Number’フィールドが存在してもよい。

0177

要素Cにおいて、DCIフォーマットのタイプはDCIフォーマット0_0、DCIフォーマット0_1、DCIフォーマット0_2である。DCIがDCIフォーマット0_0とDCIフォーマット0_1である場合、該DCIに‘Repetition Number’フィールドが存在しないようにしてもよい。DCIがDCIフォーマット0_2である場合、該DCIに‘Repetition Number’フィールドが存在するようにしてもよい。または、DCIがDCIフォーマット0_0である場合、該DCIに‘Repetition Number’フィールドが存在しないようにしてもよい。DCIがDCIフォーマット0_1またはDCIフォーマット0_2である場合、該DCIに‘Repetition Number’フィールドが存在するようにしてもよい。

0178

また、例えば、DCIフォーマット0_0がコモンサーチスペースでモニターされる場合に、該DCIに‘Repetition Number’フィールドが存在しないようにしてもよい。D
CIフォーマット0_0がUE固有サーチスペースでモニターされる場合に、該DCIに‘Repetition Number’フィールドが存在するようにしてもよい。また、例えば、DCI
フォーマット0_1がNEW−RNTIによってスクランブルされている場合に、該DCIに‘Repetition Number’フィールドが存在するようにしてもよい。DCIフォーマ
ト0_1がNEW−RNTI以外のRNTIによってスクランブルされている場合に、該DCIに‘Repetition Number’フィールドが存在しないようにしてもよい。

0179

以下、pusch-AggregationFactor-r16が設定されている端末装置1は、以下の要素(A
)から要素(C)の一部または全部に少なくとも基づいて、DCIがスケジュールするPUSCH送信に上記で説明したpusch-AggregationFactor-r16が設定されている際の機能
が適用されるかどうかを決定してもよい。

0180

要素A:DCIに付加されるCRCをスクランブルするRNTIのタイプ
要素B:DCIが検出されるサーチスペースのタイプ
要素C:DCIフォーマットのタイプ
要素Aにおいて、DCIに付加されるCRCをスクランブルするRNTIのタイプが、SI−RNTI、RA−RNTI、TC−RNTI、P−RNTI、C−RNTI、MCS−C−RNTI、または、CS−RNTIの内、何れかである場合、該DCIがスケジュールするPUSCH送信にpusch-AggregationFactor-r16が設定されている際の機能が適用されなくてもよい。また、DCIに付加されるCRCをスクランブルするRNTIのタイプがNEW−RNTIである場合、該DCIがスケジュールするPUSCH送信にpusch-AggregationFactor-r16が設定されている際の機能が適用されてもよい。

0181

要素Bにおいて、DCIを端末装置1がモニターするサーチスペースのタイプは、コモンサーチスペース、または、UE固有サーチスペースである。コモンサーチスペースは、
タイプ0コモンサーチスペース、タイプ1コモンサーチスペース、タイプ2コモンサーチスペースを含む。DCIがモニターされるサーチスペースがコモンサーチスペースである場合に、該DCIがスケジュールするPUSCH送信にpusch-AggregationFactor-r16が
設定されている際の機能が適用されなくてもよい。DCIがモニターされるサーチスペースがUE固有サーチスペースである場合に、該DCIがスケジュールするPUSCH送信にpusch-AggregationFactor-r16が設定されている際の機能が適用されてもよい。

0182

要素Cにおいて、DCIフォーマットのタイプはDCIフォーマット0_0、DCIフォーマット0_1、DCIフォーマット0_2である。DCIがDCIフォーマット0_0とDCIフォーマット0_1である場合、該DCIがスケジュールするPUSCH送信にpusch-AggregationFactor-r16が設定されている際の機能が適用されなくてもよい。DCIがDCIフォーマット0_2である場合、該DCIがスケジュールするPUSCH送信にpusch-AggregationFactor-r16が設定されている際の機能が適用されてもよい。または、DCIがDCIフォーマット0_0である場合、該DCIがスケジュールするPUSCH送信にpusch-AggregationFactor-r16が設定されている際の機能が適用されなくてもよい。DCIがDCIフォーマット0_1またはDCIフォーマット0_2である場合、該DCIがスケジュールするPUSCH送信にpusch-AggregationFactor-r16が設定されている際の機能が適用されてもよい。

0183

また、例えば、DCIフォーマット0_0がコモンサーチスペースでモニターされる場合に、該DCIがスケジュールするPUSCH送信にpusch-AggregationFactor-r16が設
定されている際の機能が適用されなくてもよい。DCIフォーマット0_0がUE固有サーチスペースでモニターされる場合に、該DCIがスケジュールするPUSCH送信にpusch-AggregationFactor-r16が設定されている際の機能が適用されてもよい。

0184

上述のように、pusch-AggregationFactor-r16が設定されている際の機能が適用されな
い場合では、もしpusch-AggregationFactorが設定されている場合に、そのDCIでスケジュールされるPUSCH送信では第1のアグリゲーション送信が行われてもよい。つまり、端末装置1は、トランスポートブロックを連続的なN個のスロットでN回繰り返し送信してもよい。Nの値はpusch-AggregationFactorによって与えられてもよい。N個のスロットでは同じシンボルアロケーションが適用されてもよい。また、pusch-AggregationFactor-r16が設定されている際の機能が適用されない場合では、もしpusch-AggregationFactorが設定されていない場合に、そのDCIでスケジュールされるPUSCH送信が1回行われてもよい。つまり、端末装置1は、トランスポートブロックを1回送信してもよい。

0185

以下、本実施形態におけるミニスロットアグリゲーション送信(mini-slot aggregation transmission, subslot aggregation transmission, multi-subslot transmission, intra-slot aggregation transmission)について説明する。

0186

前述のように、スロットアグリゲーション送信(第1のアグリゲーション送信と第2のアグリゲーション送信におけるスロットアグリゲーション送信)では、1つの上りリンクグラントが2回または2回より多いPUSCH繰り返し送信をスケジュールしてもよい。各繰り返し送信は各連続的なスロット(または、各利用可能なスロット)で行わる。つまり、スロットアグリゲーションでは、1つのスロット(1つの利用可能なスロット)内で同じトランスポートブロックの繰り返し送信の回数が最大1回のみです。利用可能なスロットは、実際にトランスポートブロックの繰り返し送信が行われるスロットであってもよい。

0187

ミニスロットアグリゲーション送信では、1つの上りリンクグラントが2回または2回より多いPUSCH繰り返し送信をスケジュールしてもよい。繰り返し送信は同じスロッ
ト内で行われてもよいし、連続的な利用可能なスロットにわたって行われてもよい。該スケジュールされるPUSCH繰り返し送信には、スロット(利用可能なスロット)内のPUSCH繰り返し送信に利用可能なシンボルに基づいて、各スロット内で行われる繰り返し送信の回数は異なってもよい。つまり、ミニスロットアグリゲーション送信では、1つのスロット(1つの利用可能なスロット)内で同じトランスポートブロックの繰り返し送信の回数が1回または1回より多くてもよい。つまり、ミニスロットアグリゲーション送信では、端末装置1は、1つのスロット内で同じトランスポートブロックの1回以上の繰り返し送信を基地局装置3に送信することができる。つまり、ミニスロットアグリゲーション送信は、スロット内アグリゲーションをサポートするモードのことを意味するとも言える。ミニスロットアグリゲーション送信に、上記で説明したシンボル割り当て拡張(スタートシンボル拡張および/またはシンボル数拡張)、および/または動的繰り返し回数、が適用されてもよい。

0188

本実施形態において、端末装置1は、(I)上位層のパラメータ、および/または、(II)上りリンクグラントに含まれるフィールドに少なくとも基づいて、その上りリンクグラントがスケジュールされるPUSCH送信にアグリゲーション送信が適用されるかどうか、または、何れかのアグリゲーション送信タイプが適用されるかどうかを決定してもよい。アグリゲーション送信のタイプは第1のアグリゲーション送信、第2のアグリゲーション送信を含んでもよい。別の例として、第2のアグリゲーション送信を、スロットアグリゲーション送信とミニスロットアグリゲーション送信にタイプを分けてもよい。つまり、アグリゲーション送信のタイプは第1のスロットアグリゲーション送信(第1のアグリゲーション送信)、第2のスロットアグリゲーション送信(第2のアグリゲーション送信におけるスロットアグリゲーション)、および、ミニスロットアグリゲーション送信を含んでもよい。

0189

本実施形態の態様Aにおいて、基地局装置3は、スロットアグリゲーション送信とミニスロットアグリゲーション送信の内何れを設定するかを上位層のパラメータによって端末装置1に通知してもよい。スロットアグリゲーション送信とミニスロットアグリゲーション送信の内何れが設定されるかは、スロットアグリゲーション送信とミニスロットアグリゲーション送信の内何れが適用されるかを意味してもよい。例えば、pusch-AggregationFactorは第1のアグリゲーション送信(第1のスロットアグリゲーション送信)の繰り返し送信の回数を示すために用いられてもよい。pusch-AggregationFactor-r16は第2のスロットアグリゲーション送信および/またはミニスロットアグリゲーション送信の繰り返し送信の回数を示すために用いられてもよい。pusch-AggregationFactor-r16は、第2のスロットアグリゲーション送信および/またはミニスロットアグリゲーション送信に対して、共通のパラメータであってもよい。上位層のパラメータrepTxWithinSlot-r16はミニスロットアグリゲーション送信を示すために用いられてもよい。上位層のパラメータrepTxWithinSlot-r16が有効にセットされる場合、端末装置1は、トランスポートブロック送信にミニスロットアグリゲーション送信が適用されることとみなし、ミニスロットアグリゲーション送信を実行してもよい。つまり、端末装置1にpusch-AggregationFactor-r16が設定され、且つ、repTxWithinSlot-r16が設定されている(有効にセットされている)場合、端末装置1は、ミニスロットアグリゲーション送信が適用されることとみなしてもよい。ミニスロットアグリゲーション送信のための繰り返し送信の回数は、pusch-AggregationFactor-r16によって示されてもよい。また、端末装置1にpusch-AggregationFactor-r16が設定され、且つ、repTxWithinSlot-r16が設定されない場合、端末装置1は、第2のスロットアグリゲーション送信が適用されることとみなしてもよい。第2のスロットアグリゲーション送信のための繰り返し送信の回数は、pusch-AggregationFactor-r16によって示されてもよい。また、端末装置1にpusch-AggregationFactorが設定され、且つ、pusch-AggregationFactor-r16が設定されない場合、端末装置1は、第1のスロットアグリゲーション送信が適用されることとみなしてもよい。また、端末装置1にpusch-AggregationFactorとpusch-AggregationFactor-r16が設定されない場合、端末装置1は、アグリゲーション送信が適用されないこととみなし、上りリンクグラントがスケジュールされるPUSCHを1回送信してもよい。本実施形態において、上位層のパラメータ(例えば、repTxWithinSlot-r16)が設定されることは、上位層のパラメータ(例えば、repTxWithinSlot-r16)が有効にセットされることを意味してもよいし、上位層のパラメータ(例えば、repTxWithinSlot-r16)が基地局装置3から送信されることを意味してもよい。本実施形態において、上位層のパラメータ(例えば、repTxWithinSlot-r16)が設定されないことは、上位層のパラメータ(例えば、repTxWithinSlot-r16)が無効に設定されることを意味してもよいし、上位層のパラメータ(例えば、repTxWithinSlot-r16)が基地局装置3から送信されないことを意味してもよい。

0190

本実施形態の態様Bにおいて、基地局装置3は、スロットアグリゲーション送信とミニスロットアグリゲーション送信の内何れを設定するかを上位層のパラメータによって端末装置1に通知してもよい。pusch-AggregationFactorは第1のスロットアグリゲーション
送信の繰り返し送信の回数を示すために用いられてもよい。pusch-AggregationFactor-r16は第2のスロットアグリゲーション送信および/またはミニスロットアグリゲーション送信の繰り返し送信の回数を示すために用いられてもよい。pusch-AggregationFactor-r16は、第2のスロットアグリゲーション送信および/またはミニスロットアグリゲーション送信に対して、共通のパラメータであってもよい。端末装置1にpusch-AggregationFactor-r16が設定されている場合、端末装置1に対して第2のスロットアグリゲーション送信および/またはミニスロットアグリゲーション送信が適用されてもよい。

0191

続いて、端末装置1は、PUSCH送信(PUSCH繰り返し送信)をスケジュールする上りリンクグラントに含まれるフィールドに基づいて、さらにスロットアグリゲーション送信またはミニスロットアグリゲーション送信の内何れが適用されるかを決定してもよい。一例として、上りリンクグラントに含まれるあるフィールドは、スロットアグリゲーション送信またはミニスロットアグリゲーション送信の内何れが適用されるかを示すために用いられてもよい。そのフィールドが1ビットであってもよい。また、端末装置1は、基地局装置3から送信された上りリンクグラントに含まれる該フィールドに基づいて、スロットアグリゲーション送信またはミニスロットアグリゲーション送信の内何れが適用されるかを決定してもよい。端末装置1は、該フィールドが0を示した場合にスロットアグリゲーション送信が適用されることを決定し、該フィールドが1を示した場合にミニスロットアグリゲーション送信が適用されることを決定してもよい。

0192

また、一例として、端末装置1は、基地局装置3から送信された上りリンクグラントに含まれる‘Time domain resource assignment’フィールドに基づいて、スロットアグリ
ゲーション送信またはミニスロットアグリゲーション送信の内何れが適用されるかを決定してもよい。前述のように、‘Time domain resource assignment’フィールドはPUS
CH時間領域リソース割り当てを示すために用いられる。端末装置1は、‘Time domain resource assignment’フィールドに基づき得られた連続的な割り当てられるシンボル数
Lが所定の値を超えているかどうかに基づいて、スロットアグリゲーション送信またはミニスロットアグリゲーション送信の内何れが適用されるかを決定してもよい。端末装置1は、シンボル数Lが所定の値を超えている場合に、スロットアグリゲーション送信が適用されることを決定してもよい。また、端末装置1は、シンボル数Lが所定の値を超えていない場合に、ミニスロットアグリゲーション送信が適用されることを決定してもよい。所定の値は、上位層のパラメータから示された値であってもよい。所定の値は、仕様書などで事前に定義された値であってもよい。例えば、所定の値は7シンボルであってもよい。

0193

本実施形態の態様Cにおいて、基地局装置3は、スロットアグリゲーション送信とミニスロットアグリゲーション送信の内何れを設定するかを上位層のパラメータによって端末
装置1に通知してもよい。例えば、基地局装置3は、第2のスロットアグリゲーション送信とミニスロットアグリゲーション送信のそれぞれに対して、繰り返し送信の回数を示す上位層のパラメータを個別に設定してもよい。例えば、pusch-AggregationFactor-r16は
第2のスロットアグリゲーション送信の繰り返し送信の回数を示すために用いられてもよい。pusch-MiniAggregationFactor-r16はミニスロットアグリゲーション送信の繰り返し
送信の回数を示すために用いられてもよい。基地局装置3は、端末装置1に第2のスロットアグリゲーション送信とミニスロットアグリゲーション送信の内何れかを設定しようとする場合に、対応する上位層のパラメータを送信してもよい。つまり、基地局装置3がpusch-AggregationFactor-r16を端末装置1に送信する場合、端末装置1は、第1のスロットアグリゲーション送信が適用されることをみなしてもよい。基地局装置3がpusch-MiniAggregationFactor-r16を端末装置1に送信する場合、端末装置1は、ミニスロットアグリゲーション送信が適用されることをみなしてもよい。

0194

また、本実施形態の態様A,態様B、または、態様Cにおいて、端末装置1は、上りリンクグラントに含まれる‘Time domain resource assignment’フィールドに基づき得ら
れたPUSCHマッピングタイプに基づいて、スロットアグリゲーション送信またはミニスロットアグリゲーション送信の内何れが適用されるかを決定してもよい。具体的に言うと、第2のスロットアグリゲーション送信および/またはミニスロットアグリゲーション送信が適用される場合に、端末装置1は、‘Time domain resource assignment’フィー
ルドに基づき得られたPUSCHマッピングタイプがPUSCHマッピングタイプAである場合に、第2のスロットアグリゲーション送信および/またはミニスロットアグリゲーション送信が適用されないこととみなしてもよい。そして、もしpusch-AggregationFactorが基地局装置3から送信されているならば、端末装置1は、上りリンクグラントがスケジュールするPUSCH送信に第1のスロットアグリゲーション送信が適用されることを決定してもよい。そのスロットアグリゲーション送信の繰り返し送信の回数は、pusch-AggregationFactorによって示される。もしpusch-AggregationFactorが基地局装置3から送信されないならば、端末装置1は、上りリンクグラントがスケジュールするPUSCHを1回送信してもよい。別の言い方で、端末装置1および基地局装置3は、第1の条件を満たす場合、pusch-AggregationFactorが設定されている場合に、それぞれのスロットでは同じシンボルアロケーション(シンボル割り当て)を適用して、トランスポートブロックを連続的なN個のスロットでN回繰り返し送信し、pusch-AggregationFactorが設定されていない場合に、トランスポートブロックを1回送信し、第2の条件を満たす場合、前述のような第2のアグリゲーション送信を適用してトランスポートブロックを送信してもよい。ここで、第1の条件は、PUSCH送信をスケジュールするDCIで、PUSCHマッピングタイプがタイプAに示されることを少なくとも含む。第2の条件は、PUSCH送信をスケジュールするDCIで、PUSCHマッピングタイプがタイプBに示されることを少なくとも含む。Nの値はpusch-AggregationFactorに与えられる。つまり、第2のスロットアグリゲーション送信および/またはミニスロットアグリゲーション送信が適用されるPUSCHのマッピングタイプは、タイプBであってもよい。第1のスロットアグリゲーション送信が適用されるPUSCHのマッピングタイプは、タイプAであってもよいし、タイプBであってもよい。

0195

以下、本実施形態における繰り返し送信回数の決定と周波数ホッピングのプロシージャについて説明する。

0196

端末装置1は、Ntotalを確定してもよい。Ntotalは1つの上りリンクグラントでスケジュールされる同じトランスポートブロックが繰り返し送信されるトータル回数(繰り返し送信されるトータルPUSCH数)である。別の言い方で、Ntotalは、1つの上りリ
ンクグラントでスケジュールされる1つまたは複数のPUSCH数である。端末装置1は、Nrepを確定してもよい。Nrepは、スロット内で同じトランスポートブロックが繰り返し送信される回数(繰り返し送信されるPUSCH数)である。別の言い方で、Nrepは、1つの上りリンクグラントでスケジュールされる1つまたは複数のPUSCHに対して有るスロット内に配置される1つまたは複数のPUSCH数である。端末装置1は、Nslotsを確定してもよい。Nslotsは、1つの上りリンクグラントでスケジュールされる同じトランスポートブロックが繰り返し送信されるスロット数である。別の言い方で、Nslotsは、1つの上りリンクグラントでスケジュールされる1つまたは複数のPUSCHに対
して使われるスロット数である。端末装置1は、NtotalをNrepとNslotsから導出して
もよい。端末装置1は、NrepをNtotalとNslotsから導出してもよい。端末装置1は、
NslotsをNrepとNtotalから導出してもよい。Nslotsは、1または2かもしれない。Nrepは、スロット間で異なる値かもしれない。Nrepは、スロット間で同じ値かもしれない。
端末装置1には上位層のパラメータfrequencyHoppingが設定(提供)されてもよい。上位層のパラメータfrequencyHoppingは、‘intraSlot’と‘interSlot’の内何れかにセットされてもよい。frequencyHoppingが‘intraSlot’にセットされている場合、端末装置1
は、スロット内周波数ホッピングを伴うPUSCH送信を実行してもよい。すなわち、端末装置1にスロット内周波数ホッピングが設定されることは、frequencyHoppingが‘intraSlot’にセットされ、且つ、そのPUSCHをスケジュールするDCIに含まれる‘Frequency hopping flag’フィールドの値が1にセットされることを意味してもよい。frequencyHoppingが‘interSlot’にセットされている場合、端末装置1は、スロット間周波数ホッピングを伴うPUSCH送信を実行してもよい。すなわち、端末装置1にスロット間周波数ホッピングが設定されることは、frequencyHoppingが‘interSlot’にセットされ、且つ、そのPUSCHをスケジュールするDCIに含まれる‘Frequency hopping flag’フィールドの値が1にセットされることを意味してもよい。また、基地局装置3がfrequencyHoppingを端末装置1に送信しない場合、端末装置1は周波数ホッピングなしPUSCH送信を実行してもよい。すなわち、端末装置1には周波数ホッピングが設定されないことは、frequencyHoppingが送信されないことを含んでもよい。また、端末装置1には周波数ホッピングが設定されないことは、frequencyHoppingが送信されても、そのPUSCHをスケジュールするDCIに含まれる‘Frequency hopping flag’フィールドの値が0にセットされることを含んでもよい。

0197

図8は本実施形態における周波数ホッピングの一例を示す図である。図8(a)は周波数ホッピングなしPUSCH送信の一例である。図8(b)はスロット内周波数ホッピング(intra-slot frequency hopping)を伴うPUSCH送信の一例である。図8(c)はスロット間周波数ホッピング(inter-slot frequency hopping)を伴うPUSCH送信の一例である。図8は、スロットアグリゲーション送信に適用されてもよい。図8は、1つのスロット内で繰り返し送信の回数が1のミニスロットアグリゲーション送信に適用されてもよい。

0198

図8(b)において、スロット内周波数ホッピングを伴うPUSCH送信は,スロット
において、第1の周波数ホップ(first frequency hop、第1のホップ、第1の周波数単
位)と第2の周波数ホップ(second frequency hop、第1のホップ、第2の周波数単位)から成る。第1の周波数ホップのシンボル数はFloor(NPUSCH,ssymb/2)によって与えられてもよい。第2の周波数ホップのシンボル数はNPUSCH,ssymb−Floor(NPUSCH,ssymb/2)によって与えられてもよい。NPUSCH,ssymbは、1つのスロット内のOFDMシンボルにおける1つのPUSCH送信の長さである。つまり、NPUSCH,ssymbは、1つのスロット内のスケジュールされる1つのPUSCHに使われるOFDMシンボルの数であってもよい。NPUSCH,ssymbの値は、DCIフォーマットまたはRARULグラントに含まれるフィールドに示されてもよい。NPUSCH,ssymbは、該トランスポートブロックの送信をスケジュールする上りリンクグラントに含まれる‘Time domain resource assignment’フィールドに基づき得られた連続的な割り当てられるシンボル数であってもよい。第1の周波数ホップの開始RB(starting RB)と第1の周波数ホップの開始RB間のリソースブロックの差RBoffsetをリソースブロックの周波数オフセットと称してもよい。つまり、RBoffsetは2つの周波数ホップ間のRBの周波数オフセットである。また、RBoffsetを第2の周波数ホップのための周波数オフセットと称してもよい。例えば、第1の周波数ホップの開始RBをRBstartと称する。第2の周波数ホップの開始RBは、(式5)(RBstart+RBoffset) mod NsizeBWPによって与えられてもよい。RBstartはPUSCHをスケジュールするDCIに含まれる周波数リソース割り当てフィールドによって与えられてもよい。NsizeBWPはアクテイベーされているBWPのサイズ(物理リソースブロックの数)である。関数(A) mod (B)は、AとBの割り算をし、割り切れない余り数字をを出力する。周波数オフセットRBoffsetの値は、PUSCH-Configに含まれる上位層のパラメータfrequencyHoppingOffsetListsによって設定される。上位層のパラメータfrequencyHoppingOffsetListsは、周波数ホッピングが適用される時に、周波数オフセット(周波数ホッピングオフセット)値のセットを示すために用いられる。図8(b)において、スロット内周波数ホッピングはシングルスロットPUSCH送信および/またはマルチスロット(スロットアグリゲーション)PUSCH送信に適用されてもよい。

0199

図8(c)において、スロット間周波数ホッピングはマルチスロットPUSCH送信(multi-slot PUSCH transmission)に適用されてもよい。RBoffsetは2つの周波数ホップ間のRBの周波数オフセットである。あるスロットで送信されるPUSCHの開始RBは、該スロットの番号nusに基づいて決定されてもよい。nus mod 2が0である場合に、該スロット内のPUSCHの開始RBはRBstartである。nus mod 2が1である場合に、該スロット内のPUSCHの開始RBは、(式5)(RBstart+RBoffset) mod NsizeBWPによっ
て与えられてもよい。RBstartはPUSCHをスケジュールするDCIに含まれる周波数リソ
ス割り当てフィールドによって与えられてもよい。図8(c)において、端末装置1は、同じトランスポートブロックを連続的な2つのスロットで繰り返し送信する。

0200

スロット内周波数ホッピングはシングルスロット送信またはスロットアグリゲーション送信に適用されてもよい。スロット間周波数ホッピングはスロットアグリゲーション送信に適用されてもよい。

0201

図9は本実施形態における繰り返し送信回数の決定と周波数ホッピングの他の一例を示す図である。図9(a)は周波数ホッピングなしPUSCH送信の一例である。図9(b)はスロット内周波数ホッピング(intra-slot frequency hopping)を伴うPUSCH送信の一例である。図9(c)はスロット内周波数ホッピング(intra-slot frequency hopping)を伴うPUSCH送信の他の一例である。図9(d)はスロット間周波数ホッピング(inter-slot frequency hopping)を伴うPUSCH送信の一例である。図9は、スロットアグリゲーション送信に適用されてもよい。図9で示すような周波数ホッピングはミニスロットアグリゲーション送信に適用されてもよい。または、図9で示すような周波数ホッピングは1つのスロット内で繰り返し送信の回数が1より多いミニスロットアグリゲーション送信に適用されてもよい。
図9(a)は、周波数ホッピングが設定されておらず、スロットアグリゲーションが設定されていない、または、スロットアグリゲーション送信回数が1、かつミニスロットアグリゲーション送信回数が4の場合を示している。この時、Nrep=4、Ntotal=1、Nslots=1である。

ページトップへ

この技術を出願した法人

この技術を発明した人物

ページトップへ

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

関連する公募課題

ページトップへ

技術視点だけで見ていませんか?

この技術の活用可能性がある分野

分野別動向を把握したい方- 事業化視点で見る -

ページトップへ

おススメ サービス

おススメ astavisionコンテンツ

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

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

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

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

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

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

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

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

関連性が強い 技術一覧

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

関連性が強い人物一覧

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

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

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

関連する公募課題一覧

astavision 新着記事

サイト情報について

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

主たる情報の出典

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