564501137浙江聯(lián)通WCDMA網(wǎng)典型案例分析

1、中國聯(lián)通浙江分公司wcdma網(wǎng)典型案例分析（20091001-20091015）（第二期）目錄案例一：紹興傳輸光端機(jī)未加線路時鐘保護(hù)導(dǎo)致基站線路時鐘源抖動異常案例3案例二：紹興快閣苑基站小區(qū)功率不一致導(dǎo)致基站license下發(fā)失敗案例5案例三：紹興科創(chuàng)大廈附近弱覆蓋引起掉話案例8案例四：湖州邊緣小區(qū)ps異系統(tǒng)切換參數(shù)修改后上網(wǎng)速度慢案例11案例五：湖州邊緣小區(qū)重選切換存在的問題案例14案例六：湖州基站誤碼導(dǎo)致基站bootp啟動偵聽失敗案例17案例七：嘉興多rru級聯(lián)底噪未更新設(shè)置導(dǎo)致hsupa速率偏低問題案例21案例八：寧波rnc前后臺數(shù)據(jù)不一致問題處理案例28案例九：舟山多普達(dá)d200用戶掉

2、話問題案例31案例十：湖州漫游用戶上網(wǎng)感知慢問題案例33案例十一：麗水ps業(yè)務(wù)上網(wǎng)速率12分鐘后降低到零問題案例38案例十二：溫州聯(lián)通龍灣機(jī)房干擾問題案例40案例一：紹興傳輸光端機(jī)未加線路時鐘保護(hù)導(dǎo)致基站線路時鐘源抖動異常案例案例編寫人：潘海龍 聯(lián)系電話：156575720581、 問題簡述紹興rnc6（v200r010c01b061）下新昌鼓山等14個站點(diǎn)開通后均有參考時鐘源異常告警 ,告警id：1008。在基站近端維護(hù)終端上用命令“dsp clkstat;”查詢時鐘狀態(tài)，顯示時鐘源異常，時鐘處于自由震蕩狀態(tài)；打開實(shí)時時鐘檢測，顯示時鐘源偏差較大。2、 發(fā)生時間和地點(diǎn)發(fā)生時間：2009-9-

3、8發(fā)生地點(diǎn)：紹興sxrnc06hw3、 原因分析wcdma基站時鐘精度（0.05ppm）要求較高，紹興基站時鐘源配置的是線路時鐘，基站從接入的2m線中鎖定獲取。（1） 從觀察到的現(xiàn)象看，問題站點(diǎn)屬于線路時鐘失鎖，基站啟用了自帶的晶體時鐘。這些站在同一rnc下，該rnc下其它站點(diǎn)（約100個）均正常，基本可以排除rnc側(cè)問題，那么問題有很大可能出現(xiàn)在傳輸和基站側(cè)。（2） 檢查基站2m線配置，和2m線狀態(tài)，均正常；用“l(fā)st lnksrc:;”檢查線路時鐘配置，無異常；（3） 該局基站默認(rèn)從配置的第一條2m線中獲取時鐘，考慮時鐘可能受到的傳輸質(zhì)量影響，嘗試更換時鐘獲取線路，如改從第二條2m線中獲取

4、時鐘，這樣做告警消失！但查詢時鐘狀態(tài)，顯示時鐘始終處于“快捕”狀態(tài)，無法鎖定，懷疑問題可能并未徹底處理掉。觀察約2小時后，告警復(fù)現(xiàn)。（4） 在傳輸網(wǎng)管上查詢這些基站，首先發(fā)現(xiàn)這些站在同一傳輸環(huán)下，懷疑該時鐘問題是同一原因所致。（5） 檢查傳輸時鐘，從傳輸網(wǎng)管“時鐘透視圖”中查看光端機(jī)時鐘狀態(tài)，發(fā)現(xiàn)問題站點(diǎn)下掛的光端機(jī)沒有線路時鐘保護(hù)，使用的是自帶時鐘，確定基站線路時鐘源抖動異常由此引起。4、 解決方案傳輸光端機(jī)加上時鐘保護(hù)，再檢查基站時鐘狀態(tài)，并觀察時鐘實(shí)時監(jiān)測，約10分鐘，基站線路時鐘鎖定，并且監(jiān)測到的時鐘無偏差，且?guī)讉€基站的時鐘異常相繼都消失，問題解決。5、 經(jīng)驗(yàn)總結(jié)在sdh網(wǎng)中，各個網(wǎng)元

5、通過一定的時鐘同步路徑一級一級地跟蹤到同一個時鐘基準(zhǔn)源，從而實(shí)現(xiàn)整個網(wǎng)絡(luò)的同步，遇到傳輸引起的時鐘問題，需要逐級，從下到上檢查nodeb傳輸經(jīng)過的傳輸設(shè)備時鐘設(shè)置，一般檢查傳輸設(shè)備的時鐘是否跟隨上級時鐘，傳輸環(huán)路有沒有異常。案例二：紹興快閣苑基站小區(qū)功率不一致導(dǎo)致基站license下發(fā)失敗案例案例編寫人：潘海龍聯(lián)系 方式：156575720581、 問題簡述在w網(wǎng)建設(shè)過程中發(fā)現(xiàn)越城快閣苑（bts3900 v200r010c01b067 ）基站小區(qū)業(yè)務(wù)測試正常，除商用license未下發(fā)外，無其他異常告警。但在通過m2000 （ v2r8c01b060spc008 ）向基站下發(fā)商用license

