kPI分析指导书

1、资料分享KPI分析手册项目名称RAN系统测试项目文档编号版 本 号作 者版权所有大唐移动通信设备有限公司 本资料及其包含的所有内容为大唐移动通信设备有限公司(大唐移动)所有,受中国法律及适用之国际公约中有关著作权法律的保护。未经大唐移动书面授权，任何人不得以任何形式复制、传播、散布、改动或以其它方式使用本资料的部分或全部内容，违者将被依法追究责任。文档更新记录日期更新人版本备注2009-11.05王西华V1.0.0创建文档。目 录1 引言. 31.1 编写目的. 31.2 预期读者. 31.3 参考资料. 31.4 缩写术语. 32 KPI统计指标分析. 42.1 逐级细分统计法. 42.2

2、TOP10小区分析法. 42.3 关联分析法. 42.4 趋势分析法. 53 KPI统计问题分析. 73.1 问题1：KPI统计报表数据全为“”. 73.1.1 原因1：OMC中没有创建正确的统计计划. 73.1.2 原因2：RNC中没有正确的统计任务. 73.1.3 原因3：RNC性能数据（pm文件）没有被解析. 93.1.4 原因4： pm文件解析失败. 93.2 问题2：码资源BRU占用统计项值为“”. 103.2.1 原因1：小区未激活. 103.2.2 原因2：NodeB性能统计上报开关关闭. 103.2.3 原因3：IPOA链路故障. 113.2.4 原因4：NEA故障. 113.

3、3 问题3：接通率指标大于100. 123.3.1 原因1：RAB建立请求和成功分别被统计到不同时段. 123.3.2 原因2：RAB建立过程中发生切换. 123.3.3 原因3：其它原因. 133.4 问题4：掉话率指标大于100. 143.4.1 原因1：RAB建立成功和掉话分别被统计到不同时段. 143.4.2 原因2：切换到目标小区后的掉话. 153.4.3 原因3：其它原因. 153.5 问题5：统计指标的其它异常. 163.6 问题6：获取计数器定义和统计指标算法. 163.6.1 方法一：从OMT中查询. 163.6.2 方法二：从“无线KPI指标统计模版用户手册”中查询. 17

4、附录1：LDT查看RNC的统计任务. 18附录2：LDT提取RNC中的cdl和pm文件. 19附录3：FTP提取jboss日志“pm.log”. 20附录4：FTP提取newPC日志“PerdataFile.log”. 20附录5：FTP提取NEA日志“NodebMsg.log”. 21附录6：FTP提取OMC中的pm文件. 21附录7：检查NodeB性能统计上报开关的状态. 211 引言1.1 编写目的在系统测试和现网维护的过程中，会涉及到KPI指标的统计，在这个过程中，可能会遇到一些问题。本文将对一些常见KPI指标统计问题的分析方法进行描述，并遵循逐步深入的原则，依次对创建KPI统计计划，

5、性能数据上报、解析、入库，KPI报表输出，KPI指标分析等各阶段的常见问题进行分析。本文基于V3 RAN系统。1.2 预期读者现网客服，中试。1.3 参考资料 无线KPI指标统计模版用户手册V 缩写术语无2 KPI统计指标分析现网每天都会输出很多KPI报表，每张报表中又包含了很多的KPI统计指标。那么，如何分析这些KPI报表中的统计指标，并把分析结果用于日常网络维护和KPI指标提升？本章节中，共总结了四种分析方法，可用于对KPI统计指标的分析。2.1 逐级细分统计法对于现网来讲，比较关注的是整体，比如RNC级甚至全网级的KPI指标。当发现某天全网某项KPI指标较差时，我们需要快

6、速、准确的去分析定位原因，这时候就需要用到本节的分析方法“逐级细分统计法”。比如，某天全网的CS掉话率达到了3，比平时1上升了2个百分点，这时可以采用以下的分析步骤去定位问题： 统计RNC级全天KPI报表，找到CS掉话率增加的RNC； 统计该RNC下的小区级全天KPI报表，找到问题小区； 统计该小区全天小时KPI报表，找到有问题的时段； 从RNC中上传该时段的cdl信令文件，分析CS掉话的详细原因。：本方法适用于全网或者RNC指标变化较明显的情况，可用于网络建设和网络维护的任何阶段。2.2 TOP10小区分析法现网维护时，从全网或者RNC级的KPI指标可能比较难发现问题（指标变化不明显），这时

