JPWO2020166179A1 - 端末装置、通信方法及び集積回路 - Google Patents

端末装置、通信方法及び集積回路 Download PDF

Info

Publication number
JPWO2020166179A1
JPWO2020166179A1 JP2020572094A JP2020572094A JPWO2020166179A1 JP WO2020166179 A1 JPWO2020166179 A1 JP WO2020166179A1 JP 2020572094 A JP2020572094 A JP 2020572094A JP 2020572094 A JP2020572094 A JP 2020572094A JP WO2020166179 A1 JPWO2020166179 A1 JP WO2020166179A1
Authority
JP
Japan
Prior art keywords
message
terminal
resource
data
rach preamble
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
JP2020572094A
Other languages
English (en)
Inventor
哲矢 山本
秀俊 鈴木
リキン シャア
昭彦 西尾
ミンホン タオ
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.)
Panasonic Intellectual Property Corp of America
Original Assignee
Panasonic Intellectual Property Corp of America
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 Panasonic Intellectual Property Corp of America filed Critical Panasonic Intellectual Property Corp of America
Publication of JPWO2020166179A1 publication Critical patent/JPWO2020166179A1/ja
Pending legal-status Critical Current

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W74/00—Wireless channel access
    • H04W74/08—Non-scheduled access, e.g. ALOHA
    • H04W74/0833—Random access procedures, e.g. with 4-step access
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W74/00—Wireless channel access
    • H04W74/08—Non-scheduled access, e.g. ALOHA
    • H04W74/0833—Random access procedures, e.g. with 4-step access
    • H04W74/0841—Random access procedures, e.g. with 4-step access with collision treatment
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W74/00—Wireless channel access
    • H04W74/002—Transmission of channel access control information
    • H04W74/006—Transmission of channel access control information in the downlink, i.e. towards the terminal
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W74/00—Wireless channel access
    • H04W74/08—Non-scheduled access, e.g. ALOHA
    • H04W74/0866—Non-scheduled access, e.g. ALOHA using a dedicated channel for access
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W80/00—Wireless network protocols or protocol adaptations to wireless operation
    • H04W80/02—Data link layer protocols
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W92/00—Interfaces specially adapted for wireless communication networks
    • H04W92/04—Interfaces between hierarchically different network devices
    • H04W92/10—Interfaces between hierarchically different network devices between terminal device and access point, i.e. wireless air interface

Landscapes

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

Abstract

ランダムアクセス処理の効率を向上することができる端末。端末（２００）において、制御部（２０９）は、プリアンブル部及びデータ部を含むランダムアクセス信号のうち、データ部の送信に関するパラメータを動的に決定する。送信部（２１７）は、ランダムアクセス信号を用いて、決定されたパラメータを基地局（１００）へ通知する。

Description

