数据业务优化报告.docx
《数据业务优化报告.docx》由会员分享，可在线阅读，更多相关《数据业务优化报告.docx（25页珍藏版）》请在冰豆网上搜索。
数据业务优化报告
兰州数据业务优化报告
本优化通过对数据业务分配机制和流程的分析，对影响数据业务分配的各个环节进行了详细的分析，对各环节是否是影响数据吞吐率的瓶颈问题进行了分析。
对影响数据业务的参数进行了分析调整，对并对一些测试中出现的问题进行了分析解决。
通过以上大量测试和分析，我们发现影响系统吞吐率的原因为：
1、部分基站的WC和MCC1X的负载偏高，会一定程度影响数据业务的速率；
2、从RFLoad来看，由于长春的系统负荷非常高，系统的FWDECIOR较差，是影响数据吞吐率的主要原因。
由于数据传输在WC和MCC1X资源以及RFLoad上要求更加严格，因此在对话音无任何影响的情况下对数据吞吐率已经产生了影响。
因此我们建议：
a）某些基站扇区的WC和MCC1X负荷较高，对数据业务产生影响。
因该考虑增加系统资源如第3载波、增加MCC1X板卡等；
b）从系统的RFLoad来看，兰州的系统负荷较高，很多地方数据业务都会受到很大影响，造成数据业务速率低。
随着数据业务的重要性越来越高，可以考虑增加新的载波单独承载数据业务
二．数据业务分配机制和流程
要对数据业务进行优化，必须要了解数据业务的分配机制和分配流程，才能更深入地了解数据业务的各个瓶颈，提出有针对性的优化方案。
1．SCH分配机制
前向SCH的申请与否由系统的PCF/Selector决定，反向SCH申请与否由手机决定。
RLP数据在Selector的Buffer里存储，Selector根据Buffer里的RLP数据大于配置参数Min_Queue_Size，就进行分配前向SCH。
Selector再根据Buffer的数据存储量、预计后续达到的数据量和数据的加权因子等计算所需要的吞吐量，选择合适速率等级的SCH信道。
手机决定何时申请反向SCH和申请SCH的种类。
一般情况下手机都申请最大吞吐量的SCH。
2．SCH分配流程
前向SCH的分配流程
ØPCF监测经过PDSN的数据吞吐量和对于F-SCH的请求
ØPSI/SDU决定发起请求的数据速率和请求F-SCH所在的扇区
ØTSM询问RFLoadmanager以某目标速率速率上传输SCH给MS所需要
的功率
ØRFLoadManager提供该速率所需的前向功率估计给TSM和MM/CPP
ØTSM向CacheManager申请符合申请速率的CE,WC和Backhaul资源
ØCacheManager提供资源信息给TSM和MM/CPP
ØTSM分配TS并告知SDU当前能力，RFLoadManager周期性地估算每一
个TimeSlice的容量
ØTSM向RFLoadmanager请求gainboost
Ø信道分配并激活gainboost
三．兰州CDMA系统各类资源负荷分析
1．PCF/Selector资源分析
摩托罗拉系统的PCF/Selector容量很大，一块PCF板卡就可以处理1800个激活
的数据呼叫和10200个dormantdatacall。
从CBSC级的统计来看，PCF/Selector的利用率都比较低――如下，目前PCF/Selector的资源不会成为制约数据业务的瓶颈。
DSWandPSI-CEUtilizationSection
MM|DSWPortUtilization|PSI-CEUtilization|
ID|AllocatedTotalAvailUtil%GF-Value|ConfigErlangBBHHUtil%GF-Value|
============================================================================================
90115812815271.30.3325832207.814:
3025.02.8029
90146576815280.7-P0.17773448498.011:
3014.45.5780
90166178815275.80.25353368384.310:
0011.47.3267
90175689815269.80.3613832379.721:
0045.61.0819
2．WC资源分析
WC属于基站载波扇区级的资源。
每个载波扇区的Walshcode总数为64个
（针对WC64而言。
实际上1X的WC可以使用WC128），用于信令信道，语音信道，基本信道和补充信道。
目前系统的每载波扇区基本都配置了导频，同步，寻呼信道各一个，也就是说余下大概61各WC可以提供给业务信道使用。
基本上每个语音呼叫占用一个语音信道和一个Walshcode。
每个1X数据呼叫占用一个基本信道，一个补充信道和一个Walshcode，每个补充信道捆绑多个Walshcode使用，多个用户共享补充信道。
语音和数据业务共享61个WC。
对于Packet基站，数据库把61个可提供给业务信道使用的WC都配置到了Cache里。
也就是说，对于Packet基站而言，Cache对于SCH的限制变小了。
但同样，对于Packet基站，语音也可调用Cache里的WC，不再是只调用Cache外的WC资源。
也就是说，对于Packet基站，SCH可调用的Cache总资源增多，但Cache的资源不再只是数据业务独享，而同样可以随时被语音调用。
这就意味着，当某载波扇区的语音用户非常多时，虽然Cache里配置的WC很多，但数据业务也会分配不到所需的WC资源。
对应不同的RC（RC3/RC4），前向不同速率SCH的CE和WC的占用情况并不一样。
RC3占用资源多，但抗干扰能力强，RC4占用资源少，但抗干扰能力差。
下表为前向RC3/RC4时的CE和WC的占用情况
FWDRC3
FWDRC4
Rate（Kbps）
CE’s
WCLength
Rate（Kbps）
CE’s
WCLength
9.6
1
64
9.6
1
128
19.2
2
32
19.2
1
64
38.4
4
16
38.4
2
32
76.8
8
8
76.8
4
16
153.6
16
4
153.6
8
8
从上图看到，当FWDRC3时，要达到153.6K（16X），需要占用16个CE,
一个WC4（也就是说16个WCWC64）；当采用RC4时，要达到16X，只需要占用8个CE，一个WC8（也就是说8个WC64）。
我们现网上行用的是RC4配置，下行用的是RC3配置。
3．数据业务WC负荷情况：
1）Forward拥塞情况
MM
BTS
S
Car
BH
Rqsts
RFBlks
WCBlks
（RF+WC）Blk%
9017
743
2
283
21
18424
8
3963
21.6
9017
712
1
283
21
18338
120
3947
22.2
9011
133
2
283
22
18093
50
3093
17.4
9011
128
3
283
22
17859
228
2739
16.6
9017
744
1
283
14
15512
3
2532
16.3
9017
712
3
283
21
15658
6
2257
14.5
9017
727
2
283
22
17042
936
1843
16.3
9017
747
1
283
19
13736
0
1828
13.3
9011
112
3
283
13
14900
288
1754
13.7
9011
35
1
283
10
13435
626
1561
16.3
9017
785
1
283
21
13102
5
1298
9.9
9017
713
1
283
17
18479
1005
943
10.5
9017
713
2
283
14
17993
433
882
7.3
9017
724
2
283
20
18013
104
820
5.1
9017
719
2
283
22
14407
313
598
6.3
9017
721
1
283
21
10800
422
572
9.2
9011
6
1
283
12
15983
346
561
5.7
9011
35
2
283
12
9917
419
527
9.5
9017
741
3
283
16
14441
38
523
3.9
9017
735
1
283
21
24153
758
503
5.2
9017
719
1
283
10
7261
0
490
6.7
9017
751
3
283
1
12190
1
411
3.4
9017
720
1
283
22
16883
16
349
2.2
9017
719
3
201
22
12011
0
324
2.7
9017
724
3
283
22
10861
0
303
2.8
9017
744
2
283
21
10562
0
281
2.7
9013
319
2
283
14
13505
210
254
3.4
9017
748
2
283
17
11397
2578
244
24.8
9017
743
1
283
20
11050
0
227
2.1
9017
750
1
283
21
12689
748
194
7.4
9011
101
2
283
22
10285
0
187
1.8
9017
745
3
283
20
6055
159
187
5.7
9017
729
2
283
20
10664
101
187
2.7
9017
753
1
283
18
14214
2
177
1.3
9011
42
2
283
22
15032
2322
158
16.5
9017
712
2
283
22
9134
58
148
2.3
9011
40
1
283
22
9396
63
138
2.1
9011
112
2
283
13
9676
577
120
7.2
9011
33
2
283
15
9154
461
119
6.3
9011
31
1
283
22
8304
236
112
4.2
9011
31
2
283
0
12505
487
101
4.7
9017
721
3
283
21
10241
926
101
10
9017
726
3
283
22
8990
0
100
1.1
2）Reverse拥塞情况
MM
BTS
S
Car
Reverse
BH
Rqsts
Blks
Blk%
9011
37
3
283
20
7370
7363
99.9
9016
219
2
283
10
9518
9507
99.9
9016
207
1
283
23
3205
3203
99.9
9011
55
1
283
19
1402
1399
99.8
9016
223
2
283
23
1133
1131
99.8
9017
714
2
283
14
2867
2859
99.7
9014
423
3
201
16
165
164
99.4
9017
753
1
283
18
5594
5425
97
9017
753
1
201
11
1445
1229
85.1
9017
714
2
201
21
3191
2561
80.3
9017
751
1
201
12
1156
829
71.7
9017
723
3
201
10
81
58
71.6
9014
513
2
283
21
1887
1310
69.4
9011
154
2
283
0
355
208
58.6
9017
735
3
283
23
3826
1791
46.8
9017
715
2
283
20
3050
1391
45.6
9014
513
1
283
10
2590
1148
44.3
9013
327
2
201
0
120
53
44.2
9017
715
3
283
17
1025
384
37.5
9013
328
1
201
21
5074
1769
34.9
9011
101
2
283
22
3948
1247
31.6
9014
441
2
283
15
2208
631
28.6
9017
782
1
283
8
1955
492
25.2
9014
8
1
283
19
5135
1131
22
9017
731
3
283
0
4008
874
21.8
9014
536
3
201
18
2832
547
19.3
9017
715
1
283
16
4207
803
19.1
9011
185
1
283
21
1240
209
16.9
9014
8
3
201
20
1218
188
15.4
9017
753
3
283
19
3156
474
15
9017
751
1
283
20
6472
936
14.5
9011
55
2
283
16
2092
301
14.4
9017
788
1
283
0
5461
739
13.5
9017
748
1
283
11
2310
238
10.3
9013
306
1
283
19
1571
157
10
4．MCC资源分析
MCC属于基站共享资源。
95话音优先占用95CE，当95CE溢出时，才占用1X
CE。
1X话音优先占用1XCE，当1XCE溢出时，才占用95CE，建立95Call。
1X数据业务一般占用一个FCH和一个SCH，FCH只能占用1XCE，SCH占用MCC1X里专门定义给SCH的CE。
也就是说数据业务的FCH和1X语音占用同样的1XCE资源，二者会相互影响。
接着我们来分析兰州系统的MCC使用情况，看看是否会对1X数据业务产生影响。
可以通过查看TRF报告来查看MCC资源的使用情况。
TRF报告里头与MCC资源相关的报告包括：
总的TCH使用情况报告和MCC1X使用情况报告两部分。
首先，来看看总的TCH使用情况报告。
从BBHTRAFFICREPORT-AllCarrierGroups报告可以看到，基本上长春全网的TCH负载并不高，平均水平大概在40％左右。
只有少数的微蜂窝基站的总TCH负载过高。
也就是说总的TCH的容量没有问题，还富有余量。
接着，来看看MCC1X使用情况报告。
从BBHTRAFFICREPORT-1XCarrierGroups报告可以看到，MCC1X的负荷与之前的TCH总负荷并不对称，不少MCC1X的负荷偏高，但该站总的TCH负荷并不高。
下表为系统中1XMCC和95MCC板卡的负荷非常不均衡的基站：
MM
BTS
1XTCHlaod%
TCHload
9016
201
87.1
29.5
9014
405
85.5
29.8
9016
246
82.7
44.1
9011
128
82
41.7
9017
712
82
43.8
9014
507
80.4
24.1
9016
207
78.2
42.3
9014
503
76.7
26.6
9014
502
72.9
31.4
9011
32
72.3
35.9
9014
408
69.8
46.8
9014
510
67.3
28.8
9014
418
65.9
29.9
9017
743
63.4
37.2
9014
409
63.1
33.7
9014
415
62.8
32.8
9014
490
62.1
45.1
9014
508
61.8
32.6
对于这些1XMCC负载偏高的基站，如果其总的MCC负载不高，则对语音业务并不会产生影响，但可能会影响到数据业务的接入和切换，从侧面降低数据的速率。
四．兰州数据业务指标统计
1．兰州地区数据业务话务量统计：
兰州地区数据业务与语音业务全天话务量对比：
图中蓝线为全天24小时语音业务的WC话务量。
粉线为数据业务WC话务量。
图中蓝线为全天24小时语音业务的XC话务量。
粉线为数据业务XC话务量。
XC话务量为WC话务量去掉所有切换话务量后的话务量。
可以看出数据业务的切换话务量要比语音小很多，数据业务XC话务量比语音稍低。
2、兰州地区全天数据业务指标：
Forward
由上图可以看到每天下载数据业务忙时为21点左右，总下载数据流量为7600Mbytes左右。
由以上两张图可以看出，兰州4个CBSC的平均下载速率为110左右，在全天数据流量较低的时段平均速率相对校高。
可以说明平均速率与网络繁忙与否有一定的对应关系。
MarchRate为用户申请所有速率SCH的成功率。
由以上两张图可以看出，兰州4个CBSC的平均MatchRate在90%左右，在全天SCH申请次数较低的时段MatchRate相对校高。
可以说明MatchRate与网络繁忙与否有一定的对应关系。
Reverse
由上图可以看到每天上传数据业务忙时为21点左右，总下载数据流量为6200Mbytes左右。
比下载数据流量小1000Mbytes左右。
由上图可以看到所有CBSC的上传平均速率为50kbps左右，全天速率比较平均。
五．兰州CDMA数据业务参数检查
1、WC参数设置及数据业务功能开关检查
BTSID
Sector
Carrier
Carrier_Type
WalshCode
Cache
1xData
52
1
283
Normal
60
0
off
95BTS
52
2
283
Normal
60
0
off
95BTS
53
1
283
Normal
60
0
off
95BTS
53
2
283
Normal
60
0
off
95BTS
146
3
283
Normal
60
0
off
Precut
148
1
283
Normal
60
0
off
95BTS
148
2
283
Normal
60
0
off
95BTS
152
1
283
Normal
60
0
off
95BTS
152
2
283
Normal
60
0
off
95BTS
197
1
283
Normal
60
16
off
227
1
283
Normal
60
0
off
95BTS
227
2
283
Normal
60
0
off
95BTS
227
3
283
Normal
61
0
off
95BTS
249
1
283
Normal
60
0
off
95BTS
249
2
283
Normal
60
0
off
95BTS
250
1
283
Normal
60
0
off
95BTS
250
2
283
Normal
60
0
off
95BTS
所有1X基站的WC配置都正常只有个别基站为保证语音业务只给数据业务预留8个WC。
在检查基站数据业务功能时，只有BTS197的数据业务功能为OFF，即不支持数据业务的请求。
该站其它有关数据业务的参数设置都为正常，现已将其数据业务功能打开。
其它没有打开数据业务功能的基站都为95基站，BTS146第三扇区BBX被Precut掉，为扇区不存在。
2、兰州基站数据业务功能检查
兰州市所以PKT基站都没有MCC丢失IP的问题，在检查所有C-BTSMCC（MAWI）IP情况发现BTS36的MCC-1没有IP地址，无法接受数据业务的请求：
gsomc-000601>statusMCC-36-1add
TELSTATE=INS_BUSYPROCEDURE=NONE
PHYSTATE=INSHDWR_TYPE=MCC1X
DEVICE_ASSUMED=NONEIP_ADDR="0.0.0.0"
TOTAL_ACTIVE_RESOURCES="192"MAX_FWD_RESOURCES="128"
MAX_RVS_RESOURCES="64"FRU_ACTIVE_RESOURCES="192"
TEMP_ACTIVATED_RESOURCES="0"TEMP_CERT_EXP_DATE=0-00-00
PERM_ACTIVATED_RESOURCES="0"
处理后：
MCC-36-108-11-1417:
16:
38gsomcMM-9011M000666.00003325524/589995
INFO:
25"MCCStatusResponse"
TELSTATE=INS_BUSYPROCEDURE=NONE
PHYSTATE=INSHDWR_TYPE=MCC1X
DEVICE_ASSUMED=NONEIP_ADDR="10.33.0.20"
TOTAL_ACTIVE_RESOURCES="192"MAX_FWD_RESOURCES="128"
MAX_RVS_RESOURCES="64"FRU_ACTIVE_RESOURCES="192"
TEMP_ACTIVATED_RESOURCES="0"TEMP_CERT_EXP_DATE=0-00-00
PERM_ACTIVATED_RESOURCES="0"
3、基站ResourceGroup检查：
多数基站通用ResourceGroupsetting
MCC
CSM
F
升级会员 