7、就需要有一种方法可以直接找到问题小区，抓住重点及时的解决，达到稳定甚至提升KPI指标的目的。这个方法就是现网最常用的“TOP10小区分析法”： 统计全网小区级的KPI报表； 在生成的Excel报表中，通过升、降序排列，找到各KPI指标最差的TOP10小区； 统计TOP10小区的小时报表； 从RNC中上传该时段的cdl信令文件，分析指标差的具体原因。：本方法可作为现网日常维护工作的主要内容，同时它也是短时间内稳定并提升KPI指标的重要手段。2.3 关联分析法对于某些KPI指标来说，仅靠独立的一个KPI指标比较难发现问题，这时候就需要和其它的KPI指标进行联合分析，这就是“关联分析法”。目前比较常

8、用的KPI指标关联分析有： ISCP报表中干扰指标对接通率、掉话率的影响； ISCP报表中干扰指标对视频和PS业务误块率的影响； ISCP报表中干扰指标对切换成功率的影响； 利用BRU占用统计项间的关系筛选故障NodeB和载波。：本方法适用于网络建设阶段，也可以作为网络维护阶段的周期性工作内容。2.4 趋势分析法前面三种KPI分析方法，基本上都是针对一个时间点上的KPI指标进行分析，对于现网维护来说，通过KPI指标的变化趋势去判断和维护无线网络的运行稳定度同样重要。这里就需要用到“趋势分析法”： 方法一：收集、记录每日KPI报表中的KPI指标并形成新的数据表（Excel表）。 方法二：直接使用

9、OMC中的“网元趋势比较”方式输出KPI指标趋势报表。OMT【性能】【视图】【报表管理】【手动输出报表】分析方式选择“网元趋势比较”。 收集了KPI指标的趋势数据后，就可以利用Excel的“图表”功能制作直观的指标趋势分析图了。例如：本方法同样可作为现网日常维护工作的主要内容。3 KPI统计问题分析3.1 问题1：KPI统计报表数据全为“”OMC输出的KPI报表，如果所有的指标统计值都为“”，其原因可能是以下任何一个。检查问题原因时，原则上也可以按照下面的顺序去确认。3.1.1 原因1：OMC中没有创建正确的统计计划KPI报表数据为“”，首先确认在OMC中是否有创建正确的统计计划。 OMT【性

10、能】【视图】【统计计划管理】：1、 查看统计计划，如果没有KPI报表所需的统计计划，请立即创建。2、 查看统计计划，如果已有统计计划，请检查计划的统计对象、统计分析和统计指标的设置是否正确或者失效。：如果检查出统计计划不正确，请重新创建统计计划。（正确设置请参考“无线KPI指标统计模版用户手册”）3.1.2 原因2：RNC中没有正确的统计任务检查OMC，已经创建正确的统计计划。还需要检查RNC中的计数器统计任务。如果RNC中没有正确的计数器统计任务，RNC不会上报性能数据（pm文件），KPI报表数据为“”。检查时使用LDT工具可快速确认需要统计的计数器组是否已经下发到RNC数据表中： 打开LD

11、T并登陆RNC【数据探针】查询主GCPA单板查询数据表“sDevCntrGrp” 查看“usCounterGroup”，是否有你需要激活的计数器组。例如，激活了R001组计数器，“usCounterGroup”中就会有“1”显示。 另外，查询表“sDevCntrGrp”，可查询到该组计数器具体激活的网元对象： 具体的原则如下：1、 如果，表“sDevCntrGrp”中有的计数器组，而表“sDevCntrGrp”中没有，则表示该计数器全RNC所有网元对象的统计任务都已被激活。2、 如果表“sDevCntrGrp”和表“sDevCntrGrp”中都有该计数器组，则说明只有部分网元激活了该计数器任务

