4G KPI优化流程

LTE TOP小区处理思路1 日常关注KPI话统KPI主要包括以下几大类：接入性指标、保持性指标、移动性指标、干扰指标、信道质量指标等。

通过对这些指标的监控、处理，可以达到：识别发现问题、风险提前预警、话统KPI的稳定与用户使用感知的提升。

实际处理过程中，应优先处理对用户影响较大指标，接通、掉线、切换三大指标，同时参考流量、信道质量、寻呼响应等指标分析处理；1.1指标项1.2指标公式2 KPI处理需求➢全网整体指标监控：重点监控切换成功率、掉线率、无线接通率、流量走势；建议提取前一天全网小时级指标与近一周数据走势对比，是否有较大波动，并分析具体原因，整网还是TOP小区影响；现阶段要求切换、接通率大于99%，掉线率小于0.5%；流量应无明显下滑（重大活动等影响除外）；➢TOP小区处理：建议选取昨日8点-23点15忙时相关指标，优先处理VIP区域、高业务区、高投诉区域小区；3 TOP小区查找和分析处理3.1 接入性TOP分析处理3.1.1筛选条件提取15忙时数据，筛选出TOP小区，对未恢复的小区进行分析处理：➢VIP小区、高业务量小区、重点活动保障区、高投诉区，请求次数较多的小区需及时处理；➢连接请求次数小于50次的TOP小区，由于触发次数较少，等级次之；如果多个时段连续无成功次数，需提升处理等级；➢业务量较小，无线环境较差，等级次之；指标定义3.1.2接入相关指标项3.1.3RRC建立失败原因小区RRC建立失败次数：➢资源分配失败而导致RRC连接建立失败的次数，指标ID：1526727083；重点关注top 资源是否足够，包括top用户数，传输、PRB等；➢UE无应答而导致RRC连接建立失败的次数，指标ID：1526727084；关注质差、干扰、无线环境等；➢小区发送RRC Connection Reject消息次数，指标ID：1526728269；关注传输问题、是否拥塞、干扰；➢因为SRS资源分配失败而导致RRC连接建立失败的次数，指标ID：1526728485；重点关注SRS带宽、配置指示、配置方式、SRS ACK/NACK设置是否合理等；➢因为PUCCH资源分配失败而导致RRC连接建立失败的次数，指标ID：1526728486；关注PUCCH信道相关参数设置是否合理，CQI RB数配置是否合理等；➢流控导致的RRC Connection Request 消息丢弃次数，指标ID：1526728489；关注拥塞，业务流控相关参数是否设置正确等；➢流控导致的发送RRC Connection Reject消息次数，指标ID：1526728490；关注拥塞，业务流控相关参数是否设置正确等；3.1.4E-RAB建立失败原因对小区E-RAB建立失败次数：➢因未收到UE响应而导致E-RAB建立失败的次数，指标ID：1526726717；处理建议：需排查覆盖，干扰，质差，ENODEB参数设置错误，终端及用户行为异常等原因。

➢核心网问题导致E-RAB建立失败次数，指标ID：1526728276；处理建议：需跟踪信令，排查核心网问题（EPC参数设置,TAC码设置的一致性，对用户开卡限制，硬件故障方面排查）；➢传输层问题导致E-RAB建立失败次数，指标ID：1526728277；处理建议：需查询传输是否有故障，高误码，闪断，传输侧参数设置问题。

➢无线层问题导致E-RAB建立失败次数，指标ID：1526728278；处理建议：处理建议：需排查覆盖，干扰，质差，ENODEB参数设置错误，终端及用户行为异常等原因。

➢无线资源不足导致E-RAB建立失败次数，指标ID：1526728279；处理建议：1、排查TOP小区资源是否足够，是否故障引起，若存在资源不足问题，可考虑参数调整，流量均衡（小区选择，重选和切换类参数）；2、结合现场调整天馈，流量均衡；3、热点区域，增补基站等；➢安全模式配置失败导致E-RAB建立失败次数，指标ID：1526728280；处理建议：需排查覆盖，干扰，质差，ENODEB参数设置错误，终端及用户行为异常等原因。

