数据业务优化报告.docx

1、数据业务优化报告兰州数据业务优化报告本优化通过对数据业务分配机制和流程的分析，对影响数据业务分配的各个环节进行了详细的分析，对各环节是否是影响数据吞吐率的瓶颈问题进行了分析。对影响数据业务的参数进行了分析调整，对并对一些测试中出现的问题进行了分析解决。通过以上大量测试和分析，我们发现影响系统吞吐率的原因为：1、 部分基站的WC和MCC1X的负载偏高，会一定程度影响数据业务的速率；2、 从RF Load来看，由于长春的系统负荷非常高，系统的FWD ECIOR较差，是影响数据吞吐率的主要原因。由于数据传输在WC和MCC1X资源以及RF Load上要求更加严格，因此在对话音无任何影响的情况下对数据吞

2、吐率已经产生了影响。因此我们建议：a) 某些基站扇区的WC和MCC1X负荷较高，对数据业务产生影响。因该考虑增加系统资源如第3载波、增加MCC1X板卡等；b) 从系统的RF Load来看，兰州的系统负荷较高，很多地方数据业务都会受到很大影响，造成数据业务速率低。随着数据业务的重要性越来越高，可以考虑增加新的载波单独承载数据业务二 数据业务分配机制和流程 要对数据业务进行优化，必须要了解数据业务的分配机制和分配流程，才能更深入地了解数据业务的各个瓶颈，提出有针对性的优化方案。1 SCH分配机制前向SCH的申请与否由系统的PCF/Selector决定，反向SCH申请与否由手机决定。RLP数据在Se

3、lector的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询问 RF Load manager 以某目标速率速率上传输

4、SCH给MS所需要的功率 RF Load Manager提供该速率所需的前向功率估计给TSM和MM/CPP TSM向Cache Manager申请符合申请速率的CE,WC和Backhaul资源 Cache Manager提供资源信息给TSM和MM/CPP TSM分配TS并告知SDU当前能力，RF Load Manager 周期性地估算每一个Time Slice的容量 TSM向RF Load manager请求gain boost 信道分配并激活gain boost三 兰州CDMA系统各类资源负荷分析1 PCF/Selector资源分析 摩托罗拉系统的PCF/Selector容量很大，一块PCF

5、板卡就可以处理1800个激活的数据呼叫和10200个dormant data call。从CBSC级的统计来看，PCF/Selector的利用率都比较低如下，目前PCF/Selector的资源不会成为制约数据业务的瓶颈。DSW and PSI-CE Utilization SectionMM | DSW Port Utilization | PSI-CE Utilization |ID | Allocated Total Avail Util% GF-Value | Config Erlang BBHH Util% GF-Value |= 9011 5812 8152 71.3 0.3325

6、832 207.8 14:30 25.0 2.80299014 6576 8152 80.7-P 0.1777 3448 498.0 11:30 14.4 5.5780 9016 6178 8152 75.8 0.2535 3368 384.3 10:00 11.4 7.3267 9017 5689 8152 69.8 0.3613 832 379.7 21:00 45.6 1.08192 WC资源分析WC属于基站载波扇区级的资源。每个载波扇区的Walsh code总数为64个（针对WC64而言。实际上1X的WC可以使用WC128），用于信令信道，语音信道，基本信道和补充信道。目前系统的每载波

7、扇区基本都配置了导频，同步，寻呼信道各一个，也就是说余下大概61各WC可以提供给业务信道使用。基本上每个语音呼叫占用一个语音信道和一个Walsh code。每个1X数据呼叫占用一个基本信道，一个补充信道和一个Walsh code，每个补充信道捆绑多个Walsh code使用，多个用户共享补充信道。语音和数据业务共享61个WC。对于Packet基站，数据库把61个可提供给业务信道使用的WC都配置到了Cache里。也就是说，对于Packet基站而言，Cache对于SCH的限制变小了。但同样，对于Packet基站，语音也可调用Cache里的WC，不再是只调用Cache外的WC资源。也就是说，对于Pa