6、時失敗，提示“網(wǎng)元重新設(shè)置失敗”。如下圖所示：2、 發(fā)生時間和地點(diǎn)發(fā)生時間：2009-8-13發(fā)生地點(diǎn)：越城快閣苑基站3、 原因分析 （1） 通過m2000下發(fā)基站license失敗時常見的情況有：基站斷連，此時提示“網(wǎng)元未連接”；基站license資源分配與實(shí)際數(shù)據(jù)配置不一致，且往往問題都與小區(qū)相關(guān)，如配置了三個小區(qū)，而license控制項(xiàng)中只分配了兩個小區(qū)，又如小區(qū)功率實(shí)際開到47dbm，而 license分配的是43 dbm的小區(qū)，等等，此種情況一般會提示“網(wǎng)元重新設(shè)置失敗”。顯然，后一種情況的可能性較大。（2） 在rnc（v200r010c01b061）側(cè)運(yùn)行l(wèi)st cell，檢查rn

7、c中小區(qū)配置數(shù)據(jù) ，查到該基站配置了3個43dbm的小區(qū)，而m2000中l(wèi)icense資源與此一致，未發(fā)現(xiàn)異常。（3） 在基站側(cè)運(yùn)行 dsp cellcfg 檢查邏輯小區(qū)配置，3個小區(qū)，最大發(fā)射功率43 dbm，也未發(fā)現(xiàn)異常。（4） 詢問之前與該基站的相關(guān)操作，得知該基站小區(qū)功率曾經(jīng)調(diào)整到47dbm做測試，之后恢復(fù)到43dbm ，問題可能出在這次小區(qū)功率調(diào)整上。（5） 考慮到基站license的小區(qū)功率控制項(xiàng)控制的是基站本地小區(qū)功率，而非邏輯小區(qū)功率，并且業(yè)務(wù)正常的情況下本地小區(qū)功率和邏輯小區(qū)功率可能不一致。（6） 在rnc 側(cè)運(yùn)行 dsp cellchk查看nodeb上報的小區(qū)最大發(fā)射功率時

8、發(fā)現(xiàn)小區(qū)最大發(fā)射功率為47 dbm ，找到問題所在。4、 解決方案rnc側(cè)用dea cell先閉塞小區(qū)，用mod cell修改邏輯小區(qū)功率 ；在基站側(cè)用mod locell 把本地小區(qū)功率修改為43 dbm ；重新激活小區(qū)，并在m2000上分配基站license ，成功下發(fā)，問題得到解決。5、 經(jīng)驗(yàn)總結(jié)在檢查調(diào)整該基站功率的過程得知，原先在恢復(fù)小區(qū)功率的時候只在 rnc側(cè)運(yùn)行了mod cell把邏輯小區(qū)功率從47 dbm 調(diào)整到43 dbm，基站側(cè)未做過任何調(diào)整，顯然這樣做不正確。而正確的修改基站功率的操作過程是 ：先在rnc側(cè)用dea cell閉塞小區(qū) ；再在基站側(cè)用mod locell 修

9、改本地小區(qū)功率；最后激活小區(qū)。案例三：紹興科創(chuàng)大廈附近弱覆蓋引起掉話案例案例編寫人：石賢富聯(lián)系 方式：156575720481、 問題簡述dt測試過程中，發(fā)現(xiàn)科創(chuàng)大廈東北角由于切換不及時產(chǎn)生了掉話。2、 發(fā)生時間和地點(diǎn)發(fā)現(xiàn)時間：2009-09-16。發(fā)生地點(diǎn)：紹興越城城東科創(chuàng)大廈附近。3、 原因分析引起此弱覆蓋點(diǎn)的主要原因：科創(chuàng)大廈樓層較高，并且由于天線貼著樓面安裝，導(dǎo)致一扇區(qū)和二扇區(qū)間出現(xiàn)一小段的弱覆蓋區(qū)域，車輛高速行駛時候可能會出現(xiàn)因?yàn)榧せ罴鲁瑫r導(dǎo)致的掉話現(xiàn)象。4、 解決方案將科創(chuàng)大廈第一扇區(qū)采用功分器分裂一個扇區(qū)，并采用低增益的天線，覆蓋科創(chuàng)大廈的樓下，使問題得到解決。下圖為調(diào)整后復(fù)

10、測結(jié)果。5、 經(jīng)驗(yàn)總結(jié)天線的安裝條件往往由于一些客觀的外部因素，無法完全理想的進(jìn)行安裝。這時需要我們通過對無線知識的理解，靈活采用一些創(chuàng)新的方法，或?qū)⒁恍?g采用的方法引用到3g的建設(shè)及網(wǎng)優(yōu)中。本案例就采用了小區(qū)分裂的方法解決了弱覆蓋區(qū)。案例四：湖州邊緣小區(qū)ps異系統(tǒng)切換參數(shù)修改后上網(wǎng)速度慢案例案例編寫人：沈忠惠聯(lián)系 電話：156572726891、 問題簡述為了保證邊緣小區(qū)覆蓋區(qū)域業(yè)務(wù)的正常使用，現(xiàn)網(wǎng)對邊緣小區(qū)的部分異系統(tǒng)切換門限參數(shù)進(jìn)行了修改（cs業(yè)務(wù)異系統(tǒng)測量rscp啟動門限由-100dbm改成-95dbm，ps業(yè)務(wù)異系統(tǒng)測量rscp啟動門限由-110dbm改成-95dbm，cs業(yè)務(wù)異系

