关于PS掉话问题的案例

z328629104

【摘要】针对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）质差小区反而增多。

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.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.2W网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分组域掉话率，提升整体网络指标。