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

1、用户 上网感知提升工程报告XX信息技术数据业务工程组2021年3月4日目 录 TOC o 1-3 h z u HYPERLINK l _Toc319162538 1概述 PAGEREF _Toc319162538 h 4 HYPERLINK l _Toc319162539 2网络承载性能分析 PAGEREF _Toc319162539 h 4 HYPERLINK l _Toc319162540 2.1Attach PAGEREF _Toc319162540 h 4 HYPERLINK l _Toc319162541 Attach成功率 PAGEREF _Toc319162541 h 4 HYP

2、ERLINK l _Toc319162542 失败原因分析 PAGEREF _Toc319162542 h 6 HYPERLINK l _Toc319162543 Attach时延 PAGEREF _Toc319162543 h 12 HYPERLINK l _Toc319162544 2.2PDP PAGEREF _Toc319162544 h 14 HYPERLINK l _Toc319162545 PDP激活成功率 PAGEREF _Toc319162545 h 14 HYPERLINK l _Toc319162546 失败原因分析 PAGEREF _Toc319162546 h 16

3、HYPERLINK l _Toc319162547 PDP激活时延 PAGEREF _Toc319162547 h 21 HYPERLINK l _Toc319162548 2.3RAU PAGEREF _Toc319162548 h 22 HYPERLINK l _Toc319162549 RA更新成功率 PAGEREF _Toc319162549 h 22 HYPERLINK l _Toc319162550 失败原因分析 PAGEREF _Toc319162550 h 24 HYPERLINK l _Toc319162551 RA更新时延 PAGEREF _Toc319162551 h 3

4、0 HYPERLINK l _Toc319162552 2.4PS寻呼分析 PAGEREF _Toc319162552 h 31 HYPERLINK l _Toc319162553 成功率 PAGEREF _Toc319162553 h 31 HYPERLINK l _Toc319162554 触发PS寻呼的业务分布 PAGEREF _Toc319162554 h 32 HYPERLINK l _Toc319162555 响应时延 PAGEREF _Toc319162555 h 33 HYPERLINK l _Toc319162556 3网络业务性能分析 PAGEREF _Toc3191625

5、56 h 34 HYPERLINK l _Toc319162557 3.1浏览类业务 PAGEREF _Toc319162557 h 34 HYPERLINK l _Toc319162558 业务成功率 PAGEREF _Toc319162558 h 34 HYPERLINK l _Toc319162559 失败原因分析 PAGEREF _Toc319162559 h 35 HYPERLINK l _Toc319162560 业务时延 PAGEREF _Toc319162560 h 47 HYPERLINK l _Toc319162561 业务速率 PAGEREF _Toc319162561

6、h 49 HYPERLINK l _Toc319162562 4用户行为分析 PAGEREF _Toc319162562 h 50 HYPERLINK l _Toc319162563 4.1数据流量分布 PAGEREF _Toc319162563 h 50 HYPERLINK l _Toc319162564 浏览类业务 PAGEREF _Toc319162564 h 50 HYPERLINK l _Toc319162565 IM类业务 PAGEREF _Toc319162565 h 51 HYPERLINK l _Toc319162566 邮件类业务 PAGEREF _Toc319162566

7、 h 52 HYPERLINK l _Toc319162567 4.2浏览类业务细分 PAGEREF _Toc319162567 h 52 HYPERLINK l _Toc319162568 5总结 PAGEREF _Toc319162568 h 54概述本文利用XX移动现有平台数据库，结合XX软件特点，分流程对网络承载性能、网络业务性能及用户行为进行分析，重点对流程中影响用户上网的问题进行阐述、信令重现并详细分析造成失败的原因，最后对这些原因进行归纳综合提出相应的解决方法。本次数据分析采用Gb接口数据，主要分析的对象为覆盖广州地区的13个BSCGZM31A、43B4、16A、16B、43B2

8、、03B、04A、04B、32A、18A、32B、03A。以下从网络承载性能、网络业务性能、用户行为三个章节分别介绍信令流程中出现的问题并加以解析。网络承载性能分析AttachAttach成功率Attach一周性能统计指标如下表数据来源时间为：2021年2月24日-2021年3月1日全天：时间尝试次数(排除用户原因)成功次数成功率2021-02-244250675388377891.40%2021-02-254189385383365291.50%2021-02-264151944378877791.30%2021-02-273642418328780490.30%2021-02-283017

