LTE随机接入过程的总结完美.docx

1、LTE随机接入过程的总结完美随机接入过程一. PRACH1. PRACH的类型表1：PRACH类型Preamble format01234*从表1可以看出，Preamble的类型一共有4种，而对于FDD系统之支持0、1、2、3这4类Preamble。对于Preamble format 0，在时间上占用一个完整的子帧；对于Preamble format 1和2，在时间上占用两个完整的子帧；对于Preamble format 3，在时间上占用三个完整的子帧。在频域上，Preamble format 03均占用一个PRB，即180KHZ的频带，区别是Preamble format 03的子载波间隔是

2、1.25KHZ，并占用864个子载波，由于ZC序列的长度是839，因此Preamble format 03真正占用中间的839个子载波传输Preamble，而剩余的25个子载波作为两边的保护带宽。不同类型的Preamble有长度不一样的CP和保护间隔，小区的覆盖范围和保护间隔GT有关，具体可参考如下公式：R = GT * C / 2其中，R为小区半径、GT为保护间隔、C表示光速。至于不同类型的Preamble对应的小区半径可参考如下：Preamble格式0：持续时间1ms，可支持半径约14km；Preamble格式1：持续时间2ms，可支持半径约77km；Preamble格式2：持续时间2ms

3、，可支持半径约29km；Preamble格式3：持续时间3ms，可支持半径约107km；2. PRACH的时频位置首先给出PRACH的时域位置，协议中由参数prach-ConfigIndex给出，每个prach-ConfigIndex给出了Preamble的类型、System frame number(Even/Any)、Subframe number。具体如表2所示：而对于PRACH的频域位置，协议中由参数确定，它的取值范围是。表2：random access configuration for preamble formats 03PRACH ConfigurationIndexPream

4、bleFormatSystem frame numberSubframe numberPRACH ConfigurationIndexPreambleFormatSystem frame numberSubframe number00Even1322Even110Even4332Even420Even7342Even730Any1352Any140Any4362Any450Any7372Any760Any1, 6382Any1, 670Any2 ,7392Any2 ,780Any3, 8402Any3, 890Any1, 4, 7412Any1, 4, 7100Any2, 5, 8422Any

5、2, 5, 8110Any3, 6, 9432Any3, 6, 9120Any0, 2, 4, 6, 8442Any0, 2, 4, 6, 8130Any1, 3, 5, 7, 9452Any1, 3, 5, 7, 9140Any0, 1, 2, 3, 4, 5, 6, 7, 8, 946N/AN/AN/A150Even9472Even9161Even1483Even1171Even4493Even4181Even7503Even7191Any1513Any1201Any4523Any4211Any7533Any7221Any1, 6543Any1, 6231Any2 ,7553Any2 ,7

6、241Any3, 8563Any3, 8251Any1, 4, 7573Any1, 4, 7261Any2, 5, 8583Any2, 5, 8271Any3, 6, 9593Any3, 6, 9281Any0, 2, 4, 6, 860N/AN/AN/A291Any1, 3, 5, 7, 961N/AN/AN/A30N/AN/AN/A62N/AN/AN/A311Even9633Even93. Prach在协议中的配置（331协议）4. PRACH baseband signal generation PRACH的时域波形通过下面的公式生成：其中是Preamble序列。而The root Za

7、doff-Chu sequence 被定义为如下式：如上所述，对于Preamble format 03的序列长度为839，而对于u的取值请参看协议36.211的Table 5.7.2-4。实际上是通过做循环移位生成的，如下式：而的计算方式如下式： 从中可以看出，涉及到unrestricted sets和restricted sets，这是由协议中的High-Speed-flag确定的，而参数是由协议参数zeroCorrelationZoneConfig和High-Speed-flag共同确定的，具体可参考协议36.211 Table5.7.2-2。还有一些其它参数，按照下述的一些公式计算：当，

8、则：当，则：5. Preamble resource group每个小区有64个可用的Preamble序列，UE会选择其中一个在PRACH上传输。这些序列可以分成两部分，一部分用于基于竞争的随机接入，另一部分用于基于非竞争的随机接入。用于基于竞争的随机接入的Preamble又分为GroupA和GroupB，这些都是由SIB2中的Rach-ConfigCommon中下发的。具体可参考图1：图1：Preamble分类分组GroupA和GroupB的原因是为了增加一定的先验知识，从而方便ENB在RAR中给MSG3分配适当的上行资源。如果UE认为自己的MSG3 size比较大（bigger than

