經(jīng)典網(wǎng)絡(luò)AMR異常掉話問題定位案例及分析解決方案

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

2、+1dB，掉話率有所下降，為0.8%左右，基本與NT公司持平。以下是我司和NT公司掉話率變化走勢圖：HUAWEI & Nortel Voice Call Drop Rate Comparison in ToledoMOD Cell RadiusMOD In/Out Sync ParaMOD AMR Max RL PWR1.20%1.00%0.80%0.60%0.40%0.20%0.00%Wed Thu Fri Sat Sun Mon Tue Wed Thu Fri Sat Sun Mon Tue WedHUAWEINortel² 通過修改語音下行最大發(fā)射功率，掉話率有所下降，

3、然而這個(gè)改善并不顯著，客戶仍然覺得我司的網(wǎng)絡(luò)掉話率比NT公司的要差，并做了一份對比報(bào)告，認(rèn)為我司網(wǎng)絡(luò)的AMR掉話率平均比NT高出一倍，對我司網(wǎng)絡(luò)的性能指標(biāo)不滿；² 從初步的CHR分析來看，有相當(dāng)多的異常掉話在信號很好的時(shí)候，而且掉話的原因仍然是以IUBRL Failure為主。通常都是呼叫剛剛建立18秒左右掉話，異?，F(xiàn)象非常典型。無1定位問題的基本手段首先根據(jù)所有可能原因，從以下幾個(gè)方面分別進(jìn)行定位分析：1)Top N 小區(qū)的路測2)Top 5 用戶的 CDT 跟蹤3)Top 5 小區(qū)的 IOS 跟蹤4)網(wǎng)絡(luò)參數(shù)對比5)Node B 的日志分析6)設(shè)備告警與掉話小區(qū)相關(guān)性檢查2初步的

4、排查1)路測：首先在對掉話率比較高的幾個(gè)小區(qū)進(jìn)行路測后，沒有發(fā)現(xiàn)掉話。路測無法重現(xiàn)這類掉話，因此基本排除了依靠路測定位此問題的可能；2)參數(shù)設(shè)置檢查：包括了與NT公司參數(shù)的對比，以及和其它商用網(wǎng)絡(luò)的對比，列出與掉話相關(guān)的幾個(gè)不同參數(shù)。分析后發(fā)現(xiàn)主要可以修改的是軟切換參數(shù)（1A的延遲觸發(fā)時(shí)間改為100ms，濾波系數(shù)改為2），這能夠解決一些切換不及時(shí)造成的掉話，而事實(shí)上該網(wǎng)絡(luò)的無線傳播環(huán)境并不復(fù)雜，切換不及時(shí)發(fā)生的概率較低，而NT公司以前是根據(jù)0.5秒周期報(bào)告來做軟切換的，比我司目前320ms的配置更慢。因此，修改該參數(shù)能帶來的增益并不大。3)Node B問題：該網(wǎng)絡(luò)普遍采用我司RRU，以前沒有普

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

6、重點(diǎn)只分析RL Failure造成的AMR掉話。在這些 RL Failure原因的掉話中，刨除掉一些確實(shí)是信號問題（Ec/Io或RSCP較差）造成的掉話，有相當(dāng)大一部分RL Failure的掉話確實(shí)是在信號非常好的地方發(fā)生（前幾秒的Ec/Io和RSCP一般達(dá)到-8dB/-80dBm以上），而且掉話的過程非常一致都是在RB Setup完成后10秒左右收到RL Failure(這時(shí)候一般還沒有發(fā)生軟切換，激活集只有一個(gè)小區(qū))，5秒鐘后沒有RL Restore掉話。因此把問題鎖定在這種典型過程的掉話上面，典型的掉話點(diǎn)信令流程如下：4鎖定異常掉話發(fā)生手機(jī)類型V980根據(jù)跟蹤的IOS信令，網(wǎng)絡(luò)發(fā)了NAS

7、層消息Idendity Request，而UE回的Idendity Response中上帶了手機(jī)的IMEI，因此根據(jù)IMEI的前6為數(shù)字可以確定手機(jī)的型號。如上圖的IMEI:3549090098161989，在Google上查詢“IMEI:354909”發(fā)現(xiàn)這是MOTO V980手機(jī)。這款手機(jī)存在較多問題，其中在其它商用網(wǎng)上發(fā)現(xiàn)該款手機(jī)存在內(nèi)環(huán)功控的問題。將RL Failure掉話的IMEI全部檢查，并一一在網(wǎng)上搜索其對應(yīng)的手機(jī)型號，發(fā)現(xiàn)V980手機(jī)占的比例相當(dāng)大，見下圖：上圖查到的V980對應(yīng)的2個(gè)IMEI占42，后來查到354757也是V980，所以V980手機(jī)實(shí)際比例為56%，這與V98