8、cket基站，SCH可调用的Cache总资源增多，但Cache的资源不再只是数据业务独享，而同样可以随时被语音调用。这就意味着，当某载波扇区的语音用户非常多时，虽然Cache里配置的WC很多，但数据业务也会分配不到所需的WC资源。对应不同的RC(RC3/RC4)，前向不同速率SCH的CE和WC的占用情况并不一样。RC3占用资源多，但抗干扰能力强，RC4占用资源少，但抗干扰能力差。下表为前向RC3/RC4时的CE和WC的占用情况FWD RC3FWD RC4Rate (Kbps)CEsWC LengthRate (Kbps)CEsWC Length9.61649.6112819.223219.21

9、6438.441638.423276.88876.8416153.6164153.688从上图看到，当FWDRC3时，要达到153.6K（16X），需要占用16个CE,一个WC4(也就是说16个WCWC64)；当采用RC4时，要达到16X，只需要占用8个CE，一个WC8(也就是说8个WC64)。我们现网上行用的是RC4配置，下行用的是RC3配置。3 数据业务WC负荷情况：1）Forward拥塞情况MMBTSSCarBHRqstsRF BlksWC Blks(RF+WC)Blk%9017743228321184248396321.6901771212832118338120394722.2901

10、11332283221809350309317.4901112832832217859228273916.69017744128314155123253216.39017712328321156586225714.5901772722832217042936184316.39017747128319137360182813.3901111232831314900288175413.790113512831013435626156116.3901778512832113102512989.9901771312831718479100594310.5901771322831417993433882

11、7.39017724228320180131048205.19017719228322144073135986.39017721128321108004225729.290116128312159833465615.790113522831299174195279.5901774132831614441385233.99017735128321241537585035.29017719128310726104906.79017751328311219014113.4901772012832216883163492.290177193201221201103242.790177243283221

12、086103032.890177442283211056202812.79013319228314135052102543.4901774822831711397257824424.890177431283201105002272.19017750128321126897481947.490111012283221028501871.8901774532832060551591875.79017729228320106641011872.790177531283181421421771.390114222832215032232215816.590177122283229134581482.3

13、9011401283229396631382.1901111222831396765771207.290113322831591544611196.390113112832283042361124.290113122830125054871014.7901772132832110241926101109017726328322899001001.12）Reverse拥塞情况MMBTSSCarReverseBHRqstsBlksBlk%9011373283207370736399.990162192283109518950799.990162071283233205320399.99011551

14、283191402139999.890162232283231133113199.890177142283142867285999.7901442332011616516499.49017753128318559454259790177531201111445122985.190177142201213191256180.39017751120112115682971.79017723320110815871.690145132283211887131069.490111542283035520858.690177353283233826179146.890177152283203050139

15、145.690145131283102590114844.39013327220101205344.29017715328317102538437.590133281201215074176934.990111012283223948124731.69014441228315220863128.6901778212838195549225.2901481283195135113122901773132830400887421.89014536320118283254719.39017715128316420780319.19011185128321124020916.9901483201201

16、21818815.490177533283193156474159017751128320647293614.5901155228316209230114.4901778812830546173913.59017748128311231023810.390133061283191571157104 MCC资源分析MCC属于基站共享资源。95话音优先占用95CE，当95CE溢出时，才占用1X CE。1X话音优先占用1XCE，当1XCE溢出时，才占用95 CE，建立95Call。1X数据业务一般占用一个FCH和一个SCH，FCH只能占用1X CE，SCH占用MCC 1X里专门定义给SCH的CE。也

17、就是说数据业务的FCH和1X语音占用同样的1X CE资源，二者会相互影响。接着我们来分析兰州系统的MCC使用情况，看看是否会对1X数据业务产生影响。 可以通过查看TRF报告来查看MCC资源的使用情况。TRF报告里头与MCC资源相关的报告包括：总的TCH使用情况报告和MCC 1X使用情况报告两部分。 首先，来看看总的TCH使用情况报告。从BBH TRAFFIC REPORT - All Carrier Groups报告可以看到，基本上长春全网的TCH负载并不高，平均水平大概在40左右。只有少数的微蜂窝基站的总TCH 负载过高。也就是说总的TCH的容量没有问题，还富有余量。接着，来看看MCC 1X

