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

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

《LTE随机接入过程Word格式.docx》由会员分享，可在线阅读，更多相关《LTE随机接入过程Word格式.docx（14页珍藏版）》请在冰豆网上搜索。

此时通过RRCtimerT301和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。

此时通过RRCtimerT304来控制，当该timer超时〔即handover失败〕时，UE的RRC层会停止之前的随机接入过程〔如果之前分配了专用的用于非竞争随机接入的preamble，如此此时认为该preamble不再有效〕，然后触发RRC连接重建过程。

〔见36.331的5.3.5.6节〕

场景四：

RRC_CONNECTED态下，下行数据到达时，上行处于“不同步〞状态〔包括“定位UE〞的场景〕；

或上行数据到达时，上行处于“不同步〞状态或没有可用的PUCCH资源用于SR传输。

由于这种场景下只有MAC层能感知到发生了随机接入过程，而RRC层是不知道的，所以当RRC层收到randomaccessproblemindication时，会认为无线链路失效〔RadioLinkFailure〕了，此时如果AS安全还没被激活，UE会进入RRC_IDLE态；

否如此的话，UE会发起RRC连接重建流程〔见36.331的5.3.11.3节〕

从上面的介绍可以看出，在场景一、场景二、场景三中，RRC层会忽略MAC层送上来的randomaccessproblemindication，而是根据对应的timer来决定是否停止之前的随机接入过程。

只有场景四下，RRC层会对randomaccessproblemindication进展处理。

【参考资料】

[1]《4GLTE/LTE-AdvancedforMobileBroadband》的14.3节

[2]《LTE–TheUMTSLongTermEvolution,2ndEdition》的17章

[3]《RandomAccessSupervision–Part1》和《RandomAccessSupervision–Part2》byJohnM.

[4]23GPP协议v10

TS36.211–5.7Physicalrandomaccesschannel

TS36.213–6MACLayerProcedurerelatedtoRACHProcess.

TS36.300–10.1.5OveralldescriptionofRACHProcess.先阅读这个.

TS36.321–5.1MACLayerprocessofrandomaccessprocedure.

TS36.331–6.3.1Systeminformationblocks�1�7SystemInformationBlockType2

TS36.331–6.3.2Radioresourcecontrolinformationelements–PRACH-Config

TS36.331–6.3.2Radioresourcecontrolinformationelements–RACH-Configmon

TS36.331–6.3.2Radioresourcecontrolinformationelements–RACH-ConfigDedicated

本条目发布于2014/04/19。

属于LTE分类，被贴了LTE、preamble、randomaccess、随机接入过程标签。

作者是wjhgh04gmail。

●各类触发事件下的随机接入过程

本节将介绍各种触发事件是如何触发随机接入过程的，主要以信令流程图的方式予以说明。

将本节内容与之前介绍的内容结合起来，有助于更深刻地理解随机接入过程。

触发随机接入过程的事件有6种，见之前介绍。

触发随机接入过程的方式有3种：

1〕PDCCHorder触发；

2〕MACsublayer触发；

3〕上层触发。

由PDCCHorder发起的随机接入过程〔“initiatedbyaPDCCHorder〞〕只有在如下场景才会发生：

1〕eNodeB要发送下行数据时，发现丢失了UE的上行同步，它会强制UE重新发起随机接入过程以获取正确的时间调整量；

2〕UE定位。

这时eNodeB会通过特殊的DCIformat1A告诉UE需要重新发起随机接入，并告诉UE应该使用的PreambleIndex和PRACHMaskIndex。

〔见36.212的5.3.3.1.3节、36.213的Table8-4〕

�0�2

图12：

DCIformat1A用于PDCCHorder时的格式

对应的信令流程如下〔注：

UE定位的处理流程与基于非竞争的下行数据到达场景类似〕：

图13：

下行数据到达〔基于竞争〕

图14：

下行数据到达〔基于非竞争〕

由MACsublayer发起随机接入过程的场景有：

UE有上行数据要发送，但在任意TTI内都没有可用于发送SR的有效PUCCH资源。

此时上行数据传输的流程变为：

1〕UE发送preamble；

2〕eNodeB回复RAR，RAR携带了ULgrant信息；

3〕UE开始发送上行数据。

什么情况下UE可能没有SR资源呢？