3.1.5接入类问题处理思路在一般正常情况下建立失败的通常为无线侧问题导致的可以处理，具体常见处理方法和流程如下：➢检查操作，告警，传输问题，是否存在网络变动和升级行为等（1.通过LST ALMAF查询站点实时告警,用LST ALMLOG参考历史告警；→存在告警则降低功率切出用户，严重的临时去激活小区，通知维护人员处理；➢通过DSP BRD 查询单板运行情况；→异常则通知维护人员；➢传输及EPC侧有网络变动（升级，割接，参数修改等）。

→一般为突发，及时同时相关人员；➢通过Mapinfo查看小区PCI复用是否合理，是否存在模三冲突；→用MOD CELL 修改PCI；➢检查小区时隙配比是否设置准确（室分:SA2\SSP7;宏站:SA2\SSP5）→LST CELL查看，MOD CELL修改；➢如每PRB上干扰噪声平均值>-110dBm,确认小区存在上行干扰，同时可通过后台跟踪，确认干扰类型；→统计话务统计看是突发的还是持续的，可应急通过MOD PDSCH降功率处理；➢检查传输模式，是否为TM3，如长时间为TM2，确认设置正确的情况下，基本确定小区存在弱覆盖；➢对比64QAM和QPSK占比，如后者比例远大于前者,可确定小区覆盖异常；➢邻区告警、故障等导致TOP小区存在弱覆盖；➢天馈问题,无线环境差；➢天线权值配置与现场天线参数不一致。

➢核查参考信号功率是否偏低（常规设置92,122，需结合现场设置）；→MOD PDSCH 进行修改；➢接通率处理思虑3.1.6拥塞类问题处理思路问题现象:在eNodeB侧话统Counter定义中，如果异常释放打点在L.E-RAB.AbnormRel.Cong Counter下，则可以判定为该掉话是由于资源拥塞问题导致的掉话。

可能原因:针对原因值为Congestion的掉话，主要是由于eNodeB侧无线资源拥塞导致的异常释放，如达到最大用户数等。

处理步骤:一旦某TOP小区出现长时间的拥塞导致的掉话，短期内可考虑打开负载均衡算法/互操作以减轻本小区的负载，长期来看，需要通过扩容等方法解决，并在通过拥塞问题解决后观察掉话类指标是否恢复。