9、623275869591.40%2021-02-291919985177469292.40%2021-03-012682118246517791.90%一周走势图如下：GPRS一周附着尝试次数23854148次，附着成功次数21792575次，附着成功率为91.36%。从上图看出，Attach成功率比拟平稳，没有明显的波动。对3月1号数据进行了BSC维度和小时维度的分析，其中，GZM32B、GZM04B指标相对较低；此外，凌晨时段成功率较差。各个BSC附着成功率分布如下。可以看出，在所有BSC中，GZM32B、GZM04B3月1号attach成功率较低。3月1号0-23点各时段pool4附着成

10、功率及尝试次数分布如下。可以看出，在凌晨2-5点attach成功率较差。失败原因分析一周内的失败原因及分布比例如下：失败原因 次数 失败原因占比GPRS services not allowed 108554552.66%detach_ul 61398929.78%GPRS services not allowed in this PLMN1428446.93%Network failure841744.08%GPRS serv. & non-GPRS serv.not allowed532122.58%Invalid mandatory information 388801.89%detac

11、h_dl 321761.56%protocol error, unspecified 80180.39%MS id cannot be derived by network 22760.11%Auth_Reject 4590.02%其分布图如下：可以看出，GPRS services not allowed、GPRS services not allowed in this PLMN等原因值占比拟大。下面将对其中的几个主要拒绝原因做出信令重现并加以解析。 GPRS services not allowed分析：根据附着过程信令流程，SGSN需要到用户归属的HLR更新其位置信息。该原因值的出现代表

12、Gr接口网络层的连通性并没有问题，map消息都能正常的接收和发送。根据HLR返回的原因值，提示用户有GPRS功能但是没开通GPRS业务或者GPRS业务处于关闭状态。下面是一个GPRS services not allowed的一个流程。下表为统计出的一周内由于该原因导致Attach失败次数超过10次的用户。可以通过短信告知用户GPRS业务不可用，提醒其开通此项业务。 GPRS services not allowed in this PLMN分析：当前的PLMN 不允许GPRS效劳，即不允许漫游，主要由于用户IMSI属于其他PLMN。此外，有些国际用户虽然与移动开通了漫游来访，但如果用户本身不

13、允许漫游，也会返回该失败原因。GPRS services not allowed in this PLMN流程示意图如下所示。下表为统计出的一周内由于该原因导致Attach失败次数超过10次的用户。除了漫游受限以外，如果本地用户在HLR中的签约数据不正确也会导致该错误，如用户的APN信息被删除。根据经验，目前工作人员在关闭用户GPRS套餐时会删除APN信息，但却不关闭GPRS的功能，此时HLR上存在两个特点：GPRS功能开启APN接入点为空这就导致局部终端有附着请求，但会产生这种GPRS services not allowed in this PLMN的原因，因此建议检查上表中本地用户在HL

14、R中的APN信息。 Detach UL该原因值属于系统内部定义值，主要由于用户终端发起Attach信令后立即发Detach消息导致，下面是一个例如：可以看到，用户发起Attach时上报的MCC和MNC均为十六进制F，LAC和RAC号码也不正确，在网络发起鉴权时主动发起去附着申请。利用平台我们可以看到大局部没有较多的信息：由此推断主要由山寨机引起。经过查询，诺基亚仿,N98、苹果仿,iPhone 4这两款终端失败次数较多。所有终端在统计时间内发生该现象的次数以及其附着成功率如下表：对于发生该现象较多而且附着成功率又较低的终端，建议联系相关厂家进行进一步测试软件问题。 GPRS serv. & n

15、on-GPRS serv.not allowed不允许GPRS及非GPRS效劳，用户被停机导致，即连普通的GSM话音功能也不允许。可能是一些被用户废弃的SIM卡重新插入 开机导致。用户如下：可以通过短信告知用户已停机，提醒其及时交费充值。 Invalid mandatory information主要由于特定终端用IMEI代替IMSI或PTMSI进行Attach尝试导致，属于终端软件异常导致，经过查询，在这些异常的用户IMSI中，其中以空值和全1值居多。 Network failure网络失败，主要与Gr接口的通畅度及HLR上用户数据配置正确与否有关，当用户数据配置错误或者漫游用户的HLR返回