18、使用情况报告。从BBH TRAFFIC REPORT - 1X Carrier Groups报告可以看到，MCC 1X的负荷与之前的TCH总负荷并不对称，不少MCC 1X的负荷偏高，但该站总的TCH负荷并不高。 下表为系统中1XMCC和95MCC板卡的负荷非常不均衡的基站：MMBTS1XTCHlaod%TCHload901620187.129.5901440585.529.8901624682.744.190111288241.790177128243.8901450780.424.1901620778.242.3901450376.726.6901450272.931.490113272.3

19、35.9901440869.846.8901451067.328.8901441865.929.9901774363.437.2901440963.133.7901441562.832.8901449062.145.1901450861.832.6对于这些1XMCC负载偏高的基站，如果其总的MCC负载不高，则对语音业务并不会产生影响，但可能会影响到数据业务的接入和切换，从侧面降低数据的速率。 四 兰州数据业务指标统计1 兰州地区数据业务话务量统计：兰州地区数据业务与语音业务全天话务量对比：图中蓝线为全天24小时语音业务的WC话务量。粉线为数据业务WC话务量。图中蓝线为全天24小时语音业务的XC

20、话务量。粉线为数据业务XC话务量。XC话务量为WC话务量去掉所有切换话务量后的话务量。可以看出数据业务的切换话务量要比语音小很多，数据业务XC话务量比语音稍低。2、兰州地区全天数据业务指标：Forward由上图可以看到每天下载数据业务忙时为21点左右，总下载数据流量为7600Mbytes左右。由以上两张图可以看出，兰州4个CBSC的平均下载速率为110左右，在全天数据流量较低的时段平均速率相对校高。可以说明平均速率与网络繁忙与否有一定的对应关系。March Rate 为用户申请所有速率SCH的成功率。由以上两张图可以看出，兰州4个CBSC的平均Match Rate在90%左右，在全天SCH申请

21、次数较低的时段Match Rate相对校高。可以说明Match Rate与网络繁忙与否有一定的对应关系。Reverse由上图可以看到每天上传数据业务忙时为21点左右，总下载数据流量为6200Mbytes左右。比下载数据流量小1000Mbytes左右。由上图可以看到所有CBSC的上传平均速率为50kbps左右，全天速率比较平均。五 兰州CDMA数据业务参数检查1、WC参数设置及数据业务功能开关检查BTS IDSectorCarrierCarrier_TypeWalshCodeCache1xData521283Normal600off95BTS522283Normal600off95BTS5312

22、83Normal600off95BTS532283Normal600off95BTS1463283Normal600offPrecut1481283Normal600off95BTS1482283Normal600off95BTS1521283Normal600off95BTS1522283Normal600off95BTS1971283Normal6016off2271283Normal600off95BTS2272283Normal600off95BTS2273283Normal610off95BTS2491283Normal600off95BTS2492283Normal600off95

23、BTS2501283Normal600off95BTS2502283Normal600off95BTS所有1X基站的WC配置都正常只有个别基站为保证语音业务只给数据业务预留8个WC。在检查基站数据业务功能时，只有BTS197的数据业务功能为OFF，即不支持数据业务的请求。该站其它有关数据业务的参数设置都为正常，现已将其数据业务功能打开。其它没有打开数据业务功能的基站都为95基站，BTS146第三扇区BBX被Precut掉，为扇区不存在。2、兰州基站数据业务功能检查兰州市所以PKT基站都没有MCC丢失IP的问题，在检查所有C-BTS MCC（MAWI） IP情况发现BTS36 的MCC-1 没有

24、IP地址，无法接受数据业务的请求：gsomc-000601 status MCC-36-1 add TELSTATE=INS_BUSY PROCEDURE=NONE PHYSTATE=INS HDWR_TYPE=MCC1X DEVICE_ASSUMED=NONE IP_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-00PERM

25、_ACTIVATED_RESOURCES=0处理后： MCC-36-1 08-11-14 17:16:38 gsomc MM-9011 M000666.00003 325524/589995 INFO:25 MCC Status Response TELSTATE=INS_BUSY PROCEDURE=NONE PHYSTATE=INS HDWR_TYPE=MCC1X DEVICE_ASSUMED=NONE IP_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-00PERM_ACTIVATED_RESOURCES=03、基站Resource Group检查：多数基站通用Resource Group settingMCCCSMF