LTE优化案例，日常优化中总结

文档发布

【资料名称】：LTE优化案例

【资料作者】：XZ

【资料日期】：2014

【资料语言】：中文

【资料格式】：DOC/DOCX

【资料目录和简介】：

案例1：LTE案例--2G小区拥塞导致CSFB失败

案例2：LTE案例--GPS失锁导致LTE掉线率高

都是在日常优化中总结的案例，不足之处，请各位大侠们指正。

部分内容：

1.经核查邻区配置等均无问题；
2.蚌埠市区为一个POOL；
3.在问题地点进行复现拨测，发现约有40%的概率出现被叫失败的情况。
正常CSFB流程如下：
阶段一：从发起ESR业务请求到接收到LTE下发的RRC_REL消息。为发起业务LTE内部处理进行释放的过程。时延均值约为100ms。
阶段二：从RRC_REL消息后进行回落，一直到回落到2G后发起CM_SERVICE_REQUEST 。为回落发起CS业务过程。时延均值约为1.8s。
阶段三：从发起CM_SERVICE_REQUEST到CC_SETUP。为发起业务到建立资源信道过程。时延均值约为1.6s。阶段四：从CC_SETUP到CC_PROCEEDING。为发起呼叫的过程。时延均值约为0.7s。
阶段五：从CC_PROCEEDING到ALERTIN。为寻呼被叫并接通的过程。时延均值约为7.5s。
备注：被叫流程中GSM网络中Paging Response消息取代CM Service Request消息，Call confirm消息取代Call proceeding消息。

把每一次失败的LOG作分析，可以发现每一次失败原因都一样，问题都出在阶段二，UE长时间不做寻呼响应导致寻呼超时。（正常点为2S左右，问题点超过17S）。
4. 分析结果如下：
而在寻呼超时的LOG中看，从第一条2G信令到paging response则消耗了90%的时间，就是说在2G侧进行接入并被BCS指派信道这一段时间是造成问题的主要原因。

1. 故障描述：
蚌埠怀远县城22日凌晨开始LTE网管接通率，掉线率急剧恶化，明显高于昨日同时段指标。