湖南长沙移动手机报数据业务组阶段报告

1、 .DOC资料. 湖南长沙移动手机报数据业务组阶段报告作者：日期：长沙移动手机报优化项目数据业务组阶段报告目 录 TOC o 1-3 h z u HYPERLINK l _Toc267343644 1概 述 PAGEREF _Toc267343644 h 4 HYPERLINK l _Toc267343645 2.GB口业务性能统计： PAGEREF _Toc267343645 h 6 HYPERLINK l _Toc267343646 3.GB口业务性能分析： PAGEREF _Toc267343646 h 10 HYPERLINK l _Toc267343647 3.1失败原因分析 PAG

2、EREF _Toc267343647 h 10 HYPERLINK l _Toc267343648 3.1.1用户侧发起PDP去激活分析： PAGEREF _Toc267343648 h 12 HYPERLINK l _Toc267343649 3.1.2小区更新过程分析： PAGEREF _Toc267343649 h 18 HYPERLINK l _Toc267343650 3.1.3FLUSH分析： PAGEREF _Toc267343650 h 19 HYPERLINK l _Toc267343651 3.1.4 Response非成功状态码整体统计： PAGEREF _Toc2673

3、43651 h 26 HYPERLINK l _Toc267343652 3.1.5 Response 非成功状态码失败原因分析： PAGEREF _Toc267343652 h 28 HYPERLINK l _Toc267343653 3.1.6 Radio_cause分析 PAGEREF _Toc267343653 h 35 HYPERLINK l _Toc267343654 3.1.7 Suspend过程中伴随LLC_discarded的超时失败： PAGEREF _Toc267343654 h 37 HYPERLINK l _Toc267343655 3.1.8“SUSPEND”与“R

4、ESUME” 的失败原因分析： PAGEREF _Toc267343655 h 38 HYPERLINK l _Toc267343656 3.2 SP站点排名： PAGEREF _Toc267343656 h 45 HYPERLINK l _Toc267343657 3.3手机报内容大小分析： PAGEREF _Toc267343657 h 47 HYPERLINK l _Toc267343658 3.4终端端口设置及操作流程 PAGEREF _Toc267343658 h 48 HYPERLINK l _Toc267343659 4.GB口下载速率分析： PAGEREF _Toc267343

5、659 h 50 HYPERLINK l _Toc267343660 4.1各小区手机报下载速率统计： PAGEREF _Toc267343660 h 50 HYPERLINK l _Toc267343661 4.2手机报下载速率整体分析： PAGEREF _Toc267343661 h 52 HYPERLINK l _Toc267343662 6.GB口介入性时延分析： PAGEREF _Toc267343662 h 56 HYPERLINK l _Toc267343663 6.1 Attach时延分布统计： PAGEREF _Toc267343663 h 56 HYPERLINK l _T

6、oc267343664 6.2 PDP激活时延分析： PAGEREF _Toc267343664 h 57 HYPERLINK l _Toc267343665 6.3 TCP连接时延分析： PAGEREF _Toc267343665 h 58 HYPERLINK l _Toc267343666 7 MMS测试分析： PAGEREF _Toc267343666 h 61 HYPERLINK l _Toc267343667 8EGPRS分析： PAGEREF _Toc267343667 h 68 HYPERLINK l _Toc267343668 9GN口统计分析 PAGEREF _Toc2673

7、43668 h 70 HYPERLINK l _Toc267343669 9.1 GN口业务性能评估： PAGEREF _Toc267343669 h 70 HYPERLINK l _Toc267343670 9.2GN与GB关联分析 PAGEREF _Toc267343670 h 72 HYPERLINK l _Toc267343671 9.3小结： PAGEREF _Toc267343671 h 76 HYPERLINK l _Toc267343672 10.1 MM1接口TCP连接分析 PAGEREF _Toc267343672 h 77 HYPERLINK l _Toc26734367

8、3 10.1.1 TCP连接建立过程描述 PAGEREF _Toc267343673 h 77 HYPERLINK l _Toc267343674 10.1.2 TCP连接建立时延分析 PAGEREF _Toc267343674 h 78 HYPERLINK l _Toc267343675 10.1.3 syn至ack消息时延分析： PAGEREF _Toc267343675 h 79 HYPERLINK l _Toc267343676 10.1.4 TCP连接建立成功率统计 PAGEREF _Toc267343676 h 79 HYPERLINK l _Toc267343677 10.1.5

