终端向基站发送了Msg1,很自然期望得到基站的Msg2(RAR)响应。本文主要针对Msg2讲两个重要的问题:1)终端如何接收Msg2?2)Msg2里面有什么?
终端如何接收Msg2
In response to a PRACH transmission, a UE attempts to detect a DCI format 1_0 with CRC scrambled by acorresponding RA-RNTI during a window controlled by higher layers (摘自38213)
这句话其实是对终端如何接收Msg2做了一个总结概括,涉及到以下几个步骤:
UE首先需要去解析用于Msg2的下行调度的PDCCH DCI。那么UE在什么时间去监听PDCCH DCI。这里面有个window的概念,UE在这个窗口内去监听PDCCH。window的长度由参数ra-ResponseWindow规定(不能超过10ms),单位是slot。window的起点是距离PRACH发送之后至少间隔1个symbol的用于Typ1-PDCCH CSS的CORESET的首个symbol。听起来有点绕,一般情况都是PRACH发送完之后的第一个下行slot作为起点(下面是协议的描述)。
The window starts at the first symbol of the earliest CORESET the UE is configured to receive PDCCH for Type1-PDCCH CSS set, as defined in Subclause 10.1, that is at least one symbol, after the last symbol of the PRACH occasion corresponding to the PRACH transmission (摘自38213)
ra-ResponseWindow: Msg2 (RAR) window length in number of slots. The network configures a value lower than or equal to 10 ms (see TS 38.321 [3], clause 5.1.4). (摘自38331)
要监听的DCI的格式是format 1_0。这个DCI需要去Common Search Space去找,由参数ra-SearchSpace定义。
基站对这个PDCCH DCI的CRC使用了RA-RNTI扰码,所以终端需要在ra-searchspace上面尝试使用RA-RNTI去解析PDCCH DCI。
如果UE成功的使用RA-RNTI解调了DCI。接着它会去解PDSCH payload
如果UE继续成功的解出了PDSCH,UE会检查RAPID(random access preamble identity)是否与自己当时发送Msg1时使用的RACH preamble ID相同。如果相同,UE认为Msg2解调成功
如果UE在ra-ResponseWindow内没有使用RA-RNTI解出DCI,或者没有成功解出PDSCH payload,或者解出了PDSCH但是RAPID不匹配,UE都会认为Msg2接收失败,会触发Msg1重发
Msg2里面有什么
6.1.5 MAC PDU (Random Access Response)
A MAC PDU consists of one or more MAC subPDUs and optionally padding. Each MAC subPDU consists one of the following:
a MAC subheader with Backoff Indicator only;
a MAC subheader with RAPID only (i.e. acknowledgment for SI request);
a MAC subheader with RAPID and MAC RAR.