16、的响应消息显示不支持GPRS的所需的MAP版本时那么Attach被拒绝。也有一种情况是用户在附着申请时本身上报的信息有误，如IMSI不正确，MCC、MNC等参数不合法等，如图：IMSI不正确，MCC、MNC等参数不合法，所以SGSN返回Network failure。另外我们从用户角度分析该原因值发现有局部国际漫游用户失败次数较多，如下表：IMSI尝试次数440006103247517 1918540202505023203910240 11890530052168235288 898573所有用户如下表：除此之外，我们又从小区维度分析发生该现象的区域分布，提取出发生次数超过100次的这些小区

17、如下表：LAC-CI尝试次数10037-6543230410037-1205527810037-5204226210037-5204320510037-6543019010037-6541818610037-6540618410037-6540415210037-2409514810037-654001289449-28884113建议检查这些小区的无线环境以及漫游用户的签约数据。Attach时延Attach是进行数据业务的第一步，3GPP中关于Attach过程的信令流程如下列图所示：在Gb接口，我们取Attach Complete消息距离Attach Request消息之间的时间间隔作为At

18、tach的时延。以下为连续一周的GPRS附着时延分布图：由上图可知本次信令分析数据的ATTACH时延主要集中在3000ms以内，根本属于正常。下面我们将对采样时间段内的一个超长ATTACH时延进行举例分析：由上图我们可以看到用户从00:03:06235开始进行第一次attach request，未得到系统响应，随后在00:03:44:737发起第二次请求，在00:03:47:953才attach accept。导致附着时延增加。PDPPDP激活成功率PDP一周上下文激活统计指标如下表数据来源时间为：2021年2月24日-2021年3月1日全天：时间尝试次数(排除用户原因)成功次数成功率2021

19、-02-247848486781342799.60%2021-02-257792192770731998.90%2021-02-267647973759132099.30%2021-02-276749896668986599.10%2021-02-285624629558968899.40%2021-02-293396996338560499.70%2021-03-014921470489584299.50%一周走势图如下：PDP上下文激活请求次数43981642次，PDP上下文激活成功次数43673065次，PDP上下文激活成功率为99.30%。整体指标保持良好。对3月1号数据进行了BSC维

20、度和小时维度的分析，其中，GZM31A、GZM04B指标相对较低；此外，晚忙时时段成功率较差。各个BSC pdp激活成功率分布如下。 其中GZM31A、GZM04B pdp激活成功率较低。3月1号0-23点各时段pool4 pdp激活成功率及尝试次数分布如下。可以看出，在晚忙时话务顶峰期，PDP激活尝试次数显著增加，成功率有所下降。失败原因分析一周内的失败原因及分布比例如下：失败原因次数失败原因占比Requested service option not subscribed13589144.04%Missing or unknown APN10830735.10%Service option

21、 not supported5548717.98%User Aauthentication failed70572.29%Insufficient resources7630.25%Network failure6480.21%Activation rejected, unspecified2120.07%Unknown PDP address or PDP type1830.06%Invalid mandatory information240.01%Protocol error, unspecified50.00%其分布图如下：可以看出，Missing or unknown APN、Req

22、uested service option not subscribed、Service option not supported等原因导致的失败占比拟大。 Requested service option not subscribed分析：这种原因主要是因为用户的apn设置不合法、用户的APN无激活权限或者用户设置了静态IP地址所致，以下是Requested service option not subscribed 拒绝原因的流程示意图。下表为因Requested service option not subscribed而PDP激活失败超过10次的用户名单。可对此类用户发送短信进行提示修

23、改。 Missing or unknown APN主要由于选项APN缺失导致，属于用户原因。具体来说有如下两种情况：MS在做PDP激活的时候，会在上下文激活请求消息里携带请求的APN，告知网络侧自己想要访问的外部PDN代表什么。但MS可能没有在激活消息里携带请求的APN，造成网络侧也就是SGSN/GGSN不知道用户想要访问哪个外部网络，造成激活失败。MS做激活的时候携带了请求的APN，但在SGSN做APN的DNS解析请求的时候，DNS SERVER上没有数据，不能返回正确的GGSN IP给SGSN，或者DNS SERVER根本就没有响应。造成激活失败。经过查询产生这种原因值得APN及激活尝试次

