随机接入过程

话不多说，先上图

                                                                             图1 基于竞争的随机接入

                                                                          图2 基于非竞争的随机接入

触发随机接入过程的方式有以下三种：

1. PDCCH order触发：eNodeB通过特殊的DCI format 1A告诉UE需要重新发起随机接入，并告诉UE应该使用的Preamble Index和PRACH Mask Index；
2. MAC子层触发：UE自己选择preamble发起随机接入；
3. 上层触发：如初始接入、RRC连接重建、handover等。

step 1：UE发送preamble

UE首先向eNodeB发送RA preamble，告诉eNodeB有一个随机接入请求，eNodeB以此估计其与UE之间的传输时延并向UE发送上行定时提前校准命令。UE要成功发送preamble，需要：1）选择preamble index；2）选择用于发送preamble的PRACH资源；3）确定对应的RA-RNTI；4）确定目标接收功率PREAMBLE_RECEIVED_TARGET_POWER。

1）选择preamble index

对基于竞争的随机接入，在随机选择preamble index之前，UE首先需要确定是选group A还是group B中的preamble，确定了group之后，UE从这个group中随机选择一个preamble并将PRACH Mask Index设为0；而对于基于非竞争的随机接入，preamble index由eNodeB直接指定（eNodeB通过为小区内的每个UE分配一个专用的preamble index来避免冲突，此外eNodeB还会为UE指定一个特定的PRACH Mask Index，注意与基于竞争的随机接入中PRACH Mask Index直接设为0相区别）。

eNodeB分配preamble index和PRACH Mask Index的方式有两种：1）通过RACH-ConfigDedicated的ra-PreambleIndex和ra-PRACH-MaskIndex字段设置（handover过程）；2）在PDCCH order触发的随机接入中，通过DCI format 1A的Preamble Index和PRACH Mask Index字段设置（下行数据到达或定位）。

2）选择用于发送preamble的PRACH资源

基于prach-ConfigIndex、PRACH Mask Index以及物理层timing限制，UE会先确定下一个包含PRACH资源的可用子帧（prach-ConfigIndex指定了时域上可用的PRACH资源集合）。

PRACH Mask Index定义了某个UE可以在系统帧内的哪些PRACH资源上发送preamble（实际上是由PRACH Resource Index指定系统帧中用于发送preamble的PRACH资源的编号）。PRACH Mask Index可以为0，表示eNodeB只为UE分配了preamble，但PRACH资源还需UE自己选择。在基于非竞争的随机接入中，eNodeB可以通过PRACH Mask Index直接指定UE在某个特定的PRACH上发送preamble，从而保证不会与其他UE发生冲突。

对于物理层timing限制，如果UE在子帧n接收到一个RAR MAC PDU，但对应的TB中没有与其发送的preamble对应的响应，则UE应该准备好在不迟于子帧n+5的时间内重发preamble；如果UE在子帧n没有接收到一个RAR MAC PDU（子帧n为RAR窗口的最后一个子帧），则UE应该准备好在不迟于子帧n+4的时间内重发preamble；如果随机接入过程是由PDCCH order在子帧n触发的，则UE将在从子帧n+k2算起的第一个有可用PRACH资源的子帧中发送preamble，其中k26。

3）确定对应的RA-RNTI

preamble的时频位置决定了RA-RNTI的值，UE在发送preamble后，会在RAR时间窗内根据这个RA-RNTI值监听对应的PDCCH。

4）确定目标接收功率PREAMBLE_RECEIVED_TARGET_POWER

 

步骤二：eNodeB发送Random Access Response

UE发送preamble后，将在RAR时间窗内监听PDCCH，以接收对应RA-RNTI的RAR。如果在此RAR时间窗内没有接收到eNodeB回复的RAR，则认为此次随机接入过程失败。需要注意的是，RAR时间窗起始于发送preamble的子帧（若preamble在时域上跨多个子帧，则以最后一个子帧计算）+ 3个子帧，并持续ra-ResponseWindowSize个子帧，如图所示。

与preamble相关联的RA-RNTI可由 RA-RNTI = 1 + t_id + 10*f_id 计算得到，其中t_id为发送preamble的PRACH所在的第一个子帧号（0t_id10），f_id为在该子帧上发送preamble的PRACH在频域上的索引（0f_id6）。对FDD而言，每个子帧上至多只有一个PRACH资源，因此f_id固定为0。

 

UE发送的preamble的时频位置是确定的，因此eNodeB在解码preamble后，也获得了该preamble的时频位置，进而知道了RAR中所需要使用的RA-RNTI。

下面将从RAR MAC PDU构成的角度介绍RAR所携带的信息，如下图所示。

MAC RAR的结构如下图所示。

由图可知，RAR MAC PDU由1个MAC头、0至多个MAC RAR和可能存在的padding组成。

图中RAPID表示Random Access Preamble Identifier，其值与eNodeB对preamble进行解码时得到的preamble index相同。当UE成功地接收到一个RAR MAC PDU（使用前面介绍的RA-RNTI解码）且发现其中某个MAC subheader的RAPID与自己发送preamble时使用的索引值相同，则认为成功接收到对应的RAR，此时UE就可以停止监听RAR了。

