数据业务组总结报告.docx

长沙移动手机报优化项目
数据业务组阶段报告

目 录
1．概 述 4
2.GB口业务性能统计： 6
3.GB口业务性能分析： 10
3.1失败原因分析 10
3.1.1用户侧发起PDP去激活分析： 12
3.1.2小区更新过程分析： 18
3.1.3 FLUSH分析： 19
3.1.4 Response非成功状态码整体统计： 26
3.1.5 Response 非成功状态码失败原因分析： 28
3.1.6 Radio_cause分析 35
3.1.7 Suspend过程中伴随LLC_discarded的超时失败： 37
3.1.8“SUSPEND”与“RESUME” 的失败原因分析： 38
3.2 SP站点排名： 45
3.3手机报内容大小分析： 47
3.4终端端口设置及操作流程 48
4.GB口下载速率分析： 50
4.1各小区手机报下载速率统计： 50
4.2手机报下载速率整体分析： 52
6. GB口介入性时延分析： 56
6.1 Attach时延分布统计： 56
6.2 PDP激活时延分析： 57
6.3 TCP连接时延分析： 58
7 MMS测试分析： 61
8．EGPRS分析： 68
9．GN口统计分析 70
9.1 GN口业务性能评估： 70
9.2 GN与GB关联分析 72
9.3小结： 76
10.1 MM1接口TCP连接分析 77
10.1.1 TCP连接建立过程描述 77
10.1.2 TCP连接建立时延分析 78
10.1.3 syn至ack消息时延分析： 79
10.1.4 TCP连接建立成功率统计 79
10.1.5异常的TCP连接统计: 80
10.2 MM1口手机报接收分析 81
10.2.1 MM1口手机报接收过程描述 81
10.2.2 Get至M-retrieve.conf时延和成功率 85
11．PUSH接口信令分析 89
11.1 PUSH口统计分析 89
11.2 PUSH口与MM1口关联分析 90
12．总 结： 93
引言：
项目管理区域范围： 本次《长沙移动GPRS手机报端到端性能优化》服务涉及长沙市区的4个BSC和3个CQT点以及相关的SGSN，GGSN, 1个WAP－Gateway和1套MMSC服务器。4个BSC如下：BSC404: BSC719: BSC728: BSC785:
1．概 述
湖南长沙移动手机报数据采集结构示意图如下所示：

本次手机报业务数据采集主要包括4个采集点，数据业务小组分别采集长沙移动现网的GB、Gn、MM1及PUSH等接口的数据用以专题分析。
2.成果综述
本次项目通过GB,GN,MM1,PUSH多接口关联分析发现的主要问题有如下4类：
1） 用户自身问题：比如彩信中心地址设置错误，以及流程没有结束用户主动释放等。可以告知用户正确设置来解决。
2） 终端问题：终端协议有问题，多为山寨机。建议厂家修补bug。
3） 无线环境问题：小区无线环境差。对小区进行无线环境优化。
4） 网络问题：超时、网络无响应。由于GGSN/SGSN忙时丢弃掉的消息。
长沙移动手机报优化成果如下：
u GB口分析主要结果与发现：
1) 网络侧超时无响应，主要是用户频繁小区更新过程中网络超时无响 应。
2) 用户行为：用户主动去激活以及彩信中心地址错误。
3) 位置更新或者语音业务抢占数据业务过程中超时无响应。
4) 终端原因：终端协议问题，上报不符合规范的消息参数
5) 网络连接中断
6) Flush成功率过低。
7) 小区更新(FLUSH)过程以及位置更新（SUSPEND）过程严重影响手机报下载速率。
8) 部分小区重传率过高。
9) 手机渗透率相对较高
u 手机报集中下发高峰期的下载速率明显低于其他时段的手机报下载 速率，网络的负荷过重时，对手机报的下载速率有着较大影响。
u GN口手机报成功率以及下载速率过低，GGSN繁忙无响应超时造成的手机报下载失败占比较高。
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接口下载速率为get request 到response消息时间差作为下载速率时间计算值。MM1接口下载速率为get request到m-retrieve-conf消息之间时间差作为下载速率时间计算值。push接口下载速率以push消息下发到MM1口收到get request消息过程时间作为计算下载速率时间差。 手机报大小均以各接口统计手机报总大小比总次数得到平均值计算得到。
接口
TCP连接平均时延(MS)
GB
810
GN
998
MM1
8

