MSCBSC 移動(dòng)通信論壇
搜索
登錄注冊(cè)
網(wǎng)絡(luò)優(yōu)化工程師招聘專欄 4G/LTE通信工程師最新職位列表 通信實(shí)習(xí)生/應(yīng)屆生招聘職位

  • 閱讀:2694
  • 回復(fù):2
經(jīng)典網(wǎng)絡(luò)AMR異常掉話問題定位案例
yuanjie_rf
初級(jí)會(huì)員



 發(fā)短消息    關(guān)注Ta 

積分 75
帖子 15
威望 422 個(gè)
禮品券 0 個(gè)
專家指數(shù) 0
注冊(cè) 2013-6-18
專業(yè)方向  網(wǎng)絡(luò)優(yōu)化
回答問題數(shù) 0
回答被采納數(shù) 0
回答采納率 0%
 
發(fā)表于 2013-06-29 12:49:56  只看樓主 
某網(wǎng)絡(luò)AMR異常掉話問題定位案例
某項(xiàng)目搬遷割接后,客戶反映AMR語音掉話率不論是RNC級(jí)話統(tǒng),還是Cluster話統(tǒng)都要比搬遷前NT網(wǎng)絡(luò)高,RNC語音掉話率在1%左右。尤其在小區(qū)半徑改大以后,掉話率呈現(xiàn)進(jìn)一步上升的趨勢(shì)。
²
現(xiàn)場(chǎng)分析話統(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ā)射功率修改為+1dB,掉話率有所下降,為0.8%左右,基本與NT公司持平。以下是我司和NT公司掉話率變化走勢(shì)圖

MOD Cell Radius


MOD AMR Max RL PWR


MOD In/Out Sync Para



²
通過修改語音下行最大發(fā)射功率,掉話率有所下降,然而這個(gè)改善并不顯著,客戶仍然覺得我司的網(wǎng)絡(luò)掉話率比NT公司的要差,并做了一份對(duì)比報(bào)告,認(rèn)為我司網(wǎng)絡(luò)的AMR掉話率平均比NT高出一倍,對(duì)我司網(wǎng)絡(luò)的性能指標(biāo)不滿;
²
從初步的CHR分析來看,有相當(dāng)多的異常掉話在信號(hào)很好的時(shí)候,而且掉話的原因仍然是以IUB RL Failure為主。通常都是呼叫剛剛建立18秒左右掉話,異,F(xiàn)象非常典型