若eNodeB在同一块PRACH资源（时频位置相同，使用同一RA-RNTI）上检测到来自多个UE的随机接入请求，则使用一个RAR MAC PDU就可以对这些接入请求进行响应，每个随机接入请求（对应一个preamble index）对应一个MAC RAR。

RAR MAC PDU在DL-SCH上传输，并使用以RA-RNTI加扰的PDCCH指示。使用相同PRACH资源发送preamble（preamble不一定需要相同）的所有UE都监听相同的RA-RNTI加扰的PDCCH，并接收相同的RAR MAC PDU，但不同的preamble index对应不同的MAC RAR。

需要注意的是，RAR MAC PDU只能使用一个RA-RNTI加扰，因此使用不同PRACH资源发送的preamble对应的MAC RAR不能复用到同一个RAR MAC PDU中。

MAC header由1至多个MAC subheader组成。除了Backoff Indicator subheader外，每个subheader对应一个MAC RAR。需要注意的是，Backoff Indicator subheader至多出现一次，且位于MAC header的第一个subheader处，如果RAR MAC PDU中有Backoff Indicator subheader，则UE会将其值保存为backoff，否则会将backoff值设为0。

BI（Backoff Indicator）指定了UE重发preamble前需要等待的时间范围。如果UE在RAR时间窗内没有接收到RAR，或者接收到的RAR中没有一个preamble与自己相符合，则认为此次RAR接收失败，此时UE需要等待一段时间后（等待时间为在0至BI指定的等待时间区间内选取一个随机值）重新发起接入（即重发preamble）。

需要注意的是，BI指定的UE重发preamble前需要等待的时间可能与前面介绍的物理层timing存在冲突。一种解释是：物理层timing只是准备好发送，实际发送的时间还是由MAC层决定。

BI的取值从侧面反映了小区的负载情况，如果接入的UE多，则该值可以设置得大一些，反之该值可以设置得小一些。

Temporary C-RNTI用于UE和eNodeB的后续传输。冲突解决后，该值可以提升为C-RNTI。

UE随机选择一个preamble用于随机接入可能导致多个UE同时选择同一PRACH资源和同一个preamble，从而导致冲突的出现（使用相同的RA-RNTI和preamble index，因此还不确定RAR是对哪个UE的响应），这时需要一个冲突解决机制来解决这个问题。冲突的存在也是RAR不使用HARQ的原因之一。（基于竞争的随机接入）

如果UE使用专用的preamble（ra-PreambleIndex由eNodeB指定）用于随机接入则不会有冲突，也就不需要后续的冲突解决处理，随机接入过程也就到此结束了。（基于非竞争的随机接入）

如果接入过程失败，则UE将在上次发射功率的基础上，提升功率powerRampingStep来重发preamble，以提高发射成功的概率。

 

步骤三：UE发送Msg3

基于非竞争的随机接入中，preamble是某个UE专用的，不存在冲突；此外，该UE已经拥有接入小区内的唯一标识C-RNTI，而无需eNodeB再给它分配C-RNTI。因此，只有基于竞争的随机接入才需要步骤三和步骤四。

注意：1）使用基于非竞争的随机接入的UE必定原本就处于RRC_CONNECTED态；2）handover时，UE在目标小区使用的C-RNTI是通过RRCConnectionReconfiguration中的MobilityControlInfo的newUE-Identity配置的。

之所以将第三条消息称为Msg3而不是某一条具体消息的原因在于，根据UE状态和应用场景的不同，这条消息也可能不同，因此将其统称为Msg3。

Msg3需要携带一个重要信息：每个UE唯一的标识，该标识将用于步骤四中的冲突解决。对处于RRC_CONNECTED态的UE，其唯一标识为C-RNTI，而非RRC_CONNECTED态的UE将使用一个来自核心网的唯一的UE标志（S-TMSI或一个随机数）作为其标识，此时eNodeB需要先与核心网通信，才能响应Msg3。

当UE处于RRC_CONNECTED态但上行不同步时，UE有自己的C-RNTI，在随机接入过程的Msg3中，UE会通过C-RNTI MAC Control Element将自己的C-RNTI告诉eNodeB，eNodeB将在步骤四中使用这个C-RNTI来解决冲突。

当UE在随机接入过程中使用上行CCCH发送Msg3时，UE还没有C-RNTI，此时UE会使用来自核心网的UE标志（S-TMSI或一个随机数）。步骤四中，eNodeB会通过发送UE Contention Resolution Identity MAC Control Element（携带S-TMSI或一个随机数）来解决冲突。

注意：1）UE Contention Resolution Identity MAC Control Element是在步骤四中使用的；2）当前只有RRC连接请求和RRC连接重建请求使用CCCH传输Msg3。

之所以将第三条消息称为Msg3而不是某一条具体消息的原因在于，根据UE的状态和应用场景的不同，这条消息也会有所不同，因此统称为Msg3。