12、，激活的网元需要查看“aucMeasObjMOC”的值。比如，“0 27 0 0 0 0 0 0”第1、2个，代表RNC的ID。“0 27 0 0 0 0 0 0”第3、4个，代表NodeB的ID。“0 27 0 0 0 0 0 0”第5、6个，代表Cell的ID。“0 27 0 0 0 0 0 0”第7个，代表Carrier的ID。每一个十进制数都是一个8位二进制数，其中RNC、NodeB和Cell必须两个十进制数转换成二进制数相加才是对应网元的ID值。如“0 27 43 103 86 206 2 0”，其中“43 103”表示NodeB的ID；“43”的二进制是“00101011”，“10

13、3”的二进制是“01100111”；则ID为“00101011 01100111”，再换算成十进制就是“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文件）没

14、有被解析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

15、服务器异常造成的。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不能

16、正常解析入库，本路径下会堆积大量的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指标

17、统计项的值为“”的情况，比如BRU占用统计项。BRU占用是载波级的统计项，算法由两部分组成，一部分是RNC上报的计数器，一部分是NodeB上报的计数器。算法中任何一个计数器的值为“”，整个统计项的值为“”（这同时也是其它统计项的统计原则）。因此，BRU占用统计项的值为“”时，可以从以下几个原因去分析。3.2.1 原因1：小区未激活检查目标小区的状态，如果未激活，小区各载波的BRU占用计数器值为“”，会使整个统计项的值为“”。：激活小区。3.2.2 原因2：NodeB性能统计上报开关关闭检查目标NodeB的性能统计上报开关状态，如果处于关闭“off”状态，NodeB不会上报任何计数器到OMC。N

18、odeB上报计数器的原则和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链路故障，No

19、deB的计数器值同样不会到达OMC，BRU占用统计值也同样为“”。检查IPOA链路状态的方法如下： OMT【配置】逻辑基站“NodeB连接状态”“正常”表示IPOA链路正常；“断连”表示IPOA故障。：首先，检查该NodeB的E1链路状态，如果处于“断连”状态，IPOA链路也会断连，立即请机房维护人员检查维修E1链路。如果E1链路正常，而IPOA链路断连，立即报知OMC技术支持。3.2.4 原因4：NEA故障OMC解析入库RNC上报的pm文件通过newPC模块，而NodeB上报计数器的解析入库是通过NEA服务器完成的。如果NEA故障，NodeB的计数器不能正常入库，BRU占用统计值为“”。NE

20、A是否故障，一般需要OMC专业人士才可以直接判断，但我们可以通过以下的方法预先判断，通过排除法确认： 在OMC中单独统计“R062_014”(HSDPA业务BRU占用数，NodeB计数器之一)的值，确认是否值为“”。如果值为“”，可进行下一步。 分别查找以上“2.2.2：原因2”和“2.2.3：原因3”，如果都没有问题，就可以暂时把怀疑对象对准NEA。：及时提取NEA里的“NodebMsg.log”日志传给OMC技术支持分析，确认NEA是否故障。提取“NodebMsg.log”的方法：FTP登陆NEA所在服务器IP，从路径“/opt/datangmobile/neacommu/log/”中上传

21、“NodebMsg.log”日志。3.3 问题3：接通率指标大于100现网中，语音、视频和PS业务的接通率指标有时会出现大于100的情况，而接通率大于100多数是由于RAB建立成功率大于100导致的。目前已知的RAB成功率大于100的原因有三种，分别说明如下：3.3.1 原因1：RAB建立请求和成功分别被统计到不同时段RAB的建立过程是需要一段时间的，KPI统计时就有可能把“RAB Assignment Request”和“RAB Assignment Response”分别统计到上、下两个不同的统计时段里。那么，在“下”统计时段，因为多了一次“RAB Assignment Response”

22、，就可能使RAB成功率大于100。这种现象在小区级的小时趋势报表中尤其常见，这是报表统计的正常现象，不是设备的问题。比如下表的数据：观察KPI报表中上一个时段的RAB请求次数和RAB成功次数，是否成功比请求少的次数正好是下一个时段多出来的RAB成功次数。比如上图的报表中，29日0点多出的一次RAB成功次数，正好是28日23点减少的一次RAB成功次数。当然，这只是初步的判断，更加准确的判断还需要提取两个时段的cdl文件分析信令后确认。cdl信令分析原则：提取两个时段的“RAB Assignment Request”和“RAB Assignment Response”数目，与KPI统计报表中RAB