9、异常的TCP连接统计: PAGEREF _Toc267343677 h 80 HYPERLINK l _Toc267343678 10.2 MM1口手机报接收分析 PAGEREF _Toc267343678 h 81 HYPERLINK l _Toc267343679 10.2.1 MM1口手机报接收过程描述 PAGEREF _Toc267343679 h 81 HYPERLINK l _Toc267343680 10.2.2 Get至M-retrieve.conf时延和成功率 PAGEREF _Toc267343680 h 85 HYPERLINK l _Toc267343681 11PUS

10、H接口信令分析 PAGEREF _Toc267343681 h 89 HYPERLINK l _Toc267343682 11.1 PUSH口统计分析 PAGEREF _Toc267343682 h 89 HYPERLINK l _Toc267343683 11.2 PUSH口与MM1口关联分析 PAGEREF _Toc267343683 h 90 HYPERLINK l _Toc267343684 12总 结： PAGEREF _Toc267343684 h 93引言：项目管理区域范围： 本次长沙移动GPRS手机报端到端性能优化服务涉及长沙市区的4个BSC和3个CQT点以及相关的SGSN，G

11、GSN, 1个WAPGateway和1套MMSC服务器。4个BSC如下：BSC404: BSC719: BSC728: BSC785: 1概 述湖南长沙移动手机报数据采集结构示意图如下所示：本次手机报业务数据采集主要包括4个采集点，数据业务小组分别采集长沙移动现网的GB、Gn、MM1及PUSH等接口的数据用以专题分析。2.成果综述本次项目通过GB,GN,MM1,PUSH多接口关联分析发现的主要问题有如下4类：用户自身问题：比如彩信中心地址设置错误，以及流程没有结束用户主动释放等。可以告知用户正确设置来解决。终端问题：终端协议有问题，多为山寨机。建议厂家修补bug。无线环境问题：小区无线环境差。

12、对小区进行无线环境优化。网络问题：超时、网络无响应。由于GGSN/SGSN忙时丢弃掉的消息。长沙移动手机报优化成果如下：GB口分析主要结果与发现：网络侧超时无响应，主要是用户频繁小区更新过程中网络超时无响 应。用户行为：用户主动去激活以及彩信中心地址错误。位置更新或者语音业务抢占数据业务过程中超时无响应。终端原因：终端协议问题，上报不符合规范的消息参数网络连接中断Flush成功率过低。小区更新(FLUSH)过程以及位置更新（SUSPEND）过程严重影响手机报下载速率。部分小区重传率过高。手机渗透率相对较高手机报集中下发高峰期的下载速率明显低于其他时段的手机报下载 速率，网络的负荷过重时，对手机

13、报的下载速率有着较大影响。GN口手机报成功率以及下载速率过低，GGSN繁忙无响应超时造成的手机报下载失败占比较高。Push口消息到GET消息之间平均时延为23.817S对手机报下过程中时间损耗贡献较大。SGSN响应BSC发送的GET请求时间损耗较长为5S左右。通过无线配合测试发现，定点测试过程（非移动状态）中手机报下载成功率较高，并且下载速率比较稳定。彩信中心多次给部分手机下发PUSH消息用户没有手机报提取行为发生。主要性能指标：接口成功率下载速率 GB 89.81%17.35(kps)GN 80.16%11.58(kbps)MM1 99.81%5394(kbps)PUSH 97.56%17.

14、32(kbps) 备注： 其中GB,GN接口下载速率为get request 到response消息时间差作为下载速率时间计算值。MM1接口下载速率为get request到m-retrieve-conf消息之间时间差作为下载速率时间计算值。push接口下载速率以push消息下发到MM1口收到get request消息过程时间作为计算下载速率时间差。 手机报大小均以各接口统计手机报总大小比总次数得到平均值计算得到。 接口TCP连接平均时延(MS) GB810GN998MM18接口PDP激活时延(MS) GB 174GN145由上表可以看出GN口TCP连接时间损耗最长是998ms，其次是GB口T