24、数如下：APN尝试次数UNIWAP4243GWAP60(blank)573GNET30UNINET28INTERNET.DHIMOBLIE2316DIGIPUB1414BLACKBERRY.NET12如上表，UNIWAP产生的次数最多，UNIWAP、3GWAP等属于联通公司的APN，接入不了移动网络。对于刚刚所列的两项可能原因的解决方法如下：1、 可以在SGSN设置缺省APN功能。或者通过额外的辅助效劳器将正确的APN信息通过短信的方式发给用户，辅助用户配置正确的APN完成激活。2、检查到DNS SERVER的连通性，确认DNS SERVER的位置。如果可能，可以在SGSN和DNS SERVE

25、R上分别用nslookup指令来解析这个APN，看是否能得到正确的结果，以此来定位故障点。如果是IP路由的问题。需要检查IP网络的路由。此外，在分析过程中我们发现用户460029611136174发起PDP激活携带的APN信息为CMWAP，但是被SGSN拒绝激活达八万屡次，因此疑心其HLR中的APN信息被删除，经查该用户为肇庆移动用户，建议进一步对其进行追踪。 Service option not supported分析：该种原因是指效劳选项不支持，比方用户请求的QoS选项和用户签约的QoS不匹配。如下面的流程：可以看到，用户请求了IPv6地址，激活返回CC32错误码。随后，该用户连续几次失败

26、均是该原因造成：而正确的设置应该如下列图：进一步的查询说明，该原因值均是用户请求地址类型为IPv6地址导致，这些用户如下表：也可以通过短信温馨提示用户设置方法。 User Authentication failed用户认证失败，也属于用户原因。如预付费用户欠费或过期是导致PDP激活失败的原因。通过平台查询，国际漫游用户欠费是导致该回复的主要原因，如我们通过平台查询到的这些用户数据：可以看到，用户设置的APN如yesinternet，等，我们进一步提取了这些用户及其设定的APN信息，发现在7057次失败中用户505029903264636奉献了6378次，占该原因值的90%。从其网络代码可以看出

27、该用户为澳大利亚用户，而且该用户在2021-2-27日到28日不断发起PDP激活消息均被SGSN拒绝，原因值相同，如此频繁地向网络发起连接不仅占用无线资源，还影响网络指标，建议通过短信通知用户及时交费充值，提升用户感知。下面是产生该原因值的用户的详细信息：PDP激活时延3GPP中关于PDP上下文激活过程的信令流程如下列图所示：我们取Activate PDP Context Accept消息距离Activate PDP Context Request消息之间的时间间隔作为PDP上下文激活的时延，以下为连续一周的PDP上下文激活时延分布图：由上图可知在数据采样时段内，用户的PDP 激活时延大局部都

28、在300ms之内。RAURA更新成功率现网13个BSC在整个数据分析时段内2012年2月21日00:00-2012年2月28日00:00的RA更新成功率及失败原因详细统计如下：原因值次数占比路由更新成58%MS id cannot be derived by network8079240.55%Implicitly detached6762070.46%Network failure6169230.42%Auth_Reject48980.00%Congestion2800.00%GPRS serv. & non-GPRS serv.not allowed520.00%

29、GPRS services not allowed230.00%No PDP context activated10.00%一周之内，RA更新成功率为98.58%，指标处于正常水平，其各天的成功率情况如下列图：2月27号全天各BSC路由区更新成功率比照方下。其中GZM18A在当天成功率较低。各失败原因Share的比例情况如下：可以看到，造成路由更新失败次数最多的原因值为MS id cannot be derived by network，其次为Implicitly detached、Network failure，这三种原因值占所有失败原因值的比例最大。失败原因分析接下来主要分析失败原因： M

30、S id cannot be derived by network分析下面是发生这种错误的信令流程例如图：可以看到，终端的路由更新请求在625ms的时间内被SGSN拒绝。一般在跨SGSN进行路由更新时，新SGSN在向旧SGSN索要SGSN上下文时，如果PURGTMR 定时器超时GMM上下文删除定时时长，那么旧SGSN已经删除了用户MM上下文，新SGSN无法获取MS用户信息；或者新SGSN根据终端上发的信息去DNS效劳器查询旧SGSN地址时出错导致例如由于割接原因但DNS配置并未更新、MS自行删除小区信息在路由更新请求消息中携带异常的参数等。3GPP协议中关于此项Cause值的描述如下：The

31、MS shall set the GPRS update status to GU2 NOT UPDATED (and shall store it according to subclause .2), enter the state GMM-DEREGISTERED, and shall delete any P-TMSI, P-TMSI signature, RAI and GPRS ciphering key sequence number. Subsequently, the MS may automatically initiate the GPRS attach procedur