23、请求次数和RAB成功次数比对，如果次数都吻合，证明确实是本原因造成的。：一旦确认是本原因造成的接通率大于100，可以视为正常现象。3.3.2 原因2：RAB建立过程中发生切换目前我们设备的信令流程在RRC建立完成后就会发切换测量控制，那么在RAB建立过程中，就有可能发生切换。一旦发生切换，就会出现“RAB Assignment Request”在源小区，而“RAB Assignment Response”在目标小区的现象。这时目标小区的RAB成功次数统计值就可能比请求次数多，从而导致目标小区接通率大于100。本现象多出现在小区级的KPI报表中，由于切换多是RNC内的切换，因此RNC级的KPI报

24、表基本不会出现这种现象。具体的分析步骤： 先初步判断KPI报表中是否有“3.3.1”原因1的现象。 如果不是，立即提取本时段的cdl文件。 cdl信令的分析原则是：首先，筛选出该小区所有没回“RAB Assignment Response”消息的RAB建立流程；然后，逐个的排查这些流程，如果发现有“RAB Assignment Request”和“RAB Assignment Response”分别在不同小区的RAB建立流程，即证明接通率大于100是由于本原因导致的。：RAB建立过程中发生切换是目前我们设备的正常流程，目前已有CR提出把切换测量控制放到“RAB Assignment Respo

25、nse”后再发，后续版本如果实现应该就会彻底解决结束这种现象。3.3.3 原因3：其它原因KPI报表中如果出现接通率大于100的情况，经过现场分析，初步确定不是3.3.1和3.3.2两类原因导致的，那么很可能就是由于系统的缺陷导致的，比如KPI算法缺陷，RNC网元缺陷引起的误统计等。：如果现场无法确认接通率指标大于100的原因时，请立即提取RNC中的cdl和pm文件，并发往KPI技术支持进行分析。提取cdl和pm文件的方法如下： cdl文件的提取：LDT登陆目标RNC【系统】【文件上传】“日志类型”选择“cdl日志”选择“文件查询”，就会看到RNC中保存的cdl文件选中要上传的cdl文件，单击

26、右键“上传”。如下图。上图中，“起始时间”和“结束时间”就是cdl文件记录RNC信令的开始、结束时间。最下面窗口中的地址“C:Program FilesLDTftpcdl”，即是cdl上传后保存到本地的路径。 pm文件的提取：LDT登陆目标RNC【系统】【文件上传】“日志类型”选择“网元直连性能数据”选择“文件查询”，就会看到RNC中保存的pm文件选中要上传的pm文件，单击右键“上传”。上图中，“起始时间”和“结束时间”就是pm文件记录RNC计数器数据的开始、结束时间。最下面窗口中地址“C:Program FilesLDTftpdlmpmdata”，即是pm文件上传后保存到本地的路径。注意：本

27、处直接从RNC中提取的pm文件，其实和3.1.3节中RNC上传到OMC中的pm文件是相同的，只是命名规则不一样而已。比如，这里的“dlm_pm_2045_20091112_2030.zip”对应的就是OMC中的“pm_000c_20091112_2030”。其中“20091112_2030”代表开始时间，“2045”代表结束时间。3.4 问题4：掉话率指标大于100语音、视频和PS业务掉话率指标大于100的问题，目前已知的原因同样有三种。3.4.1 原因1：RAB建立成功和掉话分别被统计到不同时段掉话次数的统计原则是，计算RAB建立成功后的“RAB release request”和“Iu r

28、elease request”次数。因此，同一流程的RAB建立成功和掉话被统计到不同时段的现象比较常见。而掉话率的算法原则是“掉话次数/RAB成功次数”，一旦凑巧遇到该时段内建立的业务都掉话，且之前时段建立的业务也同样在该时段掉话，那么，该时段的电话次数就有可能大于RAB成功次数，从而使掉话率大于100。这种现象在小区级的小时趋势报表中容易出现。在RNC级和全网级的报表中，因为RAB成功次数的基数较大，一般很难出现掉话率大于100的现象，因此一旦出现，就必须重点关注，这种现象很可能预示着是RNC或者小区故障。 遇到这种情况，从KPI报表很难判断出具体的原因，需要分析cdl信令才能确认。具体的分

