极好的LTE RACH 过程以及随机接入详解Word文档格式.docx

极好的LTE RACH 过程以及随机接入详解Word文档格式.docx

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

⑴以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节里能够找到答案。

不考虑测量间隔（measurementgap），当UE发送了RApreamble后，它须监测PDCCH，以获取随机接入响应（RandomAccessResponse,RAR），这个响应的标识是RA-RNTI。

RA响应窗起始于上行preamble发送终止的那个子帧号加3对应的子帧，其长度为ra-ResponseWindowSize个子帧。

这意味着网络能够发送RAR的最早时刻为接收到相应RACHpreamble后的第4个子帧。

那么它是否也是网络发送RAR的最晚时刻？

这要由ra-ResponseWindowSize来决定。

这个窗口的值为0到10，单位为子帧，其含义为从RACHpreamble的结束到RAR发送间的最大时长间隔为12个子帧（即12ms），是一个很严格的时延要求。

PRACH参数及其物理意义总结

<

prach-ConfigIndex>

zeroCorrelationZoneConfigandHighspeedflag 

>

prach-FreqOffset>

rootSequenceIndex>

初始接入阶段的RACH过程——RACH过程概述

下图是初始接入阶段RACH过程的示例。

若你是一名协议栈研发或测试开发工程师，你应对这个过程非常熟悉。

这里重申，作为研发者，我们必须掌握所有每一步中的所有细节，但显然这不是能够一蹴而就的事。

所以，让我们先从最重要的部分开始吧，我认为这应是RACH响应的部分。

下图显示的是5MHz带宽上发RAR的示例。

我们无需记住参数细节，但需要熟悉数据格式，并理解这个比特串中每一部分的含义。

若你解码了ULgrant部分，你将得到如下结果。

你会注意到这里所携带的信息与携带上行资源分配的DCIformat0是极相似的。

这个信息就是RAR消息中的ULgrant，为msg3（即RRCConnectionRequest）指示所分配的资源。

注意：

这里是系统带宽为5MHz时的示例。

若系统带宽为其它，则在Start_RB和N_RB不变时应有不同的RIV值；

或在RIV值相同时有不同的Start_RB和N_RB。

让我们再用人话来阐述一遍这个流程。

i）UE在随机接入信道（RACH）上发起随机接入过程。

（RACH的时频位置之前已通过广播信道下发至UE。

）随机接入信息包含6bit，其中主要部分为随机生成的5bit标识。

ii）网络在PDSCH上的时频grid上回复随机接入响应（RAR）消息。

（RAR消息在PDSCH中的具体时频位置，由RA消息发送的时频位置决定。

RAR消息中包含UE随机生成的标识，一个用作后续带宽分配用的小区无线网络临时ID，即T_C-RNTI，及初始上行带宽分配。

iii）接下来，UE用所分配的初始上行资源，发送一个简短的（约80bit）RRC连接请求消息，这条消息中包含了对应核心网中存储的永久性用户信息。

其中，仅仅第i）步物理层过程是RA所特有的，后续流程实际上都是一般上下行数据传输过程的重用。

如何获得RA-RNTI?

TS36.321中第5.1.4节“RandomAccessResponsereception”中，对RA-RNTI的计算方式有如下陈述：

RA-RNTI与发送RApreamble所在的PRACH资源间有这样的对应关系：

RA-RNTI=1+t_id+10*f_id

其中t_id是PRACH的首个子帧在帧内的索引（0<

=t_id<

10），而f_id是在PRACH在频域以升序排列时，在所在子帧内的索引（序号）（0<

=f_id<

6）。

对于FDD，f_id固定为0。

（Note:

在由于TDD中上行需和下行分占时隙，因此上行资源少，为了有足够的随机接入机会，在一个FDD子帧内只有一个PRACH，而在一个TDD子帧内可以至多有6个PRACH。

f_id是指这个PRACH是在同一子帧中的第几个PRACH。

因此，RA-RNTI是由UE通过选择发送preamble所用的PRACH所在的资源位置而决定的。

一个完整的RACH过程示例

下面是一个由一部商用LTE终端和LTE网络模拟器组成的示例。

我不再多解释，自己看看能不能独立看懂吧。

如果懂了，那么祝贺你把上面所讲的都理解了。

PRACH重传

上面说的基本都是理想的RACH过程，即UE发送PRACH，网络反馈RAR及后续消息都是一次性成功的。

但如果UE在第一次发送后没有收到RAR呢？

这时UE应如何做？

答案很简单，重发PRACH。

但更多问题会接踵而来。

比如说，如果我是一个UE

i）我在什么时刻重传？

（从上一次发送到重传的时间间隔应有多长？

ii）我重传PRACH时的功率要和前一次相同吗？

还是说应该增加一点？

如果要增加一点功率的话，那应该增加多少？

iii）若我多次收不到RAR，那最多应重传多少次？

直到电池用光吗？

还是有个上限，重传这么多次不成功后就放弃？

如果采用重传多次后放弃，那究竟应试多少次？

上述问题的答案都是由网络侧提供的。

问题i）的答案是，网络会有一个特殊的RARMACPDU，名为”BackoffIndicator”。

（这个IE的细节后面会提到）

ii）和iii）的答案由网络在SIB2里提供。

powerRampingStep对应问题ii），preambleTransMax对应问题iii）。

下例中，powerRampingStep=dB2，其含义是UE每次重试时，PRACH功率增加的步长为2dB。

PreambleTransMax=n6，其含义是UE重试6次PRACH后放弃尝试。

| 

+-radioResourceConfigCommon:

:

=SEQUENCE

|+-rach-Config:

||+-preambleInfo:

=SEQUENCE[0]

|||+-numberOfRA-Preambles:

=ENUMERATED[n52]

|||+-preamblesGroupAConfig:

=SEQUENCEOPTIONAL:

Omit

||+-powerRampingParameters:

||| 

+-powerRampingStep:

=ENUMERATED[dB2]

|||+-preambleInitialReceivedTargetPower:

=ENUMERATED[dBm-104]

||+-ra-SupervisionInfo:

+-preambleTransMax:

=ENUMERATED[n6]

|||+-ra-ResponseWindowSize:

=ENUMERATED[sf10]

|||+-mac-ContentionResolutionTimer:

=ENUMERATED[sf48]

||+-maxHARQ-Msg3Tx:

=INTEGER（1..8）[4]

图表阐述RACH整体流程

之前我已对RACH过程作了相当详尽的描述。

你可能会问：

“什么情形会触发UE发起的RACH过程？

”在TS36.30010.1.5节OveralldescriptionofRACHProcess中，你可以找到各种触发条件，打开UE当然是其中之一。

下面是过程的其它触发条件。

初始注册时的RACH>

这个流程基本上和前文描述的一致，但我对此作了简化，以让大家专注于RACH过程中的信令交互部分。

下图中你可以看到一些更细节的步骤，如HARQACK,DCI0（即ULGrant）。

这与实际网络流程更为类似。

切换时的RACH过程——基于竞争>

切换时的RACH过程——基于非竞争>

失步有下行数据到达时的RACH过程——基于非竞争>

失步有下行数据到达时的RACH过程——基于竞争>

失步有上行数据到达时的RACH过程>

失步进行RRC连接重建时的RACH过程>

PRACH射频波形

3GPP中的RACH过程

3GTS36.300（10.1.5）:

OveralldescriptionofRACHProcess.Readthisfirst.

3GTS36.211（5.7）:

RRCMessagesandIE（InformationElements）whichareinvolvedinRACHprocess.

3GTS36.213（6）:

MACLayerProcedurerelatedtoRACHProcess.