564501137浙江聯通WCDMA網典型案例分析

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

17、輸網絡-nodeb；使用4e1傳輸。2、 發(fā)生時間和地點發(fā)生時間：9月26日。發(fā)生地點：德清美都現代城室分基站3、 原因分析（1） 傳輸工程師配合在傳輸網管上做環(huán)斷測試正常；在nodeb近段對rnc做環(huán)斷測試正常。（2） 國內w項目nodeb缺省配置文件，阻抗特性為：75歐，非平衡模式，在配置文件生效的情況下，與單板撥碼開關設置無關。（3） 傳輸質量測試：由于傳輸質量的好壞直接影響承載的數據，導致bootp發(fā)包丟失或錯包等，因此選擇在nodeb側進行了在線誤碼測試，測試結果反映設備存在高誤碼，參考如下：+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)計-機柜編號=主柜機框編號=0槽位編號=7子板類型=基板端口編號=0線路編碼類型沖突錯誤率=0.000000e+00同步字錯誤率=2.511962e-05crc檢驗錯誤率=5.263158e-05e比特錯誤率(e1)/block錯誤率(t1)=1.052632e-04-end（4） 為進一步證實傳輸質量引起bootp偵聽失敗，做如下測試：從基站缺省配置文件看出，缺省配置文件的傳輸數據配置在6號槽位，而實際上傳輸接口板在7號槽位。通過近段登錄nodeb建立imagroup后，出現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)-機柜編號=主柜機框編號=0槽位編號=7子板類型=基板端口編號=0鏈路狀態(tài)=存在ais告警機柜編號=主柜機框編號=0槽位編號=7子板類型=基板端口編號=1鏈路狀態(tài)=存在ais告警-endais（alarmi

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

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

22、放站對上行會有噪聲積累，會直接影響hsupa速率。經確認，該小區(qū)無直放站。（3） 對桐鄉(xiāng)巨石集團wsf2_1小區(qū)覆蓋的房間經行覆蓋情況測試。測試結果rscp和ec/io均正常，如下圖所示： rscp for 1st best in active set ec/io for 1st best in active set（4） 在維護臺查看該小區(qū)的物理拓撲結構，發(fā)現該小區(qū)由兩個 rru級聯組成，如下圖所示：（5） 對兩個rru空載時的上行總帶寬接收功率（rtwp）經行測量，結果如下：時間0號載波，rx接收中心頻點號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)巨石集團sf1”rru空載時的rtwp值基本穩(wěn)定在-106，屬于正常范圍。時間0號載波，rx接收中心頻點號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)巨石集團sf2”rru空載時的rtwp值基本穩(wěn)定在-106.9，屬于正常范圍。由以上兩個rru的測量情況，可以排除是由于外部干擾引起的hsupa速率低問題。嘗試降低桐鄉(xiāng)巨石集團wsf2_1小區(qū)的主公共導頻功率：33dbm27dbm。經現場測試，hsupa速率仍無提升。將桐鄉(xiāng)巨石集團wsf2_1小區(qū)下2個rru中的一個

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

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

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

30、案例案例編寫人：林杰鋒聯系 電話：156574762791、 問題簡述rnc調測階段出現actcrc輸出有前后臺不一致表項。2、 發(fā)生時間和地點2009年9月11日，寧波聯通新大樓機房3f rnc53、 解決方案（1） 該rnc版本是bsc6810v200r010c01b061，用actcrc檢查前后臺數據一致性時輸出如下信息：%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） 用比較命令查看具體不一致的內容：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根據比較的結果發(fā)現，前臺fam比bam的數據多了一條iprt的數據。（3） 轉換出路由的值：uliproutedestuliproutemaskuliproutenexthop1843133474294967295174071811afc6603ffffffffa60200310.252.

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

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

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

37、結合用戶終端綜合分析原因，調整現網參數以提高用戶感知度。（*）盲傳輸格式檢測是指手機接收到的傳輸塊沒有包含傳輸格式說明（transportformatcombinationidentifier，tfci）的情況下，終端必須能正確檢測出以下9種速率數據包的傳輸格式：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*，其中*標注的3種速率是ts 34.121中規(guī)定必須測試的。與其他測試項不同的是，盲檢測不但要測試bler，還要測試盲檢測

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

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

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

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

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

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

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

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

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

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