29、析步骤如下： 首先，提取该时段的cdl文件。 LDT工具解析cdl文件，找到所有的掉话流程，如果有掉话流程的“RAB Assignment Response”不在本时段，记录UEID。 提取之前一个或者两个时段的cdl文件。 继续分析cdl，根据掉话流程的UEID，找到对应的“RAB Assignment Response”，即可确认本时段掉话率大于100的原因。：以上步骤在分析语音和视频电话业务的掉话率异常时比较有效，但用于分析PS业务掉话时，由于现网环境中很多用户建立网络连接后，会长时间挂机下载或者上网，“RAB Assignment Response”和掉话信令间就有可能间隔数小时甚至十

30、多个小时以上的时间。由于LDT每次只能解析一个cdl文件，因此遇到以上步骤分析PS业务掉话无效时，建议使用专用“cdl”分析工具，同时打开多个cdl文件分析。：本原因引起的掉话率大于100是正常现象，可以不用理会，搞清楚原因即可。3.4.2 原因2：切换到目标小区后的掉话语音、视频和PS业务切换到目标小区，因切换流程没有“RAB Assignment Response”信令，切换后出现掉话，就可能使掉话次数大于RAB成功次数，从而使掉话率大于100。本原因导致的掉话率异常，KPI报表现象和3.4.1图表中的现象基本一致。分析时采用的方法也和3.4.1一样，只是在分析cdl信令时，寻找和掉话信令

31、同一流程的信令将是切换信令“Physical Channel Reconfiguration”或者“Relocation Request”。：本原因引起的掉话率大于100，从流程上讲是正常的，也不是网元设备问题，主要原因在于移动在做掉话率算法时，没有考虑到这种情况。后续将建议移动修改掉话率算法定义，彻底解决本原因引起的掉话率统计异常。3.4.3 原因3：其它原因出现掉话率大于100的异常现象，而现场暂时无法确定具体原因时，请按照3.3.3的提取相关log，发给KPI统计技术支持分析定位原因。3.5 问题5：统计指标的其它异常除了接通率和掉话率指标大于100这两类异常外，现网中我们还可能会在KP

32、I报表中遇到其它的一些统计指标异常情况。比如，指标值异常增大、出现负值等等。当遇到这类情况，而一时又不能确定原因时，请及时采集log日志，发给KPI统计技术支持分析原因。：提取指标异常时段的cdl文件和pm文件（见3.3.3）。另外，针对不同类型的指标，还需要提取相应OMC的log：小区级报表中的指标异常，提取“jboss”中的“pm.log”；载波级报表中的指标异常，除了提取“jboss”中的“pm.log”，还需要提取NEA中的“NodebMsg.log”。（见附录）3.6 问题6：获取计数器定义和统计指标算法在实际的KPI统计工作中，我们经常会遇到这种情况，想了解一个计数器的详细定义或者

33、想知道一个统计指标的具体算法。那么，如何比较快捷的获取我们想要的信息呢？这里将提供两种快速获取计数器和统计指标信息的方法。3.6.1 方法一：从OMT中查询如果你正好在一台OMC操作终端OMT前，那么可以按照下面的步骤去获取。 计数器查询：OMT【性能】【视图】【测量指标管理】点击左边窗口的“计数器”标签，这里可以查询到系统所有计数器的信息。 统计指标查询：OMT【性能】【视图】【测量指标管理】点击左边窗口的“统计项”标签打开“业务状况”、“业务模型”、“信令模型”和“干扰指标”四个目录，可以看到所有预定义统计项的信息，包括具体的定义和算法等。3.6.2 方法二：从“无线KPI指标统计模版用户