15、CP连接时间损耗为810MS。MM1口TCP连接时间损耗为8ms对整个手机报下载过程来说可以忽略不计。Gb口与GN口PDP激活时延相差不大。基于上述分析结果建议如下：针对用户以及终端建议如下：针对用户彩信中心地址设置错误，建议客服联系不同厂家总结彩信中心地址设置汇总，对客户进行正确的彩信中心地址设置指导。针对无线建议如下：针对语音抢占数据业务导致超时无响应，建议修改无线参数降低小区CS/PS业务量。针对网络断连的小区建议检查这些小区无线环境。对网络负荷过重建议扩容。对数据流量大且移动性能不太好的小区，即导致TBF中断的小区重选 间隔较短的小区，通过调整一些空闲模式参数，尽量减少小区重选，以提高

16、其移动性能。针对重传率较高的小区LA参数调整建议：建议LA设置为ON，在C/I 好的情况下尽可能使用高编码方式，在C/I低的情况下使用低编码方式，降低重传。 PILTIMER调整建议：Packet Idle List Timer，当一个On-Demand PDCH处于空闲状态（Idle）时，将被系统放置在PS域的空闲列表，同时PILTIMER启动，当PILTIMER超时，On-demand PDCH将返回CS域。建议设置5秒，可提早释放GSL设备，降低GSL负荷。GSL是PCU与BSS之间的信令链路，所采用的协议为LAPD协议，故GSL链路又叫GDS LAPD。在BSC侧GSL定义于GPROC

17、下，每个PCU可支持6个主用的GSL 64kbps时隙和6个冗余备份时隙，每个64kbps时隙是一个LAPD信道，两条GSL工作于负荷分担模式。网络运行维护过程中定期分析现网GSL负荷，对负荷已经达到预警门限的GSL及时采取容量调整措施可有效保障GSL始终工作于最佳状态。建议EGPRS网络开通网络辅助小区重选和GB over IP从而减少小区 重选对手机报下载速率的影响以及帧中继模式下Gb带宽不足问题。 SUSPEND、RESUME失败主要是在跨LAC，RAC，SGSN发生重选时造成 的。想要解决这一问题需要添加Gs接口。针对核心网建议如下：建议修改GGSN qos_policymap 里的参

18、数Traffic Handling Priority可以大大提高PS业务的速率。建议调整SGSN寻呼响应计时器T3313值的设置，以减少寻呼响应时 间。 建议调整SM等待GGSN响应定时器的设置，以减少等待GGSN响应create PDP context response时间。4 建议SGSN开启对GGSN进行负荷分担功能，减少GGSN繁忙时负荷过重现象。 5 为了防止个别用户激活PDP上下文后，长时间不适用PS业务而占用系统资源，GGSN应当配置最大空闲时间，在这个时间内如果用户没有流量，则可以主动去激活此PDP上下文。建议设置为15分钟。同时设置PDP上下文最大存活时间为15分钟。6 建议

19、调整GGSN未收到SGSN响应报文时的重发时间间隔值，从而减少重传率。7 建议PUSH消息按时间分散下发，避免下发集中度过高。 8 由于晚忙时下载速率以及接入性各项指标均比早忙时要差，建议手机 报 晚忙时播报时间提前一个小时播报，同时用户避开晚忙时下班路途中下载手机报，从而减少多次进行小区重选对手机报下载速率的影响。针对无线建议的提出，通过无线优化人员配合无线参数调整优化前后指标对比：优化前优化后日期长沙手机报下载速率日期长沙手机报下载速率指标同比提升6月7日11.84 7月7日12.283.73%6月8日10.28 7月8日12.1518.19%6月9日11.13 7月9日12.3310.7

20、6%6月10日11.14 7月10日12.169.20%6月11日11.04 7月11日12.2711.23%由上表可以看出优化后手机报下载速率得到明显提高。3. GB口业务性能分析：数据采集时间点：6月25日从17：00至下午20：00和6月26日从7:30到9:30。依据上述时间段内GB接口数据针对现网手机报业务的提取性能进行分析晚忙时25日（17:0019:00）4个BSC总体手机报业务性能统计概况：晚忙时手机报接收概况类别次数比例手机报提取总次数6450100.00%提取成功次数579389.81%deactivate_pdp2043.16%flush_timeout1842.85%t

21、imeout841.30%Response非2xx761.18%Radio_cause(radio contact lost with MS)340.53%suspend_timeout330.51%Reset90.14%llc_discarded_timeout330.51%从统计结果可以看出长沙移动现网中4个BSC晚忙时手机报下发总次数为6450次，成功提取次数为5793次，成功率为89.81%，主要的失败原因是timeout（超时无响应），其次是deactivate_pdp(用户去激活)以及response返回的非成功状态码，最后是radio_cause（无线原因）引起的失败。另外值得关

