資源描述：
《wcdma網(wǎng)絡(luò)優(yōu)化會戰(zhàn)案例匯編》由會員上傳分享，免費(fèi)在線閱讀，更多相關(guān)內(nèi)容在行業(yè)資料-天天文庫。
1、WCDMA網(wǎng)絡(luò)優(yōu)化會戰(zhàn)案例匯編目錄1、天饋參數(shù)不合理導(dǎo)致掉話32、擾碼復(fù)用不合理導(dǎo)致切換失敗53、路由器設(shè)置不當(dāng)導(dǎo)致下行速率慢84、SGSN接口板的光模塊故障導(dǎo)致上行速率慢115、切換參數(shù)設(shè)置不當(dāng)對HSDPA下載速率影響126、室分接入困難157、2G到3G重選不成功（一）178、2G到3G重選不成功（二）189、3G-2G切換失?。ㄒ唬?110、3G-2G切換失敗（二）231、天饋參數(shù)不合理導(dǎo)致掉話【問題描述】如圖所示，當(dāng)車輛行駛至如圖所示位置時，UE同時占用3個主導(dǎo)頻，RSCP都在-86dBm左右，Ec
2、/Io都在-9dB左右，而且相差較小，測試過程中發(fā)生掉話?！締栴}分析】為導(dǎo)頻污染現(xiàn)象。由于該路段周邊基站天饋參數(shù)不合理，導(dǎo)致出現(xiàn)較為嚴(yán)重的導(dǎo)頻污染，并且出現(xiàn)鄰區(qū)漏配情況，從而導(dǎo)致掉話發(fā)生。調(diào)整天饋，增加鄰區(qū)關(guān)系，解決掉話問題。【問題處理】經(jīng)將北玉豐70號_1、_2的電下傾角由0度/0度調(diào)整為2度/2度；將中菲大廈_1的電下傾角由6度調(diào)整為8度；對中誠大廈_1和北玉豐70號_1、對中誠大廈_1和北玉豐70號_2、對中誠大廈_1和電器成套設(shè)備廠_2、軍糧供應(yīng)站_3和電器成套設(shè)備廠_2互配鄰區(qū)；對電器成套設(shè)備廠_
3、2提升功率。調(diào)整完成后復(fù)測無掉話。下面是調(diào)整前后對比圖：調(diào)整前RSCP調(diào)整后RSCP調(diào)整前Ec/Io調(diào)整后Ec/Io2、擾碼復(fù)用不合理導(dǎo)致切換失敗【問題描述】發(fā)現(xiàn)多小區(qū)（超過3個小區(qū)）站點(diǎn)更軟切失敗是由擾碼復(fù)用造成的，新加信號的SFN_Frame_difference.off與老信號差2以上?！締栴}分析】經(jīng)研究，發(fā)現(xiàn)多為同擾碼小區(qū)的越區(qū)干擾，造成切換失敗。分析軟切失敗原因RNC3074下NodeBID180，10801質(zhì)檢大廈_1（PSC126），10802質(zhì)檢大廈_2（PSC134），10803質(zhì)檢大廈_
4、3（PSC142），10805萬嘉商務(wù)酒店（科技路）（PSC461），10806薩菲爾。從關(guān)聯(lián)日志中可以看到當(dāng)前小區(qū)為10805（PSC461），試圖更軟切10801（PSC126），如下圖（試圖加10801）所示。2009-07-1612：59：02測量報告內(nèi)容為：報1a加PSC126，當(dāng)前激活集里面的PSC461幀偏2，如下圖所示。但PSC126幀偏203，如下圖所示。我們之前看到的多小區(qū)站點(diǎn)出現(xiàn)軟切失敗都是激活集里先加后減（測量報告中各小區(qū)幀偏都一樣），先報1a，然后1b刪去不好的那條信號，之后就報無
5、線鏈路增加失敗。如上，多小區(qū)站點(diǎn)軟切失敗時是由擾碼復(fù)用原因造成的，當(dāng)然也有相當(dāng)數(shù)量的多小區(qū)站點(diǎn)軟切失敗是僅由激活集原因造成的?！締栴}處理】解決多小區(qū)站點(diǎn)軟切失敗的方法根據(jù)上面的分析，要解決多小區(qū)站點(diǎn)軟切失敗問題首先要改小區(qū)擾碼。修改擾碼情況如下表。小區(qū)ID修改前擾碼修改后擾碼10801126390108021343981080314240610805461435修改擾碼后，從2009-07-25從關(guān)聯(lián)日志中測量報告看到報1c，用390替換406，從下圖中可以看到新信號和老信號的幀偏只相差1。3、路由器設(shè)置不
6、當(dāng)導(dǎo)致下行速率慢【問題描述】外場HSDPA單線程下載測試，在無線質(zhì)量較好前提下，定點(diǎn)HSDPA單線程下載速率平均3Mbps左右且速率波動非常大。在RNC側(cè)對單個UE灌包測試，速率平均5.5Mbps比較平穩(wěn)，說明Iub口和空口沒有問題?！締栴}分析】從UElog來看，在CQI較好的時候，UE收到下行數(shù)據(jù)量不足。上圖紅框中數(shù)據(jù)為TSN標(biāo)識，標(biāo)識連續(xù)表明下行數(shù)據(jù)未有丟包。從UE側(cè)抓包看，存在大量TCP包亂序，在亂序后馬上會啟動快速重傳，對DPA的下載速率有很大影響。從UElog上看下行數(shù)據(jù)報RLCSN連續(xù)，不存在亂
7、序，排除Iub口引入亂序的可能。而Iu-PS在RNC《-》SGSN-《-》GGSN《-》PDN均采用IP傳輸，很有可能存在亂序。從圖中可以看到SGSN－1通過2個XK－CE－1到我們的RNC1、2、3，在CN側(cè)也設(shè)置了兩個路由，且兩個路由沒有優(yōu)先級設(shè)置，這樣包可能從任何一個路由到RNC，所以很可能產(chǎn)生亂序。為確定亂序可以在Iu口抓取報文或者在UIM上抓取報文分析，由于用戶較多在UIM上抓取報文存在問題，以下引用單線程下載速率分析的相關(guān)亂序判定數(shù)據(jù)。亂序報文判斷基本原則：收到GTPU內(nèi)部IP編號1，2，3，里
8、面承載的applicationIP報文（PDN）是A,C,B，說明PDN->GGSN亂了。收到GTPU內(nèi)部IP編號1，3，2，里面承載的applicationIP報文（PDN）是A,C,B。說明GGSN->SGSN->RNC亂了。在GUIM上現(xiàn)場抓取報文，分析如下：當(dāng)TCP亂序發(fā)生時，先收到GTPU外層承載IP報文IPID為0為0xe4ac，對應(yīng)承載原始報文IPID0X4905。再收到GTPUP外層承載報文IPI
