极好的LTE RACH 过程以及随机接入详解Word下载.docx

极好的LTE RACH 过程以及随机接入详解Word下载.docx

《极好的LTE RACH 过程以及随机接入详解Word下载.docx》由会员分享，可在线阅读，更多相关《极好的LTE RACH 过程以及随机接入详解Word下载.docx（26页珍藏版）》请在冰豆网上搜索。

⑵你打开GSMUE，却看不到”ChannelRequest”时怎么办？

⑶你打开LTEUE，却看不到”RACHPreamble”时怎么办？

你需要做的第一件事是，理解这个过程的所有细节，理解高层信令和物理层的处理方式。

你还需要利用合适的，能显示这些过程细节的设备。

如果你的设备无法记录log信息或是只能记录高层信令log，那么故障排解依然会非常困难。

若你已有了合适的设备，接下来要做的就是理解这些过程的细节知识。

没有知识，再好的设备也毫无用处。

所以呢，马上进入的是LTE的第一个信令过程：

随机接入。

（可能有人会说其实RACH之前还有其它步骤，如频率同步，时间同步，MIB/SIB解码等，不过这些过程更多的是基带处理，所以我跳过了。

）

RACH过程是什么时候发生？

在协议中（36.30010.1.5），RACH过程在这些时候发生：

⑴以RRC_IDLE状态作为起始的初始接入；

⑵RRC连接重建立过程；

⑶切换；

⑷RRC_CONNECTED状态下，下行数据到达，需要启动随机接入的；

如当上行同步状态为“失步”时；

⑸RRC_CONNECTED状态下，上行数据到达，需要启动随机接入的；

如当上行同步状态为“失步”时，或没有可承载SR消息的PUCCH资源时；

⑹RRC_CONNECTED状态下，进行定位，需要启动随机接入的；

如为UE定位需要获取当前时间提前（TA）时；

Scell上进行的随机接入过程，还可用来为相应的TA组进行时间对齐。

两类RACH过程：

竞争与非竞争

当UE发送PRACHpreamble时，它用特定的标识来发。

每个LTE小区中都有64个不同的标识，UE每次接入时随机地从中选择一个。

这是否意味着可能同时有多个UE发送相同的标识？

是的。

这种可能性完全存在。

其含义是不同UE所发的相同的PRACHpreamble同时到达网络侧。

这种PRACH冲突的情形称作“竞争”，允许这种竞争存在的RACH过程称作“基于竞争的”RACH过程。

在基于竞争的PACH过程中，网络通过后续的附加过程来解决冲突问题，这个附加过程叫做“竞争解决”步骤。

而在某些情况下，出于某种原因（如时延限制）这种竞争是不能被容忍，必须避免的。

通常在这种情况下，网络提前告诉每个UE何时，用哪个preamble来发起随机接入。

当然，这种情况下，网络所分配的preamble是不会产生冲突的。

这种RACH过程叫作“无竞争的”RACH过程。

进行无竞争RACH的UE，在RACH前应已处于连接态，如切换场景。

典型的基于竞争的RACH流程如下：

i）UE-->

NW:

RACHPreamble（RA-RNTI,indicationforL2/L3messagesize）

ii）UE<

--NW:

RandomAccessResponse（TimingAdvance,T_C-RNTI,ULgrantforL2/L3message）

iii）UE-->

L2/L3message

iv）Messageforearlycontentionresolution

当第一步发生了竞争冲突时，如两个UE同时发PRACH时，它们会在第二步收到相同的T_C-RNTI及分配的资源。

然后，在第三步中两个UE在同一个分配的资源内（时/频位置）发L2/L3消息。

两个UE在同样的时频资源处发相同信息会导致什么后果？

一种可能是这两个信号彼此干扰，网络都无法解出。

这种情况下，所有UE都不会收到网络下发的回复（HARQACK），它们会认为本次RACH失败，回到第一步重新发起RACH过程。

另一种可能是网络成功地解出了一个UE的消息，而没能解出另一个的。

这时，网络成功解出L2/L3消息的那个UE就可收到回复的ACK。

这个对Msg3的ACK消息发送称为竞争解决过程。

典型的非基于竞争RACH流程为：

i）UE<

--NW:

RACHPreambleAssignment

ii）UE-->

iii）UE<

RandomAccessResponse（TimingAdvance,C-RNTI,ULgrantforL2/L3message）

UE到底什么时候发preamble？

在36.211的表5.7.1-2中有

打开协议了吗？

这里明确地指示了UE会如何根据“PRACHpreambleindex”参数发送RACH。

举例来说，若UE采用的“PRACHpreambleindex”参数值为0，则它应仅在偶数SFN中发送。

但这个答案够吗？

这是说UE可以在这个帧里的任意时刻发送吗？

这个问题的答案在上表中的“SubFrameNumber”一栏。

这里“PRACHConfigurationIndex0”对应值为“1”。

这表示UE仅可在偶数SFN的子帧1中发RACH。

为验证你对上表的理解，问个问题。