34、手册”中查询使用“方法一”有一个缺点，如果你对计数器和统计指标存放位置不熟悉的话，可能不太容易在OMT中找到想要的信息，使得“快速”的方法变得不再快速。这里，提供另外一种直接从文档中获取计数器和统计指标信息的方法。 “TDR3000性能计数器设计报告”研发文档，可查询RNC的所有计数器信息。 “TDR3000性能计数器-OMC”研发文档，可查询NodeB的计数器以及OMC扩展计数器的信息。 “无线KPI指标统计模版用户手册”商用网KPI模板的用户手册，可查询所有预定义统计指标和统计指标中使用到的计数器的信息。：第1和第2两个文档都是研发文档，可能不太容易获取到，且都只能查看计数器的信息。重点推

35、荐使用“无线KPI指标统计模版用户手册”，可查询统计指标和计数器的信息，且获取方便（商用版本发布时都会同时发布匹配的KPI模板版本，里面即携带有该用户手册）。附录1：LDT查看RNC的统计任务使用LDT工具可快速确认需要统计的计数器组是否已经下发到RNC数据表中，方法如下：u 打开LDT并登陆RNC【数据探针】查询主GCPA单板查询数据表“sDevCntrGrp” 查看“usCounterGroup”，是否有你需要激活的计数器组。例如，激活了R001组计数器，“usCounterGroup”中就会有“1”显示。u 另外，查询表“sDevCntrGrp”，可查询到该组计数器具体激活的网元对象：

36、具体的原则如下：3、 如果，表“sDevCntrGrp”中有的计数器组，而表“sDevCntrGrp”中没有，则表示该计数器全RNC所有网元对象的统计任务都已被激活。4、 如果表“sDevCntrGrp”和表“sDevCntrGrp”中都有该计数器组，则说明只有部分网元激活了该计数器任务，激活的网元需要查看“aucMeasObjMOC”的值。比如，“0 27 0 0 0 0 0 0”第1、2个，代表RNC的ID。“0 27 0 0 0 0 0 0”第3、4个，代表NodeB的ID。“0 27 0 0 0 0 0 0”第5、6个，代表Cell的ID。“0 27 0 0 0 0 0 0”第7个，代

37、表Carrier的ID。每一个十进制数都是一个8位二进制数，其中RNC、NodeB和Cell必须两个十进制数转换成二进制数相加才是对应网元的ID值。如“0 27 43 103 86 206 2 0”，其中“43 103”表示NodeB的ID；“43”的二进制是“00101011”，“103”的二进制是“01100111”；则ID为“00101011 01100111”，再换算成十进制就是“11111”，表示该NodeB的ID是“11111”。附录2：LDT提取RNC中的cdl和pm文件u cdl文件的提取：LDT登陆目标RNC【系统】【文件上传】“日志类型”选择“cdl日志”选择“文件查询”，

38、就会看到RNC中保存的cdl文件选中要上传的cdl文件，单击右键“上传”。如下图。上图中，“起始时间”和“结束时间”就是cdl文件记录RNC信令的开始、结束时间。最下面窗口中的地址“C:Program FilesLDTftpcdl”，即是cdl上传后保存到本地的路径。u pm文件的提取：LDT登陆目标RNC【系统】【文件上传】“日志类型”选择“网元直连性能数据”选择“文件查询”，就会看到RNC中保存的pm文件选中要上传的pm文件，单击右键“上传”。上图中，“起始时间”和“结束时间”就是pm文件记录RNC计数器数据的开始、结束时间。最下面窗口中地址“C:Program FilesLDTftpdl

39、mpmdata”，即是pm文件上传后保存到本地的路径。注意：本处直接从RNC中提取的pm文件，其实和3.1.3节中RNC上传到OMC中的pm文件是相同的，只是命名规则不一样而已。比如，这里的“dlm_pm_2045_20091112_2030.zip”对应的就是OMC中的“pm_000c_20091112_2030”。其中“20091112_2030”代表开始时间，“2045”代表结束时间。附录3：FTP提取jboss日志“pm.log”提取“pm.log”的方法：FTP登陆jboss所在服务器IP，从路径“/home/v3test/datangmobile/jboss/jboss-cm/se

40、rver/default/log/”中上传pm.log日志。附录4：FTP提取newPC日志“PerdataFile.log”提取“PerdataFile.log”的方法：FTP登陆newPC所在服务器IP，从路径“/home/v3test/datangmobile/newpc/log/”中上传“PerdataFile.log”日志。附录5：FTP提取NEA日志“NodebMsg.log”FTP提取“NodebMsg.log”的方法：FTP登陆NEA所在服务器IP，从路径“/opt/datangmobile/neacommu/log/”中上传“NodebMsg.log”日志。附录6：FTP提取

