JP2020162019A - 基地局装置、端末装置、通信方法、および、集積回路 - Google Patents

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

Info

Publication number
JP2020162019A
JP2020162019A JP2019060243A JP2019060243A JP2020162019A JP 2020162019 A JP2020162019 A JP 2020162019A JP 2019060243 A JP2019060243 A JP 2019060243A JP 2019060243 A JP2019060243 A JP 2019060243A JP 2020162019 A JP2020162019 A JP 2020162019A
Authority
JP
Japan
Prior art keywords
pusch
dci
pdsch
value
terminal device
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
JP2019060243A
Other languages
English (en)
Inventor
麗清 劉
Liqing Liu
麗清 劉
山田　昇平
Shohei Yamada
昇平 山田
星野　正幸
Masayuki Hoshino
正幸 星野
高橋　宏樹
Hiroki Takahashi
宏樹 高橋
秀和 坪井
Hidekazu Tsuboi
秀和 坪井
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
FG Innovation Co Ltd
Sharp Corp
Original Assignee
FG Innovation Co Ltd
Sharp Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by FG Innovation Co Ltd, Sharp Corp filed Critical FG Innovation Co Ltd
Priority to JP2019060243A priority Critical patent/JP2020162019A/ja
Priority to PCT/JP2020/008215 priority patent/WO2020195531A1/ja
Priority to US17/442,997 priority patent/US20220191912A1/en
Publication of JP2020162019A publication Critical patent/JP2020162019A/ja
Pending legal-status Critical Current

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W72/00—Local resource management
    • H04W72/20—Control channels or signalling for resource management
    • H04W72/23—Control channels or signalling for resource management in the downlink direction of a wireless link, i.e. towards a terminal
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W72/00—Local resource management
    • H04W72/12—Wireless traffic scheduling
    • H04W72/1263—Mapping of traffic onto schedule, e.g. scheduled allocation or multiplexing of flows
    • H04W72/1268—Mapping of traffic onto schedule, e.g. scheduled allocation or multiplexing of flows of uplink data flows

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

【課題】端末装置と基地局装置が効率的に通信を行うこと。【解決手段】端末装置１は、第３のＤＣＩを受信し、第１のＰＵＳＣＨの送信を決定する。第１のＰＵＳＣＨは、第３のＤＣＩによってスケジュールされ、第１の条件（アウトオブオーダーＰＵＳＣＨ送信）を満たさない場合、第１のＰＵＳＣＨのための第１のＰＵＳＣＨ手順準備時間の値は、第１の値であり、第１の条件（アウトオブオーダーＰＵＳＣＨ送信）を満たす場合、第１のＰＵＳＣＨ手順準備時間の値は、第１の値に第２の値を加算した値である。端末１は、第３のＤＣＩと第１のＰＵＳＣＨとの間のシンボル数が第１のＰＵＳＣＨ手順準備時間の値に対応するシンボルの数と等しいまたは多い場合、第１のＰＵＳＣＨの送信を決定する。【選択図】図２１

Description