采用哪个PRACHConfigurationIndex，会让UE发的RACH最容易让网络检测到？

为什么？

答案应该是14，因为这时UE能在帧内任意的SFN及任意的时隙发送RACH。

在下面这张图里，你将看到发送RACH时所有维度的情况（红色方块处就是发的PRACH信号）。

其中R_Slot由PRACHConfigurationIndex决定；

R_Length由PreambleFormat决定；

F_offset在preambleformat是0~3时由下面的公式决定；

公式中出现的n_RA_PRBoffset由网络通过SIB2中的prach-FreqOffset参数告知UE。

PreambleFormat是什么？

上面的表里有一栏是”PreambleFormat”，这是什么？

它的定义如下表所示。

你会看到PRACHpreamble的长度随preamble格式的变化而不同。

举例来说，当preamble格式为0时，PRACH长度为（3168+24576）个采样点。

（一个采样点Ts长为1/30.72us）。

看了这些，你可能会问“为什么我们需要像这样有多种preamble格式？

”尤其是“为什么我们需要时域长度不同的多种PRACH格式？

”

一个主要原因是因为小区半径的不同。

当然，这个解释太简单了。

现推荐《LTE:

TheUMTSFromTheorytoPractice》，其中第19.4.2节”ThePRACHStructure”中，有我至今见过的最详细的关于PRACH的说明。

网络如何得知UE具体在什么时刻发送RACH？

这很简单。

网络在UE发RACH前肯定已经知道它可能发送的位置，因为是它告诉UE应该什么时候发送的。

（若UE没能正确解出RACH相关的网络信息，则在UE发RACH时网络可能检测不到。

下面是RACH相关的网络信息。

哪条RRC消息里包含RACH配置？

SIB2。

在36.331中有细节。

numberOfRA-Preambles：

每个UE理论上可从64个随机接入preamble中随机选择一个。

但通常每个小区都会预留一部分preamble用作非竞争随机接入，而作普通（竞争）随机接入的UE就要从剩下的preamble中选择。

这个参数的含义就是可用做竞争随机接入的RApreamble数。

PRACH信号结构

下图展示了PRACHpreamble信号结构与普通上行子帧信号的不同。

值得指出的是：

Preamble的频域长度为上行子帧的6个RB带宽，即1.08MHz。

PRACHpreamble中每个子载波宽度为1.25kHz，而普通上行子帧中每个子载波宽为15kHz。

这意味着preamble的12个子载波相当于上行子帧的1个子载波。

怎样生成RACH信号？

如果你不是专门做LTE物理层的DSP或FPGA工程师，你其实无需了解细节。

从LTE系统的一般视角看来，我们只需知道PRACH是由ZaddOffChu序列，根据下式生成的。

其中u=物理根序列索引（physicalrootsequenceindex）

每个小区可为UE提供最多64个preamble，因此驻留在小区内的UE需要能够等概率地生成这64个preamble。

你可以用将序列作循环移位的方式生成64个preamble，但仅做到这一点还不够。

所有的preamble都必须彼此正交，否则同一小区内多个UE同时发送的不同preamble就会发生干扰。

因此我们必须用一个特别设计的值来生成序列，这个值称为CV（CyclicShiftValue,循环移位值），其定义如下。

（个人觉得CV的确定是PRACHpreamble生成过程里最复杂的一步，它牵涉到大量参数。

首先，你应注意到针对“非受限集合”与“受限集合”，其CV的计算过程是不同的。

而这个区分是由SIB2中的’Highspeedflag’IE来指示的。

若Highspeedflag置为TRUE，则用受限集合的计算式，若Highspeedflag置为FALSE，则用非受限集合的计算式。

N_{cs}则由SIB2中的zeroCorrelationZoneConfigIE来决定，如下图所示，很明显，N_{cs}对于受限集合和非受限集合取值也是不同的。

接下来是N_{zc}的获取，这个实际上很简单，由下表可得。

如果preamble要采用非受限集合得出，问题就很简单，只要知道了N_{zc}和N_{cs}就能算出CV。

而采用受限集合时preamble的计算就比较麻烦。

从上面的公式中可得出，在受限集合中计算CV需要获取以下四个值。

问题是它们的运算非常复杂，如下式所示：

看来还要有一个值用来确定要用上面三个式子里的哪一个，即d_u。

于是我们还得先算d_u。

上面这一系列麻烦的运算，都是为了得到CV。

当有了CV，我们就可以利用下式来生成多个preamble。

于是我们得到了PRACHpreamble，但这还不算完。

为了将这串数据发送出去，我们需要将数据转成时域序列，这个转换是由如下过程完成的。

PRACH生成的完整过程，请参见TS36.211的5.7.2/5.7.3节。

网络究竟何时何处发送RACH响应

我们都知道网络在收到UE发上来的RACHpreamble后应返回RACH响应，但具体在哪个子帧里返回这个响应？

这个问题在TS36.3215.1.4节里能够找到答案。

不考虑测量间隔（measurementg