接口
PDP激活时延(MS)
GB
174
GN
145
由上表可以看出GN口TCP连接时间损耗最长是998ms，其次是GB口TCP连接时间损耗为810MS。MM1口TCP连接时间损耗为8ms对整个手机报下载过程来说可以忽略不计。Gb口与GN口PDP激活时延相差不大。
u 基于上述分析结果建议如下：
· 针对用户以及终端建议如下：
针对用户彩信中心地址设置错误，建议客服联系不同厂家总结彩信中心地址设置汇总，对客户进行正确的彩信中心地址设置指导。
· 针对无线建议如下：
1. 针对语音抢占数据业务导致超时无响应，建议修改无线参数降低小区CS/PS业务量。
2. 针对网络断连的小区建议检查这些小区无线环境。
3. 对网络负荷过重建议扩容。
4 对数据流量大且移动性能不太好的小区，即导致TBF中断的小区重选 间隔较短的小区，通过调整一些空闲模式参数，尽量减少小区重选，以提高其移动性能。
5 针对重传率较高的小区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可支持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 里的参数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 建议调整GGSN未收到SGSN响应报文时的重发时间间隔值，从而减少重传率。
7 建议PUSH消息按时间分散下发，避免下发集中度过高。
8 由于晚忙时下载速率以及接入性各项指标均比早忙时要差，建议手机 报 晚忙时播报时间提前一个小时播报，同时用户避开晚忙时下班路途中下载手机报，从而减少多次进行小区重选对手机报下载速率的影响。
· 针对无线建议的提出，通过无线优化人员配合无线参数调整优化前后指标对比：
优化前
优化后
日期
长沙手机报下载速率
日期
长沙手机报下载速率
指标同比提升
6月7日
11.84
7月7日
12.28
3.73%
6月8日
10.28
7月8日
12.15
18.19%
6月9日
11.13
7月9日
12.33
10.76%
6月10日
11.14
7月10日
12.16
9.20%
6月11日
11.04
7月11日
12.27
11.23%
由上表可以看出优化后手机报下载速率得到明显提高。
3. GB口业务性能分析：
数据采集时间点：6月25日从17：00至下午20：00和6月26日从7:30到9:30。
依据上述时间段内GB接口数据针对现网手机报业务的提取性能进行分析
晚忙时25日（17:00---19:00）4个BSC总体手机报业务性能统计概况：
晚忙时手机报接收概况
类别
次数
比例
手机报提取总次数
6450
100.00%
提取成功次数
5793
89.81%
deactivate_pdp
204
3.16%
flush_timeout
184
2.85%
timeout
84
1.30%
Response非2xx
76
1.18%
Radio_cause(radio contact lost with MS)
34
0.53%
suspend_timeout
33
0.51%
Reset
9
0.14%
llc_discarded_timeout
33
0.51%
从统计结果可以看出长沙移动现网中4个BSC晚忙时手机报下发总次数为6450次，成功提取次数为5793次，成功率为89.81%，主要的失败原因是timeout（超时无响应），其次是deactivate_pdp(用户去激活)以及response返回的非成功状态码，最后是radio_cause（无线原因）引起的失败。另外值得关注的是timeout（超时无响应）失败中伴随flush（小区更新）的有184次占总提取次数的2.85%，伴随有suspend（语音业务抢占数据业务）的次数为33次占总提取次数的0.51%，是否由于小区更新过程中以及suspend过程中出现异常导致手机报的提取超时失败下面将进行深入分析。除此之外还有33次超时无响应是伴随有LLC-DISCARDED，虽然这种消息不一定造成手机报提取失败，但是这种消息的发生一般是因为小区无线环境差造成的。
早忙时（7:30---9:30） 4个BSC总体手机报业务性能统计概况：
早忙时手机报接收概况
类别
次数
比例
手机报提取总次数
4739
100.00%
提取成功次数
4392
92.68%
deactivate_pdp
104
2.19%
flush_timeout
83
1.75%
timeout
59
1.24%
Response非2xx
45
0.95%
Radio_cause(radio contact lost with MS)
15
0.32%
suspend_timeout
17
0.36%
Reset
6
0.13%
llc_discarded_timeout
18
0.38%
比较早忙与晚忙统计概况，发现早忙的成功率92.68%要高于晚忙成功率89.81%。各种失败原因的所占比例排名相同，依然都是用户主动去激活以及小区更新过程中的网络超时无响应。
4个BSC晚忙时（17:00---19:00）手机报提取成功率统计如下：
BSC
总提取次数
提取成功次数
成功率
BSC404
1639
1499
91.46%
BSC719
1251
1085
86.73%
BSC728
2061
1863
90.39%
BSC785
1617
1456
90.04%
总体
6568
5903
89.88%
由上表可以看出BSC404手机报提取成功率最高2个小时内下发1639条成功提取1499条，手机报提取成功率为91.46%，BSC719手机报提取成功率最低2个小时忙时内总的下发1251条成功提取1085条，手机报提取成功率为86.73%，BSC728在2个小时忙时内总的下发次数为2061下发次数最多，成功提取1863条，提取成功率为90.39%，BSC785在2个小时内总的下发1617条手机报，成功提取1456条，手机报提取成功率为90.04%。
早忙时段（7:30---9:30） 4个BSC手机报提取成功率统计如下：
BSC
总提取次数
成功提取次数
成功率
BSC404
996
933
93.67%
BSC719
767
712
92.83%
BSC728
1547
1417
91.60%
BSC785
1429
1330
93.07%
总体
4739
4392
92.68%
同晚忙时段统计结果对比BSC404手机报提取成功率依然最高2个小时内下发996条成功提取933条，手机报提取成功率为93.67%， BSC728在2个小时忙时内总的下发次数为1547下发次数依然最多，成功提取1417条，提取成功率为91.60%，总体 提取成功率为92.68%高于晚忙时89.88%。
4个BSC晚忙时（17:00---19:00）各小区手机报提取成功率统计如下：
各小区按照提取次数前20名列表如下：
BSC
lac_ci
总提取次数
成功次数
比例
M404
29675_47511
164
152
92.68%
M728
58358_1523
130
122
93.85%
M728
58358_1261
115
104
90.43%
M728
58358_47301
109
95
87.16%
M404
29675_4662
106
98
92.45%
M719
29675_24603
101
74
73.27%
M785
29643_8043
96
89
92.71%
M719
29675_1673
95
71
74.74%
M728
58358_1263
94
85
90.43%
M719
29675_24601
93
77
82.80%
M404
29675_4661
89
76
85.39%
M404
29675_26002
85
78
91.76%
M404
29675_23561
84
74
88.10%
M719
29675_4281
84
76
90.48%
M728
58358_7303
83
72
86.75%
M404
29675_47512
82
67
81.71%
M728
58358_1522
79
73
92.41%
M728
58358_24231
78
73
93.59%
M719
29675_1672
77
62
80.52%
M719
29675_55800
76
74
97.37%
上表中黄色部分标出的是成功率相对较低的小区。
详细列表见附件：
4个BSC早忙时（7:30---9:30）各小区手机报提取成功率统计如下：
各小区按照提取次数前20名：
BSC
LAC_CI
总提取次数
成功提取次数
成功率
M728
58358_1523
138
127
92.03%
M785
29643_8043
113
108
95.58%
M728
58358_47301
80
76
95.00%
M404
29675_47511
77
76
98.70%
M719
29675_46242
81
73
90.12%
M404
29675_47512
80
72
90.00%
M404
29675_23561
71
67
94.37%
M728
58358_24293
73
66
90.41%
M719
29675_56243
68
64
94.12%
M404
29675_47523
60
59
98.33%
M785
29643_1891
60
56
93.33%
M728
58358_24231
57
56
98.25%
M785
29643_47051
59
55
93.22%
M728
58358_24292
56
54
96.43%
M728
58358_19631
60
51
85.00%
M785
29643_3261
49
49
100.00%
M728
58358_11891
51
49
96.08%
M719
29675_1673
52
49
94.23%
M728
58358_1261
60
48
80.00%
M728
58358_47303
52
47
90.38%
上表中黄色部分标出的是成功率相对较低的小区。
详细请见附件：
3.1失败原因分析
首先看下正常接收手机报的流程，下图为WAP手机报提取过程：

