LTE掉话类KPI基本分析定位方法

掉话类KPI

1.通过LST ALMAF查询站点实时告警,参考历史告警；

2.通过DSP BRD 查询单板运行情况；

3.提取两两小区切换，确定目标小区：

A.确定目标小区运行情况，是否基站故障或异常告警；

B.检查邻区间参数设置是否正确；

C.通过Mapinfo检查小区邻区配置是否合理，进行邻区合理性优化；

D.检查基站是否周边站点缺少，如为孤站，可视为正常；

4.检查参数设置是否合理：

A.查询掉线类定时器设置是否正确；（T310、N311、N310、T311、T301）.如掉线率突

增，B.查询操作日志，确认是否有修改，导致小区异常；

5.检查是否存在干扰：

A.通过Mapinfo查看小区PCI复用是否合理，是否存在模三冲突；

B.检查小区时隙配比是否设置准确（室分:SA2\SSP7;宏站:SA2\SSP5）；

C.如每PRB上干扰噪声平均值>-110dBm,确认小区存在上行干扰，同时可通过后台跟踪，确认干扰类型；

6.是否存在高质差：

A.通过观察小区上下行丢包率是否正常，如丢包率偏高，基本断定小区存在质差；

B. 通过后台误码率跟踪，如BLER>10%，确定小区存在高误码；

7.是否存在弱覆盖：

A.检查传输模式，是否为TM3，如长时间为TM2，确认设置正确的情况下，基本确定小区存在弱覆盖；

B. 对比64QAM和QPSK占比，如后者比例远大于前者,可确定小区覆盖异常；

8.现场测试及后台跟踪：

A.安排前场人员现场测试，同时后台通过信令跟踪，配合查找问题原因；

B.如果确认问题后，需第三方配合解决，转发相关人员处理，做好跟踪工作，直至问题闭环。

1、关于掉话的定义

话统掉话的定义

当ENodeB收到来自MME的ERAB ReleaseCommand（UE Context Release Command）消息或eNodeB向MME发送E-RAB RELEASE INDICATION（UE CONTEXT RELEASE REQUEST ）消息，且释放原因不为“Normal Release”，“User Inactivity”，“Partial Handover”，“Handover triggered”，“successful-handover”，“cs-fallback-triggered”时统计该指标。如果E-RAB RELEASE COMMAND消息中要求同时释放多个E-RAB，则相应指标按各个业务的QCI分别进行累加。

2、掉话基本排查步骤

2.1、基本排查

首先需要在话统侧获取全网的掉话率指标以及趋势，掉话率趋势分析至少1到2周的数据，如果掉话率指标突然偏高，一般执行步骤：

是否全网问题

对全网MME及eNodeB侧进行告警核查（传输，设备等告警），观察期间是否实施版本升级

是否存在Top小区：

小区级的掉话率指标和掉话绝对次数按从高到低的顺序进行排序，优先分析掉话绝对次数多而且掉话率高的Top小区

对Top小区进行参数核查、告警检查等

对引起掉话的Top原因进行定位分析

若是共性问题，将优化结果复制到全网

参数对比

随机抽取部分站点的脚本与基线参数进行核对，对不一致的参数进行分析；

告警核查

是否存在传输告警：观察S1传输是否出现问题；

是否存在设备告警：观察eNB侧是否存在告警；

检查系统是否升级、打补丁等动作；

小区筛查

将小区级的掉话率指标和掉话绝对次数按从高到低的顺序进行排序，优先分析掉话绝对次数多且掉话率高的Top小区；

通常取每天掉话率高于平均指标的Top5小区进行分析，确定掉话的主要原因；

2.2、掉话问题分析规定动作

获取小区级话统掉话率指标及趋势，掉话率趋势至少分析1到2周数据

如果小区的掉话率指标突然偏高，需要核查ENB侧是否存在该小区的相关告警信

息，检测该小区所属ENodeB的相关告警，确认该小区是否存在故障分析CHR数据，获取导致掉话的各种原因的比例，按照比例从高到低的顺序分别针对不同的问题原因进行定位，并针对各TOP原因进行分析处理

判断是否存在OM操作导致的站点复位，重启等导致的掉话，

检测是否有TOP用户存在，如果有，需要对TOP用户的数据进行针对分析

如果无法通过CHR数据定位解决问题，通过抓取该小区ENodeB侧IFTS跟踪

如果无法进行深一步分析在需要使用测试终端进行复现，并抓取UE侧LOG和内部打印信息进行进一步定位

2.3、CHR原因统计

取每天的Top5站点通过InsightSharp对CHR数据进行分析，找到影响每个Top小区掉话率的主要原因：

2.4、TOP用户排查

2.4.1、Top用户的确定

Top用户的判断主要是依据终端接入时上报的TMSI进行判定，华为核心网TMSI分配的机制是对于同一个IMSI用户，TMSI的右起第5位进行随机赋值，即某用户的TMSI中只有*指示的8bits位置发生变化，就是同一个用户，C0 6* 00 05；

TMSI可以通过CHR数据分析获取：

2.4.2、Top用户log分析

●Step1：分析是否存在同频邻小区漏配或者错配导致的掉话；

●Step2：分析是否存在弱覆盖导致的掉话；

●Step3：分析是否由于切换来不及导致的掉话；

●Step4：分析是否导频污染引起的掉话：

●Step5：分析是否存在上行干扰导致的掉话：

●如果掉话原因不是步骤1~5所述的原因，则很有可能是非RF原因导致的掉话，需

要结合IFTS信息进一步定位；

●如果是异常导致的掉话，则需要结合一键式日志、TTI跟踪等信息进行异常定位。

2.4.3、Top用户隔离定位

输入数据

eNB IFTS跟踪

UE TTI跟踪

UE侧路测log

eNB表口log

一键式日志

CHR日志

2.4.5、Top用户掉话分析四步曲

●Step1：标口流程分析谁主动发起释放

?eNB主动发起释放

?eNB主动向核心网发起释放请求，收到核心网下发的释放命令后释

放用户RRCConnRel、并向核心网反馈释放完成

?核心网主动发起释放

?eNB收到核心网下发的释放命令，释放用户RRCConnRel、并向核心

网反馈释放完成

?Step2：通过S1释放请求/命令中的释放原因值隔离掉话原因

?无线侧原因触发释放

?传输原因触发释放

?NAS原因触发释放

?协议原因触发释放

?其他混合原因触发释放

?Step3：CHR分析详细释放原因

?Step4：复现问题抓取IFTS跟踪、UE侧Log，深度定位掉话根因