LTE随机接入过程Word格式.docx

1、此时通过RRC timer T301和T311来控制，当该timer超时即RRC连接重建失败时，UE的RRC层会停止MAC层的随机接入过程，并进入RRC_IDLE态。从36.331的5.3.12节可以看出，UE进入RRC_IDLE态之前会重置MAC。见36.331的5.3.7.6节和5.3.7.7节场景三：Handover。此时通过RRC timer T304来控制，当该timer超时即handover失败时，UE的RRC层会停止之前的随机接入过程如果之前分配了专用的用于非竞争随机接入的preamble，如此此时认为该preamble不再有效，然后触发RRC连接重建过程。见36.331的5.3

2、.5.6节场景四： RRC_CONNECTED态下，下行数据到达时，上行处于“不同步状态包括“定位UE的场景；或上行数据到达时，上行处于“不同步状态或没有可用的PUCCH资源用于SR传输。由于这种场景下只有MAC层能感知到发生了随机接入过程，而RRC层是不知道的，所以当RRC层收到random access problem indication时，会认为无线链路失效Radio Link Failure了，此时如果AS安全还没被激活，UE会进入RRC_IDLE态；否如此的话，UE会发起RRC连接重建流程见36.331的5.3.11.3节从上面的介绍可以看出，在场景一、场景二、场景三中，RRC层会

3、忽略MAC层送上来的random access problem indication，而是根据对应的timer来决定是否停止之前的随机接入过程。只有场景四下，RRC层会对random access problem indication进展处理。【参考资料】14G LTE/LTE-Advanced for Mobile Broadband的14.3节2LTE The UMTS Long Term Evolution, 2nd Edition的17章3 Random Access Supervision Part 1和Random Access Supervision Part 2by John

4、M.423GPP协议 v10TS 36.211 5.7 Physical random access channelTS 36.213 6 MAC Layer Procedure related to RACH Process.TS 36.300 10.1.5 Overall description of RACH Process.先阅读这个.TS 36.321 5.1 MAC Layer process of random access procedure.TS 36.331 6.3.1 System information blocks 17 SystemInformationBlockT

5、ype2TS 36.331 6.3.2 Radio resource control information elements PRACH-ConfigTS 36.331 6.3.2 Radio resource control information elements RACH-ConfigmonTS 36.331 6.3.2 Radio resource control information elements RACH-ConfigDedicated本条目发布于2014/04/19。属于LTE分类，被贴了 LTE、preamble、random access、随机接入过程 标签。作者是w

6、jhgh04gmail 。各类触发事件下的随机接入过程本节将介绍各种触发事件是如何触发随机接入过程的，主要以信令流程图的方式予以说明。将本节内容与之前介绍的内容结合起来，有助于更深刻地理解随机接入过程。触发随机接入过程的事件有6种，见之前介绍。触发随机接入过程的方式有3种：1PDCCH order触发；2MAC sublayer触发；3上层触发。由PDCCH order发起的随机接入过程“initiated by a PDCCH order只有在如下场景才会发生：1eNodeB要发送下行数据时，发现丢失了UE的上行同步，它会强制UE重新发起随机接入过程以获取正确的时间调整量；2UE定位。这时e

7、NodeB会通过特殊的DCI format 1A 告诉UE需要重新发起随机接入，并告诉UE应该使用的Preamble Index和PRACH Mask Index。见36.212的5.3.3.1.3节、36.213的Table 8-402图12：DCI format 1A用于PDCCH order时的格式对应的信令流程如下注：UE定位的处理流程与基于非竞争的下行数据到达场景类似：图13：下行数据到达基于竞争图14：下行数据到达基于非竞争由MAC sublayer发起随机接入过程的场景有：UE有上行数据要发送，但在任意TTI内都没有可用于发送SR的有效PUCCH资源。此时上行数据传输的流程变为：

