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

'用户手机上网感知提升项目报告XX信息技术有限公司数据业务项目组2012年3月4日54/54 目录1概述42网络承载性能分析42.1Attach42.1.1Attach成功率42.1.2失败原因分析62.1.3Attach时延122.2PDP142.2.1PDP激活成功率142.2.2失败原因分析162.2.3PDP激活时延212.3RAU222.3.1RA更新成功率222.3.2失败原因分析242.3.3RA更新时延302.4PS寻呼分析312.4.1成功率312.4.2触发PS寻呼的业务分布322.4.3响应时延333网络业务性能分析343.1浏览类业务343.1.1业务成功率343.1.2失败原因分析353.1.3业务时延473.1.4业务速率494用户行为分析504.1数据流量分布504.1.1浏览类业务504.1.2IM类业务514.1.3邮件类业务5254/54 4.2浏览类业务细分525总结5454/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月24日-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%一周走势图如下：54/54 GPRS一周附着尝试次数23854148次，附着成功次数21792575次，附着成功率为91.36%。从上图看出，Attach成功率比较平稳，没有明显的波动。对3月1号数据进行了BSC维度和小时维度的分析，其中，GZM32B、GZM04B指标相对较低；此外，凌晨时段成功率较差。各个BSC附着成功率分布如下。可以看出，在所有BSC中，GZM32B、GZM04B3月1号attach成功率较低。3月1号0-23点各时段pool4附着成功率及尝试次数分布如下。54/54 可以看出，在凌晨2-5点attach成功率较差。1.1.1失败原因分析一周内的失败原因及分布比例如下：失败原因次数失败原因占比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%其分布图如下：54/54 可以看出，GPRSservicesnotallowed、GPRSservicesnotallowedinthisPLMN等原因值占比较大。下面将对其中的几个主要拒绝原因做出信令重现并加以解析。2.1.2.1GPRSservicesnotallowed分析：根据附着过程信令流程，SGSN需要到用户归属的HLR更新其位置信息。该原因值的出现代表Gr接口网络层的连通性并没有问题，map消息都能正常的接收和发送。根据HLR返回的原因值，提示用户有GPRS功能但是没开通GPRS业务或者GPRS业务处于关闭状态。下面是一个GPRSservicesnotallowed的一个流程。下表为统计出的一周内由于该原因导致Attach失败次数超过10次的用户。54/54 可以通过短信告知用户GPRS业务不可用，提醒其开通此项业务。2.1.2.2GPRSservicesnotallowedinthisPLMN分析：当前的PLMN不允许GPRS服务，即不允许漫游，主要由于用户IMSI属于其他PLMN。此外，有些国际用户虽然与移动开通了漫游来访，但如果用户本身不允许漫游，也会返回该失败原因。GPRSservicesnotallowedinthisPLMN流程示意图如下所示。下表为统计出的一周内由于该原因导致Attach失败次数超过10次的用户。除了漫游受限以外，如果本地用户在HLR中的签约数据不正确也会导致该错误，如用户的APN信息被删除。根据经验，目前工作人员在关闭用户GPRS套餐时会删除APN信息，但却不关闭GPRS的功能，此时HLR上存在两个特点：•GPRS功能开启•APN接入点为空54/54 这就导致部分终端有附着请求，但会产生这种GPRSservicesnotallowedinthisPLMN的原因，因此建议检查上表中本地用户在HLR中的APN信息。2.1.2.3DetachUL该原因值属于系统内部定义值，主要由于用户终端发起Attach信令后立即发Detach消息导致，下面是一个示例：可以看到，用户发起Attach时上报的MCC和MNC均为十六进制F，LAC和RAC号码也不正确，在网络发起鉴权时主动发起去附着申请。利用平台我们可以看到大部分没有较多的信息：54/54 由此推断主要由山寨机引起。经过查询，诺基亚[仿],N98、苹果[仿],iPhone4这两款终端失败次数较多。所有终端在统计时间内发生该现象的次数以及其附着成功率如下表：对于发生该现象较多而且附着成功率又较低的终端，建议联系相关厂家进行进一步测试软件问题。2.1.2.4GPRSserv.&non-GPRSserv.notallowed不允许GPRS及非GPRS服务，用户被停机导致，即连普通的GSM话音功能也不允许。可能是一些被用户废弃的SIM卡重新插入手机开机导致。用户如下：可以通过短信告知用户已停机，提醒其及时交费充值。2.1.2.5Invalidmandatoryinformation主要由于特定终端用IMEI代替IMSI或PTMSI进行Attach尝试导致，属于终端软件异常导致，经过查询，在这些异常的用户IMSI中，其中以空值和全1值居多。2.1.2.6Networkfailure网络失败，主要与Gr接口的通畅度及HLR上用户数据配置正确与否有关，当用户数据配置错误或者漫游用户的HLR返回的响应消息显示不支持GPRS的所需的MAP版本时则Attach被拒绝。也有一种情况是用户在附着申请时本身上报的信息有误，如IMSI不正确，MCC、MNC等参数不合法等，如图：54/54 IMSI不正确，MCC、MNC等参数不合法，所以SGSN返回Networkfailure。另外我们从用户角度分析该原因值发现有部分国际漫游用户失败次数较多，如下表：IMSI尝试次数440006103247517191840411813602445554040411020121381820250502320391024011820810349179097090530052168235288894041181007973018540411030177556773所有用户如下表：54/54 除此之外，我们又从小区维度分析发生该现象的区域分布，提取出发生次数超过100次的这些小区如下表：LAC-CI尝试次数10037-6543230410037-1205527810037-5204226210037-5204320510037-6543019010037-6541818610037-6540618410037-6540415210037-2409514810037-654001289449-28884113建议检查这些小区的无线环境以及漫游用户的签约数据。1.1.1Attach时延Attach是进行数据业务的第一步，3GPP中关于Attach过程的信令流程如下图所示：54/54 在Gb接口，我们取AttachComplete消息距离AttachRequest消息之间的时间间隔作为Attach的时延。以下为连续一周的GPRS附着时延分布图：由上图可知本次信令分析数据的ATTACH时延主要集中在3000ms以内，基本属于正常。下面我们将对采样时间段内的一个超长ATTACH时延进行举例分析：54/54 由上图我们可以看到用户从00:03:06’235开始进行第一次attachrequest，未得到系统响应，随后在00:03:44:737发起第二次请求，在00:03:47:953才attachaccept。导致附着时延增加。1.1PDP1.1.1PDP激活成功率PDP一周上下文激活统计指标如下表（数据来源时间为：2012年2月24日-2012年3月1日全天）：时间尝试次数(排除用户原因)成功次数成功率2012-02-247848486781342799.60%2012-02-257792192770731998.90%2012-02-267647973759132099.30%2012-02-276749896668986599.10%2012-02-285624629558968899.40%2012-02-293396996338560499.70%2012-03-014921470489584299.50%一周走势图如下：54/54 PDP上下文激活请求次数43981642次，PDP上下文激活成功次数43673065次，PDP上下文激活成功率为99.30%。整体指标保持良好。对3月1号数据进行了BSC维度和小时维度的分析，其中，GZM31A、GZM04B指标相对较低；此外，晚忙时时段成功率较差。各个BSCpdp激活成功率分布如下。其中GZM31A、GZM04Bpdp激活成功率较低。3月1号0-23点各时段pool4pdp激活成功率及尝试次数分布如下。54/54 可以看出，在晚忙时话务高峰期，PDP激活尝试次数显著增加，成功率有所下降。1.1.1失败原因分析一周内的失败原因及分布比例如下：失败原因次数失败原因占比Requestedserviceoptionnotsubscribed13589144.04%MissingorunknownAPN10830735.10%Serviceoptionnotsupported5548717.98%UserAauthenticationfailed70572.29%Insufficientresources7630.25%Networkfailure6480.21%Activationrejected,unspecified2120.07%UnknownPDPaddressorPDPtype1830.06%Invalidmandatoryinformation240.01%Protocolerror,unspecified50.00%其分布图如下：54/54 可以看出，MissingorunknownAPN、Requestedserviceoptionnotsubscribed、Serviceoptionnotsupported等原因导致的失败占比较大。2.2.2.1Requestedserviceoptionnotsubscribed分析：这种原因主要是因为用户的apn设置不合法、用户的APN无激活权限或者用户设置了静态IP地址所致，以下是Requestedserviceoptionnotsubscribed拒绝原因的流程示意图。54/54 下表为因Requestedserviceoptionnotsubscribed而PDP激活失败超过10次的用户名单。可对此类用户发送短信进行提示修改。2.2.2.2MissingorunknownAPN主要由于选项APN缺失导致，属于用户原因。具体来说有如下两种情况：•MS在做PDP激活的时候，会在上下文激活请求消息里携带请求的APN，告知网络侧自己想要访问的外部PDN代表什么。但MS可能没有在激活消息里携带请求的APN，造成网络侧也就是SGSN/GGSN不知道用户想要访问哪个外部网络，造成激活失败。•MS做激活的时候携带了请求的APN，但在SGSN做APN的DNS解析请求的时候，DNSSERVER上没有数据，不能返回正确的GGSNIP给SGSN，或者DNSSERVER根本就没有响应。造成激活失败。经过查询产生这种原因值得APN及激活尝试次数如下：APN尝试次数UNIWAP4243GWAP60(blank)573GNET30UNINET28INTERNET.DHIMOBLIE23PDA.BELL.CA16DIGIPUB14EPC.TMOBILE.COM14BLACKBERRY.NET12如上表，UNIWAP产生的次数最多，UNIWAP、3GWAP等属于联通公司的APN，接入不了移动网络。对于刚才所列的两项可能原因的解决方法如下：1、可以在SGSN设置缺省APN功能。或者通过额外的辅助服务器将正确的APN信息通过短信的方式发给用户，辅助用户配置正确的APN完成激活。2、检查到DNSSERVER的连通性，确认DNSSERVER的位置。如果可能，可以在SGSN和DNSSERVER上分别用nslookup指令来解析这个APN，看是否能得到正确的结果，以此来定位故障点。如果是IP路由的问题。需要检查IP网络的路由。54/54 此外，在分析过程中我们发现用户460029611136174发起PDP激活携带的APN信息为CMWAP，但是被SGSN拒绝激活达八万多次，因此怀疑其HLR中的APN信息被删除，经查该用户为肇庆移动用户，建议进一步对其进行追踪。2.2.2.3Serviceoptionnotsupported分析：该种原因是指服务选项不支持，比如用户请求的QoS选项和用户签约的QoS不匹配。如下面的流程：可以看到，用户请求了IPv6地址，激活返回CC32错误码。随后，该用户连续几次失败均是该原因造成：而正确的设置应该如下图：54/54 进一步的查询表明，该原因值均是用户请求地址类型为IPv6地址导致，这些用户如下表：也可以通过短信温馨提示用户设置方法。2.2.2.4UserAuthenticationfailed用户认证失败，也属于用户原因。如预付费用户欠费或过期是导致PDP激活失败的原因。通过平台查询，国际漫游用户欠费是导致该回复的主要原因，如我们通过平台查询到的这些用户数据：可以看到，用户设置的APN如yesinternet，web.vodafone.de等，我们进一步提取了这些用户及其设定的APN信息，发现在7057次失败中用户50502990326463654/54 贡献了6378次，占该原因值的90%。从其网络代码可以看出该用户为澳大利亚用户，而且该用户在2012-2-27日到28日不断发起PDP激活消息均被SGSN拒绝，原因值相同，如此频繁地向网络发起连接不仅占用无线资源，还影响网络指标，建议通过短信通知用户及时交费充值，提升用户感知。下面是产生该原因值的用户的详细信息：1.1.1PDP激活时延3GPP中关于PDP上下文激活过程的信令流程如下图所示：我们取ActivatePDPContextAccept消息距离ActivatePDPContextRequest消息之间的时间间隔作为PDP上下文激活的时延，以下为连续一周的PDP上下文激活时延分布图：54/54 由上图可知在数据采样时段内，用户的PDP激活时延大部分都在300ms之内。1.1RAU1.1.1RA更新成功率现网13个BSC在整个数据分析时段内（2012年2月21日00:00-2012年2月28日00:00）的RA更新成功率及失败原因详细统计如下：原因值次数占比路由更新成功14597748398.58%MSidcannotbederivedbynetwork8079240.55%Implicitlydetached6762070.46%Networkfailure6169230.42%Auth_Reject48980.00%Congestion2800.00%GPRSserv.&non-GPRSserv.notallowed520.00%GPRSservicesnotallowed230.00%NoPDPcontextactivated10.00%一周之内，RA更新成功率为98.58%，指标处于正常水平，其各天的成功率情况如下图：54/54 2月27号全天各BSC路由区更新成功率对比如下。其中GZM18A在当天成功率较低。各失败原因Share的比例情况如下：54/54 可以看到，造成路由更新失败次数最多的原因值为MSidcannotbederivedbynetwork，其次为Implicitlydetached、Networkfailure，这三种原因值占所有失败原因值的比例最大。1.1.1失败原因分析接下来主要分析失败原因：2.3.2.1MSidcannotbederivedbynetwork分析下面是发生这种错误的信令流程示例图：54/54 可以看到，终端的路由更新请求在625ms的时间内被SGSN拒绝。一般在跨SGSN进行路由更新时，新SGSN在向旧SGSN索要SGSN上下文时，如果PURGTMR定时器超时（GMM上下文删除定时时长），则旧SGSN已经删除了用户MM上下文，新SGSN无法获取MS用户信息；或者新SGSN根据终端上发的信息去DNS服务器查询旧SGSN地址时出错导致（例如由于割接原因但DNS配置并未更新、MS自行删除小区信息在路由更新请求消息中携带异常的参数等）。3GPP协议中关于此项Cause值的描述如下：TheMSshallsettheGPRSupdatestatustoGU2NOTUPDATED(andshallstoreitaccordingtosubclause4.1.3.2),enterthestateGMM-DEREGISTERED,andshalldeleteanyP-TMSI,P-TMSIsignature,RAIandGPRScipheringkeysequencenumber.Subsequently,theMSmayautomaticallyinitiatetheGPRSattachprocedure.因此，发生这种错误的主要原因可能是当用户进行跨SGSN路由区更新时，核心网通过终端原来所处的SGSN识别终端，新SGSN向原SGSN索取用户信息，但是原SGSN没有用户信息或已删除，造成网络不能识别用户。可能两个SGSN之间的用户信息有误导致新SGSN不能识别用户，也可能是两个SGSN之间存在网络故障和拥塞。处理此类问题应当检查现网是否有频繁割接的区域、更新DNS路由配置信息。54/54 在采样时间段内，共发现有以下位置区域因此种错误导致路由区更新失败：源LAC目标LAC目标CI尝试次数100419486387328149731948617165565100419486387325299440943949199428100049747215013749439100363754731010041948645164249100049747215022431032210026328042219731100363386412910004974726459113建议局方对以上区域的路由信息进行核查。2.3.2.2Implicitlydetached分析Implicitlydetached（隐式分离）是指SGSN不发送任何消息通知MS的情况下把用户状态置为不可及，一般由于MobileReachableTimer超时、终端当时所处的无线环境较差没有发周期性RA更新造成。下面是一个隐含分析的示例：可以看到，用户发起RA更新后6ms的时间内就收到了网络下发的RA更新拒绝消息，Cause值为Implicitlydetached。54/54 建议检查CHR（CallHistoryRecord）日志，一般CHR日志的失败原因中，“Implicitlydetached”的CHR失败码包括“IMPLICITY_DETACHED”，“MM_GN_RET_MS_DETACHED”，“GN_RET_IMSI_UNKNOWN”和“PEER_SGSN_NO_RSP”。现在对三种情况分别加以说明：1、GN_RET_MS_DETACHED：用户在旧SGSN里已被隐式分离，但该用户还认为自己附着在网络中，到新的SGSN就发起了InterRAU，旧SGSN上找不到用户上下文的情况下，旧SGSN认为用户已经被分离，返回SGSNCONTEXTRESPONSE消息中携带原因值为MSDETACHED，新SGSN于是返回用户隐式分离。2、GN_RET_IMSI_UNKNOWN：SGSN解析到MS之前所在OLDSGSN后，向OLDSGSN取用户上下文失败。分两种情况：第一种情况是DNS服务器对用户InterRAU带上来的OLDRAI解析对应SGSN的IP地址有误，这样新SGSN找到的老SGSN并非用户InterRAU前所在的SGSN，也就无法找到用户上下文，老SGSN向新SGSN返回的SGSNCONTEXTRESPONSE消息中携带失败原因值“IMSINOTKNOWN”，对端SGSN没有MS的信息，所以新SGSN返回隐式分离。第二种情况是当PURGTMR定时器超时后（GMM上下文删除定时时长），SGSN彻底删除用户的上下文信息，此时如果用户发起INTERRAU，由于旧的SGSN里已经没有用户的上下文信息了，返回“RET_IMSI_UNKNOWN”的失败原因。3、PEER_SGSN_NO_RSP：新SGSN需要向老的SGSN发出SGSN上下文请求（包含原RAI、TLLI、原P-TMSI签名或IMSI、新SGSN地址），以获得该MS的MM上下文和PDP上下文。但由于新SGSN到旧SGSN的Gn接口链路原因，导致无法获取MS的上下文。优化思路：对于IMPLICITY_DETACHED”，“MM_GN_RET_MS_DETACHED”，如果因移动可及定时器超时导致的隐式分离，适当延长移动可及定时器取值。对于“GN_RET_IMSI_UNKNOWN”，分析CHR原因值失败记录，整理路由区列表，建议到DNS核查这些路由区是否正确配置了路由到归属SGSNIP地址的解析数据。对于“PEER_SGSN_NO_RSP”，建议检查新SGSN到旧SGSN的链路状态是否正常。2.3.2.3Networkfailure分析网络失败，根据以前的分析经验，出现这种拒绝原因主要是网络多次请求用户协商底层传输参数时，没有得到用户的响应，最后网络拒绝了用户的路由更新请求。54/54 下面是一个Networkfailure流程：如图所示，用户上发路由更新请求后，网络连续下发[LLC]UExchangeidentification消息均没有得到终端响应，随即网络下发路由更新拒绝消息，Cause值为Networkfailure。注意到随后的消息为[BSSGP]RADIO-STATUS，该消息携带的参数RadioCause为RadiocontactlostwiththeMS，即移动终端跟网络的连接丢失。3GPP中关于该参数的解释如下，详见3GPPTS480187.3RadioStatusprocedure节：ABSSandanMSradiointerfacecommunicationstatusmaychangeduetothefollowing:1)theMSgoesoutofcoverageandislost;ThisconditionissignalledbysettingtheRadioCausevalueto"RadiocontactlostwithMS".2)thelinkqualityistoobadtocontinuethecommunication;ThisconditionissignalledbysettingtheRadioCausevalueto"Radiolinkqualityinsufficienttocontinuecommunication".……Conditions1)and2)indicatethatattemptstocommunicatebetweenanMSandanSGSNviathiscellshouldbesuspendedorabandoned.AnSGSNshallstopsendingLLC-PDUstothecellfortheMS.可见，RadiocontactlostwiththeMS指示的是移动终端所处位置不在覆盖区域内，也即是说终端当时所处位置存在弱覆盖或者未覆盖的情况。通过查询记录，我们发现大部分的Networkfailure都伴随着该消息。因此，应当主要检查用户当时所在位置的无线环境。由于信令中没有路由更新前用户所在的小区信息，我们提供下表作为参考：源LAC目的LAC尝试次数54/54 9477100372575594489477113041002697477695947794487538100379477728510036974750599747100363296974710026255210026100361706100261000499410036100269019448944939910004100262939439974625310035944820794499448135944810037130可能上述区域存在局部的弱覆盖情况，建议优先检查发生次数较多的区域。2.3.2.4Auth_Reject分析鉴权拒绝，用户发起RA更新后网络会根据设置对用户进行鉴权，当鉴权失败时返回该消息。推测是计费数据的问题，可以让交换侧核查相关用户的数据。2.3.2.5GPRSserv.&non-GPRSserv.notallowed分析不允许GPRS及非GPRS服务，用户被停机导致，即连普通的GSM话音功能也不允许。该原因值在附着章节已经分析过，不再赘述。2.3.2.6GPRSservicesnotallowed分析GPRS业务不允许，用户有GPRS功能但是没开通GPRS业务；用户未开通GPRS服务：NAM=NONGPRS；或者用户GPRS服务关闭：GPRSLOCK=TRUE。该原因值在附着章节已经分析过，不再赘述。2.3.2.7CongestionCongestion可能由以下几方面原因造成：•SGSN内的容量License达到上限；•核心网设备容量不足(全局性影响)；•个别小区拥塞；•个别用户恶意行为。54/54 我们来看一个示例流程，如下：可以看到，用户在15:15:56时发起RA更新请求，约1s后进行UExchangeidentification，完成后一直没有得到SGSN的回复。约11s后，SGSN发起RA更新拒绝信息，GMM层原因值为Congestion。随后终端再次发起RA更新请求，注意到后面的信令，即上图中红色方框内的LLC-DISCARDED和随后的RADIO-STATUS消息，在前面已经分析过，属于无线信号覆盖问题。由此可以推断，用户发起RA更新时所在小区存在拥塞或资源紧张，导致失败。对于上面列出的其他原因，引用爱立信的相关解决方案为：DescriptionTheprocessingloadontheSGSNistoohigh.TheattachlimitoftheSGSNhasbeenreached.TheattachlimitisthemaximumallowedSimultaneouslyAttachedUsers(SAU),whichisaparameterthatisconnectedtoproductlicensing.ActionInvestigatetrafficloadandcheckifCentralProcessingUnit(CPU)-demandingfeaturesareturnedon.Checkattachlimitandcomparewiththenumberofattachedsubscribers.系统负荷过高时可以通过调整链路、增加硬件处理资源解决。容量License达到上限时需要检查License配置，然后进一步采取措施。1.1.1RA更新时延根据用户更新的新旧路由区是否位于同一个SGSN，路由区更新流程可分为IntraRAU和InterRAU。54/54 3GPP中关于IntraRAU过程信令流程的示例图如下：我们取RoutingAreaUpdateComplete消息距离RoutingAreaUpdateRequest消息之间的时间间隔作为路由区更新的时延。连续一周的路由区更新时延分布图如下：通过RA更新平均时延分布图可以看出，周一稍低，周五稍高，但总体变化不大，基本维持在1.3s左右。1.1PS寻呼分析1.1.1成功率下表是广州POOL4在2月21-27日的寻呼次数及成功率相关数据：54/54 该POOL下PS寻呼成功率为80.02%，由上表可以看出该BSC的PS域寻呼成功率是正常的。1.1.1触发PS寻呼的业务分布PS寻呼成功后，网络侧会下发TCP/UDP数据包，根据该消息的IP地址及其TCP/UDP端口号可以确定其业务分类。我们选取了2012-3-3日20:00~21:00对触发PS寻呼的业务分布做了分析，以下是GZM16A内触发PS寻呼的业务分类及其占比表：业务次数占比QQ9967182.98%Web1760314.66%Email460.04%Fetion390.03%Others27522.29%可以看到，上表中QQ业务导致的PS域寻呼比率是最高的，达到82.98%，其次为Web浏览类，占14.66%。各业务的对比图如下：54/54 同时我们也可以看到，FTP及流类应用不易造成PS寻呼，这也是这些应用的特点。1.1.1响应时延SGSN下发Paging消息后，当收到任何LLC层的响应消息时则认为本次寻呼成功，该消息距离Paging消息的时间间隔即为响应时延。XX移动POOL4下PS寻呼时延分布图（2月27日全天数据）如下：由上图可以看出寻呼响应的时延大多分布在2s以内，时延正常。54/54 1网络业务性能分析1.1浏览类业务浏览类业务在用户使用的所有业务中占据最高的比例。Web连接建立延迟=Web服务器开始发送第一个数据包的时间-用户终端发出HTTP请求消息(HTTPRequest)的时间这段时间包括发送请求消息到Web服务器的时间，Web服务器处理请求，并对请求做出回应的时间。1.1.1业务成功率在统计的时间内，浏览类业务的成功率如下表所示：请求次数成功次数成功率60195695156199223693.36%从上表可以看到，浏览类业务的成功率为93.36%，下面是其连续一周的成功率分布图：可以看到，一周内的浏览类业务请求次数略有变化，其成功率也略有起伏，基本变化不大。2月27号全天各BSC浏览类业务成功率对比如下。54/54 其中GZM32A、GZM43B4、GZM04B在当天浏览类业务成功率较低。1.1.1失败原因分析用户在进行数据业务时，业务请求是否有效主要以当时服务器所返回的状态码来确定，如下图：上图中，终端的[HTTP]Get请求消息发出后不久收到服务器回复的[HTTP]Response消息，该消息中携带一个StatusCode的字段，它反映了服务器当前所处的状态。如上图中该字段为“200OK,Success”54/54 ，即此次响应成功。据此我们可以分析服务器侧的状态，它对整个流程也存在时延相关的影响。除此以外，XX信令分析工具还可以监视到HTTP业务的异常结束，如服务器无响应或者链路异常。即通过对业务失败原因的分析，我们将造成业务失败的原因主要集中在下面三种情况，其占比如下：ContentCountRatio备注Noresponse3146135578.72%超时Errorstatus669476916.75%集中在4XX和5XX连接异常18085914.53%例如[TCP]Reset等消息各种原因的分布图如下：可以看到，失败主要由未响应造成，约占了总体的79%，其次为状态错误，占据17%，连接出现异常共1808591次，比例最低。下面我们针对三种原因进行分析。1.1.1.1Noresponse(78.72%)该错误占据失败原因的第一位，即服务器无响应，如下图所示：54/54 可以看到用户在发出请求消息后一直没有得到服务器的响应，可能此刻服务器正处于繁忙高峰期，来不及处理用户的请求消息，当然也可能是该请求消息没有到达服务器就已经丢失或者是服务器响应了该请求但是在到达Gb口前已经丢弃。因此，未响应事件跟服务器的处理、响应能力或者核心网的转发能力有很大关系，我们下面将出现该情况的SP列出来，下面的分析中会用到。服务器没有响应或者响应过慢一般会导致用户主动放弃业务请求，影响用户上网感知。这种失败情况虽然不是SP主动发起的，但却与SP的服务质量有着密切的关系。其主要表现在用户终端发起的部分“PeerRequest”消息及“UserRequest”消息。出现此种情况的SP列表如下，由于数量较大，只列取了次数超过100次的SP：1.1.1.1Errorstatus(16.75%)接下来我们来分析Gb口业务的状态信息。在HTTP业务中，OK和2XX成功响应和3XX重定向响应都表示响应成功，不再赘述。我们主要分析造成失败的状态码，对于Wap1.0协议还存在Abort原因值，Top10原因值分布如下：StatuscodeSamplesShareRatio403Forbidden230990034.50%404NotFound212953531.81%500InternalServerError104881515.67%502BadGateway3102574.63%Peerrequest2170063.24%400BadRequest1977312.95%503ServiceUnavailable1830672.73%54/54 416RequestedRangeNotSatisfiable950271.42%Sessionhasbeendisconnected848541.27%401Unauthorized366520.55%其对应的分布图如下：观察到在失败的状态码中以“404NotFound”占比最多，超过了总失败1/3，其次为“403Forbidden”及“500InternalServerError”等。其中Wap1.0协议Abort原因值为“Peerrequest”及“Sessionhasbeendisconnected”的失败流程主要由用户侧主动发起中断引起。接下来我们针对失败的状态码进行深入分析。403Forbidden(34.50%)该状态码一般用于服务器端不想公布请求被拒绝的细节或没有其它的回应可用，是网站访问过程中常见的错误提示。该代码指示服务器理解客户的请求，但拒绝处理它，通常由于服务器上的文件或目录的权限设置导致。例如如果从并不允许执行程序的目录中执行CGI、ISAPI或其他执行程序就可能引起此错误。下面是示例消息流程：54/54 可以看到，用户请求了一个PNG格式的图片，但是得到的却是403错误的回复。解决此类错误的方法在于服务器端合理设置文件或者目录的执行许可。404NotFound(31.81%)“404NotFound”提示用户终端服务器没有找到与请求URI相符的资源，属于终端侧错误，但跟SP有很大关系，下图是一个示例：54/54 可以看到用户请求了一个不存在的图片文件，很快收到服务器的404状态回复，指示了此次浏览失败。出现类似情况一般由于SP站点服务器已经更新了页面内容，而且在大多数SP页面中会存在链接网络中的某些其它应用服务器上的Object，一旦其链接的应用服务器上的Object地址发生了改变就会造成用户侧出现“404NotFound”的情况。解决此类错误的根本方法在于服务器端及时更新或者重定向错误链接，提升服务器运行性能。500InternalServerError(15.67%)服务器碰到了意外情况，使其无法继续回应请求。如果用户请求的地址为动态地址，则属于服务器解析碰到了意外情况或者是做过配置上的改动。下面是消息示例：54/54 可以看到，终端发出Get请求消息后经过了15s才收到服务器的Response响应消息，并且携带的StatusCode字段的状态为内部服务器错误。一般情况下服务器出现了意外情况或者服务器做了以下几种改动造成：1、更改过计算机名称；2、站点所在的文件目录自定义了安全属性；3、安装了域控制器后调整了域策略。服务器管理员可以通过恢复以上设置来减少该错误的发生。我们把所有出现该类错误的服务器地址列举出来，可以建议相应服务器管理员对该问题进行修补：HostSamplesShareratioabc2299.net:8110388710.27%datacenter.5kgg.com904238.94%source.wa3.cn829558.20%t.baidugooglestore.com:9059656646.49%t.liweihao.com:9059649896.43%su.5k3g.com582735.76%t.liweihao.com:8092468334.63%t.baidugooglestore.com:8092465564.60%ua.szyscf.net310693.07%datacenter.8jgg.net218862.16%54/54 所有网址见文件：出现这种应答码的最根本解决办法是SP站点加强维护，提升自身服务器运行性能，进而提升网络指标和用户感知度。502BadGateway(4.63%)下面是一个示例流程：在上面的流程中，移动终端发出Get请求后35s终于收到服务器的Response响应，随后TCP层结束链接。观察Response消息携带的StatusCode可以发现不是正常的200OK，而是502BadGateway。502状态码提示用户充当网关或代理的服务器从要发送请求的上游（upstream）服务器收到非法的回应。此类错误提示通常出现在论坛登陆、网页游戏载入或视频网站启动播放器时。54/54 服务器作为网关或者代理时为了完成请求访问下一个服务器，但该服务器返回了非法的应答（比如网管使用了过滤软件），这样就会出现此类错误。上图中，注意Response回复距离Get请求的时间间隔，这里是35s。通过查询返回502错误代码的数据记录，我们观察到普遍存在响应时延较大的现象。我们将这些网址列举出来，下表为Top10：URI尝试次数ShareRatio118.224.5.1533850712.77%app.wolianw.com:80803425311.36%www.52dodo.com:8080223217.40%fwd.3g.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%)该状态码提示客户端如果请求的语法不对，服务器将无法理解。客户端在对该请求做出更改之前，不应再次向服务器重复发送该请求。下面是示例消息流程：54/54 可以看到，用户的请求得到了400错误的回复。该错误一般由以下原因造成：1、在地址中可能存在键入错误；2、某个链接已过期；3、网速不稳定，而要求链接的网页存在FLASH或者大尺寸图片，造成响应过慢；4、服务器已关闭；5、DNS服务器错误。解决此类错误的方法在于服务器端及时更新链接，对用户端的错误键入进行更加有效及人性化的提示，以使用户便于理解进而及时正确地键入请求地址。503ServiceTemporarilyUnavailable(2.73%)服务器当前无法处理请求，这一般是由于服务器临时性超载或维护引起的。该状态码暗示情况是暂时性的，要产生一些延迟。下面是示例消息流程：示例图中显示了用户请求的主机地址为cgi.meigui.qq.com，104ms后返回503错误提示。一般情况下出现下面的情况时会发生503错误提示：1、网络管理员可能关闭应用程序池以执行维护；54/54 2、当请求到达时应用程序池队列已满；3、应用程序池标识没有使用预定义账户：网络服务，而自己配置了标识，但是配置的这个用户不属于IIS_WPG组；4、应用程序池启用了CPU监视，并且设置了CPU利用率超过一定百分比关闭应用程序池，而开发人员写的服务端页面（.asp,.aspx）执行效率不高，会引起CPU的长时间占用，最终达到设置的百分比，从而引起应用程序池关闭；5、应用程序池的性能选项卡的请求队列限制所填的数值太小，默认为1000；6、web.config的system.web/httpRuntime节点的appRequestQueueLimit属性值设置的太低。服务器管理员可以通过检查503错误日志来确定是何种原因，其日志都是记录在%Systemroot%System32LogFilesHTTPERRhttperr1.log中，其中s-reason项：1、若为AppShutdown，可能由于CPU占用率太高导致自动关闭应用程序池；2、若为AppOffline，可能是由于应用程序标识出错引起的；3、若为Disabled，可能是由于管理员手工关闭应用程序池引起的；4、若为QueueFull，可能是因为请求时应用程序池队列已满而生成该错误。服务器管理员可以对各种原因进行有针对性地排查，以减少此类错误的发生。发生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%54/54 所有附件见：前面我们对5xx和4xx的状态码作了分析，了解到5xx的状态码主要跟SP服务器的状态有关，进而我们统计出所有出现5xx状态码的SP列表，发现这些SP大部分在前面未响应的SP列表中都出现过，因此可以确定它们的服务器的性能不能完全满足用户上网的业务需求，需要增加相关板件等措施进行升级处理。列表如下：1.1.1.1连接异常(4.53%)有两类典型现象属于此类失败原因：一、终端发出Get请求后，在服务器回复前便发出“Ack，Fin”消息，二、消息流程中出现诸如“Reset”，“Ack，Reset”这类的消息。下面是一个示例消息流程：上图中，用户侧发出Get消息，27ms之后还没有收到服务器端的响应即发出“Ack,Fin”消息。“Ack,Fin”消息用来告知对端数据传送完毕，可以断开连接。上图示例很明显属于还没有传送数据即断开连接，而且是用户侧启动的。由于前后两条消息之间的时间间隔只有27ms，远低于人为的反应时间，我们认为属于用户终端问题。由于数据结果中没有终端型号的记录，在此不再做深入分析。54/54 另一种连接异常是消息流中出现Reset消息。Reset消息指定重置一个连接，一般用于复位因某种错误而引起的错误连接，例如数据包乱序、丢包。无论是终端侧还是服务器侧只要认为本次连接不可靠都可以发出Reset消息。消息中出现Reset不一定会造成整个流程失败，但表示终端和网络的连接过程中出现了某种问题，当然可能是网络原因，也可能是终端原因。下面是一个示例消息流程：在此次数据中我们观察到该消息全部由终端侧发起。一般来说，用户侧上发Reset消息有两种情况，即终端认为本次TCP连接不可靠或者用户主动放弃。不管是哪种原因，都可归为用户行为一类。经过统计，用户建立TCP连接请求的平均时间约为7s，即可以这样认为，用户发起连接后如果一直处于等待状态，则平均约7s后会主动放弃本次连接。而当网络侧认为连接不可靠时，也会发Reset复位连接。一般来说，当出现Reset后，终端重新进行Connect过程即可正常进行业务传输。1.1.1业务时延下图是HTTP业务中Method为Get的业务流程示例图：54/54 在完成TCP握手操作之后，移动终端就和服务器建立了连接，上图中[HTTP]Response距离[HTTP]Get之间的时间间隔就是Get时延。它反映了服务器对用户上层请求的响应速度，响应之后即开始传输应用层数据包，我们通常讲的网页信息就是使用[HTTP]Response以及后续的[HTTP]分包传送到移动终端的。下图显示了Get响应时延的分布信息：54/54 上图中，Get平均响应时延为976ms，大部分时延样本分布在1s以内，只有少许样本时延较高。1.1.1业务速率我们对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平均速率较低。54/54 1用户行为分析1.1数据流量分布在所取的时间内，每天的总数据流量情况详细见下表：Time2012/2/21(周二)2012/2/22(周三)2012/2/23(周四)2012/2/24(周五)2012/2/25(周六)2012/2/26(周日)2012/2/27(周一)DL[MB]1077503.721181847.041197263.801107362.541080610.541084756.41977909.94UL[MB]239276.44258482.07262095.22238875.57230455.45229989.94210696.84可以看到，上下行数据流量比例大约为4.6:1。其对比如下图：可见，无论是上行还是下行，周三、周四的数据流量稍高，周一和周二的数据流量稍低。经过分析，现网中对总体数据流量贡献较大的业务主要有浏览类、IM类、邮件类等，特别是浏览类业务，对总体数据流量贡献达80%之多。接下来我们分这三种业务分别来看一周内的数据流量走势。1.1.1浏览类业务浏览类业务贡献总数据流量的80%，各天的分布情况如下图：54/54 可见，其总体走势和总数据流量走势相同，正是浏览类业务的趋势奠定了总体业务流量趋势的基础。1.1.1IM类业务IM类业务贡献总体数据流量的12%左右，各天的分布情况如下图：其各天趋势和总体流量趋势略同，也是周三、周四较高，周一最低。54/54 1.1.1邮件类业务邮件类业务各天的数据流量分布情况如下图：邮件类业务流量跟浏览类、IM类业务有所不同，虽然也是周三、周四最高，但最低的时间发生在周六、周日，这也跟他们是非工作日有关。1.2浏览类业务细分下图是不同Host的用户数分布图Top10：54/54 从上图可以看出，腾讯网拥有最多的用户数，前十位有七个都是腾讯的网址。下图是不同Host的数据流量分布图Top10：从上图我们可以看出不同网址所产生的数据流量，即腾讯新闻排在第一位，新浪网也有三个字域名排在前十位。此外，移动自有业务手机阅读网址排在第十位。不同Host的点击次数分布图Top10：54/54 可以看出，新浪微博客户端所产生的点击次数摇摇领先，其次为手机百度、腾讯新闻等。值得注意的是，微博业务近来发展迅猛，受用户的欢迎程度越来越高，需要给予重点关注。1总结通过网络承载指标、网络业务性能和用户行为等方面的分析可以看到，目前XX移动网络中影响用户手机上网感知的主要原因主要存在如下几个方面：1、用户自身原因。影响用户终端ATTACH、PDP上下文激活的原因中以用户原因占比最高，即人为因素导致，需要用户配合进行检查处理。如开启GPRS业务、及时交费充值等。如用户505029903264636两天内连续发起PDP激活达六千多次，不仅占用网络资源，又影响网络指标。再如用户460029611136174在七天内发起PDP激活达八万多次，而其携带的APN为CMWAP，需要进一步确认其HLR中签约的APN信息；2、部分终端性能不佳，如发起Attach消息后紧接着发Detach消息，需要进一步测试其软件兼容性；3、GGSN忙时地址资源紧张，需要重点关注；4、无线环境和路由配置。影响用户RA更新的主要原因以无线环境和路由配置为主，需要重点关注相邻区域的无线覆盖及频繁割接网元的路由配置信息；5、部分SP服务性能有待提高。用户使用最多的业务为浏览类业务，从业务性能中可以看出SP服务性能对用户的使用感知影响较大，需要进行处理；6、点击次数中可见微博业务为当前用户热点业务，可以微博业务性能为切入点，进行网络性能评估和核心网/无线方面问题分析定位；<本篇内容完>54/54'