經(jīng)典網(wǎng)絡(luò)amr異常掉話問題定位案例

《經(jīng)典網(wǎng)絡(luò)amr異常掉話問題定位案例》由會員上傳分享，免費在線閱讀，更多相關(guān)內(nèi)容在行業(yè)資料-天天文庫。

1、某網(wǎng)絡(luò)AMR異常掉話問題定位案例某項目搬遷割接后，客戶反映AMR語音掉話率不論是RNC級話統(tǒng)，還是Cluster話統(tǒng)都要比搬遷前NT網(wǎng)絡(luò)高，RNC語音掉話率在1%左右。尤其在小區(qū)半徑改大以后，掉話率呈現(xiàn)進一步上升的趨勢。2現(xiàn)場分析話統(tǒng)發(fā)現(xiàn)超過70%的語音掉話原因是上行RLFailure，檢查上行同失步參數(shù)覺得失步比較容易觸發(fā)，因此修改了上行同失步參數(shù)。然而參數(shù)修改并沒有取得預(yù)想的效果，掉話率沒有任何改善；2分析語音掉話相關(guān)的配置參數(shù)，發(fā)現(xiàn)語音的RLMAXPower配置為-3dB，而NT公司設(shè)置是+1d

2、B，相差4dB，我司的缺省設(shè)置偏低。將語音下行最大發(fā)射功率修改為+1dB，掉話率有所下降，為0.8%左右，基本與NT公司持平。以下是我司和NT公司掉話率變化走勢圖：MODCellRadiusMODAMRMaxRLPWRMODIn/OutSyncPara2通過修改語音下行最大發(fā)射功率，掉話率有所下降，然而這個改善并不顯著，客戶仍然覺得我司的網(wǎng)絡(luò)掉話率比NT公司的要差，并做了一份對比報告，認為我司網(wǎng)絡(luò)的AMR掉話率平均比NT高出一倍，對我司網(wǎng)絡(luò)的性能指標(biāo)不滿；2從初步的CHR分析來看，有相當(dāng)多的異常掉話在

3、信號很好的時候，而且掉話的原因仍然是以IUBRLFailure為主。通常都是呼叫剛剛建立18秒左右掉話，異?，F(xiàn)象非常典型。無1．定位問題的基本手段首先根據(jù)所有可能原因，從以下幾個方面分別進行定位分析：1)TopN小區(qū)的路測2)Top5用戶的CDT跟蹤3)Top5小區(qū)的IOS跟蹤4)網(wǎng)絡(luò)參數(shù)對比1)NodeB的日志分析2)設(shè)備告警與掉話小區(qū)相關(guān)性檢查2．初步的排查1)路測：首先在對掉話率比較高的幾個小區(qū)進行路測后，沒有發(fā)現(xiàn)掉話。路測無法重現(xiàn)這類掉話，因此基本排除了依靠路測定位此問題的可能；2)參數(shù)設(shè)置檢

4、查：包括了與NT公司參數(shù)的對比，以及和其它商用網(wǎng)絡(luò)的對比，列出與掉話相關(guān)的幾個不同參數(shù)。分析后發(fā)現(xiàn)主要可以修改的是軟切換參數(shù)（1A的延遲觸發(fā)時間改為100ms，濾波系數(shù)改為2），這能夠解決一些切換不及時造成的掉話，而事實上該網(wǎng)絡(luò)的無線傳播環(huán)境并不復(fù)雜，切換不及時發(fā)生的概率較低，而NT公司以前是根據(jù)0.5秒周期報告來做軟切換的，比我司目前320ms的配置更慢。因此，修改該參數(shù)能帶來的增益并不大。3)NodeB問題：該網(wǎng)絡(luò)普遍采用我司RRU，以前沒有普遍商用過，一度懷疑RRU可能有問題。為此還對比其它商用

5、局RRU的話統(tǒng)，并對CHR進行分析；對NodeB的日志分析也沒有什么結(jié)果。4)設(shè)備告警：檢查IUB傳輸告警、小區(qū)VSWR、RTWP告警以及擁塞等告警，發(fā)現(xiàn)這些告警與當(dāng)天的TOP5小區(qū)相關(guān)性不大。5)通過以上分析，定位問題的手段主要都落在CDT和IOS跟蹤上。對前一天CHR統(tǒng)計的AMR掉話Top5用戶進行CDT跟蹤，結(jié)果好幾個用戶沒有開機（或者在NT網(wǎng)絡(luò)），跟到的兩個也沒有什么異常發(fā)生。分析的重點只能放在IOS跟蹤數(shù)據(jù)上面。3．鎖定異常掉話發(fā)生過程——RBSetup后的RLFailure根據(jù)對掉話TOP

6、5小區(qū)的IOS跟蹤數(shù)據(jù)進行分析，重點只分析RLFailure造成的AMR掉話。在這些RLFailure原因的掉話中，刨除掉一些確實是信號問題（Ec/Io或RSCP較差）造成的掉話，有相當(dāng)大一部分RLFailure的掉話確實是在信號非常好的地方發(fā)生（前幾秒的Ec/Io和RSCP一般達到-8dB/-80dBm以上），而且掉話的過程非常一致——都是在RBSetup完成后10秒左右收到RLFailure(這時候一般還沒有發(fā)生軟切換，激活集只有一個小區(qū))，5秒鐘后沒有RLRestore掉話。因此把問題鎖定在這種

7、典型過程的掉話上面，典型的掉話點信令流程如下：4．鎖定異常掉話發(fā)生手機類型——V980根據(jù)跟蹤的IOS信令，網(wǎng)絡(luò)發(fā)了NAS層消息IdendityRequest，而UE回的IdendityResponse中上帶了手機的IMEI，因此根據(jù)IMEI的前6為數(shù)字可以確定手機的型號。如上圖的IMEI:3549090098161989，在Google上查詢“IMEI:354909”發(fā)現(xiàn)這是MOTOV980手機。這款手機存在較多問題，其中在其它商用網(wǎng)上發(fā)現(xiàn)該款手機存在內(nèi)環(huán)功控的問題。將RLFailure掉話的IME

8、I全部檢查，并一一在網(wǎng)上搜索其對應(yīng)的手機型號，發(fā)現(xiàn)V980手機占的比例相當(dāng)大，見下圖：上圖查到的V980對應(yīng)的2個IMEI占42％，后來查到354757也是V980，所以V980手機實際比例為56%，這與V980在網(wǎng)絡(luò)中占有的較小比例顯然不符，因此懷疑V980手機引起異常掉話。為了進一步證實我們的懷疑，把2天CHR統(tǒng)計的掉話TOP10的IMSI逐個進行跟蹤，并查看IdentityResponse消息。一共抓到8個用戶的消息，其IMEI和對應(yīng)的手機型號如下