9、the messageSizeGroupA），并且路损小于一门限，则UE选择GroupB的Preamble，否则选择GroupA的Preamble。 二. 随机接入触发的原因触发随机接入的事件主要有如下6类：1 初始建立无线连接。（即从RRC_IDLE态到RRC_CONNECTED，或进行attach）2 RRC链接重建过程。（RRC CONNECTED Re-establishment procedure）3 切换。（hand over）注意：切换有可能是非竞争或者竞争随机接入，要看RRC_Reconfiguration消息里是否携带了Preamble index和Prach MaskInd

10、ex。4 RRC_CONNECTED态时，上行不同步，此时下行数据到来。5 RRC_CONNECTED态时，上行数据到达，但上行不同步或者在PUCCH上没有可用的SR资源。6 RRC_CONNECTED态时，需要time advance。随机接入又分为基于竞争的和基于非竞争的，基于竞争的应用于上述的前5类事件，而基于非竞争的用于第3、4、6类事件。三. 随机接入过程 首先给出基于竞争的随机接入和非竞争随机接入的基本流程，如下图2图3：图2：基于竞争随机接入图3：基于非竞争的随机接入下面详述随机接入的过程：1 UE发送Preamble，即MSG1UE要发送Preamble，需要：1）选择Prea

11、mble Index；2）选择用于发送Preamble的Prach资源；3）确定RA-RNTI；4）确定目标接收功率。1） 确定Preamble Index UE会根据Msg3 size和路损综合选择用GroupA还是GroupB的Preamble index，如果之前发生过接入失败，则再次接入时应选择和第一次发送的Preamble相同的Group。对于非竞争接入，ENB通过RACH-ConfigDedicated中的ra-PreambleIndex字段或者DCI format 1A的PDCCH的Preamble Index字段来设置UE所使用的Preamble。需要说明的是，在某些基于非竞争

12、的随机接入中，如果ENB将Preamble Index配置为0，则UE按照基于竞争的随机接入，自我选择Preamble Index。2） PRACH资源选择首先，prach-ConfigIndex确定了在一个无线帧内，哪些个子帧可以用于send Prach。而prach Mask Index指定了此UE具体用哪个资源，对于prach Mask Index 可以参考表3：表3：Prach Mask Index对于非竞争的随机接入，ENB会通过RACH-ConfigDedicated中的ra-Prach-MaskIndex字段或者DCI format 1A的PDCCH的Prach Mask Ind

13、ex字段来设置UE的MaskIndex，从而指名了UE使用哪些Prach资源。而对于非竞争随机接入如何选择Prach的资源，协议中没有明确指出。另外，还需要注意，如果非竞争的随机接入配置MaskIndex为0，则UE可以任意选择Prach的时域资源。物理层的Prach timing的机制对于Prach时域资源的选择也会有影响，主要注意如下几类：第一：如果UE在子帧n接收到RAR，但是没有一个响应与其发送的preamble对应，则UE应该在不迟于子帧n+5的时间内重新发送Preamble。第二：如果UE在时间窗内没有检测到属于自己的RAR，则UE应该在不迟于子帧n+4的时间内重新发送Preamb

14、le。第三：如果随机接入是由PDCCH触发的，则UE将在子帧n+k算起的第一个可用的PRACH子帧发送Preamble，其中k=2。而在Mac层协议中，如果UE没有收到RAR，则会选择一定的子帧延迟发送新的Preamble，这个是否和物力层协议中相矛盾呢？此问题和朋朋交流后，认为由高层触发时，采用物理层的机制，而由MAC层触发的时候采用MAC的机制。3） 确定RA-RNTIRA-RNTI的计算方式如下式：RA-RNTI= 1 + t_id+10*f_id其中，t_id表示preamble发送的第一个子帧(0=t_id10)，而f_id表示频域位置(f_id6)。对于FDD，每个子帧只有一个频域

15、资源用来发送Preamble，因此f_id固定为0。4） Prach发射功率的确定上面的公式取定了Prach的发射功率，为UE在子帧i上允许的最大发射功率，而则是UE通过小区参考信号测量出的路损，而PREAMBLE_RECEIVED_TARGET_POWER（具体请参看36.321协议）表示ENB接收Preamble时的期望到达功率。2 UE接收RARUE发送Preamble之后，将在RAR的时间窗内监听携带RA-RNTI的PDCCH，以接收自己的RAR，如果在时间窗内没有检测到属于自己的RAR，则认为此次随机接入失败。RAR的时间窗起始于n+3子帧，并持续ra-ResponseWindowS