32、e.因此，发生这种错误的主要原因可能是当用户进行跨SGSN路由区更新时，核心网通过终端原来所处的SGSN识别终端，新SGSN向原SGSN索取用户信息，但是原SGSN没有用户信息或已删除，造成网络不能识别用户。可能两个SGSN之间的用户信息有误导致新SGSN不能识别用户，也可能是两个SGSN之间存在网络故障和拥塞。处理此类问题应当检查现网是否有频繁割接的区域、更新DNS路由配置信息。在采样时间段内，共发现有以下位置区域因此种错误导致路由区更新失败：源LAC目标LAC目标CI尝试次数1004194863873281497319486171655651004194863873252994409439

33、49199428100049747215013749439100363754731010041948645164249100049747215022431032210026328042219731100363386412910004974726459113建议局方对以上区域的路由信息进行核查。 Implicitly detached分析Implicitly detached隐式别离是指SGSN不发送任何消息通知MS的情况下把用户状态置为不可及，一般由于Mobile Reachable Timer超时、终端当时所处的无线环境较差没有发周期性RA更新造成。下面是一个隐含分析的例如：可以看到，用户发

34、起RA更新后6ms的时间内就收到了网络下发的RA更新拒绝消息，Cause值为Implicitly detached。建议检查CHRCall History Record日志，一般CHR日志的失败原因中，“Implicitly detached的CHR失败码包括“IMPLICITY_DETACHED，“MM_GN_RET_MS_DETACHED， “GN_RET_IMSI_UNKNOWN和“PEER_SGSN_NO_RSP。现在对三种情况分别加以说明：1、GN_RET_MS_DETACHED：用户在旧SGSN里已被隐式别离，但该用户还认为自己附着在网络中，到新的SGSN就发起了Inter RAU

35、，旧SGSN上找不到用户上下文的情况下，旧SGSN认为用户已经被别离，返回SGSN CONTEXT RESPONSE消息中携带原因值为MS DETACHED，新SGSN于是返回用户隐式别离。2、GN_RET_IMSI_UNKNOWN：SGSN解析到MS之前所在OLD SGSN后，向OLD SGSN取用户上下文失败。分两种情况：第一种情况是DNS效劳器对用户Inter RAU带上来的OLD RAI解析对应SGSN的IP地址有误，这样新SGSN找到的老SGSN并非用户Inter RAU前所在的SGSN，也就无法找到用户上下文，老SGSN 向新SGSN返回的SGSN CONTEXT RESPONSE

36、消息中携带失败原因值“IMSI NOT KNOWN，对端SGSN没有MS的信息，所以新SGSN返回隐式别离。第二种情况是当PURGTMR 定时器超时后GMM上下文删除定时时长，SGSN彻底删除用户的上下文信息，此时如果用户发起INTER RAU，由于旧的SGSN里已经没有用户的上下文信息了，返回“RET_IMSI_UNKNOWN的失败原因。3、PEER_SGSN_NO_RSP：新SGSN需要向老的SGSN发出SGSN上下文请求包含原RAI、TLLI、原P-TMSI签名或IMSI、新SGSN地址，以获得该MS的MM上下文和PDP上下文。但由于新SGSN到旧SGSN的Gn接口链路原因，导致无法获取

37、MS的上下文。优化思路：对于IMPLICITY_DETACHED，“MM_GN_RET_MS_DETACHED，如果因移动可及定时器超时导致的隐式别离，适当延长移动可及定时器取值。对于“GN_RET_IMSI_UNKNOWN， 分析CHR原因值失败记录，整理路由区列表，建议到DNS核查这些路由区是否正确配置了路由到归属SGSN IP地址的解析数据。对于“PEER_SGSN_NO_RSP，建议检查新SGSN到旧SGSN的链路状态是否正常。 Network failure分析网络失败，根据以前的分析经验，出现这种拒绝原因主要是网络屡次请求用户协商底层传输参数时，没有得到用户的响应，最后网络拒绝了用

