51学通信技术论坛

 找回密码
 立即注册
搜索
查看: 3429|回复: 0

WCDMA网络iPhone手机上网掉线案例分析 [复制链接]

Rank: 9Rank: 9

发表于 2013-2-4 23:40:50 |显示全部楼层
一键分享 一键分享

本帖摘自《电信技术》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。

51学通信(www.51xuetongxin.com):致力打造最好的通信技术在线学习平台 。
您需要登录后才可以回帖 登录 | 立即注册

站长邮箱|Archiver|51学通信 ( 粤ICP备11025688 )

GMT+8, 2024-3-28 20:41 , Processed in 0.026140 second(s), 14 queries .

Powered by Discuz! X2

© 2001-2011 Comsenz Inc.

回顶部