本開示は、端末及び通信方法に関する。
3GPP（3rd Generation Partnership Project）では、第5世代移動通信システム（5G：5th Generation mobile communication sysmtems）の実現に向けて、Release 15 NR（New Radio access technology）の仕様策定が完了した。NRでは、モバイルブロードバンドの高度化（eMBB: enhanced Mobile Broadband）の基本的な要求条件である高速及び大容量と合わせ、超高信頼低遅延通信（URLLC: Ultra Reliable and Low Latency Communication）を実現する機能をサポートしている（例えば、非特許文献１−７を参照）。
3GPP TS 38.211 V15.4.0, "NR; Physical channels and modulation (Release 15)," December 2018 3GPP TS 38.212 V15.4.0, "NR; Multiplexing and channel coding (Release 15)," December 2018 3GPP TS 38.213 V15.4.0, "NR; Physical layer procedure for control (Release 15)," December 2018 3GPP TS 38.214 V15.4.0, "NR; Physical layer procedures for data (Release 15)," December 2018 3GPP, TS38.300 V15.4.0, "NR; NR and NG-RAN overall description; Stage 2 (Release 15)", December 2018 3GPP, TS38.321 V15.4.0, "NR; Medium accesss control (MAC) protocol specification (Release 15)", December 2018 3GPP, TS38.331 V15.4.0, "NR; Radio resource control (RRC) protocol specification (Release 15)", December 2018 B. Bertenyi, S. Nagata, H. Kooropaty, X. Zhou, W. Chen, Y. Kim, X. Dai, and X. Xu, "5G NR radio interface," Journal of ICT, Vol. 6 and 2, pp. 31-58, 2018 RP-182881, "New work item: 2-step RACH for NR," ZTE Corporation, Sanechips, December 2018
しかしながら、NRにおけるランダムアクセス処理について十分に検討されていない。
本開示の非限定的な実施例は、ランダムアクセス処理の効率を向上できる端末及び通信方法の提供に資する。
本開示の一実施例に係る端末は、プリアンブル部及びデータ部を含むランダムアクセス信号のうち、前記データ部の送信に関するパラメータを動的に決定する制御回路と、前記ランダムアクセス信号を用いて、前記決定されたパラメータを基地局へ通知する送信回路と、を具備する。
なお、これらの包括的または具体的な態様は、システム、装置、方法、集積回路、コンピュータプログラム、または、記録媒体で実現されてもよく、システム、装置、方法、集積回路、コンピュータプログラムおよび記録媒体の任意な組み合わせで実現されてもよい。
本開示の一実施例によれば、ランダムアクセス処理の効率を向上できる。
本開示の一実施例における更なる利点および効果は、明細書および図面から明らかにされる。かかる利点および／または効果は、いくつかの実施形態並びに明細書および図面に記載された特徴によってそれぞれ提供されるが、１つまたはそれ以上の同一の特徴を得るために必ずしも全てが提供される必要はない。
4ステップRandom access procedureの一例を示す図 2ステップRandom access procedureの一例を示す図 実施の形態１に係る端末の一部の構成例を示すブロック図 実施の形態１に係る基地局の構成例を示すブロック図 実施の形態１に係る端末の構成例を示すブロック図 実施の形態１に係る基地局及び端末の動作例を示すシーケンス図 実施の形態１に係るTBSとRACH preambleリソース群との対応付けの一例を示す図 Message Bの一例を示す図 Message Bの他の例を示す図 2ステップRandom access procedureの一例を示す図 2ステップRandom access procedureの一例を示す図 実施の形態２に係る送信パラメータとRACH preambleリソース群との対応付けの一例を示す図 実施の形態２に係る送信パラメータとRACH preambleリソース群との対応付けの一例を示す図 実施の形態２に係る送信パラメータとRACH preambleリソース群との対応付けの一例を示す図 実施の形態２に係る送信パラメータとRACH preambleリソース群との対応付けの一例を示す図 実施の形態３に係る基地局及び端末の動作例を示すシーケンス図 実施の形態３に係るTBSとUCIとの対応付けの一例を示す図 実施の形態４に係るTBSとUCIとの対応付けの一例を示す図
以下、本開示の実施の形態について図面を参照して詳細に説明する。
Release 15 NRにおいて、端末（移動局又はUE：User Equipmentとも呼ぶ）は、例えば、以下のケースにおいて、基地局（gNB又はeNBとも呼ぶ）に対してランダムアクセスチャネル信号（RACH：Random Access Channel）を送信する。
（１）初期アクセス時（例えば、RRC_IDLE状態からRRC_CONNECTED状態への遷移)
（２）RRC_INACTIVE状態からRRC_CONNECTED状態へ復帰する場合
（３）接続中（例えば、RRC_CONNECTED状態で上りリンク同期状態が“non-synchronized”の場合）において下りリンクデータ又は上りリンクデータが発生した時
（４）オンデマンドのSI（System Information）を要求する場合
（５）ビーム接続失敗から回復（BFR：Beam failure recovery）する場合
これにより、端末から基地局への接続又は再同期確立が試行される。これらの端末から基地局への接続又は再同期確立のために行われる一連の動作は「Random access procedure」と呼ばれる。
Release 15 NRでは、Random access procedureは、例えば、図１に示す４つのステップから構成される（4ステップRandom access procedure又は4ステップRACH procedureと呼ぶ）（例えば、非特許文献８を参照）。
＜Step 1：Message 1の送信＞
端末（例えば、UE）は、RACH preambleリソース候補（例えば、時間リソース、周波数リソース及び系列リソースの組み合わせにより規定されるリソース）群から、実際に用いるRACH preambleリソースをランダムに選択する。そして、端末は、選択したRACH preambleリソースを用いてRACH preamble（単にpreambleとも呼ぶ）を基地局（例えば、gNB）へ送信する。RACH preambleは、例えば、「Message 1」と呼ばれることがある。
＜Step 2：Message 2の送信＞
基地局は、RACH preambleを検出した場合、RACH応答（RAR: Random Access Response）を送信する。RARは、例えば、「Message 2」と呼ばれることがある。なお、この時点では、基地局は、RACH preambleを送信した端末を特定できない。このため、RARは、例えば、基地局がカバーするセルの全体に送信される。
RARには、例えば、端末が上りリンク信号の送信（Step 3：Message 3の送信）において使用するリソース（上りリンクリソース）に関する情報、又は、端末による上りリンクの送信タイミングに関する情報が含まれる。ここで、RACH preambleを送信した端末は、RACH preambleの送信タイミングから規定された期間（例えば、RAR reception windowと呼ぶ）内にRARを受信しない場合、再度、RACH preambleリソースの選択、及び、RACH preambleの送信（換言すると、Message 1の再送）を行う。
＜Step 3：Message 3の送信＞
端末は、RARによって基地局から指示された上りリンクリソースを用いて、例えば、RRC（Radio Resource Control）接続要求又はスケジュール要求等を含む「Message 3」を送信する。
＜Step 4：Message 4の送信＞
基地局は、端末を識別するための識別情報（例えば、UE-ID）を含めたメッセージ（「Message 4」と呼ばれる）を端末へ送信する。基地局は、Message 4を送信することにより、複数の端末が競合していないことを確認する（contention resolution）。なお、UE-IDには、例えば、C-RNTI（Cell-Radio Network Temporary Identifier）又はTemporary C-RNTI等が使用されてよい。
以上、4ステップRandom access procedureの一例について説明した。
一方、Release 16 NRでは、端末から基地局への接続又は再同期確立を低遅延で効率的に行うために、例えば、図２に示す２ステップから構成されるRandom access procedure（2ステップRandom access procedure、又は、2-step RACH procedureと呼ぶこともある）が検討されている（例えば、非特許文献９を参照）。
＜Step 1：Message Aの送信＞
端末は、4ステップRandom access procedure（例えば、図１を参照）のStep 1及びStep 3に相当するMessage 1（換言すると、preamble）及びMessage 3に相当する情報を含むメッセージ（以下、「Message A」と呼ぶ）を基地局へ送信する。
＜Step 2：Message Bの送信＞
基地局は、Message Aを検出した場合、Message Bを送信する。Message Bには、例えば、4ステップRandom access procedure（例えば、図１を参照）のMessage 2又はMessage 4に相当する情報（例えば、何れか一方又はまたは両方）が含まれる。
2ステップRandom access procedureは、例えば、5Gで想定されているeMBB、URLCC、及び、多数MTC（Machine Type Communication）端末のサポート（mMTC: massive MTC）等の主なユースケース、又は、ライセンスバンド及びアンライセンスドバンドに対して共通に適用できるような設計が望まれている。
ここで、Random access procedureでは、Message 3の上りリンク送信において、RRC接続要求又はスケジューリング要求等の通信を制御するための信号（例えば、C-plane（Control-plane）データとも呼ぶ）に加えて、端末が基地局に対して実際に送信したいユーザ（UP：User Plane）データを送信することによって、低遅延の上りリンクデータ伝送が実現される。
例えば、Release 16では、RRC_CONNECTED状態における2ステップRandom access procedureにおいて、UPデータ（又は、PUSCH（Physical Uplink Shared Channel）とも呼ぶ）の送信をサポートすることが期待されている（例えば、非特許文献９を参照）。なお、RRC_IDLE状態又はRRC_INACTIVE状態における2ステップRandom access procedureにおいて、UPデータの送信をサポートすることはRelease 16の検討範囲ではない。ただし、端末が2ステップRandom access procedureを開始する際の端末の状態は、RRC_CONNECTED状態に限定されない。
以下、2ステップRandom access procedureにおいてUPデータの送信をサポートする場合について説明する。
4ステップRandom access procedureでは、上述したように、端末は、RARによって基地局から指示された上りリンクリソースを用いて、Message 3を送信する。このとき、端末は、Message 3には、RRC接続要求又はスケジューリング要求等のC-planeデータに加えて、UPデータを含めることができる。
ここで、RARには、端末が上りリンクで使用するリソースに関する情報（例えば、時間リソース又は周波数リソースの位置、リソース量（又はリソースサイズ）、及び、MCS（Modulation and Coding Scheme）等）が含まれている。端末は、上記リソースに関する情報を用いて、上りリンク送信のトランスポートブロックサイズ（TBS：Transport Block Size）を決定する（例えば、非特許文献３、４を参照）。このように、4ステップRandom access procedureでは、基地局は、RARを用いて、端末に対する上りリンクのUPデータ送信を制御できるため、端末から送信されるMessage 3を正しく復調及び復号できる。
一方、2ステップRandom access procedureでは、端末は、Message Aにおいて、4ステップRandom access procedureのMessage 1（例えば、RACH preamble）及びMessage 3に相当する信号（例えば、RACHデータ部分又は単にデータ部分と呼ぶ）を送信する。そのため、端末は、Message AにおいてUPデータを送信する場合、基地局からの指示（例えば、RAR）に含まれる上りリンクで使用するリソースに関する情報（換言すると、UL grant）無しで、Message Aのデータ部分においてUPデータを送信することになる。
ここで、一例として、端末が送信するMessage Aのデータ部分に使用するリソースに関する情報（例えば、時間リソース及び周波数リソースの位置、リソース量、及びMCS等）を基地局からの報知情報又は上位レイヤ信号（例えば、RRC信号）によって、予めSemi-staticに端末に設定し、固定的なTBSの送信をサポートする方法が考えられる。
しかし、上述したように、2ステップRandom access procedureには、5Gのあらゆるユースケースに共通に適用できるような設計が望まれ、端末が送信する上りリンクのUPデータ量は、固定ではなく、ユースケースによって異なることが想定される。
また、１つのユースケースにおいても、想定するサービスによってトラフィックが異なる場合がある。一例として、URLLCにおいて、Release 15では32 Byteのパケット送信を想定するのに対して、Release 16では、URLLCサービスの拡大が期待されており、より大きなパケットサイズ（例えば、256 Byte等）のパケット送信が想定されている。
端末において送信される上りリンクのUPデータ量が可変の場合、固定的なTBSの送信をサポートする方法では、上りリンクリソース割り当ての柔軟性に欠ける。
２ステップRandom access procedureは、特に、低遅延のユースケースへの適用が有効である。このとき、端末が送信するUPデータ量に対して、上りリンクリソースが十分に割り当てられていない場合、UPデータのSegmentationが発生してしまう。この場合、2ステップRandom access procedureによって送信しきれないUPデータは、次の上りリンクデータ送信の機会まで保留される。この結果、UPデータを送信完了するまでに大きな遅延が発生して、URLLCの低遅延の要求条件を満たすことができなくなる恐れがある。
また、他の例として、端末が送信すると想定される最大のUPデータ量に合わせて上りリンクリソース（例えば、TBS）を固定的に設定する方法が考えられる。しかし、この方法では、2ステップRandom access procedureのために多くの無線リソースを確保する必要があり、リソースの利用効率が劣化する。
そこで、本開示の一実施例では、2ステップRandom access procedureにおける上りリンク送信の効率を向上する方法について説明する。
以下、各実施の形態について、詳細に説明する。
（実施の形態１）
［通信システムの概要］
本開示の各実施の形態に係る通信システムは、基地局１００及び端末２００を備える。
図３は、本開示の各実施の形態に係る端末２００の一部の構成例を示すブロック図である。図３に示す端末２００において、制御部２０９（制御回路に相当）は、プリアンブル部（例えば、Message AのRACH preambleに相当）及びデータ部（例えば、Message Aのデータ部分に相当）を含むランダムアクセス信号（例えば、Message Aに相当）のうち、データ部の送信に関するパラメータ（例えば、TBS等）を動的に決定する。送信部２１７（送信回路に相当）は、ランダムアクセス信号を用いて、決定されたパラメータを基地局１００へ通知する。
［基地局の構成］
図４は、本開示の実施の形態１に係る基地局１００の構成例を示すブロック図である。図４において、基地局１００は、制御部１０１と、データ生成部１０２と、符号化部１０３と、変調部１０４と、上位制御信号生成部１０５と、符号化部１０６と、変調部１０７と、下り制御信号生成部１０８と、符号化部１０９と、変調部１１０と、信号割当部１１１と、IFFT（Inverse Fast Fourier Transform）部１１２と、送信部１１３と、アンテナ１１４と、受信部１１５と、FFT（Fast Fourier Transform）部１１６と、抽出部１１７と、検出部１１８と、復調部１１９と、復号部１２０と、を有する。
制御部１０１は、端末２００のMessage A送信のための情報を決定し、決定した情報を抽出部１１７、復調部１１９及び復号部１２０へ出力する。また、制御部１０１は、決定した情報を上位制御信号生成部１０５へ出力する。
Message A送信のための情報には、例えば、Message Aのデータ部分のTBSに関する情報、TBSとMessage AのRACH preambleリソース候補群との対応付けに関する情報、又は、Message Aのデータ部分のリソース候補（例えば、リソース位置及びリソース量の少なくとも一つ）と、Message AのRACH preambleリソース候補群との対応付けに関する情報、等が含まれてよい。
また、制御部１０１は、データ信号（例えば、Message B等）、上位レイヤの制御信号（例えば、上位制御信号）又は下りリンク制御情報（例えば、下り制御信号）を送信するための下りリンク信号に対する無線リソース割当（例えば、下りリンクリソース及びMCS等）を決定する。制御部１０１は、決定した情報を、符号化部１０３，１０６，１０９、変調部１０４，１０７，１１０、及び、信号割当部１１１へ出力する。また、制御部１０１は、決定した情報を下り制御信号生成部１０８へ出力する。
また，制御部１０１は、復号部１２０から入力されるMessage A（例えば、C-Planeデータ又はUPデータ）の復号結果、及び、検出部１１８から入力されるMessage A（例えば、RACH preamble）の検出結果に基づいて、Message Bに含める情報を決定し、決定した情報をデータ生成部１０２へ出力する。
データ生成部１０２は、制御部１０１から入力される、Message Bに含める情報を用いて、Message Bの情報ビット列（換言すると、下りリンクデータ）を生成し、生成した情報ビット列を符号化部１０３へ出力する。
符号化部１０３は、データ生成部１０２から入力される情報ビット列（データ信号）に対して誤り符号化を行い、符号化後のデータ信号を変調部１０４へ出力する。
変調部１０４は、符号化部１０３から入力されるデータ信号を変調して、変調後のデータ信号を信号割当部１１１へ出力する。
上位制御信号生成部１０５は、制御部１０１から入力される制御情報を用いて、制御情報ビット列（上位制御信号）を生成し、生成した制御情報ビット列を符号化部１０６へ出力する。
符号化部１０６は、上位制御信号生成部１０５から入力される制御情報ビット列に対して誤り訂正符号化を行い、符号化後の制御信号を変調部１０７へ出力する。
変調部１０７は、符号化部１０６から入力される制御信号を変調して、変調後の制御信号を信号割当部１１１へ出力する。
下り制御信号生成部１０８は、制御部１０１から入力される制御情報を用いて、制御情報ビット列（下り制御信号。例えば、DCI）を生成し、生成した制御情報ビット列を符号化部１０９へ出力する。なお、制御情報が複数の端末向けに送信されることもあるため、下り制御信号生成部１０８は、各端末向けの制御情報（例えば、PDCCH：Physical Downlink Control Channel）に、全端末向けの識別情報（例えば、RA-RNTI：Random Access-RNTI）又は端末固有の識別情報（例えば、C-RNTI）等を用いてスクランブルしてもよい。
符号化部１０９は、下り制御信号生成部１０８から入力される制御情報ビット列に対して誤り訂正符号化を行い、符号化後の制御信号を変調部１１０へ出力する。
変調部１１０は、符号化部１０９から入力される制御信号を変調して、変調後の制御信号を信号割当部１１１へ出力する。
信号割当部１１１は、制御部１０１から入力される無線リソースを示す情報に基づいて、変調部１０４から入力されるデータ信号、変調部１０７から入力される上位制御信号、又は、変調部１１０から入力される下り制御信号を、無線リソースにマッピングする。信号割当部１１１は、信号がマッピングされた下りリンクの信号をIFFT部１１２へ出力する。
IFFT部１１２は、信号割当部１１１から入力される信号に対して、OFDM等の送信波形生成処理を施す。IFFT部１１２は、CP（Cyclic Prefix）を付加するOFDM伝送の場合には、CPを付加する（図示せず）。IFFT部１１２は、生成した送信波形を送信部１１３へ出力する。
送信部１１３は、IFFT部１１２から入力される信号に対してD/A（Digital-to-Analog）変換、アップコンバート等のRF（Radio Frequency）処理を行い、アンテナ１１４を介して端末２００に無線信号を送信する。
受信部１１５は、アンテナ１１４を介して受信された端末２００からの上りリンク信号波形に対して、ダウンコンバート又はA/D（Analog-to-Digital）変換などのRF処理を行い、受信処理後の上りリンク信号波形をFFT部１１６に出力する。
FFT部１１６は、受信部１１５から入力される上りリンク信号波形に対して、時間領域信号を周波数領域信号に変換するFFT処理を施す。FFT部１１６は、FFT処理により得られた周波数領域信号を抽出部１１７へ出力する。
抽出部１１７は、制御部１０１から入力される情報に基づいて、FFT部１１６から入力される信号から、RACH preambleが送信された無線リソース部分、UCIが送信された無線リソース部分、又は、Message Aのデータが送信された無線リソース部分を抽出する。抽出部１１７は、抽出したRACH preambleが送信された無線リソース部分を検出部１１８へ出力し、抽出したUCIが送信された無線リソース部分又はMessage Aのデータが送信された無線リソース部分を復調部１１９へ出力する。
検出部１１８は、抽出部１１７から入力される、RACH preambleに対応する無線リソース部分に対して、RACH preamble検出を行う。検出部１１８は、RACH preambleの検出結果に関する情報を制御部１０１へ出力する。
復調部１１９は、制御部１０１から入力される情報に基づいて、抽出部１１７から入力される、UCIに対応する無線リソース部分又はMessageAのデータに対応する無線リソース部分を復調し、復調結果（復調系列）を復号部１２０へ出力する。
復号部１２０は、制御部１０１から入力される情報に基づいて、復調部１１９から入力される復調結果に対して誤り訂正復号を行い、復号後のビット系列（例えば、UCI、C-Planeデータ又はUPデータを含む）を出力する。例えば、復号部１２０は、得られたUCIを制御部１０１へ出力する。
［端末の構成］
図５は、本開示の実施の形態に係る端末２００の構成例を示すブロック図である。図５において、端末２００は、アンテナ２０１と、受信部２０２と、FFT部２０３と、抽出部２０４と、復調部２０５と、復号部２０６と、下り制御信号復調部２０７と、復号部２０８と、制御部２０９と、RACH preamble生成部２１０と、符号化部２１１と、変調部２１２と、符号化部２１３と、変調部２１４と、信号割当部２１５と、IFFT部２１６と、送信部２１７と、を有する。
受信部２０２は、アンテナ２０１を介して受信された基地局１００からの下りリンク信号の信号波形に対して、ダウンコンバート又はA/D（Analog-to-Digital）変換などのRF処理を行い、得られる受信信号（ベースバンド信号）をFFT部２０３に出力する。下りリンク信号には、例えば、データ信号（例えば、Message B等）、上位制御信号、又は下り制御信号が含まれる。
FFT部２０３は、受信部２０２から入力される信号（時間領域信号）に対して、時間領域信号を周波数領域信号に変換するFFT処理を施す。FFT部２０３は、FFT処理により得られた周波数領域信号を抽出部２０４へ出力する。
抽出部２０４は、制御部２０９から入力される制御情報（例えば、制御信号の無線リソースに関する情報）に基づいて、FFT部２０３から入力される信号から、データ信号（例えば、Message B等）、下り制御信号、又は、上位制御信号を抽出する。抽出部２０４は、データ信号又は上位制御信号を復調部２０５へ出力し、下り制御信号を下り制御信号復調部２０７へ出力する。
復調部２０５は、抽出部２０４から入力されるデータ信号又は上位制御信号を復調し、復調結果を復号部２０６へ出力する。
復号部２０６は、復調部２０５から入力される復調結果を用いて誤り訂正復号を行い、受信データ（例えば、Message B）又は制御情報を得る。復号部２０６は、得られた受信データ又は制御情報を制御部２０９に出力する。
下り制御信号復調部２０７は、抽出部２０４から入力される下り制御信号を復調し、復調結果を復号部２０８へ出力する。
復号部２０８は、下り制御信号復調部２０７から入力される復調結果を用いて誤り訂正復号を行い、制御情報を得る。復号部２０８は、得られた制御情報を制御部２０９に出力する。
制御部２０９は、復号部２０６又は復号部２０８から入力される制御情報に基づいて、上りリンク送信（例えば、Message Aの送信）における送信方法又はパラメータ（例えば、MCS又は無線リソース等）を決定する。例えば、制御部２０９は、Message Aのデータ部分の送信に関するパラメータ（例えば、TBS等）を動的に決定（又は選択）する。制御部２０９は、決定した情報を、RACH preamble生成部２１０、符号化部２１１，２１３、変調部２１２，２１４及び信号割当部２１５へ出力する。
また、制御部２０９は、復号部２０６又は復号部２０８から入力される制御情報に含まれる、制御信号の無線リソースに関する情報を、抽出部２０４に出力する。
RACH preamble生成部２１０は、制御部２０９から入力される制御情報に基づいて、RACH preambleを生成し、生成したRACH preambleを信号割当部２１５へ出力する。
符号化部２１１は、UCIを基地局１００へ送信する場合、制御部２０９から入力される情報に基づいて、UCI（例えば、UCI系列）を誤り訂正符号化し、符号化後のUCI（ビット系列）を変調部２１２へ出力する。
変調部２１２は、制御部２０９から入力される情報に基づいて、符号化部２１１から入力されるUCIを変調して、変調後のUCI（変調シンボル列）を信号割当部２１５へ出力する。
符号化部２１３は、制御部２０９から入力される情報に基づいて、例えば、MessageAのデータ部分において送信される情報ビット系列（例えば、UPデータ）を誤り訂正符号化し、符号化後のビット系列を変調部２１４へ出力する。
変調部２１４は、制御部２０９から入力される情報に基づいて、符号化部２１３から入力されるビット系列を変調して、データ信号（変調シンボル列）を信号割当部２１５へ出力する。
信号割当部２１５は、RACH preamble生成部２１０から入力される信号、変調部２１２から入力される信号、又は、変調部２１４から入力される信号を、制御部２０９から指示される無線リソースにマッピングし、信号がマッピングされた上りリンク信号をIFFT部２１６へ出力する。
IFFT部２１６は、信号割当部２１５から入力される信号に対して、OFDM等の送信波形生成処理を施す。IFFT部２１６は、CP（Cyclic Prefix）を付加するOFDM伝送の場合には、CPを付加する（図示せず）。または、IFFT部２１６がシングルキャリア波形を生成する場合には、信号割当部２１５の前段にDFT（Discrete Fourier Transform）部が追加されてもよい（図示せず）。IFFT部２１６は、生成した送信波形を送信部２１７へ出力する。
送信部２１７は、IFFT部２１６から入力される信号に対してD/A変換、アップコンバート等のRF処理を行い、アンテナ２０１を介して基地局１００に無線信号を送信する。
［基地局１００及び端末２００の動作例］
以上の構成を有する基地局１００及び端末２００における動作例について説明する。
なお、以下では、Message Aのデータ部分のTBSが大きいほど、当該データ部分の送信に要するリソース量が多くなることを想定する。
図６は、本実施の形態に係る基地局１００及び端末２００における処理のフローの一例を示す。
本実施の形態では、Message Aのデータ部分のTBSに関する情報は、Message AのRACH preambleリソース候補（例えば、時間リソース、周波数リソース、及び、系列リソースの組み合わせにより規定されるリソース)群と対応付けられる。
基地局１００は、例えば、RACH preambleリソース群とMessage Aの送信パラメータ（例えば、TBS）との対応付けに関する情報を生成し、当該情報を端末２００へ通知する（ＳＴ１０１）。RACH preambleリソース群とMessage Aの送信パラメータとの対応付けに関する情報は、例えば、上位レイヤ信号によって基地局１００から端末２００へ通知されてよい。
端末２００は、基地局１００から通知された、RACH preambleリソース群とMessage Aの送信パラメータとの対応付けに関する情報を取得する（ＳＴ１０２）。これにより、RACH preambleリソース群とMessage Aの送信パラメータとの対応付けに関する情報は、基地局１００と端末２００との間で共有される。
図７は、TBSと、RACH preambleリソース候補群（RACH preamble resource (set)）との対応付けの一例を示す。
図７では、TBS=X1がRACH preambleリソース候補群Z1に対応付けられ、TBS=X2がRACH preambleリソース候補群Z2に対応付けられ、TBS=X3がRACH preambleリソース候補群Z3に対応付けられている。なお、RACH preambleリソース群に対応付けられるTBSの候補は、３個に限らず、２個又は４個以上でもよい。
端末２００は、送信パケット（換言すると、上りリンク信号）が発生すると、Message Aのデータ部分のTBSを決定する（ＳＴ１０３）。端末２００が選択できるTBSには、例えば、規格上、複数のTBSが予め規定されてもよく、基地局１００が上位レイヤ信号（例えば、SIB（System Information Block）又は端末固有のRRC信号）によってTBSが設定されてもよい。例えば、端末２００は、規定又は設定されたTBSの中から、Message Aのデータ部分のTBSを動的に決定する。
図６において、端末２００は、送信するRACH preambleを決定する（ＳＴ１０４）。例えば、端末２００は、TBSとRACH preambleリソース候補群との対応付けに基づいて、選択したTBSに対応付けられたRACH preambleリソース候補群から、実施に用いるRACH preambleリソースを選択する。例えば、図７において、端末２００は、TBS=X2を選択した場合、TBS=X2に対応付けられたRACH preambleリソース候補群Z2の中から、RACH preambleの送信に用いるRACH preambleリソースを選択する。図７において他のTBSが選択された場合についても同様である。
図６において、端末２００は、Message Aを生成する（ＳＴ１０５）。例えば、端末２００は、選択したTBSを用いて生成されるMessage Aのデータ部分の信号（例えば、C-Planeデータ及びUPデータの少なくとも一つ）と、選択したRACH preambleリソースを用いて生成されるRACH preambleと、を含むMessage Aを生成する。
端末２００は、生成したMessage Aを基地局１００へ送信する（ＳＴ１０６）。
基地局１００は、端末２００から送信されるMessage Aに含まれるRACH preambleを検出する（ＳＴ１０７）。基地局１００は、RACH preambleを検出した場合、TBSとRACH preambleリソース群との対応付け（例えば、図７を参照）に基づいて、検出したRACH preambleに対応するRACH preambleリソースから、端末２００から送信されるMessage Aのデータ部分のTBSを特定する。
基地局１００は、特定したTBSを用いて、検出したRACH preambleに対応するMessage Aのデータ部分を復調及び復号する（ＳＴ１０８）。
基地局１００は、Message Aの受信処理（例えば、RACH preambleの検出、及び、データ部分の復調及び復号）の後、Message Bを生成し（ＳＴ１０９）、生成したMessage Bを端末２００へ送信する（ＳＴ１１０）。
なお、本実施の形態では、Message Aの送信パラメータの一例として、Message Aのデータ部分のTBSを用いる場合について説明したが、Message Aの送信パラメータは、TBSに限らず、他のパラメータでもよい。例えば、Message Aのデータ部分のリソース情報（例えば、リソース位置及びリソース量の少なくとも一つ）と、Message AのRACH preambleリソース候補群とが対応付けられてもよい。この場合、基地局１００は、RACH preambleを検出した場合、検出したRACH preambleリソースから、端末２００がMessage Aのデータ部分の送信に用いたリソース位置又はリソース量を特定できる。また、基地局１００は、例えば、特定したデータ部分のリソース位置及びリソース量を用いて、データ部分に使用されたTBSを算出し、検出したRACH preambleに対応するMessage Aのデータ部分を復調及び復号してもよい。
このように、本実施の形態では、端末２００は、RACH preamble及びデータ部分を含むMessage A（換言すると、ランダムアクセス信号）のうち、データ部分の送信に関するパラメータ（送信パラメータ）を動的に決定する。これにより、端末２００は、発生した送信パケットに応じて、Message Aのデータ部分において用いる送信パラメータ（例えば、TBS、リソース位置又はリソース量）を適切に選択できる。
また、本実施の形態では、端末２００は、Message Aを用いて、決定された送信パラメータを基地局１００へ通知する。例えば、本実施の形態では、端末２００は、送信パラメータ（例えば、TBS）の候補と、RACH preambleリソース候補群との対応付けに基づいて、動的に決定した送信パラメータに対応付けられるRACH preambleリソース候補群の中のRACH preambleリソースを用いて、RACH preambleを送信する。
このように、本実施の形態では、Message AにおいてRACH preambleの送信に使用されるRACH preambleリソースによって、Message Aのデータ部分のTBSが、端末２００から基地局１００へ黙示的に通知される。例えば、基地局１００は、検出したRACH preambleの送信に使用されたRACH preambleリソースに基づいて、Message Aのデータ部分に用いられるTBSを黙示的に特定できる。
これにより、基地局１００は、端末２００において動的に決定されるTBSに応じて、Message Aを正しく復調及び復号できる可能性が高くなる。また、端末２００から基地局１００へのMessage Aの送信パラメータの明示的な通知が不要であるので、オーバヘッドを削減できる。
よって、本実施の形態によれば、例えば、2ステップRandom access procedureにおける上りリンク送信の効率を向上できる。
［Message A］
次に、2ステップRandom access procedureにおけるMessage Aについて説明する。
Message Aにおいて、RACH preambleとデータ部分とは、例えば、時間分割多重（TDM：Time Division Multiplexing）により構成されてよい。なお、Message AのRACH preambleとデータ部分との多重構成は、TDMに限らず、周波数分割多重（FDM：Frequency Division Multiplexing）でもよく、符号分割多重（CDM：Code Division Multiplexing）でもよい。
また、端末２００がMessage Aのデータ部分において送信するデータには、例えば、RRC接続要求又はスケジューリング要求等のC-planeデータに加えて、UPデータが含まれてよい。また、端末２００がMessage Aのデータ部分において送信するデータには、C-Planeデータが含まれ、UPデータが含まれない場合もある。
例えば、C-planeデータには、初期アクセス時のRRC接続要求（RRCSetupRequest：44 bits）、RRC_IACTIVE状態からRRC_CONNECTED状態へ復帰する場合の要求（RRCResumeRequest：48 bits）、RRC再接続要求（RRCReestablishmentRequest：44 bits又はRRCReestablishmentRequest1：64 bits）、上りリンクデータが発生した時のスケジューリング要求（Short BSR MAC CE + C-RNTI MAC CE：24 bits、又は、Long BSR MAC CE + C-RNTI MAC CE：32 bits以上）、及び、オンデマンドSI要求（RRCSystemInforRequest）等がある。なお、上述したC-Planeデータのビット数はRelease 15 NRにおける各C-planeデータのビット数であり、ビット数はこの限りではない。
また、C-planeデータには、例えば、UE-IDが含まれてよい。Message Aに含まれるUE-IDは、RRC接続要求時のS-TMSI（SAE Temporary Mobile Subscriber Identity）、ランダムなビット系列、RRC_CONNECTED状態時のC-RNTI、及び、RRC_IACTIVE状態時のResumeID等がある。
また、UE-IDは、他のC-plane情報と合わせてMessage Aのデータ部分で送信されてもよく、UCIで送信されてもよい。UE-IDをUCIで送信する場合、後述する実施の形態３〜５におけるTBSの情報を含むUCIにUE-IDを含めてもよい。
［Message B］
次に、2ステップRandom access procedureにおけるMessage Bについて説明する。
Message Bには、例えば、RACH応答（RAR）を含むMAC PDU（Medium Access Control layer Protocol Data Unit）、端末２００を識別するためのUE-IDを含めたメッセージ（例えば、Contention resolution MAC CE）を含むMAC PDU等が含まれる。また、Message Bには、上記MAC PDUの他に、RRC接続、RRC復帰、又は、RRC再接続のためのRRC信号を含むMAC PDUが含まれてよい。
また、RARを含むMAC PDUには、端末２００による上りリンクの送信タイミングに関する情報、TC-RNTI、又は、端末２００が上りリンクで使用するリソースに関する情報が含まれてよい。
上りリンクで使用するリソースに関する情報は、Random access procedureが成功した端末２００において、RRC信号を含むMAC PDUを含めてMessage Bが送信された場合に、RRC接続、RRC復帰及びRRC再接続の完了のためのメッセージを基地局１００へ送信するために使用できる。また、上りリンクで使用するリソースに関する情報は、4ステップRACH procedure へフォールバックする端末２００において、Message 3を送信するために使用できる。
4ステップRandom access procedureでは、Message 3送信のための上りリンクで使用されるリソースに関する情報、及び、Message 4受信のための情報（例えば、TC-RNTI）を、Message 2（RAR）に含める必要がある。これに対して、2ステップRandom access procedureでは、必ずしもこれらの動作が必要ではないので、上りリンクで使用するリソースに関する情報及びTC-RNTIは、Message B（例えば、RAR）に含まれなくてよい。この場合、Message B（RAR）にこれらの情報が含まれているか否か（換言すると、RARのフォーマット）は、Message BにRRC信号を含むMAC PDUが含まれているか否かに応じて端末２００が識別してもよく、MACヘッダの１ビットを用いて端末２００が識別してもよい。
端末２００は、Message Aにおいて送信したUE-IDに基づいて、Message Bを受信する。このとき、Message Bをスケジューリングするための下り制御チャネル（例えば、PDCCH：Physical Downlink Control Channel）は、全ての端末共通のRA-RNTI又は端末固有のC-RNTIによりスクランブルされてよい。
例えば、端末２００がRRC_IDLE状態又はRRC_INACTIVE状態の場合、端末２００は、全端末共通のRA-RNTIでスクランブルされたPDCCHを受信する。このとき、Message BのRARには少なくとも上りリンクの送信タイミングに関する情報が含まれる。Message BにRRC信号を含むMAC PDUが含まれていない場合、RARにはTC-RNTIが含まれる。一方、Message BにRRC信号を含むMAC PDUが含まれている場合、TC-RNTIは必要ない。また、Message Bには、端末２００を識別するためのUE-IDを含めたメッセージ（例えば、Contention resolution MAC CE）を含むMAC PDUが含まれる。
端末２００がRRC_CONNECTED状態の場合、端末２００は、端末固有のC-RNTIでスクランブルされたPDCCHを受信する。このとき、Message BのRARには少なくとも上りリンクの送信タイミングに関する情報及び上りリンクで使用するリソースに関する情報が含まれる。
Message Bに、RRC信号を含むMAC PDUが含まれている場合、RRC信号は比較的大きなデータ量で構成される。そのため、Message Bの送信に対してHARQ（Hybrid Automatic Repeat Request）を適用することで下りリンクリソースの利用効率を向上できる。
一方、Message BにHARQを適用しない場合、又は、HARQを適用するもののMessage Bの構成をHARQに最適化しない場合、Message Bはグループキャスト送信されてよい。この場合のMessage Bの構成例を図８及び図９に示す。図８は、Message Bにおいて、RRC信号を含むMAC PDUを含まない場合の例を示し、図９は、Message Bにおいて、RRC信号を含むMAC PDUを含む例を示す。
［2ステップRandom access procedure］
次に、2ステップRandom access procedureにおけるMessage A送信後の動作例について説明する。
以下、動作例１及び動作例２について説明する。
［動作例１］
図１０は、動作例１における2ステップRandom access procedureの一例を示す。
＜Message Aの送信＞
端末２００（図１０では、UE#A、UE#B及びUE#C）は、上述したように、Message Aを送信する。Message Aには、RACH preamble及びデータ部分（又は、UCI+データ部分）が含まれる。また、データ部分又はUCIには、端末２００を識別するためのUE-IDが含まれる。また、端末２００は、RACH preambleの送信タイミングから、Msg.B reception window（又は、RAR reception windowと呼ぶこともある）を動作させる。
＜Message Bの送信＞
基地局１００（図１０では、gNB）は、Message Aを検出及び正しく復号した場合、Message Bを送信する。Message Bには、例えば、RACH応答（RAR又はMAC RARと呼ぶ）及び端末２００を識別するためのUE-IDを含めたメッセージ（例えば、MAC CE）が含まれる。
一方、基地局１００は、Message Aを検出できなかった場合（例えば、RACH preambleを検出できなかった場合）、又は、Message Aを正しく復号できなかった場合（例えば、RACH preambleを検出したものの、データ部分（例えば、PUSCH）を正しく復号できなかった場合)、当該Message Aを送信した端末２００宛の情報をMessage Bに含めない。
例えば、図１０では、基地局１００（gNB）は、UE#Aから送信されたMessage Aを検出し、正しく復号する（Preamble:○、PUSCH：○）。そこで、基地局１００は、UE#Aに対するRACH応答及びUE#AのUE-IDを、Message Bに含める。
一方、図１０では、基地局１００（gNB）は、UE#Bから送信されたMessage Aを検出するものの、Message Aを正しく復号できない（Preamble:○、PUSCH：×）。また、図１０では、基地局１００（gNB）は、UE#Cから送信されたMessage Aを検出できない（Preamble:×、PUSCH：×）。そこで、基地局１００は、UE#B及びUE#Cに対するRACH応答及びUE-IDを、Message Bに含めない。
Message Aを送信した端末２００は、Msg.B reception windowの期間内に当該端末２００宛の情報を含むMessage Bを受信しない場合（例えば、図１０ではUE#B及びUE#Cに相当）、Message Aの再送を行う。
一方、Message Aを送信した端末２００は、Msg.B reception windowの期間内に当該端末２００宛の情報を含むMessage Bを受信し、Message Bに含まれるUE-IDがMessage Aで送信したUE-IDと一致している場合（例えば、図１０ではUE#Aに相当）、RACH procedureが成功したと判断する。
［動作例２］
図１１は、動作例２における2ステップRandom access procedureの一例を示す。
＜Message Aの送信＞
端末２００（図１１では、UE#A、UE#B及びUE#C）は、上述したように、Message Aを送信する。Message Aには、RACH preamble及びデータ部分（又は、UCI+データ部分）が含まれる。また、データ部分又はUCIには、端末２００を識別するためのUE-IDが含まれる。また、端末２００は、RACH preambleの送信タイミングから、Msg.B reception windowを動作させる。
＜Message Bの送信＞
基地局１００（図１１では、gNB）は、Message Aを検出及び正しく復号した場合、Message Bを送信する。Message Bには、例えば、RACH応答（RAR又はMAC RARと呼ぶ）及び端末２００を識別するためのUE-IDを含めたメッセージ（例えば、MAC CE）が含まれる。例えば、図１１では、基地局１００は、UE#Aから送信されたMessage Aを検出し、正しく復号する（Preamble:○、PUSCH：○）。そこで、基地局１００は、UE#Aに対するRACH応答及びUE#AのUE-IDを、Message Bに含める。
また、基地局１００は、Message AのRACH preambleを検出し、データ部分を正しく復号できなかった場合もMessage Bを送信する。このとき、Message Bには、RACH応答（RAR又はMAC RARと呼ぶ）が含まれる。なお、RARには、対応するRACH preambleを送信した端末２００に対して、データ部分の再送要求、及び、上りリンクで使用するリソースに関する情報が含まれている。ただし、基地局１００は、RACH preambleを検出し、データ部分を正しく復号できない場合、この時点では、RACH preambleを送信した端末２００を特定できない。よって、Message Bには、対応する端末２００を識別するためのUE-IDを含めたメッセージは含まれない。基地局１００においてRACH preambleが検出され、データ部分を正しく復号されなかった端末２００は、例えば、4ステップRACH procedureにフォールバックされる。
例えば、図１１では、基地局１００は、UE#Bから送信されたMessage Aを検出するものの、Message Aを正しく復号できない（Preamble:○、PUSCH：×）。そこで、基地局１００は、UE#Bに対するRACH応答を、Message Bに含める一方、UE#Bに対するUE-IDをMessage Bに含めない。
また、基地局１００は、Message Aを検出できなかった場合（例えば、RACH preambleを検出できなかった場合）、当該Message Aを送信した端末２００宛の情報をMessage Bに含めない。例えば、図１０では、基地局１００は、UE#Cから送信されたMessage Aを検出できない（Preamble:×、PUSCH：×）。そこで、基地局１００は、UE#Cに対するRACH応答及びUE#CのUE-IDを、Message Bに含めない。
Message Aを送信した端末２００は、Msg.B reception windowの期間内に当該端末２００宛の情報を含むMessage Bを受信しない場合（例えば、図１１ではUE#Cに相当）、Message Aの再送を行う。
一方、Message Aを送信した端末２００は、Msg.B reception windowの期間内に当該端末２００宛の情報を含むMessage Bを受信したものの、Message Bに含まれるUE-IDがMessage Aで送信したUE-IDと一致していない場合（例えば、図１１ではUE#Bに相当）、対応するMessage B内のRARに含まれる情報に従って、4ステップRACH procedure のMessage 3に相当する上りリンク送信を行う。換言すると、UE#Bは、4ステップRandom access procedureにフォールバックされる。
また、Message Aを送信した端末２００は、Msg.B reception windowの期間内に当該端末２００宛の情報を含むMessage Bを受信し、Message Bに含まれるUE-IDがMessage Aで送信したUE-IDと一致している場合（例えば、図１１ではUE#Aに相当）、RACH procedureが成功したと判断する。
以上、２ステップRandom access procedureにおけるMessage A送信後の動作例について説明した。
なお、動作例１及び動作例２において、Msg.B reception windowに設定する期間は、例えば、サービス又はトラフィックの種類によって異ならせてもよい。例えば、遅延要求が厳しくないeMBB又はmMTCでは、Msg.B reception windowに設定する期間を長くし、遅延要求が厳しいURLLCでは、Msg.B reception windowに設定する期間を短くしてもよい。
また、動作例１及び動作例２において、Message Bには、再送時の待ち時間を指定する情報（Back-off）が含まれてもよい。例えば、端末２００は、Message Bに当該端末２００宛の情報（例えば、RAR又はUE-ID）が含まれない場合でも、再送時の待ち時間を指定する情報に基づいて、Message Aの再送を制御できる。このとき、例えば、遅延要求が厳しい端末２００（例えば、URLLC端末）は、再送時に、基地局１００が指定するBack-offを用いるのではなく、指定されるback-offをより短く(又は0に)設定して、Message Aの再送を開始してもよい。
（実施の形態２）
本実施の形態に係る基地局及び端末は、実施の形態１に係る基地局１００及び端末２００と基本構成が共通するので、図４及び図５を援用して説明する。
実施の形態１では、Message Aのデータ部分のTBS（換言すると、１つの送信パラメータ）と、Message AのRACH preambleリソース候補群とが対応付けられる場合について説明した。これに対して、本実施の形態では、Message Aのデータ部分の複数の送信パラメータと、Message AのRACH preambleリソース群とが対応付けられる場合について説明する。
Message Aのデータ部分の複数の送信パラメータは、例えば、TBS、及び、リソース情報（例えば、リソース位置及びリソース量の少なくとも一つ）が含まれてよい。なお、送信パラメータは、TBS、及び、リソース情報に限らず、他のパラメータ（一例は後述する）でもよい。
例えば、基地局１００は、Message A のデータ部分のTBS及びリソース情報と、RACH preambleリソース候補群との対応付けに関して、上位レイヤ信号を用いて、複数の組み合わせを端末２００へ通知する（例えば、図６のＳＴ１０１に対応）。上位レイヤ信号は、例えば、セル又はグループ固有の報知情報（例えば、SIB）でもよく、端末固有のRRC信号でもよい。
端末２００は、Message Aのデータ部分のTBSを、基地局１００から設定された複数のTBSの中から選択する。端末２００は、例えば、実際に送信するデータ部分のデータ量（例えば、Buffer value）に基づいて、MessageAのデータ部分のTBSを選択してもよい。このとき、TBS選択の基準に用いるBuffer valueは、例えば、UPデータ量でもよく、RRC接続要求又はスケジューリング要求等のC-planeデータとUPデータの合計のデータ量でもよい。
また、Buffer valueに基づいてTBSを選択する方法では、ゼロパディング量が少なくなるTBSが選択されてもよい。これにより、Message Aのデータ部分におけるリソースの使用効率を向上できる。
また、端末２００は、選択したTBSに対応付けられたRACH preambleリソース候補群から、実際に用いるRACH preambleリソースを選択する。また、端末２００は、選択したTBSに対応付けられた、Message Aのデータ部分のリソース情報（例えば、リソース位置及びリソース量の少なくとも一つ）を特定する。
図１２は、TBS及びデータ部分のリソース情報（例えば、時間リソース及び周波数リソースのリソース位置及びリソース量）と、RACH preambleリソース候補群との対応付けの一例を示す。
また、図１２では、端末２００におけるMessage Aのデータ部分におけるデータ量（例えば、Buffer value）に基づいてTBSを選択する方法に関する対応付けについても一例として示す。
図１２では、TBS=X1と、RACH preambleリソース候補群Z1と、データ部分のリソース情報Resource 1とが対応付けられ、TBS=X2と、RACH preambleリソース候補群Z2と、データ部分のリソース情報Resource 2とが対応付けられ、TBS=X3と、RACH preambleリソース候補群Z3と、データ部分のリソース情報Resource 3とが対応付けられている。なお、RACH preambleリソース群に対応付けられるTBS及びリソース情報の候補は、３個に限らず、２個又は４個以上でもよい。
例えば、図１２では、端末２００は、Buffer valueがY1以下の場合、TBS=X1（及び、RACH preambleリソース候補群Z1、Resource 1）を選択し、Buffer valueがY2以下の場合、TBS=X2（及び、RACH preambleリソース候補群Z2、Resource 2）を選択し、Buffer valueがY3以下の場合、TBS=X3（及び、RACH preambleリソース候補群Z3、Resource 3）を選択する。
端末２００は、選択したTBS及びリソース情報を用いて生成されるMessage Aのデータ部分の信号（例えば、C-Planeデータ及びUPデータの少なくとも一つ）と、選択したRACH preambleリソースを用いて生成されるRACH preambleと、を含むMessage Aを生成する。端末２００は、生成したMessage Aを基地局１００へ送信する。
なお、Message AのRACH preambleとデータ部分とは、例えば、TDM、FDM又はCDMにより構成されてよい。また、端末２００がMessage Aのデータ部分において送信するデータには、例えば、RRC接続要求又はスケジューリング要求等のC-planeデータに加えて、UPデータが含まれてよい。または、端末２００がMessage Aのデータ部分において送信するデータには、例えば、C-Planeデータが含まれ、UPデータが含まれない場合もある。
基地局１００は、端末２００から送信されるMessage Aに含まれるRACH preambleを検出した場合、MessageAの送信パラメータ（例えば、TBS及びリソース情報）とRACH preambleリソース群との対応付けに基づいて、検出したRACH preambleに対応するRACH preambleリソースから、端末２００から送信されるMessage Aのデータ部分のTBS及びリソース情報を特定する。
基地局１００は、特定したTBS及びリソース情報を用いて、検出したRACH preambleに対応するMessage Aのデータ部分を復調及び復号する。そして、例えば、基地局１００は、Message Aの受信処理後、Message Bを端末２００へ送信する。
このように、本実施の形態では、端末２００は、RACH preamble及びデータ部分を含むMessage Aのうち、データ部分の送信に関するパラメータ（送信パラメータ）を動的に決定する。これにより、端末２００は、発生した送信パケットに応じて、Message Aのデータ部分において用いる送信パラメータ（例えば、TBS及びリソース情報）を適切に選択できる。
また、本実施の形態では、実施の形態１と同様、端末２００は、Message Aを用いて、決定された送信パラメータを基地局１００へ通知する。例えば、本実施の形態では、端末２００は、送信パラメータ（例えば、TBS及びリソース情報）の候補と、RACH preambleリソース候補群との対応付けに基づいて、動的に決定した送信パラメータに対応付けられるRACH preambleリソース候補群の中のRACH preambleリソースを用いて、RACH preambleを送信する。
これにより、例えば、基地局１００は、検出したRACH preambleの送信に使用されたRACH preambleリソースに基づいて、Message Aのデータ部分に用いられるTBS及びリソース情報を黙示的に特定できる。よって、基地局１００は、端末２００において動的に決定される送信パラメータ（例えば、TBS及びリソース情報）に応じて、Message Aを正しく復調及び復号できる可能性が高くなる。また、端末２００から基地局１００へのMessage Aの送信パラメータの明示的な通知が不要であるので、オーバヘッドを削減できる。
また、本実施の形態では、基地局１００が、Message Aの複数の送信パラメータ（例えば、データ部分のTBS及びリソース情報）と、RACH preambleリソース候補群との対応付けを設定できる。これにより、例えば、contentionベースのRACHの場合、基地局１００は、例えば、システムが利用可能な帯域幅、又は、セル内のトラフィック状況等に応じて上記対応付けを設定することにより、RACH preambleリソース又はデータ部分のリソースの衝突確率を容易に制御できる。
なお、本実施の形態におけるRACH preambleリソース候補群と、送信パラメータ（例えば、TBS及びリソース情報）との対応付けは、送信パラメータの全ての情報がRACH preambleリソース候補群と対応付けられてもよく、一部の情報がRACH preambleリソース群と対応付けられてもよい。
［バリエーション１］
実施の形態２において、RACH preambleリソース候補群に対応付けられる送信パラメータは、TBS、及び、データ部分のリソース情報に限定されない。Message Aの送信に関するその他のパラメータが、RACH preambleリソース候補群と対応付けられてよい。
以下、バリエーション１においてRACH preambleリソース候補群と対応付けられる他のパラメータの例について説明する。
＜Message Aのデータ部分のMCSとの対応付け＞
一般に、基地局１００と端末２００との間の伝搬ロス（Path loss）が閾値以上の場合と、閾値未満の場合とでは、選択可能なRACH preambleリソース候補は異なる。
例えば、端末２００は、下りリンク信号又は下りリンクチャネルを用いて、基地局１００と端末２００との間のPath lossを測定する。そして、端末２００は、測定したPath lossに対応付けられたRACH preambleリソース候補群から、実際に用いるRACH preambleリソースを選択してよい。
また、端末２００は、選択したRACH preambleリソース候補群（換言すると、Path loss）に対応付けられた、Message Aのデータ部分のMCSを選択する。例えば、Path lossが閾値以上の場合、端末２００は、低いMCSをMessage Aのデータ部分に用いる。一方、Path lossが閾値未満の場合、端末２００は、高いMCSをMessage Aのデータ部分に用いる。これにより、端末２００は、伝搬路の状況に応じてMessage Aの伝送品質を適切に制御でき、Message Aの送信効率を向上できる。
さらに、上述したPath loss及びMCSに対応付けられたRACH preambleリソース候補群は、TBS又はデータ部分のリソース情報（例えば、リソース位置及びリソース量の少なくとも一つ）に対応付けられた部分グループにそれぞれ対応付けられてよい。
例えば、図１３は、TBSとRACH preambleリソース候補群との対応付け（また、端末２００のBuffer valueに基づいたTBS選択も含む）により、Path loss及びMCSに関連付けられたRACH preambleリソース候補群を部分グループ化した場合の一例を示す。図１３では、RACH preambleリソース群は、Path lossが閾値Thより大きい場合（MCS A1）のグループと、Path lossが閾値Th以下の場合（MCS A2）のグループと、にグループ化されている。図１３に示す各グループには、TBS=X1とRACH preambleリソース候補群Z1との組み合わせ、及び、TBS=X2とRACH preambleリソース候補群Z2との組み合わせがそれぞれ含まれる。なお、図１３は一例であって、例えば、データ部分のリソース情報が含まれてもよい。
＜Message Aの送信電力との対応付け＞
例えば、RACH preambleリソース候補群と、Message Aの送信電力とが対応付けられてよい。
例えば、TBSに対応付けられたRACH preambleリソース群に応じてMessage Aの送信電力を異ならせてよい。例えば、TBS=X1に対応付けられたRACH preambleリソース群からRACH preambleを選択する場合、端末２００は、Message Aの送信電力としてP1を設定する。また、TBS=X2に対応付けられたRACH preambleリソース群からRACH preambleを選択する場合、端末２００は、Message Aの送信電力としてP2を設定する。
ここで、TBSが大きいほど高い送信電力が設定される。例えば、X1<X2の場合、P1<P2の関係となる。TBSが大きい送信ほど、再送が発生すると上りリンクリソースの利用効率が低下してしまう。これに対して、上述したRACH preambleリソース群と送信電力との対応付けによって、例えば、TBSが大きい送信について、高い送信電力を設定できるので、再送が頻繁に発生することを防ぐことができ、Message Aの送信効率を向上できる。
なお、RACH preambleリソース候補群と対応付ける送信電力に関するパラメータは、送信電力に限らず、例えば、Message Aの再送毎の電力増加量でもよい。
＜Message Aのデータ部分のRankとの対応付け＞
例えば、RACH preambleリソース候補群と、Message Aのデータ部分の送信ランク数とが対応付けられてよい。
例えば、TBSに対応付けられたRACH preambleリソース群に応じてMessage Aのデータ部分の送信ランク数を異ならせてよい。これにより、例えば、Message A送信にMIMO（Multi-input Multi-output）空間多重伝送を適用できるので、Message Aの送信効率を向上できる。
［バリエーション２］
実施の形態２におけるRACH preambleリソース候補群に対応付けられているTBSは、端末２００が送信可能（又は設定可能）な最大のTBSでもよい。
また、例えば、図１４に示すように、RACH preambleリソース候補群に、最大のTBS以下の複数のTBS（例えば、allowable TBS）が対応付けられてもよい。この場合、端末２００は、例えば、実際に送信するUPデータ量（例えば、Buffer value）に基づいてTBSを選択してもよい。
なお、TBS選択に用いるBuffer valueは、UPデータ量でもよく、RRC接続要求又はスケジューリング要求等のC-planeデータとUPデータとのデータ量の合計でもよい。また、Buffer valueからTBSを選択する方法として、ゼロパディング量が最も少なくなるTBSを選択してもよい。これにより、RACHリソースを効率的に設定しつつ、より柔軟に様々なUPデータ量の送信に対応できる。
また、基地局１００は、RACH preambleを検出した場合、検出したRACH preambleに対応するRACH preambleリソースから、端末２００がMessage Aの送信に用いる可能性のある最大のTBS、又は、最大のTBS以下の複数のTBS候補を特定する。例えば、基地局１００は、特定した複数のTBS候補に対してブラインド復号を行い、Message Aのデータ部分を復調及び復号する。
［バリエーション３］
実施の形態２におけるRACH preambleリソース候補群に含まれるRACH preambleリソースの数は、RACH preambleリソース候補群毎に異なってもよい。
例えば、図１５に示すように、TBS=X1に対応付けられたRACH preambleリソース候補群Z1に含まれるRACH preambleリソース数をN1に設定し、TBS=X2に対応付けられたRACH preambleリソース候補群Z2に含まれるRACH preambleリソース数をN2に設定し、TBS=X3に対応付けられたRACH preambleリソース候補群Z3に含まれるRACH preambleリソース数をN3に設定してよい。
図１５では、X1<X2<X3であり、かつ、N1<N2<N3である。つまり、TBSが大きいほど、RACH preambleリソース候補群に含まれるRACH preambleリソースの数が多く設定される。RACH preamble候補群に含まれるRACH preambleリソースの数が多いほど、RACH preambleの衝突確率を低減できる。TBSが大きい送信ほど、再送が発生すると上りリンクリソースの利用効率が低下してしまう。これに対して、図１５では、例えば、TBSが大きい送信に対して、RACH preambleリソースの数が多く設定され、再送が頻繁に発生することを防止できるので、Message Aの送信効率を向上できる。
なお、セル内に含まれる端末のトラフィック状況によっては、大量のUPデータを送信する端末が少なく、少量のUPデータを送信する端末の方が多い可能性もある。そのため、TBSが小さいほど、RACH preambleリソース候補群に含まれるRACH preambleリソースの数を少なく設定してもよい。
［バリエーション４］
NRにおける同期信号は、例えば、PSS（Primary Synchronization Signal）及びSSS（Secondary Synchronozation）の２つの信号から構成される（例えば、非特許文献１を参照）。特に、6GHz以上の高周波数帯では、基地局と端末との間の通信可能距離及びエリアを確保するために、例えば、基地局側で送信ビームフォーミングを適用することが考えられる。
また、NRでは、同期信号及び報知チャネル（PBCH：Physical Broadcast Channel）を１つの単位（例えば、SS/PBCHブロックと呼ぶ）として定義される。１つのSS/PBCHブロックは、同一方向の送信ビームで送信され、順次ビームを切り替えて送信される構成（beam sweeping）がサポートされている。ただし、低周波数帯等のために、beam sweepingを適用せず、単一のビームパターンで１つのSS/PBCHブロックを送信する構成も可能である。
SS/PBCHブロックにビームフォーミングを適用する場合には、そのSS/PBCHブロックを受信した端末からのRACHを受信するために同等の受信ビームフォーミングを基地局側で適用する。このため、端末は、検出したSS/PBCHブロックに紐づけられているRACH preambleリソースでRACHを送信する（例えば、非特許文献６を参照）。また、チャネル状態想定用参照信号（CSI-RS：Channel State Information Reference Signal）を用いた測定が端末に設定され、CSI-RSとRACH preambleリソースとが対応付けられることもある（例えば、非特許文献６を参照）。
バリエーション４において、端末２００は、例えば、SS/PBCHブロック又はCSI-RSを用いて受信品質（例えば、SS-RSRP（Reference Signal Received Power）又はCSI-RSRPと呼ぶ)を測定する。そして、端末２００は、SS-RSRP又はCSI-RSRPが閾値以上のSS/PBCHブロック又はCSI-RSが１つ以上ある場合、その中から１つのSS/PBCHブロック又はCSI-RSを選択し、そのSS/PBCHブロック又はCSI-RSに対応付けられるRACH preambleリソース候補群からRACH preambleを選択する。なお、SS-RSRP又はCSI-RSRPが閾値以上のSS/PBCHブロック又はCSI-RSが無い場合、端末２００は、何れかのSS-RSRP又はCSI-RSRPに対応するSS/PBCH又はCSI-RSを選択してよい。
このとき、端末２００は、TBS（換言すると、Message Aのデータ部分の送信パラメータ）に応じてSS/PBCHブロック又はCSI-RSを選択してよい。例えば、端末２００は、TBSに応じてSS-RSRP又はCSI-RSRPの閾値を異ならせてよい。例えば、端末２００は、TBSが大きいほどSS-RSRP又はCSI-RSRPの閾値を高く設定する。この場合、端末２００は、TBSが大きい送信について、より高品質のビームパターンを選択できる。よって、再送が発生すると上りリンクリソースの利用効率が低下してしまうTBSが大きい送信に対して、再送が頻繁に発生することを防止できるので、Message Aの送信効率を向上できる。
（実施の形態３）
本実施の形態に係る基地局及び端末は、実施の形態１に係る基地局１００及び端末２００と基本構成が共通するので、図４及び図５を援用して説明する。
本実施の形態では、端末２００は、Message Aのデータ部分のTBSに関する情報をUCIに含めて、2ステップRandom access procedure時に基地局１００へ通知する。
図１６は、本実施の形態に係る基地局１００及び端末２００における処理のフローの一例を示す。
なお、本実施の形態では、基地局１００は、例えば、Message Aのデータ部分の送信パラメータ（例えば、TBS又はリソース情報）とUCIビットフィールドとの対応付け（例えば、後述する図１７を参照）について、例えば、上位レイヤ信号を用いて、複数の組み合わせを端末２００へ通知してよい。上位レイヤ信号は、例えば、セル又はグループ固有の報知情報（例えば、SIB）又は端末固有のRRC信号である。
端末２００は、送信パケット（換言すると、上りリンク信号）が発生すると、Message Aのデータ部分のTBSを決定する（ＳＴ２０１）。端末２００が選択できるTBSには、例えば、規格上、複数のTBSが予め規定されてもよく、基地局１００が上位レイヤ信号（例えば、SIB又は端末固有のRRC信号）によってTBSが設定されてもよい。例えば、端末２００は、規定又は設定されたTBSの中から、Message Aのデータ部分のTBSを動的に決定する。
端末２００は、送信するRACH preambleを決定する（ＳＴ２０２）。例えば、端末２００は、複数のRACH preambleリソース候補群から、実際に用いるRACH preambleリソース候補群を選択し、選択したRACH preambleリソース候補群の中からMessage Aに用いるRACH preambleを選択する。なお、RACH preambleリソース候補群の選択は、例えば、基地局１００と端末２００との間のPath lossに基づく選択、又は、SS/PBCHブロック又はCSI-RSに基づく選択を適用してもよく、これらの選択方法に限定されない。
端末２００は、Message Aに含めるUCIの値（例えば、インデックス）を決定する（ＳＴ２０３）。例えば、端末２００は、Message Aのデータ部分のTBSに関する情報に対応付けられたインデックスを含むUCIを生成する。
図１７は、TBSとUCIビットフィールドとの対応付けの一例を示す。図１７では、例えば、TBS=X1が選択された場合、UCIビットフィールドにインデックス1が設定され、TBS=X2が選択された場合、UCIビットフィールドにインデックス2が設定され、TBS=X3が選択された場合、UCIビットフィールドにインデックス3が設定される。なお、設定されるTBSの数は、３個に限らず、例えば、２個又は４個以上でもよい。
図１６において、端末２００は、Message Aを生成する（ＳＴ２０４）。例えば、端末２００は、選択したTBSを用いてMessage Aのデータ部分を生成する。また、端末２００は、Message Aのデータ部分に、TBSに関する情報に対応するインデックスを含むUCIを多重する。また、例えば、端末２００は、選択したRACH preambleリソースを用いて、Message AのRACH preambleを生成する。
端末２００は、生成したMessage Aを基地局１００へ送信する（ＳＴ２０５）。
また、端末２００がMessage Aのデータ部分において送信するデータには、例えば、RRC接続要求又はスケジューリング要求等のC-planeデータに加えて、UPデータが含まれてよい。また、端末２００がMessage Aのデータ部分において送信するデータには、C-Planeデータが含まれ、UPデータが含まれない場合もある。
基地局１００は、端末２００から送信されるMessage Aに含まれるUCIを復調及び復号することにより、端末２００がMessage Aの送信に用いたTBSを特定する（ＳＴ２０６）。
基地局１００は、特定したTBSを用いて、Message Aのデータ部分を復調及び復号する（ＳＴ２０７）。
基地局１００は、Message Aの受信処理後、Message Bを生成し（ＳＴ２０８）、生成したMessage Bを端末２００へ送信する（ＳＴ２０９）。
このように、本実施の形態では、端末２００は、RACH preamble及びデータ部分を含むMessage A（換言すると、ランダムアクセス信号）のうち、データ部分の送信に関するパラメータ（送信パラメータ）を動的に決定する。これにより、端末２００は、発生した送信パケットに応じて、Message Aのデータ部分において用いる送信パラメータ（例えば、TBS、リソース位置又はリソース量）を適切に選択できる。
また、本実施の形態では、端末２００は、Message Aを用いて、決定された送信パラメータを基地局１００へ通知する。例えば、本実施の形態では、端末２００は、送信パラメータ（例えば、TBS）に関する情報を示すUCIを含むMessage Aを基地局１００へ送信する。すなわち、本実施の形態では、Message Aに含まれるUCIによって、Message Aのデータ部分のTBSが、端末２００から基地局１００へ明示的に通知される。例えば、基地局１００は、受信したUCIに基づいて、Message Aのデータ部分に用いられるTBSを特定できる。
これにより、基地局１００は、端末２００において動的に決定されるTBSに応じて、Message Aを正しく復調及び復号できる可能性が高くなる。
また、本実施の形態では、実施の形態１及び２のように、Message Aのデータ部分の送信パラメータに対応付けられる複数のRACH preambleリソース候補群が不要である。換言すると、本実施の形態では、端末２００に対して、例えば、RACH preambleリソース候補群が１つあればよい。このため、本実施の形態によれば、RACH preambleリソースを効率的に設定できる。
なお、本実施の形態では、Message Aの送信パラメータの一例として、Message Aのデータ部分のTBSを用いる場合について説明したが、Message Aの送信パラメータは、TBSに限らず、他のパラメータでもよい。例えば、Message Aのデータ部分のリソース情報（例えば、リソース位置及びリソース量の少なくとも一つ）と、Message AのRACH preambleリソース候補群とが対応付けられてもよい。
（実施の形態４）
本実施の形態に係る基地局及び端末は、実施の形態１に係る基地局１００及び端末２００と基本構成が共通するので、図４及び図５を援用して説明する。
本実施の形態では、端末２００は、実施の形態３と同様に、Message Aのデータ部分のTBSに関する情報をUCIに含めて、2ステップRandom access procedure時に基地局１００へ通知する。
また、本実施の形態では、UCIに含める送信パラメータには、Message Aのデータ部分のTBSに加え、Message Aのデータ部分のリソース情報（例えば、リソース位置及びリソース量の少なくとも一つ）が含まれてよい。
また、本実施の形態では、Message Aで送信されるUCIのリソース情報（例えば、リソース位置及びリソース量の少なくとも一つ）は、Message AのRACH preambleリソース（又は、RACH preambleリソース候補群）と対応付けられてもよい。
例えば、基地局１００は、Message Aのデータ部分のTBSとUCIビットフィールド（例えば、インデックス）との対応付け、及び、UCIのリソース情報とRACH preambleリソース（又は、RACH Preambleリソース候補群）との対応付けについて、上位レイヤ信号を用いて、複数の組み合わせを端末２００へ通知する。上位レイヤ信号は、例えば、セル又はグループ固有の報知情報（例えば、SIB）又は端末固有のRRC信号である。
端末２００は、Message Aのデータ部分のTBSを、例えば、基地局１００から設定された複数のTBS（TBS候補）の中から、Message Aのデータ部分のTBSを動的に決定する。
端末２００は、例えば、実際に送信するUPデータ量（例えば、Buffer value）に基づいて、Message Aのデータ部分のTBSを選択してもよい。なお、TBS選択に用いるBuffer valueは、例えば、UPデータ量でもよく、RRC接続要求又はスケジューリング要求等のC-planeデータとUPデータの合計のデータ量でもよい。また、Buffer valueに基づいてTBSを選択する方法では、ゼロパディング量が少なくなるTBSが選択されてもよい。これにより、Message Aのデータ部分のリソースの使用効率を向上できる。
また、実施の形態３と同様、端末２００は、Message Aのデータ部分のTBSに関する情報を示すUCIを生成する。例えば、端末２００は、Message Aのデータ部分のTBSに関する情報に対応付けられたインデックスを含むUCIを生成する。
図１８は、TBSとUCIビットフィールドとの対応付けの一例を示す。図１８では、端末２００のBuffer valueに基づいてTBSを選択する方法に関する対応付けについても示す。
図１８では、例えば、TBS=X1が選択された場合、UCIビットフィールドにインデックス1が設定され、TBS=X2が選択された場合、UCIビットフィールドにインデックス2が設定され、TBS=X3が選択された場合、UCIビットフィールドにインデックス3が設定される。なお、設定されるTBSの数は、３個に限らず、例えば、２個又は４個以上でもよい。
例えば、図１８では、端末２００は、Buffer valueがY1以下の場合、TBS=X1（及び、UCIビットフィールドのインデックス1）を選択し、Buffer valueがY2以下の場合、TBS=X2（及び、UCIビットフィールドのインデックス2）を選択し、Buffer valueがY3以下の場合、TBS=X3（及び、UCIビットフィールドのインデックス3）を選択する。
また、端末２００は、例えば、RACH preambleリソース候補群から、実際に用いるRACH preambleリソースを選択する。また、端末２００は、例えば、UCIのリソース情報とRACH preambleリソースとの対応付けに基づいて、選択したRACH preambleリソースから、Message AのUCIのリソース情報（例えば、リソース位置及びリソース量の少なくとも一つ）を特定する。
端末２００は、例えば、選択したTBSを用いてMessage Aのデータ部分を生成する。また、端末２００は、Message Aのデータ部分に、TBSに関する情報に対応するインデックスを含むUCIを多重する。UCIは、例えば、Message AのRACH preambleリソース（又はRACH preambleリソース候補群）に対応付けられたリソース位置及びリソース量に基づいてMessage Aのデータ部分にマッピングされる。また、例えば、端末２００は、選択したRACH preambleリソースを用いて、Message AのRACH preambleを生成する。
なお、Message AのRACH preambleリソースとMessage Aのデータ部分とは、例えば、TDM、FDM又はCDMにより構成されてよい。また、端末２００がMessage Aのデータ部分において送信するデータには、例えば、RRC接続要求又はスケジューリング要求等のC-planeデータに加えて、UPデータが含まれてよい。または、端末２００がMessage Aのデータ部分において送信するデータには、例えば、UPデータが含まれず、RRC接続要求又はスケジューリング要求等のC-planeデータが含まれてよい。
端末２００は、生成したMessage Aを基地局１００へ送信する。
基地局１００は、RACH preambleを検出した場合、検出したRACH preambleに対応するRACH preambleリソースから、端末２００がMessage AのUCI送信に用いたリソース情報を特定する。また、基地局１００は、特定したUCIのリソース情報を用いて、UCIを復調及び復号することにより、端末２００がMessage Aの送信に用いたTBS及びデータ部分のリソース情報を特定できる。
基地局１００は、特定したTBS及びデータ部分のリソース情報を用いて、検出したRACH preambleに対応するMessage Aのデータ部分を復調及び復号する。そして、基地局１００は、Message Aの受信処理後、Message Bを生成し、生成したMessage Bを端末２００へ送信する。
このように、本実施の形態では、端末２００は、RACH preamble及びデータ部分を含むMessage Aのうち、データ部分の送信に関するパラメータ（送信パラメータ）を動的に決定する。これにより、端末２００は、発生した送信パケットに応じて、Message Aのデータ部分において用いる送信パラメータ（例えば、TBS及びリソース情報）を適切に選択できる。
また、本実施の形態では、端末２００は、実施の形態３と同様、送信パラメータ（例えば、TBS及びリソース情報）に関する情報を示すUCIを含むMessage Aを基地局１００へ送信する。すなわち、本実施の形態では、Message Aに含まれるUCIによって、Message Aのデータ部分のTBS及びリソース情報が、端末２００から基地局１００へ明示的に通知される。例えば、基地局１００は、受信したUCIに基づいて、Message Aのデータ部分に用いられるTBS及びリソース情報を特定できる。
これにより、基地局１００は、端末２００において動的に決定されるTBS及びリソース情報に応じて、Message Aを正しく復調及び復号できる可能性が高くなる。
また、本実施の形態では、実施の形態１及び２のように、Message Aのデータ部分の送信パラメータに対応付けられる複数のRACH preambleリソース候補群が不要である。換言すると、本実施の形態では、端末２００に対して、例えば、RACH preambleリソース候補群が１つあればよい。このため、本実施の形態によれば、RACH preambleリソースを効率的に設定できる。
また、本実施の形態では、基地局１００は、Message A のUCIのリソース情報と、RACH preambleリソース候補群との対応付けを設定する。これにより、例えば、contentionベースのRACHの場合、基地局１００は、システムが利用可能な帯域幅、又は、セル内のトラフィック状況等に応じて上記対応付けを設定することにより、RACH preambleリソース又はデータ部分のリソースの衝突確率を容易に制御できる。
［バリエーション１］
実施の形態４においてUCIによって端末２００から基地局１００へ通知される情報は、TBS、データ部分のリソース情報に限らず、Message Aの送信に関するその他のパラメータでもよい。例えば、Message Aの送信電力に関する情報、MCS、又は、Message Aデータ部分の送信ランク数に関する情報がUCIに含められてもよい。
［バリエーション２］
UCIの送信方法は、Message Aのデータ部分に多重する方法に限らない。例えば、上り制御チャネル（PUCCH：Physical Uplink Control Channel）を用いてUCIを送信する方法でもよい。
Message AのRACH preambleと、Message Aのデータ部分と、UCIを送信するためのPUCCHとは、例えば、TDM、FDM又はCDMによって構成されてよい。
UCIを送信するためのPUCCHフォーマット、リソース位置及びリソース量に関する情報は、例えば、RACH preambleリソース候補群と対応付けられてよい。これにより、基地局１００は、UCIの送信方法及びUCIが送信される無線リソースを予め特定できるため、UCIを正しく復調及び復号できる。
（実施の形態５）
本実施の形態に係る基地局及び端末は、実施の形態１に係る基地局１００及び端末２００と基本構成が共通するので、図４及び図５を援用して説明する。
本実施の形態では、端末２００は、TBSに関する情報及びMessage Aのデータ部分のリソース情報を、RACH preambleリソース候補群に対応付けられた黙示的な通知（例えば、実施の形態１又は２を参照）と、UCIによる明示的な通知（例えば、実施の形態３又は４を参照）との組み合わせにより通知する。
例えば、Message Aのデータ部分のTBSに関する情報は、実施の形態１又は２のように、Message AのRACH preambleリソース候補（例えば、時間リソース、周波数リソース及び系列リソースの組み合わせにより規定される）群と対応付けられる。一方、Message Aのデータ部分のリソース情報は、実施の形態３又は４のように、UCIに含めて通知される。
すなわち、端末２００は、端末２００によって動的に選択されたTBSに対応付けられるRACH preambleリソース候補群の中のRACH preambleリソースを用いたRACH preambleと、Message Aのデータ部分のリソース情報を示すUCIと、を含むMessage Aを基地局１００へ送信する。
このように、本実施の形態によれば、黙示的な通知のメリットであるオーバヘッド増加の抑圧効果と、RACH preambleリソースを効率的に設定できるUCIによる通知の効果とのトレードオフを考慮した設定が可能になる。
なお、本実施の形態において、Message Aのデータ部分のTBSに関する情報は、実施の形態３又は４のように、UCIに含めて通知され、Message Aのデータ部分のリソース位置又はリソース量は、実施の形態１又は２のように、Message AのRACH preambleリソース候補（例えば、時間リソース、周波数リソース及び系列リソースの組み合わせにより規定される）群と対応付けられてもよい。
例えば、TBSに関する情報、及び、Message Aのデータ部分のリソース位置又はリソース量に関する情報のうち、選択される候補数が少ない情報がUCIによって通知されてよい。これにより、UCIの通知に要するビット数を削減できる。
また、Message Aのデータ部分に関する送信パラメータは、TBS及びリソース情報に限らず、他のパラメータでもよい。
以上、本開示の各実施の形態について説明した。
（他の実施の形態）
（１）上記実施の形態におけるMessage AのRACH preambleリソース候補群は、2ステップRandom access procedure用のRACH preambleリソース候補群である。
基地局１００又は端末２００は、例えば、4ステップRandom access procedure及び2ステップRandom access procedureの両方をサポートする可能性がある。基地局１００又は端末２００が両方のRandom access procedureをサポートする場合、RACH preambleリソース候補群は、4ステップRandom access procedure用のリソースグループ群と、2ステップRandom access procedure用のリソースグループ群とに分けられてもよい。
これにより、基地局１００は、端末２００に使用されるRACH preambleリソース候補群に基づいて、端末２００が何れのRandom access procedureをトリガしたかを特定できる。
（２）上記実施の形態におけるMessage Aのデータ部分のリソースサイズの設定において、サイズ0が設定されてもよい。
この場合、端末２００は、Message Aにおいて、RACH preambleを送信し、データ部分を送信しない。
また、端末２００又は基地局１００は、データ部分がサイズ0のMessage Aを送信又は受信した場合、当該RACH procedureが4ステップRACH procedure（換言すると、Message 1の送信又は受信）であると認識してもよい。
（３）上記実施の形態において、端末２００がMessage Aのデータ部分で送信するデータは、RRC接続要求又はスケジューリング要求等のC-planeデータ、及び、UPデータに限らない。
例えば、Message Aのデータ部分で送信されるデータには、チャネル状態情報（CQI：Channel Quality Information）が含まれてよい。RACH procedureにおいて取得されるCSIは、後続する基地局１００から端末２００へのスケジューリングに利用できる。
このとき、端末２００がCQIを測定するためのCSI測定情報は、規格上予め規定されてもよく、基地局１００から送信される上位レイヤ信号（例えば、SIB）又は端末固有のRRC信号により端末２００に設定されてもよい。
また、Message AにCSIが含まれているか否かは、Message AのRACH preambleリソース候補群に対応付けられてもよい。
以上、他の実施の形態について説明した。
本開示はソフトウェア、ハードウェア、又は、ハードウェアと連携したソフトウェアで実現することが可能である。上記実施の形態の説明に用いた各機能ブロックは、部分的に又は全体的に、集積回路であるＬＳＩとして実現され、上記実施の形態で説明した各プロセスは、部分的に又は全体的に、一つのＬＳＩ又はＬＳＩの組み合わせによって制御されてもよい。ＬＳＩは個々のチップから構成されてもよいし、機能ブロックの一部または全てを含むように一つのチップから構成されてもよい。ＬＳＩはデータの入力と出力を備えてもよい。ＬＳＩは、集積度の違いにより、ＩＣ、システムＬＳＩ、スーパーＬＳＩ、ウルトラＬＳＩと呼称されることもある。集積回路化の手法はＬＳＩに限るものではなく、専用回路、汎用プロセッサ又は専用プロセッサで実現してもよい。また、ＬＳＩ製造後に、プログラムすることが可能なＦＰＧＡ（Field Programmable Gate Array）や、ＬＳＩ内部の回路セルの接続や設定を再構成可能なリコンフィギュラブル・プロセッサを利用してもよい。本開示は、デジタル処理又はアナログ処理として実現されてもよい。さらには、半導体技術の進歩または派生する別技術によりＬＳＩに置き換わる集積回路化の技術が登場すれば、当然、その技術を用いて機能ブロックの集積化を行ってもよい。バイオ技術の適用等が可能性としてありえる。
本開示は、通信機能を持つあらゆる種類の装置、デバイス、システム（通信装置と総称）において実施可能である。通信装置は無線送受信機（トランシーバー）と処理／制御回路を含んでもよい。無線送受信機は受信部と送信部、またはそれらを機能として、含んでもよい。無線送受信機（送信部、受信部）は、ＲＦ（Ｒａｄｉｏ Ｆｒｅｑｕｅｎｃｙ）モジュールと１または複数のアンテナを含んでもよい。ＲＦモジュールは、増幅器、ＲＦ変調器／復調器、またはそれらに類するものを含んでもよい。通信装置の、非限定的な例としては、電話機（携帯電話、スマートフォン等）、タブレット、パーソナル・コンピューター（ＰＣ）（ラップトップ、デスクトップ、ノートブック等）、カメラ（デジタル・スチル／ビデオ・カメラ等）、デジタル・プレーヤー（デジタル・オーディオ／ビデオ・プレーヤー等）、着用可能なデバイス（ウェアラブル・カメラ、スマートウオッチ、トラッキングデバイス等）、ゲーム・コンソール、デジタル・ブック・リーダー、テレヘルス・テレメディシン（遠隔ヘルスケア・メディシン処方）デバイス、通信機能付きの乗り物又は移動輸送機関（自動車、飛行機、船等）、及び上述の各種装置の組み合わせがあげられる。
通信装置は、持ち運び可能又は移動可能なものに限定されず、持ち運びできない又は固定されている、あらゆる種類の装置、デバイス、システム、例えば、スマート・ホーム・デバイス（家電機器、照明機器、スマートメーター又は計測機器、コントロール・パネル等）、自動販売機、その他ＩｏＴ（Ｉｎｔｅｒｎｅｔ ｏｆ Ｔｈｉｎｇｓ）ネットワーク上に存在し得るあらゆる「モノ（Things）」をも含む。
通信には、セルラーシステム、無線ＬＡＮシステム、通信衛星システム等によるデータ通信に加え、これらの組み合わせによるデータ通信も含まれる。
また、通信装置には、本開示に記載される通信機能を実行する通信デバイスに接続又は連結される、コントローラやセンサー等のデバイスも含まれる。例えば、通信装置の通信機能を実行する通信デバイスが使用する制御信号やデータ信号を生成するような、コントローラやセンサーが含まれる。
また、通信装置には、上記の非限定的な各種装置と通信を行う、あるいはこれら各種装置を制御する、インフラストラクチャ設備、例えば、基地局、アクセスポイント、その他あらゆる装置、デバイス、システムが含まれる。
本開示の一実施例に係る端末は、プリアンブル部及びデータ部を含むランダムアクセス信号のうち、前記データ部の送信に関するパラメータを動的に決定する制御回路と、前記ランダムアクセス信号を用いて、前記決定されたパラメータを基地局へ通知する送信回路と、を具備する。
本開示の一実施例において、前記パラメータの候補と前記プリアンブル部のリソース候補群とが対応付けられ、前記送信回路は、前記決定されたパラメータに対応付けられる前記リソース候補群の中のリソースを用いて、前記プリアンブル部の信号を送信する。
本開示の一実施例において、前記パラメータの候補と前記リソース候補群との対応付けは、上位レイヤ信号によって前記端末に通知される。
本開示の一実施例において、前記パラメータは、前記データ部のトランスポートブロックサイズであり、前記リソース候補群に対して、前記端末が設定可能な最大の前記トランスポートブロックサイズがそれぞれ対応付けられている。
本開示の一実施例において、前記リソース候補群に含まれるリソースの数は、前記リソース候補群毎に異なる。
本開示の一実施例において、前記制御回路は、前記決定したパラメータに応じて、同期信号、報知チャネル、又は、チャネル状態想定用参照信号を選択する。
本開示の一実施例において、前記送信回路は、前記決定されたパラメータに関する情報を示す上り制御情報を含む前記ランダムアクセス信号を送信する。
本開示の一実施例において、前記上り制御情報のリソースは、前記プリアンブル部のリソースと対応付けられている。
本開示の一実施例において、前記パラメータのうち、第１のパラメータの候補は、前記プリアンブル部のリソース候補群と対応付けられ、前記送信回路は、前記第１のパラメータに対応付けられる前記リソース候補群の中のリソースを用いた前記プリアンブル部の信号と、前記パラメータのうち、前記第１のパラメータと異なる第２のパラメータを示す上り制御情報と、を含む前記ランダムアクセス信号を送信する。
本開示の一実施例において、前記制御回路は、前記データ部のデータ量に基づいて、前記パラメータを決定する。
本開示の一実施例において、前記パラメータは、前記データ部における、トランスポートブロックサイズ、無線リソース、符号化変調方式、送信電力、及び、送信ランク数の少なくとも１つを含む。
本開示の一実施例に係る通信方法は、プリアンブル部及びデータ部を含むランダムアクセス信号のうち、前記データ部の送信に関するパラメータを動的に決定し、前記ランダムアクセス信号を用いて、前記決定されたパラメータを基地局へ通知する。
２０１９年２月１４日出願の特願２０１９−０２４１８２の日本出願に含まれる明細書、図面および要約書の開示内容は、すべて本願に援用される。
本開示の一実施例は、移動通信システムに有用である。
１００ 基地局
１０１，２０９ 制御部
１０２ データ生成部
１０３，１０６，１０９，２１１，２１３ 符号化部
１０４，１０７，１１０，２１２，２１４ 変調部
１０５ 上位制御信号生成部
１０８ 下り制御信号生成部
１１１，２１５ 信号割当部
１１２，２１６ IFFT部
１１３，２１７ 送信部
１１４，２０１ アンテナ
１１５，２０２ 受信部
１１６，２０３ FFT部
１１７，２０４ 抽出部
１１８ 検出部
１１９，２０５ 復調部
１２０，２０６，２０８ 復号部
２００ 端末
２０７ 下り制御信号復調部
２１０ RACH preamble生成部