38、户的路由更新请求。下面是一个Network failure流程：如下图，用户上发路由更新请求后，网络连续下发LLCU Exchange identification消息均没有得到终端响应，随即网络下发路由更新拒绝消息，Cause值为Network failure。注意到随后的消息为BSSGPRADIO-STATUS，该消息携带的参数Radio Cause为Radio contact lost with the MS，即移动终端跟网络的连接丧失。3GPP中关于该参数的解释如下，详见3GPP TS 48018 7.3 Radio Status procedure节：A BSS and an MS

39、radio interface communication status may change due to the following:1)the MS goes out of coverage and is lost;This condition is signalled by setting the Radio Cause value to Radio contact lost with MS.2)the link quality is too bad to continue the communication;This condition is signalled by setting

40、 the Radio Cause value to Radio link quality insufficient to continue communication.Conditions 1) and 2) indicate that attempts to communicate between an MS and an SGSN via this cell should be suspended or abandoned. An SGSN shall stop sending LLC-PDUs to the cell for the MS.可见，Radio contact lost wi

41、th the MS指示的是移动终端所处位置不在覆盖区域内，也即是说终端当时所处位置存在弱覆盖或者未覆盖的情况。通过查询记录，我们发现大局部的Network failure都伴随着该消息。因此，应当主要检查用户当时所在位置的无线环境。由于信令中没有路由更新前用户所在的小区信息，我们提供下表作为参考：源LAC目的LAC尝试次数947710037257559448947711304100269747769594779448753810037947772851003697475059974710036329697471002625521002610036170610026100049941003610

42、0269019448944939910004100262939439974625310035944820794499448135944810037130可能上述区域存在局部的弱覆盖情况，建议优先检查发生次数较多的区域。 Auth_Reject分析鉴权拒绝，用户发起RA更新后网络会根据设置对用户进行鉴权，当鉴权失败时返回该消息。推测是计费数据的问题，可以让交换侧核查相关用户的数据。 GPRS serv. & non-GPRS serv.not allowed分析不允许GPRS及非GPRS效劳，用户被停机导致，即连普通的GSM话音功能也不允许。该原因值在附着章节已经分析过，不再赘述。 GPRS s

43、ervices not allowed分析GPRS业务不允许，用户有GPRS功能但是没开通GPRS业务；用户未开通GPRS效劳：NAM=NONGPRS；或者用户GPRS效劳关闭：GPRSLOCK=TRUE。该原因值在附着章节已经分析过，不再赘述。 CongestionCongestion可能由以下几方面原因造成：SGSN内的容量License到达上限；核心网设备容量缺乏 (全局性影响)；个别小区拥塞；个别用户恶意行为。我们来看一个例如流程，如下：可以看到，用户在15:15:56时发起RA更新请求，约1s后进行U Exchange identification，完成后一直没有得到SGSN的回复。

44、约11s后，SGSN发起RA更新拒绝信息，GMM层原因值为Congestion。随后终端再次发起RA更新请求，注意到后面的信令，即上图中红色方框内的LLC-DISCARDED和随后的RADIO-STATUS消息，在前面已经分析过，属于无线信号覆盖问题。由此可以推断，用户发起RA更新时所在小区存在拥塞或资源紧张，导致失败。对于上面列出的其他原因，引用爱立信的相关解决方案为：DescriptionThe processing load on the SGSN is too high.The attach limit of the SGSN has been reached. The attach

45、limit is the maximum allowed Simultaneously Attached Users (SAU), which is a parameter that is connected to product licensing.ActionInvestigate traffic load and check if Central Processing Unit (CPU)-demanding features are turned on.Check attach limit and compare with the number of attached subscrib

46、ers.系统负荷过高时可以通过调整链路、增加硬件处理资源解决。容量License到达上限时需要检查License配置，然后进一步采取措施。RA更新时延根据用户更新的新旧路由区是否位于同一个SGSN，路由区更新流程可分为Intra RAU和Inter RAU。3GPP中关于Intra RAU过程信令流程的例如图如下：我们取Routing Area Update Complete消息距离Routing Area Update Request消息之间的时间间隔作为路由区更新的时延。连续一周的路由区更新时延分布图如下：通过RA更新平均时延分布图可以看出，周一稍低，周五稍高，但总体变化不大，根本维持在1