41、OMC中的pm文件从OMC服务器和newPC服务器的不同位置可以获取RNC上报OMC的pm文件。u RNC上传pm文件到OMC的第一现场：FTP登陆OMC所在服务器IP，打开路径“/home/omcrftp/PM/”。 pm文件的命名规则，比如“pm_0015_20091110_0945.zip” “0015” 十六进制数，表示RNC的ID：RNC21。 “20091110_0945” 表示pm文件记录数据的开始时间。u newPC解压pm文件并保存的第二现场：FTP登陆newPC所在服务器IP，打开路径“/home/v3test/datangmobile/newpc/PM/”。u newPC

42、解析入库pm文件并备份的第三现场：FTP登陆newPC所在服务器IP，打开路径“/home/v3test/datangmobile/newpc/backup/”。附录7：检查NodeB性能统计上报开关的状态检查开关状态的方法如下：OMT【配置】物理基站“小区性能统计参数上报开关” “on”或者“off”。一种利用BRU统计筛选问题NodeB的方法：一、说明 现网中，某些情况下NodeB出现故障后，通过OMT很难及时发现，后台维护工程师不可能每天都使用LMTB去检查每一个NodeB的状态。因此，这类隐性故障一旦出现，如果无法及时发现，很可能会长期影响网络质量，影响KPI指标。本文将介绍一种利用B

43、RU占用统计报表，迅速筛选故障NodeB的方法。本方法不但可用于网络建设初期排查建网过程中的故障NodeB，同样可用于网络维护阶段，通过分析每日BRU占用统计报表，快速的筛选出故障NodeB，然后有目的使用LMTB去排查NodeB的故障。二、原理 BRU占用计数器有两种：一种由RNC上报，只要建立统计计划，并激活小区，RNC就会上报计数器值（不为“”）；另一种是由NodeB上报的计数器，主要是HSDPA和HSUPA业务的BRU占用计数器，本文中我们主要用到的是计数器“HSDPA平均占用BRU数（R062_014）”，NodeB的计数器上报不需要建立统计计划，NodeB状态正常，且性能统计上报开

44、关处于打开状态（默认状态），就可以上报计数器值。本文中，我们将利用这两种计数器分别构成的统计项，去初步判断故障NodeB。OMC统计模板“无线KPI指标统计模版”中，有一张报表统计模板“DT_无线KPI指标统计报表”。其中，统计项“DT_载频下行公共控制信道分配的BRU数”的算法中只含有RNC上报的计数器，统计项“DT_载频HSDPA业务分配的BRU数”算法中只含有NodeB上报的计数器。判断的原则是： 原则1：两个统计项的值都为“”。这种情况有可能是NodeB故障，但更大的可能是该NodeB还未开通。 原则2：“DT_载频下行公共控制信道分配的BRU数”值为“”，“DT_载频HSDPA业务分

45、配的BRU数”有值（非“”）。说明NodeB状态正常，只是小区未激活或者有其它RNC问题。 原则3：“DT_载频下行公共控制信道分配的BRU数”有值，“DT_载频HSDPA业务分配的BRU数”值为“”。这种情况就是初步判断NodeB处于故障状态的证据，是本文分析的重点。三、方法u BRU统计报表输出：使用报表统计模板“DT_无线KPI指标统计报表”在OMT中统计全网的载波级报表。该报表中包括了“DT_载频下行公共控制信道分配的BRU数”和“DT_载频HSDPA业务分配的BRU数”两个统计项。u 按“原则1”对统计报表进行筛选：在BRU占用统计报表中，筛选出“DT_载频下行公共控制信道分配的BRU数”和“DT_载频HSDPA业务分配的BRU数”的值都为“”的载波。然后和实际的NodeB开通情况做比对，检查报表显示的情况是否属实。u 按“原则2”对统计报表进行筛选：在BRU占用统计报表中，筛选出“DT_载频下行公共控制信道分配的BRU数”