WCDMA网关于PS业务掉话问题的案例
商丘分公司关于PS掉话问题的案
例
修订记录
【摘要】针对PS业务的掉话问题进行信令跟踪和分析，找出造成掉话的重要原因，对混合业务切换引起的掉话问题进行重点解决。
【关键词】PS掉话率、context request、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 ）质差小区反而增多。
同时我们分析日志文件中所描述的掉话问题，在数据文件分析中发现，现网中有一种掉话原因，在日志文件的统计中是没有统计的，这种掉话就是“RNC 请求释放分组域Iu 连接对应的RAB 数据（不确定原因）”引起的掉话，如下图：
这种“不确定原因失败”导致的掉话次数占全部掉话次数的60%-70%，是导致商丘PS 业务掉话问题的关键点。通过大量的测试和信令跟踪，发现这种“不确定原因”导致的掉话，其在信令流程中反映如下：
从上面的信令流程来看，这部分“不确定原因”导致的掉话其Iu_ReleaseRequestMsg 携带的消息对于掉话原因的阐述是“非标准原因207”，同时，这类掉话发生在异系统切换的时候，也就是说发生在cellChangeOrderFromUTRAN 以后，出现UE 请求的Iu_ReleaseRequestMsg,从而统计为掉话。
因此可以看出，商丘地区的PS掉话有相当大部分是由PS切换（WCDMA->GPRS）失败造成的。针对此类掉话进行了信令跟踪分析。
2.1 PS异系统切换正常信令流程说明
正常PS切换流程如下：
RNC信令（1次context request）
1．经判断满足切换条件，RNC发起迁移流程，下发CELL CHANGE ORDER FROM UTRAN消息给UE，让UE侧发起小区重选过程切换到GPRS系统中，消息中带有目的小区的BSIC、BAND IND（即是900的还是1800）、BCCH ARFCN、NC mode等信元2．由于UE要小区重选到GRPS小区，关闭了WCDMA的发射，NODEB上报SIR ERROR 报告，不是流程中必需的消息
3．由于UE要小区重选到GRPS小区，关闭了WCDMA的发射，NODEB上报RL FAILURE，不是流程中必需的消息
4．UE接入到异系统小区后，如果不需要恢复PDP上下文，则RNC会直接收到IU接口的IU RELEASE COMMAND消息，如果需要恢复PDP上下文，则从源RNC获取SRNS CONTEXT信息，源RNC会收到IU接口SRNS CONTEXT REQUEST消息，此消息主要带RAB标识
5．RNC响应SRNS CONTEXT RESPONSE消息给核心网，告知各RAB ID中的GTP和PDCP的上下行序列号
6．核心网再给RNC发SRNS DATA FORWARD COMMAND消息，让用户面开始传输数据。在此消息中，核心网告知RNC各RAB数据前转的目的传输层地址及隧道标识7．完成数据传输之后，核心网给RNC下发IU RELEASE COMMAND让RNC释放此UE 8．RNC给核心网回IU RELEASE COMPLETE，后面两条消息再释放NODEB的无线资源，跟正常的释放流程不同的是空口不用再发释放RRC连接消息，因为此时UE已经不在WCDMA系统了，直接本端释放。
2.2 商丘W网PS业务切换（2次context request）
在商丘抓取PS切换成功的PS切换信令发现，RNC有两次SRNS CONTEXT RESPONSE消息消息，比正常的流程多了一次。
2.3 PS掉话信令消息
现网抓取RNC、UE、SGSN、BSC侧信令
UE：
UE收到切换命令后，开始进行切换流程，2s后发送suspend request，12s后第一次发起路由区更新请求，未能及时响应，39s后第二次发起suspend request和路由区更新请求得到响应。
BSC：
第一次收到suspend request，并向SGSN透传了该信令，SGSN也向3G RNC发了context request，但UE发出的路由区更新请求没有收到，待超时后第二次收到了suspend request和路由区更新请求。
SGSN：
SGSN在收到BSC 侧的suspend请求后，与RNC进行了一次context 请求与响应，6秒钟内没有收到路由区更新请求（UE发出的路由区更新请求BSC侧没有收到），收到RNC释放了IU连接请求，因此未能进行正常切换流程。
RNC：
RNC在第一次SRNS context response后，等待data forward，6S后释放IU连接,记为掉话。实际上此时SGSN还未收到UE在GSM网络的路由区更新请求，尚未开始真正的PS切换流程。
RNC第一次收到SGSN下发的SRNSContextRequest时，就以为是上下文交互的信令，所以就直接回复SRNS ContextResponse，并一直等待RNSDataForwardCommand，但从SGSN方面来说，第一次的SRNSContextRequest的下发是MS侧Suspension Request触发的，而不是真正的上下文交互流程，SGSN侧在从Suspension触发的流程中不需要回送RNSDataForwardCommand，但RNC无法区别两个SRNSContextRequest的不同，就默认在第一条context 请求与响应后等待data forward，这样如果手机在2G未及时上报路由区更新请求，就会导致RNC等待超时，从而形成信令流程不全的掉话。
2.4 优化处理
由于2次SRNS context request 内容一样，RNC 无法区分，默认在第一条context 请求与响应后等待 data forward ，这样如果手机在2G 未及时上报路由区更新请求，就会导致RNC 等待超时，建议SGSN 不发第一次context request （发与不发都符合协议，虚线表示可发可不发，如下）。
通过沟通SGSN 侧工程师，关闭SGSN 侧关于Suspend 后下发SRNS Context request 的设置，如下：
2.5 优化效果
SGSN 的Suspend 下发值修改后，问题得到彻底解决，信令流程也正常，如下：
从PS 掉话指标和“RNC 请求释放分组域Iu 连接对应的RAB 数据（不确定原因）”来看，都有较大幅度改善，如下：
【案例总结】
PS掉话率指标是W数据业务中的重要KPI，本次处理的商丘的PS掉话问题，从各方面进行分析掉话原因和解决方案，重点突出在PS混合业务异系统切换时出现下发两次SRNS Context request导致超时掉话的问题，由于在协议定义时，PS用户进行W---GPRS切换时，未完业务挂起后是否发送SRNS Context request没有明确定义，只是说发与不发都可以，在这种情况下，中兴RNC无法区分哪个SRNS Context request是上下文交互的“正确”信令，从而导致这种统计上的掉话。这种掉话现象只是在指标上有所体现，用户体验并不严重。商丘W网络所对应的的SGSN7，现已经作出修改，如其他地市也有这种情况可以建议SGSN侧也同时修改，以降低全省RNC分组域掉话率，提升整体网络指标。