11、統(tǒng)測量rscp停止門限由-97dbm修改為-92dbm，ps業(yè)務(wù)異系統(tǒng)測量rscp停止門限由-107dbm修改為-92dbm），修改參數(shù)后能保證業(yè)務(wù)的連續(xù)使用，在覆蓋很差的區(qū)域能及時切換到2g網(wǎng)絡(luò)上。在參數(shù)修改后，個別用戶反映上網(wǎng)速度慢，收發(fā)郵件困難。2、 發(fā)生時間和地點(diǎn)發(fā)生時間：2009年8月19日。發(fā)生地點(diǎn)：長興科技創(chuàng)業(yè)園-1覆蓋方向的小區(qū)。3、 原因分析修改邊緣小區(qū)的異系統(tǒng)切換參數(shù)后，用戶反應(yīng)手機(jī)信號比以前好，但上網(wǎng)速度比以前慢了。在進(jìn)行現(xiàn)場測試時發(fā)現(xiàn)該用戶所在位置由于房屋阻擋，深度覆蓋不足，rscp值在-100到-108dbm內(nèi)波動，由于修改了異系統(tǒng)修換參數(shù)，該位置占用在2g網(wǎng)絡(luò)上。2

12、g的電平波動較大，在-85dbm到-97dbm之間，從3g切換到2g上后，上網(wǎng)速度有明顯的下降。由于2g的上網(wǎng)速度本來不高，加上占用在2g網(wǎng)絡(luò)上的用戶的增多，導(dǎo)致上網(wǎng)速度更加慢，有時連網(wǎng)頁都打不開。4、 解決方案由于邊緣區(qū)域rscp覆蓋弱，給用戶的直接感覺是信號格數(shù)少、信號差，所以調(diào)整了邊緣小區(qū)的異系統(tǒng)切換參數(shù)，使得覆蓋相對差的區(qū)域能占用在信號較好的2g網(wǎng)絡(luò)上。但占用在2g網(wǎng)絡(luò)上后，明顯的感覺上網(wǎng)速度慢很多，為了保證用戶的上網(wǎng)業(yè)務(wù)需要，我們恢復(fù)了長興科技創(chuàng)業(yè)園-1小區(qū)的ps異系統(tǒng)切換參數(shù)。具體調(diào)整方案如下：（1） 調(diào)整邊緣小區(qū)的ps業(yè)務(wù)異系統(tǒng)測量rscp啟動門限為-110dbm。（2） 調(diào)整邊

13、緣小區(qū)的ps業(yè)務(wù)異系統(tǒng)測量rscp停止門限為-107dbm。參數(shù)調(diào)整后，測試結(jié)果正常，能有效保證用戶占用3g網(wǎng)絡(luò)進(jìn)行數(shù)據(jù)業(yè)務(wù)。5、 經(jīng)驗(yàn)總結(jié)保證邊緣小區(qū)覆蓋區(qū)域業(yè)務(wù)的正常使用，對全網(wǎng)邊緣小區(qū)異系統(tǒng)切換門限參數(shù)進(jìn)行了調(diào)整。但對于實(shí)際各種不同的業(yè)務(wù)應(yīng)用場景，需根據(jù)用戶的具體使用情況對參數(shù)做一定個性化的修正。本案例中，在進(jìn)行邊緣小區(qū)異系統(tǒng)切換參數(shù)的調(diào)整時，要考慮到用戶對上網(wǎng)速度的要求和感受，使用戶盡可能多的占用在3g網(wǎng)絡(luò)上，保持高速上網(wǎng)。經(jīng)驗(yàn)證測試，在rscp值到達(dá)-105dbm時，3g網(wǎng)絡(luò)的上網(wǎng)速度還可以到達(dá)3m。案例五：湖州邊緣小區(qū)重選切換存在的問題案例案例編寫人：沈忠惠聯(lián)系 電話：156572

14、726891、 問題簡述現(xiàn)網(wǎng)中邊緣小區(qū)重選切換存在問題，導(dǎo)致邊緣小區(qū)的rrc連接成功率較市區(qū)站點(diǎn)低，影響用戶感受。2、 發(fā)生時間和地點(diǎn)發(fā)生時間：2009年8月。發(fā)生地點(diǎn)：南潯開發(fā)區(qū)西北角。3、 原因分析邊緣小區(qū)由于站點(diǎn)稀少，網(wǎng)內(nèi)干擾小，通常當(dāng)rscp為-110dbm左右時，ec/io仍然可以保持在-10db左右。目前的3g/2g互操作策略是只要滿足駐留在w的條件，就盡可能重選駐留在w。因此導(dǎo)致了在邊緣小區(qū)，當(dāng)w的rscp在-110dbm以下（手機(jī)顯示1格），而g網(wǎng)電平為-60dbm時，仍駐留在w網(wǎng)。在跨省邊界，如湖州南潯與江蘇邊界，南潯開發(fā)區(qū)西北角目前暫沒有w站點(diǎn)，而江蘇在湖州邊界是全覆蓋，會

15、導(dǎo)致該處邊界2km以內(nèi)的湖州3g用戶長期駐留到江蘇的網(wǎng)絡(luò)，話務(wù)量也會跑到蘇州去。目前，w切換電平設(shè)置也偏低，在邊緣小區(qū)存在類似重選的問題，ec/io觸發(fā)不了切換，要等電平很弱才切換到2g，給用戶造成聯(lián)通3g網(wǎng)絡(luò)覆蓋差的印象。4、 解決方案在邊緣小區(qū)，由于3g/2g互操作參數(shù)設(shè)置不合理（cs業(yè)務(wù)異系統(tǒng)測量rscp啟動門限為-100dbm，cs業(yè)務(wù)異系統(tǒng)測量rscp停止門限為-97dbm），當(dāng)rscp值為-100dbm左右時，由于還未到達(dá)啟動壓模門限，手機(jī)一直駐留在w網(wǎng)絡(luò)上，而此時rscp值已經(jīng)很低。若在這時發(fā)起呼叫，會使得接入成功率較低，建議調(diào)整cs業(yè)務(wù)異系統(tǒng)測量rscp參數(shù)門限。具體調(diào)整方案如