8、0在網(wǎng)絡(luò)中占有的較小比例顯然不符，因此懷疑V980手機(jī)引起異常掉話。為了進(jìn)一步證實(shí)我們的懷疑，把2天CHR統(tǒng)計(jì)的掉話TOP 10的IMSI逐個(gè)進(jìn)行跟蹤，并查看Identity Response消息。一共抓到8個(gè)用戶的消息，其IMEI和對應(yīng)的手機(jī)型號如下表：Top AMR Drop IMSIIMEI PrefixUE Type214014001028124354757MOTO V980214019800996086357390MOTO V3x214018400245450354757MOTO V980214015502901764354909MOTO V980214019802036798355

9、603MOTO V980214019800794715354757MOTO V980214019800805920354757MOTO V980214016002234223354757MOTO V980這樣問題逐漸明顯，肯定是與V980手機(jī)有關(guān)的。在我司的某個(gè)商用局，V980手機(jī)的問題是不做內(nèi)環(huán)功控，而是固定以滿功率發(fā)射，因此導(dǎo)致很多站的RTWP抬升導(dǎo)致其它用戶掉話。從現(xiàn)網(wǎng)問題小區(qū)的RTWP跟蹤來看，確實(shí)也有類似RTWP尖峰：于是一度把問題瞄準(zhǔn)了RTWP問題，但后來的IOS分析否定了這種推測。5RTWP 問題排除為了證實(shí)異常掉話時(shí)是否有RTWP抬升，我們打開了IOS跟蹤的NBAP公共測量報(bào)告

10、，查看RL Failure前后的測量報(bào)告，見下圖所示，RTWP=(61-1)/10-112 =-106dBm，因此RTWP非常正常。而且RL Failure之前也沒有看到UE的發(fā)射功率攀升，見下圖所示，UE Tx power 上報(bào)值為51，由此計(jì)算UE發(fā)射功率Tx Power=51-71=-20dBm。分析了IOS中很多的這類異常，發(fā)現(xiàn)都是這種情況：RTWP和UE發(fā)射功率都很正常的情況下發(fā)生的RL Failure。因此基本可以排除上行問題導(dǎo)致，而信號這么好的情況下下行怎么會有問題呢？這種錯(cuò)誤的假設(shè)也導(dǎo)致我們在問題定位的前期一直沒有注意查看下行質(zhì)量。6鎖定 RL Failure 的原因下行 BL

11、ER 100%于是打開了IOS中的UE質(zhì)量上報(bào)（下行BLER）和下行碼發(fā)射功率的測量。發(fā)現(xiàn)RL Failure前的下行BLER達(dá)到100%，而此時(shí)的導(dǎo)頻Ec/Io非常好：通過上圖UE上報(bào)的數(shù)據(jù)可以計(jì)算：¨服務(wù)小區(qū)CPICH Ec/Io=(39-1)/2-24=-5dB, RSCP=(29-1)-115=-87dBm;¨下行碼發(fā)射功率TCP=(86-10)/2-10-PO3=28dBm-3dB=25dBm¨下行BLER100（上報(bào)值63映射為100）通過以上計(jì)算，下行業(yè)務(wù)信道碼發(fā)射功率為25 dBm，并沒有達(dá)到最大發(fā)射功率。雖然下行的外環(huán)功控我們看不到，但是在覆蓋這

12、么好的地方，即使SIR Target調(diào)到上限（5dB）下行碼發(fā)射功率不需要太高也能滿足SIR的要求。這種情況是合理的。下行BLER為100%意味著下行連續(xù)誤碼，這時(shí)會觸發(fā)下行失步，下行失步后UE會在40ms時(shí)間內(nèi)關(guān)閉發(fā)射機(jī)，因此大約8秒后上行RL Failure。為什么在下行信號如此好的地方，會頻頻出現(xiàn)DL BLER為100%的情況呢？后來得到一些信息：² 從CDT信令分析，也發(fā)現(xiàn)了一次這樣的掉話，也是下行BLER很差但是TCP很小，而對方（主叫）號碼是一個(gè)特服號碼101，懷疑在接聽時(shí)刻傳送的用戶面數(shù)據(jù)異常；² 在正常呼叫流程中，在UE接聽之前，E公司的核心網(wǎng)下發(fā)的IUUP