47、.3s左右。PS寻呼分析成功率下表是广州POOL4在2月21-27日的寻呼次数及成功率相关数据：该POOL下PS寻呼成功率为80.02%，由上表可以看出该BSC的PS域寻呼成功率是正常的。触发PS寻呼的业务分布PS寻呼成功后，网络侧会下发TCP/UDP数据包，根据该消息的IP地址及其TCP/UDP端口号可以确定其业务分类。我们选取了2021-3-3日20:0021:00对触发PS寻呼的业务分布做了分析，以下是GZM16A内触发PS寻呼的业务分类及其占比表：业务次数占比QQ9967182.98%Web1760314.66%Email460.04%Fetion390.03%Others27522.

48、29%可以看到，上表中QQ业务导致的PS域寻呼比率是最高的，到达82.98%，其次为Web浏览类，占14.66%。各业务的比照图如下：同时我们也可以看到，FTP及流类应用不易造成PS寻呼，这也是这些应用的特点。响应时延SGSN下发Paging消息后，当收到任何LLC层的响应消息时那么认为本次寻呼成功，该消息距离Paging消息的时间间隔即为响应时延。XX移动POOL4下PS寻呼时延分布图2月27日全天数据如下：由上图可以看出寻呼响应的时延大多分布在2s以内，时延正常。网络业务性能分析浏览类业务浏览类业务在用户使用的所有业务中占据最高的比例。 Web连接建立延迟 = Web效劳器开始发送第一个数

49、据包的时间 - 用户终端发出 请求消息 ( Request) 的时间这段时间包括发送请求消息到Web效劳器的时间，Web效劳器处理请求，并对请求做出回应的时间。业务成功率在统计的时间内，浏览类业务的成功率如下表所示：请求次数成功次数成功率60195695156199223693.36%从上表可以看到，浏览类业务的成功率为93.36%，下面是其连续一周的成功率分布图：可以看到，一周内的浏览类业务请求次数略有变化，其成功率也略有起伏，根本变化不大。2月27号全天各BSC浏览类业务成功率比照方下。其中GZM32A、GZM43B4、GZM04B在当天浏览类业务成功率较低。失败原因分析用户在进行数据业务

50、时，业务请求是否有效主要以当时效劳器所返回的状态码来确定，如下列图： 上图中，终端的 Get请求消息发出后不久收到效劳器回复的 Response消息，该消息中携带一个Status Code的字段，它反映了效劳器当前所处的状态。如上图中该字段为“200 OK, Success，即此次响应成功。据此我们可以分析效劳器侧的状态，它对整个流程也存在时延相关的影响。除此以外，XX信令分析工具还可以监视到 业务的异常结束，如效劳器无响应或者链路异常。即通过对业务失败原因的分析，我们将造成业务失败的原因主要集中在下面三种情况，其占比方下：ContentCountRatio备注No response31461

51、35578.72%超时Error status669476916.75%集中在4XX和5XX连接异常18085914.53%例如TCPReset等消息各种原因的分布图如下：可以看到，失败主要由未响应造成，约占了总体的79%，其次为状态错误，占据17%，连接出现异常共1808591次，比例最低。下面我们针对三种原因进行分析。No response(78.72%)该错误占据失败原因的第一位，即效劳器无响应，如下列图所示：可以看到用户在发出请求消息后一直没有得到效劳器的响应，可能此刻效劳器正处于繁忙顶峰期，来不及处理用户的请求消息，当然也可能是该请求消息没有到达效劳器就已经丧失或者是效劳器响应了该请

52、求但是在到达Gb口前已经丢弃。因此，未响应事件跟效劳器的处理、响应能力或者核心网的转发能力有很大关系，我们下面将出现该情况的SP列出来，下面的分析中会用到。效劳器没有响应或者响应过慢一般会导致用户主动放弃业务请求，影响用户上网感知。这种失败情况虽然不是SP主动发起的，但却与SP的效劳质量有着密切的关系。其主要表现在用户终端发起的局部“Peer Request消息及“User Request消息。出现此种情况的SP列表如下，由于数量较大，只列取了次数超过100次的SP：Error status(16.75%)接下来我们来分析Gb口业务的状态信息。在 业务中，OK和2XX成功响应和3XX重定向响应

53、都表示响应成功，不再赘述。我们主要分析造成失败的状态码，对于Wap1.0协议还存在Abort原因值，Top10原因值分布如下：Status codeSamplesShare Ratio403 Forbidden230990034.50%404 Not Found212953531.81%500 Internal Server Error104881515.67%502 Bad Gateway3102574.63%Peer request2170063.24%400 Bad Request1977312.95%503 Service Unavailable1830672.73%416 Reque

