商丘分公司WCDMA网关于PS业务掉话问题的案例_2011年2月14日
商丘分公司关于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 的日志文件分析，如下：
发现在全天的掉话中，有50%左右的掉话是由于信号差导致弱覆盖造成的掉话。具体来看，弱覆盖原因引起的掉话我们具体从以下4个方面分析：
1、 接入时或掉话前信号非常差
2、掉话前存在多个弱信号小区，形成导频污染（这些也是由于基站
覆盖过远，造成过远基站邻区漏配，形成导频污染）
3、无主导频信号造成掉话
4、快衰落造成掉话
可以看出扰码为154的小区信号在1s内由-89迅速衰减-101.，说明用户所处的位置无线信号复杂，衰减较大，而此时又没有其他强导频，导致掉话。
对于上述弱覆盖引起的掉话问题，一方面是由于邻区漏配形成导频污染引起掉话，另一方面是由于基站的过远覆盖或室内信号的快衰落造成掉话问题，对于弱覆盖引起的问题，我们在作好邻区核查的基础上，对现网的边界基站通过RF调整进行覆盖控制，避免基站的过远覆盖，同时，调整小区接入判决量和判决条件，特别是在3G覆盖边缘的小区，较远区域小区的EC/IO还非常好，但RSCP值已经在-105以下，这时如果用户再接入3G网络，就很容易造成接入失败和掉话，对于这种情况，我们把接入判决量由EC/IO调整为RSCP，判决门限也适当升高，避免过远用户的接入
从日志文件来分析，除去弱覆盖原因还有一些不确定原因造成的掉话，这类问题多数是一个用户引起，从而产生大量的掉话，且用户不定，地理位置分布也零散，具体分析如下：
1、非确定原因
以40071网通大楼为例，在UE上报测量报告后，长达13s RNC没有收到任何信令，导致掉话。通过进一步观察发现，40071小区存在底噪突升的现象，可能与室分系统有关，因此解决底噪突升问题后，掉话问题即可解决。
上述介绍了关于日志文件中所描述的掉话问题，但在数据文件分析中发现，现网中有一种掉话原因，在日志文件的统计中是没有统计的，这种掉话就是“RNC请求释放分组域Iu连接对应的RAB数据（不确定原因）”引起的掉话，如下图：
这种“不确定原因失败”导致的掉话次数占全部掉话次数的60%-70%，是导致商丘PS业务掉话问题的关键点。通过大量的测试和信令跟踪，发现这种“不确定原因”导致的掉话，其在信令流程中反映如下：
从上面的信令流程来看，这部分“不确定原因”导致的掉话其Iu_ReleaseRequestMsg携带的消息对于掉话原因的阐述是“非标准原因207”，同时，这类掉话发生在异系统切换的时候，也就是说发生在cellChangeOrderFromUTRAN以后，出现UE请求的Iu_ReleaseRequestMsg,从而统计为掉话。
通过上述分析，我们基本上可以判定这种掉话是由于异系统切换造成的，那我们先来看一下正常的异系统切换流程，如下：
从上面的流程图中可以看到，MS在切换到2G下后，会发起路由区请求（Routing Area Upda Request）,然后SGSN向MS原来的RNC 发送上下文请求（SRNSContextRequest）,RNC回复(SRNSContextResponse),SGSN收到SRNSContextResponse后就会给
RNC发SRNSDataForwardCommand，以完成整个上下文的交互，从正常流程来看，只有RNC收到RNSDataForwardCommand后，才释放Iu链路。
但在商丘W网络的问题流程中则发现如下流程：
Iu口信令-RNC侧
在接收到两次SRNSContextRequest后大约10S左右，Iu链路异常释放，从而形成掉话。从UE侧信令流程来看，如下：
空口信令
UE在接到Cell Change Order From UTRAN后，就发起GPRS Suspension Request,同时在22秒后发起Routing area update(路由区更新)，BSC收到用户的Suspension Request和Routing area update，并上报SGSN，SGSN收到Suspension Request消息后就直接向RNC下发SRNSContextRequest，RNC还回了SRNS ContextResponse,如下图：
IU-ps口信令-SGSN侧
但在SGSN还没有收到UE发出的Routing area update(路由区更新)时，由于超时，RNC就已经把Iu链路释放了，从而造成RNC侧信令流程不全（没有收到SGSN发出的RNSDataForwardCommand）。而在RNC侧跟踪的信令来看，如下：
RNC第一次收到SGSN下发的SRNSContextRequest时，就以为是上下文交互的信令，所以就直接回复SRNS ContextResponse，并一直等待RNSDataForwardCommand，但从SGSN方面来说，第一次的SRNSContextRequest的下发是有MS侧Suspension Request触发的，而不是真正的上下文交互流程，SGSN侧在从Suspension触发的流程中不需要回送RNSDataForwardCommand，但RNC无法区别两个
SRNSContextRequest 的不同，就默认在第一条context 请求与响应后等待 data forward ，这样如果手机在2G 未及时上报路由区更新请求，就会导致RNC 等待超时，从而形成信令流程不全的掉话。
【处理过程】
根据上述的分析，建议SGSN 不发第一次SRNS Context request （发与不发都符合协议，虚线表示可发可不发），如下：
我们通过沟通SGSN 侧工程师，关闭SGSN 侧关于Suspend 后下发SRNS Context request 的设置，如下：
【效果对比】
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分组域掉话率，提升整体网络指标。