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小区掉话率的主要原因：

编号CHR打点内部

RelCause

中文解释

含义

1UEM_UECNT_REL_AU

DIT_CELLM_RELEASE

小区资源核查

基带板与主控板见小区资源核查不一致导致的用户

释放

2UEM_UECNT_REL_H

O_OUT_X2_REL_BAC

K_FAIL

X2切换目标侧

失败

X2切换过程中，源小区侧没有收到正常释放

UE_CONTEXT_REL消息，原因可能是：

1、PATHSWITCH处理失败（包括以下几种情况：

pathswitch 消息没有发送出去，或者收到pathswitch

failure 或者处理path switch 过程失败）

2、在SN STATUS 尚未处理完毕的情况下，收到重建

请求

3、没有收到切换完成也没有收到重建请求

4、收到重建请求，但是重建过程失败(除了2以外的

情况)

3UEM_UECNT_REL_RB

_RECFG_FAIL

RB重配置失败

1、核心网下发erab mod 流程涉及的空口重配置失

败

2、算法流程涉及的空口重配置失败（包括MIMO，

CQI，DRX，PUCCH资源以及其他）

3、小区内切换涉及的空口重配置失败（TTIbudding

触发，ROHC，MME下发的安全模式修改）

4UEM_UECNT_REL_RR

C_REEST_OTHER_RB_

RESTORE_FAIL

other RB恢复

失败

一般重建完成有5条消息（3条Reestablishment及2

条重建重配置），在最后两条消息处理过程中发送了

重建过程中的SRB/DRB重配置但是没有收到重配置

完成。