1定位問題的基本手段
首先根據(jù)所有可能原因,從以下幾個(gè)方面分別進(jìn)行定位分析:
1)
Top N
小區(qū)的路測(cè)
2)
Top 5
用戶的CDT跟蹤
3)
Top 5
小區(qū)的IOS 跟蹤
4)
網(wǎng)絡(luò)參數(shù)對(duì)比
5)
Node B
的日志分析
6)
設(shè)備告警與掉話小區(qū)相關(guān)性檢查
2.初步的排查
1)
路測(cè):首先在對(duì)掉話率比較高的幾個(gè)小區(qū)進(jìn)行路測(cè)后,沒有發(fā)現(xiàn)掉話。路測(cè)無法重現(xiàn)這類掉話,因此基本排除了依靠路測(cè)定位此問題的可能;
2)
參數(shù)設(shè)置檢查:包括了與NT公司參數(shù)的對(duì)比,以及和其它商用網(wǎng)絡(luò)的對(duì)比,列出與掉話相關(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,以前沒有普遍商用過,一度懷疑RRU可能有問題。為此還對(duì)比其它商用局RRU的話統(tǒng),并對(duì)CHR進(jìn)行分析;對(duì)Node B的日志分析也沒有什么結(jié)果。
4)
設(shè)備告警:檢查IUB傳輸告警、小區(qū)VSWR、RTWP告警以及擁塞等告警,發(fā)現(xiàn)這些告警與當(dāng)天的TOP 5小區(qū)相關(guān)性不大。
5)
通過以上分析,定位問題的手段主要都落在CDTIOS跟蹤上。對(duì)前一天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ù)對(duì)掉話TOP5小區(qū)的IOS跟蹤數(shù)據(jù)進(jìn)行分析,重點(diǎn)只分析RL Failure造成的AMR掉話。在這些RL Failure原因的掉話中,刨除掉一些確實(shí)是信號(hào)問題(Ec/IoRSCP較差)造成的掉話,有相當(dāng)大一部分RL Failure的掉話確實(shí)是在信號(hào)非常好的地方發(fā)生(前幾秒的Ec/IoRSCP一般達(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層消息Idendity Request,而UE回的Idendity Response中上帶了手機(jī)的IMEI,因此根據(jù)IMEI的前6為數(shù)字可以確定手機(jī)的型號(hào)

如上圖的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)上搜索其對(duì)應(yīng)的手機(jī)型號(hào),發(fā)現(xiàn)V980手機(jī)占的比例相當(dāng)大,見下圖

上圖查到的V980對(duì)應(yīng)的2個(gè)IMEI42%,后來查到354757也是V980,所以V980手機(jī)實(shí)際比例為56%,這與V980在網(wǎng)絡(luò)中占有的較小比例顯然不符,因此懷疑V980手機(jī)引起異常掉話。
為了進(jìn)一步證實(shí)我們的懷疑,把2CHR統(tǒng)計(jì)的掉話TOP 10IMSI逐個(gè)進(jìn)行跟蹤,并查看Identity Response消息。一共抓到8個(gè)用戶的消息,其IMEI和對(duì)應(yīng)的手機(jī)型號(hào)如下表

Top AMR Drop IMSI
IMEI Prefix
UE Type
214014001028124
354757
MOTO V980
214019800996086
357390
MOTO V3x
214018400245450
354757
MOTO V980
214015502901764
354909
MOTO V980
214019802036798
355603
MOTO V980
214019800794715
354757
MOTO V980
214019800805920
354757
MOTO V980
214016002234223
354757
MOTO 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分析否定了這種推測(cè)
5RTWP問題排除
為了證實(shí)異常掉話時(shí)是否有RTWP抬升,我們打開了IOS跟蹤的NBAP公共測(cè)量報(bào)告,查看RL Failure前后的測(cè)量報(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)都是這種情況:RTWPUE發(fā)射功率都很正常的情況下發(fā)生的RL Failure。因此基本可以排除上行問題導(dǎo)致,而信號(hào)這么好的情況下下行怎么會(huì)有問題呢?這種錯(cuò)誤的假設(shè)也導(dǎo)致我們?cè)趩栴}定位的前期一直沒有注意查看下行質(zhì)量。
6.鎖定RL Failure的原因——下行BLER 100%
于是打開了IOS中的UE質(zhì)量上報(bào)(下行BLER)和下行碼發(fā)射功率的測(cè)量。
發(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)功控我們看不到,但是在覆蓋這么好的地方,即使SIR Target調(diào)到上限(5dB)下行碼發(fā)射功率不需要太高也能滿足SIR的要求。這種情況是合理的
下行BLER100%意味著下行連續(xù)誤碼,這時(shí)會(huì)觸發(fā)下行失步,下行失步后UE會(huì)在40ms時(shí)間內(nèi)關(guān)閉發(fā)射機(jī),因此大約8秒后上行RL Failure
為什么在下行信號(hào)如此好的地方,會(huì)頻頻出現(xiàn)DL BLER100%的情況呢?
后來得到一些信息:
²
CDT信令分析,也發(fā)現(xiàn)了一次這樣的掉話,也是下行BLER很差但是TCP很小,而對(duì)方(主叫)號(hào)碼是一個(gè)特服號(hào)碼101,懷疑在接聽時(shí)刻傳送的用戶面數(shù)據(jù)異常;
²
在正常呼叫流程中,在UE接聽之前,E公司的核心網(wǎng)下發(fā)的IUUP是沒有數(shù)據(jù)的,而此時(shí)我司RNC配置的傳輸格式是0×0。
由此猜測(cè),在沒有數(shù)據(jù)傳輸時(shí),V980可能按照1×0的傳輸格式來解,導(dǎo)致100%BLER。這個(gè)猜測(cè)比較切合實(shí)際,因?yàn)榍皫滋炜吹降牡粼挻_實(shí)大部分都是被叫,而且也都是在UE接聽之前發(fā)生的,此時(shí)用戶面沒有數(shù)據(jù)。
通過對(duì)比我司和NT公司的RB Setup消息,確認(rèn)我司配置了0×81的傳輸格式(A子流),而NT公司沒有這種配置。而如果此問題就是導(dǎo)致下行BLER 100%的原因,則可以打開下行盲檢測(cè)開關(guān)來規(guī)避,使用SET CORRMALGOSWITCH命令,打開DOWNLINK_BLIND_DETECTION_SWITCH (下行盲檢測(cè)開關(guān))。因?yàn)橄滦忻z測(cè)開關(guān)打開后不下發(fā)0×81TF,而是下發(fā)一個(gè)1×0TF,如下圖所示:

1)下行盲檢測(cè)開關(guān)關(guān)閉時(shí)2)下行盲檢測(cè)開關(guān)打開時(shí)
檢查NT公司的消息,發(fā)現(xiàn)其盲檢測(cè)開著的(NT公司沒有面向客戶的這個(gè)開關(guān))