16、下：（1） 調(diào)整邊緣小區(qū)的cs業(yè)務(wù)異系統(tǒng)測量rscp啟動門限為-95dbm。（2） 調(diào)整邊緣小區(qū)的cs業(yè)務(wù)異系統(tǒng)測量rscp停止門限為-92dbm。對w ec/io要求，現(xiàn)網(wǎng)中設(shè)置為-10db，對邊緣小區(qū)基本不起作用，再提高也無多大意義，邊緣小區(qū)即使電平在-100dbm以下，ec/io也通常在-8db以上。5、 經(jīng)驗(yàn)總結(jié)在邊緣小區(qū)，信號一般電平低，而質(zhì)量不會太差。在設(shè)置參數(shù)方面，應(yīng)多考慮以rscp為參考。案例六：湖州基站誤碼導(dǎo)致基站bootp啟動偵聽失敗案例案例編寫人：顧曉江聯(lián)系 電話：156572720631、 問題簡述某局在開站過程中長時間無法成功啟動bootp，組網(wǎng)情況：rnc-sdh傳

17、輸網(wǎng)絡(luò)-nodeb；使用4e1傳輸。2、 發(fā)生時間和地點(diǎn)發(fā)生時間：9月26日。發(fā)生地點(diǎn)：德清美都現(xiàn)代城室分基站3、 原因分析（1） 傳輸工程師配合在傳輸網(wǎng)管上做環(huán)斷測試正常；在nodeb近段對rnc做環(huán)斷測試正常。（2） 國內(nèi)w項(xiàng)目nodeb缺省配置文件，阻抗特性為：75歐，非平衡模式，在配置文件生效的情況下，與單板撥碼開關(guān)設(shè)置無關(guān)。（3） 傳輸質(zhì)量測試：由于傳輸質(zhì)量的好壞直接影響承載的數(shù)據(jù)，導(dǎo)致bootp發(fā)包丟失或錯包等，因此選擇在nodeb側(cè)進(jìn)行了在線誤碼測試，測試結(jié)果反映設(shè)備存在高誤碼，參考如下：+hw-airbridge2009-03-2918:32:03o&m#42%stpe1t1o

18、nltst:srn=0,sn=7,sbt=base_board;%retcode=0執(zhí)行成功。e1/t1在線性能統(tǒng)計-機(jī)柜編號=主柜機(jī)框編號=0槽位編號=7子板類型=基板端口編號=0線路編碼類型沖突錯誤率=0.000000e+00同步字錯誤率=2.511962e-05crc檢驗(yàn)錯誤率=5.263158e-05e比特錯誤率(e1)/block錯誤率(t1)=1.052632e-04-end（4） 為進(jìn)一步證實(shí)傳輸質(zhì)量引起bootp偵聽失敗，做如下測試：從基站缺省配置文件看出，缺省配置文件的傳輸數(shù)據(jù)配置在6號槽位，而實(shí)際上傳輸接口板在7號槽位。通過近段登錄nodeb建立imagroup后，出現(xiàn)ai

19、s告警：hw-airbridge2009-03-2919:05:42o&m#185%addimalnk:srn=0,sn=7,sbt=base_board,imalnkn=1,imagrpsbt=base_board;%retcode=0執(zhí)行成功。-end+hw-airbridge2009-03-2919:06:18o&m#188%dspe1t1:;%retcode=0執(zhí)行成功。e1t1狀態(tài)-機(jī)柜編號=主柜機(jī)框編號=0槽位編號=7子板類型=基板端口編號=0鏈路狀態(tài)=存在ais告警機(jī)柜編號=主柜機(jī)框編號=0槽位編號=7子板類型=基板端口編號=1鏈路狀態(tài)=存在ais告警-endais（alarmi

20、ndicationsignal：告警指示信號）：沒有幀格式的全“1”信號。發(fā)送到對端，用來指示本端pcm設(shè)備或下游設(shè)備發(fā)生嚴(yán)重故障（線路已經(jīng)不可用）。告警臺出現(xiàn)此告警表示對端設(shè)備不可用。也就是說當(dāng)a端發(fā)送斷掉或者幀失步時，b端就會向a端發(fā)送rai告警指示信號，說明處于幀丟失或者幀失步狀態(tài)。同時b端向c端發(fā)出ais告警指示信號，指示本端沒有收到a端發(fā)送出的正確信號。4、 解決方案由施工隊(duì)下站進(jìn)行傳輸施工工藝整改，整改完成后，基站成功啟動bootp。5、 經(jīng)驗(yàn)總結(jié)根據(jù)以上各個方面的分析，如果站點(diǎn)存在較大的誤碼，影響傳輸承載的數(shù)據(jù)，這種誤碼存在導(dǎo)致bootp啟動偵聽失敗，最終會影響到維護(hù)通道的建立。

21、建議在開通基站前，檢查傳輸質(zhì)量，特別是2m接頭的制作工藝等問題，通過物理逐步逐段的環(huán)回，排查傳輸，消除誤碼影響。案例七：嘉興多rru級聯(lián)底噪未更新設(shè)置導(dǎo)致hsupa速率偏低問題案例案例編寫人：沈越豐聯(lián)系 電話： 156573720721、 問題簡述桐鄉(xiāng)巨石集團(tuán)wsf2_1小區(qū)由于底噪設(shè)置不當(dāng)導(dǎo)致hsupa業(yè)務(wù)速率偏低（平均速率150kb,峰值速率182kb），其他業(yè)務(wù)均正常。如下圖所示：2、 發(fā)生時間和地點(diǎn)發(fā)生時間：2009年10月7日 發(fā)生地點(diǎn)：桐鄉(xiāng)巨石集團(tuán)3、 原因分析（1） 檢查告警，經(jīng)過維護(hù)臺核實(shí)，該小區(qū)無告警。排除此因素。（2） 檢查桐鄉(xiāng)巨石集團(tuán)wsf2_1小區(qū)是否帶有直放站，因?yàn)橹?/p>

