极好的LTE RACH 过程以及随机接入详解.doc

设备故障修复时什么最难？我的经验是“若问题是在进行过程中出现的，那么寻找原因并修复相对来说比较容易(也许比起我这样动嘴皮子还是要难一点)；而如果是在开始时就出的问题，那才让人头疼。”比如说，你在网络模拟器处，为一个UE的接入设好了所有参数，然后你打开了这个UE。几秒钟后，UE开始启动，几秒钟后你看到UE屏幕上方的小天线图标然后再过几秒钟，你看到屏幕上显示”SOS”或“无服务”，而不是本应显示的运营商名及标识信号正常的天线图标。上面说的就是指“在进行过程中出现的问题”。在这种情况下，只要你查查UE和设备的log，你就至少能准备地定位到问题出现的地方，并从那里入手深入分析原因。但是，如若你遭遇了这样的事情呢？你设好网络模拟器的所有参数然后打开UE，UE启动，显示“搜索网络”，然后就挂在这了。没有信号格图标，甚至也没有”SOS”，只是显示“无服务”。查看UE和网络模拟器的log，发现没有信令消息。这种情况才让人头疼。举例来说， 你打开WCDMA UE，却看不到”RRC Connection Request”时怎么办？ 你打开GSM UE，却看不到”Channel Request”时怎么办？ 你打开LTE UE，却看不到”RACH Preamble”时怎么办？你需要做的第一件事是，理解这个过程的所有细节，理解高层信令和物理层的处理方式。你还需要利用合适的，能显示这些过程细节的设备。如果你的设备无法记录log信息或是只能记录高层信令log，那么故障排解依然会非常困难。若你已有了合适的设备，接下来要做的就是理解这些过程的细节知识。没有知识，再好的设备也毫无用处。所以呢，马上进入的是LTE的第一个信令过程：随机接入。(可能有人会说其实RACH之前还有其它步骤，如频率同步，时间同步，MIB/SIB解码等，不过这些过程更多的是基带处理，所以我跳过了。)RACH过程是什么时候发生？在协议中(36.300 10.1.5)，RACH过程在这些时候发生： 以RRC_IDLE状态作为起始的初始接入； RRC连接重建立过程； 切换； RRC_CONNECTED状态下，下行数据到达，需要启动随机接入的；如 当上行同步状态为“失步”时； RRC_CONNECTED状态下，上行数据到达，需要启动随机接入的；如 当上行同步状态为“失步”时，或没有可承载SR消息的PUCCH资源时； RRC_CONNECTED状态下，进行定位，需要启动随机接入的；如 为UE定位需要获取当前时间提前(TA)时；Scell上进行的随机接入过程，还可用来为相应的TA组进行时间对齐。两类RACH过程：竞争与非竞争当UE发送PRACH preamble时，它用特定的标识来发。每个LTE小区中都有64个不同的标识，UE每次接入时随机地从中选择一个。这是否意味着可能同时有多个UE发送相同的标识？是的。这种可能性完全存在。其含义是不同UE所发的相同的PRACH preamble同时到达网络侧。这种PRACH冲突的情形称作“竞争”，允许这种竞争存在的RACH过程称作“基于竞争的”RACH过程。在基于竞争的PACH过程中，网络通过后续的附加过程来解决冲突问题，这个附加过程叫做“竞争解决”步骤。而在某些情况下，出于某种原因(如时延限制)这种竞争是不能被容忍，必须避免的。通常在这种情况下，网络提前告诉每个UE何时，用哪个preamble来发起随机接入。当然，这种情况下，网络所分配的preamble是不会产生冲突的。这种RACH过程叫作“无竞争的”RACH过程。进行无竞争RACH的UE，在RACH前应已处于连接态，如切换场景。典型的基于竞争的RACH流程如下：i) UE - NW : RACH Preamble (RA-RNTI, indication for L2/L3 message size)ii) UE NW : L2/L3 message iv) Message for early contention resolution当第一步发生了竞争冲突时，如两个UE同时发PRACH时，它们会在第二步收到相同的T_C-RNTI及分配的资源。然后，在第三步中两个UE在同一个分配的资源内(时/频位置)发L2/L3消息。两个UE在同样的时频资源处发相同信息会导致什么后果？一种可能是这两个信号彼此干扰，网络都无法解出。这种情况下，所有UE都不会收到网络下发的回复(HARQ ACK)，它们会认为本次RACH失败，回到第一步重新发起RACH过程。另一种可能是网络成功地解出了一个UE的消息，而没能解出另一个的。这时，网络成功解出L2/L3消息的那个UE就可收到回复的ACK。这个对Msg 3的ACK消息发送称为竞争解决过程。典型的非基于竞争RACH流程为：i) UE NW : RACH Preamble (RA-RNTI, indication for L2/L3 message size)iii) UE -NW : Random Access Response (Timing Advance, C-RNTI, UL grant for L2/L3 message)UE到底什么时候发preamble？在36.211的表5.7.1-2中有打开协议了吗？这里明确地指示了UE会如何根据“PRACH preamble index”参数发送RACH。举例来说，若UE采用的“PRACH preamble index”参数值为0，则它应仅在偶数SFN中发送。但这个答案够吗？这是说UE可以在这个帧里的任意时刻发送吗？这个问题的答案在上表中的“Sub Frame Number”一栏。这里“PRACH Configuration Index 0”对应值为“1”。这表示UE仅可在偶数SFN的子帧1中发RACH。为验证你对上表的理解，问个问题。采用哪个PRACH Configuration Index，会让UE发的RACH最容易让网络检测到？为什么？答案应该是14，因为这时UE能在帧内任意的SFN及任意的时隙发送RACH。在下面这张图里，你将看到发送RACH时所有维度的情况(红色方块处就是发的PRACH信号)。其中R_Slot由PRACH Configuration Index决定；R_Length由Preamble Format决定；F_offset在preamble format是03时由下面的公式决定；公式中出现的n_RA_PRBoffset由网络通过SIB2中的prach-FreqOffset参数告知UE。Preamble Format是什么？上面的表里有一栏是”Preamble Format”，这是什么？它的定义如下表所示。你会看到PRACH preamble的长度随preamble格式的变化而不同。举例来说，当preamble格式为0时，PRACH长度为(3168+24576)个采样点。(一个采样点Ts长为 1/30.72us)。看了这些，你可能会问“为什么我们需要像这样有多种preamble格式？”尤其是“为什么我们需要时域长度不同的多种PRACH格式？”一个主要原因是因为小区半径的不同。当然，这个解释太简单了。现推荐LTE: The UMTS From Theory to Practice，其中第19.4.2节”The PRACH Structure”中，有我至今见过的最详细的关于PRACH的说明。网络如何得知UE具体在什么时刻发送RACH？这很简单。网络在UE发RACH前肯定已经知道它可能发送的位置，因为是它告诉UE应该什么时候发送的。(若UE没能正确解出RACH相关的网络信息，则在UE发RACH时网络可能检测不到。)下面是RACH相关的网络信息。哪条RRC消息里包含RACH配置？SIB2。在36.331中有细节。numberOfRA-Preambles：每个UE理论上可从64个随机接入preamble中随机选择一个。但通常每个小区都会预留一部分preamble用作非竞争随机接入，而作普通(竞争)随机接入的UE就要从剩下的preamble中选择。这个参数的含义就是可用做竞争随机接入的RA preamble数。PRACH信号结构下图展示了PRACH preamble信号结构与普通上行子帧信号的不同。值得指出的是：Preamble的频域长度为上行子帧的6个RB带宽，即1.08MHz。PRACH preamble中每个子载波宽度为1.25kHz，而普通上行子帧中每个子载波宽为15kHz。这意味着preamble的12个子载波相当于上行子帧的1个子载波。怎样生成RACH信号？如果你不是专门做LTE物理层的DSP或FPGA工程师，你其实无需了解细节。从LTE系统的一般视角看来，我们只需知道PRACH是由ZaddOff Chu序列，根据下式生成的。其中u = 物理根序列索引(physical root sequence index)每个小区可为UE提供最多64个preamble，因此驻留在小区内的UE需要能够等概率地生成这64个preamble。你可以用将序列作循环移位的方式生成64个preamble，但仅做到这一点还不够。所有的preamble都必须彼此正交，否则同一小区内多个UE同时发送的不同preamble就会发生干扰。因此我们必须用一个特别设计的值来生成序列，这个值称为CV(Cyclic Shift Value, 循环移位值)，其定义如下。(个人觉得CV的确定是PRACH preamble生成过程里最复杂的一步，它牵涉到大量参数。)首先，你应注意到针对“非受限集合”与“受限集合”，其CV的计算过程是不同的。而这个区分是由SIB2中的Highspeedflag IE来指示的。若Highspeedflag置为TRUE，则用受限集合的计算式，若Highspeedflag置为FALSE，则用非受限集合的计算式。N_cs则由SIB2中的zeroCorrelationZoneConfig IE来决定，如下图所示，很明显，N_cs对于受限集合和非受限集合取值也是不同的。接下来是N_zc的获取，这个实际上很简单，由下表可得。如果preamble要采用非受限集合得出，问题就很简单，只要知道了N_zc和N_cs就能算出CV。而采用受限集合时preamble的计算就比较麻烦。从上面的公式中可得出，在受限集合中计算CV需要获取以下四个值。问题是它们的运算非常复杂，如下式所示：看来还要有一个值用来确定要用上面三个式子里的哪一个，即d_u。于是我们还得先算d_u。上面这一系列麻烦的运算，都是为了得到CV。当有了CV，我们就可以利用下式来生成多个preamble。于是我们得到了PRACH preamble，但这还不算完。为了将这串数据发送出去，我们需要将数据转成时域序列，这个转换是由如下过程完成的。PRACH生成的完整过程，请参见TS36.211的5.7.2/5.7.3节。网络究竟何时何处发送RACH响应我们都知道网络在收到UE发上来的RACH preamble后应返回RACH响应，但具体在哪个子帧里返回这个响应？这个问题在TS 36.321 5.1.4节里能够找到答案。不考虑测量间隔(measurement gap)，当UE发送了RA preamble后，它须监测PDCCH，以获取随机接入响应(Random Access Response, RAR)，这个响应的标识是RA-RNTI。RA响应窗起始于上行preamble发送终止的那个子帧号加3对应的子帧，其长度为ra-ResponseWindowSize个子帧。这意味着网络能够发送RAR的最早时刻为接收到相应RACH preamble后的第4个子帧。那么它是否也是网络发送RAR的最晚时刻？这要由ra-ResponseWindowSize来决定。这个窗口的值为0到10，单位为子帧，其含义为从RACH preamble的结束到RAR发送间的最大时长间隔为12个子帧(即12ms)，是一个很严格的时延要求。PRACH参数及其物理意义总结初始接入阶段的RACH过程RACH过程概述下图是初始接入阶段RACH过程的示例。若你是一名协议栈研发或测试开发工程师，你应对这个过程非常熟悉。这里重申，作为研发者，我们必须掌握所有每一步中的所有细节，但显然这不是能够一蹴而就的事。所以，让我们先从最重要的部分开始吧，我认为这应是RACH响应的部分。下图显示的是5MHz带宽上发RAR的示例。我们无需记住参数细节，但需要熟悉数据格式，并理解这个比特串中每一部分的含义。若你解码了UL grant部分，你将得到如下结果。你会注意到这里所携带的信息与携带上行资源分配的DCI format 0是极相似的。这个信息就是RAR消息中的UL grant，为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?TS 36.321中第5.1.4节 “Random Access Response reception”中，对RA-RNTI的计算方式有如下陈述：RA-RNTI与发送RA preamble所在的PRACH资源间有这样的对应关系：RA-RNTI = 1 + t_id + 10 * f_id其中t_id是PRACH的首个子帧在帧内的索引(0=t_id10)，而f_id是在PRACH在频域以升序排列时，在所在子帧内的索引(序号)(0=f_id6)。对于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。但更多问题会接踵而来。比如说，如果我是一个UEi) 我在什么时刻重传？(从上一次发送到重传的时间间隔应有多长？)ii) 我重传PRACH时的功率要和前一次相同吗？还是说应该增加一点？如果要增加一点功率的话，那应该增加多少？iii) 若我多次收不到RAR，那最多应重传多少次？直到电池用光吗？还是有个上限，重传这么多次不成功后就放弃？如果采用重传多次后放弃，那究竟应试多少次？上述问题的答案都是由网络侧提供的。问题i)的答案是，网络会有一个特殊的RAR MAC PDU，名为”Backoff Indicator”。(这个IE的细节后面会提到)ii)和iii)的答案由网络在SIB2里提供。powerRampingStep对应问题ii)，preambleTransMax对应问题iii)。下例中，powerRampingStep = dB2，其含义是UE每次重试时，PRACH功率增加的步长为2dB。PreambleTransMax = n6，其含义是UE重试6次PRACH后放弃尝试。| +-radioResourceConfigCommon := SEQUENCE| | +-rach-Config := SEQUENCE| | | +-preambleInfo := SEQUENCE 0| | | | +-numberOfRA-Preambles := ENUMERATED n52| | | | +-preamblesGroupAConfig := SEQUENCE OPTIONAL:Omit| | | +-powerRampingParameters := SEQUENCE| | | |+-powerRampingStep := ENUMERATED dB2| | | | +-preambleIni