手机接收彩信时，首先要和WAP网关建立连接，连接的过程与WAP上网前的连接过程相同。连接完成后，手机向WAP网关发送GET消息，里面含有彩信中心的地址及彩信的 Transaction ID。WAP网关将该消息转换为HTTP消息，转发至彩信中心。正常情况下，彩信中心向WAP网关发送该条彩信(m-retrieve-conf)。WAP网关收到该彩信后，转化为WSP向手机转发该彩信。手机收到该彩信后，向WAP网关发送m-acknowledge-ind消息，确认彩信已经接收完毕，WAP网关转发至彩信中心，彩信中心回复200 OK，WAP网关向手机回复WSP Reply，状态码为200 OK。手机向WAP网关发送WTP acknowledge消息，接收彩信过程完成。
3.1.1用户侧发起PDP去激活分析：
1. POST消息之前用户侧发起PDP去激活
典型流程部分截图如下图：

13秒

第36个分包消息详细解码如下：

由于流程太长上面流程截图中忽略掉中间部分下发分包消息，从上面流程可以看出该用户在17：37:56’227的时候发起PDP请求随后经过tcp连接三握手后于17:38:00’729发起get请求开始下载手机报内容，随后手机报内容被分割下发，一直下发到17:38:10’197时的第36个分包，我们看到第36个分包消息的详细解码，发现TCP中Finish :more data from sender,说明这不是最后一个分包消息，还有没有下发的分包消息，用户13秒钟后仍然没有收到最后一个分包消息，开始发起deactivate PDP context request ，流程失败。至于为何网络侧没有下发最后一个分包后续将关联其他接口做深入分析。
2、Post 消息之后的PDP去激活失败流程分析
典型流程部分截图如下：

