《無錫聯通CDMA1X數據業(yè)務優(yōu)化報告.doc》由會員分享，可在線閱讀，更多相關《無錫聯通CDMA1X數據業(yè)務優(yōu)化報告.doc（59頁珍藏版）》請在裝配圖網上搜索。

無錫聯通CDMA1X數據業(yè)務優(yōu)化報告 無錫CDMA1X數據業(yè)務優(yōu)化項目組 2005年12月1日 目 錄 1．前言 4 2．優(yōu)化工作概述 4 3網絡性能指標前后對比情況 5 3．1系統部分指標 5 3．2無線部分指標對比分析 7 4 無錫數據業(yè)務分布分析 10 4．1數據業(yè)務話務分布圖 10 4．2 無錫載波分布圖 12 5．專題優(yōu)化 12 5．1啟用283頻點數據業(yè)務功能 12 5．2 Walsh Code Cache Count參數合理化調整 15 5．3 RAS門限的優(yōu)化調整 17 5．4 RC配置的優(yōu)化調整 18 5．5 前向SCH誤幀率的優(yōu)化調整 21 5．6 前向SCH功控增益的優(yōu)化調整 27 5．7 BTS CPU OVLD問題的分析 31 5．8 反向SCH指配失敗RF CPCTY問題 34 5．9 RLP零速率的初步分析 40 5．10 RLP的NAK機制優(yōu)化分析 42 5．11 MTU優(yōu)化分析 43 6．無線專題 46 6．1 問題路段處理 46 6．2 太湖大道優(yōu)化對比 57 6．3 新區(qū)優(yōu)化對比 65 7．結束語 69 1．前言 無錫CDMA1X數據業(yè)務優(yōu)化項目采用由省分技術支持中心牽頭，無錫市分公司、第三方（大唐移動）參與的聯合優(yōu)化方式，利用19天（從11月7日到11月25日）的時間完成對無錫分公司CDMA1X網絡數據業(yè)務的優(yōu)化，此項目為數據業(yè)務的初步優(yōu)化，主要工作包括對數據業(yè)務相關參數的優(yōu)化調整、對現網參數設置的檢查，路測問題點調整、太湖大道專題等。優(yōu)化目標是解決目前網絡上影響數據業(yè)務速率的明顯問題，通過本次優(yōu)化提高了無錫CDMA網絡的數據業(yè)務速率。由于本次優(yōu)化時間較短，優(yōu)化的范圍為無錫主要城區(qū)、太湖大道和新區(qū)。 2．優(yōu)化工作概述 本次優(yōu)化主要完成的工作如下： 系統部分 1． 建立無錫網絡話務模型，對無錫CDMA網絡數據業(yè)務情況進行細致了解，對無錫的1X網絡性能做了系統的分析。 2． 啟用283頻點數據功能。起到了平衡201頻點話務量，減少了手機在單載波和雙載波區(qū)域間發(fā)生硬切換的幾率，避免出現因手機進入Dormant狀態(tài)速率為0的情況，提高了整網平均速率，尤其改善了這些邊界區(qū)域數據業(yè)務用戶的上網感受。283頻點數據功能打開后有效的分擔了201頻點的話務量，減少了大量單雙載波間切換手機進Dormant的情況， SCH指配失敗中的RF BLKS得到了較大降低。具體內容見相關優(yōu)化專題。 3． 雙載波基站Walsh Code的優(yōu)化調整。將無錫OMC下的81個雙載波基站的兩個載波的Walsh Code Cache Count由原來的16調整為32，考慮到目前無錫網絡的話音話務量較小，話音沒有出現Walsh Code擁塞，剩余的32位Walsh Code完全可以滿足話音用戶的使用需求。因此該調整不會對話音用戶造成影響，沒有出現CFC20的情況；三載波基站Walsh Code的優(yōu)化調整。將無錫OMC下的37個三載波基站第三載波242頻點的Walsh Code由原來的32調整為40。目前三載波區(qū)域的242頻點設置為只承載數據業(yè)務，調整為40能夠更加充分的利用現有資源，提高系統利用率。剩余的Walsh Code足夠滿足低速數據業(yè)務（例如web業(yè)務），調整后沒有出現Walsh Code擁塞的情況。 4． RAS門限的優(yōu)化調整與對比。RAS是專門針對SCH來設計的，可以通過控制主導頻的個數的方法來提高數據的吞吐量。項目組進行了幾組RAS調整并對各種RAS設置下網絡進行了前后對比測試，及網絡統計報告跟蹤分析。最終確定將無錫網絡的前向RAS門限值設為3。在該門限下資源占用更合理，對于提高匹配率，提高降速分配率，減少RF BLKS都有較明顯的效果。 5． RC配置的優(yōu)化調整。檢查后發(fā)現無錫OMC下的幾個CBSC的FWDBASE和FWDSCH有的設置為RC3,有的設置為RC4。這樣導致了手機在不同的RC之間切換為硬切換。且在RC4中用到128位Walsh Code，Walsh Code的資源是增加了，而一個16倍速的SCH只需用到8位Walsh Code，但是由于擴頻增益減小，對射頻的要求會更高。目前的話務量情況下，信道資源未發(fā)生溢出，因此使用RC3更加合理。 6． 對SCH的外環(huán)功率控制參數前向SCH的目標FER做調整，對于高話務地區(qū)采用寬松的目標值，對于低話務地區(qū)采用嚴格的目標值，這樣可以充分的利用載波功率來維持鏈路的質量。 7． 對SCH前向增益的調整，避免在無線差的地區(qū)產生震蕩，使得fer向target以下改善，從而也影響前向的傳輸速率。 8． 對系統中出現的部分基站cpu overload進行分析，研究，發(fā)現產生cpu overload的GLI版本是2.0的，按照motorola的數據證明2.0版本的cpu處理能力要明顯差于3.0版本的，我們對401基站做了實驗，結果cpu overload消失，建議問題基站更換為3.0版本的GLI。 9． 對系統中出現的反向SCH分配時的RF Block進行了分析，研究，發(fā)現反向RF Block基本與話務量走勢一致，問題小區(qū)的分布無規(guī)律，大致認為是話務高和用戶分布引起的，但也不排除是帶外噪聲導致的。 10． 對網絡中出現的RLP零速率進行了初步分析。 11． 對RLP的NAK機制的研究。 12． 對網絡MTU的研究。 無線部分 1． 對無錫城區(qū)進行評估測試 2． 配合系統側對修改的參數進行對比測試 3． 對新區(qū)和太湖大道做了詳細的測試分析，并按照實際情況做出了優(yōu)化調整。 4． 對網絡評估中發(fā)現的問題點進行分析并做出相應的解決方案。 5． 優(yōu)化前后整網的對比測試 3網絡性能指標前后對比情況 3．1系統部分指標 通過為期三周的優(yōu)化工作，無錫聯通的CDMA1X網絡數據業(yè)務功能各項指標都有了不同程度的改善。下表為無錫兩個OMC下基站前后三天的幾項重要指標對比： 優(yōu)化前三天：11月5日至11月7日 優(yōu)化后三天：11月23日至11月25日 1，SCH分配成功率分析 數據來源： DATA報告 BTS SCH Resource Allocation – Forward 指標定義： Match Rate%: Number of data rate matches / (SCH Resource Requests - Cancels) Lower Resps: Number of times BTS responded with a lower data rate than requested Total Fail%: SCH Allocation Failures / (SCH Resource Requests - Cancels) 統計指標 11月2日 11月3日 11月4日 11月23日 11月24日 11月25日 Match Rate% 70.88 69.82 70.16 73.35 72.48 70.74　 Lower Rate% 17.93 18.94 18.54 14.16 14.99 14.91　 Total Fail% 10.31 11.19 10.95 10.96 10.51 10.66　 SCH分配失敗原因： RF Cpcty Walsh Codes MCC BW MCC CE 11月2日 1733572 7043 552 392 11月3日 2021255 11302 884 846 11月4日 2108130 10595 2561 880 11月23日 1672832 4 88 164 11月24日 1660230 5 1227 1096 11月25日 1504693 11 85 43308 注：11月24日BTS-402出現Mcc_BW原因的失敗932次/BTS404出現Mcc_BW原因的失敗285次;11月25日BTS-330出現Mcc_CE原因的失敗43189次，所以這兩天的fail次數異常。 指標說明： 從優(yōu)化前后三天的對比情況來看，經過為期三周時間的系統參數調整，SCH請求的匹配率得到了一定程度的提高，優(yōu)化前三天匹配率在70%以下浮動，優(yōu)化后匹配率基本上能夠達到72%以上。匹配率越高說明申請的速率被成功分配的幾率越高，對提高整網的速率有重要的作用。降速分配率從18％左右下降到14％左右；對于RF容量原因導致的SCH申請失敗也有很大程度的減少，這說明我們打開283頻點數據功能等措施的實施有效的提高了SCH分配成功率，數據業(yè)務的速率也相應提升。 2，分配速率分析 數據來源： Data報告 BTS and Data Rate SCH Resource Allocation – Forward 該表中的取值方法，所有基站不同速率的SCH USAGE值除以基站所有速率的SCH USAGE得到每個速率所占比例。 速率 11月2日 11月3日 11月4日 11月23日 11月24日 11月25日 9.6kbps 17.91% 18.77% 18.66% 15.03% 15.04% 15.20%　 19.2kbps 5.56% 5.29% 5.51% 5.65% 5.05% 5.16%　 38.4kbps 8.94% 9.12% 9.05% 9.03% 8.31% 8.43%　 72.6kbps 16.76% 17.39% 17.07% 18.21% 17.78% 17.35%　 153.6kbps 50.83% 49.43% 49.71% 52.08% 53.83% 53.87%　 數據分析： 從上面對不同速率的分配比例來看，在優(yōu)化后16X，8X的分配比例都有了一定程度的提高，這與我們將RAS門限從6調整到3有關。說明將SCH進入激活集的門限提高后，能夠有效的提高一部分用戶的16X和8X的分配比例，對于提高整網平均速率有重要的意義 3．2無線部分指標對比分析 數據業(yè)務和話音業(yè)務存在較大的差別，用戶感受更多的是在業(yè)務層，比如瀏覽一個網頁、下載某個文件的快慢，而影響這些速度的不僅是無線側的原因，在有線側它可能要經過很多的路由節(jié)點。而我們目前更多的是保證在RLP層有較高的吞吐量。我們認為目前衡量和評估某個網絡的性能主要還是通過無線測試。 通過Agilent路測儀表獲得的評估指標 Avg.radio Link Throughput(Rx)：無線鏈路（RLP層）平均吞吐量 Avg.Ec/Io：平均Ec/Io Avg.Receive Power：平均接收功率 Avg.Transmit Power：平均發(fā)射功率 Avg.FER (SCH0)：平均誤碼率 在無錫聯通的積極配合下，我們對無錫城區(qū)和新區(qū)進行了數據路測,測試項目組使用的是AgelentE64XX儀表，后臺使用Actix軟件進行分析，本次測試幾乎覆蓋了無錫城區(qū)數據數率高的區(qū)域。 測試指標統計 優(yōu)化前無錫的總體指標為： EcIo_Combined ReceivePower TransmitPower ForwardFER_SCH0 Throughput -6.18 -62.02 -16.24 1.51 98.11 優(yōu)化后無錫的總體指標為： EcIo_Combined ReceivePower TransmitPower ForwardFER_SCH0 Throughput -6.38 -60.59 -17.96 2.04 100.86 數據分析 從上表我們可以看到，調整前無錫的無線鏈路(RLP層)平均吞吐量為98.11Kbytes。各個速率上的平均Ec/Io在-6dB左右，平均手機接收功率在-60dBm左右，說明測試區(qū)域內的無線覆蓋情況良好。手機發(fā)射功率平均在-16dBm左右，SCH0的平均誤幀率比較低，平均在1.51％左右。而在我們優(yōu)化結束后所做的統計顯示下載速率達到了100.86Kbytes，大約提高了2K，FER由優(yōu)化前的1.51％左右升高到2.04％左右，是因為我們把RAS由6調整為3，減少了SCH激活集內的導頻數目，而那些不提供SCH的PN則造成了干擾，使得FER有小幅度的升高。 EC/IO的前后對比為： 調整前 調整后： 經過全網測試，我們找出了一些Ec/Io不好的路段，并它們進行了分析，由于時間關系只對部分問題點做了調整，而大部分的問題點以解決建議的形式提交給無錫聯通，通過問題點的調整時網絡的Ec/Io有了一定的改善。 進行了調整。 下載瞬間速率前后對比為： 調整前 調整后： 通過全網的測試分析，我們也找到下載速率低的路段進行分析，并對它們提出了調整建議，使網絡得到了改善。 4 無錫數據業(yè)務分布分析 4．1數據業(yè)務話務分布圖 數據來源：Moto系統統計報告 說 明：下面三個圖是我們從Moto系統統計報告中取出的各基站扇區(qū)一周平均的數據業(yè)務話務量的分布圖，這項指標表明了目前無錫CDMA1X數據業(yè)務的分布情況。由于無錫地區(qū)面積較大，我們只截取了三個基站比較集中的城區(qū)、縣城來表示。 圖中紅色表示該扇區(qū)1XPkt的WC Usage長度為500 Minutes到1000 Minutes（每天） 圖中黃色表示該扇區(qū)1XPkt的WC Usage長度為300 Minutes到500 Minutes（每天） 圖中藍色表示該扇區(qū)1XPkt的WC Usage長度為100 Minutes到300 Minutes（每天） 圖中綠色表示該扇區(qū)1XPkt的WC Usage長度為0 Minutes到100 Minutes（每天） 圖例說明同上圖 圖例說明同上圖 數據分析 從上面的話務量分布圖上我們可以看到，無錫的話務最高區(qū)域在人民路一帶，這里也是無錫市區(qū)中心，用戶最集中，目前是配置了三載波的基站覆蓋這里。周邊話務量稍低的地區(qū)則大部分由雙載波基站覆蓋。說明目前無錫的網絡配置與用戶話務量的分布基本上是吻合的。 4．2 無錫載波分布圖 數據來源：無錫CDMA基站數據庫文件 說 明：為了更直觀的看到目前無錫CDMA網絡基站的載波配置情況，我們從數據庫中導出不同載波的基站，并用MapInfo的方式在地圖上清晰顯示，從圖上我們可以看到三載波區(qū)域主要分布在鬧市區(qū)，兩載波基站主要覆蓋次級城區(qū)，單載波基站主要覆蓋在城郊結合部，這種配置與前面1X Pkt WC占用時間長的基站（即數據業(yè)務量高低）分布基本吻合。從圖上我們也可以很直觀的劃分出載波邊界區(qū)域。 數據分析 從上面不同載波的分布圖，結合數據業(yè)務量高基站的分布圖分析發(fā)現數據業(yè)務高的基站基本上都在三載波區(qū)域。這說明目前的網絡配置與數據業(yè)務話務分布是基本吻合的。 5．專題優(yōu)化 由于江蘇省公司已經對前期有效果的參數做了統一修改的要求，所以前面的5.1-5.4只是針對所修改的幾項參數做簡單的描述和對比。 5．1啟用283頻點數據業(yè)務功能 調整背景： 經過項目組對目前無錫網絡的設置情況進行了檢查，發(fā)現目前無錫不同的載波區(qū)域的數據與話音設置情況如下： 覆蓋類型 283 201 242 三載波 Voice only Voice only Data only 兩載波 Voice only Voice and Data 單載波 Voice and Data 表一：無錫載波功能設置情況 根據CDMA1X原理，無論是Hasing到283還是201頻點的手機在進行數據業(yè)務時在單雙載波基站間來回切換時都會進入Dormant（休眠）狀態(tài)，在這種情況下用戶數據流量會降為0，嚴重影響用戶上網的速率。項目組建議打開283頻點承載數據功能的另外一個重要原因是目前這種設置對這兩個載波的話務量平衡存在一定的隱患。 我們在南京和蘇州已經進行了同樣的調整，從測試的情況來看，與我們事先預計的情況相符合，不會對話音業(yè)務造成任何影響，在測試過程中沒有發(fā)生接入失敗和掉話情況，并且可以大量減少休眠的情況，載波邊界的速率得到了很大的提高。 手機Hasing頻點 跨載波情況 修改前 修改后 283 單載波-->雙載波 休眠 不休眠 雙載波-->單載波 休眠 不休眠 修改后雙載波-->未修改雙載波 不休眠 休眠 未修改雙載波-->修改后雙載波 不休眠 不休眠 雙載波-->三載波 休眠 休眠 三載波-->雙載波 休眠 休眠 201 單載波-->雙載波 休眠 休眠 雙載波-->單載波 休眠 不休眠 修改后雙載波-->未修改雙載波 不休眠 不休眠 未修改雙載波-->修改后雙載波 不休眠 不休眠 雙載波-->三載波 休眠 休眠 三載波-->雙載波 休眠 休眠 從上面的表格中我們可以看到，通過打開283頻點數據業(yè)務功能，單雙載波間切換休眠降低了3/4。對整網速率的提高尤其是單雙載波邊界用戶的速率提高起到非常積極的作用。 下表中列出了修改的具體基站： BTS ID Site Name BTS ID Site Name BTS ID Site Name BTS ID Site Name 102 NanQiao 301 ShanBei 1109 DongFangMingZhu 1210 Xinkezhan2 107 HeLieXiang 306 ZhuangQian 1112 ChaDong 1211 YaoSai 112 OuZhouCheng 318 GuangFeng 1118 JinSanJiao 1213 Wenmingguangchang 113 LiYuan 326 shuanghexincun 1124 YXChengBei 1216 PuQiao 115 HeLieKou 335 xiaotiane 1132 DongHong 1219 FaErSheng 116 liqiao 369 MenLou 1133 YangXian 1221 Shiyouzhengju 135 xinshijiyingcheng 401 WangZhuang 1135 QiXiangJu 1222 HuaShan 137 Luzhuang 403 KaiFaQuNan 1136 ShuiLiJu 1224 CheGuanSuo 147 ShuiXiu 404 taihuhuayuan 1137 Taipingyangdasha 1226 ChengXi 148 ZhongQiao 405 HuaFeiQiao 1138 Wujudayuan 1227 QianJinQiao 161 Qinyuan 406 Chunfengcun 1162 Baotacun 1234 Gangkou 164 xiadianqiao 422 DongTing 1178 pengyao 1238 JunShan 167 xijiao 424 ChunXing 1201 ChengNan 1239 zhigongdaxue 168 Xiajiabian 429 Wuxiqixiangju 1202 JYChengBei 1241 lvyuan 179 sezhichang 431 sizhuang 1203 XingCheng 1242 damaichang 180 liyuandianlanchang 439 ninghaili 1206 Jiangyinchengzhong 1244 xianfeng 189 kaiguanchang 1101 JiaoQiao 1207 ChengJiang 1401 MeiYuan 199 Tiyuzhongxin 1102 Haiguan 1209 JiYang 1407 Taihufandian 下面我們從PM-Data統計分析來評估參數修改對系統性能的影響。 Date 2005-11-1 2005-11-2 2005-11-17 2005-11-18 Frequency Voice 1XPkt Voice 1XPkt Voice 1XPkt Voice 1XPkt 283 31149.8 48.1 30856.6 4.3 29972.3 5294.1 30518.6 4835.6 201 17861.5 6257 16999.2 6318.1 17521.8 3018.1 17187 2182.5 數據來源：PMTraf Report 上表我們對調整前后兩個載波（201、283頻點）語音和數據業(yè)務量的分布情況進行了統計。從上面的統計表格中我們可以看到。目前無錫的CDMA網絡采用Hasing算法，手機會根據各自的IMSI號駐留到不同的頻點上。從修改前的統計報告上看201頻點的話音業(yè)務量比283頻點的話音業(yè)務量低1萬多次，而283頻點只有幾個基站打開了數據業(yè)務功能?？紤]到雙載波區(qū)域大多數基站的283頻點數據功能未開，隨著網絡中數據和話音用戶的增多，201頻點上要同時承載話音和數據業(yè)務，導致話務分布不均衡，影響網絡性能。從統計表格上看在打開283頻點數據功能后，數據業(yè)務流量被分流到兩個頻點。 我們也對系統的幾項性能指標進行了跟蹤統計，我們取了修改前后兩天的情況進行了對比。如下表： Date Match Rate% Lower Rate% Total Fail% RF Cpcty 11月1日 70.60 17.83 11.29 5715.60 11月2日 71.10 17.98 10.93 5350.53 11月13日 74.29 14.16 11.58 4793.64 11月14日 75.45 13.57 11.01 5045.48 從上面的對比表中我們可以看到，經過參數的調整，數據業(yè)務的匹配率，降速率都得到了不同程度的優(yōu)化提升。 調整效果跟蹤： 我們將283頻點的數據功能打開后對分擔載波話務量有非常大的作用，充分利用了現有資源，減少了大量的RF BLKS情況，提高了網絡性能。并且在網絡現有資源情況下，有效的提高了系統利用率。 5．2 Walsh Code Cache Count參數合理化調整 調整目的 提高1X數據業(yè)務SCH分配速率。考慮到目前雙載波和三載波基站的Walsh code配置存在不合理的情況，為了合理利用現有網絡資源，達到網絡配置的最優(yōu)化。 參數含義 Walsh Code Cache Count Data Label: WcCacheCnt Data Definition: The number of 64 bit Walsh Codes to cache at the BTS for Forward Supplemental Channels. The value must be an even number within the domain. The MM will translate this into an array of up to 5 walsh code branches defined by Walsh Code length and id. This array wll be downloaded from the MM to the GLI and MAWI. The walsh code branches allocated for this purpose are those corresponding to the 4 bit walsh codes 2 and 3 and the 8 bit walsh codes 4 and 5, since they have no walsh codes allocated for non-traffic. The MM will allocate any branches that will yield a total number of walsh codes equal to WcCacheCnt, such that the number of branches is minimized The branches must not overlap. Data Range: 0-48 Data Default: 0 Target Subsystem: BTS 網絡現狀 目前無錫CDMA網絡中的三載波基站242頻點的“WcCacheCnt”設置為32，雙載波基站283頻點的“WcCacheCnt“設置為16。 調整思路 調整雙載波基站283頻點的“WcCacheCnt”設置為32。 調整三載波基站“WcCacheCnt”設置為40。 當Walsh Code設置為16時，只能提供一個16X的SCH。又由于TSM分配的機制決定了只能由兩個用戶共享一個16X的SCH。當兩個用戶時分一個16X時，速率會從100kbps左右下降到70kbps左右。當修改設置為32后測試，可以同時分配給兩用戶16X，速率都能夠達到100kbps以上。 調整命令 調整242頻點“WcCacheCnt”為40： EDIT CARRIER-523-1-242 WCCONF WCCACHECNT=40 調整283頻點“WcCacheCnt”為32： EDIT CARRIER-523-1-283 WCCONF WCCACHECNT=32 調整效果跟蹤： 按照上面的方案調整了無錫的Walsh code cache count配置以后，我們對無錫的語音擁塞情況進行了關注，因為在單、雙載波區(qū)域話音和數據用戶要共享一個載波的64位Walsh Code，結果我們發(fā)現將單，雙載波的Walsh Code Cache Count改為32以后，那些語音話務量大的單、雙載波基站出現了不同程度的擁塞，即CFC=20?？紤]到以語音優(yōu)先的原則，我們建議將這些基站的Walsh Code Cache Count從32調整到24。使Walsh Code達到最優(yōu)化的合理配置。 我們將雙載波基站的兩個載波的Walsh Code調整為32的后出現了話音擁塞的基站找了出來，建議將相應的Walsh Code調整為24。 BTSID BTSID BTSID BTSID BTSID BTSID BTSID 1102 1120 1201 1212 1308 1418 1318 1104 1132 1202 1217 1310 308 1319 1110 1135 1203 1220 1311 318 1324 1111 1136 1204 1221 1312 329 1328 1112 1138 1205 1224 1313 330 1333 1116 1147 1206 1225 1314 402 1337 1118 1158 1208 1239 1315 411 1338 1181 1168 1209 1241 1317 1410 5．3 RAS門限的優(yōu)化調整 調整目的： 減少SCH軟切換，提高數據上傳下載速率 RAS是專門針對SCH來設計的,它的作用是通過控制主導頻的個數來提高數據的吞吐量，在語音呼叫的激活集PN的基礎上，選擇信號比較強的一個或幾個PN來進行數據傳輸。最高速率取決于其中提供速率最低的那個導頻。該項調整的目的是找到目前網絡覆蓋、話務承載情況下RAS門限的最佳設置值，由于用戶的分布和使用情況千差萬別，只能針對某些常用類型用戶的設置值。該機制只作用于IS-2000數據業(yè)務，不會對2G數據業(yè)務和2G話音業(yè)務起作用。而且在前反向鏈路上的門限是獨立的，不會互相影響。同時，由于提高了前向SCH分配的門限，使得一些信號強度不夠且變化快的導頻不能加進激活集，可以達到減少部分RF BLKS的目的。 參數定義 fwdrasthreshold 參數含義 Reduce Active Set，相當于Active Set的一個子集 The SDU includes, in the Forward Reduced Active Set, those call legs whose signal strength is within this threshold from the strength of the best leg. 現網值：6dB 取值范圍：0(30dB 步長：0.5dB 參數分析： 前向RAS功能對提高系統的前向Throughput有很大的作用，如果RAS設置過高，由于系統會根據提供數據速率最低的ACTIVE SET 來分配前向SCH，可能會使得前向Throughput變低并且占用更多WALSH Code和CE資源，如果RAS設置過低， 有可能會因為有導頻信號比較強的PN進不了SCH的ACTIVE SET而導致FER提高影響前向Throughput。 修改命令 Command: edit sdusdf-sdusdf# sdfschparms1 [fwdrasthreshold] [revrasthreshold] [tsdufwdresp] [tsdurvsresp] [minqueuesize] [maxqueuesize] [ratecontrolfactor1] [ratecontrolfactor2] 調整效果跟蹤： Date Match Rate% Lower Rate% RF Cpcty 11月5日 72.07 17.50 6721.14 11月6日 70.03 18.68 6913.58 11月20日 68.76 16.33 1616.90 11月21日 74.20 13.97 4706.64 我們可以看到，在進行了RAS門限進行了調整以后，使得系統的降速分配率得到了一定程度的降低，尤其是對減少RF Cpcty的情況效果非常明顯，這對提高整個網絡的性能，提高SCH的指配成功率有較大的幫助。 從以上的各項分析來看，我們對RAS門限參數的調整降低了SCH軟切換比例，節(jié)省了網絡資源，從整個網絡（統計的三載波、雙載波基站）的匹配率得到了提高，降速率得到了降低，高配速的比例也有一定程度的提高，從這些統計可以表明我們對RAS的調整有利于提高網絡平均速率，提高用戶滿意度！最后無錫網絡的前向RAS門限定為3！ 5．4 RC配置的優(yōu)化調整 調整目的 合理無線配置，提高系統利用率，消除不同RC間的硬切換 調整原理 RC4中用到128位Walsh Code，Walsh Code的資源是增加了，一個16倍速的SCH只需用到8位Walsh Code，但是由于擴頻增益減小，對射頻的要求會更高。而RC3中用的是64位的Walsh Code，對于一個16倍速的SCH需要用到16位的Walsh Code,擴頻增義增加，對射頻功率的需求低，但是對碼道資源的需求高。而經過對無錫的網絡進行了跟蹤分析后發(fā)現目前無錫網絡中經過項目組調整了Walsh Code配置后WC資源基本上沒有出現過溢出的現象。因此目前功率成為影響速率的更重要因素。還有一個重要的原因是，不同的CBSC在不同的RC配置下進行切換是硬切換。 網絡現狀 目前無錫各個CBSC的設置不完全相同，這導致了如果在不同RC間切換變成硬切換。 CBSC_ID FWDBASE REVBASE FWDSUP REVSUP 3091 4 3 4 3 3092 4 3 4 3 3093 4 3 4 3 3094 4 3 4 3 3031 3 3 4 3 3032 3 3 4 3 3033 3 3 4 3 3034 4 3 4 3 調整方案 將無錫CDMA網絡下的所有BSC的前反向補充和基本信道的RC配置全部調整為3。 調整命令 edit servopt-cbsc#-servopt# so1xcrc crcnum [fwdbase] [revbase] [fwdsup] [revsup] [for1xrate] [rev1xrate] 調整區(qū)域 CBSC-3031 CBSC-3032 CBSC-3033 CBSC-3034 CBSC-3091 CBSC-3092 CBSC-3093 CBSC-3094 調整結論： RC的統一配置調整是避免了不同RC間發(fā)生硬切換，根據現在網絡的用戶量不高，信道資源未發(fā)生擁塞的情況下，配置成RC3更加有利于提高用戶的上網速率。 5．5 前向SCH誤幀率的優(yōu)化調整 調整目的 降低1X業(yè)務的前向SCH誤幀率 參數含義 1x FFPC F-SCH FPC FER Data Label: FpcFER Data Definition: Target FER for Outerloop Setpoint at MS for F-SCH. Data Range: 0-10% Data Default: 5.0 Target Subsystem: MS Data Type: Fixed 現網狀況 現網的前向SCH的目標FER是5%. 調整思路 補充信道FER目標值的設置會直接影響到用戶吞吐量，甚至影響到整個網絡的吞吐量。 （1）如果FER目標值設置過高，比如20％，用戶吞吐量會因為頻繁的重發(fā)而明顯下降。但是在這樣的情況下手機要求的業(yè)務信道增益也隨之減小，即降低了對基站功率的要求。系統將有更多的資源為其他用戶服務。 （2）反之，如果FER目標值設置很低，比如1％，用戶吞吐量幾乎可以達到物理層吞吐量（忽略開銷信道）。但是業(yè)務信道增益也隨之增大，也就是說要占用基站的大部分功率。結果可能會導致基站不能容納更多的用戶，缺乏對其他用戶的公平性。 考慮到無錫現在數據用戶量較小，也就是說用戶同時在一個扇區(qū)使用數據業(yè)務（尤指CARD業(yè)務）的概率是相當小的。所以我們認為對基站來說可以為用戶分配更多功率來滿足用戶對吞吐量的要求。因為如果用戶得不到足夠的功率，FER將隨之被快速升高，導致在下一個時間片上系統將不能再為之分配高速率的SCH信道。從而最終導致用戶吞吐量較為明顯的下降。 調整方案 對于3031，高話務BSC，建議修改為3% 對于3033，低話務BSC，建議修改為2% 調整命令 edit fwdschgos-cbsc#-fwdschgos# schfpcparms Fpcschfer 調整區(qū)域 無錫市區(qū)的CBSC3031和3033。 調整效果跟蹤： BSC1的目標FER由5改為3后的前后對比為: 調整前 調整后 由上面總體比較可以看出，BSC1中FER由5改為3后，下載速率由104KBPS提到到了108KBPS，FER也由1.7%減小到1.5%，得到一定程度的改善。 16X分配比例： 調整前 調整后 由上面兩圖比較可以看出，16X分配降低了0.6個百分點，但8X分配增加了3個百分點，所以下載速率有所提高。 下載速率： 調整前 調整后 由上面對比圖可以看出，紅圓圈處的下載速率改善比較大。 FER對比為： 調整前 調整后 圖中紅泉內的FER得到了明顯地改善。 BSC3的FER由5調為2后對比為： 調整前 調整后 由以上對比可以看出，調整后FER雖然得到改善，但下載速率沒有什么變化，還下降了1Kbps。 16X分配比例： 調整前 調整后 由調整前后可以看出，16X的分配比例由74％降低到了60％，所以目標FER改為2反而影響了16X的分配。 下載速率對比: 調整前 調整后 由上面比較圖可以看出，下載速率基本沒有什么變化。 FER前后對比: 調整前 調整后 由上對比圖可以看出，紅圓圈處改變比較大。 5．6 前向SCH功控增益的優(yōu)化調整 調整目的 提高1X業(yè)務的前向速率 參數含義 fpcstepupsch - This is the parameter the MCC/MAWI uses to adjust the SCH FPC gain. The range is: 0.00 to 3.75. The default is: 0.50. This is an optional parameter. 網絡現狀 現網的前向SCH增益提升步長為0.5。 調整思路 當前向的Fer高于目標值時，網絡會調整前向SCH的增益，調整幅度為fpcstepupsch，我們認為當fer惡化時，無線環(huán)境應該是比較惡劣的，對于現在的網絡來說，fpcstepupsch和fpcstepdownsch都是0.5，這樣很容易在無線差的地區(qū)產生震蕩，使得fer無法向target逼近，從而也影響前向的速率。 前向SCH 增益 時間 在Ffer低于Fpcfer的時候，前向功率會適當的下降fpcstepdownsch，以減少干擾 當外環(huán)的Ffer高于門限時，前向功率會增加fpcstepupsch，用來維持目標的Fer fpcstepdownsch fpcstepupsch 根據其他系統的參數經驗，我們認為up的幅度應該大于下調的幅度，這樣的功控機制是更符合多變的無線環(huán)境。 調整方案 對于BSC3031，建議修改為1.0。 調整命令 edit fwdschgos-cbsc#-fwdschgos# schfpcparms 調整區(qū)域 無錫市區(qū)的CBSC3031。 調整效果跟蹤： 將BSC1的SCH0增益由0.5調為1后前后對比為： 總體情況 調整前： 調整后： 由上面對比可以看出，增益變大后，平均下載速率由101.97KBPS上升到了108.33KBPS，FER由2.7%變小到 1.5%，都得到改善。 16X分配比例對比： 調整前 調整后 由上面比較圖看出，16X的分配比例由78％增加到81％，增加了3個百分點。 下載速率對比： 調整前 調整后 從瞬間下載速率來看，總體上下載速率有所增加，但變化不是很大。 FER對比為： 調整前 調整后 上面兩圖顯示FER變化不太大，調整后紅色區(qū)域是因為手機故障導致。 5．7 BTS CPU OVLD問題的分析 BTS CPU OVLD:SDU向BTS發(fā)送SCH分配請求后等待基站回應的RES消息，如果超時會重發(fā)REQ，重發(fā)次數為maxsdutimeouts，如果再沒有收到RES，SDU將宣布該基站發(fā)生了CPU OVLD，導致SCH分配失敗，在基站側，如果GLI的負荷超過85%也是一次CPU OVLD。 調查背景： 通過檢查數據業(yè)務的相關統計報表，發(fā)現網絡中存在的問題。并對這些問題進行詳細分析并提出相應的解決建議。 調查細節(jié)如下： 1．我們首先通過檢查Moto的相關統計報告發(fā)現，無錫CDMA網絡CBSC-3034下面有10個基站因為BTS CPU OVLD的原因導致了前向SCH指配失敗次數很多，從表象上分析發(fā)現這些基站基本的BTSID較為連續(xù)。為401405以及409413。從MapInfo上我們可以看到這些基站的覆蓋范圍為泰山路、黃山路一帶。 2．為了對這些問題基站進行問題定位，看是否能夠找到它們存在共性的地方，我們考慮對這些基站的配置情況進行檢查 BTSID 載波配置 BTSID 載波配置 401 三個雙載波小區(qū) 409 三個單載波+Beacon小區(qū) 402 三個單載波+Beacon小區(qū) 410 三個單載波+Beacon小區(qū) 403 三個雙載波小區(qū) 411 三個單載波+Beacon小區(qū) 404 三個雙載波小區(qū) 412 三個單載波小區(qū) 405 三個雙載波小區(qū) 413 三個單載波+Beacon三個 我們看到CPU OVLD嚴重的這幾個基站包含了幾種類型：雙載波、單載波、單載波+Beacon它們的共同點是都可以在一個載波上同時承載語音和數據業(yè)務。 3．我們對這些基站的RF LOAD Manager參數進行了檢查，發(fā)現設置正常。 4．為什么在同樣的話務負荷或者更繁忙的基站卻沒有出現CPU OVLD情況？它們與問題基站又有那些區(qū)別呢？由于數據業(yè)務的資源指配都是由GLI CPU來進行處理的，因此我們接下來對無錫網絡中的GLI板卡類型進行了檢查，我們取11月10日無錫OMC-1的統計報告，將一天中所有出現了CPU OVLD的基站按照SCH請求次數進行了從高到低的排名（SCH請求次數前15位的基站用藍色標記）進行了統計，并對他們的GLI板卡類型進行了比較如下表： Reverse SCH Allocation Failures GLI板卡類型 BTS SCH Rqsts BTS CPU OVLD 135 208399 0 GLI3 160 196831 0 GLI3 161 234017 0 GLI3 206 192493 0 GLI3 207 187803 0 GLI3 209 229646 0 GLI3 221 291995 0 GLI3 227 234016 0 GLI3 246 216914 0 GLI3 256 430634 0 GLI3 257 364672 0 GLI3 258 212821 0 GLI3 402 177670 718 GLI2 404 245734 912 GLI2 418 193841 0 GLI3 401 134130 2851 GLI2 403 83827 392 GLI2 405 60379 246 GLI2 408 36450 12 GLI2 409 119683 136 GLI2 410 129551 189 GLI2 411 100617 324 GLI2 412 18224 22 GLI2 413 102092 103 GLI2 426 111530 113 GLI2 428 72662 41 GLI2 434 23171 11 GLI2 436 75518 74 GLI2 從上表中我們可以很明顯的看到，在該天的統計中有13個基站的SCH Rqsts次數與這幾個問題基站中SCH Rqsts請求次數接近或更高，但它們并沒有發(fā)生過一次CPU OVLD的情況。這說明在目前的網絡負載情況下SCH Rqsts請求次數高并不是引起這10個基站出現CPU OVLD的原因。同時我們在所有出現了CPU OVLD情況的BTS中，發(fā)現它們使用的GLI板卡類型是一致的都是使用的GLI2。 5．對這兩種不同類型的GLI板卡的性能差別問題，我們咨詢了MOTOROLA CNRC，他們的答復是兩種GLI板卡的CPU性能上存在著較大差異。在16.5版本，同樣的負荷情況下，GLI2的CPU使用負荷要明顯高于GLI3，大約是GLI3的兩倍左右，也就是說在同等話務負荷情況下，GLI2板卡的CPU會比GLI3板卡CPU更快的到達overload門限。使用GLI2板卡在業(yè)務高峰的時候，CPU的使用率很容易會超過它的門限，如果此時再有SDU請求SCH分配則會因為CPU OVLD，最終導致SCH指配失敗。兩種GLI板卡的CPU使用負荷性能情況如下圖： 從上面的兩種GLI的CPU負載使用率的性能對比圖上我們可以看到，在R16.5版本下，同樣在接入8個用戶的時候，GLI2的CPU負載率已經達到了40%多，而GLI3的CPU負載還只達到20%多。相差將近一倍。而且GLI2的上升曲線也比GLI3要陡。而GLI3在將來升級到R17.0版本以后的CPU使用負荷率還要更低。 于是我們挑選問題最嚴重的BTS-401基站進行調整，11月21日將該基站更換成GLI3板卡。之后我們對該基站的CPU OVLD情況進行了跟蹤。上表是對比調整前后的BTS CPU Ovld，發(fā)現CPU OVLD的情況消失。該問題得到解決。 Date Single&Multiple SCH Rqsts SCH Cancl BTS CPU Ovld SCH Usage(min) SCH Usage Mbytes 11月17日 586.5 351.7 57527 268 451 11月18日 483 291.1 46473 200 371 11月21日 190.7 128.4 18613 117 0 11月22日 359.4 248.9 35235 137 0 數據來源：.Dat報告BTS SCH Resource Allocation - Reverse 調整結論：出現CPU OVLD的基站都是使用的GL