54、sted Range Not Satisfiable950271.42%Session has been disconnected848541.27%401 Unauthorized366520.55%其对应的分布图如下：观察到在失败的状态码中以“404 Not Found占比最多，超过了总失败1/3，其次为“403 Forbidden及“500 Internal Server Error等。其中Wap1.0协议Abort原因值为“Peer request 及“Session has been disconnected的失败流程主要由用户侧主动发起中断引起。接下来我们针对失败的状态码进行深入分

55、析。403 Forbidden(34.50%)该状态码一般用于效劳器端不想公布请求被拒绝的细节或没有其它的回应可用，是网站访问过程中常见的错误提示。该代码指示效劳器理解客户的请求，但拒绝处理它，通常由于效劳器上的文件或目录的权限设置导致。例如如果从并不允许执行程序的目录中执行 CGI、ISAPI或其他执行程序就可能引起此错误。下面是例如消息流程：可以看到，用户请求了一个PNG格式的图片，但是得到的却是403错误的回复。解决此类错误的方法在于效劳器端合理设置文件或者目录的执行许可。404 Not Found(31.81%)“404 Not Found提示用户终端效劳器没有找到与请求URI相符的资

56、源，属于终端侧错误，但跟SP有很大关系，下列图是一个例如：可以看到用户请求了一个不存在的图片文件，很快收到效劳器的404状态回复，指示了此次浏览失败。出现类似情况一般由于SP站点效劳器已经更新了页面内容，而且在大多数SP页面中会存在链接网络中的某些其它应用效劳器上的Object，一旦其链接的应用效劳器上的Object地址发生了改变就会造成用户侧出现“404 Not Found的情况。解决此类错误的根本方法在于效劳器端及时更新或者重定向错误链接，提升效劳器运行性能。500 Internal Server Error(15.67%)效劳器碰到了意外情况，使其无法继续回应请求。如果用户请求的地址为动

57、态地址，那么属于效劳器解析碰到了意外情况或者是做过配置上的改动。下面是消息例如：可以看到，终端发出Get请求消息后经过了15s才收到效劳器的Response响应消息，并且携带的Status Code字段的状态为内部效劳器错误。一般情况下效劳器出现了意外情况或者效劳器做了以下几种改动造成：1、更改正计算机名称；2、站点所在的文件目录自定义了平安属性；3、安装了域控制器后调整了域策略。效劳器管理员可以通过恢复以上设置来减少该错误的发生。我们把所有出现该类错误的效劳器地址列举出来，可以建议相应效劳器管理员对该问题进行修补：HostSamplesShare ratio:8110388710.27%90

58、4238.94%829558.20%t.baidugooglestore :9059656646.49%t.liweihao :9059649896.43%582735.76%t.liweihao :8092468334.63%t.baidugooglestore :8092465564.60%310693.07%218862.16%所有网址见文件： 出现这种应答码的最根本解决方法是SP站点加强维护，提升自身效劳器运行性能，进而提升网络指标和用户感知度。502 Bad Gateway(4.63%)下面是一个例如流程：在上面的流程中，移动终端发出Get请求后35s终于收到效劳器的Response

59、响应，随后TCP层结束链接。观察Response消息携带的Status Code可以发现不是正常的200 OK，而是502 Bad Gateway。502状态码提示用户充当网关或代理的效劳器从要发送请求的上游upstream效劳器收到非法的回应。此类错误提示通常出现在论坛登陆、网页游戏载入或视频网站启动播放器时。效劳器作为网关或者代理时为了完成请求访问下一个效劳器，但该效劳器返回了非法的应答比方网管使用了过滤软件，这样就会出现此类错误。上图中，注意Response回复距离Get请求的时间间隔，这里是35s。通过查询返回502错误代码的数据记录，我们观察到普遍存在响应时延较大的现象。我们将这些网

60、址列举出来，下表为Top10：URI尝试次数Share Ratio3850712.77%app.wolianw :80803425311.36% 52dodo :8080223217.40%fwd.3g.qq :8080192786.39%96253.19%86622.87%74552.47%8:808071502.37%:8142451.41%txlwap :808139481.31%所有网址见： 另外如果效劳器在高负荷时执行较长时间的脚本也会导致此类错误，比方php-cgi进程数不够用、php执行时间长甚至是php-cgi进程吊死等。因此，建议对上表中出现次数较多的效劳器进行更改配置文件，