KPI数据分析
1 概述
网络性能KPI测试数据处理主要分为两个方面的内容:统计出KPI指标、统计出错误和异常发生的原因。下面将分别就这两方面进行阐述:
2 KPI指标统计
2.1 何为KPI指标
KPI即关键性能参数,主要有如下这些:
呼叫/激活成功率:对应语音业务而言,称呼叫成功率,对于PS业务而言,称激活成功率。
RRC成功率;
RB建立成功率;
掉话率;
切换成功率;
网络时延:包括RRC时延、RB建立时延、MMC呼叫时延、MTC呼叫时延、PS 业务时延、切换时延;
PS吞吐量;
PS ping包时延,ping包成功率;
2.2 KPI指标统计方式
KPI统计有两种方式,可以用黄河的信令分析工具分析,也可以手动通过信令分析。
2.2.1 呼叫/激活成功率
呼叫成功率有两种方式统计:
路测统计:呼叫成功率=呼通次数/总呼叫次数
后台信令统计;呼叫成功率=RRC成功率×ALERTING次数/(2×CM Service Request 次数)
其中:RRC成功率统计方式将在后面介绍,ALERTING次数和CM Service Request次数通过信令统计,如下图所示(CM Service Request次数160次,Alerting次数306次):
激活成功率有两种方式统计:
路测统计:激活成功率=激活次数/总激活次数
后台信令统计;激活成功率=RRC成功率×Active PDP Accept次数/Active PDP Request
次数,如下图所示(Active PDP Accept和Active PDP Request次数分别为253,259):
2.2.2 RRC成功率
RRC成功率是通过后台信令统计的:
RRC成功率=RRCConnectionSetupComplete总次数/(RRCConnectionRequest总次数-RRCConnectionRequest重传次数)
首先通过信令跟踪工具中“信令数据统计”功能得到RRCConnectionRequest和RRCConnectionSetupComplete的总次数,如下图所示(RRCConnectionRequest和RRCConnectionSetupComplete的总次数分别为:270和267):
然后,找出RRCConnectionRequest重传次数,方法如下:
1、过滤,在信令跟踪工具页面点击右键,选择“显示过滤”:
2、在过滤窗口勾选“进行数据过滤”,然后在下拉菜单中选择“消息名称”,“=”,在文字筐填入“rrcconnectionrequest”,点击“或条件”;用同样的方法添加“rrcconnectionsetupcomplete”,如下图所示,最后点确定。
3、通过上个步骤得到过滤后的结果如下:
4、先后双击“时间”和“UE ID”,进行排列,排列过后的样子一般是一行“RRCConnectionRequest”和一行“RRCConnectionSetupComplete”交替排列,如下图:
但是也有连续多行RRConnectionRequest之后才出现一行“RRCConnectionSetupComplete”的情况,这时有可能出现“RRCConnectionRequest”重传,如下图:
这时就要看相邻两行“RRCConnectionRequest”是否对应同样的UE ID,并且相邻两行的时间差是否小于等于2s,如果同时满足上述两个条件,则两次“RRCConnectionRequest”中有1次是重传。
2.2.3 RB建立成功率
RB成功率是通过后台信令统计的:
RB建立成功率=RadioBearerSetupComplete次数/RadioBearerSetup次数
如下图所示(RadioBearerSetup和RadioBearerSetupComplete次数分别为261,256):
2.2.4 掉话率
掉话率=掉话次数/(呼叫次数-未呼通次数)
可以通过路测统计和后台信令统计两种方式。一般采用路测统计比较准确。
2.2.5 切换成功率
切换成功率通过后台信令统计:
切换成功率=“PhysicalChannelReconfigurationComplete”次数/ (“PhysicalChannelReconfiguration”次数+“CellupdateConfirm”次数-回滚成功次数)
其中“PhysicalChannelReconfigurationComplete”,“PhysicalChannelReconfiguration”和“CellupdateConfirm”都可以用上面同样的方法统计到,不再赘述。回滚成功次数统计方法如下:
1、双击“UE ID”排序
2、右键-》“查找”,输入PhysicalChannelReconfigurationfail,如下图:
3、找到PhysicalChannelReconfigurationfail信令的地方,如果这条信令周围信令如下图,则视为回滚成功:
2.2.6 网络时延
2.2.6.1 RRC连接时延
RRC连接时延也是通过后台信令统计出来:
找到同一个用户在同一次RRC连接建立过程中“RRCConnectionRequest”和“RRCConnectionSetupComplete”的时间点
RRC连接时延=“RRCConnectionSetupComplete”的时间-“RRCConnectionRequest”的时间。
如果有大量的RRC连接次数,通过逐次求RRC时延再求平均的方式显然效率很低,可以采用如下方法处理:
1、将信令文件导成excel文件;操作方式:文件->任务导出,如下图:
2、在excel文件中过滤出“RRCConnectionRequest”,并将各条“RRCConnectionRequest”对应的时间和UE ID拷贝到一张excel工作表里;
3、用步骤2同样的方法,过滤出“RRCConnectionSetupComplete”,拷贝到和“RRCConnectionRequest”的同一张工作表里;
4、对得到的工作表,首先按时间排序,然后按UE ID排序;
5、经过以上4步,得到的excel表里面一般是“RRCConnectionRequest”和“RRCConnectionSetupComplete”间隔排列,并且同一UE ID 的信令集中在一起,这时,再通过excel公式,批量求出“RRCConnectionSetupComplete”时间-“RRCConnectionRequest”时间,再对这些时间求均值,得到RRC网络时延均值。Excel公式如下:
2.2.6.2 RB建立时延
RB建立时延也是通过后台信令统计出来:
找到同一个用户在同一次RB建立过程中“RadioBearerSetupComplete”和“RadioBearerSetup”的时间点
RB建立时延=“RadioBearerSetupComplete”的时间-“RadioBearerSetup”的时间
2.2.6.3 MMC呼叫时延
MMC呼叫时延也是通过后台信令统计出来:
找到同一对用户在一次成功呼叫过程中主叫“RRCConnectionRequest”和主叫“Alerting”的时间点
RB建立时延=“Alerting”的时间-“RRCConnectionRequest”的时间
2.2.6.4 MTC呼叫时延
MTC呼叫时延也是通过后台信令统计出来:
找到同一对用户在一次成功呼叫过程中移动用户“RRCConnectionRequest”和“Alerting”的时间点
RB建立时延=“Alerting”的时间-“RRCConnectionRequest”的时间
2.2.6.5 PS激活时延
PS激活时延也是通过后台信令统计出来:
找到同一对用户在一次成功激活过程中用户“RRCConnectionRequest”和“Activate PDP context accept”的时间点
RB建立时延=“Activate PDP context accept”的时间-“RRCConnectionRequest”的时间
2.2.7 PS吞吐量
PS吞吐量一般是通过路测软件Du Meter统计出来,一般包括平均吞吐量,最大吞吐量指标,如下图所示:
2.2.8PS ping包时延、成功率
PS ping包时延和ping包成功率是通过MS DOS窗口统计得到,如下图所示(最大时延为47ms,平均时延为9ms,丢包率0%):
3 异常情况统计
3.1 异常情况类型
异常情况主要指呼叫/激活失败,业务保持过程中掉话,网络时延过大等等情况,发生异常情况时,需要结合当时的信令,打印,路测数据以及LMT采集的性能指标等进行分析定位,或者需要重新复现该异常,这是一个比较繁琐的过程,我们这里说的异常情况统计,主要是对一项测试里面出现的典型异常情况的数量进行一个统计,不设计异常分析、定位。
各种KPI测试中,常见的异常情况如下:
短呼测试中:rrc接纳拒绝、业务接纳拒绝、RB建立超时等
移动长保过程中:切换超时掉话、小区更新掉话、UCIU Error导致掉话,上行RL失步后未恢复导致掉话等
3.2 异常情况统计
对异常情况的统计也是以后台信令为处理对象,找到掉话的地方,确定掉话的原因。
为了简化处理方式,可以利用掉话的原因信元来统计异常情况,方法如下:
1、在信令中搜索:“IuReleaseRequest”这条信令,这条信令一般标识出我们要找的掉
话时间点,如下图:
2、找到这条信令后,在右边的解码窗口里面找到“Cause”信元里面有一个
“non_Standard=数字”的行,记下这个数字,如下图(图中non_Standard=173):
3、根据第2步得到的数据查异常对应表,找出错误原因:
查如下的表:
4、搜索下一条“IuReleaseRequest”,记录下异常原因,直到处理完所有的
“IuReleaseRequest”信令。
5、输出异常类型统计表,即各种异常类型发生的次数。