LTE随机接入过程概要.docx

 HYPERLINK /?p=582 LTE随机接入过程 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的节） 场景二：RRC连接重建。此时通过RRC timer T301和T311来控制，当该timer超时（即RRC连接重建失败）时，UE的RRC层会停止MAC层的随机接入过程，并进入RRC_IDLE态。从36.331的5.3.12节可以看出，UE进入RRC_IDLE态之前会重置MAC。（见36.331的节和节） 场景三：Handover。此时通过RRC timer T304来控制，当该timer超时（即handover失败）时，UE的RRC层会停止之前的随机接入过程（如果之前分配了专用的用于非竞争随机接入的preamble，则此时认为该preamble不再有效），然后触发RRC连接重建过程。（见36.331的节） 场景四： RRC_CONNECTED态下，下行数据到达时，上行处于“不同步”状态（包括“定位UE”的场景）；或上行数据到达时，上行处于“不同步”状态或没有可用的PUCCH资源用于SR传输。由于这种场景下只有MAC层能感知到发生了???机接入过程，而RRC层是不知道的，所以当RRC层收到random access problem indication时，会认为无线链路失效（Radio Link Failure）了，此时如果AS安全还没被激活，UE会进入RRC_IDLE态；否则的话，UE会发起RRC连接重建流程（见36.331的节） 从上面的介绍可以看出，在场景一、场景二、场景三中，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] 《 HYPERLINK /get_trained/expert_opinion1/b/johnmckeague/archive/2013/03/21/random-access-supervision.aspx Random Access Supervision – Part 1》和《 HYPERLINK /get_trained/expert_opinion1/b/johnmckeague/archive/2013/03/25/random-access-supervision-part-2.aspx 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