您好,欢迎访问三七文档
2006年Page1日讯科技GSM移动通信系统原理培训讲义优化典型案例2006年Page2RisingTechnology日讯科技第一部分:信令分析在优化中的应用实例案例一:利用A接口和E接口信令分析解决局间切换问题对G2的A接口进行了信令跟踪,通过数据分析发现G2的小区向G1的切换成功率非常差,统计结果如下:2006年Page3RisingTechnology日讯科技第一部分:信令分析在优化中的应用实例从上面的数据我们可以看到,有些小区的切换性能非常差,以小区1824910063-1824010281为例,具体的A接口消息流程如下:2006年Page4RisingTechnology日讯科技第一部分:信令分析在优化中的应用实例如上图流程所示,在G2向G1发出HandoverRequired(MAP)消息后0.1秒就收到了HandoverRequiredRejected消息。根据这个现象我们首先怀疑是G2的外部小区数据定义错误,所有我们重新核查了G2的外部小区数据,MSC和BSC的数据都没有错误。在排除这个原因后,我们对应的察看了一下G2的无线话务统计,通过统计发现这种切换拒绝并不是发生在个别小区,而是整个G2向G1的外部小区切换都没有成功,但是我们本网的两个交换机到网外的局间切换都非常正常。2006年Page5RisingTechnology日讯科技第一部分:信令分析在优化中的应用实例由于前面只是进行了G2的A接口信令采集,无法从流程中看到HandoverRequiredRejected消息是不是G1发过来的,在排除外部小区数据定义错误的可能性之后,我们怀疑可能是寻址方式或者是MAP层未激活导致,所有我们又对G1G2和G2G1两个方向的E接口信令进行了采集,来验证我们的怀疑是否正确。2006年Page6RisingTechnology日讯科技第一部分:信令分析在优化中的应用实例E口数据我们采集的是23日17:00-18:00时段,在对这部分数据进行了分析后(通过CallAnalysis软件),我们发现G2向G1发出的HandoverRequired消息成功送达G1,并且收到G1的回复消息,如下所示:2006年Page7RisingTechnology日讯科技第一部分:信令分析在优化中的应用实例由图中红色标识我们可以看到,MAP层消息UDTBEG代表了切换请求,它的源信令点是393089,目标信令点是392998,通过数据检查,我们知道这两个信令点对应的分别是G1(392998);G2(393089)。这样我们就知道这条消息是G2发给G1的切换请求消息,切换的目标小区是460-00-18240-10281,即WUMA28A。2006年Page8RisingTechnology日讯科技第一部分:信令分析在优化中的应用实例我们来看一下接下来的消息UDTCON的解码:2006年Page9RisingTechnology日讯科技第一部分:信令分析在优化中的应用实例我们关注一下图中红色标识区域,通过前面的论述,我们知道这个UDTCON消息是G1发给G2的关于切换请求的回复消息。通过前面的G2G1的E口信令数据分析,我们可以肯定不是由于寻址方式和MAP层未激活导致的局间切换成功率非常差,而且我们可以肯定在G2向G1切换这个方向,切换请求已经送到了G1。2006年Page10RisingTechnology日讯科技第一部分:信令分析在优化中的应用实例为了说明问题的解决思路,我们首先来看一下局间切换的信令流程:2006年Page11RisingTechnology日讯科技第一部分:信令分析在优化中的应用实例由局间切换的信令流程我们可以看到,一个完整的局间切换流程为:首先当前服务小区所在的BSC根据收到的测量报告向所在MSC发出Handoverrequest,MSC判断出该请求属于局间切换,则向目标MSC发出Handoverrequired(MAP),目标MSC在向VLR申请切换号码后,向目标小区发出HandoverRequest消息,在成功激活信道后,向源MSC回复HandoverRequiredACK消息,源MSC收到切换请求确认消息后,向目标MSC发出IAM消息,进行切换过程。2006年Page12RisingTechnology日讯科技第一部分:信令分析在优化中的应用实例针对G2G1的切换不正常现象,我们通过前面的分析可以看到,G2发给G1的HandoverRequired消息已经成功送达MSC1,然后就收到了MSC1发送的HandoverRequiredRejected消息,对照流程我们可以看到问题出在了MSC1侧。那么我们就针对MSC1进行了数据核查,在核查过程中发现在MSC_LAC的定义中MSC1将全部的11个LAC区均定义为本MSC的LAC。在将这个问题调整后,两个交换机之间的局间切换恢复正常,话务统计对比如下:2006年Page13RisingTechnology日讯科技第一部分:信令分析在优化中的应用实例2006年Page14RisingTechnology日讯科技第一部分:信令分析在优化中的应用实例案例二:西门子特殊掉话流程分析跟踪bsc05和bsc07(16:00-17:00)整点全部A接口信令,并与无线侧相应时段的统计进行比较,详细情况见下表:表1:bsc07信令处理结果2006年Page15RisingTechnology日讯科技第一部分:信令分析在优化中的应用实例表2:bsc05信令处理结果2006年Page16RisingTechnology日讯科技第一部分:信令分析在优化中的应用实例通过对bsc05和bsc07A接口掉话流程的分析,发现在这些掉话流程中存在“特殊掉话流程”(次数如上表所列),并有一定的共性,给出一个典型情况:2006年Page17RisingTechnology日讯科技第一部分:信令分析在优化中的应用实例如上图所列出的流程,这类“特殊掉话流程”的共性是在正常通话过程中发出或收到短消息,并且在disconnect消息之前没有完成短消息流程,在relcpl消息之后msc再次指配信道,且收到指配完成消息assignmentcomplete,然后bsc向msc发clearrequest消息触发掉话。2006年Page18RisingTechnology日讯科技第一部分:信令分析在优化中的应用实例在通话过程中,短消息占用Sacch信道,标准流程如下:2006年Page19RisingTechnology日讯科技第一部分:信令分析在优化中的应用实例从实际的A接口信令中也可以滤出通话过程中收、发短信的流程,汇总结果发现在通话过程中完整的短信流程需要10s左右的时间,主要是ms收到cpdata和回应cpack之间的时间比较长约9s,详细流程如下:2006年Page20RisingTechnology日讯科技第一部分:信令分析在优化中的应用实例2006年Page21RisingTechnology日讯科技第一部分:信令分析在优化中的应用实例为了进行对比,下面给出手机在空闲模式下占用sdcch信道收、发短信的流程,可以计算出ms占用sdcch信道收发短信仅需要1s的时间,如下所示:2006年Page22RisingTechnology日讯科技第一部分:信令分析在优化中的应用实例总结:从信令跟踪情况和无线统计的对应关系来看,将“特殊掉话流程”产生的clearrequest计为掉话的可能性是存在的;并且通过其他厂家相应A接口的信令跟踪结果来看,在通话过程中占用sacch收、发短信无线侧回应cpack消息的时间接近9s是正常的。经与西门子技术支持联系,最终需要通过刷新交换机软件,修改相应的消息流程来解决这一问题。2006年Page23RisingTechnology日讯科技第二部分:无线侧优化典型案例案例一:GSM接口版本低导致双频网小区重选异常在晋城联通十二期搬迁扩容工程中,涉及阳城北留M1800基站的搬迁替换。在数据规划时,频点配置继承原有摩托M1800基站频点,结合地理信息规划完整邻区关系,并对小区参数进行合理设置,如合理配置小区层级关系、层间切换门限及磁滞,并将多频报告指示设置为3,确保1800能够很好的吸收话务,并在边缘及时切换到900M小区。搬迁工作结束后,优化人员对北留进行了详细DT测试,测试中发现如下问题:2006年Page24RisingTechnology日讯科技第二部分:无线侧优化典型案例2006年Page25RisingTechnology日讯科技第二部分:无线侧优化典型案例上述图片为在北留镇定点拨测的测试情况,该界面是手机空闲模式下的截图,可以看到在空闲模式下手机驻留在M1800小区3285062943上,邻区列表中仅列出了相邻M1800小区的信息,看不到M900小区频点,锁频到M900小区也出现类似情况,当主服务小区为M900小区时也同样看不到M1800邻区的信息,如下图所示:2006年Page26RisingTechnology日讯科技第二部分:无线侧优化典型案例2006年Page27RisingTechnology日讯科技第二部分:无线侧优化典型案例查询数据库中上述小区BA1和BA2表的频点设置情况,发现BA表中的频点集的确自动生成了,如下所示:2006年Page28RisingTechnology日讯科技第二部分:无线侧优化典型案例但在长时间的定点测试中,空闲模式下都不能正常上报非服务小区本频段的邻小区测量信息,也没有发生M900小区和M1800小区之间的小区重选。后尝试将MBR由3调整到0或者将M1800小区由层二调整回层三,现象依旧。2006年Page29RisingTechnology日讯科技第二部分:无线侧优化典型案例进行通话测试,情况如下:通话模式下占用M9002006年Page30RisingTechnology日讯科技第二部分:无线侧优化典型案例通话模式下占用M18002006年Page31RisingTechnology日讯科技第二部分:无线侧优化典型案例在通话模式下,占用M900或占用M1800小区后,均能够正常上报其他频段相邻小区的测量报告,在实际的测试中也的确可以完成双频小区之间的相互正常切换。2006年Page32RisingTechnology日讯科技第二部分:无线侧优化典型案例检查空闲和通话模式下系统消息2ter和5ter的下发情况,先看看空闲模式下驻留在M900小区(63093北留完小-3)时的系统消息2和2ter,M900小区(63093北留完小-3)系统消息22006年Page33RisingTechnology日讯科技第二部分:无线侧优化典型案例M900小区(63093北留完小-3)系统消息2ter2006年Page34RisingTechnology日讯科技第二部分:无线侧优化典型案例以下是在空闲模式下占用M1800小区(62943北留完小M1800-3)时的系统消息2和2ter,M1800小区(62493北留完小-3)系统消息22006年Page35RisingTechnology日讯科技第二部分:无线侧优化典型案例M1800小区(62493北留完小-3)系统消息2ter2006年Page36RisingTechnology日讯科技第二部分:无线侧优化典型案例从双频网小区下发系统消息2和2ter内容来看是正常的,现网华为小区开局时在系统消息使用的选择上也是默认选择系统消息2、2ter和5、5ter,同时检查通话模式下系统消息5和5ter的下发情况,结果正常。检查小区选择和重选参数,并没有发现特殊设置;在数据配置、系统消息使用等相关信息的检查后并没有发现错误,但空闲模式下的故障现象依然存在。2006年Page37RisingTechnology日讯科技第二部分:无线侧优化典型案例在后续的拨打测试中,还出现异常现象是在占用M1800小区通话,通话结束返回空闲模式时,没有经过小区重选过程直接驻留在M900小区,如下:占用M
本文标题:优化案例收集
链接地址:https://www.777doc.com/doc-4312241 .html