本発明は、基地局装置、端末装置、通信方法、および、集積回路に関する。
現在、第５世代のセルラーシステムに向けた無線アクセス方式および無線ネットワーク技術として、第三世代パートナーシッププロジェクト（3GPP: The Third Generation Partnership Project）において、LTE（Long Term Evolution）-Advanced Pro及びNR（New Radio technology）の技術検討及び規格策定が行われている（非特許文献１）。
第５世代のセルラーシステムでは、高速・大容量伝送を実現するeMBB（enhanced Mobile BroadBand）、低遅延・高信頼通信を実現するURLLC（Ultra-Reliable and Low Latency Communication）、IoT（Internet of Things）などマシン型デバイスが多数接続するmMTC（massive Machine Type Communication）の3つがサービスの想定シナリオとして要求されている。
RP-161214, NTT DOCOMO, "Revision of SI: Study on New Radio Access Technology", 2016年6月
本発明の目的は、上記のような無線通信システムにおいて、効率的な通信を可能とする端末装置、基地局装置、通信方法、および、集積回路を提供することを目的とする。
（１）上記の目的を達成するために、本発明の態様は、以下のような手段を講じた。すなわち、本発明の一態様における端末装置は、第３のＤＣＩを受信する受信部と、第１のＰＵＳＣＨの送信を決定する決定部と、を備え、前記第１のＰＵＳＣＨは前記第３のＤＣＩによってスケジュールされ、第１の条件を満たさない場合、前記第１のＰＵＳＣＨのための第１のＰＵＳＣＨ手順準備時間の値は、第１の値であり、第１の条件を満たす場合、前記第１のＰＵＳＣＨ手順準備時間の値は、前記第１の値に第２の値を加算した値であり、前記決定部は、前記第３のＤＣＩと前記第１のＰＵＳＣＨとの間のシンボル数が前記第１のＰＵＳＣＨ手順準備時間の値に対応するシンボルの数と等しいまたは多い場合、前記第１のＰＵＳＣＨの送信を決定する。
（２）また、本発明の一態様における基地局装置は、第３のＤＣＩを送信する送信部と、第１のＰＵＳＣＨの受信を決定する決定部と、を備え、前記第１のＰＵＳＣＨは前記第３のＤＣＩによってスケジュールされ、第１の条件を満たさない場合、前記第１のＰＵＳＣＨのための第１のＰＵＳＣＨ手順準備時間の値は、第１の値であり、第１の条件を満たす場合、前記第１のＰＵＳＣＨ手順準備時間の値は、前記第１の値に第２の値を加算した値であり、前記決定部は、前記第３のＤＣＩと前記第１のＰＵＳＣＨとの間のシンボル数が前記第１のＰＵＳＣＨ手順準備時間の値に対応するシンボルの数と等しいまたは多い場合、前記第１のＰＵＳＣＨの受信を決定する。
（３）また、本発明の一態様における通信方法は、端末装置の通信方法であって、第３のＤＣＩを受信し、第１のＰＵＳＣＨの送信し、前記第１のＰＵＳＣＨは前記第３のＤＣ
Ｉによってスケジュールされ、前記第１のＰＵＳＣＨのための第１のＰＵＳＣＨ手順準備時間の値は、第１の値であり、第１の条件を満たす場合、第１の条件を満たさない場合、前記第１のＰＵＳＣＨ手順準備時間の値は、前記第１の値に第２の値を加算した値であり、前記決定部は、前記第３のＤＣＩと前記第１のＰＵＳＣＨとの間のシンボル数が前記第１のＰＵＳＣＨ手順準備時間の値に対応するシンボルの数と等しいまたは多い場合、前記第１のＰＵＳＣＨの送信を決定する。
（４）また、本発明の一態様における通信方法は、基地局装置の通信方法であって、第３のＤＣＩを送信し、第１のＰＵＳＣＨの受信を決定し、前記第１のＰＵＳＣＨは前記第３のＤＣＩによってスケジュールされ、第１の条件を満たさない場合、前記第１のＰＵＳＣＨのための第１のＰＵＳＣＨ手順準備時間の値は、第１の値であり、第１の条件を満たす場合、前記第１のＰＵＳＣＨ手順準備時間の値は、前記第１の値に第２の値を加算した値であり、前記決定部は、前記第３のＤＣＩと前記第１のＰＵＳＣＨとの間のシンボル数が前記第１のＰＵＳＣＨ手順準備時間の値に対応するシンボルの数と等しいまたは多い場合、前記第１のＰＵＳＣＨの受信を決定する。
この発明によれば、基地局装置と端末装置が、効率的に通信することができる。
本発明の実施形態に係る無線通信システムの概念を示す図である。 本発明の実施形態に係るＳＳ／ＰＢＣＨブロックおよびＳＳバーストセットの例を示す図である。 本発明の実施形態に係る上りリンクおよび下りリンクスロットの概略構成の一例を示す図である。 本発明の実施形態に係るサブフレーム、スロット、ミニスロットの時間領域における関係を示した図である。 本発明の実施形態に係るスロットまたはサブフレームの一例を示す図である。 本発明の実施形態に係るビームフォーミングの一例を示した図である。 本発明の実施形態に係るＰＤＳＣＨマッピングタイプの一例を示す図である。 本発明の実施形態に係るＤＣＩを伴うＰＤＣＣＨによってスケジュールされるＰＤＳＣＨ受信と対応するＨＡＲＱ−ＡＣＫの送信の一例を示す図。 本発明の実施形態に係るＤＣＩを伴うＰＤＣＣＨによってスケジュールされるＰＵＳＣＨを送信する一例を示す図である。 本発明の実施形態に係るどのリソース割り当てテーブルをＰＤＳＣＨ時間領域リソース割り当てに適用するかを定義する図である。 本発明の実施形態に係るＰＤＳＣＨに適用するリソース割り当てテーブルの決定法を示すテーブルの一例である。 本発明の実施形態に係るＰＤＳＣＨに適用するリソース割り当てテーブルの決定法を示すテーブルの別の一例である。 本発明の実施形態に係るデフォルトテーブルＡの一例を示す図である。 本発明の実施形態に係るデフォルトテーブルＢの一例を示す図である。 本発明の実施形態に係るデフォルトテーブルＣの一例を示す図である。 本発明の実施形態に係るＳＬＩＶを算出する一例を示す図である。 本実施形態に係るどのリソース割り当てテーブルをＰＵＳＣＨ時間領域リソース割り当てに適用するかを定義する図である。 本実施形態に係るＰＵＳＣＨデフォルトテーブルＡの一例を示す図である。 本発明の実施形態に係るＰＵＳＣＨに適用するリソース割り当てテーブルの決定法を示すテーブルの一例である。 本発明の実施形態に係るＰＵＳＣＨに適用するリソース割り当てテーブルの決定法を示すテーブルの別の一例である。 本発明の実施形態に係る端末装置１の構成を示す概略ブロック図である。 本発明の実施形態に係る基地局装置３の構成を示す概略ブロック図である。
以下、本発明の実施形態について説明する。
図１は、本実施形態における無線通信システムの概念図である。図１において、無線通信システムは、端末装置１Ａ、端末装置１Ｂ、および基地局装置３を具備する。以下、端末装置１Ａ、および、端末装置１Ｂを、端末装置１とも称する。
端末装置１は、ユーザ端末、移動局装置、通信端末、移動機、端末、ＵＥ（User Equipment）、ＭＳ（Mobile Station）とも称される。基地局装置３は、無線基地局装置、基地局、無線基地局、固定局、ＮＢ（Node B）、ｅＮＢ（evolved Node B）、ＢＴＳ（Base Transceiver Station）、ＢＳ（Base Station）、ＮＲ ＮＢ（NR Node B）、ＮＮＢ、ＴＲＰ（Transmission and Reception Point）、ｇＮＢとも称される。基地局装置３は、コアネットワーク装置を含んでも良い。また、基地局装置３は、１つまたは複数の送受信点４（ｔｒａｎｓｍｉｓｓｉｏｎ ｒｅｃｅｐｔｉｏｎ ｐｏｉｎｔ）を具備しても良い。以下で説明する基地局装置３の機能／処理の少なくとも一部は、該基地局装置３が具備する各々の送受信点４における機能／処理であってもよい。基地局装置３は、基地局装置３によって制御される通信可能範囲（通信エリア）を１つまたは複数のセルとして端末装置１をサーブしてもよい。また、基地局装置３は、１つまたは複数の送受信点４によって制御される通信可能範囲（通信エリア）を１つまたは複数のセルとして端末装置１をサーブしてもよい。また、基地局装置３は、１つのセルを複数の部分領域（Ｂｅａｍｅｄ ａｒｅａ）にわけ、それぞれの部分領域において端末装置１をサーブしてもよい。ここで、部分領域は、ビームフォーミングで使用されるビームのインデックスあるいはプリコーディングのインデックスに基づいて識別されてもよい。
基地局装置３から端末装置１への無線通信リンクを下りリンクと称する。端末装置１から基地局装置３への無線通信リンクを上りリンクと称する。
図１において、端末装置１と基地局装置３の間の無線通信では、サイクリックプレフィックス（CP: Cyclic Prefix）を含む直交周波数分割多重（OFDM: Orthogonal Frequency Division Multiplexing）、シングルキャリア周波数多重（SC-FDM: Single-Carrier Frequency Division Multiplexing）、離散フーリエ変換拡散ＯＦＤＭ（DFT-S-OFDM: Discrete Fourier Transform Spread OFDM）、マルチキャリア符号分割多重（MC-CDM: Multi-Carrier Code Division Multiplexing）が用いられてもよい。
また、図１において、端末装置１と基地局装置３の間の無線通信では、ユニバーサルフィルタマルチキャリア（UFMC: Universal-Filtered Multi-Carrier）、フィルタＯＦＤＭ（F-OFDM: Filtered OFDM）、窓関数が乗算されたＯＦＤＭ（Windowed OFDM）、フィルタバンクマルチキャリア（FBMC: Filter-Bank Multi-Carrier）が用いられてもよい。
なお、本実施形態ではＯＦＤＭを伝送方式としてＯＦＤＭシンボルで説明するが、上述の他の伝送方式の場合を用いた場合も本発明に含まれる。
また、図１において、端末装置１と基地局装置３の間の無線通信では、ＣＰを用いない、あるいはＣＰの代わりにゼロパディングをした上述の伝送方式が用いられてもよい。また、ＣＰやゼロパディングは前方と後方の両方に付加されてもよい。
本実施形態の一態様は、ＬＴＥやＬＴＥ−Ａ／ＬＴＥ−Ａ Ｐｒｏといった無線アクセス技術（RAT: Radio Access Technology）とのキャリアアグリゲーションまたはデュアルコネクティビティにおいてオペレーションされてもよい。このとき、一部またはすべてのセルまたはセルグループ、キャリアまたはキャリアグループ（例えば、プライマリセル（PCell: Primary Cell）、セカンダリセル（SCell: Secondary Cell）、プライマリセカンダリセル（PSCell）、ＭＣＧ（Master Cell Group）、ＳＣＧ（Secondary Cell Group）など）で用いられてもよい。また、単独でオペレーションするスタンドアローンで用いられてもよい。デュアルコネクティビティオペレーションにおいては、ＳｐＣｅｌｌ（Special Cell）は、ＭＡＣ（MAC: Medium Access Control）エンティティがＭＣＧに関連付けられているか、ＳＣＧに関連付けられているかに応じて、それぞれ、ＭＣＧのPCellまたは、SCGのPSCellと称する。デュアルコネクティビティオペレーションでなければ、ＳｐＣｅｌｌ（Special Cell）は、PCellと称する。ＳｐＣｅｌｌ（Special Cell）は、ＰＵＣＣＨ送信と、競合ベースランダムアクセスをサポートする。
本実施形態では、端末装置１に対して１つまたは複数のサービングセルが設定されてもよい。設定された複数のサービングセルは、１つのプライマリセルと１つまたは複数のセカンダリセルとを含んでもよい。プライマリセルは、初期コネクション確立（initial connection establishment）プロシージャが行なわれたサービングセル、コネクション再確立（connection re-establishment）プロシージャを開始したサービングセル、または、ハンドオーバプロシージャにおいてプライマリセルと指示されたセルであってもよい。ＲＲＣ（Radio Resource Control）コネクションが確立された時点、または、後に、１つまたは複数のセカンダリセルが設定されてもよい。ただし、設定された複数のサービングセルは、１つのプライマリセカンダリセルを含んでもよい。プライマリセカンダリセルは、端末装置１が設定された１つまたは複数のセカンダリセルのうち、上りリンクにおいて制御情報を送信可能なセカンダリセルであってもよい。また、端末装置１に対して、マスターセルグループとセカンダリセルグループの２種類のサービングセルのサブセットが設定されてもよい。マスターセルグループは１つのプライマリセルと０個以上のセカンダリセルで構成されてもよい。セカンダリセルグループは１つのプライマリセカンダリセルと０個以上のセカンダリセルで構成されてもよい。
本実施形態の無線通信システムは、ＴＤＤ（Time Division Duplex）および／またはＦＤＤ（Frequency Division Duplex）が適用されてよい。複数のセルの全てに対してＴＤ
Ｄ（Time Division Duplex）方式またはＦＤＤ（Frequency Division Duplex）方式が適
用されてもよい。また、ＴＤＤ方式が適用されるセルとＦＤＤ方式が適用されるセルが集約されてもよい。ＴＤＤ方式はアンペアードスペクトラムオペレーション（Unpaired spectrum operation）と称されてもよい。ＦＤＤ方式はペアードスペクトラムオペレーション（Paired spectrum operation）と称されてもよい。
下りリンクにおいて、サービングセルに対応するキャリアを下りリンクコンポーネントキャリア（あるいは下りリンクキャリア）と称する。上りリンクにおいて、サービングセルに対応するキャリアを上りリンクコンポーネントキャリア（あるいは上りリンクキャリア）と称する。サイドリンクにおいて、サービングセルに対応するキャリアをサイドリンクコンポーネントキャリア（あるいはサイドリンクキャリア）と称する。下りリンクコンポーネントキャリア、上りリンクコンポーネントキャリア、および／またはサイドリンクコンポーネントキャリアを総称してコンポーネントキャリア（あるいはキャリア）と称する。
本実施形態の物理チャネルおよび物理信号について説明する。
図１において、端末装置１と基地局装置３の無線通信では、以下の物理チャネルが用いられる。
・ＰＢＣＨ（物理報知チャネル：Physical Broadcast CHannel）
・ＰＤＣＣＨ（物理下りリンク制御チャネル：Physical Downlink Control CHannel）
・ＰＤＳＣＨ（物理下りリンク共用チャネル：Physical Downlink Shared CHannel）
・ＰＵＣＣＨ（物理上りリンク制御チャネル：Physical Uplink Control CHannel）
・ＰＵＳＣＨ（物理上りリンク共用チャネル：Physical Uplink Shared CHannel）
・ＰＲＡＣＨ（物理ランダムアクセスチャネル：Physical Random Access CHannel）
ＰＢＣＨは、端末装置１が必要な重要なシステム情報を含む重要情報ブロック（MIB: Master Information Block、EIB: Essential Information Block、ＢＣＨ：Broadcast Channel）を報知するために用いられる。
また、ＰＢＣＨは、同期信号のブロック（ＳＳ／ＰＢＣＨブロックとも称する）の周期内の時間インデックスを報知するために用いられてよい。ここで、時間インデックスは、セル内の同期信号およびＰＢＣＨのインデックスを示す情報である。例えば、３つの送信ビーム（送信フィルタ設定、受信空間パラメータに関する擬似同位置（ＱＣＬ：Quasi Co-Location））の想定を用いてＳＳ／ＰＢＣＨブロックを送信する場合、予め定められた周期内または設定された周期内の時間順を示してよい。また、端末装置は、時間インデックスの違いを送信ビームの違いと認識してもよい。
ＰＤＣＣＨは、下りリンクの無線通信（基地局装置３から端末装置１への無線通信）において、下りリンク制御情報（Downlink Control Information: DCI）を送信する（また
は運ぶ）ために用いられる。ここで、下りリンク制御情報の送信に対して、１つまたは複数のＤＣＩ（ＤＣＩフォーマットと称してもよい）が定義される。すなわち、下りリンク制御情報に対するフィールドがＤＣＩとして定義され、情報ビットへマップされる。ＰＤＣＣＨは、ＰＤＣＣＨ候補において送信される。端末装置１は、サービングセルにおいてＰＤＣＣＨ候補（candidate）のセットをモニタする。モニタすることは、あるＤＣＩフ
ォーマットに応じてＰＤＣＣＨのデコードを試みることを意味する。
例えば、以下のＤＣＩフォーマットが定義されてよい。
・ＤＣＩフォーマット０＿０
・ＤＣＩフォーマット０＿１
・ＤＣＩフォーマット０＿２
・ＤＣＩフォーマット１＿０
・ＤＣＩフォーマット１＿１
・ＤＣＩフォーマット１＿２
・ＤＣＩフォーマット２＿０
・ＤＣＩフォーマット２＿１
・ＤＣＩフォーマット２＿２
・ＤＣＩフォーマット２＿３
ＤＣＩフォーマット０＿０は、あるサービングセルにおけるＰＵＳＣＨのスケジューリングのために用いられてもよい。ＤＣＩフォーマット０＿０は、ＰＵＳＣＨのスケジューリング情報（周波数領域リソース割り当て及び時間領域リソース割り当て）を示す情報を含んでよい。ＤＣＩフォーマット０＿０は、識別子であるＲａｄｉｏ Ｎｅｔｗｏｒｋ
Ｔｅｍｐｏｒａｒｙ Ｉｄｅｎｔｉｆｉｅｒ（ＲＮＴＩ）のうち、Ｃｅｌｌ−ＲＮＴＩ（Ｃ−ＲＮＴＩ）、Ｃｏｎｆｉｇｕｒｅｄ Ｓｃｈｅｄｕｌｉｎｇ（ＣＳ）−ＲＮＴＩ）、ＭＣＳ―Ｃ−ＲＮＴＩ、および／または、Ｔｅｍｐｏｒａｒｙ Ｃ−ＮＲＴＩ（ＴＣ−ＲＮＴＩ）の何れかによってスクランブルされるＣＲＣ（Cyclic Redundancy Check）が付加されてもよい。ＤＣＩフォーマット０＿０は、コモンサーチスペースまたはＵＥ固有サーチスペースにおいてモニタされてもよい。
ＤＣＩフォーマット０＿１は、あるサービングセルにおけるＰＵＳＣＨのスケジューリングのために用いられてもよい。ＤＣＩフォーマット０＿１は、ＰＵＳＣＨのスケジューリング情報（周波数領域リソース割り当て及び時間領域リソース割り当て）を示す情報、帯域部分（ＢＷＰ：BandWidth Part）を示す情報、チャネル状態情報（ＣＳＩ：Channel State Information）リクエスト、サウンディング参照信号（ＳＲＳ：Sounding Reference Signal）リクエスト、および／または、アンテナポートに関する情報を含んでよい。ＤＣＩフォーマット０＿１は、ＲＮＴＩのうち、Ｃ−ＲＮＴＩ、ＣＳ−ＲＮＴＩ、Ｓｅｍｉ Ｐｅｒｓｉｓｔｅｎｔ（ＳＰ）−ＣＳＩ−ＲＮＴＩ、および／または、ＭＣＳ―Ｃ−ＲＮＴＩの何れかによってスクランブルされるＣＲＣが付加されてもよい。ＤＣＩフォーマット０＿１は、ＵＥ固有サーチスペースにおいてモニタされてもよい。
ＤＣＩフォーマット０＿２は、あるサービングセルにおけるＰＵＳＣＨのスケジューリングのために用いられてもよい。ＤＣＩフォーマット０＿２は、ＰＵＳＣＨのスケジューリング情報（周波数領域リソース割り当て及び時間領域リソース割り当て）を示す情報、ＢＷＰを示す情報、ＣＳＩリクエスト、ＳＲＳリクエスト、および／または、アンテナポートに関する情報を含んでよい。ＤＣＩフォーマット０＿２は、ＲＮＴＩのうち、Ｃ−ＲＮＴＩ、ＣＳＩ−ＲＮＴＩ、ＳＰ−ＣＳＩ−ＲＮＴＩ、および／または、ＭＣＳ−Ｃ−ＲＮＴＩの何れかによってスクランブルされるＣＲＣが付加されてもよい。ＤＣＩフォーマット０＿２は、ＵＥ固有サーチスペースにおいてモニタされてもよい。ＤＣＩフォーマット０＿２は、ＤＣＩフォーマット０＿１Ａ等と称されるかもしれない。
ＤＣＩフォーマット１＿０は、あるサービングセルにおけるＰＤＳＣＨのスケジューリングのために用いられてもよい。ＤＣＩフォーマット１＿０は、ＰＤＳＣＨのスケジューリング情報（周波数領域リソース割り当て及び時間領域リソース割り当て）を示す情報を含んでよい。ＤＣＩフォーマット１＿０は、識別子のうち、Ｃ−ＲＮＴＩ、ＣＳ−ＲＮＴＩ、ＭＣＳ―Ｃ−ＲＮＴＩ、Ｐａｇｉｎｇ ＲＮＴＩ（Ｐ−ＲＮＴＩ）、Ｓｙｓｔｅｍ Ｉｎｆｏｒｍａｔｉｏｎ（ＳＩ）−ＲＮＴＩ、Ｒａｎｄｏｍ Ａｃｃｅｓｓ（ＲＡ）−ＲＮＴＩ、および／または、ＴＣ−ＲＮＴＩの何れかによってスクランブルされるＣＲＣが付加されてもよい。ＤＣＩフォーマット１＿０は、コモンサーチスペースまたはＵＥ固有サーチスペースにおいてモニタされてもよい。
ＤＣＩフォーマット１＿１は、あるサービングセルにおけるＰＤＳＣＨのスケジューリングのために用いられてもよい。ＤＣＩフォーマット１＿１は、ＰＤＳＣＨのスケジューリング情報（周波数領域リソース割り当て及び時間領域リソース割り当て）を示す情報、帯域部分（ＢＷＰ）を示す情報、送信設定指示（ＴＣＩ：Transmission Configuration Indication）、および／または、アンテナポートに関する情報を含んでよい。ＤＣＩフォ
ーマット１＿１は、ＲＮＴＩのうち、Ｃ−ＲＮＴＩ、ＣＳ−ＲＮＴＩ、および／または、ＭＣＳ―Ｃ−ＲＮＴＩの何れかによってスクランブルされるＣＲＣが付加されてもよい。ＤＣＩフォーマット１＿１は、ＵＥ固有サーチスペースにおいてモニタされてもよい。
ＤＣＩフォーマット１＿２は、あるサービングセルにおけるＰＤＳＣＨのスケジューリングのために用いられてもよい。ＤＣＩフォーマット１＿２は、ＰＤＳＣＨのスケジューリング情報（周波数領域リソース割り当て及び時間領域リソース割り当て）を示す情報、
ＢＷＰを示す情報、ＴＣＩ、および／または、アンテナポートに関する情報を含んでよい。ＤＣＩフォーマット１＿２は、ＲＮＴＩのうち、Ｃ−ＲＮＴＩ、ＣＳ−ＲＮＴＩ、および／または、ＭＣＳ―Ｃ−ＲＮＴＩの何れかによってスクランブルされるＣＲＣが付加されてもよい。ＤＣＩフォーマット１＿２は、ＵＥ固有サーチスペースにおいてモニタされてもよい。ＤＣＩフォーマット１＿２は、ＤＣＩフォーマット１＿１Ａ等と称されるかもしれない。
ＤＣＩフォーマット２＿０は、１つまたは複数のスロットのスロットフォーマットを通知するために用いられる。スロットフォーマットは、スロット内の各ＯＦＤＭシンボルが下りリンク、フレキシブル、上りリンクのいずれかに分類されたものとして定義される。例えば、スロットフォーマットが２８の場合、スロットフォーマット２８が指示されたスロット内の１４シンボルのＯＦＤＭシンボルに対してＤＤＤＤＤＤＤＤＤＤＤＤＦＵが適用される。ここで、Ｄが下りリンクシンボル、Ｆがフレキシブルシンボル、Ｕが上りリンクシンボルである。なお、スロットについては後述する。
ＤＣＩフォーマット２＿１は、端末装置１に対して、送信がないと想定してよい物理リソースブロックとＯＦＤＭシンボルを通知するために用いられる。なお、この情報はプリエンプション指示（間欠送信指示）と称してよい。
ＤＣＩフォーマット２＿２は、ＰＵＳＣＨおよびＰＵＳＣＨのための送信電力制御（ＴＰＣ：Transmit Power Control）コマンドの送信のために用いられる。
ＤＣＩフォーマット２＿３は、１または複数の端末装置１によるサウンディング参照信号（ＳＲＳ）送信のためのＴＰＣコマンドのグループを送信するために用いられる。また、ＴＰＣコマンドとともに、ＳＲＳリクエストが送信されてもよい。また、ＤＣＩフォーマット２＿３に、ＰＵＳＣＨおよびＰＵＣＣＨのない上りリンク、またはＳＲＳの送信電力制御がＰＵＳＣＨの送信電力制御と紐付いていない上りリンクのために、ＳＲＳリクエストとＴＰＣコマンドが定義されてよい。
下りリンクに対するＤＣＩを、下りリンクグラント（downlink grant）、または、下りリンクアサインメント（downlink assignment）とも称する。ここで、上りリンクに対す
るＤＣＩを、上りリンクグラント（uplink grant）、または、上りリンクアサインメント（Uplink assignment）とも称する。ＤＣＩを、ＤＣＩフォーマットとも称してもよい。
１つのＰＤＣＣＨで送信されるＤＣＩフォーマットに付加されるＣＲＣパリティビットは、ＳＩ−ＲＮＴＩ、Ｐ−ＲＮＴＩ、Ｃ−ＲＮＴＩ、ＣＳ−ＲＮＴＩ、ＲＡ−ＲＮＴＩ、または、ＴＣ−ＲＮＴＩでスクランブルされる。ＳＩ−ＲＮＴＩはシステム情報のブロードキャストに使用される識別子であってもよい。Ｐ−ＲＮＴＩは、ページングおよびシステム情報変更の通知に使用される識別子であってもよい。Ｃ−ＲＮＴＩ、ＭＣＳ−Ｃ−ＲＮＴＩ、および、ＣＳ−ＲＮＴＩは、セル内において端末装置を識別するための識別子である。ＴＣ−ＲＮＴＩは、競合ベースのランダムアクセス手順（contention based random access procedure）中に、ランダムアクセスプリアンブルを送信した端末装置１を識別するための識別子である。
Ｃ−ＲＮＴＩは、１つまたは複数のスロットにおけるＰＤＳＣＨまたはＰＵＳＣＨを制御するために用いられる。ＣＳ−ＲＮＴＩは、ＰＤＳＣＨまたはＰＵＳＣＨのリソースを周期的に割り当てるために用いられる。ＭＣＳ−Ｃ−ＲＮＴＩは、グラントベース送信（grant-based transmission）に対して所定のＭＣＳテーブルの使用を示すために用いられる。ＴＣ−ＲＮＴＩは、１つまたは複数のスロットにおけるＰＤＳＣＨ送信またはＰＵＳＣＨ送信を制御するために用いられる。ＴＣ−ＲＮＴＩは、ランダムアクセスメッセージ３の再送信、およびランダムアクセスメッセージ４の送信をスケジュールするために用いられる。ＲＡ−ＲＮＴＩは、ランダムアクセスプリアンブルを送信した物理ランダムアクセスチャネルの周波数および時間の位置情報に応じて決定される。
Ｃ−ＲＮＴＩおよび／またはその他のＲＮＴＩは、ＰＤＳＣＨまたはＰＵＳＣＨのトラフィックのタイプに対応して異なる値が用いられてもよい。Ｃ−ＲＮＴＩおよびその他のＲＮＴＩは、ＰＤＳＣＨまたはＰＵＳＣＨで伝送されるデータのサービスタイプ（ｅＭＢＢ、ＵＲＬＬＣ、および／または、ｍＭＴＣ）に対応して異なる値が用いられてもよい。基地局装置３は、送信するデータのサービスタイプに対応して異なる値のＲＮＴＩを用いてもよい。端末装置１は、受信したＤＣＩに適用された（スクランブルに用いられた）ＲＮＴＩの値によって、関連するＰＤＳＣＨまたはＰＵＳＣＨで伝送されるデータのサービスタイプを識別してもよい。
ＰＵＣＣＨは、上りリンクの無線通信（端末装置１から基地局装置３の無線通信）において、上りリンク制御情報（Uplink Control Information: UCI）を送信するために用い
られる。ここで、上りリンク制御情報には、下りリンクのチャネルの状態を示すために用いられるチャネル状態情報（CSI: Channel State Information）が含まれてもよい。また、上りリンク制御情報には、ＵＬ−ＳＣＨリソースを要求するために用いられるスケジューリング要求（SR: Scheduling Request）が含まれてもよい。また、上りリンク制御情報には、ＨＡＲＱ−ＡＣＫ（Hybrid Automatic Repeat request ACKnowledgement）が含まれてもよい。ＨＡＲＱ−ＡＣＫは、下りリンクデータ（Transport block, Medium Access Control Protocol Data Unit: MAC PDU, Downlink-Shared Channel: DL-SCH）に対するＨＡＲＱ−ＡＣＫを示してもよい。ＨＡＲＱ−ＡＣＫを、ＡＣＫ／ＮＡＣＫ、ＨＡＲＱフィードバック、ＨＡＲＱ−ＡＣＫフィードバック、ＨＡＲＱ応答、ＨＡＲＱ−ＡＣＫビット、ＨＡＲＱ−ＡＣＫ情報ビット、ＨＡＲＱ−ＡＣＫ応答、ＨＡＲＱ情報、ＨＡＲＱ−ＡＣＫ情報、ＨＡＲＱ制御情報、および、ＨＡＲＱ−ＡＣＫ制御情報とも称する。下りリンクデータが成功裏に復号された場合、該下りリンクデータに対するＡＣＫが生成される。下りリンクデータが成功裏に復号されなかった場合、該下りリンクデータに対するＮＡＣＫが生成される。ＤＴＸ（discontinuous transmission）は、下りリンクデータを検出しなかったことを意味してもよい。ＤＴＸ（discontinuous transmission）は、ＨＡＲＱ−ＡＣＫ応答を送信するべきデータを検出しなかったことを意味してもよい。
ＰＤＳＣＨは、媒介アクセス（MAC: Medium Access Control）層からの下りリンクデータ（DL-SCH: Downlink Shared CHannel）の送信に用いられる。また、下りリンクの場合
にはシステム情報（SI: System Information）やランダムアクセス応答（RAR: Random Access Response）などの送信にも用いられる。
ＰＵＳＣＨは、ＭＡＣ層からの上りリンクデータ（UL-SCH: Uplink Shared CHannel）
または上りリンクデータと共にＨＡＲＱ−ＡＣＫおよび／またはＣＳＩを送信するために用いられてもよい。また、ＣＳＩのみ、または、ＨＡＲＱ−ＡＣＫおよびＣＳＩのみを送信するために用いられてもよい。すなわち、ＵＣＩのみを送信するために用いられてもよい。
ここで、基地局装置３と端末装置１は、上位層（上位レイヤ：higher layer）において信号をやり取り（送受信）する。例えば、基地局装置３と端末装置１は、無線リソース制御（RRC: Radio Resource Control）層において、ＲＲＣシグナリング（RRC message: Radio Resource Control message、RRC information: Radio Resource Control informationとも称される）を送受信してもよい。また、基地局装置３と端末装置１は、ＭＡＣ（Medium Access Control）層において、ＭＡＣコントロールエレメントを送受信してもよい。また、端末装置１のＲＲＣ層は、基地局装置３から報知されるシステム情報を取得する。
ここで、ＲＲＣシグナリング、システム情報、および／または、ＭＡＣコントロールエレメントを、上位層の信号（上位レイヤ信号：higher layer signaling）または上位層のパラメータとも称する。ここでの上位層は、物理層から見た上位層を意味するため、ＭＡＣ層、ＲＲＣ層、ＲＬＣ層、ＰＤＣＰ層、ＮＡＳ（Non Access Stratum）層などの１つまたは複数を含んでもよい。例えば、ＭＡＣ層の処理において上位層とは、ＲＲＣ層、ＲＬＣ層、ＰＤＣＰ層、ＮＡＳ層などの１つまたは複数を含んでもよい。以下、“Ａは、上位層で与えられる”や“Ａは、上位層によって与えられる”の意味は、端末装置１の上位層（主にＲＲＣ層やＭＡＣ層など）が、基地局装置３からＡを受信し、その受信したＡを端末装置１の上位層から端末装置１の物理層に与えることを意味してもよい。端末装置１には上位層のパラメータが設定されることは端末装置に対して上位層のパラメータが提供されることを意味してもよい。
ＰＤＳＣＨまたはＰＵＳＣＨは、ＲＲＣシグナリング、および、ＭＡＣコントロールエレメントを送信するために用いられてもよい。ここで、ＰＤＳＣＨにおいて、基地局装置３から送信されるＲＲＣシグナリングは、セル内における複数の端末装置１に対して共通のシグナリングであってもよい。また、基地局装置３から送信されるＲＲＣシグナリングは、ある端末装置１に対して専用のシグナリング（dedicated signalingとも称する）で
あってもよい。すなわち、端末装置固有（ＵＥスペシフィック）の情報は、ある端末装置１に対して専用のシグナリングを用いて送信されてもよい。また、ＰＵＳＣＨは、上りリンクにおいてＵＥの能力（UE Capability）の送信に用いられてもよい。
図１において、下りリンクの無線通信では、以下の下りリンク物理信号が用いられる。ここで、下りリンク物理信号は、上位層から出力された情報を送信するために使用されないが、物理層によって使用される。
・同期信号（Synchronization signal: SS）
・参照信号（Reference Signal: RS）
同期信号は、プライマリ同期信号（ＰＳＳ：Primary Synchronization Signal）およびセカンダリ同期信号（ＳＳＳ）を含んでよい。ＰＳＳとＳＳＳを用いてセルＩＤが検出されてよい。
同期信号は、端末装置１が下りリンクの周波数領域および時間領域の同期をとるために用いられる。ここで、同期信号は、端末装置１が基地局装置３によるプリコーディングまたはビームフォーミングにおけるプリコーディングまたはビームの選択に用いられて良い。なお、ビームは、送信または受信フィルタ設定、あるいは空間ドメイン送信フィルタまたは空間ドメイン受信フィルタと呼ばれてもよい。
参照信号は、端末装置１が物理チャネルの伝搬路補償を行うために用いられる。ここで、参照信号は、端末装置１が下りリンクのＣＳＩを算出するためにも用いられてよい。また、参照信号は、無線パラメータやサブキャリア間隔などのヌメロロジーやＦＦＴの窓同期などができる程度の細かい同期（Fine synchronization）に用いられて良い。
本実施形態において、以下の下りリンク参照信号のいずれか１つまたは複数が用いられる。
・ＤＭＲＳ（Demodulation Reference Signal）
・ＣＳＩ−ＲＳ（Channel State Information Reference Signal）
・ＰＴＲＳ（Phase Tracking Reference Signal）
・ＴＲＳ（Tracking Reference Signal）
ＤＭＲＳは、変調信号を復調するために使用される。なお、ＤＭＲＳには、ＰＢＣＨを
復調するための参照信号と、ＰＤＳＣＨを復調するための参照信号の２種類が定義されてもよいし、両方をＤＭＲＳと称してもよい。ＣＳＩ−ＲＳは、チャネル状態情報（ＣＳＩ：Channel State Information）の測定およびビームマネジメントに使用され、周期的またはセミパーシステントまたは非周期のＣＳＩ参照信号の送信方法が適用される。ＣＳＩ−ＲＳには、ノンゼロパワー（ＮＺＰ：Ｎｏｎ−Ｚｅｒｏ Ｐｏｗｅｒ）ＣＳＩ−ＲＳと、送信電力（または受信電力）がゼロである（ゼロパワー（ＺＰ：Ｚｅｒｏ Ｐｏｗｅｒ）ＣＳＩ−ＲＳが定義されてよい。ここで、ＺＰ ＣＳＩ−ＲＳは送信電力がゼロまたは送信されないＣＳＩ−ＲＳリソースと定義されてよい。ＰＴＲＳは、位相雑音に起因する周波数オフセットを保証する目的で、時間軸で位相をトラックするために使用される。ＴＲＳは、高速移動時におけるドップラーシフトを保証するために使用される。なお、ＴＲＳはＣＳＩ−ＲＳの１つの設定として用いられてよい。例えば、１ポートのＣＳＩ−ＲＳがＴＲＳとして無線リソースが設定されてもよい。
本実施形態において、以下の上りリンク参照信号のいずれか１つまたは複数が用いられる。
・ＤＭＲＳ（Demodulation Reference Signal）
・ＰＴＲＳ（Phase Tracking Reference Signal）
・ＳＲＳ（Sounding Reference Signal）
ＤＭＲＳは、変調信号を復調するために使用される。なお、ＤＭＲＳには、ＰＵＣＣＨを復調するための参照信号と、ＰＵＳＣＨを復調するための参照信号の２種類が定義されてもよいし、両方をＤＭＲＳと称してもよい。ＳＲＳは、上りリンクのチャネル状態情報（ＣＳＩ）の測定、チャネルサウンディング、およびビームマネジメントに使用される。ＰＴＲＳは、位相雑音に起因する周波数オフセットを保証する目的で、時間軸で位相をトラックするために使用される。
下りリンク物理チャネルおよび／または下りリンク物理シグナルを総称して、下りリンク信号と称する。上りリンク物理チャネルおよび／または上りリンク物理シグナルを総称して、上りリンク信号と称する。下りリンク物理チャネルおよび／または上りリンク物理チャネルを総称して、物理チャネルと称する。下りリンク物理シグナルおよび／または上りリンク物理シグナルを総称して、物理シグナルと称する。
ＢＣＨ、ＵＬ−ＳＣＨおよびＤＬ−ＳＣＨは、トランスポートチャネルである。媒体アクセス制御（ＭＡＣ：Medium Access Control）層で用いられるチャネルをトランスポー
トチャネルと称する。ＭＡＣ層で用いられるトランスポートチャネルの単位を、トランスポートブロック（ＴＢ：transport block）および／またはＭＡＣ ＰＤＵ（Protocol Data Unit）とも称する。ＭＡＣ層においてトランスポートブロック毎にＨＡＲＱ（Hybrid Automatic Repeat reQuest）の制御が行われる。トランスポートブロックは、ＭＡＣ層が物理層に渡す（deliver）データの単位である。物理層において、トランスポートブロックはコードワードにマップされ、コードワード毎に符号化処理が行われる。
図２は、本実施形態に係るＳＳ／ＰＢＣＨブロック（同期信号ブロック、ＳＳブロック、ＳＳＢとも称される）およびＳＳバーストセット（同期信号バーストセットとも称される）の例を示す図である。図２は、周期的に送信されるＳＳバーストセット内に２つのＳＳ／ＰＢＣＨブロックが含まれ、ＳＳ／ＰＢＣＨブロックは、連続する４ＯＦＤＭシンボルで構成される例を示している。
ＳＳ／ＰＢＣＨブロックは、少なくとも同期信号（ＰＳＳ、ＳＳＳ）、および／またはＰＢＣＨを含む単位ブロックである。ＳＳ／ＰＢＣＨブロックに含まれる信号／チャネルを送信することを、ＳＳ／ＰＢＣＨブロックを送信すると表現する。基地局装置３はＳＳ
バーストセット内の１つまたは複数のＳＳ／ＰＢＣＨブロックを用いて同期信号および／またはＰＢＣＨを送信する場合に、ＳＳ／ＰＢＣＨブロック毎に独立した下りリンク送信ビームを用いてもよい。
図２において、１つのＳＳ／ＰＢＣＨブロックにはＰＳＳ、ＳＳＳ、ＰＢＣＨが時間／周波数多重されている。ただし、ＰＳＳ、ＳＳＳおよび／またはＰＢＣＨが時間領域で多重される順番は図２に示す例と異なってもよい。
ＳＳバーストセットは、周期的に送信されてよい。例えば、初期アクセスに使用されるための周期と、接続されている（ConnectedまたはRRC_Connected）端末装置のために設定する周期が定義されてもよい。また、接続されている（ConnectedまたはRRC_Connected）端末装置のために設定する周期はＲＲＣ層で設定されてよい。また、接続されている（ConnectedまたはRRC_Connected）端末のために設定する周期は潜在的に送信する可能性がある時間領域の無線リソースの周期であって、実際には基地局装置３が送信するかどうかを決めてもよい。また、初期アクセスに使用されるための周期は、仕様書などに予め定義されてよい。
ＳＳバーストセットは、システムフレーム番号（ＳＦＮ：System Frame Number）に基
づいて決定されてよい。また、ＳＳバーストセットの開始位置（バウンダリ）は、ＳＦＮと周期に基づいて決定されてよい。
ＳＳ／ＰＢＣＨブロックは、ＳＳバーストセット内の時間的な位置に応じてＳＳＢインデックス（ＳＳＢ／ＰＢＣＨブロックインデックスと称されてもよい）が割り当てられる。端末装置１は、検出したＳＳ／ＰＢＣＨブロックに含まれるＰＢＣＨの情報および／または参照信号の情報に基づいてＳＳＢインデックスを算出する。
複数のＳＳバーストセットにおける各ＳＳバーストセット内における相対的な時間が同じＳＳ／ＰＢＣＨブロックは、同じＳＳＢインデックスが割り当てられる。複数のＳＳバーストセットにおける各ＳＳバーストセット内における相対的な時間が同じＳＳ／ＰＢＣＨブロックは、ＱＣＬである（あるいは同じ下りリンク送信ビームが適用されている）と想定されてもよい。また、複数のＳＳバーストセットにおける各ＳＳバーストセット内における相対的な時間が同じＳＳ／ＰＢＣＨブロックにおけるアンテナポートは、平均遅延、ドップラーシフト、空間相関に関してＱＣＬであると想定されてもよい。
あるＳＳバーストセットの周期内で、同じＳＳＢインデックスが割り当てられているＳＳ／ＰＢＣＨブロックは、平均遅延、平均ゲイン、ドップラースプレッド、ドップラーシフト、空間相関に関してＱＣＬであると想定されてもよい。ＱＣＬである１つまたは複数のＳＳ／ＰＢＣＨブロック（あるいは参照信号であってもよい）に対応する設定をＱＣＬ設定と称してもよい。
ＳＳ／ＰＢＣＨブロック数（ＳＳブロック数あるいはＳＳＢ数と称されてもよい）は、例えばＳＳバースト、またはＳＳバーストセット内、またはＳＳ／ＰＢＣＨブロックの周期の中のＳＳ／ＰＢＣＨブロック数（個数）として定義されてよい。また、ＳＳ／ＰＢＣＨブロック数は、ＳＳバースト内、またはＳＳバーストセット内、またはＳＳ／ＰＢＣＨブロックの周期の中のセル選択のためのビームグループの数を示してもよい。ここで、ビームグループは、ＳＳバースト内、またはＳＳバーストセット内、またはＳＳ／ＰＢＣＨブロックの周期の中に含まれる異なるＳＳ／ＰＢＣＨブロックの数または異なるビームの数として定義されてよい。
以下、本実施形態で説明する参照信号は、下りリンク参照信号、同期信号、ＳＳ／ＰＢ
ＣＨブロック、下りリンクＤＭ−ＲＳ、ＣＳＩ−ＲＳ、上りリンク参照信号、ＳＲＳ、および／または、上りリンクＤＭ−ＲＳを含む。例えば、下りリンク参照信号、同期信号および／またはＳＳ／ＰＢＣＨブロックを参照信号と称してもよい。下りリンクで使用される参照信号は、下りリンク参照信号、同期信号、ＳＳ／ＰＢＣＨブロック、下りリンクＤＭ−ＲＳ、ＣＳＩ−ＲＳなどを含む。上りリンクで使用される参照信号は、上りリンク参照信号、ＳＲＳ、および／または、上りリンクＤＭ−ＲＳなどを含む。
また、参照信号は、無線リソース測定（ＲＲＭ：Radio Resource Measurement）に用いられてよい。また、参照信号は、ビームマネジメントに用いられてよい。
ビームマネジメントは、送信装置（下りリンクの場合は基地局装置３であり、上りリンクの場合は端末装置１である）におけるアナログおよび／またはディジタルビームと、受信装置（下りリンクの場合は端末装置１、上りリンクの場合は基地局装置３である）におけるアナログおよび／またはディジタルビームの指向性を合わせ、ビーム利得を獲得するための基地局装置３および／または端末装置１の手続きであってよい。
なお、ビームペアリンクを構成、設定または確立する手続きとして、下記の手続きを含んでよい。
・ビーム選択（Beam selection）
・ビーム改善（Beam refinement）
・ビームリカバリ（Beam recovery）
例えば、ビーム選択は、基地局装置３と端末装置１の間の通信においてビームを選択する手続きであってよい。また、ビーム改善は、さらに利得の高いビームの選択、あるいは端末装置１の移動によって最適な基地局装置３と端末装置１の間のビームの変更をする手続きであってよい。ビームリカバリは、基地局装置３と端末装置１の間の通信において遮蔽物や人の通過などにより生じるブロッケージにより通信リンクの品質が低下した際にビームを再選択する手続きであってよい。
ビームマネジメントには、ビーム選択、ビーム改善が含まれてよい。ビームリカバリには、下記の手続きを含んでよい。
・ビーム失敗（beam failure）の検出
・新しいビームの発見
・ビームリカバリリクエストの送信
・ビームリカバリリクエストに対する応答のモニタ
例えば、端末装置１における基地局装置３の送信ビームを選択する際にＣＳＩ−ＲＳまたはＳＳ／ＰＢＣＨブロックに含まれるＳＳＳのＲＳＲＰ（Reference Signal Received Power）を用いてもよいし、ＣＳＩを用いてもよい。また、基地局装置３への報告として
ＣＳＩ−ＲＳリソースインデックス（ＣＲＩ：CSI-RS Resource Index）を用いてもよい
し、ＳＳ／ＰＢＣＨブロックに含まれるＰＢＣＨおよび／またはＰＢＣＨの復調に用いられる復調用参照信号（ＤＭＲＳ）の系列で指示されるインデックスを用いてもよい。
また、基地局装置３は、端末装置１へビームを指示する際にＣＲＩまたはＳＳ／ＰＢＣＨの時間インデックスを指示し、端末装置１は、指示されたＣＲＩまたはＳＳ／ＰＢＣＨの時間インデックスに基づいて受信する。このとき、端末装置１は指示されたＣＲＩまたはＳＳ／ＰＢＣＨの時間インデックスに基づいて空間フィルタを設定し、受信してよい。また、端末装置１は、疑似同位置（ＱＣＬ：Quasi Co-Location）の想定を用いて受信し
てもよい。ある信号（アンテナポート、同期信号、参照信号など）が別の信号（アンテナポート、同期信号、参照信号など）と「ＱＣＬである」または、「ＱＣＬの想定が用いら
れる」とは、ある信号が別の信号と関連付けられていると解釈できる。
もしあるアンテナポートにおけるあるシンボルが搬送されるチャネルの長区間特性（Long Term Property）が他方のアンテナポートにおけるあるシンボルが搬送されるチャネルから推論されうるなら、２つのアンテナポートはＱＣＬであるといわれる。チャネルの長区間特性は、遅延スプレッド、ドップラースプレッド、ドップラーシフト、平均利得、及び平均遅延の１つまたは複数を含む。例えば、アンテナポート１とアンテナポート２が平均遅延に関してＱＣＬである場合、アンテナポート１の受信タイミングからアンテナポート２の受信タイミングが推論されうることを意味する。
このＱＣＬは、ビームマネジメントにも拡張されうる。そのために、空間に拡張したＱＣＬが新たに定義されてもよい。例えば、空間ドメインのＱＣＬの想定におけるチャネルの長区間特性（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）、受信空間パラメータであってもよい。
例えば、アンテナポート１とアンテナポート２の間で受信空間パラメータに関してＱＣＬであるとみなせる場合、アンテナポート１からの信号を受信する受信ビーム（受信空間フィルタ）からアンテナポート２からの信号を受信する受信ビームが推論されうることを意味する。
ＱＣＬタイプとして、ＱＣＬであるとみなしてよい長区間特性の組み合わせが定義されてよい。例えば、以下のタイプが定義されてよい。
・タイプＡ：ドップラーシフト、ドップラースプレッド、平均遅延、遅延スプレッド
・タイプＢ：ドップラーシフト、ドップラースプレッド
・タイプＣ：平均遅延、ドップラーシフト
・タイプＤ：受信空間パラメータ
上述のＱＣＬタイプは、ＲＲＣおよび／またはＭＡＣ層および／またはＤＣＩで１つまたは２つの参照信号とＰＤＣＣＨやＰＤＳＣＨ ＤＭＲＳとのＱＣＬの想定を送信設定指示（ＴＣＩ：Transmission Configuration Indication）として設定および／または指示
してもよい。例えば、端末装置１がＰＤＣＣＨを受信する際のＴＣＩの１つの状態として、ＳＳ／ＰＢＣＨブロックのインデックス＃２とＱＣＬタイプＡ＋ＱＣＬタイプＢが設定および／または指示された場合、端末装置１は、ＰＤＣＣＨ ＤＭＲＳを受信する際、ＳＳ／ＰＢＣＨブロックインデックス＃２の受信におけるドップラーシフト、ドップラースプレッド、平均遅延、遅延スプレッド、受信空間パラメータとチャネルの長区間特性とみなしてＰＤＣＣＨのＤＭＲＳを受信して同期や伝搬路推定をしてもよい。このとき、ＴＣＩにより指示される参照信号（上述の例ではＳＳ／ＰＢＣＨブロック）をソース参照信号、ソース参照信号を受信する際のチャネルの長区間特性から推論される長区間特性の影響を受ける参照信号（上述の例ではＰＤＣＣＨ ＤＭＲＳ）をターゲット参照信号と称してよい。また、ＴＣＩは、ＲＲＣで１つまたは複数のＴＣＩ状態と各状態に対してソース参照信号とＱＣＬタイプの組み合わせが設定され、ＭＡＣ層またはＤＣＩにより端末装置１に指示されてよい。
この方法により、ビームマネジメントおよびビーム指示／報告として、空間ドメインのＱＣＬの想定と無線リソース（時間および／または周波数）によりビームマネジメントと等価な基地局装置３、端末装置１の動作が定義されてもよい。
以下、サブフレームについて説明する。本実施形態ではサブフレームと称するが、リソースユニット、無線フレーム、時間区間、時間間隔などと称されてもよい。
図３は、本発明の第１の実施形態に係る上りリンクおよび下りリンクスロットの概略構成の一例を示す図である。無線フレームのそれぞれは、１０ｍｓ長である。また、無線フレームのそれぞれは１０個のサブフレームおよびＷ個のスロットから構成される。また、１スロットは、Ｘ個のＯＦＤＭシンボルで構成される。つまり、１サブフレームの長さは１ｍｓである。スロットのそれぞれは、サブキャリア間隔によって時間長が定義される。例えば、ＯＦＤＭシンボルのサブキャリア間隔が１５ｋＨｚ、ＮＣＰ（Normal Cyclic Prefix）の場合、Ｘ＝７あるいはＸ＝１４であり、それぞれ０．５ｍｓおよび１ｍｓである。また、サブキャリア間隔が６０ｋＨｚの場合は、Ｘ＝７あるいはＸ＝１４であり、それぞれ０．１２５ｍｓおよび０．２５ｍｓである。また、例えば、Ｘ＝１４の場合、サブキャリア間隔が１５ｋＨｚの場合はＷ＝１０であり、サブキャリア間隔が６０ｋＨｚの場合はＷ＝４０である。図３は、Ｘ＝７の場合を一例として示している。なお、Ｘ＝１４の場合にも同様に拡張できる。また、上りリンクスロットも同様に定義され、下りリンクスロットと上りリンクスロットは別々に定義されてもよい。また、図３のセルの帯域幅は帯域の一部（ＢＷＰ：BandWidth Part）として定義されてもよい。また、スロットは、送信時間間隔（ＴＴＩ：Transmission Time Interval）と定義されてもよい。スロットは、ＴＴＩとして定義されなくてもよい。ＴＴＩは、トランスポートブロックの送信期間であってもよい。
スロットのそれぞれにおいて送信される信号または物理チャネルは、リソースグリッドによって表現されてよい。リソースグリッドは、それぞれのヌメロロジー（サブキャリア間隔およびサイクリックプレフィックス長）およびそれぞれのキャリアに対して、複数のサブキャリアと複数のＯＦＤＭシンボルによって定義される。1つのスロットを構成する
サブキャリアの数は、セルの下りリンクおよび上りリンクの帯域幅にそれぞれ依存する。リソースグリッド内のエレメントのそれぞれをリソースエレメントと称する。リソースエレメントは、サブキャリアの番号とＯＦＤＭシンボルの番号とを用いて識別されてよい。
リソースグリッドは、ある物理下りリンクチャネル（ＰＤＳＣＨなど）あるいは上りリンクチャネル（ＰＵＳＣＨなど）のリソースエレメントのマッピングを表現するために用いられる。例えば、サブキャリア間隔が１５ｋＨｚの場合、サブフレームに含まれるＯＦＤＭシンボル数Ｘ＝１４で、ＮＣＰの場合には、１つの物理リソースブロックは、時間領域において１４個の連続するＯＦＤＭシンボルと周波数領域において１２＊Ｎｍａｘ個の連続するサブキャリアとから定義される。Ｎｍａｘは、後述するサブキャリア間隔設定μにより決定されるリソースブロックの最大数である。つまり、リソースグリッドは、（１４＊１２＊Ｎｍａｘ，μ）個のリソースエレメントから構成される。ＥＣＰ（Extended CP）の場合、サブキャリア間隔６０ｋＨｚにおいてのみサポートされるので、１つの物理リソースブロックは、例えば、時間領域において１２（１スロットに含まれるＯＦＤＭシンボル数）＊４（１サブフレームに含まれるスロット数）＝４８個の連続するＯＦＤＭシンボルと、周波数領域において１２＊Ｎｍａｘ，μ個の連続するサブキャリアとにより定義される。つまり、リソースグリッドは、（４８＊１２＊Ｎｍａｘ，μ）個のリソースエレメントから構成される。
リソースブロックとして、参照リソースブロック、共通リソースブロック、物理リソースブロック、仮想リソースブロックが定義される。１リソースブロックは、周波数領域で連続する１２サブキャリアとして定義される。参照リソースブロックは、全てのサブキャリアにおいて共通であり、例えば１５ｋＨｚのサブキャリア間隔でリソースブロックを構成し、昇順に番号が付されてよい。参照リソースブロックインデックス０におけるサブキ
ャリアインデックス０は、参照ポイントＡ（point A）と称されてよい（単に“参照ポイ
ント”と称されてもよい）。共通リソースブロックは、参照ポイントＡから各サブキャリア間隔設定μにおいて０から昇順で番号が付されるリソースブロックである。上述のリソースグリッドはこの共通リソースブロックにより定義される。物理リソースブロックは、後述する帯域部分（ＢＷＰ）の中に含まれる０から昇順で番号が付されたリソースブロックであり、物理リソースブロックは、帯域部分（ＢＷＰ）の中に含まれる０から昇順で番号が付されたリソースブロックである。ある物理上りリンクチャネルは、まず仮想リソースブロックにマップされる。その後、仮想リソースブロックは、物理リソースブロックにマップされる。以下、リソースブロックは仮想リソースブロックであってもよいし、物理リソースブロックであってもよいし、共通リソースブロックであってもよいし、参照リソースブロックであってもよい。
次に、サブキャリア間隔設定μについて説明する。上述のようにＮＲでは、１つまたは複数のＯＦＤＭヌメロロジーがサポートされる。あるＢＷＰにおいて、サブキャリア間隔設定μ（μ＝０，１，．．．，５）と、サイクリックプレフィックス長は、下りリンクのＢＷＰに対して上位層で与えられ、上りリンクのＢＷＰにおいて上位層で与えられる。ここで、μが与えられると、サブキャリア間隔Δｆは、Δｆ＝２＾μ・１５（ｋＨｚ）で与えられる。
サブキャリア間隔設定μにおいて、スロットは、サブフレーム内で０からＮ＾｛ｓｕｂｆｒａｍｅ，μ｝＿｛ｓｌｏｔ｝−１に昇順に数えられ、フレーム内で０からＮ＾｛ｆｒａｍｅ，μ｝＿｛ｓｌｏｔ｝−１に昇順に数えられる。スロット設定およびサイクリックプレフィックスに基づいてＮ＾｛ｓｌｏｔ｝＿｛ｓｙｍｂ｝の連続するＯＦＤＭシンボルがスロット内にある。Ｎ＾｛ｓｌｏｔ｝＿｛ｓｙｍｂ｝は１４である。サブフレーム内のスロットｎ＾｛μ｝＿｛ｓ｝のスタートは、同じサブフレーム内のｎ＾｛μ｝＿｛ｓ｝＊Ｎ＾｛ｓｌｏｔ｝＿｛ｓｙｍｂ｝番目のＯＦＤＭシンボルのスタートと時間でアラインされている。
次に、サブフレーム、スロット、ミニスロットについて説明する。図４は、サブフレーム、スロット、ミニスロットの時間領域における関係を示した図である。同図のように、３種類の時間ユニットが定義される。サブフレームは、サブキャリア間隔によらず１ｍｓであり、スロットに含まれるＯＦＤＭシンボル数は７または１４であり、スロット長はサブキャリア間隔により異なる。ここで、サブキャリア間隔が１５ｋＨｚの場合、１サブフレームには１４ＯＦＤＭシンボル含まれる。下りリンクスロットはＰＤＳＣＨマッピングタイプＡと称されてよい。上りリンクスロットはＰＵＳＣＨマッピングタイプＡと称されてよい。
ミニスロット（サブスロット（subslot）と称されてもよい）は、１つのスロットに含
まれるＯＦＤＭシンボル数よりも少ない数のＯＦＤＭシンボルで構成される時間ユニットである。同図はミニスロットが２ＯＦＤＭシンボルで構成される場合を一例として示している。ミニスロット内のＯＦＤＭシンボルは、スロットを構成するＯＦＤＭシンボルタイミングに一致してもよい。なお、スケジューリングの最小単位はスロットまたはミニスロットでよい。また、ミニスロットを割り当てることを、ノンスロットベースのスケジューリングと称してもよい。また、ミニスロットをスケジューリングされることを参照信号とデータのスタート位置の相対的な時間位置が固定であるリソースがスケジュールされたと表現されてもよい。下りリンクミニスロットはＰＤＳＣＨマッピングタイプＢと称されてよい。上りリンクミニスロットはＰＵＳＣＨマッピングタイプＢと称されてよい。
図５は、スロットフォーマットの一例を示す図である。ここでは、サブキャリア間隔１５ｋＨｚにおいてスロット長が１ｍｓの場合を例として示している。同図において、Ｄは下りリンク、Ｕは上りリンクを示している。同図に示されるように、ある時間区間内（例えば、システムにおいて１つのＵＥに対して割り当てなければならない最小の時間区間）においては、
・下りリンクシンボル
・フレキシブルシンボル
・上りリンクシンボル
のうち１つまたは複数を含んでよい。なお、これらの割合はスロットフォーマットとして予め定められてもよい。また、スロット内に含まれる下りリンクのＯＦＤＭシンボル数またはスロット内のスタート位置および終了位置で定義されてもよい。また、スロット内に含まれる上りリンクのＯＦＤＭシンボル数またはＤＦＴ−Ｓ−ＯＦＤＭシンボル数またはスロット内のスタート位置および終了位置で定義されてよい。なお、スロットをスケジューリングされることを参照信号とスロット境界の相対的な時間位置が固定であるリソースがスケジュールされたと表現されてもよい。
端末装置１は、下りリンクシンボルまたはフレキシブルシンボルで下りリンク信号または下りリンクチャネルを受信してよい。端末装置１は、上りリンクシンボルまたはフレキシブルシンボルで上りリンク信号または下りリンクチャネルを送信してよい。
図５（ａ）は、ある時間区間（例えば、１ＵＥに割当可能な時間リソースの最小単位、またはタイムユニットなどとも称されてよい。また、時間リソースの最小単位を複数束ねてタイムユニットと称されてもよい。）で、全て下りリンク送信に用いられている例であり、図５（ｂ）は、最初の時間リソースで例えばＰＤＣＣＨを介して上りリンクのスケジューリングを行い、ＰＤＣＣＨの処理遅延及び下りから上りの切り替え時間、送信信号の生成を含むフレキシブルシンボルを介して上りリンク信号を送信する。図５（ｃ）は、最初の時間リソースでＰＤＣＣＨおよび／または下りリンクのＰＤＳＣＨの送信に用いられ、処理遅延及び下りから上りの切り替え時間、送信信号の生成のためのギャップを介してＰＵＳＣＨまたはＰＵＣＣＨの送信に用いられる。ここで、一例としては、上りリンク信号はＨＡＲＱ−ＡＣＫおよび／またはＣＳＩ、すなわちＵＣＩの送信に用いられてよい。図５（ｄ）は、最初の時間リソースでＰＤＣＣＨおよび／またはＰＤＳＣＨの送信に用いられ、処理遅延及び下りから上りの切り替え時間、送信信号の生成のためのギャップを介して上りリンクのＰＵＳＣＨおよび／またはＰＵＣＣＨの送信に用いられる。ここで、一例としては、上りリンク信号は上りリンクデータ、すなわちＵＬ−ＳＣＨの送信に用いられてもよい。図５（ｅ）は、全て上りリンク送信（ＰＵＳＣＨまたはＰＵＣＣＨ）に用いられている例である。
上述の下りリンクパート、上りリンクパートは、ＬＴＥと同様に複数のＯＦＤＭシンボルで構成されてよい。
図６は、ビームフォーミングの一例を示した図である。複数のアンテナエレメントは１つの送信ユニット（TXRU: Transceiver unit）５０に接続され、アンテナエレメント毎の位相シフタ５１によって位相を制御し、アンテナエレメント５２から送信することで送信信号に対して任意の方向にビームを向けることができる。典型的には、ＴＸＲＵがアンテナポートとして定義されてよく、端末装置１においてはアンテナポートのみが定義されてよい。位相シフタ５１を制御することで任意の方向に指向性を向けることができるため、基地局装置３は端末装置１に対して利得の高いビームを用いて通信することができる。
以下、帯域部分（ＢＷＰ, Bandwidth part）について説明する。ＢＷＰは、キャリアＢＷＰとも称される。ＢＷＰは、下りリンクと上りリンクのそれぞれに設定されてよい。ＢＷＰは、共通リソースブロックの連続するサブセットから選択された連続する物理リソースの集合として定義される。端末装置１は、ある時間に１つの下りリンクキャリアＢＷＰ
（ＤＬ ＢＷＰ）が活性化される４つまでのＢＷＰを設定されうる。端末装置１は、ある時間に１つの上りリンクキャリアＢＷＰ（ＵＬ ＢＷＰ）が活性化される４つまでのＢＷＰを設定されうる。キャリアアグリゲーションの場合には、ＢＷＰは各サービングセルで設定されてもよい。このとき、あるサービングセルにおいてＢＷＰが１つ設定されていることを、ＢＷＰが設定されていないと表現されてもよい。また、ＢＷＰが２つ以上設定されていることをＢＷＰが設定されていると表現されてもよい。
＜ＭＡＣ ｅｎｔｉｔｙ動作>
活性化されたサービングセルにおいて、常に一つのアクティブな（活性化された）ＢＷＰがある。あるサービングセルに対するＢＷＰ切り替え（BWP switching）は、インアク
ティブな（非活性化された）ＢＷＰを活性化（activate）し、アクティブな（活性化された）ＢＷＰを非活性化（deactivate）するために使用される。あるサービングセルに対するＢＷＰ切り替え（BWP switching）は、下りリンク割り当てまたは上りリンクグラント
を示すＰＤＣＣＨによって制御される。あるサービングセルに対するＢＷＰ切り替え（BWP switching）は、さらに、ＢＷＰインアクティブタイマー（BWP inactivity timer）や、ＲＲＣシグナリングによってや、ランダムアクセスプロシージャの開始時にＭＡＣエンティティ自身によって制御されてもよい。ＳｐＣｅｌｌ（PCellまたはPSCell）の追加または、ＳＣｅｌｌの活性化において、一つのＢＷＰが、下りリンク割り当てまたは上りリンクグラントを示すＰＤＣＣＨを受信することなしに第一にアクティブである。第一にアクティブなＤＬ ＢＷＰ（first active DL BWP）およびＵＬ ＢＷＰ（first active UL BWP）は、基地局装置３から端末装置１に送られるＲＲＣメッセージで指定されるかもしれない。あるサービングセルに対するアクティブなＢＷＰは、基地局装置３から端末装置１に送られるＲＲＣまたはＰＤＣＣＨで指定される。また、第一にアクティブなＤＬ ＢＷＰ（first active DL BWP）およびＵＬ ＢＷＰ（first active UL BWP）は、メッセージ４に含まれてもよい。アンペアードスペクトラム（Unpaired spectrum）（ＴＤＤバンドなど）では、ＤＬ ＢＷＰとＵＬ ＢＷＰはペアされていて、ＢＷＰ切り替えは、ＵＬとＤＬに対して共通である。ＢＷＰが設定されているアクティベートされたサービングセルのそれぞれに対する、アクティブなＢＷＰにおいて、端末装置１のＭＡＣエンティティは、ノーマル処理を適用する。ノーマル処理には、ＵＬ−ＳＣＨを送信する、ＲＡＣＨを送信する、ＰＤＣＣＨをモニタする、ＰＵＣＣＨを送信する、ＳＲＳを送信する、およびＤＬ−ＳＣＨを受信することを含む。ＢＷＰが設定されているアクティベートされたサービングセルのそれぞれに対する、インアクティブなＢＷＰにおいて、端末装置１のＭＡＣエンティティは、ＵＬ−ＳＣＨを送信しない、ＲＡＣＨを送信しない、ＰＤＣＣＨをモニタしない、ＰＵＣＣＨを送信しない、ＳＲＳを送信しない、およびＤＬ−ＳＣＨを受信しない。あるサービングセルが非活性化された場合、アクティブなＢＷＰは、存在しないようにしてもよい（例えば、アクティブなＢＷＰは非活性化される）。
＜ＲＲＣ動作＞
ＲＲＣメッセージ（報知されるシステム情報や、専用ＲＲＣメッセージで送られる情報）に含まれるＢＷＰインフォメーションエレメント（IE）は、ＢＷＰを設定するために使われる。基地局装置３から送信されたＲＲＣメッセージは、端末装置１によって受信される。それぞれのサービングセルに対して、ネットワーク（基地局装置３など）は、少なくとも下りリンクのＢＷＰと１つ（もしサービングセルが上りリンクの設定された場合など）または２つ（付録のアップリンク（supplementary uplink）が使われる場合など）の上りリンクＢＷＰを含む少なくとも初期ＢＷＰ（initial BWP）を、端末装置１に対して、設定する。さらに、ネットワークは、追加の上りリンクＢＷＰや下りリンクＢＷＰをあるサービングセルに対して設定するかもしれない。ＢＷＰ設定は、上りリンクパラメータと下りリンクパラメータに分けられる。また、ＢＷＰ設定は、共通（common）パラメータと専用（dedicated）パラメータに分けられる。共通パラメータ（ＢＷＰ上りリンク共通ＩＥやＢＷＰ下りリンク共通ＩＥなど）は、セル特有である。プライマリセルの初期ＢＷＰの共通パラメータは、システム情報でも提供される。他のすべてのサービングセルに対しては、ネットワークは専用信号で共通パラメータを提供する。ＢＷＰは、ＢＷＰ ＩＤで識別される。初期ＢＷＰは、ＢＷＰ ＩＤが０である。他のＢＷＰのＢＷＰ ＩＤは、１から４までの値を取る。
端末装置１に対して上位層のパラメータｉｎｉｔｉａｌＤｏｗｎｌｉｎｋＢＷＰが設定（提供）されない場合、初期ＤＬ ＢＷＰ（初期アクティブなＤＬ ＢＷＰ、initial active DL BWP）は、タイプ０ＰＤＣＣＨコモンサーチスペースのためのコントロールリソースセット（ＣＯＲＥＳＥＴ）でのＰＤＣＣＨ受信のために、連続的なＰＲＢの位置と数、サブキャリア間隔、および、サイクリックプレフィックスによって定義されてもよい。該連続的なＰＲＢの位置は、タイプ０ＰＤＣＣＨコモンサーチスペースのためのコントロールリソースセットのＰＲＢの間で、最小インデックスのＰＲＢから始まり、最大インデックスのＰＲＢで終わる。端末装置１に対して上位層のパラメータｉｎｉｔｉａｌＤｏｗｎｌｉｎｋＢＷＰが設定（提供）されている場合、初期ＤＬ ＢＷＰは上位層のパラメータｉｎｉｔｉａｌＤｏｗｎｌｉｎｋＢＷＰによって示されてもよい。上位層のパラメータｉｎｉｔｉａｌＤｏｗｎｌｉｎｋＢＷＰは、ＳＩＢ１（systemInformationBlockType1、ServingCellConfigCommonSIB）またはＳｅｒｖｉｎｇＣｅｌｌＣｏｎｆｉｇＣｏｍｍｏｎに含まれてもよい。インフォメーションエレメントＳｅｒｖｉｎｇＣｅｌｌＣｏｎｆｉｇＣｏｍｍｏｎＳＩＢは、ＳＩＢ１内で端末装置１に対するサービングセルのセル固有パラメータを設定するために使われる。
即ち、端末装置１に対して上位層のパラメータｉｎｉｔｉａｌＤｏｗｎｌｉｎｋＢＷＰが設定（提供）されない場合、初期ＤＬ ＢＷＰのサイズは、タイプ０ＰＤＣＣＨコモンサーチスペースのためのコントロールリソースセット（ＣＯＲＥＳＥＴ＃０）のリソースブロックの数であってもよい。端末装置１に対して上位層のパラメータｉｎｉｔｉａｌＤｏｗｎｌｉｎｋＢＷＰが設定（提供）されている場合、初期ＤＬ ＢＷＰのサイズは、上位層のパラメータｉｎｉｔｉａｌＤｏｗｎｌｉｎｋＢＷＰに含まれるｌｏｃａｔｉｏｎＡｎｄＢａｎｄｗｉｄｔｈによって与えられてもよい。上位層のパラメータｌｏｃａｔｉｏｎＡｎｄＢａｎｄｗｉｄｔｈは初期ＤＬ ＢＷＰの周波数領域の位置と帯域幅を示してもよい。
前述のように、端末装置１に対して複数のＤＬ ＢＷＰが設定されていてもよい。そして、端末装置１に対して設定されているＤＬ ＢＷＰの内、上位層のパラメータｄｅｆａｕｌｔＤｏｗｎｌｉｎｋＢＷＰ−ＩｄによりデフォルトＤＬ ＢＷＰが設定されることができる。端末装置１に対して上位層のパラメータｄｅｆａｕｌｔＤｏｗｎｌｉｎｋＢＷＰ−Ｉｄが提供されない場合、デフォルトＤＬ ＢＷＰは初期ＤＬ ＢＷＰである。
端末装置１には、初期ＵＬ ＢＷＰがＳＩＢ１（systemInformationBlockType1）また
はｉｎｉｔｉａｌＵｐｌｉｎｋＢＷＰによって提供されてもよい。インフォメーションエレメントｉｎｉｔｉａｌＵｐｌｉｎｋＢＷＰは、初期ＵＬ ＢＷＰを設定するために使われる。ＳｐＣｅｌｌまたはセカンダリセルでのオペレーションに対して、端末装置１には、上位層のパラメータｉｎｉｔｉａｌＵｐｌｉｎｋＢＷＰによって初期ＵＬ ＢＷＰ（初期アクティブなＵＬ ＢＷＰ）が設定（提供）されてもよい。端末装置１に対して補足的な上りリンクキャリア（supplementary UL carrier）が設定される場合、端末装置１には、上位層のパラメータｓｕｐｐｌｅｍｅｎｔａｒｙＵｐｌｉｎｋに含まれるｉｎｉｔｉａｌＵｐｌｉｎｋＢＷＰによって、補足的な上りリンクキャリアでの初期ＵＬ ＢＷＰが設定されてもよい。
以下、本実施形態におけるコントロールリソースセット（ＣＯＲＥＳＥＴ）について説明する。
コントロールリソースセット（CORESET, Control resource set）は下りリンク制御情
報をサーチするための時間および周波数リソースである。ＣＯＲＥＳＥＴの設定情報には、ＣＯＲＥＳＥＴの識別子（ＣｏｎｔｒｏｌＲｅｓｏｕｒｃｅＳｅｔＩｄ、ＣＯＲＥＳＥＴ−ＩＤ）とＣＯＲＥＳＥＴの周波数リソースを特定する情報が含まれる。インフォメーションエレメントＣｏｎｔｒｏｌＲｅｓｏｕｒｃｅＳｅｔＩｄ（ＣＯＲＥＳＥＴの識別子）は、あるサービングセルにおけるコントロールリソースセットを特定するために使われる。ＣＯＲＥＳＥＴの識別子は、あるサービングセルにおけるＢＷＰ間で使われる。ＣＯＲＥＳＥＴの識別子は、サービングセルにおけるＢＷＰ間でユニークである。各ＢＷＰのＣＯＲＥＳＥＴの数は、初期ＣＯＲＥＳＥＴを含めて、３に制限される。あるサービングセルにおいて、ＣＯＲＥＳＥＴの識別子の値は、０から１１までの値を取る。
ＣＯＲＥＳＥＴの識別子０（ＣｏｎｔｒｏｌＲｅｓｏｕｒｃｅＳｅｔＩｄ ０）で特定されるコントロールリソースセットはＣＯＲＥＳＥＴ＃０と称する。ＣＯＲＥＳＥＴ＃０は、ＭＩＢに含まれるｐｄｃｃｈ−ＣｏｎｆｉｇＳＩＢ１、または、ＳｅｒｖｉｎｇＣｅｌｌＣｏｎｆｉｇＣｏｍｍｏｎに含まれるＰＤＣＣＨ−ＣｏｎｆｉｇＣｏｍｍｏｎによって設定されてもよい。即ち、ＣＯＲＥＳＥＴ＃０の設定情報は、ＭＩＢに含まれるｐｄｃｃｈ−ＣｏｎｆｉｇＳＩＢ１、または、ＳｅｒｖｉｎｇＣｅｌｌＣｏｎｆｉｇＣｏｍｍｏｎに含まれるＰＤＣＣＨ−ＣｏｎｆｉｇＣｏｍｍｏｎであってもよい。ＣＯＲＥＳＥＴ＃０の設定情報は、ＰＤＣＣＨ−ＣｏｎｆｉｇＳＩＢ１またはＰＤＣＣＨ−ＣｏｎｆｉｇＣｏｍｍｏｎに含まれるｃｏｎｔｒｏｌＲｅｓｏｕｒｃｅＳｅｔＺｅｒｏによって設定されてもよい。つまり、インフォメーションエレメントｃｏｎｔｒｏｌＲｅｓｏｕｒｃｅＳｅｔＺｅｒｏは、初期ＤＬ ＢＷＰのＣＯＲＥＳＥＴ＃０（コモンＣＯＲＥＳＥＴ）を示すために用いられる。ｐｄｃｃｈ−ＣｏｎｆｉｇＳＩＢ１で示されるＣＯＲＥＳＥＴは、ＣＯＲＥＳＥＴ＃０である。ＭＩＢまたは専用コンフィギュレーション内のインフォメーションエレメントｐｄｃｃｈ−ＣｏｎｆｉｇＳＩＢ１は、初期ＤＬ ＢＷＰを設定するために用いられる。ＣＯＲＥＳＥＴ＃０に対するＣＯＲＥＳＥＴの設定情報ｐｄｃｃｈ−ＣｏｎｆｉｇＳＩＢ１には、ＣＯＲＥＳＥＴの識別子とＣＯＲＥＳＥＴの周波数リソース（例えば、連続的なリソースブロックの数）および時間リソース（連続的なシンボルの数）を明示的に特定する情報は含まれないが、ＣＯＲＥＳＥＴ＃０に対するＣＯＲＥＳＥＴの周波数リソース（例えば、連続的なリソースブロックの数）および時間リソース（連続的なシンボルの数）は、ｐｄｃｃｈ−ＣｏｎｆｉｇＳＩＢ１に含まれる情報によって暗示的に特定できる。インフォメーションエレメントＰＤＣＣＨ−ＣｏｎｆｉｇＣｏｍｍｏｎは、ＳＩＢで提供されるセル固有のＰＤＣＣＨパラメータを設定するために用いられる。また、ＰＤＣＣＨ−ＣｏｎｆｉｇＣｏｍｍｏｎはハンドオーバ、および、ＰＳＣｅｌｌおよび／またはＳＣｅｌｌの追加時にも提供されてもよい。ＣＯＲＥＳＥＴ＃０の設定情報は、初期ＢＷＰの設定の中に含まれる。即ち、ＣＯＲＥＳＥＴ＃０の設定情報は、初期ＢＷＰ以外のＢＷＰの設定の中に含まれなくてもよい。ｃｏｎｔｒｏｌＲｅｓｏｕｒｃｅＳｅｔＺｅｒｏは、ｐｄｃｃｈ−ＣｏｎｆｉｇＳＩＢ１の内４ビット（例えば、ＭＳＢ ４ビット、最上位ビットの４ビット）に対応する。ＣＯＲＥＳＥＴ＃０はタイプ０ＰＤＣＣＨコモンサーチスペースのためのコントロールリソースセットである。
追加のコモンＣＯＲＥＳＥＴ（additional common control resource set）の設定情報は、ＰＤＣＣＨ−ＣｏｎｆｉｇＣｏｍｍｏｎに含まれるｃｏｍｍｏｎＣｏｎｔｒｏｌＲｅｓｏｕｒｃｅＳｅｔによって設定されてもよい。また、追加のコモンＣＯＲＥＳＥＴの設定情報は、システム情報および／またはページング手順のための追加のコモンＣＯＲＥＳＥＴを指定するために使用されてもよい。追加のコモンＣＯＲＥＳＥＴの設定情報は、ランダムアクセス手順に使われる追加のコモンＣＯＲＥＳＥＴを指定するために使用されてもよい。追加のコモンＣＯＲＥＳＥＴの設定情報は、各ＢＷＰの設定の中に含まれてもよい。ｃｏｍｍｏｎＣｏｎｔｒｏｌＲｅｓｏｕｒｃｅＳｅｔに示されるＣＯＲＥＳＥＴの識
別子は０以外の値を取る。
コモンＣＯＲＥＳＥＴは、ランダムアクセス手順に使われるＣＯＲＥＳＥＴ（例えば、追加のコモンＣＯＲＥＳＥＴ）であってもよい。また、本実施形態において、コモンＣＯＲＥＳＥＴには、ＣＯＲＥＳＥＴ＃０および／または追加のコモンＣＯＲＥＳＥＴの設定情報で設定されたＣＯＲＥＳＥＴが含まれてもよい。つまり、コモンＣＯＲＥＳＥＴはＣＯＲＥＳＥＴ＃０および／または追加のコモンＣＯＲＥＳＥＴを含んでもよい。ＣＯＲＥＳＥＴ＃０はコモンＣＯＲＥＳＥＴ＃０と称してもよい。端末装置１、コモンＣＯＲＥＳＥＴが設定されているＢＷＰ以外のＢＷＰにおいても、コモンＣＯＲＥＳＥＴの設定情報を参照（取得）してもよい。
１つまたは複数のＣＯＲＥＳＥＴの設定情報は、ＰＤＣＣＨ−Ｃｏｎｆｉｇによって設定されてもよい。インフォメーションエレメントＰＤＣＣＨ−Ｃｏｎｆｉｇは、あるＢＷＰに対してＵＥ固有のＰＤＣＣＨパラメータ（例えば、ＣＯＲＳＥＴ、サーチスペースなど）を設定するために用いられる。ＰＤＣＣＨ−Ｃｏｎｆｉｇは、各ＢＷＰの設定の中に含まれてもよい。
即ち、本実施形態において、ＭＩＢで示されるコモンＣＯＲＥＳＥＴの設定情報はｐｄｃｃｈ−ＣｏｎｆｉｇＳＩＢ１であり、ＰＤＣＣＨ−ＣｏｎｆｉｇＣｏｍｍｏｎで示されるコモンＣＯＲＥＳＥＴの設定情報はｃｏｎｔｒｏｌＲｅｓｏｕｒｃｅＳｅｔＺｅｒｏであり、ＰＤＣＣＨ−ＣｏｎｆｉｇＣｏｍｍｏｎで示されるコモンＣＯＲＥＳＥＴ（追加のコモンＣＯＲＥＳＥＴ）の設定情報はｃｏｍｍｏｎＣｏｎｔｒｏｌＲｅｓｏｕｒｃｅＳｅｔである。また、ＰＤＣＣＨ−Ｃｏｎｆｉｇで示される１つまたは複数のＣＯＲＥＳＥＴ（UE specifically configured Control Resource Sets、ＵＥ固有ＣＯＲＥＳＥＴ）の設定情報はｃｏｎｔｒｏｌＲｅｓｏｕｒｃｅＳｅｔＴｏＡｄｄＭｏｄＬｉｓｔである。
サーチスペースはＰＤＣＣＨ候補（PDCCH candidates）をサーチするために定義される。サーチスペースの設定情報に含まれるｓｅａｒｃｈＳｐａｃｅＴｙｐｅは、該サーチスペースがコモンサーチスペース（Common Search Space, CSS）であるかＵＥ固有サーチスペース（UE-specific Search Space, USS）であるかを示す。ＵＥ固有サーチスペースは、少なくとも、端末装置１がセットしているＣ−ＲＮＴＩの値から導き出される。すなわち、ＵＥ固有サーチスペースは、端末装置１毎に個別に導き出される。コモンサーチスペースは、複数の端末装置１の間で共通のサーチスペースであり、予め定められたインデックスのＣＣＥ（Control Channel Element）から構成される。ＣＣＥは、複数のリソースエレメントから構成される。サーチスペースの設定情報には、該サーチスペースでモニタされるＤＣＩフォーマットの情報が含まれる。
サーチスペースの設定情報には、ＣＯＲＥＳＥＴの設定情報で特定されるＣＯＲＥＳＥＴの識別子が含まれる。サーチスペースの設定情報の中に含まれるＣＯＲＥＳＥＴの識別子で特定されるＣＯＲＥＳＥＴは、該サーチスペースと関連付けられる。言い換えると、該サーチスペースに関連付けられるＣＯＲＥＳＥＴは、該サーチスペースに含まれるＣＯＲＥＳＥＴの識別子で特定するＣＯＲＥＳＥＴである。該サーチスペースの設定情報で示されるＤＣＩフォーマットは、関連付けられるＣＯＲＥＳＥＴでモニタされる。各サーチスペースは一つのＣＯＲＥＳＥＴに関連付けられる。例えば、ランダムアクセス手順のためのサーチスペースの設定情報はｒａ−ＳｅａｒｃｈＳｐａｃｅによって設定されてもよい。即ち、ｒａ−ＳｅａｒｃｈＳｐａｃｅと関連付けられるＣＯＲＥＳＥＴでＲＡ−ＲＮＴＩまたはＴＣ−ＲＮＴＩによってスクランブルされるＣＲＣが付加されたＤＣＩフォーマットがモニタされる。
端末装置１は、ＰＤＣＣＨをモニタリングするように設定されているそれぞれのアクテ
ィブなサービングセルに配置される、１つまたは複数のＣＯＲＥＳＥＴにおいて、ＰＤＣＣＨの候補のセットをモニタする。ＰＤＣＣＨの候補のセットは、１つまたは複数のサーチスペースセットに対応している。モニタリングすることは、モニタされる１つまたは複数のＤＣＩフォーマットに応じてそれぞれのＰＤＣＣＨの候補をデコードすることを意味する。端末装置１がモニタするＰＤＣＣＨの候補のセットは、ＰＤＣＣＨサーチスペースセット（PDCCH search space sets）で定義される。一つのサーチスペースセットは、コ
モンサーチスペースセットまたはＵＥ固有サーチスペースセットである。上記では、サーチスペースセットをサーチスペース、コモンサーチスペースセットをコモンサーチスペース、ＵＥ固有サーチスペースセットをＵＥ固有サーチスペースと称している。端末装置１は、１つまたは複数の以下のサーチスペースセットでＰＤＣＣＨ候補をモニタする。
- タイプ０ＰＤＣＣＨコモンサーチスペースセット（a Type0-PDCCH common search
space set、タイプ０コモンサーチスペース）： このサーチスペースセットは、上位層
のパラメータである、ＭＩＢで示されるｐｄｃｃｈ−ＣｏｎｆｉｇＳＩＢ１またはＰＤＣＣＨ−ＣｏｎｆｉｇＣｏｍｍｏｎで示されるサーチスペースＳＩＢ１（searchSpaceSIB1
）またはＰＤＣＣＨ−ＣｏｎｆｉｇＣｏｍｍｏｎに含まれるサーチスペースゼロ（searchSpaceZero）によって設定される。このサーチスペースは、プライマリセルにおけるＳＩ−ＲＮＲＩでスクランブルされたＣＲＣのＤＣＩフォーマットのモニタリングのためのものである。
- タイプ０ＡＰＤＣＣＨコモンサーチスペースセット（a Type0A-PDCCH common search space set、タイプ０Ａコモンサーチスペース）： このサーチスペースセットは、上位層のパラメータである、ＰＤＣＣＨ−ＣｏｎｆｉｇＣｏｍｍｏｎで示されるサーチスペース（searchSpaceOtherSystemInformation）によって設定される。このサーチスペースは、プライマリセルにおけるＳＩ−ＲＮＲＩでスクランブルされたＣＲＣのＤＣＩフォーマットのモニタリングのためのものである。
- タイプ１ＰＤＣＣＨコモンサーチスペースセット（a Type1-PDCCH common search
space set、タイプ１コモンサーチスペース）： このサーチスペースセットは、上位層
のパラメータである、ＰＤＣＣＨ−ＣｏｎｆｉｇＣｏｍｍｏｎで示されるランダムアクセス手順のためのサーチスペース（ra-SearchSpace）によって設定される。このサーチスペースは、プライマリセルにおけるＲＡ−ＲＮＲＩまたはＴＣ−ＲＮＴＩでスクランブルされたＣＲＣのＤＣＩフォーマットのモニタリングのためのものである。タイプ１ＰＤＣＣＨコモンサーチスペースセットはランダムアクセス手順のためのサーチスペースセットである。
- タイプ２ＰＤＣＣＨコモンサーチスペースセット（a Type2-PDCCH common search
space set、タイプ２コモンサーチスペース）： このサーチスペースセットは、上位層
のパラメータである、ＰＤＣＣＨ−ＣｏｎｆｉｇＣｏｍｍｏｎで示されるページング手順のためのサーチスペース（pagingSearchSpace）によって設定される。このサーチスペー
スは、プライマリセルにおけるＰ−ＲＮＴＩでスクランブルされたＣＲＣのＤＣＩフォーマットのモニタリングのためのものである。
- タイプ３ＰＤＣＣＨコモンサーチスペースセット（a Type3-PDCCH common search
space set、タイプ３コモンサーチスペース）： このサーチスペースセットは、上位層
のパラメータである、ＰＤＣＣＨ−Ｃｏｎｆｉｇで示されるサーチスペースタイプがコモンのサーチスペース（SearchSpace）によって設定される。このサーチスペースは、ＩＮ
Ｔ−ＲＮＴＩ、ＳＦＩ−ＲＮＴＩ、ＴＰＣ−ＰＵＳＣＨ−ＲＮＴＩ、ＴＰＣ−ＰＵＣＣＨ−ＲＮＴＩ、またはＴＰＣ−ＳＲＳ−ＲＮＴＩでスクランブルされたＣＲＣのＤＣＩフォーマットのモニタリングのためのものである。プライマリライセルに対しては、Ｃ−ＲＮＴＩ、ＣＳ−ＲＮＴＩ（ｓ）、またはＭＣＳ−Ｃ−ＲＮＴＩでスクランブルされたＣＲＣのＤＣＩフォーマットのモニタリングのためのものである。
- ＵＥ固有サーチスペースセット（a UE-specific search space set）： このサーチスペースセットは、上位層のパラメータである、ＰＤＣＣＨ−Ｃｏｎｆｉｇで示されるサーチスペースタイプがＵＥ固有のサーチスペース（SearchSpace）によって設定される
。このサーチスペースは、Ｃ−ＲＮＴＩ、ＣＳ−ＲＮＴＩ（ｓ）、またはＭＣＳ−Ｃ−ＲＮＴＩでスクランブルされたＣＲＣのＤＣＩフォーマットのモニタリングのためのものである。
もし、端末装置１が、対応する上位層パラメータ（searchSpaceZero、searchSpaceSIB1、searchSpaceOtherSystemInformation、 pagingSearchSpace, ra-SearchSpaceなど） によって、１つまたは複数のサーチスペースセットを提供されて、端末装置１が、Ｃ−ＲＮＴＩまたはＣＳ−ＲＮＴＩを提供されている場合、端末装置１は、Ｃ−ＲＮＴＩまたはＣＳ−ＲＮＴＩを持つＤＣＩ ｆｏｒｍａｔ ０＿０とＤＣＩ ｆｏｒｍａｔ １＿０のためのＰＤＣＣＨ候補を、その１つまたは複数のサーチスペースセットでモニタしてもよい。
ＢＷＰの設定情報はＤＬ ＢＷＰの設定情報とＵＬ ＢＷＰの設定情報に分けられる。ＢＷＰの設定情報には、インフォメーションエレメントｂｗｐ−Ｉｄ（ＢＷＰの識別子）が含まれる。ＤＬ ＢＷＰの設定情報に含まれるＢＷＰの識別子は、あるサービングセルにおけるＤＬ ＢＷＰを特定（参照）するために使われる。ＵＬ ＢＷＰの設定情報に含まれるＢＷＰの識別子は、あるサービングセルにおけるＵＬ ＢＷＰを特定（参照）するために使われる。ＢＷＰの識別子はＤＬ ＢＷＰとＵＬ ＢＷＰのそれぞれに対して付与される。例えば、ＤＬ ＢＷＰに対応するＢＷＰの識別子はＤＬ ＢＷＰ インデックス（DL BWP index）と称してもよい。ＵＬ ＢＷＰに対応するＢＷＰの識別子はＵＬ ＢＷＰ インデックス（UL BWP index）と称してもよい。初期ＤＬ ＢＷＰは、ＤＬ ＢＷＰの識別子０によって参照される。初期ＵＬ ＢＷＰは、ＵＬ ＢＷＰの識別子０によって参照される。他のＤＬ ＢＷＰまたは他のＵＬ ＢＷＰのそれぞれは、ＢＷＰの識別子 １からｍａｘＮｒｏｆＢＷＰｓまでに参照されてもよい。つまり、０にセットしたＢＷＰの識別子（ｂｗｐ−Ｉｄ＝０）は、初期ＢＷＰに関連つけられ、他のＢＷＰに使われることができない。ｍａｘＮｒｏｆＢＷＰｓはサービングセルあたりのＢＷＰの最大数であり、４である。即ち、他のＢＷＰの識別子の値は、１から４までの値を取る。他の上位層の設定情報は、ＢＷＰの識別子を利用して特定のＢＷＰに関連付けられる。ＤＬ ＢＷＰとＵＬ ＢＷＰが同じＢＷＰの識別子を有することは、ＤＬ ＢＷＰとＵＬ ＢＷＰがペアされていることを意味してもよい。
端末装置１は、１つのプライマリセルと１５までのセカンダリセルが設定されてよい。
以下では、ＰＤＳＣＨを受信する手順について説明する。
端末装置１は、ＤＣＩフォーマット１＿０、ＤＣＩフォーマット１＿１またはＤＣＩフォーマット１＿２を含むＰＤＣＣＨの検出によって、対応するＰＤＳＣＨをデコード（受信）してもよい。対応するＰＤＳＣＨは、そのＤＣＩフォーマット（ＤＣＩ）によってスケジュールされる（示される）。そのスケジュールされるＰＤＳＣＨの開始位置（開始シンボル）をＳと称する。ＰＤＳＣＨの開始シンボルＳはあるスロット内でＰＤＳＣＨが送信（マップ）される最初のシンボルであってもよい。開始シンボルＳはスロットの始まりに対応する。例えば、Ｓの値が０である場合、端末装置１は、あるスロット内の１番目のシンボルからＰＤＳＣＨを受信してもよい。また、例えば、Ｓの値が２である場合、端末装置１は、あるスロットの３番目のシンボルからＰＤＳＣＨを受信してもよい。そのスケジュールされるＰＤＳＣＨの連続的な（Consecutive）シンボルの数をＬと称する。連続的なシンボルの数Ｌは開始シンボルＳから数える。ＰＤＳＣＨに対して割り当てられたＳとＬの決定は後述する。
ＰＤＳＣＨマッピングのタイプはＰＤＳＣＨマッピングタイプＡとＰＤＳＣＨマッピングタイプＢを有する。ＰＤＳＣＨマッピングタイプＡでは、Ｓは０から３までの値を取る
。Ｌは３から１４までの値を取る。ただし、ＳとＬの和は３から１４までの値を取る。ＰＤＳＣＨマッピングタイプＢでは、Ｓは０から１２までの値を取る。Ｌは｛２、４、７｝から１つの値を取る。ただし、ＳとＬの和は２から１４までの値を取る。
ＰＤＳＣＨためのＤＭＲＳシンボルの位置は、ＰＤＳＣＨマッピングのタイプに依存する。ＰＤＳＣＨための最初のＤＭＲＳシンボル（first DM-RS symbol）の位置は、ＰＤＳＣＨマッピングのタイプに依存する。ＰＤＳＣＨマッピングタイプＡでは、最初のＤＭＲＳシンボルの位置は、上位層のパラメータｄｍｒｓ−ＴｙｐｅＡ−Ｐｏｓｉｔｉｏｎに示されてもよい。つまり、上位層のパラメータｄｍｒｓ−ＴｙｐｅＡ−ＰｏｓｉｔｉｏｎはＰＤＳＣＨまたはＰＵＳＣＨのための最初のＤＭＲＳの位置を示すために用いられる。ｄｍｒｓ−ＴｙｐｅＡ−Ｐｏｓｉｔｉｏｎは、‘ｐｏｓ２’または‘ｐｏｓ３’のいずれかにセットされてもよい。例えば、ｄｍｒｓ−ＴｙｐｅＡ−Ｐｏｓｉｔｉｏｎが‘ｐｏｓ２’にセットされている場合、ＰＤＳＣＨための最初のＤＭＲＳシンボルの位置は、スロット内の３番目のシンボルであってもよい。例えば、ｄｍｒｓ−ＴｙｐｅＡ−Ｐｏｓｉｔｉｏｎが‘ｐｏｓ３’にセットされている場合、ＰＤＳＣＨための最初のＤＭＲＳシンボルの位置は、スロット内の４番目のシンボルであってもよい。ここで、Ｓは、ｄｍｒｓ−ＴｙｐｅＡ−Ｐｏｓｉｔｉｏｎが‘ｐｏｓ３’にセットされている場合のみに、３の値をとれる。つまり、ｄｍｒｓ−ＴｙｐｅＡ−Ｐｏｓｉｔｉｏｎが‘ｐｏｓ２’にセットされている場合、Ｓは０から２までの値をとる。ＰＤＳＣＨマッピングタイプＢでは、最初のＤＭＲＳシンボルの位置は、割り当てられるＰＤＳＣＨの最初のシンボルである。
図７は本実施形態に係るＰＤＳＣＨマッピングタイプの一例を示す図である。図７（Ａ）はＰＤＳＣＨマッピングタイプＡの一例を示す図である。図７（Ａ）において、割り当てられるＰＤＳＣＨのＳは３である。割り当てられるＰＤＳＣＨのＬは７である。図７（Ａ）において、ＰＤＳＣＨための最初のＤＭＲＳシンボルの位置は、スロット内の４番目のシンボルである。即ち、ｄｍｒｓ−ＴｙｐｅＡ−Ｐｏｓｉｔｉｏｎが‘ｐｏｓ３’にセットされている。図７（Ｂ）はＰＤＳＣＨマッピングタイプＡの一例を示す図である。図７（Ｂ）において、割り当てられるＰＤＳＣＨのＳは４である。割り当てられるＰＤＳＣＨのＬは４である。図７（Ｂ）において、ＰＤＳＣＨための最初のＤＭＲＳシンボルの位置は、ＰＤＳＣＨが割り当てられる最初のシンボルである。
以下、ＰＤＳＣＨ時間領域リソース割り当ての特定方法について説明する。
基地局装置３は、ＤＣＩによって端末装置１にＰＤＳＣＨを受信させるようにスケジュールしてもよい。端末装置１は、自装置宛てのＤＣＩの検出によってＰＤＳＣＨを受信してもよい。端末装置１は、ＰＤＳＣＨ時間領域リソース割り当てを特定する時に、最初にＰＤＳＣＨに適用するリソース割り当てテーブルを決定する。リソース割り当てテーブルは、１つまたは複数のＰＤＳＣＨ時間領域リソース割り当てコンフィギュレーションを含む。端末装置１は、ＰＤＳＣＨをスケジュールするＤＣＩに含まれる‘Ｔｉｍｅ ｄｏｍａｉｎ ｒｅｓｏｕｒｃｅ ａｓｓｉｇｎｍｅｎｔ’フィールドに示される値に基づき、決定したリソース割り当てテーブル内の１つのＰＤＳＣＨ時間領域リソース割り当て設定を選んでもよい。つまり、基地局装置３は、端末装置１に対するＰＤＳＣＨのリソース割り当てを決定し、決定したリソース割り当てに基づく値の‘Ｔｉｍｅ ｄｏｍａｉｎ ｒｅｓｏｕｒｃｅ ａｓｓｉｇｎｍｅｎｔ’フィールドを生成し、その‘Ｔｉｍｅ ｄｏｍａｉｎ ｒｅｓｏｕｒｃｅ ａｓｓｉｇｎｍｅｎｔ’フィールドを含むＤＣＩを端末装置１に送信する。端末装置１は、‘Ｔｉｍｅ ｄｏｍａｉｎ ｒｅｓｏｕｒｃｅ ａｓｓｉｇｎｍｅｎｔ’フィールドの値に基づき、ＰＤＳＣＨの時間方向のリソース割り当てを特定する。
図１０は、ＰＤＳＣＨ時間領域リソース割り当てに適用するリソース割り当てテーブル
を定義する図である。端末装置１は、図１０に示されるテーブルに基づいて、ＰＤＳＣＨ時間領域リソース割り当てに適用するリソース割り当てテーブルを決定してもよい。リソース割り当てテーブルは、１つまたは複数のＰＤＳＣＨ時間領域リソース割り当ての設定（configuration）を含む。本実施形態において、リソース割り当てテーブルは、（Ｉ）事前に定義されるリソース割り当てテーブル、および、（ＩＩ）上位層のＲＲＣ信号から設定されるリソース割り当てテーブルと分類される。事前に定義されるリソース割り当てテーブルは、例えば、デフォルトＰＤＳＣＨ時間領域リソース割り当てＡ、デフォルトＰＤＳＣＨ時間領域リソース割り当てＢ、および、デフォルトＰＤＳＣＨ時間領域リソース割り当てＣとして定義される。また、デフォルトＰＤＳＣＨ時間領域リソース割り当てＡとは異なるデフォルトＰＤＳＣＨ時間領域リソース割り当てＤが定義されてもよい。以下では、それぞれ、デフォルトＰＤＳＣＨ時間領域リソース割り当てＡをデフォルトテーブルＡ、デフォルトＰＤＳＣＨ時間領域リソース割り当てＢをデフォルトテーブルＢ、デフォルトＰＤＳＣＨ時間領域リソース割り当てＣをデフォルトテーブルＣ、デフォルトＰＤＳＣＨ時間領域リソース割り当てＤをデフォルトテーブルＤと称する。
図１３は本実施形態に係るデフォルトテーブルＡの一例を示す図である。図１４は本実施形態に係るデフォルトテーブルＢの一例を示す図である。図１５は本実施形態に係るデフォルトテーブルＣの一例を示す図である。図１３の例では、デフォルトテーブルＡの行数は１６であり、各行はＰＤＳＣＨ時間領域リソース割り当ての設定を示す。図１３において、各行は、ＰＤＳＣＨマッピングタイプ、ＤＣＩを含むＰＤＣＣＨとそのＰＤＳＣＨとの間のスロットオフセットＫ０、スロット内のＰＤＳＣＨのスタートシンボルＳ、および、連続的な割当シンボル数Ｌを定義する。
上位層のＲＲＣ信号で設定されるリソース割り当てテーブルは、上位層の信号ｐｄｓｃｈ−ＴｉｍｅＤｏｍａｉｎＡｌｌｏｃａｔｉｏｎＬｉｓｔによって与えられる。ｐｄｓｃｈ−ＴｉｍｅＤｏｍａｉｎＡｌｌｏｃａｔｉｏｎＬｉｓｔは１つまたは複数のインフォメーションエレメントＰＤＳＣＨ−ＴｉｍｅＤｏｍａｉｎＲｅｓｏｕｒｃｅＡｌｌｏｃａｔｉｏｎを含む。ＰＤＳＣＨ−ＴｉｍｅＤｏｍａｉｎＲｅｓｏｕｒｃｅＡｌｌｏｃａｔｉｏｎは、ＰＤＳＣＨ時間領域リソース割り当ての設定を示す。ＰＤＳＣＨ−ＴｉｍｅＤｏｍａｉｎＲｅｓｏｕｒｃｅＡｌｌｏｃａｔｉｏｎは、ＤＣＩを含むＰＤＣＣＨとＰＤＳＣＨの間の時間領域の関係を設定するために用いられてよい。つまり、ｐｄｓｃｈ−ＴｉｍｅＤｏｍａｉｎＡｌｌｏｃａｔｉｏｎＬｉｓｔは１つまたは複数のインフォメーションエレメントを含むリストである。１つのＰＤＳＣＨ−ＴｉｍｅＤｏｍａｉｎＲｅｓｏｕｒｃｅＡｌｌｏｃａｔｉｏｎを１つのエントリ（または１つの行）と称してもよい。例えば、ｐｄｓｃｈ−ＴｉｍｅＤｏｍａｉｎＡｌｌｏｃａｔｉｏｎＬｉｓｔは最大１６個のエントリを含み、ＤＣＩに含まれる４ビットのフィールドによっていずれか１つのエントリが用いられてよい。ただし、ｐｄｓｃｈ−ＴｉｍｅＤｏｍａｉｎＡｌｌｏｃａｔｉｏｎＬｉｓｔに含まれるエントリの数は異なる数であってもよく、関連してＤＣＩに含まれるフィールドのビット数が異なる値であってもよい。ｐｄｓｃｈ−ＴｉｍｅＤｏｍａｉｎＡｌｌｏｃａｔｉｏｎＬｉｓｔの各エントリにおいて、Ｋ０、ｍａｐｐｉｎｇＴｙｐｅ、および／または、ｓｔａｒｔＳｙｍｂｏｌＡｎｄＬｅｎｇｔｈが示されてよい。Ｋ０はＤＣＩを含むＰＤＣＣＨとそのＰＤＳＣＨとの間のスロットオフセットを示す。ＰＤＳＣＨ−ＴｉｍｅＤｏｍａｉｎＲｅｓｏｕｒｃｅＡｌｌｏｃａｔｉｏｎによってＫ０を示されない場合、端末装置１はＫ０の値が所定の値（例えば０）であると想定してもよい。ｍａｐｐｉｎｇＴｙｐｅは、対応するＰＤＳＣＨのマッピングタイプがＰＤＳＣＨマッピングタイプＡであるか、またはＰＤＳＣＨマッピングタイプＢであるかを示す。ｓｔａｒｔＳｙｍｂｏｌＡｎｄＬｅｎｇｔｈは対応するＰＤＳＣＨのスタートシンボルＳ、および、連続的な割り当てシンボル数Ｌの有効な組み合わせを与えるインデックスである。ｓｔａｒｔＳｙｍｂｏｌＡｎｄＬｅｎｇｔｈをスタート位置と長さのインジケータ（ＳＬＩＶ：start and length indicator）と称してもよい。ＳＬＩＶが適用される場合は、デフォルトテーブルを用いる場合と異なり、対応するＰＤＳＣＨの開始シンボルＳと連続的なシンボル数Ｌは、ＳＬＩＶに基づいて与えられる。基地局装置３は、ＰＤＳＣＨの時間領域リソース割り当てがスロット境界を超えないようにＳＬＩＶの値をセットしてもよい。スロットオフセットＫ０とＳＬＩＶについては後述する。
上位層の信号ｐｄｓｃｈ−ＴｉｍｅＤｏｍａｉｎＡｌｌｏｃａｔｉｏｎＬｉｓｔはセル固有のＲＲＣパラメータｐｄｓｃｈ−ＣｏｎｆｉｇＣｏｍｍｏｎおよび／または端末装置１（ＵＥ）固有のＲＲＣパラメータｐｄｓｃｈ−Ｃｏｎｆｉｇに含まれてもよい。ｐｄｓｃｈ−ＣｏｎｆｉｇＣｏｍｍｏｎはあるＢＷＰに対するＰＤＳＣＨのためのセル固有パラメータを設定するために用いられる。ｐｄｓｃｈ−ＣｏｎｆｉｇはあるＢＷＰに対するＰＤＳＣＨのための端末装置１（ＵＥ）固有パラメータを設定するために用いられる。
端末装置１は、第１のＰＤＳＣＨを受信する場合と第２のＰＤＳＣＨを受信する場合とで、ＰＤＳＣＨ時間領域リソース割り当てに対して、異なるリソース割り当てテーブルを適用してもよい。基地局装置３は、第１のＰＤＳＣＨを送信する場合と第２のＰＤＳＣＨを送信する場合とで、ＰＤＳＣＨ時間領域リソース割り当てに対して、異なるリソース割り当てテーブルを適用してもよい。
第１のＰＤＳＣＨと第２のＰＤＳＣＨは異なるサービスのデータを伝送するＰＤＳＣＨであってよい。例えば、第１のＰＤＳＣＨはｅＭＢＢのデータを伝送するＰＤＳＣＨであり、第２のＰＤＳＣＨはＵＲＬＬＣのデータを伝送するＰＤＳＣＨであってもよい。第１のＰＤＳＣＨは、第１のＤＣＩによってスケジュールされるＰＤＳＣＨであってよい。第２のＰＤＳＣＨは、第２のＤＣＩによってスケジュールされるＰＤＳＣＨであってよい。第１のＤＣＩと第２のＤＣＩは異なるサービスのデータをスケジュールするＤＣＩであってよい。例えば、第１のＤＣＩはｅＭＢＢのデータを送信するＰＤＳＣＨをスケジュールするＤＣＩであり、第２のＤＣＩはＵＲＬＬＣのデータを送信するＰＤＳＣＨをスケジュールするＤＣＩであってもよい。
第１のＤＣＩと第２のＤＣＩは、異なるＲＮＴＩでスクランブルされたＣＲＣを付加されたＤＣＩであってもよい。例えば、第１のＤＣＩは第１の値の範囲であるＣ−ＲＮＴＩでスクランブルされたＣＲＣを付加されたＤＣＩであり、第２のＤＣＩは第１の値の範囲とは異なる第２の値の範囲であるＣ−ＲＮＴＩでスクランブルされたＣＲＣを付加されたＤＣＩであってもよい。例えば、第１のＤＣＩは第３の値の範囲である任意の種類のＲＮＴＩでスクランブルされたＣＲＣを付加されたＤＣＩであり、第２のＤＣＩは第３の値の範囲とは異なる第４の値の範囲である任意の種類のＲＮＴＩでスクランブルされたＣＲＣを付加されたＤＣＩであってもよい。例えば、第１のＤＣＩはＣ−ＲＮＴＩ、ＭＣＳ−Ｃ−ＲＮＴＩ，ＣＳ−ＲＮＴＩ、ＳＩ−ＲＮＴＩ、ＲＡ−ＲＮＴＩ、ＴＣ−ＲＮＴＩおよび／またはＰ−ＲＮＴＩでスクランブルされたＣＲＣを付加されたＤＣＩであり、第２のＤＣＩはＵＣ−ＲＮＴＩでスクランブルされたＣＲＣを付加されたＤＣＩであってもよい。ただし、ＵＣ−ＲＮＴＩはＣ−ＲＮＴＩ、ＭＣＳ−Ｃ−ＲＮＴＩ，ＣＳ−ＲＮＴＩ、ＳＩ−ＲＮＴＩ、ＲＡ−ＲＮＴＩ、ＴＣ−ＲＮＴＩおよびＰ−ＲＮＴＩで利用可能な値とは異なる値を用いるＲＮＴＩであってよい。ただし、ＵＣ−ＲＮＴＩは１つまたは複数のスロットにおける所定のサービスのデータのＰＤＳＣＨまたはＰＵＳＣＨを制御するために用いられるＲＮＴＩであってよい。
第１のＤＣＩと第２のＤＣＩは、異なるＤＣＩフォーマットを用いたＤＣＩであってもよい。例えば、第１のＤＣＩはＤＣＩフォーマット１＿１を用いたＤＣＩであり、第２のＤＣＩはＤＣＩフォーマット１＿２を用いたＤＣＩであってもよい。
第１のＤＣＩと第２のＤＣＩは、異なるサイズのＤＣＩフォーマットを用いたＤＣＩで
あってもよい。例えば、第１のＤＣＩは第１のサイズのＤＣＩフォーマットを用いたＤＣＩであり、第２のＤＣＩは第１のサイズとは異なる第２のサイズのＤＣＩフォーマットを用いたＤＣＩであってもよい。
第１のＤＣＩと第２のＤＣＩは、それぞれのＤＣＩフォーマット内の所定のフィールドで、対応するＰＤＳＣＨのデータに適用されるサービスが示されてもよい。例えば、第１のＤＣＩのＤＣＩフォーマット内のフィールドで、対応するＰＤＳＣＨがｅＭＢＢのデータを伝送することが特定されてもよい。例えば、第２のＤＣＩのＤＣＩフォーマット内のフィールドで、対応するＰＤＳＣＨがＵＲＬＬＣのデータを伝送することが特定されてもよい。
第１のＤＣＩと第２のＤＣＩは、異なるサーチスペースおよび／または異なるＣＯＲＥＳＥＴで伝送されるＤＣＩであってもよい。
第１のＤＣＩと第２のＤＣＩは、異なるコードブックのＰＤＳＣＨをスケジュールするＤＣＩであってもよい。
上位層のＲＲＣ信号で設定されるリソース割り当てテーブルは、上位層の信号ｐｄｓｃｈ−ＴｉｍｅＤｏｍａｉｎＡｌｌｏｃａｔｉｏｎＬｉｓｔとは異なる上位層の信号（インフォメーションエレメントあるいはＲＲＣパラメータであってよい）で与えられてもよい。例えば、上位層の信号ｐｄｓｃｈ−ＴｉｍｅＤｏｍａｉｎＡｌｌｏｃａｔｉｏｎＬｉｓｔ２によって与えられてもよい。基地局装置３は、上位層の信号でｐｄｓｃｈ−ＴｉｍｅＤｏｍａｉｎＡｌｌｏｃａｔｉｏｎＬｉｓｔおよび／またはｐｄｓｃｈ−ＴｉｍｅＤｏｍａｉｎＡｌｌｏｃａｔｉｏｎＬｉｓｔ２を通知してもよい。端末装置１は、上位層の信号でｐｄｓｃｈ−ＴｉｍｅＤｏｍａｉｎＡｌｌｏｃａｔｉｏｎＬｉｓｔおよび／またはｐｄｓｃｈ−ＴｉｍｅＤｏｍａｉｎＡｌｌｏｃａｔｉｏｎＬｉｓｔ２を受信してもよい。
ｐｄｓｃｈ−ＴｉｍｅＤｏｍａｉｎＡｌｌｏｃａｔｉｏｎＬｉｓｔ２はｐｄｓｃｈ−ＴｉｍｅＤｏｍａｉｎＡｌｌｏｃａｔｉｏｎＬｉｓｔと同様に、最大１６個のエントリを含み、ＤＣＩに含まれる４ビットのフィールドによっていずれか１つのエントリが用いられてよい。ｐｄｓｃｈ−ＴｉｍｅＤｏｍａｉｎＡｌｌｏｃａｔｉｏｎＬｉｓｔ２に含まれる各エントリにおいて、Ｋ０、ｍａｐｐｉｎｇＴｙｐｅ、および／または、ｓｔａｒｔＳｙｍｂｏｌＡｎｄＬｅｎｇｔｈが示されてよい。ｐｄｓｃｈ−ＴｉｍｅＤｏｍａｉｎＡｌｌｏｃａｔｉｏｎＬｉｓｔ２の各エントリにおけるＫ０、ｍａｐｐｉｎｇＴｙｐｅ、および／または、ｓｔａｒｔＳｙｍｂｏｌＡｎｄＬｅｎｇｔｈにおいて利用可能な値は、ｐｄｓｃｈ−ＴｉｍｅＤｏｍａｉｎＡｌｌｏｃａｔｉｏｎＬｉｓｔにおいて利用可能な値と異なってもよい。例えば、ｐｄｓｃｈ−ＴｉｍｅＤｏｍａｉｎＡｌｌｏｃａｔｉｏｎＬｉｓｔにおいて利用可能なＫ０の値は０〜３２であり、ｐｄｓｃｈ−ＴｉｍｅＤｏｍａｉｎＡｌｌｏｃａｔｉｏｎＬｉｓｔ２において利用可能なＫ０の値は０〜４であってもよい。例えば、ｐｄｓｃｈ−ＴｉｍｅＤｏｍａｉｎＡｌｌｏｃａｔｉｏｎＬｉｓｔにおいて利用可能なｍａｐｐｉｎｎｇＴｙｐｅはマッピングタイプＡとマッピングタイプＢであり、ｐｄｓｃｈ−ＴｉｍｅＤｏｍａｉｎＡｌｌｏｃａｔｉｏｎＬｉｓｔ２において利用可能なｍａｐｐｉｎｎｇＴｙｐｅはマッピングタイプＢのみであってもよい。例えば、ｐｄｓｃｈ−ＴｉｍｅＤｏｍａｉｎＡｌｌｏｃａｔｉｏｎＬｉｓｔ２ではｍａｐｐｉｎｎｇＴｙｐｅが示されなくてもよい。
端末装置１は、上位層の信号ｐｄｓｃｈ−Ｃｏｎｆｉｇにｐｄｓｃｈ−ＴｉｍｅＤｏｍａｉｎＡｌｌｏｃａｔｉｏｎＬｉｓｔが含まれており、かつ第１のＤＣＩでＰＤＳＣＨがスケジュールされている場合に、ＰＤＳＣＨのリソース割り当てテーブルにｐｄｓｃｈ−Ｃｏｎｆｉｇに含まれるｐｄｓｃｈ−ＴｉｍｅＤｏｍａｉｎＡｌｌｏｃａｔｉｏｎＬｉｓ
ｔを適用してもよい。端末装置１は、上位層の信号ｐｄｓｃｈ−Ｃｏｎｆｉｇにｐｄｓｃｈ−ＴｉｍｅＤｏｍａｉｎＡｌｌｏｃａｔｉｏｎＬｉｓｔ２が含まれており、かつ第２のＤＣＩでＰＤＳＣＨがスケジュールされている場合に、ＰＤＳＣＨのリソース割り当てテーブルにｐｄｓｃｈ−Ｃｏｎｆｉｇに含まれるｐｄｓｃｈ−ＴｉｍｅＤｏｍａｉｎＡｌｌｏｃａｔｉｏｎＬｉｓｔ２を適用してもよい。
端末装置１は、上位層の信号ｐｄｓｃｈ−Ｃｏｎｆｉｇおよびｐｄｓｃｈ−ＣｏｎｆｉｇＣｏｍｍｏｎにｐｄｓｃｈ−ＴｉｍｅＤｏｍａｉｎＡｌｌｏｃａｔｉｏｎＬｉｓｔが含まれておらず、かつ第１のＤＣＩでＰＤＳＣＨがスケジュールされている場合に、ＰＤＳＣＨのリソース割り当てテーブルにデフォルトテーブルＡを適用してもよい。端末装置１は、上位層の信号ｐｄｓｃｈ−Ｃｏｎｆｉｇおよびｐｄｓｃｈ−ＣｏｎｆｉｇＣｏｍｍｏｎにｐｄｓｃｈ−ＴｉｍｅＤｏｍａｉｎＡｌｌｏｃａｔｉｏｎＬｉｓｔ２が含まれておらず、かつ第２のＤＣＩでＰＤＳＣＨがスケジュールされている場合に、ＰＤＳＣＨのリソース割り当てテーブルにデフォルトテーブルＤを適用してもよい。端末装置１は、上位層の信号でｐｄｓｃｈ−ＴｉｍｅＤｏｍａｉｎＡｌｌｏｃａｔｉｏｎＬｉｓｔおよび／またはｐｄｓｃｈ−ＴｉｍｅＤｏｍａｉｎＡｌｌｏｃａｔｉｏｎＬｉｓｔ２が設定されていない場合に、第１のＤＣＩと第２のＤＣＩで異なるデフォルトテーブルを用いてもよい。端末装置１は、上位層の信号でｐｄｓｃｈ−ＴｉｍｅＤｏｍａｉｎＡｌｌｏｃａｔｉｏｎＬｉｓｔおよび／またはｐｄｓｃｈ−ＴｉｍｅＤｏｍａｉｎＡｌｌｏｃａｔｉｏｎＬｉｓｔ２が設定されていない場合に、第１のＤＣＩと第２のＤＣＩで同一のデフォルトテーブルを用いてもよい。
図１６は、ＳＬＩＶを算出する一例を示す図である。
図１６において、１４は１つのスロットに含まれるシンボルの数である。図１６は、ＮＣＰ（Normal Cyclic Prefix）の場合にＳＬＩＶを算出する一例を示す。ＳＬＩＶの値は、スロットに含まれるシンボルの数、開始シンボルＳ、および、連続的なシンボル数Ｌに基づいて、算出される。ここで、Ｌの値は１以上であり、（１４−Ｓ）を超えない。ＥＣＰでＳＬＩＶを算出する場合には、図１６における値７と１４には代わりに６と１２が使われる。
以下、スロットオフセットＫ０について説明する。
前述のように、サブキャリア間隔設定μにおいて、スロットは、サブフレーム内で０からＮ＾｛ｓｕｂｆｒａｍｅ，μ｝＿｛ｓｌｏｔ｝−１まで昇順に数えられ、フレーム内で０からＮ＾｛ｆｒａｍｅ，μ｝＿｛ｓｌｏｔ｝−１まで昇順に数えられる。Ｋ０はＰＤＳＣＨのサブキャリア間隔に基づくスロットの数である。Ｋ０は０から３２までの値を取り得る。あるサブフレームまたはフレームにおいて、スロットの番号は０からに昇順に数えられる。サブキャリア間隔設定１５ｋＨｚのスロット番号ｎは、サブキャリア間隔設定３０ｋＨｚのスロット番号２ｎと２ｎ＋１に対応する。
端末装置１がＰＤＳＣＨをスケジュールするＤＣＩを検出した場合に、そのＰＤＳＣＨに割り当てられるスロットはｆｌｏｏｒ（ｎ＊２μＰＤＳＣＨ／２μＰＤＣＣＨ）＋Ｋ０によって与えられる。関数ｆｌｏｏｒ（Ａ）は、Ａを上回らない最大の整数を出力する。ｎは、ＰＤＳＣＨをスケジュールするＰＤＣＣＨが検出されたスロットである。μＰＤＳＣＨはＰＤＳＣＨに対するサブキャリア間隔設定である。μＰＤＣＣＨはＰＤＣＣＨに対するサブキャリア間隔設定である。
端末装置１は、図１０に示されるように、複数の要素に基づいてＰＤＳＣＨ時間領域リソース割り当てに適用するリソース割り当てテーブルを決定してもよい。端末装置１は、
以下の要素（Ａ）から要素（Ｆ）の一部または全部に少なくとも基づいて、ＤＣＩによってスケジュールされるＰＤＳＣＨに適用するリソース割り当てテーブルを決定してもよい。
要素（Ａ）：ＤＣＩに付加されるＣＲＣをスクランブルするＲＮＴＩのタイプ
要素（Ｂ）：ＤＣＩが検出されるサーチスペースのタイプ
要素（Ｃ）：そのサーチスペースと関連付けられるＣＯＲＥＳＥＴがＣＯＲＥＳＥＴ＃０であるかどうか
要素（Ｄ）：ｐｄｓｃｈ−ＣｏｎｆｉｇＣｏｍｍｏｎがｐｄｓｃｈ−ＴｉｍｅＤｏｍａｉｎＡｌｌｏｃａｔｉｏｎＬｉｓｔを含むかどうか
要素（Ｅ）：ｐｄｓｃｈ−Ｃｏｎｆｉｇがｐｄｓｃｈ−ＴｉｍｅＤｏｍａｉｎＡｌｌｏｃａｔｉｏｎＬｉｓｔを含むかどうか
要素（Ｆ）：ＳＳ／ＰＢＣＨとＣＯＲＥＳＥＴ多重パターン
要素（Ａ）において、ＤＣＩに付加されるＣＲＣをスクランブルするＲＮＴＩのタイプは、ＳＩ−ＲＮＴＩ、ＲＡ−ＲＮＴＩ、ＴＣ−ＲＮＴＩ、Ｐ−ＲＮＴＩ、Ｃ−ＲＮＴＩ、ＭＣＳ−Ｃ−ＲＮＴＩ、または、ＣＳ−ＲＮＴＩのうち何れかである。
要素（Ｂ）において、ＤＣＩが検出されるサーチスペースのタイプは、コモンサーチスペース、または、ＵＥ固有サーチスペースである。コモンサーチスペースは、タイプ０コモンサーチスペース、タイプ１コモンサーチスペース、タイプ２コモンサーチスペースを含む。
例Ａとして、端末装置１は、ＣＯＲＥＳＥＴ＃０に関連付けられる任意のコモンサーチスペースにおいてＤＣＩを検出してもよい。検出したＤＣＩは、Ｃ−ＲＮＴＩ、ＭＣＳ−Ｃ−ＲＮＴＩ、または、ＣＳ−ＲＮＴＩのうち、何れかによってスクランブルされるＣＲＣが付加される。そして、端末装置１は、そのＤＣＩによってスケジュールされるＰＤＳＣＨに適用するリソース割り当てテーブルを決定してもよい。端末装置１に対してｐｄｓｃｈ−ＣｏｎｆｉｇＣｏｍｍｏｎがｐｄｓｃｈ−ＴｉｍｅＤｏｍａｉｎＡｌｌｏｃａｔｉｏｎＬｉｓｔを含む場合、端末装置１は、上位層のＲＲＣ信号から設定されるリソース割り当てテーブルを決定してもよい。そのリソース割り当てテーブルは、ｐｄｓｃｈ−ＣｏｎｆｉｇＣｏｍｍｏｎに含まれるｐｄｓｃｈ−ＴｉｍｅＤｏｍａｉｎＡｌｌｏｃａｔｉｏｎＬｉｓｔによって与えられる。また、端末装置１に対してｐｄｓｃｈ−ＣｏｎｆｉｇＣｏｍｍｏｎがｐｄｓｃｈ−ＴｉｍｅＤｏｍａｉｎＡｌｌｏｃａｔｉｏｎＬｉｓｔを含まない場合、端末装置１は、デフォルトテーブルＡを決定してもよい。つまり、端末装置１は、ＰＤＳＣＨ時間領域リソース割り当てのコンフィギュレーションを示すデフォルトテーブルＡを用いて、ＰＤＳＣＨ時間領域リソース割り当ての決定に適用してもよい。
例Ｂとして、端末装置１は、ＣＯＲＥＳＥＴ＃０に関連付けられない任意のコモンサーチスペースにおいてＤＣＩを検出してもよい。検出したＤＣＩは、Ｃ−ＲＮＴＩ、ＭＣＳ−Ｃ−ＲＮＴＩ、または、ＣＳ−ＲＮＴＩの内、何れかによってスクランブルされるＣＲＣが付加される。そして、端末装置１は、そのＤＣＩによってスケジュールされるＰＤＳＣＨに適用するリソース割り当てテーブルを決定してもよい。端末装置１に対してｐｄｓｃｈ−Ｃｏｎｆｉｇがｐｄｓｃｈ−ＴｉｍｅＤｏｍａｉｎＡｌｌｏｃａｔｉｏｎＬｉｓｔを含む場合、端末装置１は、ＰＤＳＣＨ時間領域リソース割り当てに適用するリソース割り当てテーブルを、ｐｄｓｃｈ−Ｃｏｎｆｉｇで提供されるｐｄｓｃｈ−ＴｉｍｅＤｏｍａｉｎＡｌｌｏｃａｔｉｏｎＬｉｓｔから与えられるリソース割り当てテーブルに決定してもよい。つまり、ｐｄｓｃｈ−Ｃｏｎｆｉｇがｐｄｓｃｈ−ＴｉｍｅＤｏｍａｉｎＡｌｌｏｃａｔｉｏｎＬｉｓｔを含む場合、端末装置１は、ｐｄｓｃｈ−ＣｏｎｆｉｇＣｏｍｍｏｎがｐｄｓｃｈ−ＴｉｍｅＤｏｍａｉｎＡｌｌｏｃａｔｉｏｎＬｉｓｔを含むか含まないかと関わらず、ｐｄｓｃｈ−Ｃｏｎｆｉｇで提供されるｐｄｓｃｈ−ＴｉｍｅＤｏｍ
ａｉｎＡｌｌｏｃａｔｉｏｎＬｉｓｔを用いて、ＰＤＳＣＨ時間領域リソース割り当ての決定に適用してもよい。また、ｐｄｓｃｈ−Ｃｏｎｆｉｇがｐｄｓｃｈ−ＴｉｍｅＤｏｍａｉｎＡｌｌｏｃａｔｉｏｎＬｉｓｔを含んでおらず、且つ、ｐｄｓｃｈ−ＣｏｎｆｉｇＣｏｍｍｏｎがｐｄｓｃｈ−ＴｉｍｅＤｏｍａｉｎＡｌｌｏｃａｔｉｏｎＬｉｓｔを含む場合、端末装置１は、ＰＤＳＣＨ時間領域リソース割り当てに適用するリソース割り当てテーブルを、ｐｄｓｃｈ−ＣｏｎｆｉｇＣｏｍｍｏｎで提供されるｐｄｓｃｈ−ＴｉｍｅＤｏｍａｉｎＡｌｌｏｃａｔｉｏｎＬｉｓｔから与えられるリソース割り当てテーブルに決定してもよい。つまり、端末装置１は、ｐｄｓｃｈ−ＣｏｎｆｉｇＣｏｍｍｏｎで提供されるｐｄｓｃｈ−ＴｉｍｅＤｏｍａｉｎＡｌｌｏｃａｔｉｏｎＬｉｓｔを用いて、ＰＤＳＣＨ時間領域リソース割り当ての決定に適用する。また、ｐｄｓｃｈ−Ｃｏｎｆｉｇがｐｄｓｃｈ−ＴｉｍｅＤｏｍａｉｎＡｌｌｏｃａｔｉｏｎＬｉｓｔを含んでおらず、且つ、ｐｄｓｃｈ−ＣｏｎｆｉｇＣｏｍｍｏｎがｐｄｓｃｈ−ＴｉｍｅＤｏｍａｉｎＡｌｌｏｃａｔｉｏｎＬｉｓｔを含まない場合、端末装置１は、ＰＤＳＣＨ時間領域リソース割り当てに適用するリソース割り当てテーブルをデフォルトテーブルＡに決定してもよい。
例Ｃとして、端末装置１は、ＵＥ固有サーチスペースにおいてＤＣＩを検出してもよい。検出したＤＣＩは、Ｃ−ＲＮＴＩ、ＭＣＳ−Ｃ−ＲＮＴＩ、または、ＣＳ−ＲＮＴＩの内、何れかによってスクランブルされるＣＲＣが付加される。そして、端末装置１は、そのＤＣＩによってスケジュールされるＰＤＳＣＨに適用するリソース割り当てテーブルを決定してもよい。端末装置１に対してｐｄｓｃｈ−Ｃｏｎｆｉｇがｐｄｓｃｈ−ＴｉｍｅＤｏｍａｉｎＡｌｌｏｃａｔｉｏｎＬｉｓｔを含む場合、端末装置１は、ＰＤＳＣＨ時間領域リソース割り当てに適用するリソース割り当てテーブルを、ｐｄｓｃｈ−Ｃｏｎｆｉｇで提供されるｐｄｓｃｈ−ＴｉｍｅＤｏｍａｉｎＡｌｌｏｃａｔｉｏｎＬｉｓｔから与えられるリソース割り当てテーブルに決定してもよい。つまり、ｐｄｓｃｈ−Ｃｏｎｆｉｇがｐｄｓｃｈ−ＴｉｍｅＤｏｍａｉｎＡｌｌｏｃａｔｉｏｎＬｉｓｔを含む場合、端末装置１は、ｐｄｓｃｈ−ＣｏｎｆｉｇＣｏｍｍｏｎがｐｄｓｃｈ−ＴｉｍｅＤｏｍａｉｎＡｌｌｏｃａｔｉｏｎＬｉｓｔを含むか含まないかと関わらず、ｐｄｓｃｈ−Ｃｏｎｆｉｇで提供されるｐｄｓｃｈ−ＴｉｍｅＤｏｍａｉｎＡｌｌｏｃａｔｉｏｎＬｉｓｔを用いて、ＰＤＳＣＨ時間領域リソース割り当ての決定に適用してもよい。また、ｐｄｓｃｈ−Ｃｏｎｆｉｇがｐｄｓｃｈ−ＴｉｍｅＤｏｍａｉｎＡｌｌｏｃａｔｉｏｎＬｉｓｔを含んでおらず、且つ、ｐｄｓｃｈ−ＣｏｎｆｉｇＣｏｍｍｏｎがｐｄｓｃｈ−ＴｉｍｅＤｏｍａｉｎＡｌｌｏｃａｔｉｏｎＬｉｓｔを含む場合、端末装置１は、ＰＤＳＣＨ時間領域リソース割り当てに適用するリソース割り当てテーブルを、ｐｄｓｃｈ−ＣｏｎｆｉｇＣｏｍｍｏｎで提供されるｐｄｓｃｈ−ＴｉｍｅＤｏｍａｉｎＡｌｌｏｃａｔｉｏｎＬｉｓｔから与えられるリソース割り当てテーブルに決定してもよい。つまり、端末装置１は、ｐｄｓｃｈ−ＣｏｎｆｉｇＣｏｍｍｏｎで提供されるｐｄｓｃｈ−ＴｉｍｅＤｏｍａｉｎＡｌｌｏｃａｔｉｏｎＬｉｓｔを用いて、ＰＤＳＣＨ時間領域リソース割り当ての決定に適用する。また、ｐｄｓｃｈ−Ｃｏｎｆｉｇがｐｄｓｃｈ−ＴｉｍｅＤｏｍａｉｎＡｌｌｏｃａｔｉｏｎＬｉｓｔを含んでおらず、且つ、ｐｄｓｃｈ−ＣｏｎｆｉｇＣｏｍｍｏｎがｐｄｓｃｈ−ＴｉｍｅＤｏｍａｉｎＡｌｌｏｃａｔｉｏｎＬｉｓｔを含まない場合、端末装置１は、ＰＤＳＣＨ時間領域リソース割り当てに適用するリソース割り当てテーブルをデフォルトテーブルＡに決定してもよい。
例Ｂと例Ｃからみると、ＵＥ固有サーチスペースにおいて検出されるＰＤＳＣＨに適用するリソース割り当てテーブルの決定方法は、ＣＯＲＥＳＥＴ＃０に関連付けられない任意のコモンサーチスペースにおいて検出されるＰＤＳＣＨに適用するリソース割り当てテーブルの決定方法と同様である。
図１１は、本実施形態に係るＰＤＳＣＨに適用するリソース割り当てテーブルの決定法を示すテーブルの一例である。端末装置１は、図１０の最後の行（ＣＯＲＥＳＥＴ＃０に
関連付けられない任意のコモンサーチスペースまたはＵＥ固有サーチスペースにおいてＤＣＩを検出し、かつＲＮＴＩが所定のタイプのＲＮＴＩである場合）において図１１のようにリソース割り当てケーブルを決定してもよい。端末装置１は、要素（Ａ）から要素（Ｆ）の一部または全部に加えて、下記の要素（Ｇ）から要素（Ｉ）の少なくとも一部に基づいて、ＤＣＩによってスケジュールされるＰＤＳＣＨに適用するリソース割り当てテーブルを決定してもよい。
要素（Ｇ）：ＤＣＩが上記の第１のＤＣＩ（1st DCI）であるか第２のＤＣＩ（2nd DCI）であるか
要素（Ｈ）：ｐｄｓｃｈ−ＣｏｎｆｉｇＣｏｍｍｏｎがｐｄｓｃｈ−ＴｉｍｅＤｏｍａｉｎＡｌｌｏｃａｔｉｏｎＬｉｓｔ２を含むかどうか
要素（Ｉ）：ｐｄｓｃｈ−Ｃｏｎｆｉｇがｐｄｓｃｈ−ＴｉｍｅＤｏｍａｉｎＡｌｌｏｃａｔｉｏｎＬｉｓｔ２を含むかどうか
ただし、第１のＤＣＩの場合と第２のＤＣＩの場合とで同一のデフォルトテーブル（例えばデフォルトテーブルＡ）が用いられてもよい。ただし、ｐｄｓｃｈ−ＴｉｍｅＤｏｍａｉｎＡｌｌｏｃａｔｉｏｎＬｉｓｔ２は、ｐｄｓｃｈ−ＣｏｎｆｉｇＣｏｍｍｏｎには含まれないパラメータでありｐｄｓｃｈ−Ｃｏｎｆｉｇにのみ含まれるパラメータであってもよい。
図１１に示すテーブルでは、端末装置１および／または基地局装置３は、要素（Ａ）〜要素（Ｉ）に基づいてＰＤＳＣＨに適用するリソース割り当てテーブルをデフォルトテーブルＡ、デフォルトテーブルＤ、ｐｄｓｃｈ−ＣｏｎｆｉｇＣｏｍｍｏｎに含まれるｐｄｓｃｈ−ＴｉｍｅＤｏｍａｉｎＡｌｌｏｃａｔｉｏｎＬｉｓｔ、ｐｄｓｃｈ−Ｃｏｎｆｉｇに含まれるｐｄｓｃｈ−ＴｉｍｅＤｏｍａｉｎＡｌｌｏｃａｔｉｏｎＬｉｓｔ、ｐｄｓｃｈ−ＣｏｎｆｉｇＣｏｍｍｏｎに含まれるｐｄｓｃｈ−ＴｉｍｅＤｏｍａｉｎＡｌｌｏｃａｔｉｏｎＬｉｓｔ２およびｐｄｓｃｈ−Ｃｏｎｆｉｇに含まれるｐｄｓｃｈ−ＴｉｍｅＤｏｍａｉｎＡｌｌｏｃａｔｉｏｎＬｉｓｔ２の中から決定する。
図１２は、本実施形態に係るＰＤＳＣＨに適用するリソース割り当てテーブルの決定法を示すテーブルの別の一例である。図１２に示すテーブルでは、端末装置１および／または基地局装置３は、要素（Ａ）〜要素（Ｇ）と要素（Ｉ）に基づいてＰＤＳＣＨに適用するリソース割り当てテーブルをデフォルトテーブルＡ、ｐｄｓｃｈ−ＣｏｎｆｉｇＣｏｍｍｏｎに含まれるｐｄｓｃｈ−ＴｉｍｅＤｏｍａｉｎＡｌｌｏｃａｔｉｏｎＬｉｓｔ、ｐｄｓｃｈ−Ｃｏｎｆｉｇに含まれるｐｄｓｃｈ−ＴｉｍｅＤｏｍａｉｎＡｌｌｏｃａｔｉｏｎＬｉｓｔおよびｐｄｓｃｈ−Ｃｏｎｆｉｇに含まれるｐｄｓｃｈ−ＴｉｍｅＤｏｍａｉｎＡｌｌｏｃａｔｉｏｎＬｉｓｔ２の中から決定する。図１２に示すテーブルの例では、ＤＣＩが第２のＤＣＩであり、ｐｄｓｃｈ−Ｃｏｎｆｉｇにｐｄｓｃｈ−ＴｉｍｅＤｏｍａｉｎＡｌｌｏｃａｔｉｏｎＬｉｓｔ２が含まれず、ｐｄｓｃｈ−ＣｏｎｆｉｇＣｏｍｍｏｎにｐｄｓｃｈ−ＴｉｍｅＤｏｍａｉｎＡｌｌｏｃａｔｉｏｎＬｉｓｔが含まれる場合には、ＰＤＳＣＨに適用するリソース割り当てテーブルはｐｄｓｃｈ−ＣｏｎｆｉｇＣｏｍｍｏｎに含まれるｐｄｓｃｈ−ＴｉｍｅＤｏｍａｉｎＡｌｌｏｃａｔｉｏｎＬｉｓｔである。ただし、ＤＣＩが第２のＤＣＩであり、ｐｄｓｃｈ−Ｃｏｎｆｉｇにｐｄｓｃｈ−ＴｉｍｅＤｏｍａｉｎＡｌｌｏｃａｔｉｏｎＬｉｓｔ２が含まれない場合には、ＰＤＳＣＨに適用するリソース割り当てテーブルはデフォルトテーブルＡまたはデフォルトテーブルＤであってもよい。
続いて、端末装置１は、そのＰＤＳＣＨをスケジュールするＤＣＩに含まれる‘Ｔｉｍｅ ｄｏｍａｉｎ ｒｅｓｏｕｒｃｅ ａｓｓｉｇｎｍｅｎｔ’フィールドに示される値に基づき、決定したリソース割り当てテーブル内の１つのＰＤＳＣＨ時間領域リソース割り当てコンフィギュレーションを選んでもよい。例えば、ＰＤＳＣＨ時間領域リソース割り当てに適用するリソース割り当てテーブルがデフォルトテーブルＡである場合、‘Ｔｉ
ｍｅ ｄｏｍａｉｎ ｒｅｓｏｕｒｃｅ ａｓｓｉｇｎｍｅｎｔ’フィールドに示される値ｍは、デフォルトテーブルＡの行インデックス（ｒｏｗ ｉｎｄｅｘ）ｍ＋１を示してもよい。この時、ＰＤＳＣＨ時間領域リソース割り当ては、行インデックスｍ＋１から示される時間領域リソース割り当てのコンフィギュレーションである。端末装置１は、行インデックスｍ＋１から示される時間領域リソース割り当てのコンフィギュレーションを想定し、ＰＤＳＣＨを受信する。例えば、‘Ｔｉｍｅ ｄｏｍａｉｎ ｒｅｓｏｕｒｃｅ ａｓｓｉｇｎｍｅｎｔ’フィールドに示される値ｍが０である場合、端末装置１は、デフォルトテーブルＡの行インデックス１のＰＤＳＣＨ時間領域リソース割り当てのコンフィギュレーションを用いて、そのＤＣＩによってスケジュールされるＰＤＳＣＨの時間方向のリソース割り当てを特定する。
また、ＰＤＳＣＨ時間領域リソース割り当てに適用するリソース割り当てテーブルがｐｄｓｃｈ−ＴｉｍｅＤｏｍａｉｎＡｌｌｏｃａｔｉｏｎＬｉｓｔから与えられるリソース割り当てテーブルである場合、‘Ｔｉｍｅ ｄｏｍａｉｎ ｒｅｓｏｕｒｃｅ ａｓｓｉｇｎｍｅｎｔ’フィールドに示される値ｍは、リストｐｄｓｃｈ−ＴｉｍｅＤｏｍａｉｎＡｌｌｏｃａｔｉｏｎＬｉｓｔにおける（ｍ＋１）番目のエレメント（エントリ、行）に対応する。例えば、‘Ｔｉｍｅ ｄｏｍａｉｎ ｒｅｓｏｕｒｃｅ ａｓｓｉｇｎｍｅｎｔ’フィールドに示される値ｍが０である場合、端末装置１は、リストｐｄｓｃｈ−ＴｉｍｅＤｏｍａｉｎＡｌｌｏｃａｔｉｏｎＬｉｓｔにおける１番目のエレメント（エントリ）を参照してもよい。例えば、‘Ｔｉｍｅ ｄｏｍａｉｎ ｒｅｓｏｕｒｃｅ ａｓｓｉｇｎｍｅｎｔ’フィールドに示される値ｍが１である場合、端末装置１は、リストｐｄｓｃｈ−ＴｉｍｅＤｏｍａｉｎＡｌｌｏｃａｔｉｏｎＬｉｓｔにおける２番目のエレメント（エントリ）を参照してもよい。
また、ＰＤＳＣＨ時間領域リソース割り当てに適用するリソース割り当てテーブルがｐｄｓｃｈ−ＴｉｍｅＤｏｍａｉｎＡｌｌｏｃａｔｉｏｎＬｉｓｔ２から与えられるリソース割り当てテーブルである場合、‘Ｔｉｍｅ ｄｏｍａｉｎ ｒｅｓｏｕｒｃｅ ａｓｓｉｇｎｍｅｎｔ’フィールドに示される値ｍは、リストｐｄｓｃｈ−ＴｉｍｅＤｏｍａｉｎＡｌｌｏｃａｔｉｏｎＬｉｓｔ２における（ｍ＋１）番目のエレメント（エントリ、行）に対応する。例えば、‘Ｔｉｍｅ ｄｏｍａｉｎ ｒｅｓｏｕｒｃｅ ａｓｓｉｇｎｍｅｎｔ’フィールドに示される値ｍが０である場合、端末装置１は、リストｐｄｓｃｈ−ＴｉｍｅＤｏｍａｉｎＡｌｌｏｃａｔｉｏｎＬｉｓｔ２における１番目のエレメント（エントリ）を参照してもよい。例えば、‘Ｔｉｍｅ ｄｏｍａｉｎ ｒｅｓｏｕｒｃｅ ａｓｓｉｇｎｍｅｎｔ’フィールドに示される値ｍが１である場合、端末装置１は、リストｐｄｓｃｈ−ＴｉｍｅＤｏｍａｉｎＡｌｌｏｃａｔｉｏｎＬｉｓｔ２における２番目のエレメント（エントリ）を参照してもよい。
以下、ＤＣＩに含まれる‘Ｔｉｍｅ ｄｏｍａｉｎ ｒｅｓｏｕｒｃｅ ａｓｓｉｇｎｍｅｎｔ’フィールドのビット数（サイズ）について説明する。
端末装置１は、ＤＣＩフォーマット１＿０、ＤＣＩフォーマット１＿１またはＤＣＩフォーマット１＿２を含むＰＤＣＣＨの検出によって、対応するＰＤＳＣＨをデコード（受信）してもよい。ＤＣＩフォーマット１＿０に含まる‘Ｔｉｍｅ ｄｏｍａｉｎ ｒｅｓｏｕｒｃｅ ａｓｓｉｇｎｍｅｎｔ’フィールドのビット数は固定のビット数であってもよい。例えば、この固定のビット数は４であってもよい。つまり、ＤＣＩフォーマット１＿０に含まれる‘Ｔｉｍｅ ｄｏｍａｉｎ ｒｅｓｏｕｒｃｅ ａｓｓｉｇｎｍｅｎｔ’フィールドのサイズは４ビットである。また、ＤＣＩフォーマット１＿１およびＤＣＩフォーマット１＿２に含まれる‘Ｔｉｍｅ ｄｏｍａｉｎ ｒｅｓｏｕｒｃｅ ａｓｓｉｇｎｍｅｎｔ’フィールドのサイズは可変のビット数であってもよい。例えば、ＤＣＩフォーマット１＿１およびＤＣＩフォーマット１＿２に含まれる‘Ｔｉｍｅ ｄｏｍａｉｎ ｒｅｓｏｕｒｃｅ ａｓｓｉｇｎｍｅｎｔ’フィールドのビット数は０、１、２、３、４の内何れかであってもよい。また、ＤＣＩフォーマット１＿２に含まれる‘Ｔｉｍｅ ｄｏｍａｉｎ ｒｅｓｏｕｒｃｅ ａｓｓｉｇｎｍｅｎｔ’フィールドのビット数は４より大きい値であってもよい。
以下、ＤＣＩフォーマット１＿１およびＤＣＩフォーマット１＿２に含まれる‘Ｔｉｍｅ ｄｏｍａｉｎ ｒｅｓｏｕｒｃｅ ａｓｓｉｇｎｍｅｎｔ’フィールドのビット数の決定について説明する。
ＤＣＩフォーマット１＿１およびＤＣＩフォーマット１＿２に含まれる‘Ｔｉｍｅ ｄｏｍａｉｎ ｒｅｓｏｕｒｃｅ ａｓｓｉｇｎｍｅｎｔ’フィールドのビット数は、（Ｉ）ｐｄｓｃｈ−ＣｏｎｆｉｇＣｏｍｍｏｎがｐｄｓｃｈ−ＴｉｍｅＤｏｍａｉｎＡｌｌｏｃａｔｉｏｎＬｉｓｔ（またはｐｄｓｃｈ−ＴｉｍｅＤｏｍａｉｎＡｌｌｏｃａｔｉｏｎＬｉｓｔ２）を含むかどうか、および／または、（ＩＩ）ｐｄｓｃｈ−Ｃｏｎｆｉｇがｐｄｓｃｈ−ＴｉｍｅＤｏｍａｉｎＡｌｌｏｃａｔｉｏｎＬｉｓｔ（またはｐｄｓｃｈ−ＴｉｍｅＤｏｍａｉｎＡｌｌｏｃａｔｉｏｎＬｉｓｔ２）を含むかどうか、および／または、（ＩＩＩ）事前に定義したデフォルトテーブルに含まれる行の数に少なくとも基づいて、与えられてもよい。本実施形態において、ＤＣＩフォーマット１＿１およびＤＣＩフォーマット１＿２は、Ｃ−ＲＮＴＩ、ＭＣＳ−Ｃ−ＲＮＴＩ、および、ＣＳ−ＲＮＴＩの内、何れかによってスクランブルされるＣＲＣが付加される。ＤＣＩフォーマット１＿１は、ＵＥ固有サーチスペースにおいて検出されてもよい。本実施形態において、‘ｐｄｓｃｈ−Ｃｏｎｆｉｇがｐｄｓｃｈ−ＴｉｍｅＤｏｍａｉｎＡｌｌｏｃａｔｉｏｎＬｉｓｔ（またはｐｄｓｃｈ−ＴｉｍｅＤｏｍａｉｎＡｌｌｏｃａｔｉｏｎＬｉｓｔ２）を含む’の意味は、‘ｐｄｓｃｈ−Ｃｏｎｆｉｇでｐｄｓｃｈ−ＴｉｍｅＤｏｍａｉｎＡｌｌｏｃａｔｉｏｎＬｉｓｔ（またはｐｄｓｃｈ−ＴｉｍｅＤｏｍａｉｎＡｌｌｏｃａｔｉｏｎＬｉｓｔ２）が提供される’の意味であってもよい。‘ｐｄｓｃｈ−ＣｏｎｆｉｇＣｏｍｍｏｎがｐｄｓｃｈ−ＴｉｍｅＤｏｍａｉｎＡｌｌｏｃａｔｉｏｎＬｉｓｔ（またはｐｄｓｃｈ−ＴｉｍｅＤｏｍａｉｎＡｌｌｏｃａｔｉｏｎＬｉｓｔ２）を含む’の意味は、‘ｐｄｓｃｈ−ＣｏｎｆｉｇＣｏｍｍｏｎでｐｄｓｃｈ−ＴｉｍｅＤｏｍａｉｎＡｌｌｏｃａｔｉｏｎＬｉｓｔ（またはｐｄｓｃｈ−ＴｉｍｅＤｏｍａｉｎＡｌｌｏｃａｔｉｏｎＬｉｓｔ２）が提供される’の意味であってもよい。
‘Ｔｉｍｅ ｄｏｍａｉｎ ｒｅｓｏｕｒｃｅ ａｓｓｉｇｎｍｅｎｔ’フィールドのビット数は、ｃｅｉｌｉｎｇ（ｌｏｇ２（Ｉ））として与えられてもよい。関数ｃｅｉｌｉｎｇ（Ａ）は、Ａを下回らない最小の整数を出力する。端末装置１に対してｐｄｓｃｈ−ＴｉｍｅＤｏｍａｉｎＡｌｌｏｃａｔｉｏｎＬｉｓｔ（またはｐｄｓｃｈ−ＴｉｍｅＤｏｍａｉｎＡｌｌｏｃａｔｉｏｎＬｉｓｔ２）が設定（提供）される場合、Ｉの値はｐｄｓｃｈ−ＴｉｍｅＤｏｍａｉｎＡｌｌｏｃａｔｉｏｎＬｉｓｔ（またはｐｄｓｃｈ−ＴｉｍｅＤｏｍａｉｎＡｌｌｏｃａｔｉｏｎＬｉｓｔ２）に含まれるエントリの数であってもよい。端末装置１に対してｐｄｓｃｈ−ＴｉｍｅＤｏｍａｉｎＡｌｌｏｃａｔｉｏｎＬｉｓｔ（またはｐｄｓｃｈ−ＴｉｍｅＤｏｍａｉｎＡｌｌｏｃａｔｉｏｎＬｉｓｔ２）が設定（提供）されない場合、Ｉの値はデフォルトテーブル（デフォルトテーブルＡ（またはデフォルトテーブルＤ））の行の数であってもよい。つまり、端末装置１に対してｐｄｓｃｈ−ＴｉｍｅＤｏｍａｉｎＡｌｌｏｃａｔｉｏｎＬｉｓｔ（またはｐｄｓｃｈ−ＴｉｍｅＤｏｍａｉｎＡｌｌｏｃａｔｉｏｎＬｉｓｔ２）が設定される場合、‘Ｔｉｍｅ ｄｏｍａｉｎ ｒｅｓｏｕｒｃｅ ａｓｓｉｇｎｍｅｎｔ’フィールドのビット数は、ｐｄｓｃｈ−ＴｉｍｅＤｏｍａｉｎＡｌｌｏｃａｔｉｏｎＬｉｓｔ（またはｐｄｓｃｈ−ＴｉｍｅＤｏｍａｉｎＡｌｌｏｃａｔｉｏｎＬｉｓｔ２）に含まれるエントリの数に基づいて与えられてもよい。端末装置１に対してｐｄｓｃｈ−ＴｉｍｅＤｏｍａｉｎＡｌｌｏｃａｔｉｏｎＬｉｓｔ（またはｐｄｓｃｈ−ＴｉｍｅＤｏｍａｉｎＡｌｌｏｃａｔｉｏｎＬｉｓ
ｔ２）が設定されない場合、‘Ｔｉｍｅ ｄｏｍａｉｎ ｒｅｓｏｕｒｃｅ ａｓｓｉｇｎｍｅｎｔ’フィールドのビット数は、デフォルトテーブル（デフォルトテーブルＡ）の行の数に基づいて与えられてもよい。具体的に言うと、ｐｄｓｃｈ−Ｃｏｎｆｉｇがｐｄｓｃｈ−ＴｉｍｅＤｏｍａｉｎＡｌｌｏｃａｔｉｏｎＬｉｓｔ（またはｐｄｓｃｈ−ＴｉｍｅＤｏｍａｉｎＡｌｌｏｃａｔｉｏｎＬｉｓｔ２）を含む場合、Ｉの値はｐｄｓｃｈ−Ｃｏｎｆｉｇで提供されるｐｄｓｃｈ−ＴｉｍｅＤｏｍａｉｎＡｌｌｏｃａｔｉｏｎＬｉｓｔ（またはｐｄｓｃｈ−ＴｉｍｅＤｏｍａｉｎＡｌｌｏｃａｔｉｏｎＬｉｓｔ２）に含まれるエントリの数であってもよい。また、ｐｄｓｃｈ−Ｃｏｎｆｉｇがｐｄｓｃｈ−ＴｉｍｅＤｏｍａｉｎＡｌｌｏｃａｔｉｏｎＬｉｓｔ（またはｐｄｓｃｈ−ＴｉｍｅＤｏｍａｉｎＡｌｌｏｃａｔｉｏｎＬｉｓｔ２）を含んでおらず、且つ、ｐｄｓｃｈ−ＣｏｎｆｉｇＣｏｍｍｏｎがｐｄｓｃｈ−ＴｉｍｅＤｏｍａｉｎＡｌｌｏｃａｔｉｏｎＬｉｓｔ（またはｐｄｓｃｈ−ＴｉｍｅＤｏｍａｉｎＡｌｌｏｃａｔｉｏｎＬｉｓｔ２）を含む場合、Ｉの値はｐｄｓｃｈ−ＣｏｎｆｉｇＣｏｍｍｏｎで提供されるｐｄｓｃｈ−ＴｉｍｅＤｏｍａｉｎＡｌｌｏｃａｔｉｏｎＬｉｓｔ（またはｐｄｓｃｈ−ＴｉｍｅＤｏｍａｉｎＡｌｌｏｃａｔｉｏｎＬｉｓｔ２）に含まれるエントリの数であってもよい。また、ｐｄｓｃｈ−Ｃｏｎｆｉｇがｐｄｓｃｈ−ＴｉｍｅＤｏｍａｉｎＡｌｌｏｃａｔｉｏｎＬｉｓｔ（またはｐｄｓｃｈ−ＴｉｍｅＤｏｍａｉｎＡｌｌｏｃａｔｉｏｎＬｉｓｔ２）を含んでおらず、且つ、ｐｄｓｃｈ−ＣｏｎｆｉｇＣｏｍｍｏｎがｐｄｓｃｈ−ＴｉｍｅＤｏｍａｉｎＡｌｌｏｃａｔｉｏｎＬｉｓｔ（またはｐｄｓｃｈ−ＴｉｍｅＤｏｍａｉｎＡｌｌｏｃａｔｉｏｎＬｉｓｔ２）を含まない場合、Ｉの値はデフォルトテーブル（例えば、デフォルトテーブルＡまたはデフォルトテーブルＤ）に含まれる行の数であってもよい。
また、別の言い方で言えば、端末装置１に対してｐｄｓｃｈ−ＴｉｍｅＤｏｍａｉｎＡｌｌｏｃａｔｉｏｎＬｉｓｔ（またはｐｄｓｃｈ−ＴｉｍｅＤｏｍａｉｎＡｌｌｏｃａｔｉｏｎＬｉｓｔ２）が設定（提供）される場合、‘Ｔｉｍｅ ｄｏｍａｉｎ ｒｅｓｏｕｒｃｅ ａｓｓｉｇｎｍｅｎｔ’フィールドのビット数は、ｃｅｉｌｉｎｇ（ｌｏｇ２（Ｉ））として与えられてもよい。端末装置１に対してｐｄｓｃｈ−ＴｉｍｅＤｏｍａｉｎＡｌｌｏｃａｔｉｏｎＬｉｓｔ（またはｐｄｓｃｈ−ＴｉｍｅＤｏｍａｉｎＡｌｌｏｃａｔｉｏｎＬｉｓｔ２）が設定（提供）されない場合、‘Ｔｉｍｅ ｄｏｍａｉｎ ｒｅｓｏｕｒｃｅ ａｓｓｉｇｎｍｅｎｔ’フィールドのビット数は、固定のビット数であってもよい。例えば、固定のビット数は４ビットであってもよい。
ここで、Ｉはｐｄｓｃｈ−ＴｉｍｅＤｏｍａｉｎＡｌｌｏｃａｔｉｏｎＬｉｓｔ（またはｐｄｓｃｈ−ＴｉｍｅＤｏｍａｉｎＡｌｌｏｃａｔｉｏｎＬｉｓｔ２）に含まれるエントリの数であってもよい。具体的に言うと、ｐｄｓｃｈ−Ｃｏｎｆｉｇがｐｄｓｃｈ−ＴｉｍｅＤｏｍａｉｎＡｌｌｏｃａｔｉｏｎＬｉｓｔ（またはｐｄｓｃｈ−ＴｉｍｅＤｏｍａｉｎＡｌｌｏｃａｔｉｏｎＬｉｓｔ２）を含む場合、Ｉの値はｐｄｓｃｈ−Ｃｏｎｆｉｇで提供されるｐｄｓｃｈ−ＴｉｍｅＤｏｍａｉｎＡｌｌｏｃａｔｉｏｎＬｉｓｔ（またはｐｄｓｃｈ−ＴｉｍｅＤｏｍａｉｎＡｌｌｏｃａｔｉｏｎＬｉｓｔ２）に含まれるエントリの数であってもよい。また、ｐｄｓｃｈ−Ｃｏｎｆｉｇがｐｄｓｃｈ−ＴｉｍｅＤｏｍａｉｎＡｌｌｏｃａｔｉｏｎＬｉｓｔ（またはｐｄｓｃｈ−ＴｉｍｅＤｏｍａｉｎＡｌｌｏｃａｔｉｏｎＬｉｓｔ２）を含んでおらず、且つ、ｐｄｓｃｈ−ＣｏｎｆｉｇＣｏｍｍｏｎがｐｄｓｃｈ−ＴｉｍｅＤｏｍａｉｎＡｌｌｏｃａｔｉｏｎＬｉｓｔ（またはｐｄｓｃｈ−ＴｉｍｅＤｏｍａｉｎＡｌｌｏｃａｔｉｏｎＬｉｓｔ２）を含む場合、Ｉの値はｐｄｓｃｈ−ＣｏｎｆｉｇＣｏｍｍｏｎで提供されるｐｄｓｃｈ−ＴｉｍｅＤｏｍａｉｎＡｌｌｏｃａｔｉｏｎＬｉｓｔ（またはｐｄｓｃｈ−ＴｉｍｅＤｏｍａｉｎＡｌｌｏｃａｔｉｏｎＬｉｓｔ２）に含まれるエントリの数であってもよい。
また、ｐｄｓｃｈ−ＴｉｍｅＤｏｍａｉｎＡｌｌｏｃａｔｉｏｎＬｉｓｔに含まれるエントリの数は、ｐｄｓｃｈ−ＴｉｍｅＤｏｍａｉｎＡｌｌｏｃａｔｉｏｎＬｉｓｔ２に含まれるエントリの数と異なってもよい。ｐｄｓｃｈ−ＴｉｍｅＤｏｍａｉｎＡｌｌｏｃａ
ｔｉｏｎＬｉｓｔに含まれるエントリの最大数は、第１の値であってもよい。例えば、第１の値は１６である。ｐｄｓｃｈ−ＴｉｍｅＤｏｍａｉｎＡｌｌｏｃａｔｉｏｎＬｉｓｔ２に含まれるエントリの最大数は、第２の値であってもよい。例えば、第１の値は１６より大きい値である。
図８はＤＣＩを伴うＰＤＣＣＨによってスケジュールされるＰＤＳＣＨ受信と対応するＨＡＲＱ−ＡＣＫの送信の一例を示す図である。図８（Ａ）は、第１のＤＣＩを伴うＰＤＣＣＨによってスケジュールされるＰＤＳＣＨ（第１のＰＤＳＣＨ）の受信と対応するＨＡＲＱ−ＡＣＫ（第１のＨＡＲＱ−ＡＣＫ）の送信の一例を示す図である。図８（Ｂ）は、第１のＤＣＩと第２のＤＣＩを伴うＰＤＣＣＨによってスケジュールされるＰＤＳＣＨ（第１のＰＤＳＣＨと第２のＰＤＳＣＨ）の受信と対応するＨＡＲＱ−ＡＣＫ（第１のＨＡＲＱ−ＡＣＫと第２のＨＡＲＱ−ＡＣＫ）の送信の一例を示す図である。
端末装置１は、ＤＣＩを含むＰＤＣＣＨの検出によって、対応するＰＤＳＣＨを受信（検出）してもよい。あるセル（ある所与のスケジューリングセル）内の任意２つのＨＡＲＱプロセス番号において、端末装置１がスロットｉでＰＤＳＣＨを受信し、対応するＨＡＲＱ−ＡＣＫをスロットｊで送信するようにスケジュールされている場合、端末装置１は、スロットｉより後のスロットでＰＤＳＣＨを受信し、対応するＨＡＲＱ−ＡＣＫをスロットｊより前のスロットで送信するようにスケジュールされるとは期待しない。ここで、言及されたＰＤＣＣＨは、第１のＤＣＩを伴うＰＤＣＣＨに対応してもよい。言及されたＰＤＳＣＨは、第１のＤＣＩによってスケジュールされる第１のＰＤＳＣＨに対応してもよい。言及されたＨＡＲＱ−ＡＣＫは、第１のＤＣＩによってスケジュールされる第１のＰＤＳＣＨに対応するＨＡＲＱ−ＡＣＫであってもよい。
ただし、端末装置１は、アウト オフ オーダー（Ｏｕｔ ｏｆ Ｏｒｄｅｒ）ＨＡＲＱ−ＡＣＫ送信をしてもよい。具体的に言うと、端末装置１は、シンボルｉで終了するＰＤＳＣＨに対応するＨＡＲＱ−ＡＣＫ送信をシンボルｊで開始するようにスケジュールされてもよい。ここで、ＰＤＣＣＨは、第１のＤＣＩを伴うＰＤＣＣＨに対応してもよい。ＨＡＲＱ−ＡＣＫは、第１のＤＣＩによってスケジュールされる第１のＰＤＳＣＨに対応するＨＡＲＱ−ＡＣＫ（第１のＨＡＲＱ−ＡＣＫ）であってもよい。続いて、端末装置１は、シンボルｉより後に終了する第２のＰＤＳＣＨを受信してもよい。該第２のＰＤＳＣＨに対応するＨＡＲＱ−ＡＣＫ（第２のＨＡＲＱ−ＡＣＫ）の送信は、第１のＨＡＲＱ−ＡＣＫ送信の開始シンボルｊより早く開始してもよい。また、端末装置１は、シンボルｉより後に終了する第２のＰＤＳＣＨを受信してもよい。該第２のＰＤＳＣＨに対応するＨＡＲＱ−ＡＣＫ（第２のＨＡＲＱ−ＡＣＫ）の送信は、第１のＨＡＲＱ−ＡＣＫ送信の終了シンボルより早く開始してもよい。本実施形態において、ＨＡＲＱ−ＡＣＫ送信は、該ＨＡＲＱ−ＡＣＫ（ＨＡＲＱ−ＡＣＫ情報ビット）を含むＰＵＣＣＨ送信と意味してもよい。
図８（Ａ）において、端末装置１は、ＰＤＳＣＨ（８００）を検出（受信）することによって、対応するＨＡＲＱ−ＡＣＫ（８０３）を送信してもよい。ここで、ＰＤＳＣＨ（８００）は第１のＤＣＩによってスケジュールされる第１のＰＤＳＣＨに対応する。ＰＤＳＣＨ（８０１）は、ＰＤＳＣＨ（８００）が終了するシンボルより後に終了するＰＤＳＣＨである。ＰＤＳＣＨ（８０１）の一部分のシンボルは、ＰＤＳＣＨ（８００）と時間的にオーバラップしてもよい。そして、ＨＡＲＱ−ＡＣＫ（８０２）は、ＨＡＲＱ−ＡＣＫ（８０３）の開始（終了）より早く開始するＨＡＲＱ−ＡＣＫであってもよい。ＨＡＲＱ−ＡＣＫ（８０４）は、ＨＡＲＱ−ＡＣＫ（８０３）の終了より後に開始するＨＡＲＱ−ＡＣＫであってもよい。ＨＡＲＱ−ＡＣＫ（８０２）、ＨＡＲＱ−ＡＣＫ（８０３）、および、ＨＡＲＱ−ＡＣＫ（８０４）は第１のＤＣＩによってスケジュールされる第１のＰＤＳＣＨに対応するＨＡＲＱ−ＡＣＫである。ＨＡＲＱ−ＡＣＫ（８０３）は、第１のＨＡＲＱプロセス番号を伴うＰＤＳＣＨに対応してもよい。ＨＡＲＱ−ＡＣＫ（８０２）は、第１のＨＡＲＱプロセス番号と異なる値に対応するＨＡＲＱプロセス番号を伴うＰＤＳＣＨに対応してもよい。ＨＡＲＱ−ＡＣＫ（８０４）は、第１のＨＡＲＱプロセス番号と異なる値に対応するＨＡＲＱプロセス番号を伴うＰＤＳＣＨに対応してもよい。すなわち、端末装置１は、ＰＤＳＣＨ（８０１）を受信し、ＰＤＳＣＨ（８０１）に対応するＨＡＲＱ−ＡＣＫ（８０２）を送信するようにスケジュールされることは期待しなくてもよい。端末装置１は、ＰＤＳＣＨ（８０１）を受信し、対応するＨＡＲＱ−ＡＣＫ（８０４）を送信するようにスケジュールされることは期待してもよい。すなわち、基地局装置３は、端末装置１にＰＤＳＣＨ（８００）に対応するＨＡＲＱ−ＡＣＫ（８０３）送信を開始するようにスケジュールしている場合に、ＰＤＳＣＨ（８０１）に対応するＨＡＲＱ−ＡＣＫ（８０２）を該端末装置１に送信するようにスケジュールしなくてもよい。すなわち、基地局装置３は、端末装置１にＰＤＳＣＨ（８００）に対応するＨＡＲＱ−ＡＣＫ（８０３）送信を開始するようにスケジュールしている場合に、ＰＤＳＣＨ（８０１）に対応するＨＡＲＱ−ＡＣＫ（８０４）を該端末装置１に送信するようにスケジュールしてもよい。
図８（Ｂ）は、アウト オフ オーダー（Ｏｕｔ ｏｆ Ｏｒｄｅｒ）ＨＡＲＱ−ＡＣＫ送信の一例を示す図である。図８（Ｂ）において、端末装置１は、ＰＤＳＣＨ（８１０）を検出することによって、その検出したＰＤＳＣＨに対応するＨＡＲＱ−ＡＣＫ（８１３）を送信してもよい。ここで、ＰＤＳＣＨ（８１０）は第１のＤＣＩがスケジュールする第１のＰＤＳＣＨに対応する。ＰＤＳＣＨ（８１１）は、ＰＤＳＣＨ（８１０）の終了するシンボルより後に終了するＰＤＳＣＨである。ＰＤＳＣＨ（８１１）の一部分のシンボルは、ＰＤＳＣＨ（８１０）と時間的にオーバラップしてもよい。そして、ＨＡＲＱ−ＡＣＫ（８１２）は、ＨＡＲＱ−ＡＣＫ（８１３）の終了（開始）より早く開始するＨＡＲＱ−ＡＣＫであってもよい。ＨＡＲＱ−ＡＣＫ（８１３）は第１のＤＣＩによってスケジュールされる第１のＰＤＳＣＨに対応するＨＡＲＱ−ＡＣＫであってもよい。ＨＡＲＱ−ＡＣＫ（８１２）は第２のＤＣＩによってスケジュールされる第２のＰＤＳＣＨに対応するＨＡＲＱ−ＡＣＫであってもよい。ＨＡＲＱ−ＡＣＫ（８１３）は、第１のＨＡＲＱプロセス番号を伴うＰＤＳＣＨに対応してもよい。ＨＡＲＱ−ＡＣＫ（８１２）は、第１のＨＡＲＱプロセス番号と異なる値に対応するＨＡＲＱプロセス番号を伴うＰＤＳＣＨに対応してもよい。すなわち、端末装置１は、ＰＤＳＣＨ（８１１）を受信し、対応するＨＡＲＱ−ＡＣＫ（８１２）を送信するようにスケジュールされることを期待してもよい。すなわち、基地局装置３は、端末装置１にＰＤＳＣＨ（８１０）の受信および対応するＨＡＲＱ−ＡＣＫ（８１３）送信を開始するようにスケジュールしている場合に、ＰＤＳＣＨ（８１１）の受信および対応するＨＡＲＱ−ＡＣＫ（８１２）を該端末装置１に送信するようにスケジュールしてもよい。ＰＤＳＣＨ（８１０）が終了するシンボルより後に終了するＰＤＳＣＨ（８１１）に対応する、ＨＡＲＱ−ＡＣＫ（８１３）の終了より早く開始するＨＡＲＱ−ＡＣＫ（８１２）の送信は、アウト オフ オーダー（Ｏｕｔ ｏｆ Ｏｒｄｅｒ）ＨＡＲＱ−ＡＣＫ送信と称してもよい。
以下、ＰＤＳＣＨ処理手順時間について説明する。
最初にＤＣＩ（スケジューリングＤＣＩ）がスケジュールするＰＤＳＣＨのためのＰＤＳＣＨ処理手順時間（ＰＤＳＣＨ Ｐｒｏｃｅｓｓｉｎｇ ｔｉｍｅ）Ｔｐｒｏｃ，１について、説明する。ＰＤＳＣＨ処理手順時間（ＰＤＳＣＨ Ｐｒｏｃｅｓｓｉｎｇ ｔｉｍｅ）Ｔｐｒｏｃ，１は、ＰＤＳＣＨに対応するＨＡＲＱ−ＡＣＫのためのＰＤＳＣＨ処理手順時間と称してもよい。Ｔｐｒｏｃ，１の値は、（式１）（Ｎ１＋ｄ１，１）（２０１８＋１４４）＊κ＊２−μ＊Ｔｃによって与えられてもよい。Ｎ１はＰＤＳＣＨ処理時間であり、ＰＤＳＣＨケイパビリティ１またはＰＤＳＣＨケイパビリティ２、および、ＤＭＲＳ位置、と、ＤＭＲＳシンボルの数に少なくとも基づいて、サブキャリア間隔のそれ
ぞれに対して、予め定義されたシンボルの数である。μは、（μＰＤＣＣＨ、μＰＤＳＣＨ、μＵＬ）の中から、より大きいＴｐｒｏｃ，１の値（最大の値）を算出するサブキャリア間隔に対応してもよい。μＰＤＣＣＨは、該ＰＤＳＣＨをスケジュールするＤＣＩを伴うＰＤＣＣＨのサブキャリア間隔に対応する。μＰＤＳＣＨは、スケジュールされるＰＤＳＣＨのサブキャリア間隔に対応する。μＵＬは、ＨＡＲＱ−ＡＣＫの送信が行われる上りリンクチャネルのサブキャリア間隔に対応する。κは、定数６４であり、Ｔｓ／Ｔｃから算出される。Ｔｓは、１／（Δｆｒｅｆ＊Ｎｆ、ｒｅｆ）から算出される。Ｔｃは、タイムユニットであり、１／（Δｆｍａｘ＊Ｎｆ）から算出される。Δｆｒｅｆは１５＊１０３ヘルツである。Ｎｆ、ｒｅｆは２０４８である。Δｆｍａｘは４８０＊１０３ヘルツである。Ｎｆは４０９６である。ｄ１，１は、ＰＤＳＣＨケイパビリティ、ＰＤＳＣＨマッピングタイプ、ＰＤＳＣＨが含むシンボルの数、ＰＤＳＣＨがそのＰＤＳＣＨをスケジュールするＰＤＣＣＨとオーバラップするシンボルの数に少なくとも基づいて与えられてもよい。
端末装置１は、ＨＡＲＱ−ＡＣＫ送信を伴うＰＵＣＣＨにおける最初の上りリンクシンボルがシンボルＬ１より前の上りリンクシンボルではない場合に、該ＰＤＳＣＨに対して有効なＨＡＲＱ−ＡＣＫメッセージを提供してもよい。有効なＨＡＲＱ−ＡＣＫメッセージを提供することは、端末装置１がそのＰＤＳＣＨ復号の結果に基づいて、該ＰＤＳＣＨに対するＡＣＫまたはＮＡＣＫを生成することを意味してもよい。即ち、端末装置１は、ＨＡＲＱ−ＡＣＫ送信のためのＰＵＣＣＨにおける最初の上りリンクシンボルがシンボルＬ１より前のシンボルである場合、該ＰＤＳＣＨに対して有効なＨＡＲＱ−ＡＣＫメッセージを提供してもよい。シンボルＬ１は、トランスポートブロックを伴うＰＤＳＣＨの最後のシンボルの受信の終了後にＴｐｒｏｃ，１の時間を始まって（経過して）から次のＣＰ（Cyclic Prefix）を伴う上りリンクシンボルとして定義される。すなわち、シンボル
Ｌ１の位置は、Ｔｐｒｏｃ，１の時間に基づいて特定（決定）されてもよい。すなわち、端末装置１は、ＰＤＳＣＨとそのＰＤＳＣＨに対応するＨＡＲＱ−ＡＣＫ送信を伴うＰＵＣＣＨとの間のタイムオフセット（time offset、上りリンクシンボルの数）がＴｐｒｏ
ｃ，１の時間（Ｔｐｒｏｃ，１の時間に対応する上りリンクシンボルの数）と等しいまたは大きい場合、該ＰＤＳＣＨに対して有効なＨＡＲＱ−ＡＣＫメッセージを提供してもよい。また、端末装置１は、ＰＤＳＣＨとそのＰＤＳＣＨに対応するＨＡＲＱ−ＡＣＫ送信を伴うＰＵＣＣＨとの間のタイムオフセット（time offset、上りリンクシンボルの数）
がＴｐｒｏｃ，１の時間（Ｔｐｒｏｃ，１の時間に対応する上りリンクシンボルの数）より小さい場合、該ＰＤＳＣＨに対して有効なＨＡＲＱ−ＡＣＫメッセージを提供しなくてもよい。有効なＨＡＲＱ−ＡＣＫメッセージを提供しないことは、端末装置１が時間の関係でそのＰＤＳＣＨを復号できないかもしれないが、復号の結果に基づきその該ＰＤＳＣＨに対してＨＡＲＱ−ＡＣＫを生成できないことを意味してもよい。
以下、アウト オフ オーダーＨＡＲＱ−ＡＣＫ送信が行われた場合に、ＰＤＳＣＨ処理手順時間について説明する。
異なるサービスのデータを伝送するＰＤＳＣＨ受信に対応するＨＡＲＱ−ＡＣＫ送信をサポートする端末装置１は、アウト オフ オーダーＨＡＲＱ−ＡＣＫ送信をサポートしてもよい。アウト オフ オーダーＨＡＲＱ−ＡＣＫ送信が行われた場合、ＨＡＲＱ−ＡＣＫ送信のためのＰＤＳＣＨ処理手順時間Ｔｐｒｏｃ，１は、（式１）から算出されたＰＤＳＣＨ処理手順時間の値と異なってもよい。例えば、Ｔｐｒｏｃ，１の値は、（式２）（Ｎ１＋ｄ１，１）（２０１８＋１４４）＊κ＊２−μ＊Ｔｃ＋Ｔｐｒｏｃ，１’によって与えられてもよい。以下、Ｔｐｒｏｃ，１’について説明する。（式２）での他のパラメータは、（式１）と同様であるため説明を省略する。
アウト オフ オーダーＨＡＲＱ−ＡＣＫ送信が行われた場合、Ｔｐｒｏｃ，１’は、
（式１）または（式２）に基づいて、与えられてもよい。アウト オフ オーダーＨＡＲＱ−ＡＣＫ送信が行われない場合、Ｔｐｒｏｃ，１’は、０にセットされてもよい。即ち、第１のＨＡＲＱ−ＡＣＫに対応するＰＤＳＣＨ処理手順時間は、該第１のＨＡＲＱ−ＡＣＫの送信前に、アウト オフ オーダーＨＡＲＱ−ＡＣＫ送信が行われるかどうかに基づいて、変わってもよい。
図８（Ｃ）は、ＰＤＳＣＨ処理手順時間とＨＡＲＱ−ＡＣＫ送信の一例を示す図である。図８（Ｃ）において、端末装置１は、ＰＤＳＣＨ（８２０）を検出（受信）することによって、そのＰＤＳＣＨに対応するＨＡＲＱ−ＡＣＫ（８２３）を送信してもよい。端末装置１は、ＰＤＳＣＨ（８２１）を検出することによって、そのＰＤＳＣＨに対応するＨＡＲＱ−ＡＣＫ（８２２）を送信してもよい。ここで、ＰＤＳＣＨ（８２０）は第１のＤＣＩによってスケジュールされる第１のＰＤＳＣＨに対応する。ＰＤＳＣＨ（８２１）は第２のＤＣＩによってスケジュールされる第２のＰＤＳＣＨに対応する。ＰＤＳＣＨ（８２１）は、ＰＤＳＣＨ（８２０）が終了するシンボルより後に終了するＰＤＳＣＨである。ＰＤＳＣＨ（８２１）の一部分のシンボルは、ＰＤＳＣＨ（８２０）と時間的にオーバラップしてもよい。ＨＡＲＱ−ＡＣＫ（８２２）は、ＨＡＲＱ−ＡＣＫ（８２３）の開始（終了）より早く開始するＨＡＲＱ−ＡＣＫであってもよい。ＨＡＲＱ−ＡＣＫ（８２２）に関連付けられるＨＡＲＱプロセス番号は、ＨＡＲＱ−ＡＣＫ（８２１）に関連付けられるＨＡＲＱプロセス番号と異なってもよい。即ち、ＨＡＲＱ−ＡＣＫ（８２３）が送信されようとする時に、アウト オフ オーダー（Ｏｕｔ ｏｆ Ｏｒｄｅｒ）ＨＡＲＱ−ＡＣＫ（ＨＡＲＱ−ＡＣＫ（８２２））送信が行われる。
図８（Ｃ）において、シンボル８２４、シンボル８２５、シンボル８２６は、シンボルＬ１に対応するシンボルの位置であってもよい。ＨＡＲＱ−ＡＣＫ（８２３）のためのＰＤＳＣＨ処理手順時間は、（式１）または（式２）に少なくとも基づいて、与えられてもよい。例えば、ＰＤＳＣＨ処理手順時間に基づき与えられたシンボルＬ１の位置がシンボル８２４または８２５の場合、端末装置１は、有効なＨＡＲＱ−ＡＣＫ（８２３）を提供してもよい。ＰＤＳＣＨ手順準備時間に基づき与えられたシンボルＬ１の位置がシンボル８２６の場合、端末装置１は、有効なＨＡＲＱ−ＡＣＫ（８２３）を提供しなくてもよい。該ＨＡＲＱ−ＡＣＫ（８２３）の送信に対して、アウト オフ オーダーＨＡＲＱ−ＡＣＫ（８２２）送信が行われた場合、該ＨＡＲＱ−ＡＣＫのためのＰＤＳＣＨ処理手順時間は、（式２）に少なくとも基づいて、与えられてもよい。該ＨＡＲＱ−ＡＣＫ（８２３）の送信に対して、アウト オフ オーダーＨＡＲＱ−ＡＣＫ（８２２）送信がない場合、該ＨＡＲＱ−ＡＣＫ（８２３）のためのＰＤＳＣＨ処理手順時間は、（式１）または（式２）に少なくとも基づいて、与えられてもよい。（式２）において、アウト オフ オーダーＨＡＲＱ−ＡＣＫ（８２２）送信が発生した場合、Ｔｐｒｏｃ，１’の値は、ＨＡＲＱ−ＡＣＫ（８２２）のためのＰＤＳＣＨ処理手順時間の値に対応してもよい。（式２）において、アウト オフ オーダーＨＡＲＱ−ＡＣＫ（８２２）送信が発生しない場合、Ｔｐｒｏｃ，１’の値は、０にセットされてもよい。別の言葉で言うと、ＨＡＲＱ−ＡＣＫ（８２３）のためのＰＤＳＣＨ処理手順時間の値は、（式１）に少なくとも基づいて、与えられた第１の値であってもよい。ＨＡＲＱ−ＡＣＫ（８２２）を送信する場合、ＨＡＲＱ−ＡＣＫ（８２３）のためのＰＤＳＣＨ処理手順時間の値は、第１の値に第２の値を加算した値であってもよい。第２の値は、ＨＡＲＱ−ＡＣＫ（８２２）のためのＰＤＳＣＨ処理手順時間の値に少なくとも基づいて与えられてもよい。ＨＡＲＱ−ＡＣＫ（８２２）の送信が発生しない場合、第２の値は、０であってもよい。
ＨＡＲＱ−ＡＣＫ（８２２）のためのＰＤＳＣＨ処理手順時間は、（式１）または（式２）に少なくとも基づいて、与えられてもよい。ここで、（式２）において、ＨＡＲＱ−ＡＣＫ（８２２）の送信に対して、アウト オフ オーダーＨＡＲＱ−ＡＣＫ送信が発生しないため、Ｔｐｒｏｃ，１’の値は、０にセットされてもよい。ＨＡＲＱ−ＡＣＫ（８
２２）に適用されるＰＤＳＣＨケイパビリティは、ＨＡＲＱ−ＡＣＫ（８２３）に適用されるＰＤＳＣＨケイパビリティと異なってもよい。即ち、ＨＡＲＱ−ＡＣＫ（８２２）に適用されるＮ１は、ＨＡＲＱ−ＡＣＫ（８２３）に適用されるＮ１の値と同様の値、または、ＨＡＲＱ−ＡＣＫ（８２３）に適用されるＮ１の値より小さい値であってもよい。また、端末装置１は、ＨＡＲＱ−ＡＣＫ（８２３）のためのＰＤＳＣＨ処理手順時間内で、ＨＡＲＱ−ＡＣＫ（８２２）の処理（準備）を開始しようとする時に、ＨＡＲＱ−ＡＣＫ（８２３）の処理（準備）を中止（スロット）してもよい。この時、ＨＡＲＱ−ＡＣＫ（８２２）のためのＰＤＳＣＨ処理手順時間は、（式１）または（式２）に少なくとも基づいて与えられた値にさらにＹ個のシンボルを加算した時間であってもよい。Ｙの値は、ＨＡＲＱ−ＡＣＫ（８２３）に適用されるＰＤＳＣＨケイパビリティ、および／または、ＨＡＲＱ−ＡＣＫ（８２３）に適用されるＰＤＳＣＨ処理時間Ｎ１に少なくともに基づいて定義された値であってもよい。ＨＡＲＱ−ＡＣＫ（８２３）の処理（準備）を中止（スロット）しない場合、Ｙの値は０であってもよい。また、端末装置１は、ＨＡＲＱ−ＡＣＫ（８２３）のためのＰＤＳＣＨ処理手順時間外で、ＨＡＲＱ−ＡＣＫ（８２２）の処理（準備）を開始しようとする時に、ＨＡＲＱ−ＡＣＫ（８２３）の処理（準備）を中止（スロット）しなくてもよい。この時、ＨＡＲＱ−ＡＣＫ（８２２）のためのＰＤＳＣＨ処理手順時間は、（式１）または（式２）に少なくとも基づいて与えられた値であってもよい。
即ち、図８（Ｃ）において、端末装置１は、アウト オフ オーダーＨＡＲＱ−ＡＣＫ（８２２）送信が発生した場合に、（式２）に基づいて与えられたＰＤＳＣＨ処理手順時間Ｔｐｒｏｃ，１を用いて、ＨＡＲＱ−ＡＣＫ（８２３）を送信するかどうかを判断してもよい。端末装置１は、（式２）に基づいて与えられたＰＤＳＣＨ処理手順時間に基づいて、シンボルＬ１の位置を特定してもよい。端末装置１は、ＨＡＲＱ−ＡＣＫ（８２３）のためのＰＵＣＣＨ割り当てにおける最初の上りリンクシンボルがシンボルＬ１より前のシンボルである場合、該ＨＡＲＱ−ＡＣＫ（８２３）を送信しなくてもよい。端末装置１は、ＨＡＲＱ−ＡＣＫ（８２３）のためのＰＵＣＣＨ割り当てにおける最初の上りリンクシンボルがシンボルＬ１またはシンボルＬ１より後のシンボルである場合、該ＨＡＲＱ−ＡＣＫ（８２３）を送信してもよい。
また、図８（Ｃ）において、端末装置１は、アウト オフ オーダーＨＡＲＱ−ＡＣＫ（８２２）送信が発生した場合に、（式１）に基づいて与えられたＰＤＳＣＨ処理手順時間Ｔｐｒｏｃ，１を用いて、ＨＡＲＱ−ＡＣＫ（８２３）を送信するかどうかを判断してもよい。ただし、この時、シンボルＬ１は、ＨＡＲＱ−ＡＣＫ（８２２）を伴うＰＵＣＣＨの最後のシンボルの送信の終了後にＴｐｒｏｃ，１の時間を始まって（経過して）から次のＣＰ（Cyclic Prefix）を伴う上りリンクシンボルとして定義されてもよい。端末装
置１は、ＨＡＲＱ−ＡＣＫ（９２３）のためのＰＵＣＣＨ割り当てにおける最初の上りリンクシンボルがシンボルＬ１より前のシンボルである場合、該ＨＡＲＱ−ＡＣＫ（８２３）を送信しなくてもよい。端末装置１は、ＨＡＲＱ−ＡＣＫ（８２３）割り当てにおける最初の上りリンクシンボルがシンボルＬ１またはシンボルＬ１より後のシンボルである場合、該ＨＡＲＱ−ＡＣＫ（８２３）を送信してもよい。
また、図８（Ｃ）において、端末装置１がＨＡＲＱ−ＡＣＫ（８２２）送信の発生によって、ＨＡＲＱ−ＡＣＫ（８２３）の処理を中止した場合、端末装置１は、（式１）に基づいて与えられたＰＤＳＣＨ処理手順時間Ｔｐｒｏｃ，１を用いて、ＨＡＲＱ−ＡＣＫ（８２３）を送信するかどうかを判断してもよい。ただし、この時、新たなシンボルＬ１は、ＨＡＲＱ−ＡＣＫ（８２２）を伴うＰＵＣＣＨの最後のシンボルの送信の終了後にＴｐｒｏｃ，１の時間を始まって（経過して）から次のＣＰ（Cyclic Prefix）を伴う上りリ
ンクシンボルとして定義されてもよい。また、端末装置１がＨＡＲＱ−ＡＣＫ（８２２）送信の発生があっても、ＨＡＲＱ−ＡＣＫ（８２３）の処理を中止しない場合、端末装置
１は、（式２）に基づいて与えられたＰＤＳＣＨ処理手順時間Ｔｐｒｏｃ，１を用いて、ＨＡＲＱ−ＡＣＫ（８２３）を送信するかどうかを判断してもよい。ただし、この時、シンボルＬ１は、ＰＤＳＣＨ（８２０）の最後のシンボルの受信の終了後にＴｐｒｏｃ，１の時間を始まって（経過して）から次のＣＰ（Cyclic Prefix）を伴う上りリンクシンボ
ルとして定義されてもよい。次に、端末装置１は、ＨＡＲＱ−ＡＣＫ（８２３）を伴うＰＵＣＣＨ割り当てにおける最初の上りリンクシンボルがシンボルＬ１より前のシンボルである場合、該ＨＡＲＱ−ＡＣＫ（８２３）を送信しなくてもよい。端末装置１は、ＨＡＲＱ−ＡＣＫ（８２３）を伴うＰＵＣＣＨ割り当てにおける最初の上りリンクシンボルがシンボルＬ１またはシンボルＬ１より後のシンボルである場合、該ＨＡＲＱ−ＡＣＫ（８２３）を送信してもよい。ＨＡＲＱ−ＡＣＫを送信することは、有効なＨＡＲＱ−ＡＣＫを提供することと意味してもよい。ＨＡＲＱ−ＡＣＫを送信しないことは、有効なＨＡＲＱ−ＡＣＫを提供しないことと意味してもよい。ＨＡＲＱ−ＡＣＫの処理を中止することは、ＨＡＲＱ−ＡＣＫが対応されるＰＤＳＣＨの処理（復号）を中止することと意味してもよい。
端末装置１は、第１のＤＣＩによってスケジュールされる第１のＰＤＳＣＨの検出によって、対応する第１のＨＡＲＱ−ＡＣＫを送信しようとする。端末装置１は、第１のＨＡＲＱ−ＡＣＫのＰＤＳＣＨ処理手順時間の値に少なくとも基づいて、該第１のＨＡＲＱ−ＡＣＫを送信するかどうかを決定してもよい。第１のＨＡＲＱ−ＡＣＫのＰＤＳＣＨ処理手順時間の値は、第１の値であってもよい。端末装置１は、第１のＰＤＳＣＨと第１のＨＡＲＱ−ＡＣＫ（第１のＨＡＲＱ−ＡＣＫを伴うＰＵＣＣＨ）との間のシンボル数が第１のＨＡＲＱ−ＡＣＫのＰＤＳＣＨ処理手順時間の値に対応するシンボルの数と等しいまたは多い場合、有効な第１のＨＡＲＱ−ＡＣＫ（メッセージ）を提供してもよい。端末装置１は、アウト オフ オーダーＨＡＲＱ−ＡＣＫ送信が発生する条件を満たす場合、第１のＨＡＲＱ−ＡＣＫのＰＤＳＣＨ処理手順時間の値は、第１の値に第２の値を加算した値であってもよい。アウト オフ オーダーＨＡＲＱ−ＡＣＫ送信が発生する条件には、以下の条件（ａ）から条件（ｈ）までの一部または全部が少なくとも含まれてもよい。（アウト オフ オーダー）ＨＡＲＱ−ＡＣＫ送信が発生することは、（アウト オフ オーダー）ＨＡＲＱ−ＡＣＫを送信することと意味してもよい。（アウト オフ オーダー）ＨＡＲＱ−ＡＣＫ送信が発生することは、（アウト オフ オーダー）ＨＡＲＱ−ＡＣＫがスケジュールされることと意味してもよい。（アウト オフ オーダー）ＨＡＲＱ−ＡＣＫ送信が発生することは、（アウト オフ オーダー）ＨＡＲＱ−ＡＣＫ送信が行われることと意味してもよい。
条件（ａ）は、第２のＨＡＲＱ−ＡＣＫが送信（スケジュール）されることである。
条件（ｂ）は、送信される第２のＨＡＲＱ−ＡＣＫが第２のＤＣＩによってスケジュールされる第２のＰＤＳＣＨに対応することである。
条件（ｃ）は、第２のＰＤＳＣＨの受信が第１のＰＤＳＣＨの受信が終了するシンボルより後に終了しことである。
条件（ｄ）は、第２のＨＡＲＱ−ＡＣＫの送信は、第１のＨＡＲＱ−ＡＣＫの送信の終了（開始）より早く開始されることである。
条件（ｅ）は、第２のＨＡＲＱ−ＡＣＫのためのＨＡＲＱプロセス番号が第１のＨＡＲＱ−ＡＣＫのためのＨＡＲＱプロセス番号と異なることである。
条件（ｆ）は、第１のＤＣＩに付加されたＣＲＣをスクランブルするＲＮＴＩの値が第１の範囲であり、第２のＤＣＩに付加されたＣＲＣをスクランブルするＲＮＴＩの値が第１の範囲とは異なる第２の範囲であることである。
条件（ｈ）は、第１のＤＣＩに用いられるフォーマットが第２のＤＣＩに用いられるフォーマットと異なるフォーマットであることである。
上述のように、アウト オフ オーダーＨＡＲＱ−ＡＣＫ送信が発生した場合、２つの
ＨＡＲＱ−ＡＣＫ送信（第１のＨＡＲＱ−ＡＣＫ送信と第２のＨＡＲＱ−ＡＣＫ送信、第１のＨＡＲＱ−ＡＣＫを伴うＰＵＣＣＨ送信と第２のＨＡＲＱ−ＡＣＫを伴うＰＵＣＣＨ送信）は、時間的にオーバラップしなくてもよい。アウト オフ オーダーＨＡＲＱ−ＡＣＫ送信が発生し、且つ、２つのＨＡＲＱ−ＡＣＫ送信（第１のＰＵＳＣＨ送信と第２のＰＵＳＣＨ送信）が時間的にオーバラップした場合、端末装置１は、ＰＤＳＣＨ処理手順時間に基づかず、第１のＨＡＲＱ−ＡＣＫを伴うＰＵＣＣＨ送信をドロップしてもよい。
以下では、ＰＵＳＣＨを受信する手順について説明する。
端末装置１は、ＤＣＩフォーマット０＿０、ＤＣＩフォーマット０＿１、または、ＤＣＩフォーマット０＿２を含むＰＤＣＣＨの検出によって、対応するＰＵＳＣＨを送信してもよい。つまり、対応するＰＵＳＣＨは、そのＤＣＩフォーマット（ＤＣＩ）によってスケジュールされてもよい（示される）。また、ＰＵＳＣＨは、ＲＡＲメッセージに含まれるＲＡＲ ＵＬグラントによってスケジュールされてもよい。そのスケジュールされるＰＵＳＣＨの開始位置（開始シンボル）をＳと称する。ＰＵＳＣＨの開始シンボルＳはあるスロット内でＰＵＳＣＨが送信（マップ）される最初のシンボルであってもよい。開始シンボルＳはスロットの始まりに対応する。例えば、Ｓの値が０である場合、端末装置１は、あるスロット内の１番目のシンボルからＰＵＳＣＨを送信してもよい。また、例えば、Ｓの値が２である場合、端末装置１は、あるスロットの３番目のシンボルからＰＵＳＣＨを送信してもよい。そのスケジュールされるＰＵＳＣＨの連続的なシンボルの数をＬと称する。連続的なシンボルの数Ｌは開始シンボルＳから数える。ＰＵＳＣＨに対して割り当てられたＳとＬの決定は後述する。
ＰＵＳＣＨマッピングのタイプはＰＵＳＣＨマッピングタイプＡおよびＰＵＳＣＨマッピングタイプＢを有する。ＰＵＳＣＨマッピングタイプＡでは、Ｓの値は０である。Ｌは４から１４までの値を取る。ただし、ＳとＬの和は４から１４までの値を取る。ＰＵＳＣＨマッピングタイプＢでは、Ｓは０から１３までの値を取る。Ｌは１から１４までの値を取る。ただし、ＳとＬの和は１から１４までの値を取る。
ＰＵＳＣＨためのＤＭＲＳシンボルの位置は、ＰＵＳＣＨマッピングのタイプに依存する。ＰＵＳＣＨための最初のＤＭＲＳシンボル（first DM-RS symbol）の位置は、ＰＵＳＣＨマッピングのタイプに依存する。ＰＵＳＣＨマッピングタイプＡでは、最初のＤＭＲＳシンボルの位置は、上位層のパラメータｄｍｒｓ−ＴｙｐｅＡ−Ｐｏｓｉｔｉｏｎに示されてもよい。ｄｍｒｓ−ＴｙｐｅＡ−Ｐｏｓｉｔｉｏｎは、‘ｐｏｓ２’または‘ｐｏｓ３’のいずれかにセットされる。例えば、ｄｍｒｓ−ＴｙｐｅＡ−Ｐｏｓｉｔｉｏｎが‘ｐｏｓ２’にセットされている場合、ＰＵＳＣＨための最初のＤＭＲＳシンボルの位置は、スロット内の３番目のシンボルであってもよい。例えば、ｄｍｒｓ−ＴｙｐｅＡ−Ｐｏｓｉｔｉｏｎが‘ｐｏｓ３’にセットされている場合、ＰＵＳＣＨための最初のＤＭＲＳシンボルの位置は、スロット内の４番目のシンボルであってもよい。ＰＵＳＣＨマッピングタイプＢでは、最初のＤＭＲＳシンボルの位置は、割り当てられるＰＵＳＣＨの最初のシンボルであってもよい。
以下、ＰＵＳＣＨ時間領域リソース割り当ての特定方法について説明する。
基地局装置３は、ＤＣＩによって端末装置１にＰＵＳＣＨを送信させるようにスケジュールしてもよい。そして、端末装置１は、自装置宛てのＤＣＩの検出によってＰＵＳＣＨを送信してもよい。端末装置１は、ＰＵＳＣＨ時間領域リソース割り当てを特定する時に、該ＰＵＳＣＨに適用するリソース割り当てテーブルを決定する。リソース割り当てテーブルは、１つまたは複数のＰＵＳＣＨ時間領域リソース割り当て設定を含む。端末装置１は、該ＰＵＳＣＨをスケジュールするＤＣＩに含まれる‘Ｔｉｍｅ ｄｏｍａｉｎ ｒｅｓｏｕｒｃｅ ａｓｓｉｇｎｍｅｎｔ’フィールドに示される値に基づき、決定したリソース割り当てテーブル内の１つのＰＵＳＣＨ時間領域リソース割り当て設定を選んでもよい。つまり、基地局装置３は、端末装置１にＰＵＳＣＨのリソース割り当てを決定し、‘Ｔｉｍｅ ｄｏｍａｉｎ ｒｅｓｏｕｒｃｅ ａｓｓｉｇｎｍｅｎｔ’フィールドの値を生成し、その‘Ｔｉｍｅ ｄｏｍａｉｎ ｒｅｓｏｕｒｃｅ ａｓｓｉｇｎｍｅｎｔ’フィールドを含むＤＣＩを端末装置１に送信する。端末装置１は、‘Ｔｉｍｅ ｄｏｍａｉｎ ｒｅｓｏｕｒｃｅ ａｓｓｉｇｎｍｅｎｔ’フィールドにセットされる値に基づき、ＰＵＳＣＨの時間領域のリソース割り当てを特定する。
図１７はどのリソース割り当てテーブルをＰＵＳＣＨ時間領域リソース割り当てに適用するかを定義する図である。端末装置１は、図１７を参照して、ＰＵＳＣＨ時間領域リソース割り当てに適用するリソース割り当てテーブルを決定してもよい。リソース割り当てテーブルは、１つまたは複数のＰＵＳＣＨ時間領域リソース割り当てのコンフィギュレーションを含む。本実施形態において、リソース割り当てテーブルは、（Ｉ）事前に定義されるリソース割り当てテーブル、および、（ＩＩ）上位層のＲＲＣ信号から設定されるリソース割り当てテーブルと分類される。事前に定義されるリソース割り当てテーブルは、デフォルトＰＵＳＣＨ時間領域リソース割り当てＡおよび／またはデフォルトＰＵＤＳＣＨ時間領域リソース割り当てＢとして定義される。以下、デフォルトＰＵＳＣＨ時間領域リソース割り当てＡをＰＵＳＣＨデフォルトテーブルＡ、デフォルトＰＵＤＳＣＨ時間領域リソース割り当てＢをＰＵＳＣＨデフォルトテーブルＢと称する。
図１８はＮＣＰ（Normal Cyclic Prefix）に対してＰＵＳＣＨデフォルトテーブルＡの一例を示す図である。図１８において、ＰＵＳＣＨデフォルトテーブルＡの行数は１６であり、各行はＰＵＳＣＨ時間領域リソース割り当ての設定（configuration）を示す。図
１８において、インデックス付きの行（indexed row）は、ＰＵＳＣＨマッピングタイプ
、ＤＣＩを含むＰＤＣＣＨとそのＰＵＳＣＨとの間のスロットオフセットＫ２、スロット内のＰＵＳＣＨのスタートシンボルＳ、および、連続的な割り当てられるシンボル数Ｌを定義する。ＰＵＳＣＨデフォルトテーブルＢもＰＵＳＣＨデフォルトテーブルと同様の構成であるが、各行におけるＰＵＳＣＨマッピングタイプ、Ｋ２、Ｓ、および／または、Ｌの値は異なってもよい。
上位層のＲＲＣ信号から設定されるリソース割り当てテーブルは、上位層の信号ｐｕｓｃｈ−ＴｉｍｅＤｏｍａｉｎＡｌｌｏｃａｔｉｏｎＬｉｓｔによって与えられる。インフォメーションエレメントＰＵＳＣＨ−ＴｉｍｅＤｏｍａｉｎＲｅｓｏｕｒｃｅＡｌｌｏｃａｔｉｏｎは、ＰUＳＣＨ時間領域リソース割り当ての設定を示す。ＰＵＳＣＨ−ＴｉｍｅＤｏｍａｉｎＲｅｓｏｕｒｃｅＡｌｌｏｃａｔｉｏｎは、ＤＣＩを含むＰＤＣＣＨとＰＵＳＣＨの間の時間領域関係を設定するために用いられてもよい。ｐｕｓｃｈ−ＴｉｍｅＤｏｍａｉｎＡｌｌｏｃａｔｉｏｎＬｉｓｔは１つまたは複数のインフォメーションエレメントＰＵＳＣＨ−ＴｉｍｅＤｏｍａｉｎＲｅｓｏｕｒｃｅＡｌｌｏｃａｔｉｏｎを含む。つまり、ｐｕｓｃｈ−ＴｉｍｅＤｏｍａｉｎＡｌｌｏｃａｔｉｏｎＬｉｓｔは１つまたは複数のエレメント（インフォメーションエレメント）を含むリストである。１つのインフォメーションエレメントＰＵＳＣＨ−ＴｉｍｅＤｏｍａｉｎＲｅｓｏｕｒｃｅＡｌｌｏｃａｔｉｏｎを１つのエントリ（または１つの行）とも称してもよい。ｐｕｓｃｈ−ＴｉｍｅＤｏｍａｉｎＡｌｌｏｃａｔｉｏｎＬｉｓｔは最大１６までのエントリを含んでもよい。エントリごとは、Ｋ２、ｍａｐｐｉｎｇＴｙｐｅ、および、ｓｔａｒｔＳｙｍｂｏｌＡｎｄＬｅｎｇｔｈによって定義されてもよい。Ｋ２はＤＣＩを含むＰＤＣＣＨとそのスケジュールされるＰＵＳＣＨとの間のスロットオフセットを示す。ＰＵＳＣＨ−ＴｉｍｅＤｏｍａｉｎＲｅｓｏｕｒｃｅＡｌｌｏｃａｔｉｏｎがＫ２を示さないならば、端末装置１は、ＰＵＳＣＨのサブキャリア間隔が１５ｋＨｚまたは３０ｋＨｚである場合に、Ｋ２の値が１であることを想定し、ＰＵＳＣＨのサブキャリア間隔が６０ｋＨｚである場合に、Ｋ２の値が２であることを想定し、ＰＵＳＣＨのサブキャリア間隔が１２０ｋＨｚである場合に、Ｋ２の値が３であることを想定してもよい。ｍａｐｐｉｎｇＴｙｐｅは、ＰＵＳＣＨマッピングタイプＡまたはＰＵＳＣＨマッピングタイプＡのいずれかを示す。ｓｔａｒｔＳｙｍｂｏｌＡｎｄＬｅｎｇｔｈはＰＵＳＣＨのスタートシンボルＳ、および、連続的な割り当てられるシンボル数Ｌの有効な組み合わせを与えるインデックスである。ｓｔａｒｔＳｙｍｂｏｌＡｎｄＬｅｎｇｔｈをスタートと長さインジケータＳＬＩＶ（start and length indicator）と称してもよい。つまり、開始シンボルＳと連続的なシンボルＬを直接に定義するデフォルトテーブルと異なって、開始シンボルＳと連続的なシンボルＬは、ＳＬＩＶに基づき与えられる。基地局装置３は、ＰＵＳＣＨの時間領域リソース割り当てがスロット境界を超えないよう、ＳＬＩＶの値をセットすることができる。ＳＬＩＶの値は、図１６における式のように、スロットに含まれるシンボルの数、開始シンボルＳ、および、連続的なシンボルの数Ｌに基づいて、算出される。
上位層の信号ｐｕｓｃｈ−ＴｉｍｅＤｏｍａｉｎＡｌｌｏｃａｔｉｏｎＬｉｓｔはセル固有のＲＲＣパラメータｐｕｓｃｈ−ＣｏｎｆｉｇＣｏｍｍｏｎおよび／または端末装置１（ＵＥ）固有のＲＲＣパラメータｐｕｓｃｈ−Ｃｏｎｆｉｇに含まれてもよい。ｐｕｓｃｈ−ＣｏｎｆｉｇＣｏｍｍｏｎはあるＢＷＰに対するＰＵＳＣＨのためのセル固有パラメータを設定するために用いられる。ｐｕｓｃｈ−ＣｏｎｆｉｇはあるＢＷＰに対するＰＵＳＣＨのための端末装置１（ＵＥ）固有パラメータを設定するために用いられる。
端末装置１は、第１のＰＵＳＣＨを送信する場合と第２のＰＵＳＣＨを送信する場合とで、ＰＵＳＣＨ時間領域リソース割り当てに対して、異なるリソース割り当てテーブルを適用してもよい。基地局装置３は、第１のＰＵＳＣＨを受信する場合と第２のＰＵＳＣＨを受信する場合とで、ＰＵＳＣＨ時間領域リソース割り当てに対して、異なるリソース割り当てテーブルを適用してもよい。
第１のＰＵＳＣＨと第２のＰＵＳＣＨは異なるサービスのデータを伝送するＰＵＳＣＨであってよい。例えば、第１のＰＵＳＣＨはｅＭＢＢのデータを伝送するＰＵＳＣＨであり、第２のＰＵＳＣＨはＵＲＬＬＣのデータを伝送するＰＵＳＣＨであってもよい。第１のＰＵＳＣＨは、第３のＤＣＩによってスケジュールされるＰＵＳＣＨであってよい。第２のＰＵＳＣＨは、第４のＤＣＩによってスケジュールされるＰＵＳＣＨであってよい。第３のＤＣＩと第４のＤＣＩは異なるサービスのデータをスケジュールするＤＣＩであってよい。例えば、第３のＤＣＩはｅＭＢＢのデータを送信するＰＵＳＣＨをスケジュールするＤＣＩであり、第４のＤＣＩはＵＲＬＬＣのデータを送信するＰＵＳＣＨをスケジュールするＤＣＩであってもよい。
第３のＤＣＩと第４のＤＣＩは、異なるＲＮＴＩでスクランブルされたＣＲＣを付加されたＤＣＩであってもよい。例えば、第３のＤＣＩは第１の値の範囲であるＣ−ＲＮＴＩでスクランブルされたＣＲＣを付加されたＤＣＩであり、第４のＤＣＩは第１の値とは異なる第２の値の範囲であるＣ−ＲＮＴＩでスクランブルされたＣＲＣを付加されたＤＣＩであってもよい。例えば、第３のＤＣＩは第３の値の範囲である任意の種類のＲＮＴＩでスクランブルされたＣＲＣを付加されたＤＣＩであり、第４のＤＣＩは第３の値の範囲とは異なる第４の値の範囲である任意の種類のＲＮＴＩでスクランブルされたＣＲＣを付加されたＤＣＩであってもよい。例えば、第３のＤＣＩはＣ−ＲＮＴＩ、ＭＣＳ−Ｃ−ＲＮＴＩ，ＣＳ−ＲＮＴＩ、ＳＩ−ＲＮＴＩ、ＲＡ−ＲＮＴＩ、ＴＣ−ＲＮＴＩおよび／またはＰ−ＲＮＴＩでスクランブルされたＣＲＣを付加されたＤＣＩであり、第４のＤＣＩはＵＣ−ＲＮＴＩでスクランブルされたＣＲＣを付加されたＤＣＩであってもよい。ただし、ＵＣ−ＲＮＴＩはＣ−ＲＮＴＩ、ＭＣＳ−Ｃ−ＲＮＴＩ，ＣＳ−ＲＮＴＩ、ＳＩ−ＲＮＴＩ、ＲＡ−ＲＮＴＩ、ＴＣ−ＲＮＴＩおよびＰ−ＲＮＴＩで利用可能な値とは異なる値を用いるＲＮＴＩであってよい。ただし、ＵＣ−ＲＮＴＩは１つまたは複数のスロットにおける所定のサービスのデータのＰＤＳＣＨまたはＰＵＳＣＨを制御するために用いられるＲＮＴＩであってよい。
第３のＤＣＩと第４のＤＣＩは、異なるＤＣＩフォーマットを用いたＤＣＩであってもよい。例えば、第１のＤＣＩはＤＣＩフォーマット０＿１を用いたＤＣＩであり、第２のＤＣＩはＤＣＩフォーマット０＿２を用いたＤＣＩであってもよい。
第３のＤＣＩと第４のＤＣＩは、異なるサイズのＤＣＩフォーマットを用いたＤＣＩであってもよい。例えば、第３のＤＣＩは第３のサイズのＤＣＩフォーマットを用いたＤＣＩであり、第４のＤＣＩは第３のサイズとは異なる第４のサイズのＤＣＩフォーマットを用いたＤＣＩであってもよい。
第３のＤＣＩと第４のＤＣＩは、それぞれのＤＣＩフォーマット内の所定のフィールドで、対応するＰＵＳＣＨのデータに適用されるサービスが示されてもよい。例えば、第３のＤＣＩのＤＣＩフォーマット内のフィールドで、対応するＰＵＳＣＨがｅＭＢＢのデータを伝送することが特定されてもよい。例えば、第４のＤＣＩのＤＣＩフォーマット内のフィールドで、対応するＰＵＳＣＨがＵＲＬＬＣのデータを伝送することが特定されてもよい。
第３のＤＣＩと第４のＤＣＩは、異なるサーチスペースおよび／または異なるＣＯＲＥＳＥＴで伝送されるＤＣＩであってもよい。
第３のＤＣＩと第４のＤＣＩは、異なるコードブックのＰＵＳＣＨをスケジュールするＤＣＩであってもよい。
上位層のＲＲＣ信号で設定されるリソース割り当てテーブルは、上位層の信号ｐｕｓｃｈ−ＴｉｍｅＤｏｍａｉｎＡｌｌｏｃａｔｉｏｎＬｉｓｔとは異なる上位層の信号（インフォメーションエレメントあるいはＲＲＣパラメータであってよい）で与えられてもよい。例えば、上位層の信号ｐｕｓｃｈ−ＴｉｍｅＤｏｍａｉｎＡｌｌｏｃａｔｉｏｎＬｉｓｔ２によって与えられてもよい。基地局装置３は、上位層の信号でｐｕｓｃｈ−ＴｉｍｅＤｏｍａｉｎＡｌｌｏｃａｔｉｏｎＬｉｓｔおよび／またはｐｕｓｃｈ−ＴｉｍｅＤｏｍａｉｎＡｌｌｏｃａｔｉｏｎＬｉｓｔ２を通知してもよい。端末装置１は、上位層の信号でｐｕｓｃｈ−ＴｉｍｅＤｏｍａｉｎＡｌｌｏｃａｔｉｏｎＬｉｓｔおよび／またはｐｕｓｃｈ−ＴｉｍｅＤｏｍａｉｎＡｌｌｏｃａｔｉｏｎＬｉｓｔ２を受信してもよい。
ｐｕｓｃｈ−ＴｉｍｅＤｏｍａｉｎＡｌｌｏｃａｔｉｏｎＬｉｓｔ２はｐｕｓｃｈ−ＴｉｍｅＤｏｍａｉｎＡｌｌｏｃａｔｉｏｎＬｉｓｔと同様に、最大１６個のエントリを含み、ＤＣＩに含まれる４ビットのフィールドによっていずれか１つのエントリが用いられてよい。ｐｕｓｃｈ−ＴｉｍｅＤｏｍａｉｎＡｌｌｏｃａｔｉｏｎＬｉｓｔ２に含まれる各エントリにおいて、Ｋ２、ｍａｐｐｉｎｇＴｙｐｅ、および／または、ｓｔａｒｔＳｙｍｂｏｌＡｎｄＬｅｎｇｔｈが示されてよい。ｐｕｓｃｈ−ＴｉｍｅＤｏｍａｉｎＡｌｌｏｃａｔｉｏｎＬｉｓｔ２の各エントリにおけるＫ２、ｍａｐｐｉｎｇＴｙｐｅ、および／または、ｓｔａｒｔＳｙｍｂｏｌＡｎｄＬｅｎｇｔｈにおいて利用可能な値は、ｐｕｓｃｈ−ＴｉｍｅＤｏｍａｉｎＡｌｌｏｃａｔｉｏｎＬｉｓｔにおいて利用可能な値と異なってもよい。例えば、ｐｕｓｃｈ−ＴｉｍｅＤｏｍａｉｎＡｌｌｏｃａｔｉｏｎＬｉｓｔにおいて利用可能なＫ２の値は０〜３２であり、ｐｕｓｃｈ−ＴｉｍｅＤｏｍａｉｎＡｌｌｏｃａｔｉｏｎＬｉｓｔ２において利用可能なＫ２の値は０〜４であってもよい。例えば、ｐｕｓｃｈ−ＴｉｍｅＤｏｍａｉｎＡｌｌｏｃａｔｉｏｎＬｉｓｔにおいて利用可能なｍａｐｐｉｎｎｇＴｙｐｅはマッピングタイプＡとマッピングタイプＢであり、ｐｕｓｃｈ−ＴｉｍｅＤｏｍａｉｎＡｌｌｏｃａｔｉｏｎＬｉｓｔ２において利用可能なｍａｐｐｉｎｎｇＴｙｐｅはマッピングタイプＢのみであってもよい。例えば、ｐｕｓｃｈ−ＴｉｍｅＤｏｍａｉｎＡｌｌｏｃａｔｉｏｎＬｉｓｔ２ではｍａｐｐｉｎｎｇＴｙｐｅが示されなくてもよい。
端末装置１は、上位層の信号ｐｕｓｃｈ−Ｃｏｎｆｉｇにｐｕｓｃｈ−ＴｉｍｅＤｏｍａｉｎＡｌｌｏｃａｔｉｏｎＬｉｓｔが含まれており、かつ第３のＤＣＩでＰＵＳＣＨがスケジュールされている場合に、ＰＵＳＣＨのリソース割り当てテーブルにｐｕｓｃｈ−Ｃｏｎｆｉｇに含まれるｐｕｓｃｈ−ＴｉｍｅＤｏｍａｉｎＡｌｌｏｃａｔｉｏｎＬｉｓｔを適用してもよい。端末装置１は、上位層の信号ｐｕｓｃｈ−Ｃｏｎｆｉｇにｐｕｓｃｈ−ＴｉｍｅＤｏｍａｉｎＡｌｌｏｃａｔｉｏｎＬｉｓｔ２が含まれており、かつ第４のＤＣＩでＰＵＳＣＨがスケジュールされている場合に、ＰＵＳＣＨのリソース割り当てテーブルにｐｕｓｃｈ−Ｃｏｎｆｉｇに含まれるｐｕｓｃｈ−ＴｉｍｅＤｏｍａｉｎＡｌｌｏｃａｔｉｏｎＬｉｓｔ２を適用してもよい。
端末装置１は、上位層の信号ｐｕｓｃｈ−Ｃｏｎｆｉｇおよびｐｕｓｃｈ−ＣｏｎｆｉｇＣｏｍｍｏｎにｐｕｓｃｈ−ＴｉｍｅＤｏｍａｉｎＡｌｌｏｃａｔｉｏｎＬｉｓｔが含まれておらず、かつ第３のＤＣＩでＰＵＳＣＨがスケジュールされている場合に、ＰＵＳＣＨのリソース割り当てテーブルにＰＵＳＣＨデフォルトテーブルＡを適用してもよい。端末装置１は、上位層の信号ｐｕｓｃｈ−Ｃｏｎｆｉｇおよびｐｕｓｃｈ−ＣｏｎｆｉｇＣｏｍｍｏｎにｐｕｓｃｈ−ＴｉｍｅＤｏｍａｉｎＡｌｌｏｃａｔｉｏｎＬｉｓｔ２が含まれておらず、かつ第４のＤＣＩでＰＵＳＣＨがスケジュールされている場合に、ＰＵＳＣＨのリソース割り当てテーブルにＰＵＳＣＨデフォルトテーブルＢを適用してもよい。端末装置１は、上位層の信号でｐｕｓｃｈ−ＴｉｍｅＤｏｍａｉｎＡｌｌｏｃａｔｉｏｎＬｉｓｔおよび／またはｐｕｓｃｈ−ＴｉｍｅＤｏｍａｉｎＡｌｌｏｃａｔｉｏｎＬｉｓｔ２が設定されていない場合に、第３のＤＣＩと第４のＤＣＩで異なるデフォルトテーブルを用いてもよい。端末装置１は、上位層の信号でｐｕｓｃｈ−ＴｉｍｅＤｏｍａｉｎＡｌｌｏｃａｔｉｏｎＬｉｓｔおよび／またはｐｕｓｃｈ−ＴｉｍｅＤｏｍａｉｎＡｌｌｏｃａｔｉｏｎＬｉｓｔ２が設定されていない場合に、第３のＤＣＩと第４のＤＣＩで同一のデフォルトテーブルを用いてもよい。
端末装置１は、ＰＵＳＣＨをスケジュールするＤＣＩを検出する。そのＰＵＳＣＨが送信されるスロットは、（式５）ｆｌｏｏｒ（ｎ＊２μＰＵＳＣＨ／２μＰＤＣＣＨ）＋Ｋ２によって与えられる。ｎは、ＰＵＳＣＨをスケジュールするＰＤＣＣＨが検出されるスロットである。μＰＵＳＣＨはＰＵＳＣＨに対するサブキャリア間隔設定である。μＰＤＣＣＨはＰＤＣＣＨに対するサブキャリア間隔設定である。
図１８において、Ｋ２の値はｊ、ｊ＋１、ｊ＋２、または、ｊ＋３の内、何れかである。ｊの値は、ＰＵＳＣＨのサブキャリア間隔に対して特定される値である。例えば、ＰＵＳＣＨが適用されるサブキャリア間隔が１５ｋＨｚまたは３０ｋＨｚである場合、ｊの値は１スロットであってもよい。例えば、ＰＵＳＣＨが適用されるサブキャリア間隔が６０ｋＨｚである場合、ｊの値は２スロットであってもよい。例えば、ＰＵＳＣＨが適用されるサブキャリア間隔が１２０ｋＨｚである場合、ｊの値は３スロットであってもよい。
Ｋ２の値はＰＵＳＣＨデフォルトテーブルＡとＰＵＳＣＨデフォルトテーブルＢで異なる値が用いられてもよい。例えば、ＰＵＳＣＨデフォルトテーブルＢではｊとは異なる値ｉが用いられてもよい。ｉの値もｊの値と同様にＰＵＳＣＨが適用されるサブキャリア間隔に対応してスロット数を定める値であってよい。
前述のように、端末装置１は、図１７に示されるようなテーブルに基づいて、どのリソース割り当てテーブルをＰＵＳＣＨ時間領域リソース割り当てに適用するかを決定してもよい。
例Ｄとして、端末装置１は、ＲＡＲ ＵＬグラントによってスケジュールされるＰＵＳＣＨに適用するリソース割り当てテーブルを決定してもよい。端末装置１に対してｐｕｓｃｈ−ＣｏｎｆｉｇＣｏｍｍｏｎがｐｕｓｃｈ−ＴｉｍｅＤｏｍａｉｎＡｌｌｏｃａｔｉｏｎＬｉｓｔを含む場合、端末装置１は、上位層のＲＲＣ信号から設定されるリソース割り当てテーブルを決定してもよい。そのリソース割り当てテーブルは、ｐｕｓｃｈ−ＣｏｎｆｉｇＣｏｍｍｏｎに含まれるｐｕｓｃｈ−ＴｉｍｅＤｏｍａｉｎＡｌｌｏｃａｔｉｏｎＬｉｓｔによって与えられる。また、端末装置１に対してｐｕｓｃｈ−ＣｏｎｆｉｇＣｏｍｍｏｎがｐｕｓｃｈ−ＴｉｍｅＤｏｍａｉｎＡｌｌｏｃａｔｉｏｎＬｉｓｔを含まない場合、端末装置１は、ＰＵＳＣＨデフォルトテーブルＡを決定してもよい。つまり、端末装置１は、ＰUＳＣＨ時間領域リソース割り当てのコンフィギュレーションを示すデフ
ォルトテーブルＡを用いて、ＰUＳＣＨ時間領域リソース割り当ての決定に適用してもよ
い。
例Eとして、端末装置１は、ＣＯＲＥＳＥＴ＃０に関連付けられる任意のコモンサーチ
スペースにおいてＤＣＩを検出してもよい。検出したＤＣＩは、Ｃ−ＲＮＴＩ、ＭＣＳ−Ｃ−ＲＮＴＩ、ＴＣ−ＲＮＴＩ、または、ＣＳ−ＲＮＴＩの内、何れかによってスクランブルされるＣＲＣが付加される。そして、端末装置１は、そのＤＣＩによってスケジュールされるＰＵＳＣＨに適用するリソース割り当てテーブルを決定してもよい。端末装置１に対してｐｕｓｃｈ−ＣｏｎｆｉｇＣｏｍｍｏｎがｐｕｓｃｈ−ＴｉｍｅＤｏｍａｉｎＡｌｌｏｃａｔｉｏｎＬｉｓｔを含む場合、端末装置１は、ＰＵＳＣＨ時間領域リソース割り当てに適用するリソース割り当てテーブルを、ｐｕｓｃｈ−ＣｏｎｆｉｇＣｏｍｍｏｎで提供されるｐｕｓｃｈ−ＴｉｍｅＤｏｍａｉｎＡｌｌｏｃａｔｉｏｎＬｉｓｔから与えられるリソース割り当てテーブルに決定してもよい。また、ｐｕｓｃｈ−ＣｏｎｆｉｇＣｏｍｍｏｎがｐｕｓｃｈ−ＴｉｍｅＤｏｍａｉｎＡｌｌｏｃａｔｉｏｎＬｉｓｔを含まない場合、端末装置１は、ＰＵＳＣＨ時間領域リソース割り当てに適用するリソース割り当てテーブルをＰＵＳＣＨデフォルトテーブルＡに決定してもよい。
例Ｆとして、端末装置１は、（Ｉ）ＣＯＲＥＳＥＴ＃０に関連付けられる任意のコモンサーチスペースまたは（ＩＩ）ＵＥ固有サーチスペースにおいてＤＣＩを検出してもよい。検出したＤＣＩは、Ｃ−ＲＮＴＩ、ＭＣＳ−Ｃ−ＲＮＴＩ、ＴＣ−ＲＮＴＩ、または、ＣＳ−ＲＮＴＩの内、何れかによってスクランブルされるＣＲＣが付加される。そして、端末装置１は、そのＤＣＩによってスケジュールされるＰＵＳＣＨに適用するリソース割り当てテーブルを決定してもよい。端末装置１に対してｐｕｓｃｈ−Ｃｏｎｆｉｇがｐｕｓｃｈ−ＴｉｍｅＤｏｍａｉｎＡｌｌｏｃａｔｉｏｎＬｉｓｔを含む場合、端末装置１は、ＰＵＳＣＨ時間領域リソース割り当てに適用するリソース割り当てテーブルを、ｐｕｓｃｈ−Ｃｏｎｆｉｇで提供されるｐｕｓｃｈ−ＴｉｍｅＤｏｍａｉｎＡｌｌｏｃａｔｉｏｎＬｉｓｔから与えられるリソース割り当てテーブルに決定してもよい。つまり、ｐｕｓｃｈ−Ｃｏｎｆｉｇがｐｕｓｃｈ−ＴｉｍｅＤｏｍａｉｎＡｌｌｏｃａｔｉｏｎＬｉｓｔを含む場合、端末装置１は、ｐｕｓｃｈ−ＣｏｎｆｉｇＣｏｍｍｏｎがｐｕｓｃｈ−ＴｉｍｅＤｏｍａｉｎＡｌｌｏｃａｔｉｏｎＬｉｓｔを含むか含まないかと関わらず、ｐｕｓｃｈ−Ｃｏｎｆｉｇで提供されるｐｕｓｃｈ−ＴｉｍｅＤｏｍａｉｎＡｌｌｏｃａｔｉｏｎＬｉｓｔを用いて、ＰＵＳＣＨ時間領域リソース割り当ての決定に適用してもよい。また、ｐｕｓｃｈ−Ｃｏｎｆｉｇがｐｕｓｃｈ−ＴｉｍｅＤｏｍａｉｎＡｌｌｏｃａｔｉｏｎＬｉｓｔを含んでおらず、且つ、ｐｕｓｃｈ−ＣｏｎｆｉｇＣｏｍｍｏｎがｐｕｓｃｈ−ＴｉｍｅＤｏｍａｉｎＡｌｌｏｃａｔｉｏｎＬｉｓｔを含む場合、端末装置１は、ＰＵＳＣＨ時間領域リソース割り当てに適用するリソース割り当てテーブルを、ｐｕｓｃｈ−ＣｏｎｆｉｇＣｏｍｍｏｎで提供されるｐｕｓｃｈ−ＴｉｍｅＤｏｍａｉｎＡｌｌｏｃａｔｉｏｎＬｉｓｔから与えられるリソース割り当てテーブルに決定してもよい。つまり、端末装置１は、ｐｕｓｃｈ−ＣｏｎｆｉｇＣｏｍｍｏｎで提供されるｐｕｓｃｈ−ＴｉｍｅＤｏｍａｉｎＡｌｌｏｃａｔｉｏｎＬｉｓｔを用いて、ＰＵＳＣＨ時間領域リソース割り当ての決定に適用する。また、ｐｕｓｃｈ−Ｃｏｎｆｉｇがｐｕｓｃｈ−ＴｉｍｅＤｏｍａｉｎＡｌｌｏｃａｔｉｏｎＬｉｓｔを含んでおらず、且つ、ｐｕｓｃｈ−ＣｏｎｆｉｇＣｏｍｍｏｎがｐｕｓｃｈ−ＴｉｍｅＤｏｍａｉｎＡｌｌｏｃａｔｉｏｎＬｉｓｔを含まない場合、端末装置１は、ＰＵＳＣＨ時間領域リソース割り当てに適用するリソース割り当てテーブルをＰＵＳＣＨデフォルトテーブルＡに決定してもよい。
端末装置１は、図１７の最後の行（ＣＯＲＥＳＥＴ＃０に関連付けられない任意のコモンサーチスペースまたはＵＥ固有サーチスペースにおいてＤＣＩを検出し、かつＲＮＴＩが所定のタイプのＲＮＴＩである場合）において図１９のようにリソース割り当てテーブルを決定してもよい。端末装置１は、下記の要素（Ｊ）から要素（Ｌ）の少なくとも一部に基づいて、ＤＣＩによってスケジュールされるＰＵＳＣＨに適用するリソース割り当てテーブルを決定してもよい。
要素（Ｊ）：ＤＣＩが上記の第３のＤＣＩ（3rd DCI）であるか第４のＤＣＩ（4th DCI）であるか
要素（Ｋ）：ｐｕｓｃｈ−ＣｏｎｆｉｇＣｏｍｍｏｎがｐｕｓｃｈ−ＴｉｍｅＤｏｍａｉｎＡｌｌｏｃａｔｉｏｎＬｉｓｔ２を含むかどうか
要素（Ｌ）：ｐｕｓｃｈ−Ｃｏｎｆｉｇがｐｕｓｃｈ−ＴｉｍｅＤｏｍａｉｎＡｌｌｏｃａｔｉｏｎＬｉｓｔ２を含むかどうか
ただし、第３のＤＣＩの場合と第４のＤＣＩの場合とで同一のデフォルトテーブル（例えばデフォルトテーブルＡ）が用いられてもよい。ただし、ｐｕｓｃｈ−ＴｉｍｅＤｏｍａｉｎＡｌｌｏｃａｔｉｏｎＬｉｓｔ２は、ｐｕｓｃｈ−ＣｏｎｆｉｇＣｏｍｍｏｎには含まれないパラメータでありｐｕｓｃｈ−Ｃｏｎｆｉｇにのみ含まれるパラメータであってもよい。
図１９に示すテーブルでは、端末装置１および／または基地局装置３は、ＰＵＳＣＨに適用するリソース割り当てテーブルをデフォルトテーブルＡ、デフォルトテーブルＢ、ｐｕｓｃｈ−ＣｏｎｆｉｇＣｏｍｍｏｎに含まれるｐｕｓｃｈ−ＴｉｍｅＤｏｍａｉｎＡｌｌｏｃａｔｉｏｎＬｉｓｔ、ｐｕｓｃｈ−Ｃｏｎｆｉｇに含まれるｐｕｓｃｈ−ＴｉｍｅＤｏｍａｉｎＡｌｌｏｃａｔｉｏｎＬｉｓｔ、ｐｕｓｃｈ−ＣｏｎｆｉｇＣｏｍｍｏｎに含まれるｐｕｓｃｈ−ＴｉｍｅＤｏｍａｉｎＡｌｌｏｃａｔｉｏｎＬｉｓｔ２およびｐｕｓｃｈ−Ｃｏｎｆｉｇに含まれるｐｕｓｃｈ−ＴｉｍｅＤｏｍａｉｎＡｌｌｏｃａｔｉｏｎＬｉｓｔ２の中から決定する。
図２０は、本実施形態に係るＰＵＳＣＨに適用するリソース割り当てテーブルの決定法を示すテーブルの別の一例である。図２０に示すテーブルでは、端末装置１および／または基地局装置３は、ＰＵＳＣＨに適用するリソース割り当てテーブルをＰＵＳＣＨデフォルトテーブルＡ、ｐｕｓｃｈ−ＣｏｎｆｉｇＣｏｍｍｏｎに含まれるｐｕｓｃｈ−ＴｉｍｅＤｏｍａｉｎＡｌｌｏｃａｔｉｏｎＬｉｓｔ、ｐｕｓｃｈ−Ｃｏｎｆｉｇに含まれるｐｕｓｃｈ−ＴｉｍｅＤｏｍａｉｎＡｌｌｏｃａｔｉｏｎＬｉｓｔおよびｐｕｓｃｈ−Ｃｏｎｆｉｇに含まれるｐｕｓｃｈ−ＴｉｍｅＤｏｍａｉｎＡｌｌｏｃａｔｉｏｎＬｉｓｔ２の中から決定する。図２０に示すテーブルの例では、ＤＣＩが第４のＤＣＩであり、ｐｕｓｃｈ−Ｃｏｎｆｉｇにｐｕｓｃｈ−ＴｉｍｅＤｏｍａｉｎＡｌｌｏｃａｔｉｏｎＬｉｓｔ２が含まれず、ｐｕｓｃｈ−ＣｏｎｆｉｇＣｏｍｍｏｎにｐｕｓｃｈ−ＴｉｍｅＤｏｍａｉｎＡｌｌｏｃａｔｉｏｎＬｉｓｔが含まれる場合には、ＰＵＳＣＨに適用するリソース割り当てテーブルはｐｕｓｃｈ−ＣｏｎｆｉｇＣｏｍｍｏｎに含まれるｐｕｓｃｈ−ＴｉｍｅＤｏｍａｉｎＡｌｌｏｃａｔｉｏｎＬｉｓｔである。ただし、ＤＣＩが第４のＤＣＩであり、ｐｕｓｃｈ−Ｃｏｎｆｉｇにｐｕｓｃｈ−ＴｉｍｅＤｏｍａｉｎＡｌｌｏｃａｔｉｏｎＬｉｓｔ２が含まれない場合には、ＰＵＳＣＨに適用するリソース割り当てテー
ブルはＰＵＳＣＨデフォルトテーブルＡまたはＰＵＳＣＨデフォルトテーブルＢであってもよい。
端末装置１は、ＰＵＳＣＨをスケジュールするＤＣＩに含まれる‘Ｔｉｍｅ ｄｏｍａｉｎ ｒｅｓｏｕｒｃｅ ａｓｓｉｇｎｍｅｎｔ’フィールドに示される値に基づき、決定したリソース割り当てテーブル内の１つのＰＵＳＣＨ時間領域リソース割り当て設定を選んでもよい。例えば、ＰＵＳＣＨ時間領域リソース割り当てに適用するリソース割り当てテーブルがＰＵＳＣＨデフォルトテーブルＡ（またはＰＵＳＣＨデフォルトテーブルＢ）である場合、‘Ｔｉｍｅ ｄｏｍａｉｎ ｒｅｓｏｕｒｃｅ ａｓｓｉｇｎｍｅｎｔ’フィールドに示される値ｍは、ＰＵＳＣＨデフォルトテーブルＡ（またはＰＵＳＣＨデフォルトテーブルＢ）の行インデックス（ｒｏｗ ｉｎｄｅｘ）ｍ＋１を示してもよい。この時、ＰＵＳＣＨ時間領域リソース割り当ては、行インデックスｍ＋１から示される時間領域リソース割り当ての設定である。端末装置１は、行インデックスｍ＋１から示される時間領域リソース割り当ての設定を想定し、ＰＵＳＣＨを送信する。例えば、‘Ｔｉｍｅ ｄｏｍａｉｎ ｒｅｓｏｕｒｃｅ ａｓｓｉｇｎｍｅｎｔ’フィールドに示される値ｍが０である場合、端末装置１は、ＰＵＳＣＨデフォルトテーブルＡ（またはＰＵＳＣＨデフォルトテーブルＢ）の行インデックス１のＰＵＳＣＨ時間領域リソース割り当ての設定を用いて、そのＤＣＩによってスケジュールされるＰＵＳＣＨの時間方向のリソース割り当てを特定する。
また、ＰＵＳＣＨ時間領域リソース割り当てに適用するリソース割り当てテーブルがｐｕｓｃｈ−ＴｉｍｅＤｏｍａｉｎＡｌｌｏｃａｔｉｏｎＬｉｓｔから与えられるリソース割り当てテーブルである場合、‘Ｔｉｍｅ ｄｏｍａｉｎ ｒｅｓｏｕｒｃｅ ａｓｓｉｇｎｍｅｎｔ’フィールドに示される値ｍは、リストｐｕｓｃｈ−ＴｉｍｅＤｏｍａｉｎＡｌｌｏｃａｔｉｏｎＬｉｓｔにおける（ｍ＋１）番目のエレメント（エントリ、行）に対応する。例えば、‘Ｔｉｍｅ ｄｏｍａｉｎ ｒｅｓｏｕｒｃｅ ａｓｓｉｇｎｍｅｎｔ’フィールドに示される値ｍが０である場合、端末装置１は、リストｐｕｓｃｈ−ＴｉｍｅＤｏｍａｉｎＡｌｌｏｃａｔｉｏｎＬｉｓｔにおける１番目のエレメント（エントリ）を参照してもよい。例えば、‘Ｔｉｍｅ ｄｏｍａｉｎ ｒｅｓｏｕｒｃｅ ａｓｓｉｇｎｍｅｎｔ’フィールドに示される値ｍが１である場合、端末装置１は、リストｐｕｓｃｈ−ＴｉｍｅＤｏｍａｉｎＡｌｌｏｃａｔｉｏｎＬｉｓｔにおける２番目のエレメント（エントリ）を参照してもよい。
また、ＰＤＳＣＨ時間領域リソース割り当てに適用するリソース割り当てテーブルがｐｕｓｃｈ−ＴｉｍｅＤｏｍａｉｎＡｌｌｏｃａｔｉｏｎＬｉｓｔ２から与えられるリソース割り当てテーブルである場合、‘Ｔｉｍｅ ｄｏｍａｉｎ ｒｅｓｏｕｒｃｅ ａｓｓｉｇｎｍｅｎｔ’フィールドに示される値ｍは、リストｐｕｓｃｈ−ＴｉｍｅＤｏｍａｉｎＡｌｌｏｃａｔｉｏｎＬｉｓｔ２における（ｍ＋１）番目のエレメント（エントリ、行）に対応する。例えば、‘Ｔｉｍｅ ｄｏｍａｉｎ ｒｅｓｏｕｒｃｅ ａｓｓｉｇｎｍｅｎｔ’フィールドに示される値ｍが０である場合、端末装置１は、リストｐｕｓｃｈ−ＴｉｍｅＤｏｍａｉｎＡｌｌｏｃａｔｉｏｎＬｉｓｔ２における１番目のエレメント（エントリ）を参照してもよい。例えば、‘Ｔｉｍｅ ｄｏｍａｉｎ ｒｅｓｏｕｒｃｅ ａｓｓｉｇｎｍｅｎｔ’フィールドに示される値ｍが１である場合、端末装置１は、リストｐｕｓｃｈ−ＴｉｍｅＤｏｍａｉｎＡｌｌｏｃａｔｉｏｎＬｉｓｔ２における２番目のエレメント（エントリ）を参照してもよい。
以下、ＤＣＩに含まれる‘Ｔｉｍｅ ｄｏｍａｉｎ ｒｅｓｏｕｒｃｅ ａｓｓｉｇｎｍｅｎｔ’フィールドのビット数（サイズ）について説明する。
端末装置１は、ＤＣＩフォーマット０＿０、ＤＣＩフォーマット０＿１またはＤＣＩフ
ォーマット０＿２を含むＰＤＣＣＨの検出によって、対応するＰＵＳＣＨを送信してもよい。ＤＣＩフォーマット０＿０に含まれる‘Ｔｉｍｅ ｄｏｍａｉｎ ｒｅｓｏｕｒｃｅ
ａｓｓｉｇｎｍｅｎｔ’フィールドのビット数は固定のビット数であってもよい。例えば、この固定のビット数は４であってもよい。つまり、ＤＣＩフォーマット０＿０に含まれる‘Ｔｉｍｅ ｄｏｍａｉｎ ｒｅｓｏｕｒｃｅ ａｓｓｉｇｎｍｅｎｔ’フィールドのサイズは４ビットである。また、ＤＣＩフォーマット０＿１またはＤＣＩフォーマット０＿２に含まれる‘Ｔｉｍｅ ｄｏｍａｉｎ ｒｅｓｏｕｒｃｅ ａｓｓｉｇｎｍｅｎｔ’フィールドのサイズは可変のビット数であってもよい。例えば、ＤＣＩフォーマット０＿１またはＤＣＩフォーマット０＿２に含まれる‘Ｔｉｍｅ ｄｏｍａｉｎ ｒｅｓｏｕｒｃｅ ａｓｓｉｇｎｍｅｎｔ’フィールドのビット数は０、１、２、３、４のうち何れかであってもよい。また、ＤＣＩフォーマット１＿２に含まれる‘Ｔｉｍｅ ｄｏｍａｉｎ ｒｅｓｏｕｒｃｅ ａｓｓｉｇｎｍｅｎｔ’フィールドのビット数は４より大きい値であってもよい。
以下、ＤＣＩフォーマット０＿１またはＤＣＩフォーマット０＿２に含まれる‘Ｔｉｍｅ ｄｏｍａｉｎ ｒｅｓｏｕｒｃｅ ａｓｓｉｇｎｍｅｎｔ’フィールドのビット数の決定について説明する。
‘Ｔｉｍｅ ｄｏｍａｉｎ ｒｅｓｏｕｒｃｅ ａｓｓｉｇｎｍｅｎｔ’フィールドのビット数は、ｃｅｉｌｉｎｇ（ｌｏｇ２（Ｉ））として与えられてもよい。端末装置１に対してｐｕｓｃｈ−ＴｉｍｅＤｏｍａｉｎＡｌｌｏｃａｔｉｏｎＬｉｓｔ（またはｐｕｓｃｈ−ＴｉｍｅＤｏｍａｉｎＡｌｌｏｃａｔｉｏｎＬｉｓｔ２）が設定（提供）される場合、Ｉの値はｐｕｓｃｈ−ＴｉｍｅＤｏｍａｉｎＡｌｌｏｃａｔｉｏｎＬｉｓｔ（またはｐｕｓｃｈ−ＴｉｍｅＤｏｍａｉｎＡｌｌｏｃａｔｉｏｎＬｉｓｔ２）に含まれるエントリの数であってもよい。端末装置１に対してｐｕｓｃｈ−ＴｉｍｅＤｏｍａｉｎＡｌｌｏｃａｔｉｏｎＬｉｓｔ（またはｐｕｓｃｈ−ＴｉｍｅＤｏｍａｉｎＡｌｌｏｃａｔｉｏｎＬｉｓｔ２）が設定（提供）されない場合、Ｉの値はＰＵＳＣＨデフォルトテーブルＡ（またはＰＵＳＣＨデフォルトテーブルＢ）の行の数であってもよい。つまり、端末装置１に対してｐｕｓｃｈ−ＴｉｍｅＤｏｍａｉｎＡｌｌｏｃａｔｉｏｎＬｉｓｔ（またはｐｕｓｃｈ−ＴｉｍｅＤｏｍａｉｎＡｌｌｏｃａｔｉｏｎＬｉｓｔ２）が設定される場合、‘Ｔｉｍｅ ｄｏｍａｉｎ ｒｅｓｏｕｒｃｅ ａｓｓｉｇｎｍｅｎｔ’フィールドのビット数は、ｐｕｓｃｈ−ＴｉｍｅＤｏｍａｉｎＡｌｌｏｃａｔｉｏｎＬｉｓｔ（またはｐｕｓｃｈ−ＴｉｍｅＤｏｍａｉｎＡｌｌｏｃａｔｉｏｎＬｉｓｔ２）に含まれるエントリの数に基づいて与えられてもよい。端末装置１に対してｐｕｓｃｈ−ＴｉｍｅＤｏｍａｉｎＡｌｌｏｃａｔｉｏｎＬｉｓｔ（またはｐｕｓｃｈ−ＴｉｍｅＤｏｍａｉｎＡｌｌｏｃａｔｉｏｎＬｉｓｔ２）が設定されない場合、‘Ｔｉｍｅ ｄｏｍａｉｎ ｒｅｓｏｕｒｃｅ ａｓｓｉｇｎｍｅｎｔ’フィールドのビット数は、デフォルトテーブル（ＰＵＳＣＨデフォルトテーブルＡまたはＰＵＳＣＨデフォルトテーブルＢ）の行の数に基づいて与えられてもよい。具体的に言うと、ｐｕｓｃｈ−Ｃｏｎｆｉｇがｐｕｓｃｈ−ＴｉｍｅＤｏｍａｉｎＡｌｌｏｃａｔｉｏｎＬｉｓｔ（またはｐｕｓｃｈ−ＴｉｍｅＤｏｍａｉｎＡｌｌｏｃａｔｉｏｎＬｉｓｔ２）を含む場合、Ｉの値はｐｕｓｃｈ−Ｃｏｎｆｉｇで提供されるｐｕｓｃｈ−ＴｉｍｅＤｏｍａｉｎＡｌｌｏｃａｔｉｏｎＬｉｓｔ（またはｐｕｓｃｈ−ＴｉｍｅＤｏｍａｉｎＡｌｌｏｃａｔｉｏｎＬｉｓｔ２）に含まれるエントリの数であってもよい。また、ｐｕｓｃｈ−Ｃｏｎｆｉｇがｐｕｓｃｈ−ＴｉｍｅＤｏｍａｉｎＡｌｌｏｃａｔｉｏｎＬｉｓｔ（またはｐｕｓｃｈ−ＴｉｍｅＤｏｍａｉｎＡｌｌｏｃａｔｉｏｎＬｉｓｔ２）を含んでおらず、且つ、ｐｕｓｃｈ−ＣｏｎｆｉｇＣｏｍｍｏｎがｐｕｓｃｈ−ＴｉｍｅＤｏｍａｉｎＡｌｌｏｃａｔｉｏｎＬｉｓｔ（またはｐｕｓｃｈ−ＴｉｍｅＤｏｍａｉｎＡｌｌｏｃａｔｉｏｎＬｉｓｔ２）を含む場合、Ｉの値はｐｕｓｃｈ−ＣｏｎｆｉｇＣｏｍｍｏｎで提供されるｐｕｓｃｈ−ＴｉｍｅＤｏｍａｉｎＡｌｌｏｃａｔｉｏｎＬｉｓｔ（またはｐｕｓｃｈ−ＴｉｍｅＤｏｍａｉｎＡｌｌｏｃａｔｉｏｎＬｉｓｔ２）に含まれるエントリの数であってもよい。また、ｐｕｓｃｈ−Ｃｏｎｆｉｇがｐｕｓｃｈ−ＴｉｍｅＤｏｍａｉｎＡｌｌｏｃａｔｉｏｎＬｉｓｔ（またはｐｕｓｃｈ−ＴｉｍｅＤｏｍａｉｎＡｌｌｏｃａｔｉｏｎＬｉｓｔ２）を含んでおらず、且つ、ｐｕｓｃｈ−ＣｏｎｆｉｇＣｏｍｍｏｎがｐｕｓｃｈ−ＴｉｍｅＤｏｍａｉｎＡｌｌｏｃａｔｉｏｎＬｉｓｔ（またはｐｕｓｃｈ−ＴｉｍｅＤｏｍａｉｎＡｌｌｏｃａｔｉｏｎＬｉｓｔ２）を含まない場合、Ｉの値はＰＵＳＣＨデフォルトテーブルＡ（またはＰＵＳＣＨデフォルトテーブルＢ）に含まれる行の数であってもよい。
また、ｐｕｓｃｈ−ＴｉｍｅＤｏｍａｉｎＡｌｌｏｃａｔｉｏｎＬｉｓｔに含まれるエントリの数は、ｐｕｓｃｈ−ＴｉｍｅＤｏｍａｉｎＡｌｌｏｃａｔｉｏｎＬｉｓｔ２に含まれるエントリの数と異なってもよい。ｐｕｓｃｈ−ＴｉｍｅＤｏｍａｉｎＡｌｌｏｃａｔｉｏｎＬｉｓｔに含まれるエントリの最大数は、第１の値であってもよい。例えば、第１の値は１６である。ｐｕｓｃｈ−ＴｉｍｅＤｏｍａｉｎＡｌｌｏｃａｔｉｏｎＬｉｓｔ２に含まれるエントリの最大数は、第２の値であってもよい。例えば、第１の値は１６より大きい値である。
図９はＤＣＩを伴うＰＤＣＣＨによってスケジュールされるＰＵＳＣＨを送信する一例を示す図である。図９（Ａ）は、第３のＤＣＩを伴うＰＤＣＣＨによってスケジュールされるＰＵＳＣＨ（第１のＰＵＳＣＨ）を送信する一例を示す図である。図９（Ｂ）は、第３のＤＣＩと第４のＤＣＩを伴うＰＤＣＣＨによってスケジュールされるＰＵＳＣＨ（第１のＰＵＳＣＨと第２のＰＵＳＣＨ）を送信する一例を示す図である。
前述のように、端末装置１は、ＤＣＩを含むＰＤＣＣＨの検出によって、対応するＰＵＳＣＨを送信してもよい。つまり、対応するＰＵＳＣＨは、そのＤＣＩフォーマット（ＤＣＩ）によってスケジュールされてもよい（示される）。あるセル（ある所与のスケジューリングセル）内の任意２つのＨＡＲＱプロセス番号において、端末装置１がシンボルｉで終了するＰＤＣＣＨによってシンボルｊで開始する最初のＰＵＳＣＨ送信を開始するようにスケジュールされている場合、端末装置１は、シンボルｉより後に終了するＰＤＣＣＨによって最初のＰＵＳＣＨの終了より早く開始するあるＰＵＳＣＨを送信するようにスケジュールされるとは期待しない。即ち、あるセル内の任意２つのＨＡＲＱプロセス番号において、基地局装置３は、ある端末装置１にシンボルｉで終了するＰＤＣＣＨによってシンボルｊで開始する最初のＰＵＳＣＨ送信を開始するようにスケジュールしている場合に、シンボルｉより後に終了するＰＤＣＣＨによって最初のＰＵＳＣＨの終了より早く開始するあるＰＵＳＣＨを該端末装置１に送信するようにスケジュールしなくてもよい。所与のセル内の任意２つのＨＡＲＱプロセス番号において、端末装置１は、他のＰＵＳＣＨと時間的にオーバラップするＰＵＳＣＨを送信することを期待されなくてもよい。即ち、所与のセル内の任意２つのＨＡＲＱプロセス番号において、基地局装置３は、端末装置１に、端末装置１宛てのあるＰＵＳＣＨと時間的にオーバラップする他のＰＵＳＣＨを送信するようにスケジュールしなくてもよい。ここで、言及されたＰＤＣＣＨは、第３のＤＣＩを伴うＰＤＣＣＨに対応してもよい。言及されたＰＵＳＣＨは、第３のＤＣＩによってスケジュールされる第１のＰＵＳＣＨに対応してもよい。
ただし、端末装置１は、アウト オフ オーダー（Ｏｕｔ ｏｆ Ｏｒｄｅｒ）ＰＵＳＣＨ送信をしてもよい。具体的に言うと、端末装置１は、シンボルｉで終了するＰＤＣＣＨによってシンボルｊで開始する最初のＰＵＳＣＨ送信を開始するようにスケジュールされてもよい。ここで、ＰＤＣＣＨは、第３のＤＣＩを伴うＰＤＣＣＨに対応してもよい。最初のＰＵＳＣＨは、第３のＤＣＩによってスケジュールされる第１のＰＵＳＣＨに対応してもよい。続いて、端末装置１は、シンボルｉより後に終了する第４のＤＣＩを伴うＰＤＣＣＨを受信してもよい。該第４のＤＣＩによってスケジュールされるＰＵＳＣＨ（第２のＰＵＳＣＨ）は、最初のＰＵＳＣＨの終了より早く開始してもよい。即ち、あるセル
（ある所与のスケジューリングセル）内の任意２つのＨＡＲＱプロセス番号において、端末装置１がシンボルｉで終了する第３のＤＣＩを伴うＰＤＣＣＨによってシンボルｊで開始する最初のＰＵＳＣＨ送信を開始するようにスケジュールされている場合、端末装置１は、シンボルｉより後に終了する第４のＤＣＩを伴うＰＤＣＣＨによって最初のＰＵＳＣＨの終了より早く開始するあるＰＵＳＣＨを送信するようにスケジュールされるとは期待してもよい。即ち、あるセル内の任意２つのＨＡＲＱプロセス番号において、基地局装置３は、ある端末装置１にシンボルｉで終了する第３のＤＣＩを伴うＰＤＣＣＨによってシンボルｊで開始する最初のＰＵＳＣＨ送信を開始するようにスケジュールしている場合に、シンボルｉより後に終了する第４のＤＣＩを伴うＰＤＣＣＨによって最初のＰＵＳＣＨの終了より早く開始するあるＰＵＳＣＨを該端末装置１に送信するようにスケジュールしてもよい。
図９（Ａ）において、端末装置１は、ＤＣＩ（９００）を検出することによって、その検出したＤＣＩによってスケジュールされるＰＵＳＣＨ（９０３）を送信してもよい。ここで、ＤＣＩ（９００）は第３のＤＣＩに対応する。ＤＣＩ（９０１）は、ＤＣＩ（９００）が終了するシンボルより後に終了するＤＣＩである。ＤＣＩ（９０１）の一部分のシンボルは、ＤＣＩ（９００）と時間的にオーバラップしてもよい。そして、ＰＵＳＣＨ（９０２）は、ＰＵＳＣＨ（９０３）の終了より早く開始するＰＵＳＣＨであってもよい。ＰＵＳＣＨ（９０４）は、ＰＵＳＣＨ（９０３）の終了より後に開始するＰＵＳＣＨであってもよい。ＰＵＳＣＨ（９０２）、ＰＵＳＣＨ（９０３）、および、ＰＵＳＣＨ（９０４）は第３のＤＣＩによってスケジュールされる第１のＰＵＳＣＨに対応する。図９（Ａ）において、ＰＵＳＣＨ（９０３）は、最初のＰＵＳＣＨと称してもよい。ＰＵＳＣＨ（９０３）は、第１のＨＡＲＱプロセス番号を伴うＰＵＳＣＨに対応してもよい。ＰＵＳＣＨ（９０２）は、第１のＨＡＲＱプロセス番号と異なる値に対応するＨＡＲＱプロセス番号を伴うＰＵＳＣＨに対応してもよい。ＰＵＳＣＨ（９０４）は、第１のＨＡＲＱプロセス番号と異なる値に対応するＨＡＲＱプロセス番号を伴うＰＵＳＣＨに対応してもよい。すなわち、端末装置１は、ＤＣＩ（９０１）を受信し、対応するＰＵＳＣＨ（９０２）を送信するようにスケジュールされることを期待しなくてもよい。端末装置１は、ＤＣＩ（９０１）を受信し、対応するＰＵＳＣＨ（９０４）を送信するようにスケジュールされることを期待してもよい。すなわち、基地局装置３は、端末装置１にＤＣＩ（９００）によってＰＵＳＣＨ（９０３）送信を開始するようにスケジュールしている場合に、ＤＣＩ（９０１）によってＰＵＳＣＨ（９０２）を該端末装置１に送信するようにスケジュールしなくてもよい。すなわち、基地局装置３は、端末装置１にＤＣＩ（９００）によってＰＵＳＣＨ（９０３）送信を開始するようにスケジュールしている場合に、ＤＣＩ（９０１）によってＰＵＳＣＨ（９０４）を該端末装置１に送信するようにスケジュールしてもよい。即ち、ＰＵＳＣＨ（９０２）送信をスケジュールしようとするＤＣＩは、ＤＣＩ（９００）を伴うＰＤＣＣＨが終了するシンボルと同じシンボルで終了するＤＣＩであってもよいし、ＤＣＩ（９００）を伴うＰＤＣＣＨが終了するシンボルより前に終了するＤＣＩであってもよい。
図９（Ｂ）は、アウト オフ オーダー（Ｏｕｔ ｏｆ Ｏｒｄｅｒ）ＰＵＳＣＨ送信の一例を示す図である。図９（Ｂ）において、端末装置１は、ＤＣＩ（９１０）を検出することによって、その検出したＤＣＩによってスケジュールされるＰＵＳＣＨ（９１３）を送信してもよい。ここで、ＤＣＩ（９１０）は第３のＤＣＩに対応する。ＤＣＩ（９１１）は、ＤＣＩ（９１０）が終了するシンボルより後に終了するＤＣＩである。ＤＣＩ（９１１）の一部分のシンボルは、ＤＣＩ（９１０）と時間的にオーバラップしてもよい。そして、ＰＵＳＣＨ（９１２）は、ＰＵＳＣＨ（９１３）の終了（開始）より早く開始するＰＵＳＣＨであってもよい。ＰＵＳＣＨ（９１４）は、ＰＵＳＣＨ（９１３）の終了より後に開始するＰＵＳＣＨであってもよい。ＰＵＳＣＨ（９１３）は第３のＤＣＩによってスケジュールされる第１のＰＵＳＣＨに対応する。ＰＵＳＣＨ（９１２）、および、ＰＵＳＣＨ（９１４）は第４のＤＣＩによってスケジュールされる第２のＰＵＳＣＨに対応する。図９（Ｂ）において、ＰＵＳＣＨ（９１３）は、最初のＰＵＳＣＨと称してもよい。ＰＵＳＣＨ（９１３）は、第１のＨＡＲＱプロセス番号を伴うＰＵＳＣＨに対応してもよい。ＰＵＳＣＨ（９１２）は、第１のＨＡＲＱプロセス番号と異なる値に対応するＨＡＲＱプロセス番号を伴うＰＵＳＣＨに対応してもよい。ＰＵＳＣＨ（９１４）は、第１のＨＡＲＱプロセス番号と異なる値に対応するＨＡＲＱプロセス番号を伴うＰＵＳＣＨに対応してもよい。すなわち、端末装置１は、ＤＣＩ（９１１）を受信し、対応するＰＵＳＣＨ（９１２）を送信するようにスケジュールされることを期待してもよい。端末装置１は、ＤＣＩ（９１１）を受信し、対応するＰＵＳＣＨ（９１４）を送信するようにスケジュールされることを期待してもよい。すなわち、基地局装置３は、端末装置１にＤＣＩ（９１０）によってＰＵＳＣＨ（９１３）送信を開始するようにスケジュールしている場合に、ＤＣＩ（９１１）によってＰＵＳＣＨ（９１２）を該端末装置１に送信するようにスケジュールしてもよい。すなわち、基地局装置３は、端末装置１にＤＣＩ（９１０）によってＰＵＳＣＨ（９１３）送信を開始するようにスケジュールしている場合に、ＤＣＩ（９１１）によってＰＵＳＣＨ（９１４）を該端末装置１に送信するようにスケジュールしてもよい。ＤＣＩ（９１０）が終了するシンボルより後に終了するＤＣＩ（９１１）によってスケジュールされる、ＰＵＳＣＨ（９１３）の終了（または、開始）より早く開始するＰＵＳＣＨ（９１２）の送信は、アウト オフ オーダー（Ｏｕｔ ｏｆ Ｏｒｄｅｒ）ＰＵＳＣＨ送信と称してもよい。
以下、ＰＵＳＣＨ準備手順時間について説明する。
最初にＤＣＩ（スケジューリングＤＣＩ）がスケジュールするＰＵＳＣＨのためのＰＵＳＣＨ準備手順時間（ＰＵＳＣＨ ｐｒｅｐａｒａｔｉｏｎ ｔｉｍｅ）Ｔｐｒｏｃ，２について、説明する。Ｔｐｒｏｃ，２の値は、（式３）ｍａｘ（（Ｎ２＋ｄ２，１）（２０１８＋１４４）＊κ＊２−μ＊Ｔｃ、ｄ２，２）によって与えられてもよい。関数ｍａｘ（Ａ、Ｂ）は、Ａの値とＢの値の内、最大の値を出力する。Ｎ２はＰＵＳＣＨ準備時間であり、予め定義されたシンボルの数である。ＰＵＳＣＨケイパビリティ１（ＰＵＳＣＨ
ｔｉｍｉｎｇ ｃａｐａｂｉｌｉｔｙ１）では、サブキャリア間隔１５ｋＨｚ、３０ｋＨｚ、６０ｋＨｚ、１２０ｋＨｚのそれぞれに対応するＮ２の数は、１０、１２、２３，３６であってもよい。ＰＵＳＣＨケイパビリティ２（ＰＵＳＣＨ ｔｉｍｉｎｇ ｃａｐａｂｉｌｉｔｙ２）では、サブキャリア間隔１５ｋＨｚ、３０ｋＨｚ、６０ｋＨｚのそれぞれに対応するＮ２の数は、５、５．５、１１であってもよい。μは、（μＤＬ、μＵＬ）の中から、より大きいＴｐｒｏｃ，２の値（最大の値）を算出するサブキャリア間隔に対応してもよい。μＤＬは、該ＰＵＳＣＨをスケジュールするＤＣＩを伴うＰＤＣＣＨのサブキャリア間隔に対応する。μＵＬは、ＰＵＳＣＨの送信が行われる上りリンクチャネルのサブキャリア間隔に対応する。ＰＵＳＣＨ割り当ての最初のシンボルがＤＭＲＳのみで構成（送信）されている場合、ｄ２，１は０であってもよい。ＰＵＳＣＨ割り当ての最初のシンボルがＤＭＲＳとトランスポートブロックのデータで構成（送信）されている場合、ｄ２，１は１であってもよい。κは、定数６４であり、Ｔｓ／Ｔｃから算出される。Ｔｓは、１／（Δｆｒｅｆ＊Ｎｆ、ｒｅｆ）から算出される。Ｔｃは、タイムユニットであり、１／（Δｆｍａｘ＊Ｎｆ）から算出される。Δｆｒｅｆは１５＊１０３ヘルツである。Ｎｆ、ｒｅｆは２０４８である。Δｆｍａｘは４８０＊１０３ヘルツである。Ｎｆは４０９６である。ＰＵＳＣＨをスケジュールするＤＣＩ（スケジューリングＤＣＩ）がＢＷＰ切り替えをトリガーした場合、ｄ２，２は、予め定義された値にセットされてもよい。ＰＵＳＣＨをスケジュールするＤＣＩがＢＷＰ切り替えをトリガーしない場合、ｄ２，２は、０にセットされてもよい。
端末装置１は、ＰＵＳＣＨ割り当てにおける最初の上りリンクシンボルがシンボルＬ２より前のシンボルではない場合に、該トランスポートブロックのためのＰＵＳＣＨを送信
してもよい。言い換えると、端末装置１は、ＰＵＳＣＨ割り当てにおける最初の上りリンクシンボルがシンボルＬ２と同じシンボル、または、シンボルＬ２より後のシンボルである場合に、該トランスポートブロックのためのＰＵＳＣＨを送信してもよい。即ち、端末装置１は、ＰＵＳＣＨ割り当てにおける最初の上りリンクシンボルがシンボルＬ２より前のシンボルである場合、該トランスポートブロックのためのＰＵＳＣＨを送信しなくてもよい。別の言い方で言えば、端末装置１は、ＰＵＳＣＨ割り当てにおける最初の上りリンクシンボルがシンボルＬ２より前のシンボルである場合、該スケジューリングＤＣＩを無視（ドロップ）してもよい。シンボルＬ２は、ＰＵＳＣＨをスケジュールするＤＣＩを伴うＰＤＣＣＨの最後のシンボルの受信の終了後にＴｐｒｏｃ，２の時間を始まって（経過して）から次のＣＰ（Cyclic Prefix）を伴う上りリンクシンボルとして定義される。す
なわち、シンボルＬ２の位置は、Ｔｐｒｏｃ，２の時間に基づいて特定（決定）されてもよい。すなわち、端末装置１は、ＤＣＩを伴うＰＤＣＣＨとそのＤＣＩがスケジュールするＰＵＳＣＨとの間のタイムオフセット（time offset、上りリンクシンボルの数）がＴ
ｐｒｏｃ，２の時間（Ｔｐｒｏｃ，２の時間に対応する上りリンクシンボルの数）と等しいまたは大きい場合、該ＰＵＳＣＨを送信してもよい。また、端末装置１は、ＤＣＩを伴うＰＤＣＣＨとそのＤＣＩがスケジュールするＰＵＳＣＨとの間のタイムオフセット（time offset）がＴｐｒｏｃ，２の時間（Ｔｐｒｏｃ，２の時間に対応する上りリンクシン
ボルの数）より小さい場合、該ＰＵＳＣＨを送信しなくてもよいし、該ＤＣＩをドロップしてもよい。そして、基地局装置３は、該ＰＵＳＣＨの受信を試みらなくてもよい。即ち、Ｔｐｒｏｃ，２の時間（Ｔｐｒｏｃ，２の時間に対応する上りリンクシンボルの数）は、ＰＵＳＣＨの送信が行われるかどうかを決定するために用いられてもよい。
以下、アウト オフ オーダーＰＵＳＣＨ送信が行われた場合に、ＰＵＳＣＨ準備手順時間について説明する。
異なるサービスのデータを伝送するＰＵＳＣＨ送信をサポートする端末装置１は、アウト オフ オーダーＰＵＳＣＨ送信をサポートしてもよい。アウト オフ オーダーＰＵＳＣＨ送信が行われた場合、ＰＵＳＣＨ送信のためのＰＵＳＣＨ準備手順時間（ＰＵＳＣＨ ｐｒｅｐａｒａｔｉｏｎ ｔｉｍｅ）Ｔｐｒｏｃ，２は、（式３）から算出されたＰＵＳＣＨ準備手順時間の値と異なってもよい。例えば、Ｔｐｒｏｃ，２の値は、（式４）ｍａｘ（（Ｎ２＋ｄ２，１）（２０１８＋１４４）＊κ＊２−μ＊Ｔｃ＋Ｔｐｒｏｃ，２’、ｄ２，２）によって与えられてもよい。以下、Ｔｐｒｏｃ，２’について説明する。（式４）での他のパラメータは、（式３）と同様であるため説明を省略する。
アウト オフ オーダーＰＵＳＣＨ送信が行われた場合、Ｔｐｒｏｃ，２’は、（式３）または（式４）に基づいて、与えられてもよい。アウト オフ オーダーＰＵＳＣＨ送信が行われない場合、Ｔｐｒｏｃ，２’は、０にセットされてもよい。即ち、第１のＰＵＳＣＨに対応するＰＵＳＣＨ準備手順時間は、該第１のＰＵＳＣＨの送信前に、アウト オフ オーダーＰＵＳＣＨ送信が行われるかどうかに基づいて、変わってもよい。
図９（Ｃ）は、ＰＵＳＣＨ準備手順時間とＰＵＳＣＨ送信の一例を示す図である。図９（Ｃ）において、端末装置１は、ＤＣＩ（９２０）を検出することによって、その検出したＤＣＩによってスケジュールされるＰＵＳＣＨ（９２３）を送信してもよい。端末装置１は、ＤＣＩ（９２１）を検出することによって、その検出したＤＣＩによってスケジュールされるＰＵＳＣＨ（９２２）を送信してもよい。ここで、ＤＣＩ（９２０）は第３のＤＣＩに対応する。ＤＣＩ（９２１）は第４のＤＣＩに対応する。ＤＣＩ（９２１）は、ＤＣＩ（９２０）が終了するシンボルより後に終了するＤＣＩである。ＤＣＩ（９２１）の一部分のシンボルは、ＤＣＩ（９２０）と時間的にオーバラップしてもよい。ＰＵＳＣＨ（９２２）は、ＰＵＳＣＨ（９２３）の終了（または、開始）より早く開始するＰＵＳＣＨであってもよい。ＰＵＳＣＨ（９２２）に関連付けられるＨＡＲＱプロセス番号は、
ＰＵＳＣＨ（９２１）に関連付けられるＨＡＲＱプロセス番号と異なってもよい。即ち、ＰＵＳＣＨ（９２３）が送信されようとする時に、アウト オフ オーダー（Ｏｕｔ ｏｆ Ｏｒｄｅｒ）ＰＵＳＣＨ（ＰＵＳＣＨ（９２２））送信が行われる。
図９（Ｃ）において、シンボル９２４、シンボル９２５、シンボル９２６は、シンボルＬ２に対応するシンボルの位置であってもよい。ＰＵＳＣＨ（９２３）のためのＰＵＳＣＨ手順準備時間は、（式３）または（式４）に少なくとも基づいて、与えられてもよい。例えば、ＰＵＳＣＨ手順準備時間に基づき与えられたシンボルＬ２の位置がシンボル９２４または９２５の場合、端末装置１は、ＰＵＳＣＨ（９２３）を送信してもよい。ＰＵＳＣＨ手順準備時間に基づき与えられたシンボルＬ２の位置がシンボル９２６の場合、端末装置１は、ＰＵＳＣＨ（９２３）を送信しなくてもよいし、該ＰＵＳＣＨ（９２３）をスケジュールするＤＣＩ（９２０）をドロップしてもよい。該ＰＵＳＣＨ（９２３）の送信に対して、アウト オフ オーダーＰＵＳＣＨ（９２２）送信が行われた場合、該ＰＵＳＣＨのためのＰＵＳＣＨ手順準備時間は、（式４）に少なくとも基づいて、与えられてもよい。該ＰＵＳＣＨ（９２３）の送信に対して、アウト オフ オーダーＰＵＳＣＨ（９２２）送信がない場合、該ＰＵＳＣＨ（９２３）のためのＰＵＳＣＨ手順準備時間は、（式３）または（式４）に少なくとも基づいて、与えられてもよい。（式４）において、アウト オフ オーダーＰＵＳＣＨ（９２２）送信が発生した場合、Ｔｐｒｏｃ，２’の値は、ＰＵＳＣＨ（９２２）のためのＰＵＳＣＨ手順準備時間の値に対応してもよい。（式４）において、アウト オフ オーダーＰＵＳＣＨ（９２２）送信が発生しない場合、Ｔｐｒｏｃ，２’の値は、０にセットされてもよい。別の言葉で言うと、ＰＵＳＣＨ（９２３）のためのＰＵＳＣＨ手順準備時間の値は、（式３）に少なくとも基づいて、与えられた第１の値であってもよい。ＰＵＳＣＨ（９２２）を送信する場合、ＰＵＳＣＨ（９２３）のためのＰＵＳＣＨ手順準備時間の値は、第１の値に第２の値を加算した値であってもよい。第２の値は、ＰＵＳＣＨ（９２２）のためのＰＵＳＣＨ手順準備時間の値に少なくとも基づいて与えられてもよい。ＰＵＳＣＨ（９２２）の送信が発生しない場合、第２の値は、０であってもよい。端末装置１は、ＤＣＩ（９２０）とＰＵＳＣＨ（９２３）との間のシンボル数がＰＵＳＣＨ（９２３）のためのＰＵＳＣＨ手順準備時間の値に対応するシンボルの数と等しいまたは多い場合、ＰＵＳＣＨ（９２３）を送信してもよい。また、端末装置１は、ＤＣＩ（９２０）とＰＵＳＣＨ（９２３）との間のシンボル数がＰＵＳＣＨ（９２３）のためのＰＵＳＣＨ手順準備時間の値に対応するシンボルの数より少ない場合、ＰＵＳＣＨ（９２３）を送信しなくてもよい。
ＰＵＳＣＨ（９２２）のためのＰＵＳＣＨ手順準備時間は、（式３）または（式４）に少なくとも基づいて、与えられてもよい。ここで、（式４）において、ＰＵＳＣＨ（９２２）の送信に対して、アウト オフ オーダーＰＵＳＣＨ送信が発生しないため、Ｔｐｒｏｃ，２’の値は、０にセットされてもよい。ＰＵＳＣＨ（９２２）に適用されるＰＵＳＣＨケイパビリティは、ＰＵＳＣＨ（９２３）に適用されるＰＵＳＣＨケイパビリティと異なってもよい。即ち、ＰＵＳＣＨ（９２２）に適用されるＮ２は、ＰＵＳＣＨ（９２３）に適用されるＮ２の値と同様の値、または、ＰＵＳＣＨ（９２３）に適用されるＮ２の値より小さい値であってもよい。また、端末装置１は、ＰＵＳＣＨ（９２３）のためのＰＵＳＣＨ手順準備時間内で、ＰＵＳＣＨ（９２２）の処理（準備）を開始しようとする時に、ＰＵＳＣＨ（９２３）の処理（準備）を中止（スロット）してもよい。この時、ＰＵＳＣＨ（９２２）のためのＰＵＳＣＨ手順準備時間は、（式３）または（式４）に少なくとも基づいて与えられた値にさらにＸ個のシンボルを加算した値であってもよい。Ｘの値は、ＰＵＳＣＨ（９２３）に適用されるＰＵＳＣＨケイパビリティ、および／または、ＰＵＳＣＨ（９２３）に適用されるＰＵＳＣＨ準備時間Ｎ２に少なくともに基づいて定義された値であってもよい。ＰＵＳＣＨ（９２３）の処理（準備）を中止（スロット）しない場合、Ｘの値は０であってもよい。また、端末装置１は、ＰＵＳＣＨ（９２３）のためのＰＵＳＣＨ手順準備時間外で、ＰＵＳＣＨ（９２２）の処理（準備）を開始しようとする時に、ＰＵＳＣＨ（９２３）の処理（準備）を中止（スロット）しなくてもよい。この時、ＰＵＳＣＨ（９２２）のためのＰＵＳＣＨ手順準備時間は、（式３）または（式４）に少なくとも基づいて与えられた値であってもよい。
即ち、図９（Ｃ）において、端末装置１は、アウト オフ オーダーＰＵＳＣＨ（９２２）送信が発生した場合に、（式４）に基づいて与えられたＰＵＳＣＨ手順準備時間Ｔｐｒｏｃ，２を用いて、ＰＵＳＣＨ（９２３）を送信するかどうかを判断してもよい。端末装置１は、（式４）に基づいて与えられたＰＵＳＣＨ手順準備時間に基づいて、シンボルＬ２の位置を特定してもよい。端末装置１は、ＰＵＳＣＨ（９２３）割り当てにおける最初の上りリンクシンボルがシンボルＬ２より前のシンボルである場合、該ＰＵＳＣＨ（９２３）を送信しなくてもよい。端末装置１は、ＰＵＳＣＨ（９２３）割り当てにおける最初の上りリンクシンボルがシンボルＬ２またはシンボルＬ２より後のシンボルである場合、該ＰＵＳＣＨ（９２３）を送信してもよい。
また、図９（Ｃ）において、端末装置１は、アウト オフ オーダーＰＵＳＣＨ（９２２）送信が発生した場合に、（式３）に基づいて与えられたＰＵＳＣＨ手順準備時間Ｔｐｒｏｃ，２を用いて、ＰＵＳＣＨ（９２３）を送信するかどうかを判断してもよい。ただし、この時、シンボルＬ２は、ＰＵＳＣＨ（９２２）の最後のシンボルの送信の終了後にＴｐｒｏｃ，２の時間を始まって（経過して）から次のＣＰ（Cyclic Prefix）を伴う上
りリンクシンボルとして定義されてもよい。端末装置１は、ＰＵＳＣＨ（９２３）割り当てにおける最初の上りリンクシンボルがシンボルＬ２より前のシンボルである場合、該ＰＵＳＣＨ（９２３）を送信しなくてもよい。端末装置１は、ＰＵＳＣＨ（９２３）割り当てにおける最初の上りリンクシンボルがシンボルＬ２またはシンボルＬ２より後のシンボルである場合、該ＰＵＳＣＨ（９２３）を送信してもよい。
また、図９（Ｃ）において、端末装置１がＰＵＳＣＨ（９２２）送信の発生によって、ＰＵＳＣＨ（９２３）の処理を中止した場合、端末装置１は、（式３）に基づいて与えられたＰＵＳＣＨ手順準備時間Ｔｐｒｏｃ，２を用いて、ＰＵＳＣＨ（９２３）を送信するかどうかを判断してもよい。ただし、この時、新たなシンボルＬ２は、ＰＵＳＣＨ（９２２）の最後のシンボルの送信の終了後にＴｐｒｏｃ，２の時間を始まって（経過して）から次のＣＰ（Cyclic Prefix）を伴う上りリンクシンボルとして定義されてもよい。また、端末装置１がＰＵＳＣＨ（９２２）送信の発生があっても、ＰＵＳＣＨ（９２３）の処理を中止しない場合、端末装置１は、（式４）に基づいて与えられたＰＵＳＣＨ手順準備時間Ｔｐｒｏｃ，２を用いて、ＰＵＳＣＨ（９２３）を送信するかどうかを判断してもよい。ただし、この時、シンボルＬ２は、ＤＣＩ（９２０）を伴うＰＤＣＣＨの最後のシンボルの受信の終了後にＴｐｒｏｃ，２の時間を始まって（経過して）から次のＣＰ（Cyclic Prefix）を伴う上りリンクシンボルとして定義されてもよい。次に、端末装置１は、ＰＵＳＣＨ（９２３）割り当てにおける最初の上りリンクシンボルがシンボルＬ２より前のシンボルである場合、該ＰＵＳＣＨ（９２３）を送信しなくてもよい。端末装置１は、ＰＵＳＣＨ（９２３）割り当てにおける最初の上りリンクシンボルがシンボルＬ２またはシンボルＬ２より後のシンボルである場合、該ＰＵＳＣＨ（９２３）を送信してもよい。
端末装置１は、第３のＤＣＩの検出によって、対応する第１のＰＵＳＣＨを送信しようとする。端末装置１は、第１のＰＵＳＣＨのＰＵＳＣＨ手順準備時間の値に少なくとも基づいて、該第１のＰＵＳＣＨを送信するかどうかを決定してもよい。第１のＰＵＳＣＨのＰＵＳＣＨ手順準備時間の値は、第１の値であってもよい。端末装置１は、第３のＤＣＩと第１のＰＵＳＣＨとの間のシンボル数が第１のＰＵＳＣＨのＰＵＳＣＨ手順準備時間の値に対応するシンボルの数と等しいまたは多い場合、第１のＰＵＳＣＨの送信を決定してもよい。端末装置１は、アウト オフ オーダーＰＵＳＣＨ送信が発生する条件を満たす場合、第１のＰＵＳＣＨのＰＵＳＣＨ手順準備時間の値は、第１の値に第２の値を加算し
た値であってもよい。アウト オフ オーダーＰＵＳＣＨ送信が発生する条件には、以下の条件（Ａ）から条件（Ｈ）までの一部または全部が少なくとも含まれてもよい。（アウト オフ オーダー）ＰＵＳＣＨ送信が発生することは、（アウト オフ オーダー）ＰＵＳＣＨを送信することと意味してもよい。（アウト オフ オーダー）ＰＵＳＣＨ送信が発生することは、（アウト オフ オーダー）ＰＵＳＣＨがスケジュールされることと意味してもよい。（アウト オフ オーダー）ＰＵＳＣＨ送信が発生することは、（アウト オフ オーダー）ＰＵＳＣＨ送信が行われることと意味してもよい。
条件（Ａ）は、第２のＰＵＳＣＨが送信されることである。
条件（Ｂ）は、送信される第２のＰＵＳＣＨが第４のＤＣＩによってスケジュールされることである。
条件（Ｃ）は、第４のＤＣＩの受信が第３のＤＣＩの受信が終了するシンボルより後に終了しことである。
条件（Ｄ）は、第２のＰＵＳＣＨの送信は、第１のＰＵＳＣＨの送信の終了より早く開始されることである。
条件（Ｅ）は、第２のＰＵＳＣＨのためのＨＡＲＱプロセス番号が第１のＰＵＳＣＨのためのＨＡＲＱプロセス番号と異なることである。
条件（Ｆ）は、第３のＤＣＩに付加されたＣＲＣをスクランブルするＲＮＴＩの値が第１の範囲であり、第４のＤＣＩに付加されたＣＲＣをスクランブルするＲＮＴＩの値が第１の範囲とは異なる第２の範囲であることである。
条件（Ｈ）は、第３のＤＣＩに用いられるフォーマットが第４のＤＣＩに用いられるフォーマットと異なるフォーマットであることである。
上述のように、アウト オフ オーダーＰＵＳＣＨ送信が発生した場合、２つのＰＵＳＣＨ送信（第１のＰＵＳＣＨ送信と第２のＰＵＳＣＨ送信）は、時間的にオーバラップしなくてもよい。アウト オフ オーダーＰＵＳＣＨ送信が発生し、且つ、２つのＰＵＳＣＨ送信（第１のＰＵＳＣＨ送信と第２のＰＵＳＣＨ送信）が時間的にオーバラップした場合、端末装置１は、ＰＵＳＣＨ手順準備時間に基づかず、第１のＰＵＳＣＨ送信をドロップしてもよい。
以下、本実施形態における装置の構成について説明する。
図２１は、本実施形態の端末装置１の構成を示す概略ブロック図である。図示するように、端末装置１は、無線送受信部１０、および、上位層処理部１４を含んで構成される。無線送受信部１０は、アンテナ部１１、ＲＦ（Radio Frequency）部１２、および、ベー
スバンド部１３を含んで構成される。上位層処理部１４は、媒体アクセス制御層処理部１５、無線リソース制御層処理部１６を含んで構成される。無線送受信部１０を送信部、受信部、モニタ部、または、物理層処理部とも称する。上位層処理部１４を測定部１４、選択部１４、決定部１４または制御部１４とも称する。
上位層処理部１４は、ユーザの操作等により生成された上りリンクデータ（トランスポートブロックと称されてもよい）を、無線送受信部１０に出力する。上位層処理部１４は、媒体アクセス制御（MAC: Medium Access Control）層、パケットデータ統合プロトコル（Packet Data Convergence Protocol: PDCP）層、無線リンク制御（Radio Link Control: RLC）層、無線リソース制御（Radio Resource Control: RRC）層の一部あるいはすべての処理を行なう。上位層処理部１４は、基地局装置３から受信した上位層の信号および／または下りリンク制御情報に基づいて、物理上りリンク共用チャネルを送信するための時間パラメータを決定する機能を備えてもよい。上位層処理部１４は、ＰＤＳＣＨ処理手順時間またはＰＵＳＣＨ手順準備時間に基づいて、対応するＨＡＲＱ−ＡＣＫの送信またはＰＵＳＣＨの送信を決定したり、中止したりする機能を備えてもよい。
上位層処理部１４が備える媒体アクセス制御層処理部１５は、ＭＡＣレイヤ（媒体アクセス制御層）の処理を行なう。媒体アクセス制御層処理部１５は、無線リソース制御層処理部１６によって管理されている各種設定情報／パラメータに基づいて、スケジューリング要求の伝送の制御を行う。
上位層処理部１４が備える無線リソース制御層処理部１６は、ＲＲＣレイヤ（無線リソース制御層）の処理を行なう。無線リソース制御層処理部１６は、自装置の各種設定情報／パラメータの管理をする。無線リソース制御層処理部１６は、基地局装置３から受信した上位層の信号に基づいて各種設定情報／パラメータをセットする。すなわち、無線リソース制御層処理部１６は、基地局装置３から受信した各種設定情報／パラメータを示す情報に基づいて各種設定情報／パラメータをセットする。無線リソース制御層処理部１６は、基地局装置３から受信した下りリンク制御情報に基づいてリソース割り当てを制御（特定）する。
無線送受信部１０は、変調、復調、符号化、復号化などの物理層の処理を行う。無線送受信部１０は、基地局装置３から受信した信号を、分離、復調、復号し、復号した情報を上位層処理部１４に出力する。無線送受信部１０は、データを変調、符号化することによって送信信号を生成し、基地局装置３等に送信する。無線送受信部１０は、基地局装置３から受信した上位層の信号（ＲＲＣメッセージ）、ＤＣＩなどを上位層処理部１４に出力する。また、無線送受信部１０は、上位層処理部１４からの指示に基づいて、上りリンク信号（物理上りリンク制御チャネルおよび／または物理上りリンク共用チャネルを含む）を生成して送信する。無線送受信部１０は、物理下りリンク制御チャネルおよび／または物理下りリンク共用チャネルを受信する機能を備えてもよい。無線送受信部１０は、物理上りリンク制御チャネルおよび／または物理上りリンク共用チャネルを送信する機能を備えてもよい。無線送受信部１０は、物理下りリンク制御チャネルで下りリンク制御情報を受信する機能を備えてもよい。無線送受信部１０は、物理下りリンク制御チャネルで受信した下りリンク制御情報を上位層処理部１４に出力する機能を備えてもよい。
ＲＦ部１２は、アンテナ部１１を介して受信した信号を、直交復調によりベースバンド信号に変換し（ダウンコンバート: down covert）、不要な周波数成分を除去する。ＲＦ
部１２は、処理をしたアナログ信号をベースバンド部に出力する。
ベースバンド部１３は、ＲＦ部１２から入力されたアナログ信号を、アナログ信号をデジタル信号に変換する。ベースバンド部１３は、変換したデジタル信号からＣＰ（Cyclic
Prefix）に相当する部分を除去し、ＣＰを除去した信号に対して高速フーリエ変換（Fast Fourier Transform: FFT）を行い、周波数領域の信号を抽出する。
ベースバンド部１３は、データを逆高速フーリエ変換（Inverse Fast Fourier Transform: IFFT）して、ＯＦＤＭシンボルを生成し、生成されたＯＦＤＭシンボルにＣＰを付加し、ベースバンドのデジタル信号を生成し、ベースバンドのデジタル信号をアナログ信号に変換する。ベースバンド部１３は、変換したアナログ信号をＲＦ部１２に出力する。
ＲＦ部１２は、ローパスフィルタを用いてベースバンド部１３から入力されたアナログ信号から余分な周波数成分を除去し、アナログ信号を搬送波周波数にアップコンバート（up convert）し、アンテナ部１１を介して送信する。また、ＲＦ部１２は、電力を増幅する。また、ＲＦ部１２は在圏セルにおいて送信する上りリンク信号および／または上りリンクチャネルの送信電力を決定する機能を備えてもよい。ＲＦ部１２を送信電力制御部とも称する。
図２２は、本実施形態の基地局装置３の構成を示す概略ブロック図である。図示するように、基地局装置３は、無線送受信部３０、および、上位層処理部３４を含んで構成される。無線送受信部３０は、アンテナ部３１、ＲＦ部３２、および、ベースバンド部３３を含んで構成される。上位層処理部３４は、媒体アクセス制御層処理部３５、無線リソース制御層処理部３６を含んで構成される。無線送受信部３０を送信部、受信部、モニタ部、または、物理層処理部とも称する。また様々な条件に基づき各部の動作を制御する制御部を別途備えてもよい。上位層処理部３４を、決定部３４または制御部３４とも称する。
上位層処理部３４は、媒体アクセス制御（MAC: Medium Access Control）層、パケットデータ統合プロトコル（Packet Data Convergence Protocol: PDCP）層、無線リンク制御（Radio Link Control: RLC）層、無線リソース制御（Radio Resource Control: RRC）層の一部あるいはすべての処理を行なう。上位層処理部３４は、端末装置１に送信した上位層の信号に基づいて、物理上りリンク共用チャネルを送信するための時間パラメータに基づいて下りリンク制御情報を生成する機能を備えてもよい。上位層処理部３４は、生成した下りリンク制御情報などを無線送受信部３０に出力する機能を備えてもよい。
上位層処理部３４が備える媒体アクセス制御層処理部３５は、ＭＡＣレイヤの処理を行なう。媒体アクセス制御層処理部３５は、無線リソース制御層処理部３６によって管理されている各種設定情報／パラメータに基づいて、スケジューリングリクエストに関する処理を行う。
上位層処理部３４が備える無線リソース制御層処理部３６は、ＲＲＣレイヤの処理を行なう。無線リソース制御層処理部３６は、端末装置１にリソースの割当情報を含む下りリンク制御情報（上りリンクグラント、下りリンクグラント）を生成する。無線リソース制御層処理部３６は、下りリンク制御情報、物理下りリンク共用チャネルに配置される下りリンクデータ（トランスポートブロック、ランダムアクセス応答）、システム情報、ＲＲＣメッセージ、ＭＡＣ ＣＥ（Control Element）などを生成し、又は上位ノードから取
得し、無線送受信部３０に出力する。また、無線リソース制御層処理部３６は、端末装置１各々の各種設定情報／パラメータの管理をする。無線リソース制御層処理部３６は、上位層の信号を介して端末装置１各々に対して各種設定情報／パラメータをセットしてもよい。すなわち、無線リソース制御層処理部３６は、各種設定情報／パラメータを示す情報を送信／報知する。無線リソース制御層処理部３６は、あるセルにおける１つまたは複数の参照信号の設定を特定するための情報を送信／報知してもよい。
基地局装置３から端末装置１にＲＲＣメッセージ、ＭＡＣ ＣＥ、および／またはＰＤＣＣＨを送信し、端末装置１がその受信に基づいて処理を行う場合、基地局装置３は、端末装置が、その処理を行っていることを想定して処理（端末装置１やシステムの制御）を行う。すなわち、基地局装置３は、端末装置にその受信に基づく処理を行わせるようにするＲＲＣメッセージ、ＭＡＣ ＣＥ、および／またはＰＤＣＣＨを端末装置１に送っている。
無線送受信部３０は、端末装置１に上位層の信号（ＲＲＣメッセージ）、ＤＣＩなどを送信する。また、無線送受信部３０は、上位層処理部３４からの指示に基づいて、端末装置１から送信した上りリンク信号を受信する。無線送受信部３０は、物理下りリンク制御チャネルおよび／または物理下りリンク共用チャネルを送信する機能を備えてもよい。無線送受信部３０は、物理上りリンク制御チャネルおよび／または物理上りリンク共用チャネルを受信する機能を備えてもよい。無線送受信部３０は、物理下りリンク制御チャネルで下りリンク制御情報を送信する機能を備えてもよい。無線送受信部３０は、上位層処理部３４が出力した下りリンク制御情報を物理下りリンク制御チャネルで送信する機能を備えてもよい。その他、無線送受信部３０の一部の機能は、無線送受信部１０と同様である
ため説明を省略する。なお、基地局装置３が１つまたは複数の送受信点４と接続している場合、無線送受信部３０の機能の一部あるいは全部が、各送受信点４に含まれてもよい。
また、上位層処理部３４は、基地局装置３間あるいは上位のネットワーク装置（ＭＭＥ、Ｓ−ＧＷ（Ｓｅｒｖｉｎｇ−ＧＷ））と基地局装置３との間の制御メッセージ、またはユーザデータの送信（転送）または受信を行なう。図２２において、その他の基地局装置３の構成要素や、構成要素間のデータ（制御情報）の伝送経路については省略してあるが、基地局装置３として動作するために必要なその他の機能を有する複数のブロックを構成要素として持つことは明らかである。例えば、上位層処理部３４には、無線リソース管理（Ｒａｄｉｏ Ｒｅｓｏｕｒｃｅ Ｍａｎａｇｅｍｅｎｔ）層処理部や、アプリケーション層処理部が存在している。
なお、図中の「部」とは、セクション、回路、構成装置、デバイス、ユニットなど用語によっても表現される、端末装置１および基地局装置３の機能および各手順を実現する要素である。
端末装置１が備える符号１０から符号１６が付された部のそれぞれは、回路として構成されてもよい。基地局装置３が備える符号３０から符号３６が付された部のそれぞれは、回路として構成されてもよい。
（１）本発明の第１の態様における端末装置１は、第３のＤＣＩを受信する受信部１０と、第１のＰＵＳＣＨの送信を決定する決定部１４と、を備え、前記第１のＰＵＳＣＨは前記第３のＤＣＩによってスケジュールされ、第１の条件を満たさない場合、前記第１のＰＵＳＣＨのための第１のＰＵＳＣＨ手順準備時間の値は、第１の値であり、第１の条件を満たす場合、前記第１のＰＵＳＣＨ手順準備時間の値は、前記第１の値に第２の値を加算した値であり、前記決定部は、前記第３のＤＣＩと前記第１のＰＵＳＣＨとの間のシンボル数が前記第１のＰＵＳＣＨ手順準備時間の値に対応するシンボルの数と等しいまたは多い場合、前記第１のＰＵＳＣＨの送信を決定する。
（２）本発明の第２の態様における基地局装置３は、第３のＤＣＩを送信する送信部３０と、第１のＰＵＳＣＨの受信を決定する決定部３４と、を備え、前記第１のＰＵＳＣＨは前記第３のＤＣＩによってスケジュールされ、第１の条件を満たさない場合、前記第１のＰＵＳＣＨのための第１のＰＵＳＣＨ手順準備時間の値は、第１の値であり、第１の条件を満たす場合、前記第１のＰＵＳＣＨ手順準備時間の値は、前記第１の値に第２の値を加算した値であり、前記決定部は、前記第３のＤＣＩと前記第１のＰＵＳＣＨとの間のシンボル数が前記第１のＰＵＳＣＨ手順準備時間の値に対応するシンボルの数と等しいまたは多い場合、前記第１のＰＵＳＣＨの受信を決定する。
（３）本発明の第１の態様または第２の態様において、前記第１の条件には、第２のＰＵＳＣＨを送信することが少なくとも含まれ、前記第２のＰＵＳＣＨは第４のＤＣＩによってスケジュールされ、前記第４のＤＣＩの受信は、前記第３のＤＣＩの受信が終了するシンボルより後に終了し、前記第２のＰＵＳＣＨの送信は、前記第１のＰＵＳＣＨの送信の終了より早く開始される。
（４）本発明の第１の態様または第２の態様において、前記第２の値は、前記第２のＰＵＳＣＨの送信のためのＰＵＳＣＨ手順準備時間の値に少なくとも基づく与えられてもよい。
（５）本発明の第１の態様または第２の態様において、前記第２の値は、上位層のパラメータ、前記第４のＤＣＩのサブキャリア間隔、前記第２のＰＵＳＣＨのサブキャリア間
隔、前記第２のＰＵＳＣＨに割り当てられるリソースブロックの数、シンボルの数、トランスポートブロックのサイズ、ＭＣＳの内、一部または全部に少なくとも基づいて与えられる。
（６）本発明の第１の態様または第２の態様において、前記第３のＤＣＩに付加されたＣＲＣをスクランブルするＲＮＴＩの値が第１の範囲であり、前記第４のＤＣＩに付加されたＣＲＣをスクランブルするＲＮＴＩの値が前記第１の範囲とは異なる第２の範囲である。
（７）本発明の第１の態様または第２の態様において、前記第３のＤＣＩに用いられるフォーマットが第１のフォーマットであり、前記第４のＤＣＩに用いられるフォーマットが前記第１のフォーマットと異なる第２のフォーマットであることである。
（８）本発明の第１の態様または第２の態様において、前記第１のＰＵＳＣＨが第１のＨＡＲＱプロセス番号に対応し、前記第２のＰＵＳＣＨが第１のＨＡＲＱプロセス番号と異なる第２のＨＡＲＱプロセス番号に対応する。
これにより、端末装置１は、効率的に基地局装置３と通信することができる。例えば、異なるサービス（ｅＭＢＢ、ＵＲＬＬＣおよび／またはｍＭＴＣ等）のデータの送信に対して、端末装置１は、対応するＨＡＲＱ−ＡＣＫおよび／またはＰＵＳＣＨの送信を決定することができる。また、基地局装置３は、効率的に端末装置１と通信することができる。基地局装置３は、端末装置１が送信しないＨＡＲＱ−ＡＣＫおよび／またはＰＵＳＣＨに対して、対応するＰＤＳＣＨの送信（再送信）および／またはＰＵＳＣＨの送信（再送信）をスケジュールするＤＣＩを端末装置１に送信してもよい。
本発明に関わる装置で動作するプログラムは、本発明に関わる実施形態の機能を実現するように、Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ（ＣＰＵ）等を制御してコンピュータを機能させるプログラムであっても良い。プログラムあるいはプログラムによって取り扱われる情報は、一時的にＲａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ（ＲＡＭ）などの揮発性メモリあるいはフラッシュメモリなどの不揮発性メモリやＨａｒｄ Ｄｉｓｋ Ｄｒｉｖｅ（ＨＤＤ）、あるいはその他の記憶装置システムに格納される。
尚、本発明に関わる実施形態の機能を実現するためのプログラムをコンピュータが読み取り可能な記録媒体に記録しても良い。この記録媒体に記録されたプログラムをコンピュータシステムに読み込ませ、実行することによって実現しても良い。ここでいう「コンピュータシステム」とは、装置に内蔵されたコンピュータシステムであって、オペレーティングシステムや周辺機器等のハードウェアを含むものとする。また、「コンピュータが読み取り可能な記録媒体」とは、半導体記録媒体、光記録媒体、磁気記録媒体、短時間動的にプログラムを保持する媒体、あるいはコンピュータが読み取り可能なその他の記録媒体であっても良い。
また、上述した実施形態に用いた装置の各機能ブロック、または諸特徴は、電気回路、たとえば、集積回路あるいは複数の集積回路で実装または実行され得る。本明細書で述べられた機能を実行するように設計された電気回路は、汎用用途プロセッサ、デジタルシグナルプロセッサ（ＤＳＰ）、特定用途向け集積回路（ＡＳＩＣ）、フィールドプログラマブルゲートアレイ（ＦＰＧＡ）、またはその他のプログラマブル論理デバイス、ディスクリートゲートまたはトランジスタロジック、ディスクリートハードウェア部品、またはこれらを組み合わせたものを含んでよい。汎用用途プロセッサは、マイクロプロセッサであってもよいし、従来型のプロセッサ、コントローラ、マイクロコントローラ、またはステートマシンであっても良い。前述した電気回路は、デジタル回路で構成されていてもよいし、アナログ回路で構成されていてもよい。また、半導体技術の進歩により現在の集積回路に代替する集積回路化の技術が出現した場合、本発明の一又は複数の態様は当該技術による新たな集積回路を用いることも可能である。
なお、本発明に関わる実施形態では、基地局装置と端末装置で構成される通信システムに適用される例を記載したが、Ｄ２Ｄ（Device to Device）のような、端末同士が通信を行うシステムにおいても適用可能である。
なお、本願発明は上述の実施形態に限定されるものではない。実施形態では、装置の一例を記載したが、本願発明は、これに限定されるものではなく、屋内外に設置される据え置き型、または非可動型の電子機器、たとえば、ＡＶ機器、キッチン機器、掃除・洗濯機器、空調機器、オフィス機器、自動販売機、その他生活機器などの端末装置もしくは通信装置に適用出来る。
以上、この発明の実施形態に関して図面を参照して詳述してきたが、具体的な構成はこの実施形態に限られるものではなく、この発明の要旨を逸脱しない範囲の設計変更等も含まれる。また、本発明は、請求項に示した範囲で種々の変更が可能であり、異なる実施形態にそれぞれ開示された技術的手段を適宜組み合わせて得られる実施形態についても本発明の技術的範囲に含まれる。また、上記各実施形態に記載された要素であり、同様の効果を奏する要素同士を置換した構成も含まれる。
１（１Ａ、１Ｂ） 端末装置
３ 基地局装置
４ 送受信点（ＴＲＰ）
１０ 無線送受信部
１１ アンテナ部
１２ ＲＦ部
１３ ベースバンド部
１４ 上位層処理部
１５ 媒体アクセス制御層処理部
１６ 無線リソース制御層処理部
３０ 無線送受信部
３１ アンテナ部
３２ ＲＦ部
３３ ベースバンド部
３４ 上位層処理部
３５ 媒体アクセス制御層処理部
３６ 無線リソース制御層処理部
５０ 送信ユニット（ＴＸＲＵ）
５１ 位相シフタ
５２ アンテナエレメント