22、注的是timeout（超时无响应）失败中伴随flush（小区更新）的有184次占总提取次数的2.85%，伴随有suspend（语音业务抢占数据业务）的次数为33次占总提取次数的0.51%，是否由于小区更新过程中以及suspend过程中出现异常导致手机报的提取超时失败下面将进行深入分析。除此之外还有33次超时无响应是伴随有LLC-DISCARDED，虽然这种消息不一定造成手机报提取失败，但是这种消息的发生一般是因为小区无线环境差造成的。早忙时（7:309:30） 4个BSC总体手机报业务性能统计概况：早忙时手机报接收概况类别次数比例手机报提取总次数4739100.00%提取成功次数439292.

23、68%deactivate_pdp1042.19%flush_timeout831.75%timeout591.24%Response非2xx450.95%Radio_cause(radio contact lost with MS)150.32%suspend_timeout170.36%Reset60.13%llc_discarded_timeout180.38%比较早忙与晚忙统计概况，发现早忙的成功率92.68%要高于晚忙成功率89.81%。各种失败原因的所占比例排名相同，依然都是用户主动去激活以及小区更新过程中的网络超时无响应。4个BSC晚忙时（17:0019:00）手机报提取成功率统

24、计如下：BSC总提取次数提取成功次数成功率BSC4041639149991.46%BSC7191251108586.73%BSC7282061186390.39%BSC7851617145690.04%总体6568590389.88% 由上表可以看出BSC404手机报提取成功率最高2个小时内下发1639条成功提取1499条，手机报提取成功率为91.46%，BSC719手机报提取成功率最低2个小时忙时内总的下发1251条成功提取1085条，手机报提取成功率为86.73%，BSC728在2个小时忙时内总的下发次数为2061下发次数最多，成功提取1863条，提取成功率为90.39%，BSC785在2

25、个小时内总的下发1617条手机报，成功提取1456条，手机报提取成功率为90.04%。 早忙时段（7:309:30） 4个BSC手机报提取成功率统计如下：BSC总提取次数成功提取次数成功率BSC40499693393.67%BSC71976771292.83%BSC7281547141791.60%BSC7851429133093.07%总体4739439292.68%同晚忙时段统计结果对比BSC404手机报提取成功率依然最高2个小时内下发996条成功提取933条，手机报提取成功率为93.67%， BSC728在2个小时忙时内总的下发次数为1547下发次数依然最多，成功提取1417条，提取成功

26、率为91.60%，总体 提取成功率为92.68%高于晚忙时89.88%。 4个BSC晚忙时（17:0019:00）各小区手机报提取成功率统计如下：各小区按照提取次数前20名列表如下：BSClac_ci总提取次数成功次数比例M40429675_4751116415292.68%M72858358_152313012293.85%M72858358_126111510490.43%M72858358_473011099587.16%M40429675_46621069892.45%M71929675_246031017473.27%M78529643_8043968992.71%M71929675

27、_1673957174.74%M72858358_1263948590.43%M71929675_24601937782.80%M40429675_4661897685.39%M40429675_26002857891.76%M40429675_23561847488.10%M71929675_4281847690.48%M72858358_7303837286.75%M40429675_47512826781.71%M72858358_1522797392.41%M72858358_24231787393.59%M71929675_1672776280.52%M71929675_558007

28、67497.37%上表中黄色部分标出的是成功率相对较低的小区。详细列表见附件：4个BSC早忙时（7:309:30）各小区手机报提取成功率统计如下：各小区按照提取次数前20名：BSCLAC_CI总提取次数成功提取次数成功率M72858358_152313812792.03%M78529643_804311310895.58%M72858358_47301807695.00%M40429675_47511777698.70%M71929675_46242817390.12%M40429675_47512807290.00%M40429675_23561716794.37%M72858358_242

29、93736690.41%M71929675_56243686494.12%M40429675_47523605998.33%M78529643_1891605693.33%M72858358_24231575698.25%M78529643_47051595593.22%M72858358_24292565496.43%M72858358_19631605185.00%M78529643_32614949100.00%M72858358_11891514996.08%M71929675_1673524994.23%M72858358_1261604880.00%M72858358_473035