Claims (12)

  1. プリアンブル部及びデータ部を含むランダムアクセス信号のうち、前記データ部の送信に関するパラメータを動的に決定する制御回路と、
    前記ランダムアクセス信号を用いて、前記決定されたパラメータを基地局へ通知する送信回路と、
    を具備する端末。
  2. 前記パラメータの候補と前記プリアンブル部のリソース候補群とが対応付けられ、
    前記送信回路は、前記決定されたパラメータに対応付けられる前記リソース候補群の中のリソースを用いて、前記プリアンブル部の信号を送信する、
    請求項１に記載の端末。
  3. 前記パラメータの候補と前記リソース候補群との対応付けは、上位レイヤ信号によって前記端末に通知される、
    請求項２に記載の端末。
  4. 前記パラメータは、前記データ部のトランスポートブロックサイズであり、
    前記リソース候補群に対して、前記端末が設定可能な最大の前記トランスポートブロックサイズがそれぞれ対応付けられている、
    請求項２に記載の端末。
  5. 前記リソース候補群に含まれるリソースの数は、前記リソース候補群毎に異なる、
    請求項２に記載の端末。
  6. 前記制御回路は、前記決定したパラメータに応じて、同期信号、報知チャネル、又は、チャネル状態想定用参照信号を選択する、
    請求項２に記載の端末。
  7. 前記送信回路は、前記決定されたパラメータに関する情報を示す上り制御情報を含む前記ランダムアクセス信号を送信する、
    請求項１に記載の端末。
  8. 前記上り制御情報のリソースは、前記プリアンブル部のリソースと対応付けられている、
    請求項７に記載の端末。
  9. 前記パラメータのうち、第１のパラメータの候補は、前記プリアンブル部のリソース候補群と対応付けられ、
    前記送信回路は、
    前記第１のパラメータに対応付けられる前記リソース候補群の中のリソースを用いた前記プリアンブル部の信号と、前記パラメータのうち、前記第１のパラメータと異なる第２のパラメータを示す上り制御情報と、を含む前記ランダムアクセス信号を送信する、
    請求項１に記載の端末。
  10. 前記制御回路は、前記データ部のデータ量に基づいて、前記パラメータを決定する、
    請求項１に記載の端末。
  11. 前記パラメータは、前記データ部における、トランスポートブロックサイズ、無線リソース、符号化変調方式、送信電力、及び、送信ランク数の少なくとも１つを含む、
    請求項１に記載の端末。
  12. プリアンブル部及びデータ部を含むランダムアクセス信号のうち、前記データ部の送信に関するパラメータを動的に決定し、
    前記ランダムアクセス信号を用いて、前記決定されたパラメータを基地局へ通知する、
    通信方法。