22、放站對上行會有噪聲積累，會直接影響hsupa速率。經(jīng)確認(rèn)，該小區(qū)無直放站。（3） 對桐鄉(xiāng)巨石集團(tuán)wsf2_1小區(qū)覆蓋的房間經(jīng)行覆蓋情況測試。測試結(jié)果rscp和ec/io均正常，如下圖所示： rscp for 1st best in active set ec/io for 1st best in active set（4） 在維護(hù)臺查看該小區(qū)的物理拓?fù)浣Y(jié)構(gòu)，發(fā)現(xiàn)該小區(qū)由兩個 rru級聯(lián)組成，如下圖所示：（5） 對兩個rru空載時的上行總帶寬接收功率（rtwp）經(jīng)行測量，結(jié)果如下：時間0號載波，rx接收中心頻點(diǎn)號0號載波主集天線rtwp(0.1dbm)2009-10-7 10:549763-10

23、602009-10-7 10:549763-10612009-10-7 10:549763-10602009-10-7 10:549763-10602009-10-7 10:549763-10612009-10-7 10:549763-10582009-10-7 10:549763-10612009-10-7 10:549763-10552009-10-7 10:549763-10592009-10-7 10:549763-10612009-10-7 10:549763-10602009-10-7 10:549763-10592009-10-7 10:549763-10612009-10-7

24、10:549763-10602009-10-7 10:549763-10602009-10-7 10:549763-10602009-10-7 10:549763-10602009-10-7 10:549763-10582009-10-7 10:549763-10592009-10-7 10:549763-1058“桐鄉(xiāng)巨石集團(tuán)sf1”rru空載時的rtwp值基本穩(wěn)定在-106，屬于正常范圍。時間0號載波，rx接收中心頻點(diǎn)號0號載波主集天線rtwp(0.1dbm)2009-10-7 10:549763-10682009-10-7 10:549763-10692009-10-7 10:54976

25、3-10692009-10-7 10:549763-10692009-10-7 10:549763-10682009-10-7 10:549763-10682009-10-7 10:549763-10682009-10-7 10:549763-10682009-10-7 10:549763-10682009-10-7 10:549763-10682009-10-7 10:549763-10682009-10-7 10:549763-10682009-10-7 10:549763-10682009-10-7 10:549763-10682009-10-7 10:549763-10682009-1

26、0-7 10:549763-10682009-10-7 10:549763-10682009-10-7 10:549763-10682009-10-7 10:549763-10682009-10-7 10:549763-10692009-10-7 10:549763-1069“桐鄉(xiāng)巨石集團(tuán)sf2”rru空載時的rtwp值基本穩(wěn)定在-106.9，屬于正常范圍。由以上兩個rru的測量情況，可以排除是由于外部干擾引起的hsupa速率低問題。嘗試降低桐鄉(xiāng)巨石集團(tuán)wsf2_1小區(qū)的主公共導(dǎo)頻功率：33dbm27dbm。經(jīng)現(xiàn)場測試，hsupa速率仍無提升。將桐鄉(xiāng)巨石集團(tuán)wsf2_1小區(qū)下2個rru中的一個

27、閉塞，只留一個rru，再對覆蓋區(qū)經(jīng)行測試。結(jié)果如下：rru名桐鄉(xiāng)巨石集團(tuán)sf1桐鄉(xiāng)巨石集團(tuán)sf2hsupa速率rru管理狀態(tài)解閉塞閉塞正常閉塞解閉塞正常解閉塞解閉塞速率偏低由此懷疑是否因?yàn)閞ru級聯(lián)數(shù)字合路引起上報rnc的rtwp的值升高，從而導(dǎo)致hsupa速率低。當(dāng)多個rru級聯(lián)共小區(qū)時，下行多個天線發(fā)送相同的數(shù)據(jù)，上行多個rru的信號直接線型疊加送給基帶處理，上行信號合路會帶來底噪抬升，這樣nodeb上報給rnc的rtwp數(shù)值就會偏高。但偏高的rtwp并不是真正物理意義上的底噪被抬高，因此需要在rnc維護(hù)臺上修改底噪值來規(guī)避，否則rnc會認(rèn)為這時上行負(fù)荷很高（w中用rtwp來表征上行負(fù)荷）

28、，導(dǎo)致準(zhǔn)入拒絕或者ps的速率降低。多rru共小區(qū)時rnc上底噪計算及修改方法為：多rru共小區(qū)的rtwp的抬升量：10log（n），n為級聯(lián)數(shù)。在rnc側(cè)需要調(diào)整的背景噪聲：61100log（n）。背景噪聲設(shè)置值對應(yīng)的rtwp：112（背景噪聲設(shè)置值1）/10mml命令：add cellcac4、 解決方案桐鄉(xiāng)巨石集團(tuán)wsf2_1小區(qū)共有2個rru，根據(jù)上一節(jié)的計算方法，在rnc上將小區(qū)的背景噪聲由61修改為91。修改小區(qū)底噪后對覆蓋區(qū)域經(jīng)行復(fù)測，hsupa的平均速率達(dá)到237.3kb，峰值速率為301.1kb，為正常水平。復(fù)測時hsdpa的平均速率達(dá)到618.67kb，峰值速率為688.82