30、24790.38%上表中黄色部分标出的是成功率相对较低的小区。详细请见附件：3.1失败原因分析首先看下正常接收手机报的流程，下图为WAP手机报提取过程：手机接收彩信时，首先要和WAP网关建立连接，连接的过程与WAP上网前的连接过程相同。连接完成后，手机向WAP网关发送GET消息，里面含有彩信中心的地址及彩信的Transaction ID。WAP网关将该消息转换为HTTP消息，转发至彩信中心。正常情况下，彩信中心向WAP网关发送该条彩信(m-retrieve-conf)。WAP网关收到该彩信后，转化为WSP向手机转发该彩信。手机收到该彩信后，向WAP网关发送m-acknowledge-ind消息

31、，确认彩信已经接收完毕，WAP网关转发至彩信中心，彩信中心回复200 OK，WAP网关向手机回复WSP Reply，状态码为200 OK。手机向WAP网关发送WTP acknowledge消息，接收彩信过程完成。3.1.1用户侧发起PDP去激活分析：POST消息之前用户侧发起PDP去激活典型流程部分截图如下图：13秒第36个分包消息详细解码如下： 由于流程太长上面流程截图中忽略掉中间部分下发分包消息，从上面流程可以看出该用户在17：37:56227的时候发起PDP请求随后经过tcp连接三握手后于17:38:00729发起get请求开始下载手机报内容，随后手机报内容被分割下发，一直下发到17:3

32、8:10197时的第36个分包，我们看到第36个分包消息的详细解码，发现TCP中Finish :more data from sender,说明这不是最后一个分包消息，还有没有下发的分包消息，用户13秒钟后仍然没有收到最后一个分包消息，开始发起deactivate PDP context request ，流程失败。至于为何网络侧没有下发最后一个分包后续将关联其他接口做深入分析。2、Post 消息之后的PDP去激活失败流程分析典型流程部分截图如下：第52个分包消息的消息参数如下： 由上图可以看出手机报分割下发后，下发到第52个分包消息，通过该消息参数可以看到这个分包消息IP：total len

33、gth :823比以上所有分包消息都小，手机终端认为这个分包就是最后一个分包消息，随后向网络侧发起接收完成回应消息POST，手机接收彩信完成，post消息参数如下： 由消息参数可以看出该消息request_URI:/设置正确，可能是由于网路侧一直没有收到终端上发的POST消息，最终网络侧没有下发response 200 ok，最后用户等待14秒钟后仍然没有收到网络侧的response，所以用户发起deactivate pdp context request. 这种情况属于用户接收彩信完成，从用户侧角度来看属于提取成功，但是如果网络侧收不到post消息，不返回response 200 ok的话，

34、彩信中心认为手机报没有提取成功，将继续保留该彩信直到过期，这样势必对彩信中心SP有影响，彩信日志中会出现手机报过期没有提取的错误日志记录。对以上2种用户侧发起PDP去激活情况进行统计发现Post之前的pdp去激活147次，post之后的PDP去激活71次。POST之前的PDP去激活请求属于用户行为，从局方角度无法干涉用户主动放弃提取彩信行为，但是可以看出很大部分是由于下发过程太过漫长，以至于用户主动放弃，这需要提高手机报下载速率来解决，post之后的PDP去激则在下一步分析中与GN口关联分析，看是否是POST消息上发过程中网络侧丢包或者与手机终端有关导致网络侧没有发送response。Post

35、之后的PDP去激活手机终端型号：手机终端型号次数SAMSUNG-GT-S5230C10SAMSUNG-GT-S3650C8MAUI MMS User Agent7SonyEricssonK700c7Nokia26103Nokia26263SAMSUNG-GT-S3930C_CMCC3SAMSUNG-S8300C3SAMSUNG-SGH-L878E2SHARP2SonyEricssonW302c2Android-Mms1Bird.M111Java1LENOVO I5161LENOVO-TD9001LG-KU3111PHOENIX1PRIZM1SAMSUNG-GT-C5510U1SAMSUNG-G

