《数据业务组总结报告.docx》由会员分享，可在线阅读，更多相关《数据业务组总结报告.docx（87页珍藏版）》请在三一办公上搜索。
1、长沙移动手机报优化项目数据业务组阶段报告目 录1概 述42.GB口业务性能统计：63.GB口业务性能分析：103.1失败原因分析103.1.1用户侧发起PDP去激活分析：123.1.2小区更新过程分析：183.1.3FLUSH分析：193.1.4 Response非成功状态码整体统计：263.1.5 Response 非成功状态码失败原因分析：283.1.6 Radio_cause分析353.1.7 Suspend过程中伴随LLC_discarded的超时失败：373.1.8“SUSPEND”与“RESUME” 的失败原因分析：383.2 SP站点排名：453.3手机报内容大小分析：473.4
2、终端端口设置及操作流程484.GB口下载速率分析：504.1各小区手机报下载速率统计：504.2手机报下载速率整体分析：526.GB口介入性时延分析：566.1 Attach时延分布统计：566.2 PDP激活时延分析：576.3 TCP连接时延分析：587 MMS测试分析：618EGPRS分析：689GN口统计分析709.1 GN口业务性能评估：709.2GN与GB关联分析729.3小结：7610.1 MM1接口TCP连接分析7710.1.1 TCP连接建立过程描述7710.1.2 TCP连接建立时延分析7810.1.3 syn至ack消息时延分析：7910.1.4 TCP连接建立成功率统计
3、7910.1.5异常的TCP连接统计:8010.2 MM1口手机报接收分析8110.2.1 MM1口手机报接收过程描述8110.2.2 Get至M-retrieve.conf时延和成功率8511PUSH接口信令分析8911.1 PUSH口统计分析8911.2 PUSH口与MM1口关联分析9012总 结：93引言：项目管理区域范围： 本次长沙移动GPRS手机报端到端性能优化服务涉及长沙市区的4个BSC和3个CQT点以及相关的SGSN，GGSN, 1个WAPGateway和1套MMSC服务器。4个BSC如下：BSC404: BSC719: BSC728: BSC785: 1概 述湖南长沙移动手机报
4、数据采集结构示意图如下所示：本次手机报业务数据采集主要包括4个采集点，数据业务小组分别采集长沙移动现网的GB、Gn、MM1及PUSH等接口的数据用以专题分析。2.成果综述本次项目通过GB,GN,MM1,PUSH多接口关联分析发现的主要问题有如下4类：1） 用户自身问题：比如彩信中心地址设置错误，以及流程没有结束用户主动释放等。可以告知用户正确设置来解决。2） 终端问题：终端协议有问题，多为山寨机。建议厂家修补bug。3） 无线环境问题：小区无线环境差。对小区进行无线环境优化。4） 网络问题：超时、网络无响应。由于GGSN/SGSN忙时丢弃掉的消息。长沙移动手机报优化成果如下：u GB口分析主要
5、结果与发现：1) 网络侧超时无响应，主要是用户频繁小区更新过程中网络超时无响 应。2) 用户行为：用户主动去激活以及彩信中心地址错误。3) 位置更新或者语音业务抢占数据业务过程中超时无响应。4) 终端原因：终端协议问题，上报不符合规范的消息参数5) 网络连接中断6) Flush成功率过低。7) 小区更新(FLUSH)过程以及位置更新（SUSPEND）过程严重影响手机报下载速率。8) 部分小区重传率过高。9) 手机渗透率相对较高u 手机报集中下发高峰期的下载速率明显低于其他时段的手机报下载 速率，网络的负荷过重时，对手机报的下载速率有着较大影响。u GN口手机报成功率以及下载速率过低，GGSN繁
6、忙无响应超时造成的手机报下载失败占比较高。u Push口消息到GET消息之间平均时延为23.817S对手机报下过程中时间损耗贡献较大。u SGSN响应BSC发送的GET请求时间损耗较长为5S左右。u 通过无线配合测试发现，定点测试过程（非移动状态）中手机报下载成功率较高，并且下载速率比较稳定。u 彩信中心多次给部分手机下发PUSH消息用户没有手机报提取行为发生。u 主要性能指标：接口成功率下载速率 GB 89.81%17.35(kps)GN 80.16%11.58(kbps)MM1 99.81%5394(kbps)PUSH 97.56%17.32(kbps) 备注： 其中GB,GN接口下载速率
7、为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口TCP连接时间损耗为810MS。MM1口TCP连接时间
8、损耗为8ms对整个手机报下载过程来说可以忽略不计。Gb口与GN口PDP激活时延相差不大。u 基于上述分析结果建议如下： 针对用户以及终端建议如下：针对用户彩信中心地址设置错误，建议客服联系不同厂家总结彩信中心地址设置汇总，对客户进行正确的彩信中心地址设置指导。 针对无线建议如下：1. 针对语音抢占数据业务导致超时无响应，建议修改无线参数降低小区CS/PS业务量。2. 针对网络断连的小区建议检查这些小区无线环境。3. 对网络负荷过重建议扩容。4 对数据流量大且移动性能不太好的小区，即导致TBF中断的小区重选 间隔较短的小区，通过调整一些空闲模式参数，尽量减少小区重选，以提高其移动性能。5 针对重
9、传率较高的小区LA参数调整建议：建议LA设置为ON，在C/I 好的情况下尽可能使用高编码方式，在C/I低的情况下使用低编码方式，降低重传。6 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下，每个PCU可
10、支持6个主用的GSL 64kbps时隙和6个冗余备份时隙，每个64kbps时隙是一个LAPD信道，两条GSL工作于负荷分担模式。网络运行维护过程中定期分析现网GSL负荷，对负荷已经达到预警门限的GSL及时采取容量调整措施可有效保障GSL始终工作于最佳状态。7 建议EGPRS网络开通网络辅助小区重选和GB over IP从而减少小区 重选对手机报下载速率的影响以及帧中继模式下Gb带宽不足问题。 8 SUSPEND、RESUME失败主要是在跨LAC，RAC，SGSN发生重选时造成 的。想要解决这一问题需要添加Gs接口。 针对核心网建议如下：1 建议修改GGSN qos_policymap 里的参数
11、Traffic Handling Priority可以大大提高PS业务的速率。2 建议调整SGSN寻呼响应计时器T3313值的设置，以减少寻呼响应时 间。 3 建议调整SM等待GGSN响应定时器的设置，以减少等待GGSN响应create PDP context response时间。4 建议SGSN开启对GGSN进行负荷分担功能，减少GGSN繁忙时负荷过重现象。 5 为了防止个别用户激活PDP上下文后，长时间不适用PS业务而占用系统资源，GGSN应当配置最大空闲时间，在这个时间内如果用户没有流量，则可以主动去激活此PDP上下文。建议设置为15分钟。同时设置PDP上下文最大存活时间为15分钟。6
12、 建议调整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.33
13、10.76%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:00-19:00）4个BSC总体手机报业务性能统计概况：晚忙时手机报接收概况类别次数比例手机报提取总次数6450100.00%提取成功次数579389.81%deactivate_pdp2043.16%flush_timeout1842
14、.85%timeout841.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（无线原因）引起的失败。
15、另外值得关注的是timeout（超时无响应）失败中伴随flush（小区更新）的有184次占总提取次数的2.85%，伴随有suspend（语音业务抢占数据业务）的次数为33次占总提取次数的0.51%，是否由于小区更新过程中以及suspend过程中出现异常导致手机报的提取超时失败下面将进行深入分析。除此之外还有33次超时无响应是伴随有LLC-DISCARDED，虽然这种消息不一定造成手机报提取失败，但是这种消息的发生一般是因为小区无线环境差造成的。早忙时（7:30-9:30） 4个BSC总体手机报业务性能统计概况：早忙时手机报接收概况类别次数比例手机报提取总次数4739100.00%提取成功次数4
16、39292.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:00-19:00）手机
17、报提取成功率统计如下：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%，B
18、SC785在2个小时内总的下发1617条手机报，成功提取1456条，手机报提取成功率为90.04%。 早忙时段（7:30-9:30） 4个BSC手机报提取成功率统计如下：BSC总提取次数成功提取次数成功率BSC40499693393.67%BSC71976771292.83%BSC7281547141791.60%BSC7851429133093.07%总体4739439292.68%同晚忙时段统计结果对比BSC404手机报提取成功率依然最高2个小时内下发996条成功提取933条，手机报提取成功率为93.67%， BSC728在2个小时忙时内总的下发次数为1547下发次数依然最多，成功提取14
19、17条，提取成功率为91.60%，总体 提取成功率为92.68%高于晚忙时89.88%。 4个BSC晚忙时（17:00-19: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%
20、M71929675_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%M719296
21、75_55800767497.37%上表中黄色部分标出的是成功率相对较低的小区。详细列表见附件：4个BSC早忙时（7:30-9: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%M72
22、858358_24293736690.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%M72858
23、358_47303524790.38%上表中黄色部分标出的是成功率相对较低的小区。详细请见附件：3.1失败原因分析首先看下正常接收手机报的流程，下图为WAP手机报提取过程：手机接收彩信时，首先要和WAP网关建立连接，连接的过程与WAP上网前的连接过程相同。连接完成后，手机向WAP网关发送GET消息，里面含有彩信中心的地址及彩信的Transaction ID。WAP网关将该消息转换为HTTP消息，转发至彩信中心。正常情况下，彩信中心向WAP网关发送该条彩信(m-retrieve-conf)。WAP网关收到该彩信后，转化为WSP向手机转发该彩信。手机收到该彩信后，向WAP网关发送m-acknowl
24、edge-ind消息，确认彩信已经接收完毕，WAP网关转发至彩信中心，彩信中心回复200 OK，WAP网关向手机回复WSP Reply，状态码为200 OK。手机向WAP网关发送WTP acknowledge消息，接收彩信过程完成。3.1.1用户侧发起PDP去激活分析：1. POST消息之前用户侧发起PDP去激活典型流程部分截图如下图：13秒第36个分包消息详细解码如下： 由于流程太长上面流程截图中忽略掉中间部分下发分包消息，从上面流程可以看出该用户在17：37:56227的时候发起PDP请求随后经过tcp连接三握手后于17:38:00729发起get请求开始下载手机报内容，随后手机报内容被分
25、割下发，一直下发到17:38:10197时的第36个分包，我们看到第36个分包消息的详细解码，发现TCP中Finish :more data from sender,说明这不是最后一个分包消息，还有没有下发的分包消息，用户13秒钟后仍然没有收到最后一个分包消息，开始发起deactivate PDP context request ，流程失败。至于为何网络侧没有下发最后一个分包后续将关联其他接口做深入分析。2、Post 消息之后的PDP去激活失败流程分析典型流程部分截图如下：第52个分包消息的消息参数如下： 由上图可以看出手机报分割下发后，下发到第52个分包消息，通过该消息参数可以看到这个分包消
26、息IP：total length :823比以上所有分包消息都小，手机终端认为这个分包就是最后一个分包消息，随后向网络侧发起接收完成回应消息POST，手机接收彩信完成，post消息参数如下： 由消息参数可以看出该消息request_URI: 200 ok，最后用户等待14秒钟后仍然没有收到网络侧的response，所以用户发起deactivate pdp context request. 这种情况属于用户接收彩信完成，从用户侧角度来看属于提取成功，但是如果网络侧收不到post消息，不返回response 200 ok的话，彩信中心认为手机报没有提取成功，将继续保留该彩信直到过期，这样势必对彩信
27、中心SP有影响，彩信日志中会出现手机报过期没有提取的错误日志记录。对以上2种用户侧发起PDP去激活情况进行统计发现Post之前的pdp去激活147次，post之后的PDP去激活71次。POST之前的PDP去激活请求属于用户行为，从局方角度无法干涉用户主动放弃提取彩信行为，但是可以看出很大部分是由于下发过程太过漫长，以至于用户主动放弃，这需要提高手机报下载速率来解决，post之后的PDP去激则在下一步分析中与GN口关联分析，看是否是POST消息上发过程中网络侧丢包或者与手机终端有关导致网络侧没有发送response。Post之后的PDP去激活手机终端型号：手机终端型号次数SAMSUNG-GT-S
28、5230C10SAMSUNG-GT-S3650C8MAUI MMS User Agent7SonyEricssonK700c7Nokia26103Nokia26263SAMSUNG-GT-S3930C_CMCC3SAMSUNG-S8300C3SAMSUNG-SGH-L878E2SHARP2SonyEricssonW302c2Android-Mms1Bird.M111Java1LENOVO I5161LENOVO-TD9001LG-KU3111PHOENIX1PRIZM1SAMSUNG-GT-C5510U1SAMSUNG-GT-M8800C1SAMSUNG-GT-S56001SAMSUNG-GT
29、-S6700C1SAMSUNG-GT-S7070C1SAMSUNG-SGH-E8481SHARP SH6220C1SonyEricssonF305c1SonyEricssonS500i1YuLong1YuLong-Coolpad73601YuLong-CoolpadN681不难看出主要是三星手机终端出现这种情况失败，建议这些终端型号升级软件。3.1.2小区更新过程分析：典型流程如下：可以看出数据包下发过程中，进行小区更新，从而导致网络侧无响应，消息流程失败，这种原因可能跟早忙、晚忙时，上下班高峰，很多用户都在路上或者车上移动，频繁进行小区更新，导致网络侧无响应超时失败。下边分析FLUSH过程对
30、下手机报下载成功率以及下载速率的影响。3.1.3 FLUSH分析：3.1.3.1 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) transferred45881.96%晚忙时LLC-SDU(s) dele
31、ted7539722.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的FLUSH流程中发现所有的参数Action va
32、lue参数大部分都是LLC-SDU(s) deleted，所以有一部分FLUSH消息不被PCU相应属于正常现象，不影响网络的运行。3.1.3.2 Flush过程描述下面为3GGP里面对FLUSH流程的描述。SGSN检测到MS由于小区重选或者路由更新使得小区变更时，将向老BVCI发送一个FLUSH-LL PDU来启动一下流程：l 一个NSE(如一个BSS即为一个NSE)和一个路由区内部的小区变更时，存储在老BVCI(对应原小区)中的由TLLI确定的LLC-PDU要么被删除，要么被传送到与该TLLI相关联的一个新BVCI（对应新的小区）。l 两个NSE或两个路由区之间的小区变更时，存储在老的BVC
33、I中的由TLLI确定的LLC-PDU被删除。在FLUSH-LL PDU中，SGSN向BSSGP提供：l 用于识别MS的TLLI;l 用于识别小区的老BVCI，该小区可找到针对某个MS的缓存LLC-PDU；l 用于识别与MS当前相关联的小区新的BVCI（仅在同一NSE和同一路由区时）FLUSH-LL PDU中如果没有提供新BVCI，则视为删除老的BVC排队的LLC-PDU。排队的BSSGP信令，比如寻呼消息，将不受这个流程影响。作为对FLUSH-LL PDU的回应，BSS将SGSN发送一个FLUSH-LL-ACK PDU，该PDU包括：l FLUSH-LL PDU中收到的TLLI；l 是否转发（
34、在同一NSE内）或删除LLC-PDU的指示。如果SDU指示为转发，应包含新BVCI。当SGSN收到FLUSH-LL-ACK PDU时，如果该PDU指示了与老PDU指示了与老BVC相关联的LLC-PDU已被删除，SGSN将选择如下操作之一：l 立即在新BVC（即新小区）上向MS重传所有未确认的LLC-PDU（在LLC确认刷新下）；l 按照LLC重传机制来发送未确认的LLC-PDU。当SGSN收到FLUSH-LL-ACK PDU时，该PDU指示了与老BVC相关联的LLC-PDU在NSE内转发，SGSN不必执行以上任何操作。在FLUSH-LL流程中，如果BSS能够转发缓存的LLC PDU给新BVCI
35、，BSS上下文将被保存；否则BSS上下文将被删除。原来的frame被deleted后,上层应用(TCP或WTP)会触发重发,如果重发成功的话,不会造成下载失败. 但会造成时延较大。3.1.3.3 Flush过程对手机报下载影响分析针对上文统计中手机报下载过程中，伴随flush过程的timeout失败流程进行分析。典型流程如下：由上图可以看出手机报下载过程中用户17:42:34084从小区LAC:29675；CI：26001更新到LAC:29675；CI:26002，并且Flush-LL-ACK，action value:LLC-SDU(S) deleted。由上图可以看出sequence nu
36、mber：317D09AE(830278062)以及 sequence number：317D0F4E(830279498)，sequence number：317D0412(830276626)均被触发重传。显然由于网络一直重传下行数据包而没有得到终端响应，最终导致超时失败。就算最终下载成功，小区更新触发重传也会对下载速率产生很大影响。发生flush的各小区统计如下：BVCILACCIflush次数10352964318931938110002964356071192891010296432447218690100929643244711764810332964318911733310272
37、964388511409510422964325163136931002296435607312035100729643804211713102829643885211182100429643476428590104129643251628436100829643804383111017296434705376541046296435304176031015296434705175991006296438041755510242964332616968100529643476436893102329675462416066详细清单见如下附件:3.1.3.4 数据包重传分析小区更新会触发下行数据
38、包的重传，下边则对重传率进行统计。早晚忙时段下行包重传率如下：时段下行传送包数下行重传包数重传率早忙时9269631760082.92%晚忙时179422719438010.83%早忙时下行数据包重传率为2.92%，晚忙时下行数据包重传率10.83%，明显高于早忙时。早忙时各小区重传率统计如下：按照重传率排名前20：BVCI重传包个数总的下行包个数重传率10677331323.32%1064352261513.46%104943463648011.91%105488398818.94%105721030546.88%10381392212896.54%10502101351695.97%106
39、32127382775.56%10313779692985.45%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.6
40、6%1066355114730.95%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%10075
41、8934092514.40%104147783333914.33%103019701402814.04%：详细清单如附件：3.1.3.5 小结： 针对重传率较高的小区LA参数调整建议：建议LA设置为ON，在C/I好的情况下尽可能使用高编码方式，在C/I低的情况下使用低编码方式，降低重传。 对数据流量大且移动性能不太好的小区，即导致TBF中断的小区重选间隔较短的小区，通过调整一些空闲模式参数，尽量减少小区重选，以提高其移动性能，建议进行参数调整的小区如下；BSCLAC_CI手机报总提取次数手机报提取成功次数手机报提取成功率该小区FLUSH发生次数M78529643_8043968992.71%2
42、709M72858358_1522797392.41%1814M78529643_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%1251M78529643_3261403587.50%2567M78529643_5607138
