LTE网络接通率分析思路
TD-LTE网络接通率分析思路
接通率优化的思路遵循以下方式：
1. 通过话统分析是否出现接入成功率低的问题，根据局方对接入成功率指
标的要求启动问题定位或专题优化。
2. 通过对话统的原始数据进行分析，查出问题出现最多的TOP站点和TOP
时间段。
3. 针对TOP站点进行针对性的网管信令跟踪，LMT跟踪，告警检查等。
4. 如果网管信令和LMT跟踪仍然无法定位问题，针对性的进行路测复现问
题，采集前后台log,请相关开发人员协助定位。
当获取接入问题的TOP小区和TOP时段后，通过网管信令跟踪，LMT跟踪，告警检查等方法首先排查是否设备异常、组网配置问题：
1. 排查小区状态。
-检查各单板状态、RRU是否正常，小区状态是否为可用；
-查看小区是否存在告警，进行告警分析；手动恢复告警后查看告警
是否存在；上报问题；
2. 排查UE、小区、核心网组网配置、对接参数是否正常(常见于实验网阶
段)。
-检查UE的频点配置是否与eNB一致，检查UE的PLMN与eNB
配置的PLMN是否一致，如果频点、PLMN配置不正确，UE进行
小区搜索失败。
-检查核心网是否有开户信息。测试的IMSI没开户，表现为用户完
成随机接入，上行直传消息后核心网立即回
“S1AP_DL_CONTEXT_REL_CMD”，释放UE。
-检查SCTP链路状态是否OK，如果异常，需要检查ENODB与
MME连接的网线是否插好，端口是否与配置的SCTP端口号一致，
是否与MME正常通信；检查S1接口状态是否正常，S1接口是否
处于闭塞状态，寻求设备侧同事的帮助和研发指导。
-检查安全模式配置。UE和核心网需要共同开启或关闭鉴权，并且
按照运营商提供的“LTE USIM卡参数建议”配置C值和R值。eNB
和核心网需要共同开启或关闭完整性保护算法和加密算法，并且保
证配置的算法一致。
检查IPPATH。基站在完成安全模式控制和UE能力查询后，将申
请准备GTPU资源，如果资源准备失败会向核心网返回促使上下
文建立失败响应消息：INIT_CONTEXT_SETUP_FAIL，原因值为：
transport resource unavailable。在这种情况下，需要MML查看
IPPACH配置是否正确，并且确认核心网在初始上下文建立请求中
携带的IPPACH值是否与eNB一致。
在上述基本检查皆未发现问题时，考虑进行路测，跟踪前、后台信令，进一步从空口无线环境对指标的影响角度进行问题的分析和解决。
根据初始接入的前台信令流程，从UE发起attach请求开始，将UE接入过程分解为三个阶段：RRC建立过程，初始直传和安全模式控制，E-RAB建立过程。目前用户量较少E-RAB 建立较少有失败的现象，而随机接入过程出现的问题较多，导致RRC连接无响应，引起起呼失败，所以解决随机接入失败问题是当前提升接通率的关键。
图接通率分析思路
1 接入失败根因分析全貌图
注意:
接通率的计算是从UE发起“attach请求”或“业务请求”到“初始上下文建立完成”这一过程，UE搜索不到小区或由于其他原因无法驻留小区不计算在接通率中，但作为接入失败的一种现象也在根因全貌分析图中进行了说明。
2 随机接入问题分析
随机接入过程发生在以下五种场景：
1. 从空闲态转到连接态的初始接入；
2. 无线链路失败后的接入；
3. 切换过程中的接入；
4. 当UE处于连接态时下行数据到达是因为某些原因需要随机接入，如上行
失步时有下行数据到达；
5. 当UE处于连接态时上行数据到达是因为某些原因需要随机接入，如上行
失步时有上行数据到达。
随机接入分为基于冲突的随机接入和基于非冲突的随机接入两个流程，其区别为针对两种流程其选择随机接入前缀的方式。前者为UE从基于冲突的随机接入前缀中依照一定算法随机选择一个随机前缀；后者是基站侧通过下行专用信令给UE指派非冲突的随机接入前缀。基于竞争的随机接入适用于上述1、2、5三种场景，非竞争的随机接入适用于上述3、4两种场景。
图基于竞争的随机接入
图基于非竞争的随机接入
UE eNB
1. MSG 1：UE选择随机接入前导preamble,,在PRACH上发送随机接入请
求；
2. MSG2：ENB的MAC层产生随机接入响应RAR，并在PDSCH上发送；
3. MSG3：UE的RRC层产生RRC Connection Request，并开启竞争解
决定时器，等待竞争解决消息。；
4. MSG4：RRC Connection Setup 由ENB的RRC层产生，连同竞争解
决控制信息映射到PDSCH上发送。
基于竞争的随机接入成功后，UE的RRC层生成RRC Connection Set up Complete并发往eNB。而非竞争的接入过程与基于竞争的接入过程最大差别在于接入前导的分配是由eNodeB产生的，这样就减少了竞争和冲突解决过程。
从前台UE侧角度分析竞争的随机接入失败发生在以下三个阶段：
1. MSG1发送后是否收到MSG2；
2. MSG3是否发送成功；
3. MSG4是否正确接收。
2.1 MSG1发送后是否收到MSG2
图MSG1分析思路
UE发出MSG1后未收到MSG2，UE按照Prach发送周期对MSG1进行重发。若收不到MSG2的PDCCH，可分别对上行和下行进行分析：
上行：
1. 结合后台MTS的PRACH信道收包情况，确认上行是否收到MSG1。
2. 检查MTS上行通道的接收功率是否>-99dBm，若持续超过-99dBm，解
决上行干扰问题，比如是否存在GPS交叉时隙干扰。
3. PRACH相关参数调整：提高PRACH期望接收功率，增大PRACH的功
率攀升步长，降低PRACH绝对前缀的检测门限。
下行：
1. UE侧收不到以RA_RNTI加扰的PDCCH，检查下行RSRP是
否>-119dBm，SINR>-3dB，下行覆盖问题通过调整工程参数、RS功率、
PCI等改善。
2. PDCCH相关参数调整：比如增大公共空间CCE聚合度初始值。
2.2 MSG3是否发送成功
图MSG3分析思路
根据随机接入流程，UE收到MSG2后若没有发出MSG3，检查MSG2带的授权信息是否正确；若UE已发出MSG3的PUSCH，结合基站侧信令查看EnodeB是否收到到RRC Connection Request，若基站侧已发出RRC Connection Setup前台未收到，如“2.3 MSG4是否正确接收”MSG4过程分析；若基站侧RRC Connection Request未收到，说明上行存在问题；
1. 检查MTS上行通道的接收功率是否>-99dBm，若持续超过-99dBm，解
决上行干扰问题。
2. 检查RAR中携带的MSG3功率参数是否合适，调整MSG3发送的功率。
2.3 MSG4是否正确接收
在随机接入过程中出现MSG4 fail，失败原因是failure at MSG4 due to CT timer expired。CT timer即冲突检测定时器，UE发出MSG3后开启CT timer等待冲突解决Msg4，若定时器到期时仍未收到msg4触发随机接入失败。该问题的分析思路如下图：
图MSG4 fail分析思路
1. UE是否收到PDCCH，若没有收到PDCCH，从下行信号分析及参数两
方面解决解决PDCCH接收问题。
2. 多次收到PDCCH后是否收到PDSCH？
（1）确认收到的PDCCH是否重传消息，检查重传消息的DCI格式填
写是否正确；
（2）PDSCH收不到，检查PDSCH采用的MCS，检查PA参数配置，
适当增大PDSCH的RB分配数。
3 鉴权、完保问题分析
鉴权、完保导致的未接通主要有以下表现：
1. eNB发起INIT_UE_MSG后，等待核心网回复初始上下文建立请求超时，
即核心网没有下发初始上下文建立请求消息，然后eNB主动发起RRC
连接释放，造成未接通。
2. eNB发起INIT_UE_MSG后和核心网进行NAS消息直传，在进行安全
模式控制交互之前，收到核心网下发的
S1AP_UeContextReleaseCommandMsg消息，随后eNodeB发出RRC
连接释放。
3. eNB收到核心网下发的S1AP_InitialContextSetupReq后，与UE进行
模式控制交互，UE回复SecurityModeFailure，导致未接通。
通常这些问题都是与UE、eNB、核心网的鉴权、完保、加密算法配置相关，需要多个网元配合排查。问题1.2可以在核心网侧信令查看鉴权失败的原因，问题3可以通过空口消息的分析，检查出SMC失败的原因。通过对UE、eNB、核心网的鉴权、完保、加密参数的调整来解决问题。