第52个分包消息的消息参数如下：

由上图可以看出手机报分割下发后，下发到第52个分包消息，通过该消息参数可以看到这个分包消息IP：total length :823比以上所有分包消息都小，手机终端认为这个分包就是最后一个分包消息，随后向网络侧发起接收完成回应消息POST，手机接收彩信完成，post消息参数如下：

由消息参数可以看出该消息request_URI: 200 ok，最后用户等待14秒钟后仍然没有收到网络侧的response，所以用户发起deactivate pdp context request. 这种情况属于用户接收彩信完成，从用户侧角度来看属于提取成功，但是如果网络侧收不到post消息，不返回response 200 ok的话，彩信中心认为手机报没有提取成功，将继续保留该彩信直到过期，这样势必对彩信中心SP有影响，彩信日志中会出现手机报过期没有提取的错误日志记录。
对以上2种用户侧发起PDP去激活情况进行统计发现Post之前的pdp去激活147次，post之后的PDP去激活71次。POST之前的PDP去激活请求属于用户行为，从局方角度无法干涉用户主动放弃提取彩信行为，但是可以看出很大部分是由于下发过程太过漫长，以至于用户主动放弃，这需要提高手机报下载速率来解决，post之后的PDP去激则在下一步分析中与GN口关联分析，看是否是POST消息上发过程中网络侧丢包或者与手机终端有关导致网络侧没有发送response。
Post之后的PDP去激活手机终端型号：
手机终端型号
次数
SAMSUNG-GT-S5230C
10
SAMSUNG-GT-S3650C
8
MAUI MMS User Agent
7
SonyEricssonK700c
7
Nokia2610
3
Nokia2626
3
SAMSUNG-GT-S3930C_CMCC
3
SAMSUNG-S8300C
3
SAMSUNG-SGH-L878E
2
SHARP
2
SonyEricssonW302c
2
Android-Mms
1
Bird.M11
1
Java
1
LENOVO I516
1
LENOVO-TD900
1
LG-KU311
1
PHOENIX
1
PRIZM
1
SAMSUNG-GT-C5510U
1
SAMSUNG-GT-M8800C
1
SAMSUNG-GT-S5600
1
SAMSUNG-GT-S6700C
1
SAMSUNG-GT-S7070C
1
SAMSUNG-SGH-E848
1
SHARP SH6220C
1
SonyEricssonF305c
1
SonyEricssonS500i
1
YuLong
1
YuLong-Coolpad7360
1
YuLong-CoolpadN68
1
不难看出主要是三星手机终端出现这种情况失败，建议这些终端型号升级软件。
3.1.2小区更新过程分析：
典型流程如下：

