您好,欢迎访问三七文档
当前位置:首页 > 商业/管理/HR > 薪酬管理 > WCDMA网关于PS业务掉话问题的案例
商丘分公司关于PS掉话问题的案例拟制人余红杰、陈超、胥世忠、杨鹏案例编号审核人发布日期适用范围PS掉话、异系统切换修订记录日期修订内容评审意见【摘要】针对PS业务的掉话问题进行信令跟踪和分析,找出造成掉话的重要原因,对混合业务切换引起的掉话问题进行重点解决。【关键词】PS掉话率、contextrequest、SGSN【现象描述】商丘WCDMA网络掉话率指标持续较高,掉话率月平均0.46%(以11月份为例),明显高出全省0.29%的平均水平,全省指标排名倒数。0.000.100.200.300.400.500.600.702010年11月1日2010年11月3日2010年11月5日2010年11月7日2010年11月9日2010年11月11日2010年11月13日2010年11月15日2010年11月17日2010年11月19日2010年11月21日2010年11月23日2010年11月25日2010年11月27日2010年11月29日全省平均郑州商丘全网掉话率指标差,从掉话较多的基站筛选来看,掉话问题主要集中在边界区域。如下图:(掉话高基站分布,红/黄为掉话高基站)但通过大量的投诉分析和实地测试,没有感受到有掉话现象,但后台统计则发现许多掉话问题(后台统计为掉话)【问题分析】WCDMA掉话率指标=(RNC请求释放的电路域掉话的RAB数目+RNC请求释放电路域Iu连接对应的RAB数目+RNC请求释放的分组域掉线的RAB数目+RNC请求释放分组域Iu连接对应的RAB数目)/(电路域总共释放的RAB数目+分组域总共释放的RAB数目)×100%从上述公式来看,WCDMA掉话率是有CS掉话和PS掉话共同决定的,从KPI指标分析,商丘WCDMA网的掉话严重问题是由于PS掉话所引起的。如下:0.000.100.200.300.400.500.600.700.8011月1日11月3日11月5日11月7日11月9日11月11日11月13日11月15日11月17日11月19日11月21日11月23日11月25日11月27日11月29日3G掉话率CS业务掉话率PS业务掉话率从上图可以看出,掉话主要是由于PS业务掉话引起,下面也只针对PS掉话进行分析。提取一天全网所有RNC的日志文件分析,如下:目前PS掉话主要有三类,最大一类是弱覆盖引起的,有50%左右的掉话是由于信号差导致弱覆盖造成的掉话,结合地理化显示可以看出,主要的问题小区分布在3G的边缘覆盖区域,这种环境是极易造成掉话,另一类是未定义的无线原因,例如无线链路不恢复,无线链路失败等等,导致该类问题的原因较多,而且一般用户都很分散,排查有难度,再有一类是导频污染导致,其中导致导频污染原因较多的是邻区漏配造成激活集强干扰。针对以上这几种情况的优化大致策略有以下三种:1.1弱覆盖引起的PS掉话1)、RF优化解决,针对TOP小区,通过优化工程参数,合理控制覆盖范围,避免较远处用户使用,可配合参数优化。2)、推动加站,网络边缘位置,弱覆盖严重,加站是最佳解决方案。3)、参数优化,主要集中在系统间切换类参数,2D,3A类事件参数优化,可针对这些小区建立合理的参数索引,使信号不好时用户尽快切向2G侧,同时需要2G侧覆盖良好。1.2未定义的无线原因该类问题用户较多,分布杂乱,一个用户偶尔几次的掉话,累计起来会产生很多,对于该类问题,需要连续观察TOP差小区,对于那些一段时间一直位于差小区行列的小区进行重点排查,偶尔一次进入差小区行列的小区,可能是某一个用户的偶尔导致,可继续观察,滚动式跟踪优化。如下图所示:1.3导频污染引起结合关联日志分析,导频污染的多路信号差别不大,这些主要需要RF优化解决,大多数是由于基站覆盖过远,造成过远基站邻区漏配,如下图所示:扰码为165的小区满足了1A事件门限,但是由于没有配置为邻区,所以不能及时加入激活集导致强干扰掉话。2.弱覆盖掉话分析分析发现绝大部分PS掉话都是在3G覆盖边缘发生的,因此,首先考虑的就是通过优化调整2/3G切换参数,使信号不好时用户尽快切向2G侧。将覆盖边缘的3G小区的PS域WCDMA-GPRS的2D门限参数调整为-95dbm,通过一周的指标分析,发现PS掉话没有明显提升,而且PS切换出成功率(WCDMA-GPRS)质差小区反而增多。RRC建立成功率质差小区数量RAB建立成功率质差语音业务掉话率质差PS业务掉话率小区系统间电路域切换出成功率(WCDMA-GSM)质差小区系统间电路域切换出成功率(WCDMA-GPRS)质差小区系统间电路域切换出成功率(GPRS-WCDMA)质差72195191000同时我们分析日志文件中所描述的掉话问题,在数据文件分析中发现,现网中有一种掉话原因,在日志文件的统计中是没有统计的,这种掉话就是“RNC请求释放分组域Iu连接对应的RAB数据(不确定原因)”引起的掉话,如下图:这种“不确定原因失败”导致的掉话次数占全部掉话次数的60%-70%,是导致商丘PS业务掉话问题的关键点。通过大量的测试和信令跟踪,发现这种“不确定原因”导致的掉话,其在信令流程中反映如下:从上面的信令流程来看,这部分“不确定原因”导致的掉话其Iu_ReleaseRequestMsg携带的消息对于掉话原因的阐述是“非标准原因207”,同时,这类掉话发生在异系统切换的时候,也就是说发生在cellChangeOrderFromUTRAN以后,出现UE请求的Iu_ReleaseRequestMsg,从而统计为掉话。因此可以看出,商丘地区的PS掉话有相当大部分是由PS切换(WCDMA-GPRS)失败造成的。针对此类掉话进行了信令跟踪分析。2.1PS异系统切换正常信令流程说明正常PS切换流程如下:RNC信令(1次contextrequest)1.经判断满足切换条件,RNC发起迁移流程,下发CELLCHANGEORDERFROMUTRAN消息给UE,让UE侧发起小区重选过程切换到GPRS系统中,消息中带有目的小区的BSIC、BANDIND(即是900的还是1800)、BCCHARFCN、NCmode等信元2.由于UE要小区重选到GRPS小区,关闭了WCDMA的发射,NODEB上报SIRERROR报告,不是流程中必需的消息3.由于UE要小区重选到GRPS小区,关闭了WCDMA的发射,NODEB上报RLFAILURE,不是流程中必需的消息4.UE接入到异系统小区后,如果不需要恢复PDP上下文,则RNC会直接收到IU接口的IURELEASECOMMAND消息,如果需要恢复PDP上下文,则从源RNC获取SRNSCONTEXT信息,源RNC会收到IU接口SRNSCONTEXTREQUEST消息,此消息主要带RAB标识5.RNC响应SRNSCONTEXTRESPONSE消息给核心网,告知各RABID中的GTP和PDCP的上下行序列号6.核心网再给RNC发SRNSDATAFORWARDCOMMAND消息,让用户面开始传输数据。在此消息中,核心网告知RNC各RAB数据前转的目的传输层地址及隧道标识7.完成数据传输之后,核心网给RNC下发IURELEASECOMMAND让RNC释放此UE8.RNC给核心网回IURELEASECOMPLETE,后面两条消息再释放NODEB的无线资源,跟正常的释放流程不同的是空口不用再发释放RRC连接消息,因为此时UE已经不在WCDMA系统了,直接本端释放。2.2商丘W网PS业务切换(2次contextrequest)在商丘抓取PS切换成功的PS切换信令发现,RNC有两次SRNSCONTEXTRESPONSE消息消息,比正常的流程多了一次。2.3PS掉话信令消息现网抓取RNC、UE、SGSN、BSC侧信令UE:UE收到切换命令后,开始进行切换流程,2s后发送suspendrequest,12s后第一次发起路由区更新请求,未能及时响应,39s后第二次发起suspendrequest和路由区更新请求得到响应。BSC:第一次收到suspendrequest,并向SGSN透传了该信令,SGSN也向3GRNC发了contextrequest,但UE发出的路由区更新请求没有收到,待超时后第二次收到了suspendrequest和路由区更新请求。SGSN:SGSN在收到BSC侧的suspend请求后,与RNC进行了一次context请求与响应,6秒钟内没有收到路由区更新请求(UE发出的路由区更新请求BSC侧没有收到),收到RNC释放了IU连接请求,因此未能进行正常切换流程。RNC:RNC在第一次SRNScontextresponse后,等待dataforward,6S后释放IU连接,记为掉话。实际上此时SGSN还未收到UE在GSM网络的路由区更新请求,尚未开始真正的PS切换流程。RNC第一次收到SGSN下发的SRNSContextRequest时,就以为是上下文交互的信令,所以就直接回复SRNSContextResponse,并一直等待RNSDataForwardCommand,但从SGSN方面来说,第一次的SRNSContextRequest的下发是MS侧SuspensionRequest触发的,而不是真正的上下文交互流程,SGSN侧在从Suspension触发的流程中不需要回送RNSDataForwardCommand,但RNC无法区别两个SRNSContextRequest的不同,就默认在第一条context请求与响应后等待dataforward,这样如果手机在2G未及时上报路由区更新请求,就会导致RNC等待超时,从而形成信令流程不全的掉话。2.4优化处理由于2次SRNScontextrequest内容一样,RNC无法区分,默认在第一条context请求与响应后等待dataforward,这样如果手机在2G未及时上报路由区更新请求,就会导致RNC等待超时,建议SGSN不发第一次contextrequest(发与不发都符合协议,虚线表示可发可不发,如下)。2.Suspend6.RouteingAreaUpdateRequest1.IntersystemHandoverMSBSS2G/3GSGSNMSC/VLR3.Suspend4.Resume5.ChannelRelease3.SuspendAck4.ResumeNackSRNS3.SRNSContextReqest3.SRNSContextResponse通过沟通SGSN侧工程师,关闭SGSN侧关于Suspend后下发SRNSContextrequest的设置,如下:2.5优化效果SGSN的Suspend下发值修改后,问题得到彻底解决,信令流程也正常,如下:从PS掉话指标和“RNC请求释放分组域Iu连接对应的RAB数据(不确定原因)”来看,都有较大幅度改善,如下:【案例总结】PS掉话率指标是W数据业务中的重要KPI,本次处理的商丘的PS掉话问题,从各方面进行分析掉话原因和解决方案,重点突出在PS混合业务异系统切换时出现下发两次SRNSContextrequest导致超时掉话的问题,由于在协议定义时,PS用户进行W---GPRS切换时,未完业务挂起后是否发送SRNSContextrequest没有明确定义,只是说发与不发都可以,在这种情况下,中兴RNC无法区分哪个SRNSContextrequest是上下文交互的“正确”信令,从而导致这种统计上的掉话。这种掉话现象只是在指标上有所体现,用户体验并不严重。商丘W网络所对应的的SGSN7,现已经作出修改,如其他地市也有这种情况可以建议SGSN侧也同时修改,以降低全省RNC分组域掉话率,提升整体网络指标。
本文标题:WCDMA网关于PS业务掉话问题的案例
链接地址:https://www.777doc.com/doc-2866988 .html