WCDMA网关于PS业务掉话问题的案例分析.docx
- 文档编号:18536125
- 上传时间:2023-08-19
- 格式:DOCX
- 页数:14
- 大小:4.59MB
WCDMA网关于PS业务掉话问题的案例分析.docx
《WCDMA网关于PS业务掉话问题的案例分析.docx》由会员分享,可在线阅读,更多相关《WCDMA网关于PS业务掉话问题的案例分析.docx(14页珍藏版)》请在冰点文库上搜索。
WCDMA网关于PS业务掉话问题的案例分析
商丘分公司关于PS掉话问题的案例
拟制人
余红杰、陈超、胥世忠、杨鹏
案例编号
审核人
发布日期
适用范围
PS掉话、异系统切换
修订记录
日期
修订内容
评审意见
【摘要】针对PS业务的掉话问题进行信令跟踪和分析,找出造成掉话的重要原因,对混合业务切换引起的掉话问题进行重点解决。
【关键词】PS掉话率、contextrequest、SGSN
【现象描述】
商丘WCDMA网络掉话率指标持续较高,掉话率月平均0.46%(以11月份为例),明显高出全省0.29%的平均水平,全省指标排名倒数。
全网掉话率指标差,从掉话较多的基站筛选来看,掉话问题主要集中在边界区域。
如下图:
(掉话高基站分布,红/黄为掉话高基站)
但通过大量的投诉分析和实地测试,没有感受到有掉话现象,但后台统计则发现许多掉话问题(后台统计为掉话)
【问题分析】
WCDMA掉话率指标=(RNC请求释放的电路域掉话的RAB数目+RNC请求释放电路域Iu连接对应的RAB数目+RNC请求释放的分组域掉线的RAB数目+RNC请求释放分组域Iu连接对应的RAB数目)/(电路域总共释放的RAB数目+分组域总共释放的RAB数目)×100%
从上述公式来看,WCDMA掉话率是有CS掉话和PS掉话共同决定的,从KPI指标分析,商丘WCDMA网的掉话严重问题是由于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)质差
7
2
1
95
19
100
0
同时我们分析日志文件中所描述的掉话问题,在数据文件分析中发现,现网中有一种掉话原因,在日志文件的统计中是没有统计的,这种掉话就是“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释放此UE
8.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(发与不发都符合协议,虚线表示可发可不发,如下)。
通过沟通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分组域掉话率,提升整体网络指标。
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- WCDMA 网关 PS 业务 问题 案例 分析
![提示](https://static.bingdoc.com/images/bang_tan.gif)