可以看出数据包下发过程中，进行小区更新，从而导致网络侧无响应，消息流程失败，这种原因可能跟早忙、晚忙时，上下班高峰，很多用户都在路上或者车上移动，频繁进行小区更新，导致网络侧无响应超时失败。
下边分析FLUSH过程对下手机报下载成功率以及下载速率的影响。
3.1.3 FLUSH分析：
3.1.3.1 Flush过程概况统计：
统计结果如下：
时段
消息名称
次数
占总FLUHS次数比例
早忙时
Flush-LL
234279
100.00%
Flush-LL-ack
66755
28.49%
晚忙时
Flush-LL
337835
100.00%
Flush-LL-ack
86171
25.51%
由统计结果可以发现flush成功率比较低。
时段
Action 参数值
次数
占总FLUSH次数比例
早忙时
LLC-SDU(s) deleted
62167
26.54%
LLC-SDU(s) transferred
4588
1.96%
晚忙时
LLC-SDU(s) deleted
75397
22.32%
LLC-SDU(s) transferred
10774
3.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 value参数大部分都是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或两个路由区之间的小区变更时，存储在老的BVCI中的由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 是否转发（在同一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，BSS上下文将被保存；否则BSS上下文将被删除。
原来的frame被deleted后,上层应用(TCP或WTP)会触发重发,如果重发成功的话,不会造成下载失败. 但会造成时延较大。
3.1.3.3 Flush过程对手机报下载影响分析
针对上文统计中手机报下载过程中，伴随flush过程的timeout失败流程进行分析。
典型流程如下：

