LTE随机接入过程.docx

LTE随机接入过程 l preamble传输达到最大传输次数的处理从UE的角度上看，随机接入过程可能遇到以下问题而导致随机接入失败： UE没有收到其发送的preamble对应的RAR（没有收到RAR，或收到的RAR MAC PUD中没有对应该preamble的RAR）；UE发送了Msg3，但没有收到Msg4；UE收到了Msg4，但该UE不是冲突解决的胜利者。如果某次随机接入失败了，UE会重新发起随机接入。在36.321中，介绍到一个字段preambleTransMax，该字段指定了preamble的最大传输次数。当UE发送的preamble数超过preambleTransMax时，协议要求MAC层发送一个random access problem indication到上层（通常是RRC层），但MAC层并不会停止发送preamble。也就是说，MAC层被设计成“无休止”地发送preamble，而出现“UE发送的preamble数超过preambleTransMax”时如何处理是由上层（RRC层）决定的。也就是说，无论是发生上面介绍的哪种情况，MAC层都会“无休止”地发送preamble以期望能成功接入小区。在收到MAC层的random access problem indication后，RRC层的行为取决于触发随机接入的场景：场景一：RRC连接建立。此时UE通过RRC timer T300来控制，当该timer超时（即RRC连接建立失败）时，UE的RRC层会停止随机接入过程（此时会重置MAC，释放MAC配置。而从36.321的5.9节可知，重置MAC会停止正在进行的随机接入过程），并通知上层RRC连接建立失败。（见36.331的5.3.3.6节）场景二：RRC连接重建。此时通过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.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层会忽略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 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 SystemInformationBlockType2TS 36.331 6.3.2 Radio resource control information elements PRACH-ConfigTS 36.331 6.3.2 Radio resource control information elements RACH-ConfigCommonTS 36.331 6.3.2 Radio resource control information elements RACH-ConfigDedicated本条目发布于2014/04/19。属于LTE分类，被贴了 LTE、preamble、random access、随机接入过程 标签。作者是wjhgh04。 l 各类触发事件下的随机接入过程本节将介绍各种触发事件是如何触发随机接入过程的，主要以信令流程图的方式予以说明。将本节内容与之前介绍的内容结合起来，有助于更深刻地理解随机接入过程。触发随机接入过程的事件有6种，见之前介绍。触发随机接入过程的方式有3种：1）PDCCH order触发；2）MAC sublayer触发；3）上层触发。由PDCCH order发起的随机接入过程（“initiated by a PDCCH order”）只有在如下场景才会发生：1）eNodeB要发送下行数据时，发现丢失了UE的上行同步，它会强制UE重新发起随机接入过程以获取正确的时间调整量；2）UE定位。这时eNodeB会通过特殊的DCI format 1A 告诉UE需要重新发起随机接入，并告诉UE应该使用的Preamble Index和PRACH Mask Index。（见36.212的5.3.3.1.3节、36.213的Table 8-4）02图12：DCI format 1A用于PDCCH order时的格式对应的信令流程如下（注：UE定位的处理流程与基于非竞争的下行数据到达场景类似）：图13：下行数据到达（基于竞争）图14：下行数据到达（基于非竞争）由MAC sublayer发起随机接入过程的场景有：UE有上行数据要发送，但在任意TTI内都没有可用于发送SR的有效PUCCH资源。此时上行数据传输的流程变为：1）UE 发送preamble；2）eNodeB回复RAR，RAR携带了UL grant信息；3）UE开始发送上行数据。什么情况下UE可能没有SR资源呢？场景一：从36.331可以看出，SchedulingRequestConfig是一个UE级的可选的IE（optional），默认为release。如果 eNodeB不给某UE配置SR（这取决于不同厂商的实现），则该UE只能通过随机接入来获取UL grant。因此，是否配置SR主要影响用户面的延迟，并不影响上行传输的功能！场景二：当UE丢失了上行同步，它也会释放SR资源，如果此时有上行数据要发送，也需要触发随机接入过程。从上面的描述可以看出，当UE没有被分配SR资源时，基于竞争的random access可以替代SR的功能用于申请上行资源。但这只适用于低密集度的上行资源请求的情况。图15：上行数据到达（基于竞争）上层触发的随机接入过程包括：1）初始接入；2）RRC连接重建； 3）切换。图16：初始接入（initial access）02图17：RRC连接重建（RRC Reestablishment）02图18：handover（基于竞争）图19：handover（基于非竞争）对于handover，如果是基于竞争的随机接入，其msg3应该是C-RNTI MAC Control Element + BSR MAC Control Element + PHR MAC Control Element。之前已经介绍过，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外的其它逻辑信道的数据 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外，还能够容纳RRCConnectionReconfigurationComplement消息时，则msg3可以为C-RNTI + BSR + PHR + RRCConnectionReconfigurationComplement。对于handover，如果eNodeB在重配置消息中，根本不带rach-ConfigDedicated字段（该字段是OPTIONAL，即可选的），则UE发起基于竞争的随机接入。图20：MobilityControlInfo本条目发布于2014/04/19。属于LTE分类，被贴了 LTE、random access、随机接入过程 标签。作者是wjhgh04。 l 步骤三：UE发送Msg3基于非竞争的随机接入， preamble是某个UE专用的，所以不存在冲突；又因为该UE已经拥有在接入小区内的唯一标志C-RNTI，所以也不需要eNodeB给它分配C-RNTI。因此，只有基于竞争的随机接入才需要步骤三和步骤四。注：（1）使用基于非竞争的随机接入的UE必定原本处于RRC_CONNECTED态；（2）handover时，UE在目标小区使用的C-RNTI是通过RRCConnectionReconfiguration中的MobilityControlInfo的newUE-Identity来配置的。之所以将第3条消息称为Msg3而不是某一条具体消息的原因在于，根据UE状态的不同和应用场景的不同，这条消息也可能不同，因此统称为Msg3，即第3条消息。如果UE在子帧n成功地接收了自己的RAR，则UE应该在n + （其中 6）开始的第一个可用上行子帧（对于FDD而言，就是n + 6；对于TDD而言，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在UL-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 MAC control element将自己的C-RNTI告诉eNodeBeNodeB在步骤四中使用这个C-RNTI来解决冲突。当UE在随机接入过程中使用上行CCCH来发送Msg3消息时， UE还没有C-RNTI，此时UE会使用来自核心网的UE标志（S-TMSI或一个随机数）。步骤四中，eNodeB会通过发送UE Resolution Identity MAC Control Element（携带了这个UE标志）来解决冲突。注意：（1）Contention Resolution Identity MAC Control Element是在步骤四中使用的。（2）在36.331中搜索“UL-CCCH-Message”，就可以知道有哪些上行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为在DCCH上传输的经过加密和完整性保护的RRC Handover Confirm，必须包含UE的C-RNTI，且如果可能的话，需要携带BSR。4、对于其它触发事件，则至少需要携带C-RNTI。上行传输通常使用UE特定的信息，如C-RNTI，对UL-SCH的数据进行加扰。但由于此时冲突还未解决，UE也还没有被分配最终的标志，所以加扰不能基于C-RNTI，而只能使用TC-RNTI。也就是说，Msg3只会使用TC-RNTI进行加扰l 步骤四：eNodeB发送contention resolution在步骤三中已经介绍过，UE会在Msg3有携带自己唯一的标志： C-RNTI或来自核心网的UE标志（S-TMSI或一个随机数）。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。如果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中接收到的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并认为冲突解决失败。如果冲突解决失败，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 buffer。对于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，发现二者匹配，就知道自己接入成功了。