29、kb，也正常。調(diào)整后hsupa復(fù)測速率調(diào)整后hsdpa復(fù)測速率（同調(diào)整前）5、 經(jīng)驗(yàn)總結(jié)上行干擾是造成上行業(yè)務(wù)異常的主要原因。在處理上行問題時，對干擾的定位是處理問題的關(guān)鍵。wcdma系統(tǒng)上行異常干擾主要分為內(nèi)部干擾和外部干擾。內(nèi)部干擾可能由于工程質(zhì)量，或者天線、連接器等器件本身質(zhì)量等引起；外部干擾可能是由于直放站、手機(jī)干擾器等設(shè)備引起。定位上行干擾可通過實(shí)時測試小區(qū)或rru的rtwp來發(fā)現(xiàn)問題。當(dāng)多rru共小區(qū)時，因多rru級聯(lián)造成的底噪抬升也會影響上行業(yè)務(wù)，所以在多rru級聯(lián)時，rnc上需根據(jù)級聯(lián)的rru數(shù)量正確設(shè)置小區(qū)底噪，以規(guī)避級聯(lián)造成的影響。案例八：寧波rnc前后臺數(shù)據(jù)不一致問題處理

30、案例案例編寫人：林杰鋒聯(lián)系 電話：156574762791、 問題簡述rnc調(diào)測階段出現(xiàn)actcrc輸出有前后臺不一致表項(xiàng)。2、 發(fā)生時間和地點(diǎn)2009年9月11日，寧波聯(lián)通新大樓機(jī)房3f rnc53、 解決方案（1） 該rnc版本是bsc6810v200r010c01b061，用actcrc檢查前后臺數(shù)據(jù)一致性時輸出如下信息：%actcrc:;%retcode=0executionsucceeded.subrackno.0slotno.6subsystemno.0boardtypescu-tablenamecheckresulttiproutetblcheckinconsistentcrcc

31、heckoperationcompleted(numberofconsistenttables=103,others=1)subrackno.0slotno.2subsystemno.0boardtypespucrccheckresult-crccheckoperationcompleted(numberofconsistenttables=395,others=0)subrackno.0slotno.2subsystemno.1boardtypespucrccheckresult-tablenamecheckresultcellhsupaparascheckinconsistentcrcch

32、eckoperationcompleted(numberofconsistenttables=394,others=1)說明0子框6槽位的scu板上的tiproutetbl表和2槽位的spu板上的cellhsupaparas兩個表前后臺不一致。（2） 用比較命令查看具體不一致的內(nèi)容：cmptbldata:bt=scu,srn=0,tname=tiproutetbl;tiproutetbl-record1.fromfam:uliproutedest=184313347uliproutemask=4294967295uliproutenexthop=174071811uciprouteslotin

33、dex=14ucnexthopslotindex=14ucnexthopportindex=0ucpriority=80ucroutetype=0frombam:correspondingresultsnotfound(numberofresults=1)datatableoperationsucceeded根據(jù)比較的結(jié)果發(fā)現(xiàn)，前臺fam比bam的數(shù)據(jù)多了一條iprt的數(shù)據(jù)。（3） 轉(zhuǎn)換出路由的值：uliproutedestuliproutemaskuliproutenexthop1843133474294967295174071811afc6603ffffffffa60200310.252.

34、102.3255.255.255.25510.96.32.3（4） 重新下發(fā)這條路由數(shù)據(jù)到bam。（5） 用同樣的方法修改第二個表的內(nèi)容。（6） 再次用actcrc比較前后臺數(shù)據(jù)發(fā)現(xiàn)已一致。4、 經(jīng)驗(yàn)總結(jié)bam是工作在主備雙機(jī)工作模式下，數(shù)據(jù)出現(xiàn)不同步原因主要是由于主備bam在數(shù)據(jù)不同步狀態(tài)下發(fā)生異常倒換時，如果不小心誤操作下發(fā)數(shù)據(jù)同步命令，會丟失少量的數(shù)據(jù)從而使前后臺不一致，如果bam里數(shù)據(jù)少于fam的情況下，用復(fù)位rnc來同步會使前臺的數(shù)據(jù)也丟失。所以用手工的方式修改可以避免復(fù)位rnc，也不會丟失數(shù)據(jù)。平時盡量避免倒換主備bam，如需要倒換，需在倒換之前通過dsp bam檢查主備bam是否

35、正常同步，確認(rèn)同步以后再進(jìn)行倒換，避免出現(xiàn)前后臺數(shù)據(jù)不一致。案例九：舟山多普達(dá)d200用戶掉話問題案例案例編寫人：許重九聯(lián)系 電話：156570979421、 問題簡述用戶投訴多普達(dá)d900掉話嚴(yán)重2、 發(fā)生時間和地點(diǎn)發(fā)生時間：2009年9月-10月。發(fā)生地點(diǎn)：定海、普陀城區(qū)。3、 原因分析 后臺chr分析發(fā)現(xiàn)該用戶全網(wǎng)掉話率極高，全天掉話達(dá)30余次，現(xiàn)場測試ec/io、rscp均屬正常，amr、vp、hspa測試正常均正常，排除ran側(cè)問題，跟蹤用戶信令，發(fā)現(xiàn)ue信令同步失敗。華為反應(yīng)該終端較老，在全國普遍存在掉話嚴(yán)重現(xiàn)象，故將原因定位為終端問題。后將問題提交華為研發(fā)，研發(fā)給出分析結(jié)果如下：