拥塞及用户数相关Counter另外要同时关注eNodeB侧LICENSE的配置情况以及LICENSE的有效日期3.2 保持性TOP小区分析处理3.2.1筛选条件掉线率直接影响用户使用感知，提取15忙时数据，筛选出TOP小区，对未恢复的小区进行分析处理：➢VIP小区、高业务量小区、重点活动保障区、高投诉区，请求次数较多的小区需及时处理；➢UE Context建立成功总次数小于50次的TOP小区，由于触发次数较少，等级次之；但如果多个时段连续UE Context异常释放次数与建立成功次数相等，需提升处理等级；➢业务量较小，无线环境较差，等级次之；3.2.2指标定义3.2.3异常释放原因分析TOP小区分析可通过M2000提取异常释放原因：无线掉线率释放原因如下：□eNodeB发起的原因为UE LOST的UE Context释放次数□eNodeB发起的原因为切换失败的UE Context释放次数□eNodeB发起的原因为无线层问题的UE Context释放次数□eNodeB发起的S1 RESET导致的UE Context释放次数E-RAB掉线率释放原因如下：□无线层问题导致的激活的E-RAB异常释放次数□传输层问题导致的激活的E-RAB异常释放次数□网络拥塞导致的激活的E-RAB异常释放次数□切换流程失败导致激活的E-RAB异常释放次数□核心网问题导致E-RAB异常释放次数3.2.4异常释放后台统计指标项3.2.5保持类问题处理过程➢通过LST ALMAF查询站点实时告警,参考历史告警LST ALMLOG；→存在告警则降低功率切出用户，严重的临时去激活小区，通知维护人员处理；➢通过DSP BRD 查询单板运行情况；→若异常，通知维护人员处理；➢提取两两小区切换，确定目标小区：⏹确定目标小区运行情况，是否基站故障或异常告警；→若异常，通知维护人员处理；⏹检查邻区间参数设置是否正确；→核查修改邻区外部小区参数是否正确，切换偏置是否合理；⏹通过Mapinfo检查小区邻区配置是否合理，进行邻区合理性优化；→进行邻区的合理删除和添加；⏹检查基站是否周边站点缺少，如为孤站，可视为正常；→暂不做处理，观察；➢检查参数设置是否合理：⏹查询掉线类定时器设置是否正确；（T310、N311、N310、T311、T301）. LSTUETIMERCONST:;⏹如掉线率突增，查询操作日志，确认是否有修改，导致小区异常；→用LST OPTLOG查看是否指标异常开始时段有相应修改操作，询问修改人进行相应恢复观察；➢检查是否存在干扰：⏹通过Mapinfo查看小区PCI复用是否合理，是否存在模三冲突；→修改PCI⏹检查小区时隙配比是否设置准确（E频段室分:SA2\SSP7; F和D频段宏站:SA2\SSP5）；→修改时隙配比配比MOD CELL;⏹如每PRB上干扰噪声平均值>-110dBm,确认小区存在上行干扰，同时可通过后台跟踪，确认干扰类型；→统计话务统计看是突发的还是持续的，可应急通过MODPDSCH降功率处理；➢是否存在高质差：⏹通过观察小区上下行丢包率是否正常，如丢包率偏高，基本断定小区存在质差；⏹通过后台误码率跟踪，如BLER>10%，确定小区存在高误码；➢是否存在弱覆盖：⏹检查传输模式，是否为TM3，如长时间为TM2，确认设置正确的情况下，基本确定小区存在弱覆盖；⏹对比64QAM和QPSK占比，如后者比例远大于前者,可确定小区覆盖异常；➢现场测试及后台跟踪：⏹安排前场人员现场测试，同时后台通过信令跟踪，配合查找问题原因；⏹如果确认问题后，需配合解决，转发相关人员处理，做好跟踪工作，直至问题闭环。

➢掉线处理思路3.3 移动性指标TOP小区分析与处理3.3.1筛选条件提取15忙时数据，筛选出TOP小区，对未恢复的小区进行分析处理：➢VIP小区、高业务量小区、重点活动保障区、高投诉区，请求次数较多的小区需及时处理；➢切换尝试次数小于50次的TOP小区，由于触发次数较少，等级次之；但如果多个时段连续切换成功次数为0，需提升处理等级，考虑PCI冲突等切换问题；➢业务量较小，无线环境较差，等级次之；3.3.2指标定义3.3.3切换失败原因分析TOP小区分析可通过M2000提取切换出失败原因：□核心网原因导致切换出准备失败次数□目标小区无响应导致切换出准备失败次数□目标小区回复切换准备失败消息导致切换出准备失败次数□源小区发送切换取消导致切换出准备失败次数□eNodeB间切换出取消次数3.3.4切换失败相关指标项3.3.5切换失败处理过程➢查询站点有无告警,小区状态是否正常；（1.通过LST ALMAF查询站点实时告警,用LST ALMLOG参考历史告警；→存在告警则降低功率切出用户，严重的临时去激活小区，通知维护人员处理；➢查询有无外部干扰（每PRB上干扰噪声平均值>-110dBm，则存在外部干扰）；→统计话务统计看是突发的还是持续的，可应急通过MOD PDSCH降功率处理；➢提取两两小区切换，确定切换出目标小区，核查外部小区参数（PCI、TAC、频点、小区标识、切换参数）配置有无错误；→若错误则对外部定义的小区参数进行修改，另外关注两两小区切换过早和过晚或者乒乓切换统计，进行相应的CIO调整；➢查看MAPINFO图层，查看邻区是否存在MOD干扰，确认基站规划是否合理，是否会产生弱覆盖。