然而我們不敢輕易打開盲檢測(cè)開關(guān),因?yàn)橛行├习姹镜母咄ㄐ酒袀(gè)BUG,如果盲檢測(cè)開關(guān)打開,而網(wǎng)絡(luò)側(cè)配置了太多的CTFC則可能導(dǎo)致問題,因此目前我司的商用網(wǎng)絡(luò)全部關(guān)閉了這個(gè)開關(guān)。而對(duì)于AMR語音核心網(wǎng)只指配了3種速率,于是檢查NT公司的CTFC和我司的對(duì)比,發(fā)現(xiàn)都是6個(gè),見下圖所示
NT

Huawei


如果NT公司不存在上述高通芯片的問題,我司的配置也不會(huì)有問題。于是決定打開盲檢測(cè)開關(guān),現(xiàn)場(chǎng)使用V980手機(jī)進(jìn)行對(duì)比測(cè)試。
²
下行盲檢測(cè)開關(guān)關(guān)閉時(shí),V980做被叫如果不接聽則頻頻掉話,跟蹤的消息和我們先前分析的異常掉話原因相同;
²
下行盲檢測(cè)開關(guān)打開時(shí),單獨(dú)對(duì)V980的手機(jī)進(jìn)行被叫測(cè)試,連續(xù)進(jìn)行上百次的測(cè)試,沒有一次掉話。
打開盲檢測(cè)開關(guān)后話統(tǒng)指標(biāo)驗(yàn)證
²
打開盲檢測(cè)開關(guān)后18:00一小時(shí)的AMR掉話率降到了0.44%,在這個(gè)時(shí)段是從未有過的新低;而接下來的幾個(gè)忙時(shí),掉話率也都在0.4%左右保持;
²
修改后18:00~21:00各時(shí)段AMR掉話率與前兩天同期的對(duì)比統(tǒng)計(jì)圖如下

RNCId

RNCName

Time(As hour)

AMR drop call rate

AMR Call Attempts

121

RNC:121

2006-11-15 18:00

0.70%

8337

121

RNC:121

2006-11-15 19:00

0.86%

8561

121

RNC:121

2006-11-15 20:00

1.04%

7895

121

RNC:121

2006-11-15 21:00

0.69%

6533

121

RNC:121

2006-11-16 18:00

0.68%

8082

121

RNC:121

2006-11-16 19:00

0.84%

8383

121

RNC:121

2006-11-16 20:00

0.93%

8180

121

RNC:121

2006-11-16 21:00

0.75%

6617

121

RNC:121

2006-11-17 18:00

0.44%

9211

121

RNC:121

2006-11-17 19:00

0.43%

9212

121

RNC:121

2006-11-17 20:00

0.38%

8829

121

RNC:121

2006-11-17 21:00

0.27%

7313

²

Switch on DOWNLINK BLIND DETECTION


MOD AMR Max RL PWR