Claims (16)

  1. 端末装置であって、
    第３のＤＣＩを受信する受信部と、
    第１のＰＵＳＣＨの送信を決定する決定部と、を備え、
    前記第１のＰＵＳＣＨは前記第３のＤＣＩによってスケジュールされ、
    第１の条件を満たさない場合、前記第１のＰＵＳＣＨのための第１のＰＵＳＣＨ手順準備時間の値は、第１の値であり、
    第１の条件を満たす場合、前記第１のＰＵＳＣＨ手順準備時間の値は、前記第１の値に第２の値を加算した値であり、
    前記決定部は、前記第３のＤＣＩと前記第１のＰＵＳＣＨとの間のシンボル数が前記第１のＰＵＳＣＨ手順準備時間の値に対応するシンボルの数と等しいまたは多い場合、前記第１のＰＵＳＣＨの送信を決定する
    端末装置。
  2. 前記第１の条件には、第２のＰＵＳＣＨを送信することが少なくとも含まれ、
    前記第２のＰＵＳＣＨは第４のＤＣＩによってスケジュールされ、
    前記第４のＤＣＩの受信は、前記第３のＤＣＩの受信が終了するシンボルより後に終了し、
    前記第２のＰＵＳＣＨの送信は、前記第１のＰＵＳＣＨの送信の終了より早く開始される請求項１記載の端末装置。
  3. 前記第２の値は、前記第２のＰＵＳＣＨの送信のためのＰＵＳＣＨ手順準備時間の値に少なくとも基づく請求項２記載の端末装置。
  4. 前記第２の値は、上位層のパラメータ、前記第４のＤＣＩのサブキャリア間隔、前記第２のＰＵＳＣＨのサブキャリア間隔、前記第２のＰＵＳＣＨに割り当てられるリソースブロックの数、シンボルの数、トランスポートブロックのサイズ、ＭＣＳの内、一部または全部に少なくとも基づいて与えられる請求項２記載の端末装置。
  5. 前記第３のＤＣＩに付加されたＣＲＣをスクランブルするＲＮＴＩの値が第１の範囲であり、前記第４のＤＣＩに付加されたＣＲＣをスクランブルするＲＮＴＩの値が前記第１の範囲とは異なる第２の範囲である請求項２記載の端末装置。
  6. 前記第３のＤＣＩに用いられるフォーマットが第１のフォーマットであり、前記第４のＤＣＩに用いられるフォーマットが前記第１のフォーマットと異なる第２のフォーマットであることである請求項２記載の端末装置。
  7. 前記第１のＰＵＳＣＨが第１のＨＡＲＱプロセス番号に対応し、前記第２のＰＵＳＣＨが第１のＨＡＲＱプロセス番号と異なる第２のＨＡＲＱプロセス番号に対応する請求項２記載の端末装置。
  8. 基地局装置であって、
    第３のＤＣＩを送信する送信部と、
    第１のＰＵＳＣＨの受信を決定する決定部と、を備え、
    前記第１のＰＵＳＣＨは前記第３のＤＣＩによってスケジュールされ、
    第１の条件を満たさない場合、前記第１のＰＵＳＣＨのための第１のＰＵＳＣＨ手順準備時間の値は、第１の値であり、
    第１の条件を満たす場合、前記第１のＰＵＳＣＨ手順準備時間の値は、前記第１の値に第２の値を加算した値であり、
    前記決定部は、前記第３のＤＣＩと前記第１のＰＵＳＣＨとの間のシンボル数が前記第１のＰＵＳＣＨ手順準備時間の値に対応するシンボルの数と等しいまたは多い場合、前記第１のＰＵＳＣＨの受信を決定する
    基地局装置。
  9. 前記第１の条件には、第２のＰＵＳＣＨを送信することが少なくとも含まれ、
    前記第２のＰＵＳＣＨは第４のＤＣＩによってスケジュールされ、
    前記第４のＤＣＩの受信は、前記第３のＤＣＩの受信が終了するシンボルより後に終了し、
    前記第２のＰＵＳＣＨの送信は、前記第１のＰＵＳＣＨの送信の終了より早く開始される請求項８記載の基地局装置。
  10. 前記第２の値は、前記第２のＰＵＳＣＨの送信のためのＰＵＳＣＨ手順準備時間の値に少なくとも基づく請求項８記載の基地局装置。
  11. 前記第２の値は、上位層のパラメータ、前記第４のＤＣＩのサブキャリア間隔、前記第２のＰＵＳＣＨのサブキャリア間隔、前記第２のＰＵＳＣＨに割り当てられるリソースブロックの数、シンボルの数、トランスポートブロックのサイズ、ＭＣＳの内、一部または全部に少なくとも基づいて与えられる請求項８記載の基地局装置。
  12. 前記第３のＤＣＩに付加されたＣＲＣをスクランブルするＲＮＴＩの値が第１の範囲であり、前記第４のＤＣＩに付加されたＣＲＣをスクランブルするＲＮＴＩの値が前記第１の範囲とは異なる第２の範囲である請求項８記載の基地局装置。
  13. 前記第３のＤＣＩに用いられるフォーマットが第１のフォーマットであり、前記第４のＤＣＩに用いられるフォーマットが前記第１のフォーマットと異なる第２のフォーマットであることである請求項８記載の基地局装置。
  14. 前記第１のＰＵＳＣＨが第１のＨＡＲＱプロセス番号に対応し、前記第２のＰＵＳＣＨが第１のＨＡＲＱプロセス番号と異なる第２のＨＡＲＱプロセス番号に対応する請求項８記載の基地局装置。
  15. 端末装置の通信方法であって、
    第３のＤＣＩを受信し、
    第１のＰＵＳＣＨの送信し、
    前記第１のＰＵＳＣＨは前記第３のＤＣＩによってスケジュールされ、
    第１の条件を満たさない場合、前記第１のＰＵＳＣＨのための第１のＰＵＳＣＨ手順準備時間の値は、第１の値であり、
    第１の条件を満たす場合、前記第１のＰＵＳＣＨ手順準備時間の値は、前記第１の値に第２の値を加算した値であり、
    前記決定部は、前記第３のＤＣＩと前記第１のＰＵＳＣＨとの間のシンボル数が前記第１のＰＵＳＣＨ手順準備時間の値に対応するシンボルの数と等しいまたは多い場合、前記第１のＰＵＳＣＨの送信を決定する
    通信方法。
  16. 基地局装置の通信方法であって、
    第３のＤＣＩを送信し、
    第１のＰＵＳＣＨの受信を決定し、
    前記第１のＰＵＳＣＨは前記第３のＤＣＩによってスケジュールされ、
    第１の条件を満たさない場合、前記第１のＰＵＳＣＨのための第１のＰＵＳＣＨ手順準
    備時間の値は、第１の値であり、
    第１の条件を満たす場合、前記第１のＰＵＳＣＨ手順準備時間の値は、前記第１の値に第２の値を加算した値であり、
    前記決定部は、前記第３のＤＣＩと前記第１のＰＵＳＣＨとの間のシンボル数が前記第１のＰＵＳＣＨ手順準備時間の値に対応するシンボルの数と等しいまたは多い場合、前記第１のＰＵＳＣＨの受信を決定する
    通信方法。
