NR随机接入（二）

184 阅读 0 评论 122 点赞

我是靠谱客的博主畅快路灯，最近开发中收集的这篇文章主要介绍NR随机接入（二），觉得挺不错的，现在分享给大家，希望可以做个参考。

概述

LTE和NR的随机接入总体来说十分相似，都包含两种方式 —— CBRA（Contention Based Random Access）和CFRA（Contention Free Random Access），即基于“竞争”的随机接入和基于“非竞争”的随机接入。
为什么会出现“竞争”？
一方面，网络资源是有限的，在同一时间（准确的说，是时机），基站只能处理有限UE的请求。
另一方面，用户标识也是问题，在随机接入前（特别是，在初始接入中），UE无法发送RRC消息和NAS消息，这就意味着，UE无法将自己的身份（比如说，IMSI或IMEI）告知网络。
因此，随机接入还要考虑系统容量和用户识别。在LTE和NR中，随机接入是这么实现的：基站通过系统广播（比如初始接入场景）或RRC消息（比如HO或SN Addition场景）提前告知UE可用的Random Access Preamble，UE从中选择一个作为自己的临时标识，向基站发送随机接入请求（Random Access Preamble）。
Random Access Preamble即随机接入前导码，简称Preamble。Preamble的数量和（单位时间内）PRACH Occasion的数量，实际就决定了小区的随机接入容量。用于随机接入的资源（PRACH）增加，随机接入的容量就会增加，但相应的，用于上行数据的资源也会减少。因而，随机接入的资源配置，要结合小区的业务模型进行考虑。

我们先不去关心Preamble具体长啥样，这里只要知道，在一个小区中，每个Preamble和一个Preamble Index（索引）关联，如果UE收到Random Access Response，并且包含UE选择的Preamble对应的Preamble Index，UE就认为基站响应了自己的请求。
在这里插入图片描述
这个机制的问题是，在同一时机（PRACH Occasion），如果请求UE比Preamble多，必然会出现不同UE选择了同一Preamble的情况（抽屉原理：如果放入抽屉的球比抽屉多，必然存在一个抽屉放入的球数量多于一个），就算请求UE没这么多，UE之间不会“打招呼”（甚至不会感知对方的存在），即使只有两个UE，依然存在“Preamble碰撞”的可能，此时UE之间就存在“竞争” —— 大家都选了这个Preamble，如果基站响应，算是答应了谁呢？
UE可以不管那么多，反正其他UE都是透明的（旁若无人）。既然基站响应了，UE就使用UL Grant指示的PUSCH资源发送上行消息，内容取决于随机接入场景，比如说，在初始接入中是RRC SETUP REQUEST，在RRC恢复中是RRC RESUME REQUEST。当然，UE知道可能存在“竞争者”（使用相同PRACH Occasion，且选择相同Preamble的UE），为了确认基站到底答应了谁，UE在请求中附带自己的ID，如果基站的第二条响应携带相同的ID（或在RRC CONNECTED状态中，基站使用相同的ID（C-RNTI）加扰），说明UE在“竞争”中胜出，随机接入成功，否则，说明UE在“竞争”中落选，随机接入失败。
在这里插入图片描述
以上就是CBRA的大致过程，UE和基站之间共有两次交互，四条消息依次称为MSG1（Random Access Preamble，上行）、MSG2（Random Access Response，下行）、MSG3（Schedule Transmission，上行）、MSG4（Contention Resolution，下行）。如果UE没有成功收到MSG2，或没有成功收到MSG4，都意味着随机接入失败，UE如果还没死心，只能 ——

一二三四，再来一次。

CFRA倒是不用竞争。不过，这事儿不能UE说了算，还得“上面有人”。因此，UE主动触发的随机接入场景，包括初始接入、RRC重建、RRC恢复、上行数据到达（没有用于SR的PUCCH资源，或上行失步）等，只能使用CBRA；基站指示触发的随机接入场景，包括HO、SN Addition（以上为RRC触发）；或下行数据到达（上行失步）、Secondary TAG上行同步、为定位UE获取UE的TA（以上为PDCCH order触发）等，才可能使用CFRA。波束恢复和on-demand SI Request较为特殊（也是UE主动触发的随机接入），UE可能使用CBRA，也可能使用CFRA。
沿用上面的例子，老王把部分数字单独划出来，告诉有关系的学生（暗箱操作，通常是RRC CONNECTED状态的UE，on-demand SI Request除外），不就没有“竞争”啦。相似的，基站把部分Preamble作为Dedicated Preamble，提前分配给UE（HO或SN Addition场景）或SI（on-demand SI Request场景），UE使用Dedicated Preamble发送MSG1，基站一看就知道是“自己人”—— Pass！