36、現(xiàn)網(wǎng)ran10版本默認(rèn)開啟下行鏈路盲傳輸格式檢測功能（*），由于多普達(dá)d900較老，該終端在amr速率格式超過ts 34.121規(guī)定必須檢測的3種（12.2 kbit/s、7.95 kbit/s、1.95 kbit/s）時，手機(jī)將不支持盲傳輸格式檢測，導(dǎo)致掉話。4、 解決方案由于現(xiàn)網(wǎng)ran10版本網(wǎng)絡(luò)側(cè)所發(fā)送的傳輸塊包含tfci，華為研發(fā)認(rèn)為關(guān)閉該開關(guān)不會對網(wǎng)絡(luò)性能產(chǎn)生影響，建議關(guān)閉以解決該掉話現(xiàn)象。在ran側(cè)將downlink_blind_detection_switch關(guān)閉后該問題得到解決。5、 經(jīng)驗(yàn)總結(jié)wcdma發(fā)展多年，經(jīng)歷了多個版本的演進(jìn)，現(xiàn)網(wǎng)共存了多種版本的ue，在處理用戶投訴時需

37、結(jié)合用戶終端綜合分析原因，調(diào)整現(xiàn)網(wǎng)參數(shù)以提高用戶感知度。（*）盲傳輸格式檢測是指手機(jī)接收到的傳輸塊沒有包含傳輸格式說明（transportformatcombinationidentifier，tfci）的情況下，終端必須能正確檢測出以下9種速率數(shù)據(jù)包的傳輸格式：12.2 kbit/s*、10.2 kbit/s、7.95 kbit/s*、7.4 kbit/s、6.7 kbit/s、5.9 kbit/s、5.15 kbit/s、4.75 kbit/s、1.95 kbit/s*，其中*標(biāo)注的3種速率是ts 34.121中規(guī)定必須測試的。與其他測試項(xiàng)不同的是，盲檢測不但要測試bler，還要測試盲檢測

38、率（fdr）。測試fdr時，終端需要正確檢測出下行傳輸格式，解碼其數(shù)據(jù)并根據(jù)檢測的傳輸格式產(chǎn)生相應(yīng)的tfci比特，手機(jī)環(huán)回數(shù)據(jù)并帶循環(huán)冗余校驗(yàn)，在軟交換側(cè)測試上行tfci錯誤的個數(shù)。盲檢測需要在靜態(tài)信道和動態(tài)信道多徑環(huán)境case3兩種情況下進(jìn)行測試。接收機(jī)的ai性能測試由錯誤告警概率和正確檢測概率共同決定，測試在靜態(tài)條件下進(jìn)行。盲檢測和ai性能是wcdma終端測試所特有的。案例十：湖州漫游用戶上網(wǎng)感知慢問題案例案例編寫人：沈忠惠聯(lián)系 電話：156572726891、 問題簡述測試卡卡號imsi：460016024342902，該卡目前屬于德清分公司。以下測試結(jié)果，如果

39、測試地點(diǎn)沒有特別注明的，都在湖州太湖路聯(lián)通公司辦公樓，覆蓋區(qū)域?qū)儆趓nc2。2、 發(fā)生時間和地點(diǎn)發(fā)生時間：2009年7月15日發(fā)生地點(diǎn)：德清分公司 3、 原因分析（1） 數(shù)據(jù)速率測試上新浪視頻網(wǎng)，打開兩三個視頻后，發(fā)現(xiàn)速率可以達(dá)到4mbps以上，如下圖所示：說明該卡在湖州數(shù)據(jù)速率正常，但發(fā)現(xiàn)進(jìn)行視頻點(diǎn)播很慢。（2） 時延測試 湖州本地上網(wǎng)卡測試結(jié)果如下：ping 221.12.1.228172.31.254.9屬于本地局域網(wǎng)地址，124.160.58.137來自浙江省網(wǎng)通，60.12.6.42來自杭州網(wǎng)通。 該漫游卡測試結(jié)果如下：ping 221.12.1.228（tracert是在德清聯(lián)通分

40、公司測試的，該覆蓋區(qū)域?qū)儆趓nc3）經(jīng)上網(wǎng)查詢，192.192.1.21和192.192.2.9 ip來自臺灣，61.148.32.109來自北京網(wǎng)通。另外，也用該測試卡測嘗試過tracert百度、新浪、google等網(wǎng)站，第一跳的地址都是192.192.1.*.（3） 信令消息分析德清漫游用戶cdtlog（用戶感知網(wǎng)速慢）：本地用戶cdtlog（正常）用兩張不同的sim卡，在相同地點(diǎn)測試，用同一張上網(wǎng)卡（華為180e），感知漫游卡上網(wǎng)速度慢，而本地卡上網(wǎng)速度正常。從信令分析中可以看出，該測試點(diǎn)覆蓋信號良好，漫游卡開卡速率下行在7.4mbps以上，上行開卡速率在5.9mbps。所以可以肯定原因

41、不在于無線側(cè)，而且也不在于漫游卡的開卡速率和上網(wǎng)卡（終端上）。4、 解決方案在核心網(wǎng)上進(jìn)行路由優(yōu)化后，問題解決。5、 經(jīng)驗(yàn)總結(jié)在時延測試中，漫游的用戶比較本地用戶，時延多110ms左右，tracert多個網(wǎng)址，發(fā)現(xiàn)第一跳地址都是192.192.1.*，這一跳花的時間都在130ms以上。在同一地點(diǎn)測試，用本地上網(wǎng)卡，測試一切正常，而用漫游外地卡，測試發(fā)現(xiàn)時延大，導(dǎo)致用戶感知上網(wǎng)慢。通過和核心網(wǎng)工程師溝通，得知本省卡和外省卡的業(yè)務(wù)流程分別如下：（1） 外省卡業(yè)務(wù)流程是浙江本地sgsn1-承載網(wǎng)（本地承載網(wǎng)和聯(lián)通全國gn承載網(wǎng)）-北京ggsn-業(yè)務(wù)網(wǎng)站服務(wù)器（2） 本省業(yè)務(wù)流程是浙江本地sgsn1-