JP2019060243A 2019-03-27 2019-03-27 基地局装置、端末装置、通信方法、および、集積回路 Pending JP2020162019A (ja)

Priority Applications (3)

Application Number Priority Date Filing Date Title
JP2019060243A JP2020162019A (ja) 2019-03-27 2019-03-27 基地局装置、端末装置、通信方法、および、集積回路
PCT/JP2020/008215 WO2020195531A1 (ja) 2019-03-27 2020-02-28 基地局装置、端末装置、および、通信方法
US17/442,997 US20220191912A1 (en) 2019-03-27 2020-02-28 Base station apparatus, terminal apparatus, and communication method

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2019060243A JP2020162019A (ja) 2019-03-27 2019-03-27 基地局装置、端末装置、通信方法、および、集積回路

Publications (1)

Publication Number Publication Date
JP2020162019A true JP2020162019A (ja) 2020-10-01

Family

ID=72611852

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2019060243A Pending JP2020162019A (ja) 2019-03-27 2019-03-27 基地局装置、端末装置、通信方法、および、集積回路

Country Status (3)

Country Link
US (1) US20220191912A1 (ja)
JP (1) JP2020162019A (ja)
WO (1) WO2020195531A1 (ja)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US12004142B2 (en) * 2020-03-30 2024-06-04 Qualcomm Incorporated Uplink timing associated with uplink transmission configuration indication (TCI) state
US20230309140A1 (en) * 2022-03-24 2023-09-28 Qualcomm Incorporated Methods and systems for aligning transmissions for intra-band carrier aggregation in sidelink communications