基站可以对CBRA使用的Preamble进行分组，通过UE选择的Preamble获得一些先验信息（基站不知道，需要UE告诉基站的信息）。更具体的，基站将CBRA使用的Preamble分为group A和group B，如果UE后续发送的MSG3较大，且路损（pathloss，通过基站发送功率和UE接收功率计算获得）小于配置阈值，UE选择group B的Preamble，否则，选择group A的Preamble。基站通过UE选择的Preamble，就可以在MSG2中给MSG3分配合适的上行资源。基站也可以不对CBRA使用的Preamble进行分组（group B不存在），但为了保证MSG3的传输，需要给MSG3分配较多的上行资源（就高不就低），可能会造成资源的浪费。
UE和基站都知道哪些是Dedicated Preamble。在CFRA中，UE和基站不用发送MSG3和MSG4，如果UE收到包含MSG1（Random Access Preamble）对应Preamble Index的MSG2（Random Access Response），就认为随机接入成功。在HO或SN Addition场景的CFRA中，Dedicated Preamble和UE对应，在on-demand SI Request场景的CFRA中，Dedicated Preamble和SI对应。

注意：在HO或SN Addition场景中，即使UE获得Dedicated Preamble，UE也不一定以CFRA方式随机接入。原因是，基站分配的Dedicated Preamble可能和某个SSB波束关联（基于UE此前的测量报告），如果UE收到RRC重配时，Dedicated Preamble对应的SSB波束已经不满足门限（比如RSRP）要求，UE可能会选择其他SSB波束，以CBRA方式随机接入。
再具体一点。

从LTE和NR的信道映射关系可以看到，只有MSG1（Random Access Preamble）在特殊的物理信道 —— PRACH传送，MSG2、MSG3和MSG4都在PDSCH或PUSCH传送。换句话说，除了MSG1，其他消息都和普通数据一样传输，这样可以简化系统（物理层）设计，还可以利用MAC的HARQ（Hybrid Automatic Repeat Request）机制。
在这里插入图片描述

不过，HARQ只用于MSG3和MSG4，不用于MSG2。原因是，MSG2携带了基站根据MSG1估计的TA（Timing Advance）。TA的大小和UE发送MSG1时所在位置密切相关，如果MSG2重传数次后UE才收到，UE所在位置（可能）已经发生较大变化，MSG2携带的TA就不适用了（黄花菜都凉了）。
MSG2、MSG3、MSG4都有加扰（Scramble），但使用不同的扰码。对于MSG2，基站不知道请求UE是谁，不能使用某个具体的C-RNTI加扰，使用RA-RNTI（Random Access Radio Network Temporary Identifier）加扰；对于MSG3，UE可能还没有C-RNTI（RRC IDLE状态），或即使有C-RNTI（RRC CONNECTED状态），竞争也尚未解决，因而UE使用（MSG2携带的）TC-RNTI加扰；对于MSG4，如果在随机接入前，UE已经处于RRC CONNECTED状态（MSG3包含C-RNTI MAC CE），基站使用C-RNTI加扰，否则，基站使用TC-RNTI加扰。
RA-RNTI和PRACH Occasion（发送Preamble的时频位置）有关，UE和基站分别根据PRACH Occasion计算RA-RNTI，实现MSG2的加扰和解扰。在LTE和NR中，RA-RNTI的计算方法有点不同，这也反映了PRACH Occasion分布的差异。在LTE中，RA-RNTI = 1 + t_id + 10 * f_id。其中，t_id表示PRACH第一个子帧（在一个系统帧中）的索引（即子帧号），取值为0~9；f_id表示同一子帧上不同PRACH Occasion在频域上的索引，按照频率由小到大的顺序，取值为0~5。

在LTE中，FDD每个子帧（subframe）只有1个PRACH资源，f_id固定为0。在时域上，TDD上行资源相比FDD稀疏很多（时分复用，大部分资源分配给了下行），为了实现和FDD相近的PRACH容量，TDD通过FDM（频率复用）增加PRACH资源，因而f_id取值为0~5，同一子帧最多有6个PRACH资源。
在这里插入图片描述
在NR中，RA-RNTI = 1 + s_id + 14 * t_id + 14 x 80 x f_id + 14 x 80 x 8 x ul_carrier_id。其中，s_id表示第1个OFDM符号（在一个PRACH Occasion中）的索引，取值为0~13；t_id表示PRACH Occasion第1个时隙（在一个系统帧中）的索引，取值为0~79；f_id表示PRACH Occasion在频域上的索引，含义和LTE中相同，取值为0~8；ul_carrier_id表示PRACH使用的上行载波，取值0表示NUL载波，取值1表示SUL载波。