42、承載網(wǎng)（本地承載網(wǎng)）-本地ggsn-業(yè)務(wù)網(wǎng)站服務(wù)器從時延測試結(jié)果看，北京ggsn到業(yè)務(wù)網(wǎng)站服務(wù)器的時延大致在30ms左右，這個應(yīng)該在正常范圍內(nèi)，所以初步斷定問題出在承載網(wǎng)上，需要對承載網(wǎng)的路由表進(jìn)行優(yōu)化。案例十一：麗水ps業(yè)務(wù)上網(wǎng)速率12分鐘后降低到零問題案例案例編寫人：朱軼聯(lián)系 電話：156572293991、 問題簡述 ps業(yè)務(wù)上網(wǎng)速率12分鐘后降為零。2、 發(fā)生時間和地點(diǎn)兄弟省份出現(xiàn)過。3、 原因分析（1） 用兩個終端(mf330數(shù)據(jù)卡和高通6280手機(jī))同時測試，分別都在12分鐘左右速率降為0，用此方法排除了終端的原因。（2） 將iub口傳輸承載用atm方式和ip方式都試了一遍，還是有

43、同樣的問題，而且在12分鐘速率降為0后查看用戶面pdcp層統(tǒng)計，發(fā)現(xiàn)是cn沒有下行包發(fā)下來，所以排除了iub口的原因。（3） 在rnc升級前，用306的版本時沒有該問題，說明這個問題是在升級到307的版本后引入的，從另一方面也說明了不是cn的問題。（4） 將問題縮小在iu口，由于每次都是12分鐘，懷疑是定時器引起的限制，而該定時器是在307系統(tǒng)中引入的或者在307系統(tǒng)中定時器的默認(rèn)值設(shè)小了。（5） 抓取了信令儀碼流進(jìn)行分析，發(fā)現(xiàn)在速率降為0之前rnc向cn發(fā)了釋放消息（sccp層），釋放原因：expiration of receive inactivity timer，之后沒有任何下行數(shù)據(jù)。在

44、ps業(yè)務(wù)建立后，rnc會定時發(fā)it消息（sccp層）給cn，但cn一直沒有回，當(dāng)在12分鐘左右的時候接收it消息的定時器超時，sccp層發(fā)起釋放。（6） 接收it消息的定時器默認(rèn)值為72000秒，由于愛立信cn一直不回消息，會導(dǎo)致定時器超時。4、 解決方案通過修改rnc側(cè)該定時器的值來解決，在增大了r_mpprtmrdft表中t_it_receive字段的值后問題解決。5、 經(jīng)驗(yàn)總結(jié)日常維護(hù)和優(yōu)化工作中應(yīng)加深對各類參數(shù)特別是與業(yè)務(wù)相關(guān)參數(shù)的理解，發(fā)現(xiàn)和解決各類隱性網(wǎng)絡(luò)問題。案例十二：溫州聯(lián)通龍灣機(jī)房干擾問題案例案例編寫人：范昕潮聯(lián)系 電話：156577900211、 問題簡述聯(lián)通公司內(nèi)部員工反

45、映在龍灣機(jī)房門口經(jīng)常打電話接不通，從統(tǒng)計上看，rrc連接成功率較低，部分時段甚至只有左右，但rab建立成功率基本為100%。檢查網(wǎng)絡(luò)的無線環(huán)境，發(fā)現(xiàn)統(tǒng)計上，該站附近上行干擾很強(qiáng)。以下為9/229/24日所有時段的上行底噪變化趨勢線。attention：在載波上，上行干擾非常強(qiáng)，其中、載波的平均干擾強(qiáng)度為-86db左右；載波的方向的干擾強(qiáng)度為-76db左右。attention:在載波上，干擾強(qiáng)度明顯減弱。其中4、5載波的干擾底噪在-100以下；載波在-95以下。但同時也可以看出，載波的干擾強(qiáng)度較其它兩個方向強(qiáng)（與載波的方位相同），且有周期性變化。2、 發(fā)生時間和地點(diǎn)發(fā)生時間：9月底。發(fā)生地點(diǎn)：溫

46、州分公司大樓。3、 原因分析（1） 干擾方向?yàn)槎确轿唬ㄝd波）最強(qiáng)。（2） 干擾對fdd1的影響強(qiáng)烈；對fdd2的影響相對較弱。根據(jù)以上結(jié)論，按照以下方法進(jìn)行干擾排查和解決用戶投訴。用小天線掛接在nodeb饋線接口，然后統(tǒng)計上行底噪。若底噪降低，可排除設(shè)備內(nèi)部產(chǎn)生噪聲的可能。執(zhí)行：2009-9-25 14:29我們將第三載波的天線斷開，改用室內(nèi)微蜂窩使用的吸頂天線。觀察時段：2009年9月25日14:292009-9-26年9月26日9:14。rssi的統(tǒng)計趨勢圖如下：結(jié)論：可以看出，利用indoor天線替換室外大天線后，底噪下降了20db以上。這說明，現(xiàn)網(wǎng)底噪抬升源自設(shè)備外部。4、 解決方案考

47、慮到干擾排查較為困難。同時聯(lián)通用戶比較集中，建議目前將業(yè)務(wù)轉(zhuǎn)移到fdd2上進(jìn)行。待干擾源排查后，再重新將業(yè)務(wù)調(diào)整回fdd1上。為了達(dá)到以上目的，需要對參數(shù)調(diào)整如下：parameter nameold valuenew valuefdd1sintersearch616umtsneighrelationidumtsneighbouring/0 umtsneighbouringrelation/1umtsneighbouring/0 umtsneighbouringrelation/2serviceprioritygeneraltableconfclassidradioaccessservice/0 imcta/0 serviceprioritygeneraltableconfclass