8、1UE 发送preamble；2eNodeB回复RAR，RAR携带了UL grant信息；3UE开始发送上行数据。什么情况下UE可能没有SR资源呢？从36.331可以看出，SchedulingRequestConfig是一个UE级的可选的IEoptional，默认为release。如果 eNodeB不给某UE配置SR这取决于不同厂商的实现，如此该UE只能通过随机接入来获取UL grant。因此，是否配置SR主要影响用户面的延迟，并不影响上行传输的功能！当UE丢失了上行同步，它也会释放SR资源，如果此时有上行数据要发送，也需要触发随机接入过程。从上面的描述可以看出，当UE没有被分配SR资源时，基

9、于竞争的random access可以替代SR的功能用于申请上行资源。但这只适用于低密集度的上行资源请求的情况。图15：上行数据到达基于竞争上层触发的随机接入过程包括：1初始接入；2RRC连接重建； 3切换。图16：初始接入initial access图17：RRC连接重建RRC Reestablishment图18：handover基于竞争图19：handover基于非竞争对于handover，如果是基于竞争的随机接入，其msg3应该是C-RNTI MAC Control Element + BSR MAC Control Element + PHR MAC Control Element。

10、之前已经介绍过，RAR中UL grant指定的上行资源最小为56 bits。对于C-RNTI MAC Control Element，8 bits用于MAC subheader，16 bits用于C-RNTI MAC Control Element，共24 bits，还剩于32 bits。我在LTE：MAC复用和逻辑信道优先级中介绍过，MAC复用的优先级为： C-RNTI MAC Control Element and UL-CCCH Regular/Periodic BSR MAC Control Element PHR MAC Control Element 除了UL-CCCH外的其它逻辑

11、信道的数据 padding BSR MAC control element。所以在剩余的32 bits里会优先放置BSR和PHR：BSR：8 bits用于MAC subheader，8 bits用于BSR MAC Control ElementPHR：8 bits用于MAC subheader，8 bits用于PHR MAC Control Element但当RAR中的UL grant指定的上行资源足够大，除了容纳C-RNTI + BSR + PHR外，还能够容纳RRCConnectionReconfigurationplement消息时，如此msg3可以为C-RNTI + BSR + PHR

12、 + RRCConnectionReconfigurationplement。对于handover，如果eNodeB在重配置消息中，根本不带rach-ConfigDedicated字段该字段是OPTIONAL，即可选的，如此UE发起基于竞争的随机接入。图20：MobilityControlInfo属于LTE分类，被贴了 LTE、random access、随机接入过程 标签。步骤三：UE发送Msg3基于非竞争的随机接入， preamble是某个UE专用的，所以不存在冲突；又因为该UE已经拥有在接入小区内的唯一标志C-RNTI，所以也不需要eNodeB给它分配C-RNTI。因此，只有基于竞争的随

13、机接入才需要步骤三和步骤四。注：1使用基于非竞争的随机接入的UE必定原本处于RRC_CONNECTED态；2handover时，UE在目标小区使用的C-RNTI是通过RRCConnectionReconfiguration中的MobilityControlInfo的newUE-Identity来配置的。之所以将第3条消息称为Msg3而不是某一条具体消息的原因在于，根据UE状态的不同和应用场景的不同，这条消息也可能不同，因此统称为Msg3，即第3条消息。如果UE在子帧n成功地接收了自己的RAR，如此UE应该在n + 其中 6开始的第一个可用上行子帧对于FDD而言，就是n + 6；对于TDD而言，

14、n + 6可能不是上行子帧，所以可能 6发送Msg3。RAR所带的UL grant中包含一个1 bit的字段UL delay，如果该值为0，如此n + 为第一个可用于Msg3的上行子帧；如果该值为1，如此UE会在n + 之后的第一个可用上行子帧来发送Msg3。见36.213的6.1.1节正常的上行传输是在收到UL grant之后的4个子帧发送上行数据，其UL grant在PDCCH中传输。但对于Msg3来说，是在收到RAR之后的6个子帧上传输，这是因为RAR包含Msg3的UL grant是在PDSCH而不是PDCCH中传输，所以UE需要更多的时间去确定UL grant、传输格式等。Msg3在U

15、L-SCH上传输，使用HARQ，且RAR中带的UL grant指定的用于Msg3的TB大小至少为80比特。见36.300的10.1.5.1节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

