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进行处理。
【参考资料】
[1] 《4G LTE/LTE-Advanced for Mobile Broadband》的14.3节
[2] 《LTE – The UMTS Long Term Evolution, 2nd Edition》的17章
[3] 《Random Access Supervision – Part 1》和《Random Access Supervision – Part 2》by John M.
[4] 23GPP协议 v10
TS 36.211 – 5.7 Physical random access channel
TS 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 �1�7 SystemInformationBlockType2
TS 36.331 – 6.3.2 Radio resource control information elements – PRACH-Config
TS 36.331 – 6.3.2 Radio resource control information elements – RACH-ConfigCommon
TS 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）
�0�2

图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）

�0�2
图17：RRC连接重建（RRC Reestablishment）
�0�2

图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 Element
PHR：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告诉eNodeB，eNodeB在步骤四中使用这个C-RNTI来解决冲突。

当UE在随机接入过程中使用上行CCCH来发送Msg3消息时， UE还没有CRNTI，此时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连接重建（RRC�0�2 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）在0~BI值之间随机选择一个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，发现二者匹配，就知道自己接入成功了。