16、ize个子帧。具体如图4：图4：RAR接收时间窗那么RAR中会携带什么呢，下面结合RAR的结构详细说明，如图5，为MAC RAR PDU的完整结构：图5：MAC RAR PDU结构从上图可以看出，该MAC PDU由一个MAC 头（MAC header）+ 0个或多个MAC RAR（MAC Random Access Response）+ 可能存在的padding组成。从MAC PDU的结构可以看出，如果eNodeB同一时间内检测到来自多个UE的随机接入请求，则使用一个MAC PDU就可以对这些接入请求进行响应，每个随机接入请求的响应对应一个MAC RAR。如果多个UE在同一PRACH资源（时频

17、位置相同，使用同一RA-RNTI）发送preamble，则对应的RAR复用在同一MAC PDU中。MAC PDU在DL-SCH上传输，并用以RA-RNTI加扰的PDCCH。前面已经介绍过，使用相同时频位置发送preamble的所有UE都监听相同的RA-RNTI指示的PDCCH。MAC header由一个或多个MAC subheader组成。除了Backoff Indicator subheader外，每个subheader对应一个MAC RAR。如果包含Backoff Indicator subheader，则该subheader只出现一次，且位于MAC header的第一个subheader

18、处。Backoff Indicator subheader的结构如图6：图6：Backoff Indicator subheaderBI（Backoff Indicator）指定了UE重发preamble前需要等待的时间范围（取值范围见36.321的7.2节）。如果UE在RAR时间窗内没有接收到RAR，或接收到的RAR中没有一个preamble与自己的相符合，则认为此次RAR接收失败。此时UE需要等待一段时间后，再发起随机接入。等待的时间为在0至BI指定的等待时间区间内选取一个随机值。（注：如果在步骤四中，冲突解决失败，也会有这样的后退机制）RAR subheader结构如图7：图7：RAR

19、subheaderRAPID为Random Access Preamble IDentifier的简称，为eNodeB在检测preamble时得到的preamble index。如果UE发现该值与自己发送preamble时使用的索引相同，则认为成功接收到对应的RAR。RAR的结构如图8：图8：RARTC-RNTI用于UE和eNodeB的后续传输。冲突解决后，该值可能变成C-RNIT。11-bit的Timing advance command用于指定UE上行同步所需要的时间调整量。具体可以参考36.213协议。20bit UL grant指定了分配给msg3的上行资源。当有上行数据传输时，例如需

20、要解决冲突，eNodeB在RAR中分配的grant不能小于56bit。Gant的结构如图9：图9：Grant结构UE随机选择一个preamble用于随机接入，就可能导致多个UE同时选择同一PRACH资源的同一个preamble，从而导致冲突的出现（使用相同的RA-RNTI和preamble，因此还不确定RAR是对哪个UE的响应），这时需要一个冲突解决机制来解决这个问题。冲突的存在也是RAR不使用HARQ的原因之一。 如果UE使用专用的preamble用于随机接入，则不会有冲突，也就不需要后续的冲突解决处理，随机接入过程也就到此结束了。（基于非竞争的随机接入） 如果接入过程失败（即在RAR窗内没

21、有收到RAR，或者有RAR但没有属于自己的RAR PDU），UE需要将PREAMBLE_TRANSMISSION_ COUNTER加1（如果此时PREAMBLE_TRANSMISSION_ COUNTER = preambleTransMax + 1，则通知上层随机接入失败），之后在0BI值之间随机选择一个backoff time，UE延迟backoff time后，再发起随机接入。对于Preamble的发射功率而言，如果没有达到最大的随机接入尝试次数preambleTransMax， 则UE将在上次发射功率的基础上，提升功率powerRampingStep来发送下次preamble，以提高发

22、射成功的概率。3 UE发送MSG3基于非竞争的随机接入，preamble是某个UE专用的，所以不存在冲突，又因为该UE已经拥有在接入小区内的唯一标志C-RNTI，所以也不需要eNodeB给它分配C-RNTI。因此，只有基于竞争的随机接入才需要步骤三和步骤四。之所以称为msg3而不是某一条具体消息的原因在于，根据UE状态的不同和应用场景的不同，这条消息也可能不同，因此统称为msg3，即第3条消息。如果UE在子帧n成功地接收了自己的RAR，则UE应该在n+k的第一个可用的上行子帧发送msg3，而对于FDD系统k为6。需要注意的是，在RAR中UL grant包含1bit的字段UL delay，如果d

23、elay为0，则UE会在n+k发送msg3，如果为1，则UE会在n+k后的下一个子帧发送msg3。 msg3在UL-SCH上传输，使用HARQ，且RAR中带的UL grant指定的用于msg3的TB大小至少为80比特。msg3中需要包含一个重要信息：每个UE唯一的标志。该标志将用于步骤四的冲突解决。对于处于RRC_CONNECTED态的UE来说，其唯一标志是C-RNTI。UE会通过C-RNTI MAC control element将自己的C-RNTI告诉eNodeB，eNodeB在步骤四中使用这个C-RNTI来解决冲突。C-RNTI MAC control element如图10：图10：C

