(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公開特許公報(A)
(11)【公開番号】P2024138378
(43)【公開日】2024-10-08
(54)【発明の名称】基地局、通信方法及び集積回路
(51)【国際特許分類】
H04W 74/0836 20240101AFI20241001BHJP
H04W 74/0833 20240101ALI20241001BHJP
H04W 72/21 20230101ALI20241001BHJP
【FI】
H04W74/0836
H04W74/0833
H04W72/21
【審査請求】有
【請求項の数】17
【出願形態】OL
(21)【出願番号】P 2024109531
(22)【出願日】2024-07-08
(62)【分割の表示】P 2021508747の分割
【原出願日】2019-12-18
(31)【優先権主張番号】P 2019061499
(32)【優先日】2019-03-27
(33)【優先権主張国・地域又は機関】JP
【公序良俗違反の表示】
(特許庁注:以下のものは登録商標)
1.3GPP
(71)【出願人】
【識別番号】514136668
【氏名又は名称】パナソニック インテレクチュアル プロパティ コーポレーション オブ アメリカ
【氏名又は名称原語表記】Panasonic Intellectual Property Corporation of America
(74)【代理人】
【識別番号】110002952
【氏名又は名称】弁理士法人鷲田国際特許事務所
(72)【発明者】
【氏名】山本 哲矢
(72)【発明者】
【氏名】西尾 昭彦
(72)【発明者】
【氏名】鈴木 秀俊
(72)【発明者】
【氏名】リ イーフェイ
(57)【要約】
【課題】ランダムアクセス処理の効率を向上する。
【解決手段】基地局は、ランダムアクセス信号の送信応答であるメッセージBを送信する送信回路と、メッセージBに含まれる第1のパラメータに基づいて決定されたPUCCH(Physical Uplink Control Channel)リソースでメッセージBに対する応答信号を受信する受信回路と、を具備し、受信回路は、メッセージBがランダムアクセス信号のデータ部分の再送を要求する場合、メッセージBで通知したリソースを用いてメッセージ3を受信する。
【選択図】
図4
【特許請求の範囲】
【請求項1】
ランダムアクセス信号の送信応答であるメッセージBを送信する送信回路と、
前記メッセージBに含まれる第1のパラメータに基づいて決定されたPUCCH(Physical Uplink Control Channel)リソースで前記メッセージBに対する応答信号を受信する受信回路と、を具備し、
前記受信回路は、前記メッセージBが前記ランダムアクセス信号のデータ部分の再送を要求する場合、前記メッセージBで通知したリソースを用いてメッセージ3を受信する、
基地局。
【請求項2】
物理下り制御チャネルのビット及び制御チャネルエレメント番号を用いず、前記第1のパラメータに基づいて前記PUCCHリソースが決定される、
請求項1に記載の基地局。
【請求項3】
前記第1のパラメータに基づいて複数のリソースから前記PUCCHリソースが決定され、前記複数のリソースは上位レイヤ信号によって通知する、
請求項1に記載の基地局。
【請求項4】
前記メッセージBは前記応答信号の送信に用いられる送信タイミング情報を含む、
請求項1に記載の基地局。
【請求項5】
端末の識別情報が前記メッセージBに含まれる場合、ランダムアクセス手順が完了したと判断する、
請求項1に記載の基地局。
【請求項6】
前記メッセージBが前記ランダムアクセス信号のデータ部分の再送を要求する場合、端末の識別情報は前記メッセージBに含まない、
請求項1に記載の基地局。
【請求項7】
前記メッセージBは、前記ランダムアクセス信号のプリアンブル部分が基地局によって検出されなかった1つ以上の端末の制御情報を含まない、
請求項1に記載の基地局。
【請求項8】
前記ランダムアクセス信号はプリアンブル部とデータ部を含む、
請求項1に記載の基地局。
【請求項9】
基地局は、
ランダムアクセス信号の送信応答であるメッセージBを送信し、
前記メッセージBに含まれる第1のパラメータに基づいて決定されたPUCCH(Physical Uplink Control Channel)リソースで前記メッセージBに対する応答信号を受信し、
前記メッセージBが前記ランダムアクセス信号のデータ部分の再送を要求する場合、前記メッセージBで通知したリソースを用いてメッセージ3を受信する、
通信方法。
【請求項10】
物理下り制御チャネルのビット及び制御チャネルエレメント番号を用いず、前記第1のパラメータに基づいて前記PUCCHリソースが決定される、
請求項9に記載の通信方法。
【請求項11】
前記第1のパラメータに基づいて複数のリソースから前記PUCCHリソースが決定され、前記複数のリソースは上位レイヤ信号によって通知される、
請求項9に記載の通信方法。
【請求項12】
前記メッセージBは前記応答信号の送信に用いられる送信タイミング情報を含む、
請求項9に記載の通信方法。
【請求項13】
端末の識別情報が前記メッセージBに含まれる場合、ランダムアクセス手順が完了したと判断する、
請求項10に記載の通信方法。
【請求項14】
前記メッセージBが前記ランダムアクセス信号のデータ部分の再送を要求する場合、端末の識別情報は前記メッセージBに含まれない、
請求項10に記載の通信方法。
【請求項15】
前記メッセージBは、前記ランダムアクセス信号のプリアンブル部分が基地局によって検出されなかった1つ以上の端末の制御情報を含まない、
請求項9に記載の通信方法。
【請求項16】
前記ランダムアクセス信号はプリアンブル部とデータ部を含む、
請求項9に記載の通信方法。
【請求項17】
ランダムアクセス信号の送信応答であるメッセージBを送信する処理と、
前記メッセージBに含まれる第1のパラメータに基づいて決定されたPUCCH(Physical Uplink Control Channel)リソースで前記メッセージBに対する応答信号を受信する処理と、
前記メッセージBが前記ランダムアクセス信号のデータ部分の再送を要求する場合、前記メッセージBで通知されたリソースを用いてメッセージ3を受信する処理と、
を制御する、
集積回路。
【発明の詳細な説明】
【技術分野】
【0001】
本開示は、基地局、通信方法及び集積回路に関する。
【背景技術】
【0002】
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)を実現する機能をサポートしている(例えば、非特許文献1-7を参照)。
【先行技術文献】
【非特許文献】
【0003】
【非特許文献1】3GPP TS 38.211 V15.4.0, "NR; Physical channels and modulation (Release 15)," December 2018.
【非特許文献2】3GPP TS 38.212 V15.4.0, "NR; Multiplexing and channel coding (Release 15)," December 2018.
【非特許文献3】3GPP TS 38.213 V15.4.0, "NR; Physical layer procedure for control (Release 15)," December 2018.
【非特許文献4】3GPP TS 38.214 V15.4.0, "NR; Physical layer procedures for data (Release 15)," December 2018.
【非特許文献5】3GPP, TS38.300 V15.4.0, “NR; NR and NG-RAN overall description; Stage 2 (Release 15)”, December 2018.
【非特許文献6】3GPP, TS38.321 V15.4.0, “NR; Medium accesss control (MAC) protocol specification (Release 15)”, December 2018.
【非特許文献7】3GPP, TS38.331 V15.4.0, “NR; Radio resource control (RRC) protocol specification (Release 15)”, December 2018.
【非特許文献8】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.
【非特許文献9】RP-182881, “New work item: 2-step RACH for NR,” ZTE Corporation, Sanechips, December 2018.
【発明の概要】
【発明が解決しようとする課題】
【0004】
しかしながら、ランダムアクセス処理について十分に検討されていない。
【0005】
本開示の非限定的な実施例は、ランダムアクセス処理の効率を向上できる基地局、通信方法及び集積回路の提供に資する。
【課題を解決するための手段】
【0006】
本開示の一実施例に係る端末は、複数の端末向けの下りリンク信号に対する応答信号の送信に用いるリソースを、前記複数の端末毎にそれぞれ設定されるパラメータに基づいて決定する制御回路と、前記リソースにおいて前記応答信号を送信する送信回路と、を具備する。
【0007】
なお、これらの包括的または具体的な態様は、システム、装置、方法、集積回路、コンピュータプログラム、または、記録媒体で実現されてもよく、システム、装置、方法、集積回路、コンピュータプログラムおよび記録媒体の任意な組み合わせで実現されてもよい。
【発明の効果】
【0008】
本開示の一実施例によれば、ランダムアクセス処理の効率を向上できる。
【0009】
本開示の一実施例における更なる利点および効果は、明細書および図面から明らかにされる。かかる利点および/または効果は、いくつかの実施形態並びに明細書および図面に記載された特徴によってそれぞれ提供されるが、1つまたはそれ以上の同一の特徴を得るために必ずしも全てが提供される必要はない。
【図面の簡単な説明】
【0010】
【
図1】4ステップRandom access procedureの一例を示す図
【
図2】2ステップRandom access procedureの一例を示す図
【
図3】実施の形態1に係る端末の一部の構成例を示すブロック図
【
図4】実施の形態1に係る基地局の構成例を示すブロック図
【
図5】実施の形態1に係る端末の構成例を示すブロック図
【
図6】実施の形態1に係る基地局及び端末の動作例を示すシーケンス図
【
図7】実施の形態1に係る2ステップRandom access procedureの一例を示す図
【
図8】実施の形態1に係る2ステップRandom access procedureの一例を示す図
【発明を実施するための形態】
【0011】
以下、本開示の実施の形態について図面を参照して詳細に説明する。
【0012】
[Random access procedure]
Release 15 NRにおいて、端末(移動局又はUE:User Equipmentとも呼ぶ)は、例えば、以下のケースにおいて、基地局(gNB又はeNBとも呼ぶ)に対してランダムアクセス信号(RACH:Random Access Channel、又は、PRACH:Physical RACHとも呼ぶ)を送信する。
(1)初期アクセス時(例えば、RRC_IDLE状態からRRC_CONNECTED状態へ遷移する場合)
(2)RRC_INACTIVE状態からRRC_CONNECTED状態へ復帰する場合
(3)接続中(例えば、RRC_CONNECTED状態で上りリンク同期状態が“non-synchronized”の場合)において下りリンクデータ又は上りリンクデータが発生した時
(4)オンデマンドのSI(System Information)を要求する場合
(5)ビーム接続失敗から回復(BFR:Beam failure recovery)する場合
【0013】
これにより、端末から基地局への接続又は再同期確立が試行される。これらの端末から基地局への接続又は再同期確立のために行われる一連の動作は「Random access procedure」と呼ばれる。
【0014】
Release 15 NRでは、Random access procedureは、例えば、
図1に示す4つのステップから構成される(4ステップRandom access procedure又は4ステップRACH procedureと呼ぶ)(例えば、非特許文献8を参照)。
【0015】
<Step 1:Message 1の送信>
端末(例えば、UE)は、プリアンブル信号(以下、RACH preamble、PRACH preamble又は単にpreambleとも呼ぶ)のリソース候補(例えば、時間リソース、周波数リソース及び系列リソースの組み合わせにより規定されるリソース)群から、実際に用いるPRACH preambleリソースをランダムに選択する。そして、端末は、選択したPRACH preambleリソースを用いてPRACH preambleを基地局(例えば、gNB)へ送信する。PRACH preambleは、例えば、「Message 1」と呼ばれることがある。
【0016】
<Step 2:Message 2の送信>
基地局は、PRACH preambleを検出した場合、RACH応答(RAR: Random Access Responseとも呼ぶ)を送信する。RARは、例えば、「Message 2」と呼ばれることがある。なお、この時点では、基地局は、PRACH preambleを送信した端末を特定できない。このため、RARは、例えば、基地局がカバーするセルの全体に送信される。
【0017】
RARには、例えば、端末が上りリンク信号の送信(Step 3:Message 3の送信)において使用するリソース(上りリンクリソース)に関する情報、又は、端末による上りリンクの送信タイミングに関する情報が含まれる。ここで、PRACH preambleを送信した端末は、PRACH preambleの送信タイミングから規定された期間(例えば、RAR reception windowと呼ぶ)内にRARを受信しない場合、再度、PRACH preambleリソースの選択、及び、PRACH preambleの送信(換言すると、Message 1の再送)を行う。
【0018】
<Step 3:Message 3の送信>
端末は、RARによって基地局から指示された上りリンクリソースを用いて、例えば、RRC(Radio Resource Control)接続要求又はスケジュール要求等を含む「Message 3」を送信する。
【0019】
<Step 4:Message 4の送信>
基地局は、端末を識別するための識別情報(例えば、UE-ID)を含むメッセージ(「Message 4」と呼ばれる)を端末へ送信する。基地局は、Message 4を送信することにより、複数の端末が競合していないことを確認する(contention resolution)。なお、UE-IDには、例えば、C-RNTI(Cell-Radio Network Temporary Identifier)又はTemporary C-RNTI等が使用されてよい。
【0020】
以上、4ステップRandom access procedureの一例について説明した。
【0021】
一方、Release 16 NRでは、端末から基地局への接続又は再同期確立を低遅延で効率的に行うために、例えば、
図2に示す2ステップから構成されるRandom access procedure(2ステップRandom access procedure、又は、2-step RACH procedureと呼ぶこともある)が検討されている(例えば、非特許文献9を参照)。
【0022】
<Step 1:Message Aの送信>
端末は、4ステップRandom access procedure(例えば、
図1を参照)のStep 1及びStep 3に相当するMessage 1(換言すると、preamble)及びMessage 3に相当する情報を含むメッセージ(以下、「Message A」と呼ぶ)を基地局へ送信する。
【0023】
<Step 2:Message Bの送信>
基地局は、Message Aを検出した場合、Message Bを送信する。Message Bには、例えば、4ステップRandom access procedure(例えば、
図1を参照)のMessage 2又はMessage 4に相当する情報(例えば、何れか一方又はまたは両方)が含まれる。
【0024】
[Random access procedureにおける再送制御]
4ステップRandom access procedureでは、Message 2の送信はグループキャスト(又はマルチキャスト)送信である。Message 2において、例えば、MAC PDU(Medium Access Control layer Protocol Data Unit)には、1又は複数の端末に対するMAC RAR(又は、MAC subPDU)が含まれる。また、Message 2に対しては、再送制御であるHARQ(Hybrid Automatic Repeat Request)は適用されていない。
【0025】
また、4ステップRandom access procedureでは、Message 4の送信はユニキャスト送信であり、かつ、Message 4に対してHARQが適用されている。
【0026】
一方、2ステップRandom access procedureでは、Message Bには、少なくともRACH応答(例えば、RAR)を含むMAC PDUと、端末を識別するための識別情報(例えば、UE-ID)を含めたメッセージ(例えば、Contention resolution MAC CE)を含むMAC PDUとが含まれる。
【0027】
例えば、Message Bの送信が4ステップRandom access procedureのMessage 4と同様、ユニキャスト送信であると、基地局100は、ランダムアクセスを行った全ての端末に対して、下りリンク制御チャネル(例えば、PDCCH:Physical Downlink Control Channel)によってMessage Bをスケジューリングすることになる。この場合、例えば、ランダムアクセスを行う端末の数が増加するほど、下りリンク制御チャネルのオーバヘッドが増加する可能性がある。
【0028】
よって、Message Bの送信は、4ステップRandom access procedureのMessage 2と同様、グループキャスト送信とすることが想定される。これにより、下りリンク制御チャネルのオーバヘッドを削減できる。
【0029】
また、Message Bには、上述したRARを含むMAC PDU及びUE-IDを含むMAC PDUに加え、例えば、RRC(Radio Resource Control)接続、RRC復帰及びRRC再接続に関するRRC信号を含むMAC PDUが含まれてもよい。RRC信号を含むMAC PDUがMessage Bに含まれることにより、2ステップRandom access procedureの遅延を更に削減できる。
【0030】
ただし、RRC信号は、他の信号と比較してデータ量が大きい。そのため、例えば、Message Bに対して、4ステップRandom access procedureのMessage 4と同様、HARQを適用することにより、下りリンクリソースの利用効率を向上することが想定される。Message Bに対してHARQが適用される場合、端末は、上りリンクにおいて、下りリンクデータ(例えば、RRC信号)の誤り検出結果を示す応答信号(例えば、ACK/NACK:Acknowledgement/Negative Acknowledgment)を基地局へ送信する。
【0031】
しかしながら、2ステップRandom access procedureにおいてグループキャスト送信されるMessage Bに対してACK/NACK信号を送信する方法は十分に検討されていない。
【0032】
例えば、Release 15 NRでは、Message 4に対するACK/NACK信号を送信するための上りリンク制御チャネル(例えば、PUCCH:Physical Uplink control channel)のリソース(以下、PUCCHリソースと呼ぶ)の割当が導入されている(例えば、非特許文献3を参照)。
【0033】
例えば、基地局は、SIB(System Information Block)等のセル固有の上位レイヤ信号(例えば、RMSI:Reminaing Minimum System Information)によって、PUCCHリソースに関する複数のパラメータの組み合わせを示すリソース設定(例えば、PUCCH resource set)を端末に予め通知する。例えば、Release 15 NRでは、PUCCH resource setには、16個のPUCCHリソースに関するパラメータの組み合わせが含まれる。
【0034】
また、基地局は、Message 4をスケジューリングするPDCCH内の一部のビット(例えば、Release 15 NRでは3ビット)と、PDCCHのリソース割当情報であるCCE(Control Channel Element)番号とに基づいて、PUCCH resource setの中から、端末が実際に用いるPUCCHリソースに関するパラメータの組み合わせを1つ選択する。
【0035】
例えば、PUCCHリソースに関するパラメータの組み合わせrPUCCH(例えば、0~15の16個)は、次式で与えられる。
rPUCCH = ceiling (2nCCE/NCCE) + 2ΔPRI (1)
【0036】
式(1)において、nCCEはCCE番号を表し、NCCEはCCE数を表し、ΔPRIはPDCCHの一部のビット(例えば、3ビット)によって明示的に通知される値(例えば、0~7の何れか)を表す。
【0037】
ここで、Message 4の送信はユニキャスト送信であるので、各端末に対するMessage 4はそれぞれ異なるPDCCHによってスケジューリングされる。したがって、例えば、基地局が、式(1)に示すPUCCHリソースに関するパラメータの組み合わせと、PDCCHによって通知されるΔPRIとを適切に設定することにより、Message 4に対するACK/NACK信号について、端末間のPUCCHリソースは衝突しない。
【0038】
一方、Message Bの送信がグループキャスト送信である場合、Message Bには、複数の端末に対するMAC PDUが含まれる。よって、各端末のチャネル状態に応じて、セル内には、MAC PDUを正しく復号できる端末と、MAC PDUの復号に失敗する端末とが混在して発生する可能性がある。換言すると、各端末におけるMessage BのMAC PDU(例えば、RRC信号を含むMAC PDU)に対する復号結果(換言すると、ACK/NACK信号)は、端末間で異なる可能性がある。
【0039】
しかし、Message Bの送信がグループキャスト送信である場合、基地局は1つのPDCCHによって複数の端末宛のMAC PDUを含むMessage Bをスケジューリングする。このため、例えば、式(1)に示すRelease 15 NRのMessage 4のためのPUCCHリソース割当では、全ての端末に対して同一のPUCCHリソースが割り当てられる。よって、各端末がMessage BのMAC PDUの復号結果に応じたACK/NACK信号を基地局へ送信する場合、全ての端末が同一のPUCCHリソースにおいてACK/NACK信号を送信することになる。換言すると、Message Bに対するACK/NACK信号について、端末間においてPUCCHリソースが衝突し得る。
【0040】
例えば、基地局がPDCCHにおいて端末毎のΔPRI(例えば、式(1)を参照)を含めて送信することにより、Message Bに対するACK/NACK信号について、端末間のPUCCHリソースの衝突を抑制できる。しかし、この場合、PDCCHのオーバヘッドが増加する。例えば、Release 15 NRと同様、3ビットのΔPRIを仮定すると、端末数(換言すると、ユーザ数)×3ビットのオーバヘッドが生じ得る。
【0041】
そこで、本開示の一実施例では、2ステップRandom access procedureにおいて、Message Bの送信がグループキャスト送信である場合におけるMessage Bに対するACK/NACK信号の送信方法について説明する。本開示の一実施例によれば、PDCCHのオーバヘッドを抑制しつつ、端末間のPUCCHリソースの衝突を抑制できる。
【0042】
以下、各実施の形態について、詳細に説明する。
【0043】
(実施の形態1)
[通信システムの概要]
本開示の各実施の形態に係る通信システムは、基地局100及び端末200を備える。
【0044】
図3は、本開示の各実施の形態に係る端末200の一部の構成例を示すブロック図である。
図3に示す端末200において、制御部209(制御回路に相当)は、複数の端末向けの下りリンク信号(例えば、Message B)に対する応答信号(例えば、ACK/NACK信号)の送信に用いるリソースを、複数の端末毎にそれぞれ設定されるパラメータに基づいて決定する。送信部218は、上記リソースにおいて応答信号を送信する。
【0045】
[基地局の構成]
図4は、本開示の実施の形態1に係る基地局100の構成例を示すブロック図である。
図4において、基地局100は、制御部101と、データ生成部102と、符号化部103と、再送制御部104と、変調部105と、上位制御信号生成部106と、符号化部107と、変調部108と、下り制御信号生成部109と、符号化部110と、変調部111と、信号割当部112と、IFFT(Inverse Fast Fourier Transform)部113と、送信部114と、アンテナ115と、受信部116と、FFT(Fast Fourier Transform)部117と、抽出部118と、検出部119と、復調部120と、復号部121と、を有する。
【0046】
制御部101は、端末200のMessage A送信のための情報(又は、Message Aの送信パラメータとも呼ぶ)を決定し、決定した情報を抽出部118、復調部120及び復号部121へ出力する。また、制御部101は、決定した情報を上位制御信号生成部106へ出力する。Message A送信のための情報には、例えば、Message AのPRACH preambleリソース、PUSCHリソース、PUSCHのTBS(Transport Block Size)又はMCSに関する情報が含まれてもよい。
【0047】
また、制御部101は、データ信号(例えば、Message B等)、上位レイヤの制御信号(例えば、上位制御信号)又は下りリンク制御情報(例えば、下り制御信号)を送信するための下りリンク信号に対する無線リソース割当(例えば、下りリンクリソース及びMCS等)を決定する。制御部101は、決定した情報(例えば、スケジューリング情報を含む)を、符号化部103,107,110、変調部105,108,111、及び、信号割当部112へ出力する。また、制御部101は、決定した情報を下り制御信号生成部109へ出力する。
【0048】
また、制御部101は、復号部121から入力されるMessage A(例えば、C-Planeデータ又はUP(User Plane)データ)の復号結果、及び、検出部119から入力されるMessage A(例えば、PRACH preamble)の検出結果に基づいて、Message Bに含める情報を決定し、決定した情報をデータ生成部102へ出力する。
【0049】
また、制御部101は、端末200がMessage Bに対するACK/NACK信号を送信するためのPUCCHリソースに関する情報を決定する。制御部101は、決定した情報を、上位制御信号生成部106、下り制御信号生成部109、データ生成部102、又は、抽出部118へ出力する。
【0050】
データ生成部102は、制御部101から入力される、Message Bに含める情報を用いて、Message Bの情報ビット列(換言すると、下りリンクデータ)を生成し、生成した情報ビット列を符号化部103へ出力する。
【0051】
符号化部103は、データ生成部102から入力される情報ビット列(データ信号)に対して誤り符号化を行い、符号化後のデータ信号を再送制御部104へ出力する。
【0052】
再送制御部104は、初回送信時には、符号化部103から入力される符号化後のデータ信号を変調部105へ出力する。また、再送制御部104は、符号化後のデータ信号を保持する。また、再送制御部104は、復号部121から、送信したデータ信号に対するNACKが入力されると、対応する保持データを変調部105へ出力し、送信したデータに対するACKが入力されると、対応する保持データを削除する。
【0053】
変調部105は、再送制御部104から入力されるデータ信号を変調して、変調後のデータ信号を信号割当部112へ出力する。
【0054】
上位制御信号生成部106は、制御部101から入力される制御情報を用いて、制御情報ビット列(上位制御信号)を生成し、生成した制御情報ビット列を符号化部107へ出力する。
【0055】
符号化部107は、上位制御信号生成部106から入力される制御情報ビット列に対して誤り訂正符号化を行い、符号化後の制御信号を変調部108へ出力する。
【0056】
変調部108は、符号化部107から入力される制御信号を変調して、変調後の制御信号を信号割当部112へ出力する。
【0057】
下り制御信号生成部109は、制御部101から入力される制御情報を用いて、制御情報ビット列(下り制御信号。例えば、DCI:Downlink Control Information)を生成し、生成した制御情報ビット列を符号化部110へ出力する。なお、制御情報が複数の端末向けに送信されることもあるため、下り制御信号生成部109は、各端末向けの制御情報(例えば、PDCCH:Physical Downlink Control Channel)に、全端末向けの識別情報(例えば、RA-RNTI:Random Access-RNTI)又は端末固有の識別情報(例えば、C-RNTI)等を用いてスクランブルしてもよい。
【0058】
符号化部110は、下り制御信号生成部109から入力される制御情報ビット列に対して誤り訂正符号化を行い、符号化後の制御信号を変調部111へ出力する。
【0059】
変調部111は、符号化部110から入力される制御信号を変調して、変調後の制御信号を信号割当部112へ出力する。
【0060】
信号割当部112は、制御部101から入力される無線リソースを示す情報に基づいて、変調部105から入力されるデータ信号、変調部108から入力される上位制御信号、又は、変調部111から入力される下り制御信号を、無線リソースにマッピングする。信号割当部112は、信号がマッピングされた下りリンクの信号をIFFT部113へ出力する。
【0061】
IFFT部113は、信号割当部112から入力される信号に対して、OFDM(Orthogonal Frequency Division Multiplexing)等の送信波形生成処理を施す。IFFT部113は、CP(Cyclic Prefix)を付加するOFDM伝送の場合には、CPを付加する(図示せず)。IFFT部113は、生成した送信波形を送信部114へ出力する。
【0062】
送信部114は、IFFT部113から入力される信号に対してD/A(Digital-to-Analog)変換、アップコンバート等のRF(Radio Frequency)処理を行い、アンテナ115を介して端末200に無線信号を送信する。
【0063】
受信部116は、アンテナ115を介して受信された端末200からの上りリンク信号波形に対して、ダウンコンバート又はA/D(Analog-to-Digital)変換等のRF処理を行い、受信処理後の上りリンク信号波形をFFT部117に出力する。
【0064】
FFT部117は、受信部116から入力される上りリンク信号波形に対して、時間領域信号を周波数領域信号に変換するFFT処理を施す。FFT部117は、FFT処理により得られた周波数領域信号を抽出部118へ出力する。
【0065】
抽出部118は、制御部101から入力される情報に基づいて、FFT部117から入力される信号から、PRACH preambleが送信された無線リソース部分、又は、Message AのPUSCHが送信された無線リソース部分を抽出する。抽出部118は、抽出したPRACH preambleが送信された無線リソース部分を検出部119へ出力し、PRACH preambleと異なる他の信号(例えば、Message AのPUSCH)が送信された無線リソース部分を復調部120へ出力する。また、抽出部118は、制御部101から入力される情報に基づいて、FFT部117から入力される信号から、Message Bに対するACK/NACK信号を抽出し、復調部120へ出力する。
【0066】
検出部119は、抽出部118から入力される、PRACH preambleに対応する無線リソース部分に対して、PRACH preambleの検出を行う。検出部119は、PRACH preambleの検出結果に関する情報を制御部101へ出力する。
【0067】
復調部120は、制御部101から入力される情報に基づいて、抽出部118から入力されるMessageAのデータ、又は、Message Bに対するACK/NACK信号を復調し、復調結果(復調系列)を復号部121へ出力する。
【0068】
復号部121は、制御部101から入力される情報に基づいて、復調部120から入力される復調結果に対して誤り訂正復号を行い、復号後のビット系列(例えば、C-Planeデータ又はUPデータを含む)を出力する。また、例えば、復号部121は、Message Aの復号結果を制御部101へ出力する。
【0069】
また、復号部121は、復調部120から入力される復調結果に基づいて、Message Bに対するACK/NACK信号を復号し、送信したデータ信号に対するACK/NACK信号がACK及びNACKの何れを示しているかを判定する。復号部121は、判定結果(ACK又はNACK)を再送制御部104に出力する。
【0070】
[端末の構成]
図5は、本開示の実施の形態に係る端末200の構成例を示すブロック図である。
図5において、端末200は、アンテナ201と、受信部202と、FFT部203と、抽出部204と、復調部205と、復号部206と、下り制御信号復調部207と、復号部208と、制御部209と、PRACH preamble生成部210と、ACK/NACK生成部211と、符号化部212と、変調部213と、符号化部214と、変調部215と、信号割当部216と、IFFT部217と、送信部218と、を有する。
【0071】
受信部202は、アンテナ201を介して受信された基地局100からの下りリンク信号の信号波形に対して、ダウンコンバート又はA/D(Analog-to-Digital)変換などのRF処理を行い、得られる受信信号(ベースバンド信号)をFFT部203に出力する。下りリンク信号には、例えば、データ信号(例えば、Message B等)、上位制御信号、又は下り制御信号が含まれる。
【0072】
FFT部203は、受信部202から入力される信号(時間領域信号)に対して、時間領域信号を周波数領域信号に変換するFFT処理を施す。FFT部203は、FFT処理により得られた周波数領域信号を抽出部204へ出力する。
【0073】
抽出部204は、制御部209から入力される制御情報(例えば、制御信号の無線リソースに関する情報)に基づいて、FFT部203から入力される信号から、データ信号(例えば、Message B等)、下り制御信号、又は、上位制御信号を抽出する。抽出部204は、データ信号又は上位制御信号を復調部205へ出力し、下り制御信号を下り制御信号復調部207へ出力する。
【0074】
復調部205は、抽出部204から入力されるデータ信号又は上位制御信号を復調し、復調結果を復号部206へ出力する。
【0075】
復号部206は、復調部205から入力される復調結果を用いて誤り訂正復号を行い、受信データ(例えば、Message B)又は制御情報を得る。復号部208は、得られた受信データ又は制御情報を制御部209に出力する。また、復号部206は、受信データに対して誤り検出を行い、誤り検出結果(例えば、誤り有り又は誤り無し)をACK/NACK生成部211へ出力する。
【0076】
下り制御信号復調部207は、抽出部204から入力される下り制御信号を復調し、復調結果を復号部208へ出力する。
【0077】
復号部208は、下り制御信号復調部207から入力される復調結果を用いて誤り訂正復号を行い、制御情報を得る。復号部208は、得られた制御情報を制御部209に出力する。
【0078】
制御部209は、復号部206又は復号部208から入力される制御情報に基づいて、上りリンク送信(例えば、Message Aの送信)に関するパラメータを決定する。制御部209は、決定した情報を、PRACH preamble生成部210、符号化部212,214、変調部213,215及び信号割当部216へ出力する。
【0079】
また、制御部209は、復号部206又は復号部208から入力される、Message Bに対するACK/NACK信号を送信するリソースに関する情報に基づいて、ACK/NACK信号の送信に関する情報(例えば、上りリンクリソース、送信方法又はパラメータ等)を決定する。制御部209は、決定した情報を符号化部212、変調部213及び信号割当部216へ出力する。
【0080】
また、制御部209は、復号部206又は復号部208から入力される制御情報に含まれる、制御信号の無線リソースに関する情報を、抽出部204に出力する。
【0081】
PRACH preamble生成部210は、制御部209から入力される制御情報(例えば、Message Aの送信パラメータ)に基づいて、PRACH preambleを生成し、生成したPRACH preambleを信号割当部216へ出力する。
【0082】
ACK/NACK生成部211は、復号部206から入力される誤り検出結果に基づいて、受信した下りリンクデータ(例えば、Message B)に対するACK/NACK信号を生成し、ACK/NACK信号(例えば、ACK/NACK信号系列)を符号化部212へ出力する。
【0083】
符号化部212は、制御部209から入力される情報(例えば、ACK/NACK信号の送信に関する情報)に基づいて、ACK/NACK生成部211から入力されるACK/NACK信号系列を誤り訂正符号化し、符号化後のACK/NACK信号系列を変調部213へ出力する。
【0084】
変調部213は、制御部209から入力される情報に基づいて、符号化部212から入力されるACK/NACK信号系列を変調して、変調後のACK/NACK信号(変調シンボル列)を信号割当部216へ出力する。
【0085】
符号化部214は、制御部209から入力される制御情報(例えば、Message Aの送信パラメータ)に基づいて、例えば、MessageAのデータ部分において送信される情報ビット系列(例えば、C-Planeデータ及びUPデータ)を誤り訂正符号化し、符号化後のビット系列を変調部215へ出力する。
【0086】
変調部215は、制御部209から入力される情報に基づいて、符号化部214から入力されるビット系列を変調して、データ信号(変調シンボル列)を信号割当部216へ出力する。
【0087】
信号割当部216は、PRACH preamble生成部210から入力される信号、変調部213から入力される信号、又は、変調部215から入力される信号を、制御部209から指示される無線リソースにマッピングし、信号がマッピングされた上りリンク信号をIFFT部217へ出力する。
【0088】
IFFT部217は、信号割当部216から入力される信号に対して、OFDM等の送信波形生成処理を施す。IFFT部217は、CPを付加するOFDM伝送の場合には、CPを付加する(図示せず)。または、IFFT部217がシングルキャリア波形を生成する場合には、信号割当部216の前段にDFT(Discrete Fourier Transform)部が追加されてもよい(図示せず)。IFFT部217は、生成した送信波形を送信部218へ出力する。
【0089】
送信部218は、IFFT部217から入力される信号に対してD/A変換、アップコンバート等のRF処理を行い、アンテナ201を介して基地局100に無線信号を送信する。
【0090】
[基地局100及び端末200の動作例]
以上の構成を有する基地局100及び端末200における動作例について説明する。
【0091】
図6は、本実施の形態に係る基地局100及び端末200におけるMessage Bに対するACK/NACK信号の送受信処理に関するフローの一例を示す。
【0092】
図6において、基地局100は、例えば、上りリンクリソース(例えば、PUCCHリソース)に関する情報を端末200へ通知する(ST101)。PUCCHリソースに関する情報には、例えば、Message Bに対するACK/NACK信号を送信するためのPUCCHリソースに関する情報が含まれる。端末200は、PUCCHリソースに関する情報を取得する(ST102)。
【0093】
基地局100は、例えば、Message Bの割当情報を含むスケジューリング情報を端末200へ送信する(ST103)。Message Bのスケジューリング情報は、例えば、PDCCHによって送信されてもよい。端末200は、Message Bのスケジューリング情報を取得する(ST104)。
【0094】
基地局100は、例えば、Message Bのスケジューリング情報に基づいて、Message Bを端末200へ送信する(ST105)。
【0095】
端末200は、Message Bを受信すると、Message Bを復調及び復号する(ST106)。また、端末200は、Message Bに対するACK/NACK信号を生成する。
【0096】
端末200は、例えば、PUCCHリソースに関する情報、スケジューリング情報(例えば、PDCCH)、及び、Message B(例えば、RAR)の少なくとも一つに基づいて、Message B(例えば、RRC信号)に対するACK/NACK信号を送信するための上りリンクリソースを決定する(ST107)。
【0097】
そして、端末200は、決定した上りリンクリソースに基づいて、Message Bに対するACK/NACK信号を基地局100へ送信する(ST108)。
【0098】
[Message Bに対するACK/NACK信号の送信方法]
次に、Message Bに対するACK/NACK信号の送信方法の一例について説明する。
【0099】
本実施の形態では、端末200は、例えば、PUCCHにおいて、Message Bに対するACK/NACK信号を送信する。
【0100】
このとき、端末200は、Message Bに対するACK/NACK信号を送信するためのPUCCHリソースを、例えば、4ステップRandom access procedureのMessage 4に対するACK/NACK信号を送信するためのPUCCHリソースの通知(例えば、式(1)に示すパラメータ)に加え、新たなパラメータ「X」に基づいて決定する。パラメータXは、例えば、Message Bの送信宛てになる複数の端末200毎にそれぞれ設定される値でもよい。
【0101】
まず、以下に、本実施の形態における2ステップRACH procedureの動作例1及び動作例2について説明する。
【0102】
ここでは、一例として、3つの端末200(例えば、UE#A、UE#B及びUE#C)がMessage Aを基地局100(例えば、gNB)へ送信する場合について説明する。
【0103】
[動作例1]
図7は、動作例1における2ステップRACH procedureの一例を示す。
【0104】
<Message Aの送信>
各端末200は、Message Aを基地局100へ送信する。
【0105】
Message Aには、例えば、RACH preamble(例えば、Preamble#1~#3の何れか)、及び、PUSCH(例えば、データ部分、又は、UCI+データ部分)が含まれる。また、PUSCHには、例えば、端末200を識別するためのUE-ID(例えば、UE-ID#A、UE-ID#B及びUE-ID#Cの何れか)が含まれる。
【0106】
また、各端末200は、RACH preamble(換言すると、Message A)の送信タイミングから、Message Bの受信可能期間である「Msg.B reception window」(換言すると、タイマ)を動作させる。
【0107】
<Message Bの送信>
基地局100は、各端末200から送信されるMessage Aを検出し、かつ、正しく復号した場合、Message Bを送信する。Message Bには、例えば、RAR及び端末200を識別するためのUE-IDを含めたメッセージ(例えば、MAC RAR及びMAC CE)が含まれる。
【0108】
一方、基地局100は、Message A(例えば、PRACH preamble)を検出できなかった場合、又は、Message A(例えば、PUSCH)を正しく復号できなかった場合、対応するMessage Aを送信した端末200宛の情報をMessage Bに含めない。
【0109】
例えば、
図7に示す例では、基地局100(gNB)は、UE#Aから送信されたMessage AのPreamble#1を検出し(検出結果:○)、PUSCHを正しく復号する(復号結果:○)。一方、基地局100(gNB)は、UE#Bから送信されたMessage AのPreamble#2を検出し(検出結果:○)、PUSCHを正しく復号できない(復号結果:×)。また、基地局100(gNB)は、UE#Cから送信されたMessage AのPreamble#1を検出できず(検出結果:×)、PUSCHを正しく復号できない(復号結果:×)。
【0110】
よって、
図7に示す例では、基地局100は、UE#Aに対するRAR、及び、UE#AのUE-ID#Aを含むMessage Bを生成する。換言すると、
図7では、Message Bには、UE#B及びUE#C宛ての情報は含まれない。
【0111】
<Message Bの受信>
Message Aを送信した端末200は、Msg.B reception windowの期間内に当該端末200宛の情報を含むMessage Bを受信しない場合、Message Aを再送する(換言すると、Random access処理をMessage Aの送信から再度行う)。
図7に示す例では、UE#B及びUE#Cは、Msg.B reception windowの期間内にUE#B及びUE#C宛てのMessage Bを受信しないので、Message Aを再送する。
【0112】
一方、Message Aを送信した端末200は、Msg.B reception windowの期間内に当該端末200宛の情報を含むMessage Bを受信し、Message Bに含まれるUE-IDが、送信したMessage Aに含めたUE-IDと一致する場合、RACH procedureが成功したと判断する。
図7に示す例では、UE#Aは、Msg.B reception windowの期間内にUE#A宛てのMessage Bを受信し、当該Message Bに含まれるUE-ID(UE-ID#A)が、送信したMessage Aに含めたUE-ID(UE-ID#A)と一致するので、RACH procedureが成功したと判断する(RA procedure:○)。
【0113】
<動作例2>
図8は、動作例2における2ステップRACH procedureの一例を示す。
【0114】
<Message Aの送信>
各端末200は、Message Aを基地局100へ送信する。
【0115】
動作例1と同様、Message Aには、例えば、RACH preamble(例えば、Preamble#1~#3の何れか)、及び、PUSCH(例えば、データ部分、又は、UCI+データ部分)が含まれる。また、PUSCHには、例えば、端末200を識別するためのUE-ID(例えば、UE-ID#A、UE-ID#B及びUE-ID#Cの何れか)が含まれる。
【0116】
また、各端末200は、RACH preamble(換言すると、Message A)の送信タイミングから、Message Bの受信可能期間である「Msg.B reception window」(換言すると、タイマ)を動作させる。
【0117】
<Message Bの送信>
基地局100は、各端末200から送信されるMessage Aを検出し、かつ、正しく復号した場合、Message Bを送信する。Message Bには、例えば、RAR及び端末200を識別するためのUE-IDを含めたメッセージ(例えば、MAC RAR及びMAC CE)が含まれる。
【0118】
また、基地局100は、各端末200から送信されるMessage AのRACH preambleを検出し、データ部分を正しく復号できなかった場合もMessage Bを送信する。基地局100は、RACH preambleを検出し、データ部分を正しく復号できなかった場合、この時点では、当該RACH preambleを送信した端末200を特定できない。よって、この場合、例えば、Message Bには、RARが含まれる(換言すると、UE-IDは含まれない)。RARには、例えば、対応するRACH preambleを送信した端末200に対して、データ部分の再送の要求に関する情報及び上りリンクにおいて使用するリソースに関する情報が含まれてもよい。
【0119】
一方、基地局100は、Message A(例えば、PRACH preamble)を検出できなかった場合、対応するMessage Aを送信した端末200宛の情報をMessage Bに含めない。
【0120】
例えば、
図8に示す例では、動作例1(例えば、
図7)と同様、基地局100(gNB)は、UE#Aから送信されたMessage AのPreamble#1を検出し(検出結果:○)、PUSCHを正しく復号する(復号結果:○)。一方、基地局100(gNB)は、UE#Bから送信されたMessage AのPreamble#2を検出し(検出結果:○)、PUSCHを正しく復号できない(復号結果:×)。また、基地局100(gNB)は、UE#Cから送信されたMessage AのPreamble#1を検出できず(検出結果:×)、PUSCHを正しく復号できない(復号結果:×)。
【0121】
よって、
図8に示す例では、基地局100は、UE#Aに対するRAR、UE#AのUE-ID#A、及び、UE#Bに対するRARを含むMessage Bを生成する。換言すると、
図7では、Message Bには、UE#C宛ての情報は含まれない。
【0122】
<Message Bの受信>
Message Aを送信した端末200は、Msg.B reception windowの期間内に当該端末200宛の情報を含むMessage Bを受信しない場合、Message Aを再送する(換言すると、Random access処理をMessage Aの送信から再度行う)。
図8に示す例では、UE#Cは、Msg.B reception windowの期間内にUE#C宛てのMessage Bを受信しないので、Message Aを再送する。
【0123】
一方、Message Aを送信した端末200は、Msg.B reception windowの期間内に当該端末200宛の情報を含むMessage Bを受信したものの、Message Bに含まれるUE-IDが、送信したMessage Aに含めたUE-IDと一致しない場合、Message A(例えば、PRACH preamble)に対応するRARに含まれる情報に従って、上りリンク送信を行う。
図8に示す例では、UE#Bは、Msg.B reception windowの期間内にUE#B宛てのMessage B(例えば、RAR)を受信するものの、当該Message Bに含まれるUE-ID(UE-ID#A)が、送信したMessage Aに含めたUE-ID(UE-ID#B)と一致しないので、RACH procedureが未だ成功していないと判断する(RA procedure:×)。UE#Bは、例えば、Message BのUE#Bに対するRARに含まれる情報に基づいて、PUSCHを再送してもよい。換言すると、UE#Bは、4ステップRandom access procedureのMessage 3の送信へFallbackしてもよい。
【0124】
また、Message Aを送信した端末200は、Msg.B reception windowの期間内に当該端末200宛の情報を含むMessage Bを受信し、Message Bに含まれるUE-IDが、送信したMessage Aに含めたUE-IDと一致する場合、RACH procedureが成功したと判断する。
図8に示す例では、UE#Aは、Msg.B reception windowの期間内にUE#A宛てのMessage Bを受信し、当該Message Bに含まれるUE-ID(UE-ID#A)が、送信したMessage Aに含めたUE-ID(UE-ID#A)と一致するので、RACH procedureが成功したと判断する(RA procedure:○)。
【0125】
以上、2ステップRandom access procedureの動作例1及び2について説明した。
【0126】
上述したように、基地局100がMessage Aを検出及び正しく復号した場合、Message Bには、RARを含むMAC PDU、及び、端末200を識別するためのUE-IDを含めたメッセージ(例えば、Contention resolution MAC CE)を含むMAC PDUが含まれる。
【0127】
また、RARを含むMAC PDUには、例えば、端末200における上りリンク信号の送信タイミングに関する情報、TC-RNTI(Temporary C-RNTI)、又は、端末200が上りリンクで使用するリソースに関する情報が含まれてもよい。
【0128】
また、Message Bには、RAR及びUE-IDを含むMAC PDUの他に、例えば、RRC接続、RRC復帰及びRRC再接続のためのRRC信号を含むMAC PDUが含まれてもよい。
【0129】
図9及び
図10は、Message Bの構成例を示す。
図9は、Message BにRRC信号を含むMAC PDUが含まれない場合の一例を示し、
図10は、Message BにRRC信号を含むMAC PDUが含まれる一例を示す。
【0130】
例えば、端末200は、端末200宛の情報を含むMessage Bを受信し、Message Bに含まれるUE-IDが、送信したMessage Aに含まれるUE-IDと一致している場合、かつ、当該Message Bに端末200宛のRRC信号を含むMAC PDUが含まれている場合、RRC信号を含むMAC PDUを復号し、復号結果(又は、誤り検出結果)に対応するACK/NACK信号を、上りリンクリソース(例えば、PUCCHリソース)において基地局100へ送信する。
【0131】
以下、ACK/NACK信号を送信するPUCCHリソースの決定方法について説明する。
【0132】
基地局100は、例えば、SIB等のセル固有の上位レイヤ信号(例えば、RMSI)によって、PUCCHリソースに関する複数のパラメータの組み合わせを示すリソース設定(例えば、PUCCH resource set)を端末200に予め通知する。例えば、Release 15 NRでは、PUCCH resource setには、16個のPUCCHリソースに関するパラメータの組み合わせが含まれる。なお、PUCCH resource setに含まれるPUCCHリソースに関するパラメータの組み合わせの数は、16個に限定されず、他の個数でもよい。
【0133】
また、基地局100は、Message BをスケジューリングするPDCCH内の一部のビット(例えば、Release 15 NRでは3ビット)と、PDCCHのCCE番号と、追加の通知情報“X”とに基づいて、PUCCH resource setの中から、端末200が実際に用いるPUCCHリソースに関するパラメータの組み合わせを1つ選択する。
【0134】
例えば、PUCCHリソースに関するパラメータの組み合わせrPUCCH(例えば、0~15の16個)は、次式で与えられる。
rPUCCH = ceiling (2nCCE/NCCE) + 2ΔPRI + X (2)
【0135】
式(2)において、nCCEはCCE番号を表し、NCCEはCCE数を表し、ΔPRIはPDCCHの3ビットによって明示的に通知される値(0~7の何れか)を表す。なお、ΔPRIはPDCCHの3ビットに限らず、他のビット数でもよい。
【0136】
このように、端末200は、例えば、Message Bに関するPDCCHによって通知される値(例えば、ΔPRI)と、当該PDCCHが割り当てられるリソース(例えば、nCCE)と、端末200毎に設定されるパラメータ“X”とに基づいて、ACK/NACK信号の送信に用いる上りリンクリソースを決定する。換言すると、端末200は、例えば、4ステップRandom access procedureのMessage 4に対するACK/NACK信号を送信するためのPUCCHリソースを決定する方法(例えば、式(1)を参照)とは異なる方法(例えば、式(2)を参照)に基づいて、Message Bに対するACK/NACK信号を送信するためのPUCCHリソースを決定する。
【0137】
式(2)において、パラメータ“X”は、例えば、以下の方法(Option 1~5の何れか又は組み合わせ)により、明示的(explicit)又は黙示的(implicit)に基地局100から端末200へ通知されてよい。
【0138】
<Option 1>
パラメータ“X”は、Message BのMAC RAR(換言すると、Message A(PRACH preamble)に対する応答に関する情報)に含まれてもよい。
【0139】
RARを含むMAC PDUには、パラメータ“X”の他に、端末200における上りリンクの送信タイミングに関する情報、TC-RNTI、又は端末200が上りリンクで使用するリソースに関する情報が含まれてもよい。
【0140】
<Option 2>
パラメータ“X”は、端末200が送信したMessage Aに含まれるUE-IDと関連付けられた値でもよい。
【0141】
例えば、X = UE-ID mod Yのように関連付けられてもよい。ここで、YはPUCCH resource setに含まれるPUCCHリソースに関する複数のパラメータの組み合わせの数であり、Release 15 NRではY=16である。
【0142】
<Option 3>
パラメータ“X”は、Message Bのおける、複数の端末200宛にそれぞれ対応するRARの配置順番(例えば、RAR orderと呼ぶ)と関連付けられた値でもよい。
【0143】
例えば、
図10に示すMessage Bには、MAC subPDU3A、MAC subPDU4A、…の順にRARが含まれている。また、
図10に示すMessage Bでは、MAC subPDU3Aに対応する端末200宛のRRC信号がMAC subPDU3Cに含まれ、MAC subPDU4Aに対応する端末200宛のRRC信号がMAC subPDU4Cに含まれている。
【0144】
この場合、例えば、Message BにおいてRARが含まれる順番(配置順番)に基づいて、MAC subPDU3C(例えば、1番目のRAR)に対応する端末200に対してはX=0が設定され、MAC subPDU4C(例えば、2番目のRAR)に対応する端末200に対してX=1が設定されてもよい。なお、Message Bに含まれるRARの数、及び、RARの配置順番に関連付けられるXの値は、これらに限定されない。
【0145】
<Option 4>
パラメータ“X”は、端末200が送信するMessage Aにおいて使用されたRACH preamble番号(例えば、PAID)と関連付けられた値でもよい。
【0146】
例えば、X = PAID mod Yのように関連付けられてもよい。ここで、Yは、PUCCH resource setに含まれるPUCCHリソースに関する複数のパラメータの組み合わせの数であり、Release 15 NRではY=16である。
【0147】
<Option 5>
パラメータ“X”は、端末200が送信するMessage Aにおいて使用されたPUSCHの参照信号(例えば、DMRS:Demodulation Reference Signal)のポート番号(例えば、DMRS port番号)と関連付けられた値でもよい。
【0148】
例えば、X = DMRS port index mod Yのように関連付けられてもよい。ここで、YはPUCCH resource setに含まれるPUCCHリソースに関する複数のパラメータの組み合わせの数であり、Release 15 NRではY=16である。
【0149】
以上、パラメータ“X”の通知方法(Option 1~5)について説明した。
【0150】
上述した5つのOptionによれば、PDCCHのオーバヘッドの増加無しに、パラメータ“X”が端末200に通知される。
【0151】
また、例えば、パラメータ“X”を含む式(2)によって、各端末200は、PUCCHリソースに関するパラメータの組み合わせrPUCCHを、端末200毎に選択できる。換言すると、端末200は、グループキャスト送信されるMessage B(換言すると、複数の端末200宛ての信号)に対するACK/NACK信号を送信するPUCCHリソースを、端末200毎にそれぞれ設定されるパラメータ“X”に基づいて個別に決定できる。よって、Message B(例えば、RRC信号)に対するACK/NACK信号の送信において、端末200間におけるPUCCHリソースの衝突を抑制できる。
【0152】
よって、本実施の形態によれば、Message B(例えば、RRC信号を含む)がグループキャスト送信される場合でも、PDCCHのオーバヘッドを増加することなく、当該RRC信号に対するACK/NACK信号の送信において、端末200間におけるPUCCHリソースの衝突を抑制できる。これにより、本実施の形態では、2ステップRandom access procedureのMessage Bにおけるランダムアクセス処理(例えば、再送制御)の効率を向上できる。
【0153】
なお、上述したOption1~5のうち、何れか1つが適用されてもよく、複数のOptionの組み合わせが適用されてもよい。
【0154】
また、本実施の形態において、端末200が、Message BをスケジューリングするPDCCHの一部のビット(例えば、Release 15 NRでは3ビット)、及び、PDCCHのリソース割当情報であるCCE番号に加えて、パラメータ“X”を用いてPUCCHを決定する場合に限定されない。例えば、端末200は、Message BをスケジューリングするPDCCHの一部のビット及びCCE番号を用いずに、パラメータ“X”を用いてPUCCHリソースを決定してもよい。この場合、PDCCHのオーバヘッドを更に削減できる。
【0155】
また、Message Bにおいてグループキャスト型、及び、ユニキャスト型の複数の送信方法がサポートされる場合、端末200は、Message Bの送信方法に応じてPUCCHリソースを決定してもよい。例えば、端末200は、Message Bに対してグループキャスト型送信が設定される場合、パラメータ“X”を用いてPUCCHリソースを決定するのに対し(例えば、式(2)を参照)、ユニキャスト型送信が設定される場合、パラメータ“X”を用いないでPUCCHリソースを決定してもよい(例えば、式(1)を参照)。
【0156】
(実施の形態2)
本実施の形態に係る基地局及び端末は、実施の形態1に係る基地局100及び端末200と基本構成が共通するので、
図4及び
図5を援用して説明する。
【0157】
本実施の形態では、端末200は、上りリンク制御チャネル(例えば、PUCCH)において、Message Bに対するACK/NACK信号を送信する。
【0158】
このとき、基地局100は、ACK/NACK信号を送信するためのPUCCHリソースを、例えば、Message BのRARに含まれる上りリンク割当情報(例えば、ULグラントと呼ぶ)を用いて端末200へ通知する。端末200は、例えば、端末200宛てのMessage BのRARに含まれるULグラントに基づいて、Message B(例えば、RRC信号)に対するACK/NACK信号を送信するためのPUCCHリソースを決定する。
【0159】
例えば、実施の形態1における2ステップRandom access procedureの動作例2(例えば、
図8を参照)では、基地局100は、Message Aを検出及び正しく復号した場合、Message Bを送信する。このとき、Message Bには、RAR及び端末200を識別するためのUE-IDを含めたメッセージが含まれる。
【0160】
本実施の形態では、基地局100は、Message Aを検出及び正しく復号した場合、RARに含まれるULグラントにおいて、Message B(例えば、RRC信号)に対するACK/NACK信号を送信するための上りリンクリソース(例えば、PUCCHリソース)を通知する。端末200は、例えば、端末200宛ての情報を含むMessage Bを受信し、Message Bに含まれるUE-IDがMessage Aで送信したUE-IDと一致している場合、かつ、Message Bに端末200宛てのRRC信号を含むMAC PDUが含まれている場合、MAC PDUを復号し、復号結果(例えば、ACK/NACK信号)を、ULグラントで通知されたPUCCHリソースにおいて基地局100へ送信する。
【0161】
例えば、
図8に示す例では、基地局100(gNB)は、UE#Aから送信されたMessage AのPreamble#1を検出し(検出結果:○)、PUSCHを正しく復号する(復号結果:○)。そこで、基地局100は、Message Bにおいて、UE#Aに対するRARに含まれるULグラントに、Message Bに対するACK/NACK信号を送信するためのPUCCHリソースを設定する。UE#Aは、Message Bに含まれるUE#Aに対するRARに含まれるULグラントに示されるPUCCHリソースに基づいて、Message Bに対するACK/NACK信号を送信する。
【0162】
また、実施の形態1における2ステップRandom access procedureの動作例2(例えば、
図8を参照)では、基地局100は、Message AのRACH preambleを検出し、データ部分を正しく復号できなかった場合もMessage Bを送信する。このとき、Message Bには、RARが含まれる。RARには、例えば、対応するRACH preambleを送信した端末200に対して、データ部分の再送の要求に関する情報、及び、端末200が上りリンクで使用するリソースに関する情報(ULグラント)が含まれてもよい。
【0163】
本実施の形態では、例えば、基地局100は、Message A(
図8では、UE#BのMessage A)のRACH preambleを検出し、データ部分を正しく復号できなかった場合、RARに含まれるULグラントにおいて、Message Aにおけるデータ部分(例えば、PUSCH)を再送するための上りリンクリソース(例えば、PUSCHリソース)を通知する。端末200(
図8では、UE#B)は、Message Bの端末200に対するRARに含まれるULグラントに示されるPUSCHリソースに基づいて、Message Aのデータ部分(例えば、PUSCH)を再送する。
【0164】
なお、RARには、ULグラントによってMessage A(例えば、PUSCH)の再送のための上りリンクリソースが通知されるのか、Message Bに対するACK/NACK信号を送信するためのPUCCHリソースが通知されるのかを識別するフラグが含まれてもよい。
【0165】
Release 15 NRでは、例えば、RARに含まれるULグラントは27ビットのフィールドで構成される。本実施の形態では、例えば、Message Bに対するACK/NACK信号を送信するためのPUCCHリソースの通知には、ULグラントに含まれる27ビットフィールドの一部が使用されてもよい。なお、ULグラントに含まれるフィールドのサイズは27ビットに限定されない。
【0166】
また、例えば、Release 15 NRと同様にPUCCH resource setに含まれるPUCCHリソースに関する複数のパラメータの組み合わせの数が16である場合、Message Bに対するACK/NACK信号を送信するためのPUCCHリソースの通知に4ビットが使用され、残りのフィールドをその他の用途又はReservedとしてもよい。なお、PUCCHリソースの通知に使用されるビット数は4ビットに限定されない。
【0167】
本実施の形態によれば、基地局100は、Message BのRARに含まれるULグラントによって、Message Bに対するACK/NACK信号を送信するためのPUCCHリソースを通知する。換言すると、基地局100は、Message Bの各端末200に対するRARに含まれるULグラントにおいて、端末200毎のPUCCHリソースをそれぞれ設定(換言すると、スケジューリング)できる。
【0168】
これにより、端末200は、グループキャスト送信されるMessage B(換言すると、複数の端末200宛ての信号)に対するACK/NACK信号を送信するPUCCHリソースを、端末200毎にそれぞれ設定されるULグラントに基づいて個別に決定できる。よって、Message B(例えば、RRC信号)に対するACK/NACK信号の送信において、端末200間におけるPUCCHリソースの衝突を抑制できる。
【0169】
また、基地局100は、PDCCH(換言すると、DCI)によってPUCCHリソースを通知しなくてもよいので、PDCCHのオーバヘッドを削減できる。
【0170】
(実施の形態3)
本実施の形態に係る基地局及び端末は、実施の形態1に係る基地局100及び端末200と基本構成が共通するので、
図4及び
図5を援用して説明する。
【0171】
本実施の形態では、端末200は、上りリンクデータチャネル(例えば、PUSCH)において、Message Bに対するACK/NACK信号を送信する。
【0172】
このとき、基地局100は、ACK/NACK信号を送信するためのPUSCHリソースを、例えば、Message BのRARに含まれるULグラントを用いて端末200へ通知する。端末200は、例えば、端末200宛てのMessage BのRARに含まれるULグラントに基づいて、Message B(例えば、RRC信号)に対するACK/NACK信号を送信するためのPUSCHリソースを決定する。
【0173】
例えば、実施の形態1における2ステップRandom access procedureの動作例2(例えば、
図8を参照)では、基地局100は、Message Aを検出及び正しく復号した場合、Message Bを送信する。このとき、Message Bには、RAR及び端末200を識別するためのUE-IDを含めたメッセージが含まれる。
【0174】
本実施の形態では、基地局100は、Message Aを検出及び正しく復号した場合、RARに含まれるULグラントにおいて、Message B(例えば、RRC信号)に対するACK/NACK信号を送信するための上りリンクリソース(例えば、PUSCHリソース)を通知する。端末200は、例えば、端末200宛ての情報を含むMessage Bを受信し、Message Bに含まれるUE-IDがMessage Aで送信したUE-IDと一致している場合、かつ、Message Bに端末200宛てのRRC信号を含むMAC PDUが含まれている場合、MAC PDUを復号し、復号結果(例えば、ACK/NACK信号)を、ULグラントで通知されたPUSCHリソースにおいて基地局100へ送信する。
【0175】
例えば、
図8に示す例では、基地局100(gNB)は、UE#Aから送信されたMessage AのPreamble#1を検出し(検出結果:○)、PUSCHを正しく復号する(復号結果:○)。そこで、基地局100は、Message Bにおいて、UE#Aに対するRARに含まれるULグラントに、Message Bに対するACK/NACK信号を送信するためのPUSCHリソースを設定する。UE#Aは、Message Bに含まれるUE#Aに対するRARに含まれるULグラントに示されるPUSCHリソースに基づいて、Message Bに対するACK/NACK信号を送信する。
【0176】
また、実施の形態1における2ステップRandom access procedureの動作例2(例えば、
図8を参照)では、基地局100は、Message AのRACH preambleを検出し、データ部分を正しく復号できなかった場合もMessage Bを送信する。このとき、Message Bには、RARが含まれる。RARには、例えば、対応するRACH preambleを送信した端末200に対して、データ部分の再送の要求に関する情報、及び、端末200が上りリンクで使用するリソースに関する情報(ULグラント)が含まれてもよい。
【0177】
本実施の形態では、例えば、基地局100は、Message A(
図8では、UE#BのMessage A)のRACH preambleを検出し、データ部分を正しく復号できなかった場合、RARに含まれるULグラントにおいて、Message Aにおけるデータ部分(例えば、PUSCH)を再送するための上りリンクリソース(例えば、PUSCHリソース)を通知する。端末200(
図8では、UE#B)は、Message Bの端末200宛てのRARに含まれるULグラントに示されるPUSCHリソースに基づいて、Message Aのデータ部分(例えば、PUSCH)を再送する。
【0178】
なお、本実施の形態では、例えば、
図6において、Message Bに対するACK/NACK送信のためのPUCCHリソースに関する情報の送信及び取得する処理(例えば、ST101及びST102の処理)は不要である。
【0179】
また、PUSCHにおけるACK/NACK信号のマッピング方法については、例えば、以下の2つの方法の何れかを適用してもよい。
【0180】
1つ目の方法は、UL-SCH(UL Shared Channel)と同様に、ACK/NACK信号をデータ部分と同様の方法でPUSCHにマッピングする方法である。この場合、ACK/NACK信号は、ULグラントによって通知されたMCSに従って送信される。
【0181】
2つ目の方法は、ACK/NACK信号を、例えば、Release 15 NRにおいてUL-SCHが無い場合にUCI(Uplink Control Information)をPUSCH上に多重する方法(例えば、非特許文献2及び3を参照)でPUSCHにマッピングする方法である。この場合、ACK/NACK信号は、ULグラントによって通知されたMCSと比較して低いMCSに従って送信されてもよい。
【0182】
本実施の形態によれば、基地局100は、Message BのRARに含まれるULグラントによって、Message Bに対するACK/NACK信号を送信するためのPUSCHリソースを通知する。換言すると、基地局100は、Message Bの各端末200に対するRARに含まれるULグラントにおいて、端末200毎のPUSCHリソースをそれぞれ設定(換言すると、スケジューリング)できる。
【0183】
これにより、端末200は、グループキャスト送信されるMessage B(換言すると、複数の端末200宛ての信号)に対するACK/NACK信号を送信するPUSCHリソースを、端末200毎にそれぞれ設定されるULグラントに基づいて個別に決定できる。よって、Message B(例えば、RRC信号)に対するACK/NACK信号の送信において、端末200間におけるPUSCHリソースの衝突を抑制できる。
【0184】
また、基地局100は、PDCCH(換言すると、DCI)によってPUSCHリソースを通知しなくてもよいので、PDCCHのオーバヘッドを削減できる。
【0185】
また、本実施の形態では、Message BのRARに含まれるULグラントによって、Message A(例えば、PUSCH)の再送のためのPUSCHリソース、又は、Message Bに対するACK/NACK信号を送信するためのPUSCHリソースが通知される。換言すると、本実施の形態では、基地局100におけるMessage Aの検出及び復号結果に依らず、Message BのRARにおいて通知されるリソースは、PUSCHリソースである。よって、本実施の形態によれば、RARのULグラントによって通知される情報は、基地局100におけるMessage Aの復号結果に応じて変更しなくてよいので、RARの構成を簡易化できる。
【0186】
以上、本開示の一実施例について説明した。
【0187】
上述した各実施の形態では、端末200がMessage Bに対するACK/NACK信号(ACK又はNACK)を送信する場合について説明した。しかし、端末200は、例えば、Message Bの復号に失敗した場合にNACKを基地局100へ送信し、Message Bの復号に成功した場合にはACKを基地局100へ送信しなくてもよい。
【0188】
例えば、端末200は、Message BをスケジューリングするPDCCHを正しく復号し、かつMessage Bに含まれるMAC PDUを正しく復号した場合、ランダムアクセス動作が正しく完了したと判断する。また、端末200は、基地局100に対してACKを送信しない。
【0189】
一方、端末200は、Message BをスケジューリングするPDCCHを正しく復号したものの、Message Bに含まれるMAC PDUを正しく復号できなかった場合、NACKを基地局100へ送信し、Message Bの再送を要求する。
【0190】
また、端末200は、NACKの送信タイミングからTimerを動作させてもよい。基地局100は、端末200が送信したNACKの受信に成功した場合、Message Bを再送する。一方、基地局100は、端末200が送信したNACKの受信に失敗した場合、端末200がMessage Bの受信に成功したと判断し、Message Bの再送を行うことができない。このとき、端末200は、NACKの送信タイミングから動作させたTimerが一定期間を超えた場合、RACH動作を再度行う。
【0191】
このように、端末200は、ACKを送信しないので、上りリンクリソースのオーバヘッドを低減でき、端末200の消費電力を低減できる。
【0192】
また、上述した各実施の形態では、端末200はMessage Bの復号に成功した場合にACKを基地局100へ送信し、Message Bの復号に失敗した場合にはNACKを基地局100へ送信しなくてもよい。
【0193】
例えば、Message Bに、RARを含むMAC PDUと、端末を識別するための識別情報(例えば、UE-ID)を含めたメッセージ(例えば、Contention resolution MAC CE)を含むMAC PDUとが含まれる場合、端末200は、Message Bの復号に失敗した場合、復号を試みたMessage Bが自端末宛かどうかを識別することができない。そのため、端末200は、基地局100に対してNACKを送信しなくてもよい。
【0194】
本開示はソフトウェア、ハードウェア、又は、ハードウェアと連携したソフトウェアで実現することが可能である。上記実施の形態の説明に用いた各機能ブロックは、部分的に又は全体的に、集積回路であるLSIとして実現され、上記実施の形態で説明した各プロセスは、部分的に又は全体的に、一つのLSI又はLSIの組み合わせによって制御されてもよい。LSIは個々のチップから構成されてもよいし、機能ブロックの一部または全てを含むように一つのチップから構成されてもよい。LSIはデータの入力と出力を備えてもよい。LSIは、集積度の違いにより、IC、システムLSI、スーパーLSI、ウルトラLSIと呼称されることもある。集積回路化の手法はLSIに限るものではなく、専用回路、汎用プロセッサ又は専用プロセッサで実現してもよい。また、LSI製造後に、プログラムすることが可能なFPGA(Field Programmable Gate Array)や、LSI内部の回路セルの接続や設定を再構成可能なリコンフィギュラブル・プロセッサを利用してもよい。本開示は、デジタル処理又はアナログ処理として実現されてもよい。さらには、半導体技術の進歩または派生する別技術によりLSIに置き換わる集積回路化の技術が登場すれば、当然、その技術を用いて機能ブロックの集積化を行ってもよい。バイオ技術の適用等が可能性としてありえる。
【0195】
本開示は、通信機能を持つあらゆる種類の装置、デバイス、システム(通信装置と総称)において実施可能である。通信装置は無線送受信機(トランシーバー)と処理/制御回路を含んでもよい。無線送受信機は受信部と送信部、またはそれらを機能として、含んでもよい。無線送受信機(送信部、受信部)は、RF(Radio Frequency)モジュールと1または複数のアンテナを含んでもよい。RFモジュールは、増幅器、RF変調器/復調器、またはそれらに類するものを含んでもよい。通信装置の、非限定的な例としては、電話機(携帯電話、スマートフォン等)、タブレット、パーソナル・コンピューター(PC)(ラップトップ、デスクトップ、ノートブック等)、カメラ(デジタル・スチル/ビデオ・カメラ等)、デジタル・プレーヤー(デジタル・オーディオ/ビデオ・プレーヤー等)、着用可能なデバイス(ウェアラブル・カメラ、スマートウオッチ、トラッキングデバイス等)、ゲーム・コンソール、デジタル・ブック・リーダー、テレヘルス・テレメディシン(遠隔ヘルスケア・メディシン処方)デバイス、通信機能付きの乗り物又は移動輸送機関(自動車、飛行機、船等)、及び上述の各種装置の組み合わせがあげられる。
【0196】
通信装置は、持ち運び可能又は移動可能なものに限定されず、持ち運びできない又は固定されている、あらゆる種類の装置、デバイス、システム、例えば、スマート・ホーム・デバイス(家電機器、照明機器、スマートメーター又は計測機器、コントロール・パネル等)、自動販売機、その他IoT(Internet of Things)ネットワーク上に存在し得るあらゆる「モノ(Things)」をも含む。
【0197】
通信には、セルラーシステム、無線LANシステム、通信衛星システム等によるデータ通信に加え、これらの組み合わせによるデータ通信も含まれる。
【0198】
また、通信装置には、本開示に記載される通信機能を実行する通信デバイスに接続又は連結される、コントローラやセンサー等のデバイスも含まれる。例えば、通信装置の通信機能を実行する通信デバイスが使用する制御信号やデータ信号を生成するような、コントローラやセンサーが含まれる。
【0199】
また、通信装置には、上記の非限定的な各種装置と通信を行う、あるいはこれら各種装置を制御する、インフラストラクチャ設備、例えば、基地局、アクセスポイント、その他あらゆる装置、デバイス、システムが含まれる。
【0200】
本開示の一実施例に係る端末は、複数の端末向けの下りリンク信号に対する応答信号の送信に用いるリソースを、前記複数の端末毎にそれぞれ設定されるパラメータに基づいて決定する制御回路と、前記リソースにおいて前記応答信号を送信する送信回路と、を具備する。
【0201】
本開示の一実施例において、前記制御回路は、前記下りリンク信号に関する制御情報によって通知される値、前記制御情報が割り当てられるリソース、及び、前記パラメータに基づいて、前記リソースを決定する。
【0202】
本開示の一実施例において、前記下りリンク信号は、前記複数の端末がそれぞれ送信するランダムアクセス信号に対する応答に関する情報を含み、前記パラメータは、前記応答に関する情報に含まれる。
【0203】
本開示の一実施例において、前記下りリンク信号は、前記複数の端末がそれぞれ送信するランダムアクセス信号に対する応答に関する情報を含み、前記パラメータは、前記ランダムアクセス信号に含まれる前記複数の端末をそれぞれ識別する情報に関連付けられた値を示す。
【0204】
本開示の一実施例において、前記下りリンク信号は、前記複数の端末がそれぞれ送信するランダムアクセス信号に対する応答に関する情報を含み、前記パラメータは、前記下りリンク信号における、前記複数の端末にそれぞれ対応する前記応答に関する情報の配置順番に関連付けられた値を示す。
【0205】
本開示の一実施例において、前記下りリンク信号は、前記複数の端末がそれぞれ送信するランダムアクセス信号に対する応答に関する情報を含み、前記パラメータは、前記ランダムアクセス信号において使用されたプリアンブル番号に関連付けられた値を示す。
【0206】
本開示の一実施例において、前記下りリンク信号は、前記複数の端末がそれぞれ送信する、プリアンブル部及びデータ部を含むランダムアクセス信号に対する応答に関する情報を含み、前記パラメータは、前記データ部において使用された参照信号のポート番号に関連付けられた値を示す。
【0207】
本開示の一実施例において、前記下りリンク信号は、前記複数の端末がそれぞれ送信するランダムアクセス信号に対する応答に関する情報を含み、前記パラメータは、前記応答に関する情報に含まれる上りリンクリソース割当情報である。
【0208】
本開示の一実施例において、前記リソースは、上りリンク制御リソースである。
【0209】
本開示の一実施例において、前記リソースは、上りリンクデータリソースである。
【0210】
本開示の一実施例に係る送信方法は、複数の端末向けの下りリンク信号に対する応答信号の送信に用いるリソースを、前記複数の端末毎にそれぞれ設定されるパラメータに基づいて決定し、前記リソースにおいて前記応答信号を送信する。
【0211】
2019年3月27日出願の特願2019-061499の日本出願に含まれる明細書、図面および要約書の開示内容は、すべて本願に援用される。
【産業上の利用可能性】
【0212】
本開示の一実施例は、移動通信システムに有用である。
【符号の説明】
【0213】
100 基地局
101,209 制御部
102 データ生成部
103,107,110,212,214 符号化部
104 再送制御部
105,108,111,213,215 変調部
106 上位制御信号生成部
109 下り制御信号生成部
112,216 信号割当部
113,217 IFFT部
114,218 送信部
115,201 アンテナ
116,202 受信部
117,203 FFT部
118,204 抽出部
119 検出部
120,205 復調部
121,206,208 復号部
200 端末
207 下り制御信号復調部
210 PRACH preamble生成部
211 ACK/NACK生成部