由上图可以看出手机报下载过程中用户17:42:34’084从小区LAC:29675；CI：26001更新到LAC:29675；CI:26002，并且Flush-LL-ACK，action value:LLC-SDU(S) deleted。由上图可以看出sequence number：317D09AE(830278062)以及 sequence number：317D0F4E(830279498)，sequence number：317D0412(830276626)均被触发重传。显然由于网络一直重传下行数据包而没有得到终端响应，最终导致超时失败。就算最终下载成功，小区更新触发重传也会对下载速率产生很大影响。
发生flush的各小区统计如下：
BVCI
LAC
CI
flush次数
1035
29643
1893
19381
1000
29643
56071
19289
1010
29643
24472
18690
1009
29643
24471
17648
1033
29643
1891
17333
1027
29643
8851
14095
1042
29643
25163
13693
1002
29643
56073
12035
1007
29643
8042
11713
1028
29643
8852
11182
1004
29643
47642
8590
1041
29643
25162
8436
1008
29643
8043
8311
1017
29643
47053
7654
1046
29643
53041
7603
1015
29643
47051
7599
1006
29643
8041
7555
1024
29643
3261
6968
1005
29643
47643
6893
1023
29675
46241
6066
详细清单见如下附件:
3.1.3.4 数据包重传分析
小区更新会触发下行数据包的重传，下边则对重传率进行统计。
早晚忙时段下行包重传率如下：
时段
下行传送包数
下行重传包数
重传率
早忙时
92696
3176008
2.92%
晚忙时
1794227
194380
10.83%
早忙时下行数据包重传率为2.92%，晚忙时下行数据包重传率10.83%，明显高于早忙时。
早忙时各小区重传率统计如下：
按照重传率排名前20：
BVCI
重传包个数
总的下行包个数
重传率
1067
73
313
23.32%
1064
352
2615
13.46%
1049
4346
36480
11.91%
1054
883
9881
8.94%
1057
210
3054
6.88%
1038
1392
21289
6.54%
1050
2101
35169
5.97%
1063
2127
38277
5.56%
1031
3779
69298
5.45%
1040
2230
41596
5.36%
1051
1039
24386
4.26%
1011
4212
102382
4.11%
1015
2739
72224
3.79%
1053
329
8912
3.69%
1003
2768
75532
3.66%
1033
4017
109926
3.65%
1046
2702
74330
3.64%
1001
2107
58443
3.61%
1022
1366
39547
3.45%
1041
2242
65502
3.42%
详细清单见附件如下：
晚忙时各小区重传率统计如下：
按照重传率排名前20：
BVCI
重传包次数
下行包次数
重传率
1053
1039
2914
35.66%
1066
355
1147
30.95%
1069
19
70
27.14%
1032
401
1740
23.05%
1062
1508
7317
20.61%
1052
1777
9350
19.01%
1028
4000
22066
18.13%
1049
5019
27851
18.02%
1047
3172
19060
16.64%
1010
5068
30871
16.42%
1012
1795
10983
16.34%
1042
3812
23654
16.12%
1063
3125
19493
16.03%
1014
2725
17458
15.61%
1027
5516
35641
15.48%
1013
3891
25207
15.44%
1018
4828
33407
14.45%
1007
5893
40925
14.40%
1041
4778
33339
14.33%
1030
1970
14028
14.04%
：详细清单如附件：
3.1.3.5 小结：
Ø 针对重传率较高的小区LA参数调整建议：建议LA设置为ON，在C/I好的情况下尽可能使用高编码方式，在C/I低的情况下使用低编码方式，降低重传。
Ø 对数据流量大且移动性能不太好的小区，即导致TBF中断的小区重选间隔较短的小区，通过调整一些空闲模式参数，尽量减少小区重选，以提高其移动性能，建议进行参数调整的小区如下；
BSC
LAC_CI
手机报总提取次数
手机报提取成功次数
手机报提取成功率
该小区FLUSH发生次数
M785
29643_8043
96
89
92.71%
2709
M728
58358_1522
79
73
92.41%
1814
M785
29643_1891
75
61
81.33%
11077
M785
29643_8042
74
65
87.84%
4349
M785
29643_53041
71
61
85.92%
2081
M785
29643_47051
62
53
85.48%
3949
M785
29643_47641
60
58
96.67%
2806
M785
29643_47642
59
53
89.83%
2996
M719
29675_46241
49
44
89.80%
3972
M785
29643_47643
46
43
93.48%
2584
M785
29643_47052
43
40
93.02%
2644
M785
29643_19313
40
40
100.00%
1251
M785
29643_3261
40
35
87.50%
2567
M785
29643_56071
38
35