24、-RNTI MAC control element对于非RRC_CONNECTED态的UE来说，将使用一个来自核心网的唯一的UE标志（S-TMSI或一个随机数）作为其标志。此时eNodeB需要先与核心网通信，才能响应msg3。对于msg能携带的消息主要有两类，一类主要是UE要带给ENB或者EPC端的一些信令，如RRC ConnectionRequest、handover相关等；另一类是用于冲突解决的，比如处于连接态时需要携带C-RNTI，而处于非连接态时需要携带S-TMSI或者一个由UE产生的随机数。注意：此时ENB要用TC-RNTI加扰的PDCCH调度UE。最后，需要注意的是，在MSG3阶段

25、，协议设计了一个定时器Mac-ContentionResolutionTimer，当Mac-ContentionResolutionTimer超时并且还没有收到MSG4时，则认为本次随机接入失败，并择机重新发送Preamble，而当MSG3出现HARQ重传时，此定时器需要复位并重启。最后再总结一下MSG3可能会携带的东西，主要包括：C-RNTI MAC Control Element、BSR MAC Control Element、PHR MAC Control Element、还有一些RRC消息等。4 冲突解决（ENB发送MSG4）关于这个问题，我认为只要关注如下：如果在MSG3中携带了UE

26、的C-RNTI，此时UE只要检测到了用C-RNTI加扰的PDCCH，即可以认为冲突解决。而对于MSG3中携带的是UE的一个标识，此时UE需要检测到UEContentionResolutionIdentity MAC Control Element，并且里面携带的信息要和MSG3中的一下才可以认为冲突解决，此时TC-RNTI升级为C-RNTI。UEContentionResolutionIdentity MAC Control Element如图11：图11：UEContentionResolutionIdentity MAC Control Element如果冲突解决失败，UE需要将PREAM

27、BLE_TRANSMISSION_ COUNTER加1（如果此时PREAMBLE_TRANSMISSION_ COUNTER = preambleTransMax + 1，则通知上层随机接入失败），之后在0BI值之间随机选择一个backoff time，UE延迟backoff time后，再发起随机接入。四. 各种可以触发随机接入事件的信令流程 触发随机接入过程的事件有6种，见之前介绍。 触发随机接入过程的方式有3种：1）PDCCH order触发；2）MAC sublayer触发；3）上层触发。 由PDCCH order发起的初始随机接入过程（“initiated by a PDCCH or

28、der”）只有在如下场景才会发生：1）eNodeB要发送下行数据时，发现丢失了UE的上行同步，它会强制UE重新发起随机接入过程以获取正确的时间调整量；2）UE定位。这时eNodeB会通过特殊的DCI format 1A 告诉UE需要重新发起随机接入，并告诉UE应该使用的Preamble Index和PRACH Mask Index。 由PDCCH触发的随机接入的信令流程如下图（两张图，第一张为基于非竞争的，第二张基于竞争的）：图12：基于非竞争图13：基于竞争 由MAC sublayer发起随机接入过程的场景有：UE有上行数据要发送，但在任意TTI内都没有可用于发送SR的有效PUCCH资源。此

29、时上行数据传输的流程变为： 1UE 发送preamble； 2eNodeB回复RAR，RAR携带了UL grant信息； 3UE开始发送上行数据。 什么情况下UE可能没有SR资源呢？场景一：从36.331可以看出，SchedulingRequestConfig是一个UE级的可选的IE（optional），默认为release。如果 eNodeB不给某UE配置SR（这取决于不同厂商的实现），则该UE只能通过随机接入来获取UL grant。因此，是否配置SR主要影响用户面的延迟，并不影响上行传输的功能！场景二：当UE丢失了上行同步，它也会释放SR资源，如果此时有上行数据要发送，也需要触发随机接入过程。具体的信令流程图如图14所示：图14：上行数据要发送时没有SR资源时触发的随机接入流程 上层触发的随机接入过程包括：1）初始接入；2）RRC连接重建； 3）切换。初始接入的随机接入信令流程如图15所示：图15：初始接入的随机接入信令流程RRC连接重建的随机接入信令流程如图16所示：图16：RRC连接重建的随机接入信令流程HandOver时的随机接入流程（包括基于竞争的和基于非竞争的）：图17：HandOver随机接入的信令流程（基于竞争）图18：HandOver随机接入的信令流程（基于非竞争的）