从36.331可以看出，SchedulingRequestConfig是一个UE级的可选的IE〔optional〕，默认为release。

如果eNodeB不给某UE配置SR〔这取决于不同厂商的实现〕，如此该UE只能通过随机接入来获取ULgrant。

因此，是否配置SR主要影响用户面的延迟，并不影响上行传输的功能！

当UE丢失了上行同步，它也会释放SR资源，如果此时有上行数据要发送，也需要触发随机接入过程。

从上面的描述可以看出，当UE没有被分配SR资源时，基于竞争的randomaccess可以替代SR的功能用于申请上行资源。

但这只适用于低密集度的上行资源请求的情况。

图15：

上行数据到达〔基于竞争〕

上层触发的随机接入过程包括：

1〕初始接入；

2〕RRC连接重建；

3〕切换。

图16：

初始接入〔initialaccess〕

图17：

RRC连接重建〔RRCReestablishment〕

图18：

handover〔基于竞争〕

图19：

handover〔基于非竞争〕

对于handover，如果是基于竞争的随机接入，其msg3应该是C-RNTIMACControlElement+BSRMACControlElement+PHRMACControlElement。

之前已经介绍过，RAR中ULgrant指定的上行资源最小为56bits。

对于C-RNTIMACControlElement，8bits用于MACsubheader，16bits用于C-RNTIMACControlElement，共24bits，还剩于32bits。

我在《LTE：

MAC复用和逻辑信道优先级》中介绍过，MAC复用的优先级为：

C-RNTIMACControlElementandUL-CCCH>

Regular/PeriodicBSRMACControlElement>

PHRMACControlElement>

除了UL-CCCH外的其它逻辑信道的数据>

paddingBSRMACcontrolelement。

所以在剩余的32bits里会优先放置BSR和PHR：

BSR：

8bits用于MACsubheader，8bits用于BSRMACControlElement

PHR：

8bits用于MACsubheader，8bits用于PHRMACControlElement

但当RAR中的ULgrant指定的上行资源足够大，除了容纳C-RNTI+BSR+PHR外，还能够容纳RRCConnectionReconfigurationplement消息时，如此msg3可以为C-RNTI+BSR+PHR+RRCConnectionReconfigurationplement。

对于handover，如果eNodeB在重配置消息中，根本不带rach-ConfigDedicated字段〔该字段是OPTIONAL，即可选的〕，如此UE发起基于竞争的随机接入。

图20：

MobilityControlInfo

属于LTE分类，被贴了LTE、randomaccess、随机接入过程标签。

●步骤三：

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所带的ULgrant中包含一个1bit的字段ULdelay，如果该值为0，如此n+

为第一个可用于Msg3的上行子帧；

如果该值为1，如此UE会在n+

之后的第一个可用上行子帧来发送Msg3。

〔见36.213的6.1.1节〕

正常的上行传输是在收到ULgrant之后的4个子帧发送上行数据，其ULgrant在PDCCH中传输。

但对于Msg3来说，是在收到RAR之后的6个子帧上传输，这是因为RAR〔包含Msg3的ULgrant〕是在PDSCH而不是PDCCH中传输，所以UE需要更多的时间去确定ULgrant、传输格式等。

Msg3在UL-SCH上传输，使用HARQ，且RAR中带的ULgrant指定的用于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-RNTIMACcontrolelement将自己的C-RNTI告诉eNodeB，eNodeB在步骤四中使用这个C-RNTI来解决冲突。

当UE在随机接入过程中使用上行CCCH来发送Msg3消息时，UE还没有C-RNTI，此时UE会使用来自核心网的UE标志〔S-TMSI或一个随机数〕。

步骤四中，eNodeB会通过发送UEResolutionIdentityMACControlElement〔携带了这个UE标志〕来解决冲突。

注意：

〔1〕ContentionResolutionIdentityMACControlElement是在步骤四中使用的。

〔2〕在36.331中搜索“UL-CCCH-Message〞，就可以知道有哪些上行RRC消息使用CCCH信道。

当前只有RRC连接请求和RRC连接重建请求这两条消息使用上行CCCH。

与随机接入的触发事件对应起来，Msg3携带的信息如下：

1、如果是初次接入〔initialaccess〕，Msg3为在CCCH上传输的RRCConnectionRequest，且至少需要携带NASUE标志信息。