JP2020572094A 2019-02-14 2019-12-04 端末装置、通信方法及び集積回路 Pending JPWO2020166179A1 (ja)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
JP2019024182 2019-02-14
JP2019024182 2019-02-14
PCT/JP2019/047377 WO2020166179A1 (ja) 2019-02-14 2019-12-04 端末及び通信方法

Publications (1)

Publication Number Publication Date
JPWO2020166179A1 true JPWO2020166179A1 (ja) 2021-12-16

Family

ID=72044978

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2020572094A Pending JPWO2020166179A1 (ja) 2019-02-14 2019-12-04 端末装置、通信方法及び集積回路

Country Status (5)

Country Link
US (1) US20220104279A1 (ja)
EP (1) EP3927039A4 (ja)
JP (1) JPWO2020166179A1 (ja)
CN (1) CN113439463A (ja)
WO (1) WO2020166179A1 (ja)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11930490B2 (en) * 2020-04-01 2024-03-12 Samsung Electronics Co., Ltd. Method and apparatus for idle mode operation in wireless communication system

Family Cites Families (20)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20070180508A1 (en) * 2006-01-30 2007-08-02 International Business Machines Corporation Shared authentication for composite applications
KR101488525B1 (ko) * 2007-08-07 2015-02-04 삼성전자주식회사 이동 통신 시스템에서 랜덤 액세스 절차 수행 방법 및 장치
US8130667B2 (en) * 2008-09-19 2012-03-06 Texas Instruments Incorporated Preamble group selection in random access of wireless networks
JP5379256B2 (ja) * 2012-03-14 2013-12-25 シャープ株式会社 移動局装置、基地局装置、通信方法、集積回路および無線通信システム
CN104205670B (zh) * 2012-03-22 2017-12-05 中兴通讯(美国)公司 机器类型通信数据从移动装置向无线网络的优化传输
US9706522B2 (en) * 2013-03-01 2017-07-11 Intel IP Corporation Wireless local area network (WLAN) traffic offloading
JP5756505B2 (ja) * 2013-10-02 2015-07-29 シャープ株式会社 無線通信システム、移動局装置、ランダムアクセス方法及び集積回路
CN104981022B (zh) * 2014-04-04 2020-07-10 北京三星通信技术研究有限公司 数据传输的方法、基站及终端
US20170099660A1 (en) * 2015-10-01 2017-04-06 Electronics And Telecommunications Research Institute Method and apparatus for transmitting uplink data
EP3400747A4 (en) * 2016-01-08 2019-01-16 ZTE Corporation METHODS OF TRANSMITTING SMALL CRITICAL DATA FOR THE MISSION USING A RANDOM ACCESS CHANNEL
CN109845378B (zh) * 2016-09-28 2023-10-10 索尼公司 下一代无线系统中的随机接入
CN108282874B (zh) * 2017-01-06 2019-08-16 电信科学技术研究院 一种数据传输方法、装置及系统
CN108306841B (zh) * 2017-01-11 2022-02-11 中兴通讯股份有限公司 用于ofdm通信的信号设计方法及系统、发射机、接收机
US10397958B2 (en) * 2017-03-17 2019-08-27 Asustek Computer Inc. Method and apparatus for backoff mechanism applied for random access procedure in a wireless communication system
JP7013700B2 (ja) 2017-07-25 2022-02-01 セイコーエプソン株式会社 印刷装置、及び、印刷方法
US11057938B2 (en) * 2018-05-23 2021-07-06 Qualcomm Incorporated Wireless communication including random access
EP3817483B1 (en) * 2018-07-27 2023-02-15 Guangdong Oppo Mobile Telecommunications Corp., Ltd. Random access method, terminal device, and network device
AU2019310936B2 (en) * 2018-07-27 2023-12-21 Guangdong Oppo Mobile Telecommunications Corp., Ltd. Random access method, terminal device, network device, and storage medium
CN112566273B (zh) * 2019-09-26 2022-12-23 维沃移动通信有限公司 一种数据接收、发送方法、终端及网络侧设备
CN112689335A (zh) * 2019-10-18 2021-04-20 深圳市中兴微电子技术有限公司 随机接入信道的数据合并方法及装置