从RA-RNTI的构成方式可见，在相同PRACH Occasion发送MSG1的UE，会使用相同RA-RNTI监听PDCCH。这意味着，如果基站对其中的某一个（或某几个）UE进行响应，其他UE也会成功解扰RAR MAC PDU。反过来，如果UE成功解扰RAR MAC PDU，不代表UE成功接收响应（不要高兴的太早），还要看RAR MAC PDU是否包含MSG1对应的Preamble Index。
UE用于加扰MSG3的TC-RNTI，来自于MSG2，即RAR（Random Preamble Response）。除了TC-RNTI，RAR还包含TA和UL Grant。先看一下RAR MAC PDU的报文结构。在LTE和NR中，一个RAR MAC PDU都可以包含多个响应（MAC RAR），但LTE和NR的RAR MAC PDU构成方式稍有不同（主要是LTE和NR的MAC PDU的差异）。
在LTE中，MAC PDU由MAC header和MAC payload构成。MAC header由subheader构成，放置在MAC PDU前面，各个subheader对应的payload（MAC RAR1、MAC RAR … MAC RARn）依序串接构成MAC payload，放置在MAC PDU后面，最后是填充部分（padding）。注意，只包含BI（Backoff Indicator）的subheader，没有对应的payload（MAC RAR），这里暂时忽略BI subheader。
在这里插入图片描述
在NR中，MAC PDU由MAC sub PDU构成，就是将LTE的MAC header打散，把subheader和对应payload（MAC RAR）放回一起（终于团圆了）。RAR的MAC PDU由三种MAC sub PDU构成：1、仅包含BI subheader（如果存在，必须放置在MAC PDU最前面）；2、仅包含RAPID subheader（用于MSG1 based SI Request）；3、包含RAPID subheader和payload（MAC RAR）。NR通过MAC PDU构成方式的改变，让MAC实体提前处理数据，减少整体时延，但MAC PDU包含的内容和LTE本质没什么不同。
RAPID是Random Access Preamble Identifier的缩写，就是前面提到的Preamble Index。RAPID长度为6位，取值为0~63，由此可以推算，一个小区的Preamble数量应为64。需要强调的是，UE在MSG1发送的是Preamble，而不是将RAPID直接告知基站，基站检测接收的Preamble，对照配置获得对应RAPID。
在这里插入图片描述
在LTE中，包含RAPID的subheader必然有对应的payload（MAC RAR），而在NR中，MAC sub PDU可以仅包含RAPID subheader。这种特殊的MAC sub PDU，用于MSG1 based SI Request —— 如果基站为特定的SI配置Dedicated Preamble，并提前告知UE，UE就可以在MSG1发送 Dedicated Preamble请求特定的SI，如果基站在MSG2返回Dedicated Preamble对应的RAPID（Preamble Index），就表示响应UE的SI Request。显然，MSG1 based SI Request是CFRA方式，相对应的，MSG3 based SI Request是CBRA方式。

如果UE成功解出MSG2，并且（某个MAC sub PDU的）RAPID和MSG1的Preamble对应，就认为成功收到基站的响应，读取RAPID subheader对应的payload（MAC RAR）。示图为LTE和NR的MAC RAR，两者报文结构稍有些不同，主要是TA和UL Grant的长度。在LTE的MAC RAR中，TA长度为11位，UL Grant长度为20位（或12位，示图中未呈现）；在NR的MAC RAR中，TA长度为12位，UL Grant长度为27位。
在这里插入图片描述
UE成功接收RAR后，即可以发送MSG3。如果UE在UL CCCH发送MSG3，会使用来自核心网的UE标识（在LTE中，UE标识是S-TMSI或随机数（40位），在NR中，如果UE处于RRC IDLE状态，UE标识是ng-5G-S-TMSI-part1或随机数（39位），如果UE处于RRC INACTIVE状态，UE标识是resume Identity（24位或40位）），基站在MSG4通过UE Contention Resolution Identity MAC CE（48位）携带UE标识（如果长度超过48位，只取前48位），如果MSG4和MSG3携带的UE标识相同，UE认为竞争解决，随机接入成功。

在LTE中，可以在UL CCCH发送的消息，只有RRC CONNECTION SETUP REQUEST和RRC CONNECTION REESTABLISHMENT REQUEST；在NR中，可以在UL CCCH发送的消息，在LTE基础上增加了两个（同时，LTE的两条消息在NR中名称变更为RRC SETUP REQUEST和RRC REESTABLISHMENT REQUEST）：RRC RESUME REQUEST和RRC SYSTEM INFO REQUEST，对应NR的两个新特性 —— RRC INACTIVE状态和on-demand SI。
在这里插入图片描述
反过来，如果不是上述四种场景（RRC建立、RRC重建、RRC恢复、请求SI），UE不会在UL CCCH发送MSG3。此时，UE应处于RRC CONNECTED状态，并已有C-RNTI。在MSG3中，UE通过C-RNTI MAC CE（16位）携带C-RNTI，然后使用C-RNTI尝试对PDCCH进行解扰，如果解扰成功，UE认为竞争解决，随机接入成功。

只有满足以下条件时，MSG2携带的TC-RNTI才会升级为C-RNTI：1、UE在UL CCCH发送MSG3；2、MSG3不是RRC SYSTEM INFO REQUEST；3、UE随机接入成功。简单的说，只有在RRC建立、RRC重建和RRC恢复场景中，且随机接入成功，TC-RNTI才会升级为C-RNTI，在其他场景中，UE最后都会丢弃TC-RNTI。在RRC消息触发的随机接入场景中（比如HO或SN Addition场景），UE在目标小区的C-RNTI直接从RRC消息（newUE-Identity）获得。