16、MAC control element将自己的C-RNTI告诉eNodeB，eNodeB在步骤四中使用这个C-RNTI来解决冲突。当UE在随机接入过程中使用上行CCCH来发送Msg3消息时， UE还没有C-RNTI，此时UE会使用来自核心网的UE标志S-TMSI或一个随机数。步骤四中，eNodeB会通过发送UE Resolution Identity MAC Control Element携带了这个UE标志来解决冲突。注意：1Contention ResolutionIdentity MAC ControlElement是在步骤四中使用的。2在36.331中搜索“UL-CCCH-Message

17、，就可以知道有哪些上行RRC消息使用CCCH信道。当前只有RRC连接请求和RRC连接重建请求这两条消息使用上行CCCH。与随机接入的触发事件对应起来，Msg3携带的信息如下：1、如果是初次接入initial access，Msg3为在CCCH上传输的RRC Connection Request，且至少需要携带NAS UE标志信息。 2、如果是RRC连接重建RRC02 Connection Re-establishment，Msg3为CCCH上传输的RRC Connection Re-establishment Request，且不携带任何NAS消息。3、如果是切换handover，Msg3为在

18、DCCH上传输的经过加密和完整性保护的RRC Handover Confirm，必须包含UE的C-RNTI，且如果可能的话，需要携带BSR。4、对于其它触发事件，如此至少需要携带C-RNTI。上行传输通常使用UE特定的信息，如C-RNTI，对UL-SCH的数据进展加扰。但由于此时冲突还未解决，UE也还没有被分配最终的标志，所以加扰不能基于C-RNTI，而只能使用TC-RNTI。也就是说，Msg3只会使用TC-RNTI进展加扰步骤四：eNodeB发送contention resolution在步骤三中已经介绍过，UE会在Msg3有携带自己唯一的标志： C-RNTI或来自核心网的UE标志S-TMS

19、I或一个随机数。eNodeB在冲突解决机制中，会在Msg4我们把步骤四的消息称为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。如

20、果UE监听到了PDCCH，且UE在发送Msg3时携带了C-RNTI MAC control element，如此在以下2种情况下，UE认为冲突解决成功即该UE成功接入，此时UE会停止mac-ContentionResolutionTimer，并丢弃TC-RNTI。这2种情况下TC-RNTI不会提升为C-RNTI：1随机接入过程由MAC子层触发，且UE在Msg4中接收到的PDCCH由Msg3携带的C-RNTI加扰，且给新传的数据分配了上行资源；2随机接入过程由PDCCH order触发，且UE在Msg4中接收到的PDCCH由Msg3携带的C-RNTI加扰。如果Msg3在CCCH发送，且在Msg4

21、中接收到的PDCCH由RAR中指定的TC-RNTI加扰，如此当成功解码出的MAC PDU中包含的UE Contention Resolution Identity MAC control element与Msg3发送的CCCH SDU匹配时，UE会认为随机接入成功并将自己的C-RNTI设置成TC-RNTI。只要成功解码RAR MAC PDU，就停止mac-ContentionResolutionTimer，并不需要等待冲突解决成功。这种情况下TC-RNTI会提升为C-RNTI如果mac-ContentionResolutionTimer超时，UE会丢弃TC-RNTI并认为冲突解决失败。如果冲突

22、解决失败，UE需要1清空Msg3对应的HARQ buffer；2将PREAMBLE_TRANSMISSION_ COUNTER加1，如果此时PREAMBLE_TRANSMISSION_ COUNTER = preambleTransMax + 1，如此通知上层随机接入发生了问题Random Access problem indication；3在0BI值之间随机选择一个backoff time，UE延迟backoff time后，再发起随机接入。如果UE接入成功，UE会1如果收到ra-PreambleIndex和ra-PRACH-MaskIndex，如此丢弃；2清空Msg3对应的HARQ bu

23、ffer。对于Msg4而言，也使用HARQ，但不需要与Msg3同步。从前面的介绍可以看出，对于初始接入和无线链路失效而言，Msg4使用TC-RNTI加扰，且使用RLC-TM模式；而对处于RRC_CONNECTED态的UE而言，Msg4使用C-RNTI加扰。简单地说：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，发现二者匹配，就知道自己接入成功了。