36、T-M8800C1SAMSUNG-GT-S56001SAMSUNG-GT-S6700C1SAMSUNG-GT-S7070C1SAMSUNG-SGH-E8481SHARP SH6220C1SonyEricssonF305c1SonyEricssonS500i1YuLong1YuLong-Coolpad73601YuLong-CoolpadN681不难看出主要是三星手机终端出现这种情况失败，建议这些终端型号升级软件。3.1.2小区更新过程分析：典型流程如下：可以看出数据包下发过程中，进行小区更新，从而导致网络侧无响应，消息流程失败，这种原因可能跟早忙、晚忙时，上下班高峰，很多用户都在路上或者车上移

37、动，频繁进行小区更新，导致网络侧无响应超时失败。下边分析FLUSH过程对下手机报下载成功率以及下载速率的影响。 FLUSH分析： Flush过程概况统计：统计结果如下：时段消息名称次数占总FLUHS次数比例早忙时Flush-LL234279100.00%Flush-LL-ack6675528.49%晚忙时Flush-LL337835100.00%Flush-LL-ack8617125.51%由统计结果可以发现flush成功率比较低。时段Action 参数值次数占总FLUSH次数比例早忙时LLC-SDU(s) deleted6216726.54%LLC-SDU(s) transferred458

38、81.96%晚忙时LLC-SDU(s) deleted7539722.32%LLC-SDU(s) transferred107743.19%通过对SGSN回复flush消息参数action的统计发现，LLC-SDU大多数被deleted,只有一小部分被转发。在FLUSH流程中的FLUSH-ACK消息中BSSGP层中Action value参数有两个可设定的值，一个为LLC-SDU(s) transferred 另一个为LLC-SDU(s) deleted。当设置成完全是LLC-SDU(s) deleted的时候可以不返回FLUSH-ACK消息，在老的LLC-PDU也会被删除掉。 在4个BSC的

39、FLUSH流程中发现所有的参数Action value参数大部分都是LLC-SDU(s) deleted，所以有一部分FLUSH消息不被PCU相应属于正常现象，不影响网络的运行。Flush过程描述下面为3GGP里面对FLUSH流程的描述。SGSN检测到MS由于小区重选或者路由更新使得小区变更时，将向老BVCI发送一个FLUSH-LL PDU来启动一下流程：一个NSE(如一个BSS即为一个NSE)和一个路由区内部的小区变更时，存储在老BVCI(对应原小区)中的由TLLI确定的LLC-PDU要么被删除，要么被传送到与该TLLI相关联的一个新BVCI（对应新的小区）。两个NSE或两个路由区之间的小区

40、变更时，存储在老的BVCI中的由TLLI确定的LLC-PDU被删除。在FLUSH-LL PDU中，SGSN向BSSGP提供：用于识别MS的TLLI;用于识别小区的老BVCI，该小区可找到针对某个MS的缓存LLC-PDU；用于识别与MS当前相关联的小区新的BVCI（仅在同一NSE和同一路由区时）FLUSH-LL PDU中如果没有提供新BVCI，则视为删除老的BVC排队的LLC-PDU。排队的BSSGP信令，比如寻呼消息，将不受这个流程影响。作为对FLUSH-LL PDU的回应，BSS将SGSN发送一个FLUSH-LL-ACK PDU，该PDU包括：FLUSH-LL PDU中收到的TLLI；是否转

41、发（在同一NSE内）或删除LLC-PDU的指示。如果SDU指示为转发，应包含新BVCI。当SGSN收到FLUSH-LL-ACK PDU时，如果该PDU指示了与老PDU指示了与老BVC相关联的LLC-PDU已被删除，SGSN将选择如下操作之一：立即在新BVC（即新小区）上向MS重传所有未确认的LLC-PDU（在LLC确认刷新下）；按照LLC重传机制来发送未确认的LLC-PDU。当SGSN收到FLUSH-LL-ACK PDU时，该PDU指示了与老BVC相关联的LLC-PDU在NSE内转发，SGSN不必执行以上任何操作。在FLUSH-LL流程中，如果BSS能够转发缓存的LLC PDU给新BVCI，B

42、SS上下文将被保存；否则BSS上下文将被删除。原来的frame被deleted后,上层应用(TCP或WTP)会触发重发,如果重发成功的话,不会造成下载失败. 但会造成时延较大。Flush过程对手机报下载影响分析针对上文统计中手机报下载过程中，伴随flush过程的timeout失败流程进行分析。典型流程如下：由上图可以看出手机报下载过程中用户17:42:34084从小区LAC:29675；CI：26001更新到LAC:29675；CI:26002，并且Flush-LL-ACK，action value:LLC-SDU(S) deleted。由上图可以看出sequence number：317D0