2、如果是RRC连接重建〔RRC�0�2ConnectionRe-establishment〕，Msg3为CCCH上传输的RRCConnectionRe-establishmentRequest，且不携带任何NAS消息。

3、如果是切换〔handover〕，Msg3为在DCCH上传输的经过加密和完整性保护的RRCHandoverConfirm，必须包含UE的C-RNTI，且如果可能的话，需要携带BSR。

4、对于其它触发事件，如此至少需要携带C-RNTI。

上行传输通常使用UE特定的信息，如C-RNTI，对UL-SCH的数据进展加扰。

但由于此时冲突还未解决，UE也还没有被分配最终的标志，所以加扰不能基于C-RNTI，而只能使用TC-RNTI。

也就是说，Msg3只会使用TC-RNTI进展加扰

●步骤四：

eNodeB发送contentionresolution

在步骤三中已经介绍过，UE会在Msg3有携带自己唯一的标志：

C-RNTI或来自核心网的UE标志〔S-TMSI或一个随机数〕。

eNodeB在冲突解决机制中，会在Msg4〔我们把步骤四的消息称为Msg4〕中携带该唯一的标志以指定胜出的UE。

而其它没有在冲突解决中胜出的UE将重新发起随机接入。

eNodeB会通过PCell上使用C-RNTI加扰的PDCCH，或DL-SCH上传输的UEContentionResolutionIdentityMACcontrolelement来指明哪个UE在冲突解决中胜出。

UE发送了Msg3后，会启动一个mac-ContentionResolutionTimer，并在Msg3进展HARQ重传时，重启该timer。

在该timer超时或停止之前，UE会一直监听PDCCH。

如果UE监听到了PDCCH，且UE在发送Msg3时携带了C-RNTIMACcontrolelement，如此在以下2种情况下，UE认为冲突解决成功〔即该UE成功接入，此时UE会停止mac-ContentionResolutionTimer，并丢弃TC-RNTI。

这2种情况下TC-RNTI不会提升为C-RNTI〕：

1〕随机接入过程由MAC子层触发，且UE在Msg4中接收到的PDCCH由Msg3携带的C-RNTI加扰，且给新传的数据分配了上行资源；

2〕随机接入过程由PDCCHorder触发，且UE在Msg4中接收到的PDCCH由Msg3携带的C-RNTI加扰。

如果Msg3在CCCH发送，且在Msg4中接收到的PDCCH由RAR中指定的TC-RNTI加扰，如此当成功解码出的MACPDU中包含的UEContentionResolutionIdentityMACcontrolelement与Msg3发送的CCCHSDU匹配时，UE会认为随机接入成功并将自己的C-RNTI设置成TC-RNTI。

〔只要成功解码RARMACPDU，就停止mac-ContentionResolutionTimer，并不需要等待冲突解决成功。

这种情况下TC-RNTI会提升为C-RNTI〕

如果mac-ContentionResolutionTimer超时，UE会丢弃TC-RNTI并认为冲突解决失败。

如果冲突解决失败，UE需要

1〕清空Msg3对应的HARQbuffer；

2〕将PREAMBLE_TRANSMISSION_COUNTER加1，如果此时PREAMBLE_TRANSMISSION_COUNTER=preambleTransMax+1，如此通知上层随机接入发生了问题〔RandomAccessproblemindication〕；

3〕在0~BI值之间随机选择一个backofftime，UE延迟backofftime后，再发起随机接入。

如果UE接入成功，UE会

1〕如果收到ra-PreambleIndex和ra-PRACH-MaskIndex，如此丢弃；

2〕清空Msg3对应的HARQbuffer。

对于Msg4而言，也使用HARQ，但不需要与Msg3同步。

从前面的介绍可以看出，对于初始接入和无线链路失效而言，Msg4使用TC-RNTI加扰，且使用RLC-TM模式；

而对处于RRC_CONNECTED态的UE而言，Msg4使用C-RNTI加扰。

简单地说：

1〕如果UE原本就处于RRC_CONNECTED态，如此该UE在小区内有唯一的标志C-RNTI。

步骤三中，Msg3会通过C-RNTIMACcontrolelement把这个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会通过UEContentionResolutionIdentityMACControlElement将步骤三的信息发回给UE，UE比拟Msg3和Msg4，发现二者匹配，就知道自己接入成功了。