KPI分析和定位手册.docx
- 文档编号:12205684
- 上传时间:2023-04-17
- 格式:DOCX
- 页数:31
- 大小:904.05KB
KPI分析和定位手册.docx
《KPI分析和定位手册.docx》由会员分享,可在线阅读,更多相关《KPI分析和定位手册.docx(31页珍藏版)》请在冰豆网上搜索。
KPI分析和定位手册
KPI分析和定位手册
项目名称
RAN系统测试项目
文档编号
版本号
作者
版权所有
大唐移动通信设备有限公司
本资料及其包含的所有内容为大唐移动通信设备有限公司(大唐移动)所有,受中国法律及适用之国际公约中有关著作权法律的保护。
未经大唐移动书面授权,任何人不得以任何形式复制、传播、散布、改动或以其它方式使用本资料的部分或全部内容,违者将被依法追究责任。
文档更新记录
日期
更新人
版本
备注
2009-11.05
王西华
V0.0.1
创建文档。
2009-12-07
王西华
V1.0.0
根据评审意见修改文档。
1引言
1.1编写目的
在系统测试和现网维护工作中,可能会涉及到KPI指标的统计和分析。
本文总结了几种实际工作中可以用到的KPI分析方法,并对一些常见的KPI指标统计问题的定位措施进行了整理。
本文不会有太多原理性或者过于深入的分析描述,力图通过几个最常用的工具或者软件,能够初步定位或者解决在KPI统计工作中遇到的一些常见问题。
本文基于V3RAN系统。
1.2预期读者
客服、中试。
1.3参考资料
《无线KPI指标统计模版用户手册》V1.3.1
1.4缩写术语
缩语
原文
中文解释
KPI
KeyPerformanceIndicator
关键性能指标
RAN
RadioAccessNetwork
无线接入网
RNC
RadioNetworkController
无线网络控制器
OMC
Operation&MaintenanceCenter
操作维护中心
OMT
OperationsMaintenanceTerminator
操作维护终端
NEA
NetworkElementAdapter
网元适配
LMT-B
LocalMaintenanceTerminalforNodeB
NodeB本地操作维护终端
LDT
LogicalDebug&DiagnoseTool
逻辑诊断测试工具
BRU
BasicResourceUnit
基本资源单元
ISCP
InterferenceSignalCodePower
干扰信号码功率
CDL
CallDetailLog
呼叫详细日志
IPOA
IPOverATM
GCPA
GlobalControlProcessAssemble
全局处理板
FTP
FileTransferProtocol
文件传输协议
2KPI统计指标分析
现网每天都会输出很多KPI报表,每张报表中又包含了很多的KPI统计指标。
那么,如何分析这些KPI报表中的统计指标,并把分析结果用于日常网络维护和KPI指标提升?
本章节中,一共总结了四种分析方法,可用于对KPI统计指标的分析。
2.1逐级细分统计法
对于现网来讲,比较关注的是整体,比如RNC级甚至全网级的KPI指标。
当发现某天全网某项KPI指标较差时,我们需要快速、准确的去分析定位原因,这时候就需要用到本节的分析方法――“逐级细分统计法”。
比如,某天全网的CS掉话率达到了3%,比平时1%上升了2个百分点,这时可以采用以下的分析步骤去定位问题:
步骤1:
统计RNC级全天KPI报表,找到CS掉话率增加的RNC。
步骤2:
统计该RNC下的小区级全天KPI报表,找到问题小区。
步骤3:
统计该小区全天小时KPI报表,找到有问题的时段。
步骤4:
从OMT中查看小区(或小区所属NodeB)在该时段的告警信息,如果出现故障,立即处理,并重点观察处理后的KPI统计结果。
步骤5:
如果没有告警信息,或者故障处理后KPI仍然没有得到改善,可从RNC中上传该时段的cdl信令文件,分析CS掉话的详细原因。
<注>:
本方法适用于全网或者RNC指标变化较明显的情况,可用于网络建设和网络维护的任何阶段。
2.2Top10小区分析法
现网维护时,从全网或者RNC级的KPI指标可能比较难发现问题(总体指标变化不明显),这时就需要有一种方法可以直接找到问题小区,抓住重点及时的解决,达到迅速稳定甚至提升KPI指标的目的。
这个方法就是现网最常用的“Top10小区分析法”:
步骤1:
统计全网小区级的KPI报表。
步骤2:
在生成的Excel报表中,通过升、降序排列,找到KPI指标最差的Top10小区(根据实际情况,可不限于10个小区)。
步骤3:
统计Top10小区的小时报表。
步骤4:
从OMT中查看Top10小区(或小区所属NodeB)在该时段的告警信息,如果出现故障,立即处理,并重点观察处理后的KPI统计结果。
步骤5:
如果没有告警信息,或者故障处理后KPI仍然没有得到改善,从RNC中上传该时段的cdl信令文件,分析指标差的具体原因。
<注>:
本方法可作为现网日常维护工作的主要内容,同时它也是短时间内稳定并提升KPI指标的重要手段。
2.3关联分析法
对于某些KPI指标来说,仅靠独立的一个KPI指标比较难发现问题,这时候就需要和其它的KPI指标进行联合分析,这就是“关联分析法”。
目前比较常用的KPI指标关联分析有:
关联1:
ISCP报表中干扰指标对接通率、掉话率的影响;对视频和PS业务误块率的影响;对切换成功率的影响等。
在实际的KPI指标分析过程中,遇到以上KPI指标异常时,可首先分析该小区的ISCP。
比如,在“逐级细分统计法”和“Top10小区分析法”分析中,可分别于“步骤4”告警分析前,先分析该小区的ISCP,以迅速排查干扰对KPI指标的影响。
分析ISCP报表时,一般遵循的原则有:
✓ISCP最大值小于“-95dBm”,小区基本没有干扰,不用关注。
✓ISCP最大值大于“-95dBm”,但ISCP平均值小于“-95dBm”,小区一般是短暂的瞬时干扰,也可以不用关注。
✓ISCP最大值大于“-95dBm”,ISCP平均值也大于“-95dBm”,这表明小区受到干扰。
ISCP平均值越大,表明干扰越强,且ISCP平均值越接近最大值,表明干扰持续的时间越长。
关联2:
利用BRU占用统计项间的关系筛选故障NodeB和载波。
<注>:
本方法适用于网络建设阶段,也可以作为网络维护阶段的周期性工作内容。
2.4趋势分析法
前面三种KPI分析方法,基本上都是针对一个时间点上的KPI指标进行分析,对于现网维护来说,通过KPI指标的变化趋势去判断和维护无线网络的运行稳定度同样重要。
这里就需要用到“趋势分析法”。
趋势分析法应用:
Ø网元(载波、小区、RNC和全网等)的时间趋势分析,比如小时趋势报表分析,可发现网元在某个时段出现了问题。
Ø通过网元KPI指标的变化趋势,比如每日趋势报表分析,可尽早发现设备变坏的趋势。
Ø统计网络中一直最差的网元,指导优化。
趋势分析方法:
方法一:
收集、记录每日KPI报表中的KPI指标数据,并形成新的KPI数据表(Excel表)。
方法二:
直接使用OMC中的“网元趋势比较”方式输出KPI指标趋势报表。
OMT→【性能】→【视图】→【报表管理】→【手动输出报表】→分析方式选择“网元趋势比较”。
Ø收集了KPI指标的趋势数据后,就可以利用Excel的“图表”功能制作直观的指标趋势分析图了。
例如:
<注>:
本方法同样可作为现网日常维护工作的主要内容。
3OMC的KPI统计问题分析
3.1问题1:
KPI统计报表数据全为“-”
OMC输出的KPI报表,如果所有的指标统计值都为“-”,其原因可能是以下任何一个。
检查问题原因时,原则上也可以按照以下原因的先后顺序去确认。
3.1.1原因1:
OMC中没有创建正确的统计计划
KPI报表数据为“-”,首先确认在OMC中是否有创建正确的统计计划。
ØOMT→【性能】→【视图】→【统计计划管理】:
1、查看统计计划,如果没有KPI报表所需的统计计划,请立即创建。
2、查看统计计划,如果已有统计计划,请检查计划的统计对象、统计分析和统计指标的设置是否正确或者失效。
<措施>:
如果检查出统计计划不正确,请重新创建统计计划。
(正确设置请参考“无线KPI指标统计模版用户手册”)
3.1.2原因2:
RNC中没有正确的统计任务
检查OMC,发现已经创建了正确的统计计划,还需要确认RNC中的计数器统计任务。
如果RNC中没有正确的计数器统计任务,RNC不会上报性能数据文件(pm文件),KPI报表数据为“-”。
检查时使用LDT工具可快速确认需要统计的计数器组是否已经下发到RNC数据表中:
Ø打开LDT并登陆RNC→【数据探针】→查询主GCPA单板→查询数据表“sDevCntrGrp”→查看“usCounterGroup”,是否有你需要激活的计数器组。
例如,激活了R001组计数器,“usCounterGroup”中就会有“1”显示。
Ø另外,查询表“sDevMeasObj”,可查询到该组计数器具体激活的网元对象:
具体的原则如下:
1、如果,表“sDevCntrGrp”中有的计数器组,而表“sDevMeasObj”中没有,则表示该计数器全RNC所有网元对象的统计任务都已被激活。
2、如果表“sDevCntrGrp”和表“sDevMeasObj”中都有该计数器组,则说明只有部分网元激活了该计数器任务,激活的网元需要查看“aucMeasObjMOC”的值。
比如,
“027000000”――第1、2个,代表RNC的ID。
“027000000”――第3、4个,代表NodeB的ID。
“027000000”――第5、6个,代表Cell的ID。
“027000000”――第7个,代表Carrier的ID。
每一个十进制数都是一个8位二进制数,其中RNC、NodeB和Cell必须两个十进制数转换成二进制数相加才是对应网元的ID值。
如“027431038620620”,其中“43103”表示NodeB的ID;“43”的二进制是“00101011”,“103”的二进制是“01100111”;则ID为“0010101101100111”,再换算成十进制就是“11111”,表示该NodeB的ID是“11111”。
<措施>:
如果检查出OMC中统计计划已经创建,但RNC中没有对应的计数器组被激活,请及时提取jboss里的“pm.log”日志传给OMC技术支持分析,确认OMC的任务模块是否存在问题。
提取“pm.log”的方法:
FTP登陆jboss所在服务器IP,从路径“/home/v3test/datangmobile/jboss/jboss-cm/server/default/log/”中上传pm.log日志。
3.1.3原因3:
RNC性能数据(pm文件)没有被解析
OMC中的统计计划和RNC中的统计任务均正常,RNC上传给OMC的性能数据(pm文件)正常,但解析pm文件的newPC服务器(OMC性能文件入库模块)没有安装或者故障,KPI报表数据同样会是“-”。
检查newPC是否正常的一个简单方法:
ØFTP登陆OMC所在服务器IP,检查路径“/home/omcrftp/PM/”下,是否有pm打头的“*.zip”压缩文件长期(10分钟)遗留。
本路径是RNC上传pm文件给newPC解析的第一现场,newPC周期检查该目录,发现pm压缩文件,即解压该文件存放到其它路径,同时会删除该pm压缩文件。
因此,如果该路径下有pm压缩文件长期遗留,多数情况都是newPC服务器异常造成的。
pm文件的命名规则,比如“pm_0015_20091110_0945.zip”
“0015”――十六进制数,表示RNC的ID:
RNC21。
“20091110_0945”――表示pm文件记录数据的开始时间。
<措施>:
联系OMC技术支持,检查newPC的状态。
3.1.4原因4:
pm文件解析失败
RNC上传OMC的pm压缩文件从“/home/omcrftp/PM/”路径被newPC解压缩后,会被newPC放入本地路径“/home/v3test/datangmobile/newpc/PM/”中等待newPC的解析,newPC正常解析pm数据文件后才能把数据放入OMC数据库。
如果newPC不能正常解析pm文件,本路径下就会堆积大量的pm文件,或者大量带有“.bad”后缀的pm文件。
如果该路径下看到大量目标RNC的pm文件,证明数据没有入库,KPI报表中数据为“-”。
<措施>:
及时提取newPC里的“PerdataFile.log”日志传给OMC技术支持分析,确认OMC的解析入库功能是否存在问题。
提取“PerdataFile.log”的方法:
FTP登陆newPC所在服务器IP,从路径“/home/v3test/datangmobile/newpc/log/”中上传“PerdataFile.log”日志。
3.2问题2:
码资源BRU占用统计项值为“-”
在KPI报表中,有的时候可能会遇到部分KPI指标统计项的值为“-”的情况,比如BRU占用统计项。
BRU占用是载波级的统计项,算法由两部分组成,一部分是RNC上报的计数器,一部分是NodeB上报的计数器。
算法中任何一个计数器的值为“-”,整个统计项的值为“-”(这同时也是其它统计项的统计原则)。
因此,BRU占用统计项的值为“-”时,可以从以下几个原因去分析。
3.2.1原因1:
小区未激活
检查目标小区的状态,如果未激活,小区各载波的BRU占用计数器值为“-”,会使整个统计项的值为“-”。
<措施>:
激活小区。
3.2.2原因2:
NodeB性能统计上报开关关闭
检查目标NodeB的性能统计上报开关状态,如果处于关闭“off”状态,NodeB不会上报任何计数器到OMC。
NodeB上报计数器的原则和RNC上报的原则不一样,NodeB不需要预先在OMC中创建计划,只需打开本开关即可让NodeB上报计数器。
因此,如果这个开关处于“off”状态,OMC中HSDPA和HSUPA业务的BRU占用计数器的值就为“-”,那么,整个BRU占用统计项的值也会是“-”。
检查开关状态的方法如下:
ØOMT→【配置】→物理基站→“小区性能统计参数上报开关”→“on”或者“off”。
<措施>:
将“小区性能统计参数上报开关”的状态置为“on”。
3.2.3原因3:
IPOA链路故障
NodeB上报计数器与RNC通过O接口上报pm文件给OMC不一样,NodeB通过IPOA链路上报计数器。
如果IPOA链路故障,NodeB的计数器值同样不会到达OMC,BRU占用统计值也同样为“-”。
检查IPOA链路状态的方法如下:
方法一:
OMT→【配置】→逻辑基站→“NodeB连接状态”→“正常”表示IPOA链路正常;“断连”表示IPOA故障。
方法二:
查看OMT中的告警信息,如果该NodeB的IPOA断连,会出现“IPOA链路故障”告警。
<措施>:
首先,检查该NodeB的E1链路状态,如果处于“断连”状态,IPOA链路也会断连,立即请机房维护人员检查维修E1链路。
如果E1链路正常,而IPOA链路断连,立即报知OMC技术支持。
3.2.4原因4:
NEA故障
OMC解析入库RNC上报的pm文件通过newPC模块,而NodeB上报计数器的解析入库是通过NEA服务器完成的。
如果NEA服务器故障或者NEA和网元的连接故障,NodeB的计数器都不能正常入库,BRU占用统计值为“-”。
NEA故障,IPOA链路必然故障,判断NEA是否故障的方法是:
Ø查看OMT的告警信息,如果NEA出现问题,将会有“NEA服务器停止”、“NEA和NodeB断连”或“NEA和RNC断连”等告警信息上报。
<措施>:
首先根据告警信息的修复建议,修复NEA,使其正常工作。
同时,提取NEA运行日志“nea.log”传给OMC技术支持分析,确认NEA故障的原因。
提取“nea.log”的方法:
FTP登陆NEA所在服务器IP,从路径“/opt/datangmobile/neacommu/log/”中上传“nea.log”日志。
3.3问题3:
接通率指标大于100%
现网中,语音、视频和PS业务的接通率指标有时会出现大于100%的情况,而接通率大于100%多数是由于RAB建立成功率大于100%导致的。
目前已知的RAB成功率大于100%的原因有三种,分别说明如下:
3.3.1原因1:
RAB建立请求和成功分别被统计到不同时段
RAB的建立过程是需要一段时间的,KPI统计时就有可能把“RABAssignmentRequest”和“RABAssignmentResponse”分别统计到上、下两个不同的统计时段里。
那么,在“下”统计时段,因为多了一次“RABAssignmentResponse”,就可能使RAB成功率大于100%。
这种现象在小区级的小时趋势报表中尤其常见,这是报表统计的正常现象,不是设备的问题。
比如下表的数据:
观察KPI报表中上一个时段的RAB请求次数和RAB成功次数,是否成功比请求少的次数正好是下一个时段多出来的RAB成功次数。
比如上图的报表中,29日0点多出的一次RAB成功次数,正好是28日23点减少的一次RAB成功次数。
当然,这只是初步的判断,更加准确的判断还需要提取两个时段的cdl文件分析信令后确认。
cdl信令分析原则:
提取两个时段的“RABAssignmentRequest”和“RABAssignmentResponse”数目,与KPI统计报表中RAB请求次数和RAB成功次数比对,如果次数都吻合,证明确实是本原因造成的。
<措施>:
一旦确认是本原因造成的接通率大于100%,可以视为正常现象。
3.3.2原因2:
RAB建立过程中发生切换
目前我们设备的信令流程在RRC建立完成后就会发切换测量控制,那么在RAB建立过程中,就有可能发生切换。
一旦发生切换,就会出现“RABAssignmentRequest”在源小区,而“RABAssignmentResponse”在目标小区的现象。
这时目标小区的RAB成功次数统计值就可能比请求次数多,从而导致目标小区接通率大于100%。
本现象多出现在小区级的KPI报表中,由于切换多是RNC内的切换,因此RNC级的KPI报表基本不会出现这种现象。
具体的分析步骤:
Ø先初步判断KPI报表中是否有“3.3.1”原因1的现象。
Ø如果不是,立即提取本时段的cdl文件。
Øcdl信令的分析原则是:
首先,筛选出该小区所有没回“RABAssignmentResponse”消息的RAB建立流程;然后,逐个的排查这些流程,如果发现有“RABAssignmentRequest”和“RABAssignmentResponse”分别在不同小区的RAB建立流程,即证明接通率大于100%是由于本原因导致的。
<措施>:
RAB建立过程中发生切换是目前我们设备的正常流程,目前已有CR提出把切换测量控制放到“RABAssignmentResponse”后再发,后续版本如果实现应该就能彻底解决结束这种现象。
3.3.3原因3:
其它原因
KPI报表中如果出现接通率大于100%的情况,经过现场分析,初步确定不是3.3.1和3.3.2两类原因导致的,那么很可能就是由于系统的缺陷导致的,比如KPI算法缺陷,RNC网元缺陷引起的误统计等。
<措施>:
如果现场无法确认接通率指标大于100%的原因时,请立即提取RNC中的cdl和pm文件,并发往OMC技术支持进行分析。
提取cdl和pm文件的方法如下:
✧cdl文件的提取:
LDT登陆目标RNC→【系统】→【文件上传】→“日志类型”选择“cdl日志”→选择“文件查询”,就会看到RNC中保存的cdl文件→选中要上传的cdl文件,单击右键“上传”。
如下图。
上图中,“起始时间”和“结束时间”就是cdl文件记录RNC信令的开始、结束时间。
最下面窗口中的地址“C:
\ProgramFiles\LDT\ftp\cdl\”,即是cdl上传后保存到本地的路径。
✧pm文件的提取:
LDT登陆目标RNC→【系统】→【文件上传】→“日志类型”选择“网元直连性能数据”→选择“文件查询”,就会看到RNC中保存的pm文件→选中要上传的pm文件,单击右键“上传”。
上图中,“起始时间”和“结束时间”就是pm文件记录RNC计数器数据的开始、结束时间。
最下面窗口中地址“C:
\ProgramFiles\LDT\ftp\dlmpmdata\”,即是pm文件上传后保存到本地的路径。
注意:
本处直接从RNC中提取的pm文件,其实和3.1.3节中RNC上传到OMC中的pm文件是相同的,只是命名规则不一样而已。
比如,
这里的“dlm_pm_2045_20091112_2030.zip”对应的就是OMC中的“pm_000c_20091112_2030.zip”。
其中“20091112_2030”代表开始时间,“2045”代表结束时间。
3.4问题4:
掉话率指标大于100%
语音、视频和PS业务掉话率指标大于100%的问题,目前已知的原因同样有三种。
3.4.1原因1:
RAB建立成功和掉话分别被统计到不同时段
掉话次数的统计原则是,计算RAB建立成功后的“RABreleaserequest”和“Iureleaserequest”次数。
因此,同一流程的RAB建立成功和掉话被统计到不同时段的现象比较常见。
而掉话率的算法原则是“掉话次数/RAB成功次数”,一旦凑巧遇到该时段内建立的业务都掉话,且之前时段建立的业务也同样在该时段掉话,那么,该时段的掉话次数就有可能大于RAB成功次数,从而使掉话率大于100%。
这种现象在小区级的小时趋势报表中容易出现。
在RNC级和全网级的报表中,因为RAB成功次数的基数较大,一般很难出现掉话率大于100%的现象,因此一旦出现,就必须重点关注,这种现象很可能预示着是RNC或者小区故障。
遇到这种情况,从KPI报表很难判断出具体的原因,需要分析cdl信令才能确认。
具体的分析步骤如下:
Ø首先,提取该时段的cdl文件。
ØLDT工具解析cdl文件,找到所有的掉话流程,如果有掉话流程的“RABAssignmentResponse”不在本时段,记录UeID。
Ø提取之前一个或者两个时段的cdl文件。
Ø继续分析cdl,根据掉话流程的UeID,找到对应的“RABAssignmentResponse”,即可确认本时段掉话率大于100%的原因。
<注>:
以上步骤在分析语音和视频电话业务的掉话率异常时比较有效,但用于分析PS业务掉话时,由于现网环境中很多用户建立网络连接后,会长时间挂机下载或者上网,“RABAssignmentResponse”和掉话信令间就有可能间隔数小时甚至十多个小时以上的时间。
由于LDT每次只能解析一个cdl文件,因此遇到以上步骤分析PS业务掉话无效时,建议使用专用“cdl”分析工具,同时打开多个cdl文件分析。
<措施>:
本原因引起的掉话率大于100%是正常现象,可以不用理会,搞清楚原因即可。
3.4.2原因2:
切换到目标小区后的掉话
语音、视频和PS业务切换到目标小区,因切换流程没有“RABAssignmentResponse”信令,切换后出现掉话,就可能使掉话次数大于RAB成功次数,从而使掉话率大于100%。
本原因导致的掉话率异常,KPI报表现象和3.4.1图表中的现象基本一致。
分析时采用的方法也和3.4.1一样,只是在
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- KPI 分析 定位 手册
![提示](https://static.bdocx.com/images/bang_tan.gif)