13、是沒有數(shù)據(jù)的，而此時(shí)我司RNC配置的傳輸格式是0×0。由此猜測，在沒有數(shù)據(jù)傳輸時(shí)，V980可能按照1×0的傳輸格式來解，導(dǎo)致100%的BLER。這個(gè)猜測比較切合實(shí)際，因?yàn)榍皫滋炜吹降牡粼挻_實(shí)大部分都是被叫，而且也都是在UE接聽之前發(fā)生的，此時(shí)用戶面沒有數(shù)據(jù)。通過對比我司和NT公司的RB Setup消息，確認(rèn)我司配置了0×81的傳輸格式（A子流），而NT公司沒有這種配置。而如果此問題就是導(dǎo)致下行BLER 100%的原因，則可以打開下行盲檢測開關(guān)來規(guī)避，使用SET CORRMALGOSWITCH命令，打開DOWNLINK_BLIND_DETECTION_SWITCH

14、(下行盲檢測開關(guān))。因?yàn)橄滦忻z測開關(guān)打開后不下發(fā)0×81的TF，而是下發(fā)一個(gè)1×0的TF，如下圖所示：（1）下行盲檢測開關(guān)關(guān)閉時(shí)（2）下行盲檢測開關(guān)打開時(shí)檢查NT公司的消息，發(fā)現(xiàn)其盲檢測開著的（NT公司沒有面向客戶的這個(gè)開關(guān)）：然而我們不敢輕易打開盲檢測開關(guān)，因?yàn)橛行├习姹镜母咄ㄐ酒袀€(gè)BUG，如果盲檢測開關(guān)打開，而網(wǎng)絡(luò)側(cè)配置了太多的CTFC則可能導(dǎo)致問題，因此目前我司的商用網(wǎng)絡(luò)全部關(guān)閉了這個(gè)開關(guān)。而對于AMR語音核心網(wǎng)只指配了3種速率，于是檢查NT公司的CTFC和我司的對比，發(fā)現(xiàn)都是6個(gè)，見下圖所示：NTHuawei如果NT公司不存在上述高通芯片的問題，我司的配置也不會

15、有問題。于是決定打開盲檢測開關(guān)，現(xiàn)場使用V980手機(jī)進(jìn)行對比測試。²下行盲檢測開關(guān)關(guān)閉時(shí)，V980做被叫如果不接聽則頻頻掉話，跟蹤的消息和我們先前分析的異常掉話原因相同；²下行盲檢測開關(guān)打開時(shí)，單獨(dú)對V980的手機(jī)進(jìn)行被叫測試，連續(xù)進(jìn)行上百次的測試，沒有一次掉話。打開盲檢測開關(guān)后話統(tǒng)指標(biāo)驗(yàn)證：²打開盲檢測開關(guān)后18:00一小時(shí)的AMR掉話率降到了0.44，在這個(gè)時(shí)段是從未有過的新低；而MOD AMR Max RL PWRCS AMR Call Drop RateSwitch on DOWNLINK1.20%1.00%0.80%0.60%0.40%0.20%0.00

16、%2006-11-11 2006-11-12 2006-11-13 2006-11-14 2006-11-15 2006-11-16 2006-11-17 2006-11-18 2006-11-19接下來的幾個(gè)忙時(shí)，掉話率也都在0.4%左右保持；²修改后18:0021:00各時(shí)段AMR掉話率與前兩天同期的對比統(tǒng)計(jì)圖如下：RNCIdRNCNameTime(As hour)AMR drop callrateAMR CallAttempts121RNC:1212006-11-15 18:000.70%8337121RNC:1212006-11-15 19:000.86%8561121RNC:1212006-11-15 20:001.04%7895121RNC:1212006-11-15 21:000.69%6533121RNC:1212006-11-16 18:000.68%8082121RNC:1212006-11-16 19:000.84%8383121RNC:1212006-11-16 20:000.93%8180121RNC:1212006-11-16 21:000.75%6617121RNC:1212006-11-17 18:000.44%9211121RNC:1212006-11-17 19:00