43、9AE(830278062)以及 sequence number：317D0F4E(830279498)，sequence number：317D0412(830276626)均被触发重传。显然由于网络一直重传下行数据包而没有得到终端响应，最终导致超时失败。就算最终下载成功，小区更新触发重传也会对下载速率产生很大影响。发生flush的各小区统计如下：BVCILACCIflush次数103529643189319381100029643560711928910102964324472186901009296432447117648103329643189117333102729643885114

44、09510422964325163136931002296435607312035100729643804211713102829643885211182100429643476428590104129643251628436100829643804383111017296434705376541046296435304176031015296434705175991006296438041755510242964332616968100529643476436893102329675462416066详细清单见如下附件:数据包重传分析小区更新会触发下行数据包的重传，下边则对重传率进行统计。早

45、晚忙时段下行包重传率如下：时段下行传送包数下行重传包数重传率早忙时9269631760082.92%晚忙时179422719438010.83%早忙时下行数据包重传率为2.92%，晚忙时下行数据包重传率10.83%，明显高于早忙时。早忙时各小区重传率统计如下：按照重传率排名前20：BVCI重传包个数总的下行包个数重传率10677331323.32%1064352261513.46%104943463648011.91%105488398818.94%105721030546.88%10381392212896.54%10502101351695.97%10632127382775.56%103

4645%10402230415965.36%10511039243864.26%101142121023824.11%10152739722243.79%105332989123.69%10032768755323.66%103340171099263.65%10462702743303.64%10012107584433.61%10221366395473.45%10412242655023.42%详细清单见附件如下： 晚忙时各小区重传率统计如下：按照重传率排名前20：BVCI重传包次数下行包次数重传率10531039291435.66%1066355114730.95

47、%1069197027.14%1032401174023.05%10621508731720.61%10521777935019.01%102840002206618.13%104950192785118.02%104731721906016.64%101050683087116.42%101217951098316.34%104238122365416.12%106331251949316.03%101427251745815.61%102755163564115.48%101338912520715.44%101848283340714.45%100758934092514.40%1041

48、47783333914.33%103019701402814.04%：详细清单如附件：小结：针对重传率较高的小区LA参数调整建议：建议LA设置为ON，在C/I好的情况下尽可能使用高编码方式，在C/I低的情况下使用低编码方式，降低重传。对数据流量大且移动性能不太好的小区，即导致TBF中断的小区重选间隔较短的小区，通过调整一些空闲模式参数，尽量减少小区重选，以提高其移动性能，建议进行参数调整的小区如下；BSCLAC_CI手机报总提取次数手机报提取成功次数手机报提取成功率该小区FLUSH发生次数M78529643_8043968992.71%2709M72858358_1522797392.41%1

49、814M78529643_1891756181.33%11077M78529643_8042746587.84%4349M78529643_53041716185.92%2081M78529643_47051625385.48%3949M78529643_47641605896.67%2806M78529643_47642595389.83%2996M71929675_46241494489.80%3972M78529643_47643464393.48%2584M78529643_47052434093.02%2644M78529643_193134040100.00%1251M785296

50、43_3261403587.50%2567M78529643_56071383592.11%11773M78529643_24471383386.84%8964M78529643_244733636100.00%1794M7192967514%2825M78529643_23721343397.06%1295M78529643_24472333193.94%7115M78529643_1893333090.91%9715M78529643_28801292586.21%1069M78529643_1894292793.10%1492M78529643_56072262

51、492.31%1280M78529643_8041262284.62%3773M78529643_19312242291.67%1886M78529643_47053222090.91%3995M78529643_56073212095.24%5338M78529643_23723212095.24%16423.1.4 Response非成功状态码整体统计： 晚忙时各非成功状态码统计如下：error_status次数比例500 Internal Server Error6484.21%502 Bad Gateway67.89%403 Forbidden22.63%405 Method not

52、allowed22.63%400 Bad Request11.32%504 Gateway Timeout11.32%附图如下：通过统计发现主要的非成功状态码为：500 Internal Server Error占84.21%。早忙时非成功状态码分析：error_status 次数比例500 Internal Server Error3271.11%404 Not Found511.11%403 Forbidden36.67%502 Bad Gateway36.67%405 Method Not Allowed24.44%附图如下：比较早晚忙手机报提取返回非成功状态码发现主要的失败原因都是50