Also Published As

Publication number Publication date
WO2020166179A1 (ja) 2020-08-20
CN113439463A (zh) 2021-09-24
EP3927039A1 (en) 2021-12-22
US20220104279A1 (en) 2022-03-31
EP3927039A4 (en) 2022-04-13

Similar Documents

Publication Publication Date Title
US10159092B2 (en) Uplink contention based multiple access for cellular IoT
US11877317B2 (en) Method and device used for wireless communication
CN108347760B (zh) 一种上行信道的功率分配方法及装置
CN110692211B (zh) 基站装置和终端装置
KR20080107457A (ko) 무선 통신 시스템에서의 고속 액세스 장치 및 방법
CN112469127B (zh) 一种通信方法、终端及网络设备
JP7394835B2 (ja) 端末、通信方法及び集積回路
WO2018202111A1 (zh) 用于传输数据的方法和设备
US11743088B2 (en) Method and device in base station for unlicensed spectrum
US20200053698A1 (en) Base station device, terminal device, radio communication system, and radio communication method
WO2020217611A1 (ja) 端末及び通信方法
CN113273115B (zh) 信息发送和接收方法以及装置
CN114073161B (zh) 终端、基站、通信方法及集成电路
WO2020194924A1 (ja) 端末及び送信方法
JP2021512518A (ja) データ伝送方法及び端末装置
US20220104265A1 (en) Method and apparatus for performing random access in wireless communication system
WO2020166179A1 (ja) 端末及び通信方法
US20190182830A1 (en) Base station apparatus, terminal apparatus, radio communication system, and transmission timing setting method
WO2018081985A1 (zh) 数据传输方法、网络设备及终端设备
RU2788630C1 (ru) Терминал и способ передачи
CN112673704B (zh) 信息传输方法及相关设备

Legal Events

Date Code Title Description
A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20210909

A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20220914

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20231205

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20240221

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20240402

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20240530