NR随机接入之MSG2

更多NR协议分享，请关注微信公众号—沧海Radio

1. NR MSG2基础

MSG2是随机过程中UE与gNB的第二次握手。由于在UE成功解出MSG2之前，gNB与UE之前没有完成初始同步，所以MSG2没有基于HARQ的重传机制。MSG2存在两种形式：C-RNTI加扰的DCI和RAR PDU。其中C-RNTI加扰的DCI是NR针对BFR场景新增的。如果gNB为BFR配置了专用的RACH资源，则UE需要在BFR搜索空间内检测C-RNTI加扰的DCI。其他所有随机接过程的MSG2，均是由RA-RNTI加扰的DCI调度的RAR PDU。非竞争BFR之所以可以如此任性是因为此时UE既没有失步，也不需要与其他UE竞争，并且gNB可以通过MSG1识别出该UE的身份。而其他场景，在收MSG2之前，UE仅完成下行同步以及preamble的发送，此时gNB还尚未给该UE分配身份。3GPP通过UE发送preamble使用的时频资源来作为该阶段UE的身份标识，即RA-RNT，
RA-RNTI = 1 + s_id + 14 × t_id + 14 × 80 × f_id + 14 × 80 × 8 × ul_carrier_id
RAR PDU由一个或多个RAR subPDU以及可选的padding（下行授权大于RAR subPDU所需要时，padding存在）组成。为什么会出现多个RAR subPDU复用在同一个RAR PDU中呢？这是因为在竞争解决场景，多个UE可能使用相同的时频资源发送，由上面的RA-RNTI计算公式可知，此时的多个UE的RA-RNTI的值是相同的，因此多个RAR subPDU可能会复用在一个MAC RAR PDU中。RAR subPDU有如下3中形式：
1）仅含有BI字段的MAC subheader(type1)

图1 type1 RAR subPDU 图中字段E==1:表示该RAR subPDU后还有其他RAR subPDU，E==0:表示这是RAR PDU中的最后一个subPDU；T==0:表示subheader包含BI，T==1:表示subheader包含RAPID；BI用于指示BI timer的取值，如表1所示。当UE随机接入失败再次发起前，UE需要等待rand()%BI timer时间后，再次发起随机接入。这样设计可以将UE接入冲突随机化，减小发生冲突的概率。基站可以根据当前发生冲突UE的个数结合自身的调度策略，选择合适的BI值。简单的来说就是发生冲突的UE个数少时，选择较小的BI；发生冲突的UE个数多时，选择较大的BI。从上面的分析看，UE等待的时间是随机的，因此可以完全不等，直接再次随机接入。对于这种不遵守游戏规则的UE，如何处理呢（读者可以在公众号中留言）？表1 BI取值

2）仅含有RAPID字段的MAC subheader(type2)
这种格式仅用于非竞争的SI Request场景。因为SI Request仅是为了获取系统消息，不需要实现UE与gNB之间的上行同步，也不需要上行授权等信息，SI Request成功的UE依然保持原有状态（idle或inactive），故CFRA场景下UE不需要MAC RAR。
Note: RAPID就是UE发送Preamble的Index。

图2 type2 RAR subPDU 3）含有RAPID字段的MAC subheader + MAC RAR(type3)

图3 type3 RAR subPDU 由于type3和type2中均包含RAPID，因此UE如果发现SIB1中配置了用于SI Request的专用RACH资源时，需要先比较RAPID是否为SI Request的Preamble。MAC RAR中的Timing Advance Command是用来实现上行同步的，调整UE的TA；Temporary C-RNTI是gNB分配给UE在RAN侧的临时身份标识；27bits的UL Grant包含了UE的上行调度信息，具体表2所示，表中各字段的含义在下面章节中体现。表2 RAR Grant信息

Note：type1 RAR subPDU需要在RAR PDU的最前面（这里留这个问题：为什么需要将仅含BI的SubPDU放在RAR PDU的最前面），Padding放在RAR PDU的最后面。

2. UE RAR处理

UE发送MSG1之后，RAR的处理如图4所示，此外UE还需要调整TA。对于非竞争随机接入，UE在成功解出MSG2后即完成CFRA过程。如果随机接入是SI Request发起的CFRA，MSG2成功后，MAC需要发送消息通知RRC接收SIB消息，这种场景UE可以不调整TA。如果是CBRA，UE需要保存TC-RNTI以用于解MSG3重传的DCI或MSG4的DCI（MSG4的DCI也可能是C-RNTI加扰的）。MSG2的处理在协议上是属于MAC的，但是UE可以在L1实现（MAC功能的下沉在UE和gNB实现中是目前比较常见的一种设计方式）。

图4 UE的MSG2处理流程

3. gNB RAR处理

相对UE来说，基站侧MSG2相关的处理就要复杂的多。首先基站需要根据自身的调度能力、小区用户量、MSG2调度策略、帧结构、随机接入场景等因素配置RAR窗（ra-ResponseWindow）的大小。根据基站的MSG2的处理策略，基站在收到MSG1后可以维护RAR窗，也可以不维护。
基站在每个有效的RO上周期性检测Preamble，可以设置一些门限，比如要求功率大于一定值时，才认为是有效的Preamble；检测到有效的MSG1之后，基站需要根据MSG1的类型进行不同的处理或分配不同大小的MSG3授权。
♦CFRA：
1）SI Request：通知RRC，组仅包含RAPID的RAR
2）BFR：基站需要结合自身的波束管理策略通过DCI来响应UE，该DCI可以携带上行授权，也可以携带下行授权，甚至是不携带任何有效授权。
3）其他：基站需要组type3 RAR subPDU，这个分支比较复杂些，基站需要根据MSG1的类型（Group A/B）分配上行授权，需要考虑诸如是否限制单个slot内调度的RAR个数、如果限制了，限制多少合适、MSG3是否需要跳频，采用什么波形等等一些列问题
♦CBRA：
1）同CFRA其他分支
此外上述过程还涉及CCE、PUSCH（PDSCH）等资源的分配策略以及AMC、功控内容，但这些属于设备厂家的实现策略，是基站软实力的核心，这里就不做详细描述了。
在上述各步骤的处理完后，gNB需要将具有相同RA-RNTI的SDU组合成RAR PDU，在分配的下行调度机会中广播给UE。
最后贴个之前同事经常问的一个小问题：非竞争随机接入MSG2为什么还需要上行授权（波束失败恢复/SI Request除外）？
MSG2中的上行授权是用于传输业务而非MSG3，例如对于非竞争切换，RAR授权用于传输重配完成信令，可以省去UE发起SR的过程。而非竞争的BFR以及SI Request主要是为了完成两次握手过程。

Reference:

[1]3GPP TS 38.321: “NR; Medium Access Control (MAC) protocol specification”.38.213
[2]3GPP TS 38.331: “NR; Radio Resource Control (RRC); Protocol specification”.
[3]3GPP TS 38.213: “NR; Physical Layer Procedures for control”.
更多内容请关注微信公众号—沧海Radio