TDSCDMAKPI专题优化

丹东市KPI优化总结报告中国移动通信集团辽宁有限公司2010年6 前言内容介绍鉴于现在TD网络的kpi优化没有现成的经验可寻，大家都是在一步一步的摸索当中，因此本人总结了一下丹东现网的kpi优化思路及具体问题解决方法以供大家参考，本指导首先从大体上介绍了一下丹东TD KPI优化的主体思路，然后通过实例给大家介绍一下具体是怎样实践的，希望能给大家带来一定的启发，通过本指导书希望大家能不断总结自己项目的经验，然后不断的将自己的优化思路和案例形成指导书，为TD kpi优化开拓一条新的思路。读者对象本书适合下列人员阅读：TD-SCDMA工程运维优化的人员ii 一总体思路TOPN小区分析流程图：TOPN小区分析流程：TOPN小区的选取：一.关注KPI指标的拟定： 进行TOP小区分析，首先需要制定重点关注的KPI指标，一般无线的重要指标有：RRC建立成功率，RAB建立成功率，无线接通率，切换成功率以及掉话率等，也可以咨询一下客户还有哪些需要重点关注的。备注：一般对网络指标有直接影响的是失败次数或者掉话次数，所以建议先解决这些小区；成功率低或者掉话率高但是次数很少的小区也需要关注，因为当业务量上来的时候这些小区很可能对网络有很大冲击。2.TOPN小区筛选首先提取全天的全网级的KPI 指标，然后关注各项指标是否符合移动的要求，如不符合，对全网级的小区级kpi进行分析，然后筛选出小区指标差的TOP N，并且每天形成一份kpi数据库，丹东项目上每天通过机房rnc人员将topn小区筛选出来，并形成kpi数据库，并将相应时段的cdl提取放到OMCR 服务器上，以备每天的cdl分析。二、统计信息的输入：采集相关信息如小区状态、ISCP信息、KPI信息及告警信息等，以便进行TOPN小区分析。三、TOPN小区分析：针对问题小区及周边存在的问题，逐个进行处理，输出问题跟踪列表。1、告警查询及解决 在筛选出TOPN小区后，就要对针对这些小区进行分析。在进行分析的时候，建议首选做告警查询及解决。进行告警查询及解决可以先排除由于告警原因或者硬件故障引起的问题，往往在我们分析问题找不到问题原因时，回头一查却是有告警的站点，告警恢复后问题就解决了，这样浪费很多时间和精力，所以建立先做告警查询及解决。2、ISCP查询及处理 ISCP查询及处理和告警查询及处理的目的基本上是一样的，就是先把ISCP原因导致的问题解决掉。具体的ISCP信息查询和KPI一样都是性能查询。（ISCP的查询在人员多的情况下可以按照双提升给出的方法进行分析，但现在项目上为了更快的分析，可以通过表格筛选出iscp值异常的小区，简单做个表格进行分析处理一下）四、CDL分析：针对不存在告警以及ISCP问题的TOPN小区需要重点优化，进行CDL分析，输入问题跟踪列表。 针对问题小区分析CDL文件，看看该小区出现问题的具体原因，能否找到解决问题的办法。例如：如果发现该小区下的问题都是一个用户造成的（可以从IMSI分析出来），这样怀疑是手机问题，可以反馈给客户寻找该用户进行针对处理。在如，若该小区下的问题都和切换有关系，需要核查切换参数设置是否合理，等等。鉴于现在公司软件方面做得不能一次到位，丹东现在系统间的切换着重通过cdlmr分析，掉话和RRC建立失败等着重通过简版cdl分析。五、路测信息采集：若通过CDL分析仍然没有定位问题的具体原因，需要安排针对性测试进行信息采集，该测试的目的是抓到问题产生的现象，以备分析，分析后输出问题跟踪列表。六、反馈技术支持：经过测试分析若依然没有找到问题的原因，整理整个分析过程的信息，反馈给技术支持寻求帮助，输出问题跟踪列表，并跟踪技术支持的处理进度。二 丹东KPI优化操作实践一工具使用在介绍KPI优化时首现介绍一下，首先介绍丹东现网使用丹东优化经理冷涛开发的用数据库筛选TOPN的方法。1、表的创建。 我们每日都从机房提取KPI指标进行分析，每天需要得到最坏小区的相关信息。所以我们将每日的KPI数据导入access中创建为原始表便于查询。就目前来说对我们比较有用的是“小区KPI指标（日常分析）”和“全网KPI指标”两张表。这是通过OMT取出的原始表格式。为了以后的查询更加方便，我们将这两张数据表加入日期列，如下图将加入日期后的数据另存为XLS格式。存好以后我们现在在access中创建原始表。1、在文件菜单中点击获取外部数据-导入-导入刚刚另存为的xls格式的“小区KPI（日常分析）”选择不要主键命名为小区KPI（日常分析）点击完成即可。第一次创建完成以后，以后的每天导入数据便可导入现有表中，选择你要追究的表的名称，如下图。点击完成即可。2、创建查询。附件中我已经将查询创建好，大家只需要双击即可。如我们双击各个查询得出下列表格（1）点击CS语音掉话大于0次（2）点击CS域T-G切换失败次数大于0（3）点击CS域T-G切换失败次数大于0（4）点击PS域T-G切换失败次数大于0（5）点击掉话次数总和（6）点击全网KPI指标查询另外在查询语句中我添加了条件语句，如WHERE 全网KPI.时间 Between 40244 And 40246这里的40244和40246是指的时间，分别对应为2010-3-7，2010-3-9，由于表格存储时不知道数据格式是否发生了变化，如果直接输入时间的话就无法查询，所以只能由数字对应时间。这里的对照关系是通过EXCELL的日期转换为数据的格式转变的。二丹东KPI优化的具体流程丹东现在在kpi优化上主要是机房组人员和优化组人员共同进行的，每天机房组人员查看全网指标，如全网指标不达标，那么立马通知优化组人员，优化组人员立马处理，如全网指标达标，但肯定有个别小区存在指标不达标，因此机房组人员统计出这些小区并发给优化人员，优化人员结合机房组给出的信息，进行原因分析，并维护kpi数据库，如果同一个问题连续出现几天那么就通过参数和路测共同来解决问题。在丹东优化过程中感觉kpi数据库起到一个很好的作用，先将丹东统计的kpi数据在附件里展现出来，希望能给大家带来启发。三丹东具体问题的处理方法本人认为现在咱对于TD的TOPN小区的统计流程肯定是没有问题，现在就缺乏的问题的处理方法，只要掌握问题的处理方法，那么就很好办了，因此只有通过大家不断的总结KPI优化时问题的处理方法，那么KPI优化就不再是一件难事了，从本人做丹东KPI优化来说，感觉现在问题的处理方法和通过参数的优化来解决问题这方面还是比较欠缺，希望大家能集思广义为KPI优化献计献策。案例一：系统间切换成功率的问题处理方法。系统间切换由于涉及到2g信息，2g信息的准确性是2 3g系统间切换的成功率的基础，首先要保证现网TD所加2g邻区的准确性，丹东是通过网络规划优化部王稳利制作的ENET来核查TD所加2g信息的准确性，在保证了TD所加2g小区的合理性后，就需要保证2g与TD小区频点与码字与现网的统一，因此丹东现网每周与局方进行一次2 3g信息的核查，为了核查的方便我方与局方人员共同约定一个表格，在核查数据是只要更新这个表格就可以了，表格如下：为了避免由于TD所加2g邻区的同basic和同bcch问题造成系统间切换失败，首先对全网2g邻区进行basic和bcch进行核查，为了核查的方便本人做了一个TD所加2g小区的信息表，通过这个表格就可以很好的核查出TD所加2g邻区是否是同basic和同bcch，使用方法如下：（1）首先做一个TD的所加2g小区的表： TD所加2g邻区信息表（2）用CONCATENATE函数将TD的RNCID ，CELLID，2G的BCCH，2g的BASIC连接成一个新的字符串，例如如1067 ，13412，74，组成一个新的字符串1067-13412-74，然后用COUNTIF函数统计这个字符串的出现的次数，如这个字符串出现的次数不是一次，就说明该TD所加2g邻区存在同BCCH或同BASIC现象，对于存在这种现象将结合实际路测对同频或同BASIC的2g邻区进行删除。通过CONCATENATE函数将相应的RNCID ， CELLID ， 2G的BCCH，BASIC组成字符串。通过COUNTIF函数统计每个字符串的出现的次数，如果大于一次就说明存在TD所加2g邻区的同频同B问题，因此通过筛选出现次数大于1的字符串，就可以核查出TD小区的2g邻区同频同b现象，例如1067-13411-16696-61出现两次就说明TD的2g邻区有同BASIC现象，然后通过删减来避免同BCCH与同BASIC现象。（3）具体问题的处理方法问题现象：在2月2日17点至2月3日17，2月3日17点至2月4日17点期间段发现丹东现网大唐区域的的系统间切换成功率分别为68.97%和69.23%，非常的低通过网管统计的具体指标如下：RNC1067 ps系统间切换失败统计DT_PS域系统间切换出请求次数DT_PS域系统间切换出失败次数DT_Ps域系统间切换出成功率44813968.97%分小区统计2010-2-2 17:002010-2-3 17:20小区DT_PS域系统间切换出请求次数DT_PS域系统间切换出失败次数DDDT4110513-丹建锦园37249发现丹建锦园3小区切换失败次数占总体失败比例为的35%2月3号到17点到2月4号17点Rnc1067系统间切换失败统计DT_PS域系统间切换出请求次数DT_PS域系统间切换出失败次数DT_Ps域系统间切换出成功率36411269.23%分小区统计小区DT_PS域系统间切换出请求次数DT_PS域系统间切换出失败次数DDDT4118711-铁矿沟13028DDDT4110513-丹建锦园35843DDDT4110711-太阳大厦13910丹间锦园3小区失败次数占总体失败比例为38%通过cdlmr分析丹间锦园的失败主要集中在一个用户IMSI=460079440139882IMSI=460079440139882的用户系统间切换失败记录（cdl统计的时间为2月1号到2月2号）SRNC IDSCELL IDCS/PS域T-LACT-CI总切换次数总失败次数106710513PS45121432614037IMSI=460079440139882的用户系统间切换失败记录（cdl统计时间为1月31号到2月1号）SRNC IDSCELL IDCS/PS域T-LACT-CI总切换次数总失败次数106710513PS45121432613330通过以上分析：丹建锦园3小区的ps系统间切换时严重拖累全网指标，通过移动核心网查找该用户为省外用户无法回访改用户，为了不影向ps系统间切换指标，咱通过删除切换失败的2g邻区来解决指标低的问题。删除后观察近几天的kpi如下2月6日网元及指标比较分析网元DT_Ps域系统间切换出成功率全网93.63%网元及指标比较分析RNC标识小区DT_Ps域系统间切换出成功率1067DDDT4110513-丹建锦园399.34%2月5日网元及指标比较分析2010-2-5 17:00网元DT_Ps域系统间切换出成功率DDDRNC4196.84%网元及指标比较分析RNC标识小区DT_Ps域系统间切换出成功率1067DDDT4110513-丹建锦园3100.00%总结在有的时候无法找到用户的情况下，可以通过删除老是失败的2g邻小区或者提高系统间切换门限让其尽量不进行系统间切换，但这样掉话率会有一定的提升。案例二接通率低的处理方法在实际的应用中本人发现CDLMR在分析系统间切换很好用而在统计掉话等相关问题时只能统计出总的原因，不能很好的定位到信令方面的原因，因此本人在分析RRC与掉话问题时主要通过简版cdl来定位具体问题，通过cdlmr来统计一个大体原因，在分析时通过网管统计出rrc失败与掉话的的具体时间段，然后通过LDT提取相应时段的CDL，然后借助简版cdl分析。问题现象：通过kpi数据库发现丹东大唐区域2月25日，2月26日两天丹东射线公司1与铁矿沟1小区的rrc建立成功率较低，具体指标如图：通过网管分时间段统计发现两个小区的rrc都在同一个时刻失败。并且查看这两个小区无对应告警，因此通过LDT提取相应时段的CDL通过简版cdl分析发现18711与11611这两个小区失败时接入的接入标识是一样的，如图示：通过简版CDL导入CDL简版cdl统计的结果 通过cdl信令分析发现RNC在向UE下发RRC建立请求后，5秒后RNC直接向NODEB下发无线链路删除请求。 信令分析结果通过分析此问题很可能有两个原因：1） 出现这种情况很可能是因为“在UE附近存在2个（或以上）小区同频同码”的情况。当UE所处的服务小区和旁边的小区（并且是属于同一个RNC）同频同码时，UE上发的RRC Connect Request的小区，会被这两个小区都收到。这两个小区收到后，都会上报给RNC，不过可能因为处理时延不同，到RNC的时刻不同。当RNC收到一个RRC Connetion Request请求后就会开始处理，开始同NodeB建立RL。在RL建立之前，RNC又收到了同一UE的RRC Connection Request消息时，就会认为前一个请求已经无效了，就会马山下发Radio Link Delete Request消息，将正要建的RL取消掉，就会出现这样的现象。2） 基站或者RNC出现故障。还有一种可能是“NodeB设备存在故障”：通过现场测试和UE_TRACE信令分析发现，无线链路建立时，RNC主动删除无线链路的原因为在建立RRC连接的过程中，RNC发送节点同步消息，但是基站没有响应或者RNC在底层因为异常丢弃了节点同步帧，初步怀疑为Node B侧设备存在硬件故障。再有一种可能是“RNC板卡故障”：如果这种问题主要集中在一个小区中发生的异常现象基本可以确定是单个小区的故障，但如果某个RNC下很多小区都发生有这种情况，则还是要通过这些小区在RNC端的收敛性来定位是否是RNC相关板卡的故障。通过现场与RNC与基站组交流排除了硬件故障，因此初步怀疑是第一种原因引起的rrc建立失败， 通过ENET查看二者确实是同频同码但距离较远，但发现失败时间一般集中在晚上，但根据TD的特点，怀疑还是有可能存在越区覆盖的，因此修改铁矿沟一下的的码字，修改后第二天发现RRC建立失败现象消失，因此初步判断就是二者同频同码引起的RRC建立失败。案例三：语音掉话优化问题现象：通过网管发现太阳大厦掉话两次：2010-3-15 17:00小区DT_语音业务掉话总次数DDDT4110711-太阳大厦1(RAN=1067,rRnc=1067,rNodeB=107,rCell=10711)2通过网管将掉话时间段找出，然后提取相应时段的cdl，通过简版cdl导出掉话分析：序列号IMSI接入小区频点信息上行码道列表下行码道列表域名417IMSI = 4600771415010681071110055(TS2.8/7)(TS4.16/11) (TS4.16/12)CS简版cdl导出的掉话分析然后根据简版导出的掉话分析中的UEID来查找相应掉话时间段的信令，通过信令发现时太阳大厦1小区与太阳大厦科技大厦（室分站）切换失败引起的掉话。切换失败通过ENET发现太阳大厦1小区与室分站（太阳科技大厦）同频干扰。更换太阳世纪大厦1（室分站）小区的频点10055为10063后连续观察几天后不再出现类似的掉话。 三总结本资料对丹东kpi优化思路及经验作了一个整体的介绍，并举出了具体的一些实力，希望能对大家有一定的指导意义，在TD的KPI优化过程中，本人感觉还是缺乏相关的实践经验，在优化经验我们能找到现象，对有时候很难“对症下药”，这就需要大家不断总结自己的经验，再一个，参数优化方面本人也感觉比较欠缺，希望各位有参数优化方面经验与大家分享一下，丹东现在正在进行参数对kpi指标的一些影响的验证，有结果一定会通知大家，最后希望辽宁项目在KPI优化上能总结出自己的路子来，共同提高辽宁项目的kpi优化水平！ 第 26 页 共 26 页