KPI数据分析.docx

KPI数据分析.docx

《KPI数据分析.docx》由会员分享，可在线阅读，更多相关《KPI数据分析.docx（14页珍藏版）》请在冰点文库上搜索。

KPI数据分析

1概述

网络性能KPI测试数据处理主要分为两个方面的内容：

统计出KPI指标、统计出错误和异常发生的原因。

下面将分别就这两方面进行阐述：

2KPI指标统计

2.1何为KPI指标

KPI即关键性能参数，主要有如下这些：

Ø呼叫/激活成功率：

对应语音业务而言，称呼叫成功率，对于PS业务而言，称激活成功率。

ØRRC成功率；

ØRB建立成功率；

Ø掉话率；

Ø切换成功率；

Ø网络时延：

包括RRC时延、RB建立时延、MMC呼叫时延、MTC呼叫时延、PS业务时延、切换时延；

ØPS吞吐量；

ØPSping包时延，ping包成功率；

2.2KPI指标统计方式

KPI统计有两种方式，可以用黄河的信令分析工具

分析，也可以手动通过信令分析。

2.2.1呼叫/激活成功率

呼叫成功率有两种方式统计：

路测统计：

呼叫成功率＝呼通次数/总呼叫次数

后台信令统计；呼叫成功率＝RRC成功率×ALERTING次数/（2×CMServiceRequest次数）

其中：

RRC成功率统计方式将在后面介绍，ALERTING次数和CMServiceRequest次数通过信令统计，如下图所示（CMServiceRequest次数160次，Alerting次数306次）：

激活成功率有两种方式统计：

路测统计：

激活成功率＝激活次数/总激活次数

后台信令统计；激活成功率＝RRC成功率×ActivePDPAccept次数/ActivePDPRequest次数，如下图所示（ActivePDPAccept和ActivePDPRequest次数分别为253，259）：

2.2.2RRC成功率

RRC成功率是通过后台信令统计的：

RRC成功率＝RRCConnectionSetupComplete总次数/（RRCConnectionRequest总次数－RRCConnectionRequest重传次数）

首先通过信令跟踪工具中“信令数据统计”功能得到RRCConnectionRequest和RRCConnectionSetupComplete的总次数，如下图所示（RRCConnectionRequest和RRCConnectionSetupComplete的总次数分别为：

270和267）：

然后，找出RRCConnectionRequest重传次数，方法如下：

1、过滤，在信令跟踪工具页面点击右键，选择“显示过滤”：

2、在过滤窗口勾选“进行数据过滤”，然后在下拉菜单中选择“消息名称”，“＝”，在文字筐填入“rrcconnectionrequest”,点击“或条件”；用同样的方法添加“rrcconnectionsetupcomplete”,如下图所示，最后点确定。

3、通过上个步骤得到过滤后的结果如下：

4、先后双击“时间”和“UEID”，进行排列，排列过后的样子一般是一行“RRCConnectionRequest”和一行“RRCConnectionSetupComplete”交替排列，如下图：

但是也有连续多行RRConnectionRequest之后才出现一行“RRCConnectionSetupComplete”的情况，这时有可能出现“RRCConnectionRequest”重传，如下图：

这时就要看相邻两行“RRCConnectionRequest”是否对应同样的UEID，并且相邻两行的时间差是否小于等于2s，如果同时满足上述两个条件，则两次“RRCConnectionRequest”中有1次是重传。

2.2.3RB建立成功率

RB成功率是通过后台信令统计的：

RB建立成功率＝RadioBearerSetupComplete次数/RadioBearerSetup次数

如下图所示（RadioBearerSetup和RadioBearerSetupComplete次数分别为261，256）：

2.2.4掉话率

掉话率＝掉话次数/（呼叫次数－未呼通次数）

可以通过路测统计和后台信令统计两种方式。

一般采用路测统计比较准确。

2.2.5切换成功率

切换成功率通过后台信令统计：

切换成功率＝“PhysicalChannelReconfigurationComplete”次数/（“PhysicalChannelReconfiguration”次数＋“CellupdateConfirm”次数－回滚成功次数）

其中“PhysicalChannelReconfigurationComplete”，“PhysicalChannelReconfiguration”和“CellupdateConfirm”都可以用上面同样的方法统计到，不再赘述。

回滚成功次数统计方法如下：

1、双击“UEID”排序

2、右键－》“查找”，输入PhysicalChannelReconfigurationfail，如下图：

3、找到PhysicalChannelReconfigurationfail信令的地方，如果这条信令周围信令如下图，则视为回滚成功：

