WCDMA网络iPhone手机上网掉线案例分析

admin

本帖摘自《电信技术》2012年08期。【作者】 程松；

【机构】 中国联合网络通信集团有限公司西安市分公司；

【摘要】 在iPhone手机WCDMA网络上玩QQ游戏时经常掉线,根据现场实际情况,通过调整"SGSN的下行报文缓存功能"安全变量设置使该问题得到解决。

【关键词】 WCDMA； 掉线； 释放； 丢包；

1 案例描述

随着WCDMA网络的开通和智能移动终端的普及，越来越多的用户使用手机上网。近期大量用户投诉，使用iPhone手机在WCDMA网络下在线玩“QQ斗地主”游戏时经常掉线。

2案例分析

2.1初步分析

笔者针对iPhone手机玩“QQ斗地主”游戏的场景进行了多次测试，抓取RNC、CN的信令和数据进行分析。通过分析RNC信令发现，iPhone手机有一个特点：在没有数据流量时，会自已发起Signalling Connection Release Indication，等到有新的数据需要发送时，手机会再次发起业务建立。iPhone自已发起的释放、建立非常频繁。

根据RNC的信令可知，UE主动发起的Signalling Connection Release Indication导致释放，而且业务保持的时间较短，大部分情况下只能保持几秒钟或十几秒钟。每次建立、释放都是正常的，没有发现RAB建立失败、RRC连接释放超时的情况。

其他终端（如ZTE数据卡）不会自已发起Signalling Connection Release Indication。在RNC打开了DRBC功能的情况下，如果没有数据流量，RNC会在一段时间后对其进行RRC连接释放，将其转为Idle状态，这个时间一般比UE主动上报Signalling Connection Release Indication的时间要长，因此iPhone测试时大部分情况都是UE主动发起的释放。

2.2 Ping包测试结果

为了进一步弄清楚情况，现场通过ZTE数据卡进行Ping包对比测试，抓取了RNC、GGSN、SGSN的数据流进行分析。

测试发现，每次从Idle状态下Ping包时，第一包总是不通，通过SGSN的码流分析，发现第一包下行数据在SGSN就已经被丢弃，没有发给RNC。

由于iPhone玩“QQ斗地主”游戏时会频繁发起释放和业务建立的指令，很可能会出现上述数据丢失的情况。

通过以上分析可知，数据丢失的原因是：当SGSN没有建立该UE的Iu连接时，无法发送下行数据，而“SGUP下行缓存功能”安全变量没有打开，数据没有缓存，就会被丢弃。上述Ping包测试时，Iu连接正在建立，但Ping包数据比RAB Assignment Response更快到达SGSN，即SGSN的Iu连接还没有完全建好，因此下行数据被丢弃。

iPhone手机进行QQ游戏时，如果UE释放了RRC连接，而服务器需要发送数据给UE时，SGSN需要发起Paging，等待UE的Paging Response，建立RAB，在RAB Assignment Response之前的数据都会被丢弃，这个时间比较长，因此丢的数据比较多。

2.3异常SGSN信令分析

iPhone手机有时会在一次流程中上报两次Service Request初始直传消息，而正常情况下，手机在一次连接中在一个CN域内只应该发起一次初始直传消息。

从异常SGSN信令中可以看出，没有发起RAB指派流程，而是Iu释放，这一次的业务请求失败了。UE在过了几十秒之后再次发起建立。由于中断的时间比较长，上层应用认为连接已经断开，导致游戏掉线。

以上消息流程中出现失败的原因如下。

• SGSN在iPhone用户Iu链路释放后收到用户下行报文，触发Paging，SGSN处于等待Paging响应过程。

•在等待Paging响应的过程中，收到用户的第一条Service Request(请求类型是Data，应是手机有上行业务请求触发），按协议任何上行报文都可以作为Paging响应，SGSN认为收到Paging响应继续后续流程，SGSN发送安全模式命令，处于等待安全模式命令完成的状态。

•在等待安全模式命令完成的状态中，又收到了用户的第二条Service Request消息（请求类型是Paging响应），发送方式是InitialUE承载消息。对于一个用户，SGSN和RNC之间只有一条Iu链路，因此SGSN将第一条Iu链路释放，后续消息都应该从新的链路发送。此处RNC发送第二条“Service Request”消息的方式有问题，应该使用直传消息。

•由于业务请求作为Paging响应消息，而业务请求流程失败会导致Paging流程失败。现场寻呼间隔时间为60min，因此此用户60min内不再发生寻呼请求，也就是后续链路的建立完全靠终端主动建链，Iu链路释放期间，网络侧下行报文全部被丢弃。

然而，上报两次Service Request直传消息不一定会导致异常。在正常的SGSN信令流程中，SGSN收到的第二条Service Request是直传而不是初始直传，后续流程正常，也能看到有Paging下发。只有当两条Service Request都是初始直传且相隔很近时，由于没有可用的Iu连接，RNC才会发起两次Iu建立，引发SGSN流程失败。如果第二条初始直传较晚上报，RNC在已经有Iu连接的情况下，会将其转化为直传发给SGSN，不会引发失败。

2.4 SGSN与GGSN数据对比

通过记录游戏掉线的时间点，对比RNC、SGSN、GGSN的信令和数据，发现游戏掉线时间点附近一般会出现TCP层的FIN、RST包，终止了TCP连接。由于TCP层有数据重传的功能，只要丢包不多、时间不长，TCP层还可以挽救回来。出现TCP连接终止说明丢包超过了TCP层的阈值范围。

将SGSN与GGSN的数据进行对比，发现丢包较多，期间虽然GGSN有数据要发送，由于SGSN没有向UE发送Paging，无法建立连接，TCP层多次重发的数据都被丢弃，最终TCP连接终止，QQ游戏掉线。

从TCP层看，如果UE从下行的TCP ACK包携带的序号感知下行有丢包，UE不会回ACK，而是等待对端重传下行包，如果一段时间后没有收到下行数据，UE就发起FIN结束TCP连接。多次游戏掉线都是这个原因。

2.5对比RNC信令分析

在未出现掉线的RNC下测试发现，RNC频繁发送IU Release Request消息给SGSN，猜测也是因为UE上报Signalling Connection Release Indication导致的。

在实际测试过程中也出现过一次流程中上报两次Service Request消息的情况，SGSN收到的第二条Service Request是直传而不是初始直传，之后直接回应Service Accept，然后再次发起RAB Assignment Request。测试过程中没有出现长时间不发Paging的现象。

3 结束语

开启“SGSN的下行报文缓存功能”安全变量，可以解决两条初始直传消息导致的失败问题，RNC屏蔽同一个域的第二条初始直传消息，或将其缓存并转化为直传发给CN。