53、0 Internal Server Error。下边对这些非成功状态码进行深入分析。3.1.5 Response 非成功状态码失败原因分析：500 Internal Server Error分析： 典型流程截图如下：Post消息参数如下： 由上图可以看出用户发起的POST消息中彩信中心地址设置错误：host；mmsc.vnet.mobi正确的彩信中心地址应该为：。因此SGSN返回response消息中Status code :500 internal server error。另外我们发现有些彩信中心地址设置正确的消息流程也出现同样的500 internal server error,这主要是

54、由于SP不稳定，统计如下：Url_mainFrom_NumberError_Statuspost_uri3210658000/TYPE=PLMN500 Internal Server Error3210658000/TYPE=PLMN500 Internal Server Error3210658000/TYPE=PLMN500 Internal Server Error3210658000/TYPE=PLMN500 Internal Server Error3210658000/TYPE=PLMN500 Internal Server Error3210658000/TYPE=PLMN500

55、 Internal Server Error3210658000/TYPE=PLMN500 Internal Server Error发现SP均是10658000，通过分析发现10658000主要的发送内容为新闻早晚报以及三湘晨晚报，该SP下发手机报占所有下发手机报比例89.71%，所以建议提高该SP稳定性。404 Not Found分析：典型流程截图如下：Get消息参数截图如下：由上图可以看出用户发起的提取手机报的Get消息Uri main： ，不是标准的手机报地址，因此这种失败是由于用户终端请求地址上报错误，同时彩信中心地址设置也错误。统计结果如下：to_numberurl_mainerr

56、or_statuspost_urimobil_type次数8615200834633404 Not Found3MyWebClient1.02 861581111344531404 Not Found3NokiaE63-12 8613548767889404 Not Found1 这种原因属于终端原因导致错误的GET请求中的URI不是标准的彩信中心地址，建议对这种终端进行关注。502 Bad Gateway分析：典型流程如下：由上图可以看出用户向彩信中心发起get请求，url:67,在手机报提取过程中，终端往网络侧发送了一个上行包,由于彩信中心SP不接受终端发送的这种数据包所以对其进行拒绝，发

57、送response status code:502 bad geteway 。我们对这种失败进行统计，结果如下：由统计结果可以看出终端类型是MOZILLA和coolpadf800 并且彩信中心地址都是32正确的彩信中心地址应该为：。从而可以认为这是终端原因造成的。403 Forbidden典型流程如下：由上图可以看出，终端手机在18:05:54156向彩信中心发起get请求后URI main:32。然后，在18:05:54515又发起post消息其uri main :72。这个时间差小于一秒钟，随后手机又重新发起get请求，结果又在不到一秒钟的时间内，终端又向72发起post消息，网络侧拒绝，

58、发起response status code: 403 Forbidden。由此可见这是因为终端存在问题造成的失败，我们对这种终端类型统计如下：发现手机终端类型为山寨手机，建议用户更换手机。其中400 Bad Request属于彩信过期提取，由于早晚忙时数据中只出现一次，在此不在深入分析。3.1.6 Radio_cause分析典型流程如下：由上面流程图可以看出radio_status失败主要是radio contact lost with the MS，并且伴随LLC-DISCARDED，主要是无线环境差引起的，或者是处于小区边界以及小区更新过程中。对这种失败发生的小区进行统计如下表：LACC

59、I发生次数2964347643229675167322967552713229675562432583581963322964340621296432372212964324471129643325121296434764212964352661129643526721296751671129675167212967546621296751288012967524603129675260021296754751212967547513129675567521296755681315835812611583581522158358303115835846111583587303158358196

60、31158358242911583582429313.1.7 Suspend过程中伴随LLC_discarded的超时失败：典型流程部分截图如下：由消息流程可以看出手机报提取的过程中发生了Spended过程，但是随后伴随的是小区更新以及路由区更新，路由区更新完成后，一直没有resume消息恢复数据业务，最终导致超时失败。另外84次超时无响应可能存在核心网无响应，下文GB与GN口关联分析中将通过GN口关联分析具体什么原因导致核心网无响应超时。下边对SUSPEND/RESUME过程则具体分析该过程对手机报下载速率以及成功率的影响。3.1.8“SUSPEND”与“RESUME” 的失败原因分析：SU