对应于随机接入的触发事件，Msg3携带的信息如下：

1. 如果是初次接入，Msg3为在CCCH上传输的RRC Connection Request，且至少需要携带NAS UE标志信息；
2. 如果是RRC连接重建，Msg3为在CCCH上传输的RRC Connection Re-establishment Request，且不携带任何NAS消息；
3. 如果是切换，Msg3为在DCCH上传输的经过加密和完整性保护的RRC Handover Confirm，必须包含UE的C-RNTI，且如果可能的话需要携带BSR；
4. 对于其它触发事件，Msg3至少需要携带C-RNTI。

上行传输经常使用UE特定的信息（如C-RNTI）对UL-SCH的数据进行加扰。但此时冲突还未解决，加扰不能基于C-RNTI，而只能使用Temporary C-RNTI。也就是说，Msg3使用Temporary C-RNTI对UL-SCH的数据进行加扰。

 

步骤四：eNodeB发送contention resolution

步骤三中，UE会在Msg3中携带自己唯一的标识：C-RNTI或来自核心网的UE标识（S-TMSI或一个随机数）。eNodeB在冲突解决机制中，会在Msg4中携带该唯一标识用于指定胜出的UE，其它没有在冲突解决中胜出的UE将重新发起随机接入。

eNodeB会通过在PCell上使用C-RNTI加扰的PDCCH，或DL-SCH上传输的UE Contention Resolution Identity MAC Control Element指明哪个UE在冲突解决中胜出。

UE在发送完Msg3后会启动一个mac-ContentionResolutionTimer，并在Msg3进行HARQ重传时重启该timer。在该timer超时或停止之前，UE会一直监听PDCCH。如果UE监听到PDCCH，且UE在发送Msg3时携带了C-RNTI MAC Control Element，则在以下两种情况下UE认为冲突解决成功（即该UE成功接入，此时UE会停止mac-ContentionResolutionTimer并丢弃Temporary C-RNTI，需要注意的是，这两种情况下Temporary C-RNTI不会提升为C-RNTI）：

1. 随机接入过程由MAC子层触发，且UE在Msg4中接收到的PDCCH由Msg3携带的C-RNTI加扰，且给新传的数据分配了上行资源；
2. 随机接入过程由PDCCH order触发，且UE在Msg4中接收到的PDCCH由Msg3携带的C-RNTI加扰。

如果Msg3在CCCH上发送，且在Msg4中接收到的PDCCH由RAR中指定的Temporary C-RNTI加扰，则当成功解码出的MAC PDU中包含的UE Contention Resolution Identity MAC Control Element与Msg3发送的CCCH SDU匹配时，UE会认为随机接入成功并将自己的C-RNTI设置为Temporary C-RNTI。（只要成功解码RAR MAC PDU，就停止mac-ContentionResolutionTimer，并不需要等待冲突解决成功，注意，这种情况下Temporary C-RNTI会提升为C-RNTI）

如果mac-ContentionResolutionTimer超时，UE会丢弃Temporary C-RNTI并认为冲突解决失败。

如果冲突解决失败，UE需要：

1. 清空Msg3对应的HARQ buffer；
2. 将PREAMBLE_TRANSMISSION_COUNTER加1，若此时PREAMBLE_TRANSMISSION_COUNTER=preambleTransMax+1，则通知上层随机接入发生了问题（Random Access problem indication）；
3. 在0~BI值之间随机选择一个backoff time，UE延迟backoff time后再发起随机接入。

如果UE接入成功，UE会：

1. 如果收到ra-PreambleIndex和ra-PRACH-MaskIndex，则丢弃；
2. 清空Msg3对应的HARQ buffer。

Msg4也是用HARQ，但不需要与Msg3同步。对于初始接入和无线链路失效而言，Msg4使用Temporary C-RNTI加扰，且使用RLC-TM模式，；而对处于RRC_CONNECTED态的UE而言，Msg4使用C-RNTI加扰。

如果UE在之前发送过Msg3且接入失败，则再次尝试接入时使用的preamble应该与第一次发送Msg3使用的preamble属于相同的group。

 

总结：

1. 如果UE原本就处于RRC_CONNECTED态，则该UE在小区内有唯一的标识C-RNTI。步骤三中，Msg3会通过C-RNTI Mac Control Element把这个C-RNTI带给eNodeB；步骤四中，如果此UE在冲突解决中胜出，eNodeB就使用这个C-RNTI对PDCCH进行加扰，UE收到以此C-RNTI加扰的PDCCH就知道自己接入成功了。
2. 如果UE原本不处于RRC_CONNECTED态，则该UE在小区内不存在C-RNTI，其唯一的标识就是来自核心网的S-TMSI或一个随机数。步骤三中，Msg3会将该唯一标识带给eNodeB；步骤四中，如果此UE在冲突解决中胜出，eNodeB会通过UE Contention Resolution Identity MAC Control Element将步骤三的信息发回给UE，UE比较Msg3和Msg4，发现两者匹配，就知道自己接入成功了。