【案例分享】 LTE接入失败问题分析

案例背景：

在某个基站下做业务测试时，UE终端一直不能接入LTE网络。

问题描述：

在某次测试中发现 UE 在 PCI126、127 小区做业务时，多次发起 RRC Connection Request 消息，但始终无法接入。

问题具体信令如下：

    如上图 UE 在问题小区多次发起 Service Requset 随后发起 RRC Connection Request 。但系统侧一直未响应 RRC Connection Setup 。

分析与对策：

    随机接入排查思路：

 步骤一：在发送上行接入前导序列之前，终端应该已经和系统下行同步好了，下行同步意味着 UE 获得了帧同步以及系统广播消息，但是上行并没有同步。通过前导序列，让 eNB 知道存在一个终端试图跟基站建立连接；

根据确认的前导分配相应的资源用于发送消息 3 （ MSG3 ）；

步骤二： eNB 通过时隙调整确保上行同步，也就是发送 time-advance 消息实现；同时分配上行资源，这些内容就是由随机接入响应消息携带；

步骤三：在已经分配的资源上发送用户 ID ，以及相应的 UL-SCH 信息用于发送用户 ID 以及 RRC 连接请求之类的等基本信息，也就是所谓的消息 3 了（ MSG3 ），具体内容跟用户所处的状态相关；

步骤四：通过 DL-SCH 发送冲突解决消息到终端。

只有第一步是纯粹的物理层过层，后面三个步骤跟普通的数据传输过程没有区别，看 MAC 协议经常看到 MSG3 或者 MSG4 等等，因为在随机接入的过程中，这些消息的内容不是固定，有时候可能携带的是 RRC 连接请求，有时候可能会带一些控制消息甚至业务数据包，因此简称为消息 3 之类，其意思就是第三条消息。

从 DSP 监控可以判断 MSG2 网络侧已经发送，因为没有内部消息无法判断 UE 是否正确解析 MSG2 ，在层 3 中可以看到 MSG3 UE 已经发送，所以认为 MSG3 消息问题，该问题针对 MSG3 发布上去进行分析。

根据以上排查思路进行现场排查：

1.     首先对该站点的告警进行过滤，该站点无任何告警。

           2.     其次对两个小区的上行干扰（ IOT ）进行跟踪，发现每个 RB 的 IOT 基本都在 -115dB 左右，可以排除上行干扰问题导致。

           3.     对数据配置进行了核查，发现配置数据正确。

           4.     检查告警、数据配置无果，因为该站点之前测试接入正常，突然出现无法接入现象，对该站点操作记录进行过滤，发现有人改过时隙配置，再次对时隙配置进行检查，跟现网配置一致。

   5.     怀疑网管未能将配置同步至 eNodeB, ，对该站点进行整表同步后，业务恢复正常。

处理结果：

将该站点进行整表同步业务接入正常，如下图切换后的随机接入正常。