Family Cites Families (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10568081B2 (en) * 2016-03-21 2020-02-18 Samsung Electronics Co., Ltd. Scheduling uplink transmissions
CN111133814B (zh) * 2017-09-19 2024-01-26 日本电气株式会社 用于传输控制信息的方法和装置
WO2020145460A1 (ko) * 2019-01-10 2020-07-16 엘지전자 주식회사 비면허 대역을 지원하는 무선 통신 시스템에서 단말과 기지국의 동작 방법 및 이를 지원하는 장치
US11956816B2 (en) * 2019-01-22 2024-04-09 Samsung Electronics Co., Ltd. Method and device for determining transmission time in wireless communication system
US11246153B2 (en) * 2019-02-15 2022-02-08 Mediatek Singapore Pte. Ltd. Method and apparatus for handling out-of-order uplink scheduling in mobile communications
US10980067B2 (en) * 2019-05-02 2021-04-13 Qualcomm Incorporated Reference signal transmission techniques for random access messages
US20230354312A1 (en) * 2020-04-10 2023-11-02 Telefonaktiebolaget Lm Ericsson (Publ) Processing time for fast-switched ul tx across carriers

Also Published As

Publication number Publication date
US20220191912A1 (en) 2022-06-16
WO2020195531A1 (ja) 2020-10-01

Similar Documents

Publication Publication Date Title
JP7271097B2 (ja) 基地局装置、端末装置、および、通信方法
JP7246874B2 (ja) 基地局装置、端末装置、および、通信方法
JP7197297B2 (ja) 基地局装置、端末装置、および、通信方法
JP7313839B2 (ja) 基地局装置、端末装置、通信方法、および、集積回路
JP7240843B2 (ja) 基地局装置、端末装置、通信方法、および、集積回路
JP7287787B2 (ja) 基地局装置、端末装置、通信方法、および、集積回路
JP6917403B2 (ja) 基地局装置、端末装置および通信方法
JP7249785B2 (ja) 端末装置、基地局装置、および通信方法
WO2020218529A1 (ja) 基地局装置、端末装置、および、通信方法
JP6963586B2 (ja) 基地局装置、端末装置、および通信方法
WO2021066133A1 (ja) 端末装置、基地局装置、および、通信方法
JP2020137007A (ja) 基地局装置、端末装置、通信方法、および、集積回路
WO2020203427A1 (ja) 基地局装置、端末装置、および、通信方法
WO2021066154A1 (ja) 端末装置、基地局装置、および、通信方法
WO2021029367A1 (ja) 基地局装置、端末装置、および、通信方法
WO2020195531A1 (ja) 基地局装置、端末装置、および、通信方法
WO2020218348A1 (ja) 基地局装置、端末装置、通信方法、および、集積回路
JP2022102124A (ja) 端末装置、基地局装置、および、通信方法
JP2022025801A (ja) 端末装置、基地局装置、および、通信方法
JP2022011324A (ja) 端末装置、基地局装置、および、通信方法
WO2022239492A1 (ja) 端末装置、基地局装置、および、通信方法
JP2022102123A (ja) 端末装置、基地局装置、および、通信方法
JP2022055393A (ja) 端末装置、基地局装置、および、通信方法
WO2021029402A1 (ja) 基地局装置、端末装置、および、通信方法
WO2022138564A1 (ja) 端末装置、基地局装置、および、通信方法

Legal Events

Date Code Title Description
RD02 Notification of acceptance of power of attorney

Free format text: JAPANESE INTERMEDIATE CODE: A7422

Effective date: 20200706