XX移动用户手机上网感知提升项目报告

'用户手机上网感知提升项目报告XX信息技术有限公司数据业务项目组2012年3月4日1概述42网络承载性能分析42.1Attach4 1.1.1Attach成功率41.1.2失败原因分析61.1.3Attach时延121.2PDP141.2.1PDP激活成功率141.2.2失败原因分析161.2.3PDP激活时延211.3RAU221.3.1RA更新成功率221.3.2失败原因分析241.3.3RA更新时延301.4PS寻呼分析311.4.1成功率311.4.2触发PS寻呼的业务分布321.4.3响应时延332网络业务性能分析343」浏览类业务343.1.1业务成功率343.1.2失败原因分析353.1.3业务时延473.1.4业务速率493用户行为分析504.1数据流量分布504.1.1浏览类业务504.1.2IM类业务514.1.3邮件类业务524.2浏览类业务细分52 1总结54 1概述本文利用XX移动现有平台数据库，结合XX软件特点，分流程对网络承载性能、网络业务性能及用户行为进行分析，重点对流程中影响用户上网的问题进行阐述、信令重现并详细分析造成失败的原因，最后对这些原因进行归纳综合提出相应的解决方法。本次数据分析采用Gb接口数据，主要分析的对彖为覆盖广州地区的13个BSC（GZM31A、43B4、16A、16B、43B2、03B、04A、04B、32A、18A、32B、03A）。以下从网络承载性能、网络业务性能、用户行为三个章节分别介绍信令流程中出现的问题并加以解析。2网络承载性能分析2.1Attach2.1.1Attach成功率Attach-周性能统计指标如下表（数据来源时间为：2012年2月240-2012年3月1日全天）：吋间尝试次数（排除用户原因）成功次数成功率2012-02-244250675388377891.40%2012-02-254189385383365291.50%2012-02-264151944378877791.30%2012-02-273642418328780490.30%2012-02-283017623275869591.40%2012-02-291919985177469292.40%2012-03-012682118246517791.90%•周走势图如下: Attach成功率周走势GPRS—周附着尝试次数23854148次，附着成功次数21792575次，附着成功率为91.36%。从上图看出，Attach成功率比较平稳，没有明显的波动。对3月1号数据进行了BSC维度和小时维度的分析,其中,GZM32B、GZM04B指标相对较低；此外，凌晨时段成功率较差。各个BSC附着成功率分布如下。BSC级attach成功率可以看出，在所有BSC中,GZM32B、GZM04B3月1号attach成功率较低。3月1号0-23点各时段pool4附着成功率及尝试次数分布如下。 Pool4attach尝试次数及成功率96.00%94.00%92.00%90.00%88.00%86.00%84.00%82.00%80.00%01234567891011121314151617181920212223—尝试次数TB-成功率可以看出，在凌晨2-5点attach成功率较差。2.1.2失败原因分析一周内的失败原因及分布比例如下:失败原因次数失败原因占比GPRSservicesnotallowed108554552.66%detach_ul61398929.78%GPRSservicesnotallowedinthisPLMN1428446.93%Networkfailure841744.08%GPRSserv,&non-GPRSserv.notallowed532122.58%Invalidmandatoryinformation388801.89%detach_dl321761.56%protocolerror,unspecified80180.39%MSidcannotbederivedbynetwork22760.11%Auth_Reject4590.02%英分布图如下: Attach失败原因值分布■Auth_Reject■GPRSserv.&non-GPRSserv.notallowed■GPRSservicesnotallowed■GPRSservicesnotallowedinthisPLMN■Invalidmandatoryinformation■MSidcannotbederivedbynetworkiNetworkfailuredetach_dldetachul可以看出，GPRSservicesnotallowedGPRSservicesnotallowedinthisPLMN等原因值占比较大。下面将对其中的几个主要拒绝原因做出信令重现并加以解析。2.1.2.1GPRSservicesnotallowed分析:下面是一个GPRSservicesnotallowed的一个流程。下表为统计出的一周内由于该原因导致Attach失败次数超过10次的用户。根据附着过程信令流程，SGSN需要到用户归属的HLR更新其位置信息。该原因值的出现代表Gr接口网络层的连通性并没有问题，mop消息都能正常的接收和发送。根据HLR返冋的原因值，提示用户有GPRS功能但是没开通GPRS业务或者GPRS业务处于关闭状态。 gprsservicesnotal1owed・xls可以通过短信告知用八GPRS业务不可用，提醒其开通此项业务。2.1.2.1GPRSservicesnotallowedinthisPLMN分析：当前的PLMN不允许GPRS服务，即不允许漫游，主要由于用户IMSI属于其他PLM乂此外，有些国际用户虽然与移动开通了漫游来访，但如果用户本身不允许漫游，也会返冋该失败原因。GPRSservicesnotallowedinthisPLMN流程示意图如下所示。下表为统计出的一周内由于该原因导致Attach失败次数超过10次的用户。gprsservicesnotallowedinthisp除了漫游受限以外，如果本地用户在HLR中的签约数据不正确也会导致该错误，如用户的APN信息被删除。根据经验，目前工作人员在关闭用户GPRS套餐吋会删除APN信息，但却不关闭GPRS的功能，此吋HLR上存在两个特点:•GPRS功能开启•APN接入点为空 这就导致部分终端有附着请求，但会产生这种GPRSservicesnotallowedinthisPLMN的原因，因此建议检查上表中本地用户在HLR中的APN信息。2.123DetachUL该原因值属于系统内部定义值，主要由于用户终端发起Attach信令后立即发Detach消息导致，下面是一个示例：可以看到，用户发起Attach时上报的MCC和MC均为十六进制F,LAC和RAC号码也不正确，在网络发起鉴权时主动发起去附着申请。利用平台我们对以看到大部分没有较多的信息:拖曳一列页眉在此进行排序LACCI用户原因值去试次数成功次数成功率平均时延（皇秒）终端943913182d.etach_ul200.00%943913191detAch_ul1700.00%943913191d►►iJ亠Q拖曳一列页眉在此进行排序时间LACCIBSC名小区名站塑网络类型用户IMEI终端原因值失败消息2012-03-0117:2013943913191GZM31ADIEXFC1■2G460000110669212=3536820216787301jMotorolaV500d*ttch_ulDTREQ 由此推断主要由山寨机引起。经过查询，诺基亚［仿］,N98、苹果［仿］,iPhone4这两款终端失败次数较多。所有终端在统计时间内发生该现象的次数以及其附着成功率如下表：MSTypecauseofDetach_ul.xls对于发生该现象较多而且附着成功率又较低的终端，建议联系相关厂家进行进一步测试软件问题。2.1.2.4GPRSserv.&non・GPRSserv.notallowed不允许GPRS及非GPRS服务，用户被停机导致，即连普通的GSM话音功能也不允许。可能是一些被用户废弃的STM卡重新插入手机开机导致。用户如下：GPRSserv.&nonGPRSserv.notal可以通过短信告知用户已停机，提醒其及时交费充值。2.1.2.5Invalidmandatoryinformation主要由于特定终端用TMET代替TMST或PTMST进行Attach尝试导致，属于终端软件异常导致，经过查询，在这些异常的用户IMSI屮，其屮以空值和全1值居多。2.1.2.6Networkfailure网络失败，主要与Gr接口的通畅度及HLR上用户数据配置正确与否有关，当用户数据配置错误或者漫游用户的HLR返回的响应消息显示不支持GPRS的所需的MAP版本时则Attach被拒绝。也有一种情况是用户在附着申请时本身上报的信息有误，如TMST不正确，MCC、MNC等参数不合法等，如图： Cl99483012:51:43"36301O.1Z8.24S.14—>1CL129•丄60•夕7[GHMSM]Attachrequest.214S8996146125143*5201S710.129•丄60.97-->10.128.24S.Z8[GMMSM]Attachreject996226125143*53016710.128.245.14-->10・129・160.97[BSSGP]UL-UNITDATA214S8113989412S201*2271786410.128.245.14-->10.129.160.97[GMMSM]Attachrequest214581141347125201*38718024丄0•丄160.97--MCL128・24S•丄4[GMMSM]Attachreject11561S312SZ03*16919806丄0•丄28.24S.14-->1CL129・JL60.97[BSSGP]LLC-DISCARDED116802Z12SZ0416Z321260JLO•丄Z8・Z45・丄4-->10.129.160.97[GMMSM]Att.achrequest214S81169749125Z04"8172145410.129•丄60・97-->10.128.24S•丄5[GMMSH]Attachreject116980312SZ04"825Z1462JLO•丄28.24S•丄4-->10.129・160.97[BSSGP]UL-UNITDATA214S81246326125214"44531082丄0•丄Z8.245・丄4--津:L0.129・160.97[GMMSM]Att.achrequest214581247514125214159531232JLO•丄29.160.97--津丄0・128.245.25[GMMSM]Attachreject12475S8125214"60031237丄0•丄28.245.14-->10.129■丄60.97[BSSGP]UL-UNITDATA214S813657901Z5229"4Z746064丄0•丄28.245.14-->10.129■丄60.97[GMMSM]Attachrequest214581366854125229"56346200丄0•丄29.160.97・->丄0・128・Z45.20[GMMSM]Attachreject1366911125229"S714620810.128・245・14・-»丄0・129・160.97[BSSGP]UL-UNITDATA21458148951112SZ44"5856122210.128・24S・129・丄60.97[GMMSM]Att.achrequest.21458149110612S244"7736141010.129・160.97-->10.128・245•丄7[GMMSM]Attachreject149176712S244"8606149710.128.245•丄4―>10.129.丄60.97[BSSGP]UL-UNITDATA214S8160206012S258"2687490510.128.245•丄4--〃丄0•丄29.丄60.97[GMMSM]Detachrequest-21458160206912S258乜687490510.129・丄60・97-丄0・128・24S•丄0[LLC]UExchangeidentification160Z070125Z58"2687490510.129・丄60・97-・»丄0・128・24S•丄0[GMMSM]Detachrequest.160213912SZ58*2737491010.128・24S・14--AJ.0.123.JL60.37[BSSGP]UL-UNITDATA214581602140125258*273749101O.1Z8.24S.14—>10・129•丄60•夕7[BSSGP]UL-UNITDATA214S81606029125258*7517S3881O.128.24S.14-->10・129・160.97[LLC]UExchangeidentificat214S81746061125316*5089314510.128.245.14-->10・129・160.97[BSSGP]PADIO-STATUS頭消息参数MainInfoGHMSM::Transaction/Skipid:0GMMSM::SplitPGcyclecode:8GMMSM::GMMSM::GMMSM::GZIHSM::GZIHSM::IMSI:460000000000000ICC:INC:LAC:RAC:FFFFF655340GHMSM::RFPowerCapability[1]GMMSM::RFPowerCapability[2]IMSI不正确,MCC>MNC等参数不合法，所以SGSN返回Networkfailure。另外我们从用户角度分析该原因值发现有部分国际漫游用户失败次数较多，如下表:所有用户如下表:IMSI尝试次数440006103247517191840411813602445554040411020121381820250502320391024011820810349179097090530052168235288894041181007973018540411030177556773 雹附着优化总体结杲networkfailure・x除此之外，我们又从小区维度分析发生该现彖的区域分布，提取出发生次数超过100次的这些小区如下表：LAC-CI尝试次数10037-6543230410037-1205527810037-5204226210037-5204320510037-6543019010037-6541818610037-6540618410037-6540415210037-2409514810037-654001289449-28884113建议检查这些小区的无线环境以及漫游用户的签约数据。2.1.3Attach时延Attach是进行数据业务的第一步，3GPP屮关于Attach过程的信令流程如下图所示: MS||RANSGSNHLR-1.AttachRequest占IdentityRequest•2.IdentityResponst•••••••••■・・■■■■■■■•・•••••••••••••••S^Au^entication*■次数一■■累计占比4a.gp城Location-e—4b.InsertSubscriberDat4c.InsertSubscriberDat直实—^d.UpdateLocationA康右AttachAccept6.AttachComplete在Gb接口,我们取AttachComplete消息距离AttachRequest消息之间的时间间隔作为Attach的时延。以下为连续一周的GPRS附着时延分布图：Attach时延分布7000000600000050000004000000300000020000001000000由上图可知本次信令分析数据的ATTACH时延主要集中在3000ms以内，基本属于正常。下曲我们将对采样时间段内的一个超长ATTACH时延进行举例分析: -w||PillJ弐]RefGroup：!Default2J&IS...IJJU]MainInfoClSequence...Acknowled...WindowExpected...382649100:03:06-235010.128.238・73--》JL0.JL29.164.1289S?MHSM)Attachrequest00:03:06*241600:03:07*04380800:03:13*637740200:03:13*637740200:03:22*0101S77S00:03:24"Z441800900:03:25*6591942400:03:25"6591942400:03:30*2452401000:03:37*0113077600:03:37*0433080800:03:37*045308103826S3S383070638598113839812389S1313906006391Z81339128143933573396914639693563969364[BSSGP]LLC-DISCAPDED[BSSGP]RADIO-STATUS[BSSGP]RA-CAPABILITY-UPDATE-ACK[GMMSM]Ident,icyrequesZ[BSSCP]LLC-DISCAPLED[BSSCP]RADIO-STATUS[GIIHSM]Ident-it-yrequest.[BSSGP]PA-CAPABILITY-UPDATE-ACK(BSSGP1RA-CAPABILITY-UPDATE10.129・丄64•丄92—aJL0.128.238.73[GMHSM]Identityrequest.丄0•丄28.238・73—>10•丄Z今•丄64..1289S3SSGP]UL-UNITDATA丄0•丄Z8・238・73~>10•丄Z乡•丄64•丄9Z丄0・128・Z38.73―>10.129.164.192丄0.129・164.192—>10・1Z8・Z38.76丄0.1Z9・丄64.丄夕Z--AJLO.JLZ8・Z38.73丄0.128・238・73—>10.129•丄64•丄9210.128.238.73—>10.129.164.192丄0・129・J.64.192―>10.128.238.73丄0・129.164.192—>10.128.238.7610.128.238.73—>10.129.164.192丄0・JL28.238・73—>10•丄29•丄64..1289S3SSGP]UL-UNITDATA400929300:03:44"73738S02丄0・128.238・73--A1L0・丄29・JL64・丄289Asachreauwst4014S8800:03:4S"7173948210・128.238・73--aJL0・129・JL64・.1289S5MHSM]Identityresponse402L5Z7800:03:45"8563夕6Z丄丄0・JLZ9•丄64•丄夕2--》丄0・1Z8・Z38.73〔GMMSH】AuChgnCiuationandcipheringrequest:40Z650400:03:47"9S34丄7丄8丄0・J.Z9・丄64•丄0・1Z8・Z38・73[GMHSH】A匸匸auh[4062S2300:03:55*0394880410.12S.23S.73—>10.129.164..12S953MHSH1Attachcoiaplete由上图我们可以看到用户从00:03:06"235开始进行第一次attachrequest,未得到系统响应，随后在00:03:44:737发起第二次请求，在00:03:47:953才attachaccepto导致附着时延增加。2.1PDP2.2.1PDP激活成功率PDP—周上下文激活统计指标如下表（数据来源时间为：2012年2月24B-2012年3月1日全天）：吋间尝试次数（排除用户原因）成功次数成功率2012-02-247848486781342799.60%2012-02-25779219277073199&90%2012-02-267647973759132099.30%2012-02-276749896668986599.10%2012-02-285624629558968899.40%2012-02-293396996338560499.70%2012-03-014921470489584299.50%一周走势图如下: PDP激活成功率100.00%99.80%99.60%99.40%99.20%99.00%98.80%98.60%98.40%98.20%PDP±下文激活请求次数43981642次，PDP±下文激活成功次数43673065次，PDP±下文激活成功率为99.30%。整体指标保持良好。对3月1号数据进行了BSC维度和小时维度的分析,其中,GZM31A、GZM04B指标相对较低；此外，晚忙时时段成功率较差。各个BSCpdp激活成功率分布如下。BSC级PDP激活成功率其中GZM31A.GZM04Bpdp激活成功率较低。3月1号0-23点各时段pooldpdp激活成功率及尝试次数分布如下。 Pool4pdp激活尝试次数及成功率100.00%99.50%99.00%98.50%98.00%iiiiiiiiiiiiiiii45000040000035000030000025000020000015000010000050000001234567891011121314151617181920212223■尝试次数-•-成功率可以看出，在晚忙时话务高峰期，PDP激活尝试次数显著增加，成功率有所下降。2.2.2失败原因分析一周内的失败原因及分布比例如下:失败原因次数失败原因占比Requestedserviceoptionnotsubscribed13589144.04%MissingorunknownAPN10830735.10%Serviceoptionnotsupported5548717.98%UserAauthenticationfailed70572.29%Insufficientresources7630.25%Networkfailure6480.21%Activationrejected,unspecified2120.07%UnknownPDPaddressorPDPtype1830.06%Invalidmandatoryinformation240.01%Protocolerror,unspecified50.00%其分布图如下: PDP激活失败原因分布■Activationrejected,unspecified■Insufficientresources■Invalidmandatoryinformation■MissingorunknownAPN■Netv/orkfailure■Protocolerror,unspecifiedRequestedserviceoptionnotsubscribediServiceoptionnotsupportedUnknownPDPaddressorPDPtype■UserAauthenticationfailed可以看出，MissingorunknownAPN、Requestedserviceoptionnotsubscribed^Serviceoptionnotsupported等原因导致的失败占比较大。2.2.2.1Requestedserviceoptionnotsubscribed分析：这种原因主要是因为用户的apn设置不合法、用户的APN无激活权限或者用户设置了静态IP地址所致,以下是Requestedserviceoptionnotsubscribed拒绝原因的流程示意图。-W|P|||~"三」三4叵RefGroup:|DefaukMeinInfoHI®阮ISequence...Acknowled...|WindowExpected...Cl83344403:14:42"6743078783345503:14:42"677307908352S903:14:43*45531568i83SZ6503:14:43"45631S69836S7103:14:43"99532108838Z6Z03:14:44"77S3288883826803:14:443288984321103:14:47*1143S22784321803:14:47"116352298469Z503:14:48"8943700784693303:14:48"8963700986174603:14:55,9964410986175003:14:55,9964410986176403:14:55*999441128638S103:14:56"8954S008囲消息参教丄0・129・160・97—>10.128・242•丄0[BSSGP]FLUSH-LL丄0.128・242・丄0.129•丄60.97[BSSGP]FLUSH-LL-ACK10.128.242.1129•丄60ZJLSIJSMMSH】ActivatePDPcontextrequest.10.129.160.97-->l0.JLZ8.242.10[GMHSM]Activat^ePDPcontextreject丄0・128・Z4Z・10—>10.1Z9・160ZlSll^MMSH]SHstatusJLO.1Z8・Z4Z・10—AJLO.129.16021S113HMSM]Activate10.129・160・97—>10.128・Z4Z・10[GMHSH]Activat:e10.128.Z42・10—>10.129.16021S11JMMSH)Act±vaze10.129.160・97―>10.128.242.10[CMHSH]Activate10.1Z8・Z4Z・10—>10・1Z9•丄6021S11JMMSH)ActivaT：e10・129・160・97―>10.128・24Z・10[GMMSH)Activate丄0•丄29・160・97—>10.128.242・4S【BSSGP】FLUSH-LL丄0・128・242・45—>丄0・129•丄6040SSSLLC]UxinuioberedPDPPDPPDPPDPPDPPDPcont.extcontextcontextcontextcontextcont.extrequest,rejectrequestrejectrequestreject.informat-ion丄0.128.242・10-->丄0・129•丄60.97[BSSGPJFLUSH-LL-ACK10.128.242.4S—>10.129•丄604OSS5^MHSH]ActivatePDPcontext.request.-InlxlSAPI:LLGMH(l)Encrypt-ion:noencrypt-ion(0)Protect-edmode:protect-ed(l)(Messagetype]:Unnumberedin.foruiat.ion(8)C/R:1N(U):78LLCLengt-h:6圉BSSGP::GPRSHult:iSlot.Class(l]:10BSSGP::BSSGPLength:SILLC:LLC:LLC:LLC:LLC:LLC:LLC: GlgISM^iProtoco^^iscriminat£^^^^MHjae^sacjieis^lOj^^^^—CMHSM::SHCause:Reqxiest.edserviceopt-ionnot.subscribed(33)IGMHSH::[Messagetype]:ActivatePDPcontextreject(67)GMHSH::Transaction/Skipid:8下表为因Requestedserviceoptionnotsubscribed而PDP激活失败超过10次的用户名单。requestedserviceoptionnotsubscr可对此类用八发送短信进行提示修改。2.2.2.2MissingorunknownAPN主要由于选项APN缺失导致，属于用户原因。具体來说有如下两种情况：•MS在做PDP激活的时候，会在上下文激活请求消息里携带请求的APN,告知网络侧自己想要访问的外部PDN代表什么。但MS可能没有在激活消息里携带请求的APT,造成网络侧也就是SGSN/GGSN不知道用户想要访问哪个外部网络，造成激活失败。•MS做激活的时候携带了请求的APN,但在SGSN做APN的DNS解析请求的时候，DNSSERVER±没有数据，不能返回正确的GGSN1P给SGSN,或者DNSSERVER根本就没有响应。造成激活失败。经过查询产生这种原因值得APN及激活尝试次数如下：APN尝试次数UNIWAP4243GWAP60(blank)573GNET30UNINET28INTERNET.DHIMOB23PDA.BELL.CA16DIGIPUB14EPC.TMOBILE.COM14BLACKBERRY.NET12如上表，UNTWAP产生的次数最多，UNTWAP.3GWAP等属于联通公司的APN,接入不了移动网络。对于刚才所列的两项可能原因的解决方法如下：1、可以在SGS"设置缺省AP7功能。或者通过额外的辅助服务器将正确的AP7信息通过短信的方式发给用户，辅助用户配置正确的APN完成激活。2、检查到DNSSERVER的连通性，确认DNSSERVER的位置。如果可能，可以在SGSN和DNS SERVER上分别用nslookup指令来解析这个八PN,看是否能得到正确的结果，以此来定位故障点。如果是TP路由的问题。需要检查TP网络的路由。 此外，在分析过程屮我们发现用户460029611136174发起PDP激活携带的APN信息为CMWAP,但是被SGSN拒绝激活达八万多次，因此怀疑其1ILR中的APN信息被删除，经查该用户为肇庆移动用户，建议进一步对其进行追踪。2.2.2.2Serviceoptionnotsupported分析：该种原因是指服务选项不支持，比如用户请求的QoS选项和用户签约的QoS不匹配。如下面的流程：*|P||仔三」h|匡RefGroup:|DefaultMainInfoClSequence.・・Acknowled...133666009:21:10"033010.128.24S・JL9--A丄0•JL29・丄60•今7ril2949]ActivatePDPcontextrec33668909:21:10*0363丄0・1Z9•丄60.97-->l0・1Z8.245・AcCivaCePDPcontextreject消息参数J-GMMSM::Delayclass:Subscribeddelayclass(0)/GMMSM::Precedenceclass:Subscribedprecedent(0)GMMSM::Peakthroughput:Subscribedpeakthryughput(0)GMMSM::Meanthroughput:besteffort(31)/GHMSM::PDPtypeorganisation:IETFAllocatedAddress(1)GMMSM:|PDP匕yp色nuiobmir":HPxr6GMMSM::DeliveryoferroneousSDUs:SubscribeddeliveryoferroneousSDUs(0)GMMSM::Deliveryorder:Subscribeddeliveryorder(0)GHMSM::Trafficclass:Subscribedtrafficclass(0)GMMSM::SDUerrorratio:SubscribedSDUerrorratio(0)GMMSM::ResidualBER:SubscribedresidualBER(O)GHMSM::Traffichandlingpriority:Subscribedtraffichandlingpriority(0)GMMSM::SourceStatisticsDescriptor:unknoxm(2)GMMSM::Signallingindication:Notoptimisedforsignallingtraffic(0)可以看到，用户请求了IPv6地址，激活返回CC32错误码。随后，该用户连续几次失败均是该原因造成:时间LACCIBSC名小区名站型冋络类型用户接入点原因值是否咸功时延是否超时2012-03-0709:21:101003612949GZM16BGPWBYQ32G460001331336175c・“pServiceoptionnotsupported否2012-03-0709:21:191003612949GZM16BGPWBYQ32G460001331336175Serviceoptionnotsnpported失败否2012-03-0709:21:261003612949GZM16BGPWBYQ32G460001331336175cw*apServiceoptionnotsupported失败否2012-03-0709:21:291003612949GZM16BGPWBYQ32G460001331336175c・“apServiceoptionnotsupported否而正确的设置应该如下图: J11Jk=i|P||[3三』叵IRefGroup:|DefaultMainInfo7827S708:07:53-640010.丄28.245・30--》丄0・丄29・160・97[GMMSM]AuCivHePDPuon七exCrequest78311808:07:53-72585丄0・129•丄60.97—>10.1Z8・[GMMSH]Au匕ivaCePDPcontextaccept消息蚤数GMMSMGl-niSMGMMSMGMMSMGMMSMGMMSMGMMSMGMMSMGMMSMGMMSMGHHSMGMMSMGMMSMGMMSM:Delayclass:Subscribeddelayclass(0):Precedenceclass:Subscribedpreceden:Peakthroughput:Subscribedpeakt-hr:Meanthroughput:besteffort(31):PDPtypwoirganisaLtioii:TETF人110亡呼€!<1:|PDPtypenuiobQf":TPv48L&d"ss(33)||(0)ghput(0)Address(1):DeliveryoferroneousSDUs:SubscribeddeliveryoferroneousSDUs(0):Deliveryorder:Without,deliveryorder("no*)(2):Trafficclass:Subscribedtrafficclass(0):SDUerrorratio:SubscribedSDUerrorratio(0):ResidualBER:SubscribedresidualBER(O):Traffichandlingpriority:Subscribedtraffichandlingpriority(0):SourceStatisticsDescriptor:unknoxm(0):Signallingindication:Notoptimisedforsignallingtraffic(0)进一步的查询表明，该原因值均是用户请求地址类型为IPv6地址导致，这些用户如下表:CC32-Serviceoptionnotsuppor也可以通过短信温馨提示用户设置方法。2.2.2.2UserAuthenticationfailed用户认证失败，也属于用户原因。如预付费用户欠费或过期是导致PDP激活失败的原因。通过平台查询，国际漫游用户欠费是导致该回复的主要原因，如我们通过平台查询到的这些用户数据：时间LACCIBSC名小区名站型网络类塑用户接入点原因值2012-02-2400:12:15944924521GZM32BD2FDLHN2G^262026660000494web.vodafone.deUserA&uthenticationfailed2012-02-2400:13:15944928884GZM32BG2FDLNN2G262028660000494wtb・vodafon•・GZM04B在当天浏览类业务成功率较低。3.1.2失败原因分析用户在进行数据业务时，业务请求是否有效主要以当时服务器所返冋的状态码來确定，如下图：上图屮，终端的[HTTP]Get请求消息发出后不久收到服务器回复的[HTTP]Response消息，该消息中携带一个StatusCode的字段，它反映了服务器当前所处的状态。如上图中该字段为“200OK,Success",即此次响应成功。据此我们可以分析服务器侧的状态，它对整个流程也 存在时延相关的影响。除此以外，XX信令分析工具还可以监视到HTTP业务的异常结束，如服务器无响应或者链路异常。即通过对业务失败原因的分析，我们将造成业务失败的原因主耍集中在下面三种情况，其占比如下：ContentCountRatio备注■Noresponse3146135578.72%时Errorstatus669476916.75%集中在4XXJL5XX连接异常18085914.53%例如fTCPIReset等消息各种原因的分布图如下:接出现异常共1808591次，比例最低。下面我们针对三种原因进行分析。3.1.2.1Noresponse(78.72%)该错误占据失败原因的第一位，即服务器无响应，如下图所示: 可以看到用户在发出请求消息后一直没有得到服务器的响应，可能此刻服务器正处于繁忙高峰期，来不及处理用户的请求消息，当然也可能是该请求消息没有到达服务器就己经丢失或者是服务器响应了该请求但是在到达Gb口前已经丢弃。因此，未响应事件跟服务器的处理、响应能力或者核心网的转发能力有很大关系，我们下面将出现该情况的SP列出來，下面的分析中会用到。服务器没有响应或者响应过慢一般会导致用户主动放弃业务请求，影响用户上网感知。这种失败情况虽然不是SP主动发起的，但却与SP的服务质量有着密切的关系。其主要表现在用户终端发起的部分"PeerRequest"消息及"UserRequest"消息。出现此种情况的SP列表如下，Ftl于数量较大，只列取了次数超过100次的SP：浏览类优化-SPNoresponse・xls3.1.2.1Errorstatus(16.75%)接下來我们來分析Gb口业务的状态信息。在HTTP业务中，0K和2XX成功响应和3XX重定向响应都表示响应成功，不再赘述。我们主要分析造成失败的状态码，对于Wapl.O协议还存在Abort原因值，Top10原因值分布如下:StatuscodeSamplesShareRatio403Forbidden230990034.50%404NotFound212953531.81%500InternalServerError104881515.67%502BadGateway3102574.63%Peerrequest2170063.24%400BadRequest1977312.95%503ServiceUnavailable1830672.73% 416RequestedRangeNotSatisfiable950271.42%Sessionhasbeendisconnected848541.27%401Unauthorized366520.55%其对应的分布图如下:失败原因比例■403Forbidden■404NotFound■500InternalServerError■502BadGateway0%■Peerrequest0%・400BadRequest°%■503ServiceUnavailable0%掘«416RequestedRangeNot9咒Satisfiable■Sessionhasbeendisconnected■401Unauthorized观察到在失败的状态码中以“404NotFound”占比最多，超过了总失败1/3,其次为"403Forbidden"及“500InternalServerError等。其中Wapl.0协议Abort原因值为uPeerrequest”及"Sessionhasbeendisconnected"的失败流程主要由用户侧主动发起中断引起。接下来我们针对失败的状态码进行深入分析。403Forbidden(34>50%)该状态码一般用于服务器端不想公布请求被拒绝的细节或没有其它的回应可用，是网站访问过程中常见的错误提示。该代码指示服务器理解客户的请求，但拒绝处理它，通常由于服务器上的文件或目录的权限设置导致。例如如果从并不允许执行程序的目录中执行CGI、ISAPI或其他执行程序就可能引起此错误。下面是示例消息流程： 可以看到，用户请求了一个門G格式的图片，但是得到的却是403错误的冋复。解决此类错误的方法在于服务器端合理设置文件或者目录的执行许可。404NotFound(31.81%)“404NotFound”提示用户终端服务器没有找到与请求URI相符的资源，属于终端侧错误，但跟SP有很大关系，下图是一个示例: 可以看到用户请求了一个不存在的图片文件，很快收到服务器的404状态回复，指示了此次浏览失败。出现类似情况一般由于SP站点服务器已经更新了页面内容，而且在大多数SP页面中会存在链接网络中的某些其它应用服务器上的Object,一旦其链接的应用服务器上的Object地址发生了改变就会造成用户侧出现“404NotFound”的情况。解决此类错误的根本方法在于服务器端及时更新或者重定向错误链接，提升服务器运行性能。服务器碰到了意外情况，使其无法继续回应请求。如果用户请求的地址为动态地址，则属于服务器解析碰到了意外情况或者是做过配置上的改动。下面是消息示例: 可以看到，终端发出Get请求消息后经过了15s才收到服务器的Response响应消息，并且携带的StatusCode字段的状态为内部服务器错误。一般情况下服务器出现了意外情况或者服务器做了以下几种改动造成:1、更改过计算机名称；2、站点所在的文件目录自定义了安全属性;3、安装了域控制器后调整了域策略。服务器管理员可以通过恢复以上设置来减少该错误的发生。我们把所有出现该类错误的服务器地址列举出来，可以建议相应服务器管理员对该问题进行修补：HostSamplesShareratioabc2299.net:8110388710.27%datacenter.5kgg.com904238.94%source.wa3.cn829558.20%t.baidugooqlestore.com:9059656646.49%t.liweihao.com:9059649896.43%su.5k3q.com582735.76%t.liweihao.com:8092468334.63%t.baidugooglestore.com:8092465564.60%ua.szyscf.net310693.07%datacenter.8jgg.net218862.16% 500Internal所有网址见文件：ServerError.xls出现这种应答码的最根本解决办法是SP站点加强维护，提升口身服务器运行性能，进而提升网络指标和用户感知度。502BadGateway(4.63%)下面是一个示例流程：在上面的流程屮，移动终端发出Get请求后35s终于收到服务器的Response响应，随后TCP层结束链接。观察Response消息携带的StatusCode可以发现不是正常的2000K,而是502BadGateway。502状态码提示用户充当网关或代理的服务器从要发送请求的上游(upstream)服务器收到非法的回应。此类错误提示通常出现在论坛登陆、网页游戏载入或视频网站启动播放器时。服务器作为网关或者代理时为了完成请求访问下一个服务器，但该服务器返回了非法的应答(比如网管使用了过滤软件)，这样就会出现此类错误。上图中，注意Response冋复距离 Get请求的时间间隔，这里是35s。通过查询返回502错误代码的数据记录，我们观察到普遍存在响应时延较大的现象。我们将这些网址列举出来，下表为ToplO：所冇网址见:502BadGateway.xlsURI尝试次数■ShareRatio118.224.5.1533850712.77%app.wolianw.com:80803425311.36%www.52dodo.com:8080223217.40%fwd.3q.qq.com:8080192786.39%smscount.qq.com96253.19%f.qq.com86622.87%sp.aplussh.com.cn74552.47%117.135.129.38:808071502.37%abc2299.net:8142451.41%txlwap.cn:808139481.31%另外如果服务器在高负荷时执行较长时间的脚本也会导致此类错误，比如php-cgi进程数不够用、php执行时问长甚至是php-cgi进程吊死等。因此，建议对上表屮出现次数较多的服务器进行更改配置文件，例如可以通过增大Cgi进程数进行测试。400BadRequest(2.95%)该状态码提示客户端如果请求的语法不对，服务器将无法理解。客户端在对该请求做出更改之前，不应再次向服务器重复发送该请求。下面是示例消息流程： 可以看到，用户的请求得到了400错误的回复。该错误一般由以下原因造成：1、在地址中可能存在键入错误；2、某个链接己过期；3、网速不稳定，而要求链接的网页存在FLASH或者大尺寸图片，造成响应过慢;4、服务器已关闭；5、DNS服务器错误。解决此类错误的方法在于服务器端及时更新链接，对用户端的错误键入进行更加有效及人性化的提示，以使用户便于理解进而及时止确地键入请求地址。503ServiceTemporarilyUnavailable(2.73%)服务器当前无法处理请求，这一般是由于服务器临时性超载或维护引起的。该状态码暗示情况是暂时性的，要产生一些延迟。下面是示例消息流程：示例图中显示了用户请求的主机地址为cgi.meigui.qq.com,104ms后返冋503错误提示。-般情况下出现下面的情况时会发生503错误提示:1、网络管理员可能关闭应用程序池以执行维护; 2、当请求到达时应用程序池队列C满;3、应用程序池标识没有使用预定义账户：网络服务，而自己配置了标识，但是配置的这个用户不属于IIS.WPG组；4、应用程序池启用了CPU监视，并且设置了CPU利用率超过一定百分比关闭应用程序池，而开发人员写的服务端页面(.asp,.aspx)执行效率不高，会引起CPU的长时间占用，最终达到设置的百分比，从而引起应用程序池关闭；5、应用程序池的性能选项卡的请求队列限制所填的数值太小，默认为1000；6、web.config的system.web/httpRunlime节点的appRequestQueueLimit属性值设置的A低。服务器管理员对以通过检查503错误日志來确定是何种原因，其日志都是记录在%Systemroot%System32LogFilesHTTPERRhttperrl.log中，其中s-reason项:1、若为AppShutdown,可能由于CPU占用率太高导致自动关闭应用程序池；2、若为AppOffline,可能是由于应用程序标识出错引起的；3、若为Disabled,可能是由于管理员手工关闭应用程序池引起的；4、若为QueueFulL可能是因为请求时应用程序池队列已满而生成该错课。服务器管理员可以对各种原因进行有针对性地排查，以减少此类错误的发生。503Service发生503失败的SP列表如下：上文中提到了5xx主要是服务器侧出现了异常，4xx表示客户端出现了异常。我们把出现4xx的终端类型做了分布，以备查用，如下表:URI尝试次数ShareRationokian70519075.26%Nokia5230474414.81%Nokia5233321243.25%NokiaC5-03170981.73%iMobeeBook167761.70%NokiaSyncMLHTTPClient164831.67%SonyEricssonW595c154351.56%NokiaN73145891.48%Nokia5800XpressMusic145241.47%SonyEricssonW995138821.41% 4xx・xls所有附件见:前面我们对5xx和4xx的状态码作了分析，了解到5xx的状态码主要跟SP服务器的状态有关，进而我们统计出所有出现5xx状态码的SP列表，发现这些SP大部分在前面未响应的SP列表中都出现过，因此可以确定它们的服务器的性能不能完全满足用户上网的业务需求，需要增加相关板件等措施进行升级处理。列表如下：浏览类优化-SP-5xx・xls3.1.2.1连接异常(4.53%)有两类典型现象屈丁•此类失败原因:一、终端发出Get请求后，在服务器冋复前便发出“Ack,Fin”消息,二、消息流程屮出现诸如“Reset”，“Ack,Reset"这类的消息。下面是一个示例消息流程:上图中，用户侧发出Get消息，27ms之后还没有收到服务器端的响应即发出“Ack,Fin”消息。“Ack,Fin”消息用來告知对端数据传送完毕，可以断开连接。上图示例很明显属于还没有传送数据即断开连接，而且是用户侧启动的。由于前后两条消息之间的时间间隔只有27ms,远低于人为的反应吋I"可，我们认为属于用户终端问题。由于数据结果中没有终端型号的记录，在此不再做深入分析。另一种连接异常是消息流中岀现Reset消息。Reset消息指定重置一个连接，一般用于复位因某种错误而引起的错误连接，例如数据包乱序、丢包。无论是终端侧还是服务器侧只耍认为本次连接不可靠都可以发出Reset消息。消息中出现Reset不一定会造成整个流程失败，但表示终端和网络的连接过程中出现了某种问题，当然可能是网络原因，也可能是终端原因。下面是一个示例消息流程： 创也IW1^1Referenced:|lP_only耳I®瓦~1660715722:03^44*1060???-->???[TCP]AckFin1660964922:03:44*13933???-->???[TCP]Ack,Push,Fin1665196822:03:44*743637???—>???[TCP]Reset在此次数据中我们观察到该消息全部由终端侧发起。一般来说，用户侧上发Reset消息有两种情况，即终端认为本次TCP连接不可靠或者用户主动放弃。不管是哪种原因，都可归为用户行为一类。经过统计，用户建立TCP连接请求的平均时间约为7s,即可以这样认为，用户发起连接后如果一直处于等待状态，则平均约7s后会主动放弃本次连接。而当网络侧认为连接不可靠时，也会发Reset复位连接。一般来说，当出现Reset后，终端重新进行Connect程即可正常进行业务传输。3.1.3业务时延下图是HTTP业务屮Method为Get的业务流程示例图: 在完成TCP握手操作之后，移动终端就和服务器建立了连接，上图中[HTTP]Response距离[HTTP]GetZl"nJ的时I"可间隔就是Get时延。它反映了服务器对用户上层请求的响应速度，响应之后即开始传输应用层数据包，我们通常讲的网页信息就是使用[HTTP]Response以及后续的[HTTP]分包传送到移动终端的。下图显示了Get响应时延的分布信息:平均响应时延平均响应时延[ms] 上图屮，Gel平均响应时延为976ms,大部分时延样本分布在Is以内，只有少许样本时延较高。3.1.4业务速率我们对13个BSC的HTTP层速率做了分布统计，从此可以看出各个BSC级业务层速率的高低关系，如下表：BSC上行[kbps]下行[kbps]947750.2924.20944848.2226.301002689.5428.159746112.2246.201003748.0950.519747127.5852.7410036331.9153.7010004204.1655.829439126.8560.0010035144.5961.919486306.1361.959731312.5164.10从上表可以看到，各BSC速率表现不一，上行速率普遍高于下行速率，且LAC-9477.9448>10026平均速率较低。 4用户行为分析4.1数据流量分布在所取的时间内，每天的总数据流量情况详细见下表:Time2012/2/21（周二）2012/2/22（周三）2012/2/23（周四）2012/2/24（周五）2012⑵25（周六）2012/2/26（周日）2012/2/27（周一）DLfMB]1077503.721181847.041197263.801107362.541080610.541084756.41977909.94ULrMB]1239276.44258482.07262095.22L238875.57230455.451229989.94210696.84可以看到，上下行数据流量比例大约为4.6:1。其对比如下图:数据流量分布图■Downlink[MB]■Uplink[MB]可见，无论是上行还是下行，周三、周四的数据流量稍高，周一和周二的数据流量稍低。经过分析，现网屮对总体数据流量贡献较大的业务主要有浏览类、IM类、邮件类等，特别是浏览类业务，对总体数据流量贡献达80%之多。接下来我们分这三种业务分别来看一周内的数据流量走势。4.1.1浏览类业务浏览类业务贡献总数据流量的80%,各天的分布情况如下图: 浏览类业务流量分布图■Volume[MB]可见，其总体走势和总数据流量走势相同，正是浏览类业务的趋势奠定了总体业务流量趋势的基础。4.1.2IM类业务IM类业务贡献总体数据流量的12%左右，各天的分布情况如下图:IM类业务流量分布图180000160000140000120000100000800006000040000200000■Volume[MB]其各天趋势和总体流量趋势略同，也是周三、周四较高，周一最低。 4.1.3邮件类业务邮件类业务各天的数据流量分布情况如下图:邮件类业务流量分布图■Volume[MB]邮件类业务流暈跟浏览类.IM类业务有所不同，虽然也是周三.周四最高，但最低的时间发生在周六、周FI,这也跟他们是非工作FI有关。4・2浏览类业务细分下图是不同Host的用户数分布图ToplO：不同Host用户数分布图6000005000004000003000002000001000000T-用户数 从上图可以看出，腾讯网拥有最多的用户数，前H立有七个都是腾讯的网址。下图是不同Host的数据流量分布图ToplO：不同Host数据流量分布图■Volume[MB]从上图我们可以看出不同网址所产生的数据流量，即腾讯新闻排在第一位，新浪网也冇三个字域名排在前十位。此外，移动自有业务手机阅读网址排在第十位。不同Host的点击次数分布图ToplO：点击次数分布图4000000035000000300000002500000020000000150000001000000050000000•点击次数 可以看出，新浪微博客户端所产生的点击次数摇摇领先，其次为手机百度、腾讯新闻等。值得注意的是，微聘业务近来发展迅猛，受用户的欢迎程度越来越高，需要给予重点关注。5总结通过网络承载指标、网络业务性能和用户行为等方面的分析可以看到，目前XX移动网络中影响用户手机上网感知的主要原因主要存在如下儿个方而：1、用户自身原因。影响用户终端ATTACH>PDP上下文激活的原因中以用户原因占比最高，即人为因素导致，需要用户配合进行检查处理。如开启GPRS业务、及时交费充值等。如用户505029903264636两天内连续发起PDP激活达六千多次，不仅占用网络资源，又影响网络指标。再如用户460029611136174在七天内发起PDP激活达八万多次,而其携带的APN为CMWAP,需要进一步确认其HLR中签约的APN信息；2、部分终端性能不佳，如发起Attach消息后紧接着发Detach消息，需要进一步测试其软件兼容性；3、GGSN忙时地址资源紧张，需要重点关注；4、无线坏境和路由配置。影响用户RA更新的主要原因以无线坏境和路由配置为主，需要重点关注相邻区域的无线覆盖及频繁割接网元的路由配置信息；5、部分SP服务性能有待提高。用户使用最多的业务为浏览类业务，从业务性能中可以看出SP服务性能对用户的使用感知影响较大，需要进行处理；6、点击次数中可见微博业务为当前用户热点业务，可以微博业务性能为切入点，进行网络性能评估和核心网/无线方面问题分析定位；v本篇内容完〉'