修改前后幾天,RNC話統(tǒng)統(tǒng)計(jì)AMR掉話率曲線走勢(shì)圖如下: 從上圖可以看出,打開盲檢測(cè)開關(guān)后,掉話率話統(tǒng)指標(biāo)有了較大的改善,RNC話統(tǒng)的AMR掉話率都穩(wěn)定在0.4%以下。
在定位此類異常掉話的問題時(shí),通過話統(tǒng)分析,找出網(wǎng)絡(luò)中的異常手機(jī)的型號(hào),并針對(duì)具體的手機(jī)型號(hào)進(jìn)行問題的定位分析,這是網(wǎng)絡(luò)優(yōu)化中一種方法。該方法在其它商用網(wǎng)絡(luò)中定位某款手機(jī)內(nèi)環(huán)功控的問題時(shí)也有所應(yīng)用。
掃碼關(guān)注5G通信官方公眾號(hào),免費(fèi)領(lǐng)取以下5G精品資料
  • 1、回復(fù)“YD5GAI”免費(fèi)領(lǐng)取《中國移動(dòng):5G網(wǎng)絡(luò)AI應(yīng)用典型場(chǎng)景技術(shù)解決方案白皮書
  • 2、回復(fù)“5G6G”免費(fèi)領(lǐng)取《5G_6G毫米波測(cè)試技術(shù)白皮書-2022_03-21
  • 3、回復(fù)“YD6G”免費(fèi)領(lǐng)取《中國移動(dòng):6G至簡(jiǎn)無線接入網(wǎng)白皮書
  • 4、回復(fù)“LTBPS”免費(fèi)領(lǐng)取《《中國聯(lián)通5G終端白皮書》
  • 5、回復(fù)“ZGDX”免費(fèi)領(lǐng)取《中國電信5G NTN技術(shù)白皮書
  • 6、回復(fù)“TXSB”免費(fèi)領(lǐng)取《通信設(shè)備安裝工程施工工藝圖解
  • 7、回復(fù)“YDSL”免費(fèi)領(lǐng)取《中國移動(dòng)算力并網(wǎng)白皮書
  • 8、回復(fù)“5GX3”免費(fèi)領(lǐng)取《 R16 23501-g60 5G的系統(tǒng)架構(gòu)1
  • 對(duì)本帖內(nèi)容的看法? 我要點(diǎn)評(píng)

     
    [充值威望,立即自動(dòng)到帳] [VIP貴賓權(quán)限+威望套餐] 另有大量?jī)?yōu)惠贈(zèng)送活動(dòng),請(qǐng)光臨充值中心
    充值擁有大量的威望和最高的下載權(quán)限,下載站內(nèi)資料無憂
    wwwmscbsccom
    超級(jí)版主
    鎵嬫満鍙風(fēng)爜宸查獙璇? style=


     發(fā)短消息    關(guān)注Ta 

    公益·慈善勛章   專家·高級(jí)勛章   紀(jì)念勛章·八周年   紀(jì)念勛章·九周年  
    積分 15793
    帖子 1497
    威望 34182 個(gè)
    禮品券 1225 個(gè)
    專家指數(shù) 8308
    注冊(cè) 2013-4-27
    專業(yè)方向  終端、協(xié)議測(cè)試、軟件測(cè)試
    回答問題數(shù) 0
    回答被采納數(shù) 0
    回答采納率 0%
     
    發(fā)表于 2013-06-30 10:31:22 
    技術(shù)貼不頂啊,不過看不到圖片啊。

    對(duì)本帖內(nèi)容的看法? 我要點(diǎn)評(píng)





    http://m.gg1fic3.cn/bbs/space.php?uid=10105337
     
    [立即成為VIP會(huì)員,百萬通信專業(yè)資料立即下載,支付寶、微信付款,簡(jiǎn)單、快速!]
    OscarDon
    論壇副管
    鎵嬫満鍙風(fēng)爜宸查獙璇? style=


     發(fā)短消息    關(guān)注Ta 

    C友·鐵桿勛章   管理·勤奮勛章   管理·優(yōu)秀勛章   公益·慈善勛章   C友·紀(jì)念勛章   管理·貢獻(xiàn)勛章   C友·貢獻(xiàn)勛章   “灌水之王”   紀(jì)念勛章·七周年   C友·魅力勛章   管理·標(biāo)兵勛章   活動(dòng)·積極勛章   財(cái)富勛章·財(cái)運(yùn)連連   財(cái)富勛章·大富豪   財(cái)富勛章·小財(cái)主   專家·終級(jí)勛章   紀(jì)念勛章·三周年   財(cái)富勛章·神秘富豪   C友·幸運(yùn)勛章   C友·登錄達(dá)人   C友·活躍勛章   公益·環(huán)保勛章   紀(jì)念勛章·五周年   紀(jì)念勛章·四周年   財(cái)富勛章·富可敵國   財(cái)富勛章·富甲一方   財(cái)富勛章·鉆石王老五   活動(dòng)·第一屆通信技術(shù)杯   活動(dòng)·第二屆通信技術(shù)杯   紀(jì)念勛章·六周年   活動(dòng)·攝影達(dá)人   通信正能量   紀(jì)念勛章·八周年   紀(jì)念勛章·九周年   紀(jì)念勛章·十周年   C友·技術(shù)大神   紀(jì)念勛章·十二周年  
    積分 61012
    帖子 5541
    威望 53882 個(gè)
    禮品券 15891 個(gè)
    專家指數(shù) 25389
    注冊(cè) 2008-6-30
    專業(yè)方向  通信工程
    來自 江蘇
    回答問題數(shù) 0
    回答被采納數(shù) 0
    回答采納率 0%
     
    發(fā)表于 2013-07-01 19:36:03  QQ
    確實(shí)圖片看不到

    對(duì)本帖內(nèi)容的看法? 我要點(diǎn)評(píng)





    當(dāng)我輕輕轉(zhuǎn)身,細(xì)數(shù)身上的傷痕,每一道都是福分。
     
    最新通信職位:廣東通信人才網(wǎng) | 北京通信人才網(wǎng) | 上海通信人才網(wǎng) | 南京通信人才網(wǎng) | 西安通信人才網(wǎng) | 重慶通信人才網(wǎng) | 中國通信人才網(wǎng)

    快速回復(fù)主題    
    標(biāo)題
    內(nèi)容
     上傳資料請(qǐng)點(diǎn)左側(cè)【添加附件】

    當(dāng)前時(shí)區(qū) GMT+8, 現(xiàn)在時(shí)間是 2025-01-09 21:02:00
    渝ICP備11001752號(hào)  Copyright @ 2006-2016 mscbsc.com  本站統(tǒng)一服務(wù)郵箱:mscbsc@163.com

    Processed in 0.696867 second(s), 17 queries , Gzip enabled
    TOP
    清除 Cookies - 聯(lián)系我們 - 移動(dòng)通信網(wǎng) - 移動(dòng)通信論壇 - 通信招聘網(wǎng) - Archiver