2.2.6网络时延

2.2.6.1RRC连接时延

RRC连接时延也是通过后台信令统计出来：

找到同一个用户在同一次RRC连接建立过程中“RRCConnectionRequest”和“RRCConnectionSetupComplete”的时间点

RRC连接时延＝“RRCConnectionSetupComplete”的时间－“RRCConnectionRequest”的时间。

如果有大量的RRC连接次数，通过逐次求RRC时延再求平均的方式显然效率很低，可以采用如下方法处理：

1、将信令文件导成excel文件；操作方式：

文件－>任务导出，如下图：

2、在excel文件中过滤出“RRCConnectionRequest”，并将各条“RRCConnectionRequest”对应的时间和UEID拷贝到一张excel工作表里；

3、用步骤2同样的方法，过滤出“RRCConnectionSetupComplete”，拷贝到和“RRCConnectionRequest”的同一张工作表里；

4、对得到的工作表，首先按时间排序，然后按UEID排序；

5、经过以上4步，得到的excel表里面一般是“RRCConnectionRequest”和“RRCConnectionSetupComplete”间隔排列，并且同一UEID的信令集中在一起，这时，再通过excel公式，批量求出“RRCConnectionSetupComplete”时间－“RRCConnectionRequest”时间，再对这些时间求均值，得到RRC网络时延均值。

Excel公式如下：

2.2.6.2RB建立时延

RB建立时延也是通过后台信令统计出来：

找到同一个用户在同一次RB建立过程中“RadioBearerSetupComplete”和“RadioBearerSetup”的时间点

RB建立时延＝“RadioBearerSetupComplete”的时间－“RadioBearerSetup”的时间

2.2.6.3MMC呼叫时延

MMC呼叫时延也是通过后台信令统计出来：

找到同一对用户在一次成功呼叫过程中主叫“RRCConnectionRequest”和主叫“Alerting”的时间点

RB建立时延＝“Alerting”的时间－“RRCConnectionRequest”的时间

2.2.6.4MTC呼叫时延

MTC呼叫时延也是通过后台信令统计出来：

找到同一对用户在一次成功呼叫过程中移动用户“RRCConnectionRequest”和“Alerting”的时间点

RB建立时延＝“Alerting”的时间－“RRCConnectionRequest”的时间

2.2.6.5PS激活时延

PS激活时延也是通过后台信令统计出来：

找到同一对用户在一次成功激活过程中用户“RRCConnectionRequest”和“ActivatePDPcontextaccept”的时间点

RB建立时延＝“ActivatePDPcontextaccept”的时间－“RRCConnectionRequest”的时间

2.2.7PS吞吐量

PS吞吐量一般是通过路测软件DuMeter统计出来，一般包括平均吞吐量，最大吞吐量指标，如下图所示：

2.2.8PSping包时延、成功率

PSping包时延和ping包成功率是通过MSDOS窗口统计得到，如下图所示（最大时延为47ms，平均时延为9ms，丢包率0％）：

3异常情况统计

3.1异常情况类型

异常情况主要指呼叫/激活失败，业务保持过程中掉话，网络时延过大等等情况，发生异常情况时，需要结合当时的信令，打印，路测数据以及LMT采集的性能指标等进行分析定位，或者需要重新复现该异常，这是一个比较繁琐的过程，我们这里说的异常情况统计，主要是对一项测试里面出现的典型异常情况的数量进行一个统计，不设计异常分析、定位。

各种KPI测试中，常见的异常情况如下：

短呼测试中：

rrc接纳拒绝、业务接纳拒绝、RB建立超时等

移动长保过程中：

切换超时掉话、小区更新掉话、UCIUError导致掉话，上行RL失步后未恢复导致掉话等

3.2异常情况统计

对异常情况的统计也是以后台信令为处理对象，找到掉话的地方，确定掉话的原因。

为了简化处理方式，可以利用掉话的原因信元来统计异常情况，方法如下：

1、在信令中搜索：

“IuReleaseRequest”这条信令，这条信令一般标识出我们要找的掉话时间点，如下图：

2、找到这条信令后，在右边的解码窗口里面找到“Cause”信元里面有一个“non_Standard=数字”的行，记下这个数字，如下图（图中non_Standard=173）：

3、根据第2步得到的数据查异常对应表，找出错误原因：

查如下的表：

4、搜索下一条“IuReleaseRequest”，记录下异常原因，直到处理完所有的“IuReleaseRequest”信令。

5、输出异常类型统计表，即各种异常类型发生的次数。