【文章內(nèi)容簡(jiǎn)介】 UU口消息”在彈出的窗口可以看到UU口的消息，雙擊每條信令可以看到每條信息的詳細(xì)IE，在“UU口消息”界面右鍵彈出列表后，點(diǎn)擊“Export Results”可以將UU口消息名、時(shí)間戳等保存出來(lái)。右鍵點(diǎn)擊“UU口消息解碼”可以將信令保存下來(lái)，共后臺(tái)分析。 miniPTAS軟件聯(lián)芯log目前聯(lián)芯提供的miniPTAS版本，可以抓取各層LOG，但只提供了LOG抓取功能，不能對(duì)LOG在軟件上進(jìn)行分析，只能發(fā)回聯(lián)芯進(jìn)行分析。第一步：?jiǎn)螕簟拔募薄靶陆ā薄皽y(cè)試工程”選擇保存位置后，進(jìn)行保存。第二步：?jiǎn)螕簟拔募薄靶陆ā薄皽y(cè)試連接”在彈出的界面上，查看是否是終端的鏈接確認(rèn)后，完成測(cè)試連接的建立。第三步：點(diǎn)擊“連接”在彈出菜單中選擇“連接”在輸出結(jié)果框中看到“已經(jīng)連上”代表連接建立成功。第四步：點(diǎn)擊“連接”選擇“無(wú)線參數(shù)”在彈出的窗口選擇需要抓取的LOG。第五步：使用終端發(fā)起業(yè)務(wù)，如果看到LOG數(shù)有變化，說(shuō)明已經(jīng)抓取了LOG第六步：保存后，發(fā)給聯(lián)芯進(jìn)行分析 CN側(cè)CN側(cè)可以進(jìn)行內(nèi)部數(shù)據(jù)采集，但較麻煩，采集數(shù)據(jù)必須CN研發(fā)人員用專門的解碼工具轉(zhuǎn)換后方可看，解碼工具不公開(kāi)。因此，CN側(cè)的數(shù)據(jù)采集需要由CN研發(fā)人員來(lái)做。這里不作介紹。5 語(yǔ)音雜音問(wèn)題不同原因分析 語(yǔ)音保持過(guò)程中存在一直有雜音的情況1） 當(dāng)語(yǔ)音業(yè)務(wù)保持過(guò)程中一直存在雜音時(shí)，首先需要檢查傳輸是否正常，2） 如果傳輸正常，雜音還存在， 語(yǔ)音保持過(guò)程中突然出現(xiàn)單通或者雙方都聽(tīng)不到聲音1） ，確認(rèn)是否誤碼較大2） 提取ISCP15分鐘統(tǒng)計(jì)值，檢查ISCP是否有突變的情況3） 檢查NODEB告警是否有DSP故障告警4） 如果NDOEB存在DSP告警，一般是NODEB的BBU板卡出現(xiàn)問(wèn)題，可以嘗試替換BBU進(jìn)行測(cè)試，確認(rèn)問(wèn)題返修有問(wèn)題的BBU5） 語(yǔ)音保持雙方靜默時(shí)，主被叫均可以聽(tīng)到明顯有節(jié)奏的噪音。若雙方進(jìn)行通話后，噪音會(huì)逐漸減輕1） 首先需要確認(rèn)CN是那個(gè)廠商的設(shè)備，是否支持RFCI為NO_DATA（3個(gè)子流全0）的情況2） 如果CN支持RFCI為NO_DATA，則需要將RNC側(cè)rIuRfci表里面的RFCI對(duì)應(yīng)子流為0的字段刪掉3） 6 案例 語(yǔ)音業(yè)務(wù)在切換過(guò)程中存在短暫的金屬雜音問(wèn)題描述：語(yǔ)音業(yè)務(wù)在接力切換過(guò)程中存在短暫的金屬雜音問(wèn)題分析：1） 傳輸排查：登陸LMTB查看基站IMA鏈路是否有“接收非法ICP信元錯(cuò)誤”和“幀失步”，STUFF信元發(fā)送統(tǒng)計(jì)是否在增加，判斷傳輸層是否有信元丟棄；經(jīng)定位沒(méi)有發(fā)現(xiàn)傳輸問(wèn)題。2） 業(yè)務(wù)QOS統(tǒng)計(jì)：對(duì)用戶進(jìn)行多次切換QoS跟蹤，發(fā)現(xiàn)切換前后的上行誤碼都為0，只有在發(fā)生切換時(shí)的28S內(nèi)有誤碼產(chǎn)生；初步懷疑接力切換在實(shí)現(xiàn)上有問(wèn)題。3） 查看小區(qū)切換方式，配置為接力切換，此時(shí)跟蹤到的QoS切換誤碼范圍為10~26塊，修改小區(qū)切換方式為硬切換，QoS跟蹤發(fā)現(xiàn)切換時(shí)誤碼明顯減少，范圍為0~9，切換過(guò)程中雜音現(xiàn)象改善較大；經(jīng)RNC研發(fā)確認(rèn)RNC在接力切換目前的實(shí)現(xiàn)上存在問(wèn)題，需要優(yōu)化處理。4） 查看基站測(cè)告警進(jìn)行分析，發(fā)現(xiàn)有DCH出窗告警，經(jīng)基站研發(fā)分析告警LOG，認(rèn)為基站對(duì)于上行丟幀的處理方式和上行譯碼錯(cuò)誤情況的處理方式需要改善；5） 檢查無(wú)線環(huán)境，是否服務(wù)小區(qū)和臨區(qū)RSCP值相當(dāng)，這樣需要優(yōu)化無(wú)線環(huán)境解決方法：1） RNC側(cè)處理：判斷對(duì)于語(yǔ)音業(yè)務(wù)，如果基站FP數(shù)據(jù)幀中的QE值上報(bào)為218的話，丟棄該數(shù)據(jù)包，不向CN發(fā)送，但外環(huán)功控的BLER統(tǒng)計(jì)需要正常累加。RNC判斷在切換狀態(tài)下，如果兩個(gè)小區(qū)上報(bào)的數(shù)據(jù)幀一個(gè)正確一個(gè)錯(cuò)誤，選擇正確的上報(bào)CN；如果兩個(gè)小區(qū)上報(bào)的數(shù)據(jù)幀都錯(cuò)誤，判斷QE值，選擇BER低上報(bào)CN。2） 基站側(cè)處理方式252。 對(duì)于上行丟幀的處理方式（此情況對(duì)應(yīng)于終端應(yīng)正常發(fā)送上行數(shù)據(jù)，但基站未能檢測(cè)到的情況）：，即SJ上報(bào)CC的數(shù)據(jù)指示未通過(guò)激活檢測(cè)；，但CC對(duì)TFCI譯碼后，判斷TFCI值超出建鏈參數(shù)的最大范圍；對(duì)于以上兩種情況，CC上報(bào)FP丟幀（CRCI填寫(xiě)為0xff），F(xiàn)P上報(bào)RNC的數(shù)據(jù)幀中的CRCI指示為1，但QE值固定填寫(xiě)為218（對(duì)應(yīng)0255的協(xié)議值范圍）。252。 對(duì)于上行譯碼錯(cuò)誤情況的處理方式：PL層通過(guò)激活檢測(cè)，且CC對(duì)TFCI譯碼在合理的范圍內(nèi)，但對(duì)傳輸信道的TB塊譯碼后CRC校驗(yàn)錯(cuò)；對(duì)于這種情況，CC上報(bào)FP的CRCI為0x80，誤比特率BER值按照實(shí)際計(jì)算值上報(bào)，F(xiàn)P將BER值填寫(xiě)在QE位置供RNC使用。 貴州省移動(dòng)大樓語(yǔ)音質(zhì)量問(wèn)題問(wèn)題描述:移動(dòng)李總反映在新華苑（貴州移動(dòng)辦公大樓）14樓語(yǔ)音模糊不清晰。移動(dòng)投訴語(yǔ)音質(zhì)量模糊不清楚的問(wèn)題，復(fù)現(xiàn)情況描述如下：1） T網(wǎng)G網(wǎng)，通話10分鐘左右，突然上行出現(xiàn)單通，下行正常；2） T網(wǎng)G網(wǎng)，通話兩到三分鐘，出現(xiàn)雙方都聽(tīng)不到對(duì)方講話。問(wèn)題分析:測(cè)試人員在新華苑14樓進(jìn)行了問(wèn)題復(fù)現(xiàn)，我們發(fā)現(xiàn)語(yǔ)音質(zhì)量模糊不清晰時(shí)占用的是茅臺(tái)金波TD1小區(qū)信號(hào)，通過(guò)RNC側(cè)QoS信令跟蹤發(fā)現(xiàn)上行誤塊率高，基站側(cè)發(fā)現(xiàn)時(shí)隙干擾ISCP異常，上站提取告警發(fā)現(xiàn)同時(shí)有DSP任務(wù)運(yùn)行故障告警，因此懷疑基站BBU板卡處理問(wèn)題。解決方法:將茅臺(tái)金波站的BBU板更換到紅邊門站測(cè)試時(shí)多次復(fù)現(xiàn)了語(yǔ)音質(zhì)量問(wèn)題，在茅臺(tái)金波站更換其他BBU板，大量測(cè)試下來(lái)語(yǔ)音質(zhì)量良好，但偶爾仍有毛刺，經(jīng)分析發(fā)現(xiàn)，新華苑為單HSDPA 配置，旁邊的新華社為雙HSDPA配置，HSDPA干擾了R4，將新華社改為單HSDPA配置后，再次經(jīng)過(guò)大量測(cè)試，沒(méi)有發(fā)現(xiàn)語(yǔ)音質(zhì)量問(wèn)題，語(yǔ)音模糊不清晰的原因就是基站BBU板卡和HSDPA干擾了R4業(yè)務(wù)。其它:將茅臺(tái)金波站出現(xiàn)問(wèn)題的BBU板已經(jīng)反饋給北京研發(fā)分析定位。 上行語(yǔ)音質(zhì)量差問(wèn)題描述:使用TD手機(jī)通話過(guò)程中出現(xiàn)語(yǔ)音不清晰現(xiàn)象問(wèn)題分析:現(xiàn)場(chǎng)定位：第一：正常撥打語(yǔ)音電話，主被叫同時(shí)監(jiān)聽(tīng)語(yǔ)音質(zhì)量；存在語(yǔ)音不清晰現(xiàn)象，但出現(xiàn)概率很低，兩天測(cè)試才抓到4次這樣的現(xiàn)象。第二：撥打語(yǔ)音電話，然后觸發(fā)小區(qū)間切換、NB間切換；容易出現(xiàn)語(yǔ)音不清晰現(xiàn)象，比例大概在30%到40%。第三：撥打測(cè)試，主被叫同時(shí)監(jiān)聽(tīng)語(yǔ)音質(zhì)量。中間涉及到的變動(dòng)包括更換基站版本、更換RRU、更換BBU槽位、更換基站（整站）、跳過(guò)室分系統(tǒng)、關(guān)閉外環(huán)功率控制。結(jié)果顯示都存在話音不清晰問(wèn)題。現(xiàn)場(chǎng)定位總結(jié)：接入后就會(huì)出現(xiàn)不清晰的現(xiàn)象，但沒(méi)有切換觸發(fā)的語(yǔ)音不清晰的概率高。語(yǔ)音不清晰的時(shí)候，從空口上看RSCP、C/I、UE發(fā)射功率均正常。室內(nèi)分布3個(gè)基站（包含移動(dòng)大樓）有語(yǔ)音不清晰問(wèn)題，室外基站測(cè)試了2個(gè)小時(shí)沒(méi)有出現(xiàn)語(yǔ)音不清晰的現(xiàn)象。從NB和RNC聯(lián)合分析的結(jié)論：Iub口傳輸沒(méi)有問(wèn)題。研發(fā)定位：?jiǎn)螜C(jī)測(cè)試環(huán)境下，模擬組織上行語(yǔ)音幀處理。由于考慮到該問(wèn)題主要頻繁出現(xiàn)在觸發(fā)切換后（切換時(shí)容易出現(xiàn)時(shí)間抖動(dòng)），因此模擬抖動(dòng)情況進(jìn)行測(cè)試。模擬組織上行語(yǔ)音幀，測(cè)試發(fā)現(xiàn)發(fā)送到CN的語(yǔ)音幀幀號(hào)錯(cuò)誤，第一幀語(yǔ)音數(shù)據(jù)的幀號(hào)不為0，且后續(xù)的幀號(hào)不連續(xù)，這樣就會(huì)導(dǎo)致CN在接收到語(yǔ)音幀并進(jìn)行幀號(hào)檢查時(shí)發(fā)現(xiàn)幀號(hào)錯(cuò)誤，做出幀號(hào)異常情況處理，進(jìn)而造成語(yǔ)音不清晰。代碼走查發(fā)現(xiàn)，在目前的處理機(jī)制中，主調(diào)函數(shù)中每隔一個(gè)20ms調(diào)用一次上行數(shù)據(jù)處理函數(shù)。用戶實(shí)體建立成功后，上行數(shù)據(jù)處理函數(shù)第一次被調(diào)用時(shí)沒(méi)有判斷是否是真正的數(shù)據(jù)，就當(dāng)作是第一幀數(shù)據(jù)賦予初始幀號(hào)，這樣的話，當(dāng)?shù)谝粠嬲臄?shù)據(jù)到來(lái)時(shí)幀號(hào)已經(jīng)不是初始值。而且在第一幀數(shù)據(jù)到來(lái)時(shí)，沒(méi)有存儲(chǔ)當(dāng)前的rfn值，這樣導(dǎo)致計(jì)算后續(xù)幀號(hào)時(shí)前一個(gè)rfn和當(dāng)前rfn的差值diffrfn過(guò)大，由此計(jì)算出來(lái)的幀號(hào)不連續(xù)。解決方法:修改上行數(shù)據(jù)處理函數(shù)。在第一幀數(shù)據(jù)處理之前增加是否是真正數(shù)據(jù)的判斷，只有真正的數(shù)據(jù)才賦予幀號(hào)。在第一幀數(shù)據(jù)處理中增加存儲(chǔ)當(dāng)前的rfn值，這樣才能保證后續(xù)計(jì)算幀號(hào)時(shí)diffrfn為固定的差值，計(jì)算出來(lái)的幀號(hào)就是連續(xù)值。其他:該案例發(fā)生于2009年6月13日保定移動(dòng)大樓。 No DATA數(shù)據(jù)情況下出現(xiàn)噪音問(wèn)題描述：手機(jī)互打，雙方靜默時(shí)，主被叫均可以聽(tīng)到明顯有節(jié)奏的噪音。若雙方進(jìn)行通話后，噪音會(huì)逐漸減輕。CN測(cè)發(fā)送NO_DATA數(shù)據(jù)（即3個(gè)子流全部為0）的情況下，在終端會(huì)有雜音。定位過(guò)程：判斷CN是哪家的設(shè)備，因?yàn)橛行S家支持RFCI為NO_DATA（3個(gè)子流全0）的情況。如果CN不發(fā)NO_DATA數(shù)據(jù)，語(yǔ)音清晰。阿爾卡特的CN支持全0的情況，而RNC在IUUP初始化消息里面攜帶了RFCI為全0的情況，所以CN認(rèn)為RNC支持RFCI為NO_DATA，會(huì)下發(fā)全0的數(shù)據(jù)。此時(shí)雙方靜默時(shí)，主被叫均可以聽(tīng)到明顯有節(jié)奏的噪音，判斷可能是RNC對(duì)NO_DATA數(shù)據(jù)處理有問(wèn)題，經(jīng)與研發(fā)溝通，定位過(guò)程如下：，數(shù)據(jù)處理正常；只模擬發(fā)送下行靜默幀（子流長(zhǎng)度為0）數(shù)據(jù)處理正常；模擬發(fā)送下行NO_DATA數(shù)據(jù)（子流長(zhǎng)度為0、0、0）數(shù)據(jù)處理有誤；模擬有抖動(dòng)的情況下交替發(fā)送數(shù)據(jù)幀和靜默幀，則數(shù)據(jù)不能正常發(fā)送。這是由于語(yǔ)音處理有2個(gè)緩存交替存儲(chǔ)數(shù)據(jù)。正常情況下，只有一個(gè)緩存有數(shù)據(jù)，IU口每20ms來(lái)一包數(shù)據(jù)存下來(lái)。每20msMAC調(diào)度一次，MAC根據(jù)IUUP通知的數(shù)據(jù)量通知進(jìn)行TFC選擇，然后MAC根據(jù)選擇結(jié)果從IUUP取數(shù)據(jù)，MAC加頭之后交給FP處理，F(xiàn)P發(fā)送數(shù)據(jù)。異常情況下（有抖動(dòng)），兩個(gè)緩存都有數(shù)據(jù)（語(yǔ)音數(shù)據(jù)和靜默數(shù)據(jù)），由于當(dāng)前緩存處理完畢之后IUUP通知MAC剩余數(shù)據(jù)量（下一個(gè)緩存的數(shù)據(jù)長(zhǎng)度）有誤，導(dǎo)致MAC TFC選擇有誤，當(dāng)前緩存下的數(shù)據(jù)不能發(fā)送，導(dǎo)致語(yǔ)音質(zhì)量差。解決方法：在當(dāng)時(shí)RNC沒(méi)有升級(jí)的情況下，如果CN支持RFCI為NO_DATA，則需要將RNC側(cè)rIuRfci表里面的RFCI對(duì)應(yīng)子流為0的字段刪掉；RNC升級(jí)版本后不會(huì)出現(xiàn)該問(wèn)題。其他：該案例發(fā)生于2009年7月1日長(zhǎng)春。7 總結(jié)本文針對(duì)語(yǔ)音業(yè)務(wù)網(wǎng)絡(luò)優(yōu)化中出現(xiàn)的語(yǔ)音不清晰甚至掉話、語(yǔ)音聲音小、突發(fā)噪音等問(wèn)題，描述了如何一步步排查這些問(wèn)題的方法、以及需要采集的數(shù)據(jù)和抓取的log，并如何進(jìn)行數(shù)據(jù)分析，最終問(wèn)題解決。本文還給出了一些案例分析，通過(guò)這些案例積累對(duì)于我們解決類似問(wèn)題也給出了很好的借鑒。另外也介紹了相關(guān)技術(shù)原理和背景知識(shí)。根據(jù)后續(xù)更多案例分析以及問(wèn)題定位方法等積累，可以再進(jìn)一步完善本文檔。8 附錄介紹相關(guān)背景知識(shí)、以及一些原理性知識(shí)。 端到端QoS技術(shù)原理在描述E2E的QoS之前，我們先了解一下語(yǔ)音的呼叫流程。在TDSCDMA系統(tǒng)中，一個(gè)呼叫的建立，首先是通過(guò)終端與網(wǎng)絡(luò)側(cè)的信令交互，也就是控制面的過(guò)程，完成用戶面連接的建立。在一般的UMTS系統(tǒng)，一個(gè)標(biāo)準(zhǔn)的移動(dòng)到移動(dòng)的語(yǔ)音呼叫，原始信號(hào)(語(yǔ)音數(shù)據(jù))首先在發(fā)起側(cè)UE中編碼，經(jīng)過(guò)無(wú)線接口的傳送，在本地代碼轉(zhuǎn)換機(jī)中轉(zhuǎn)換成A律或者μ律PCM編碼( 制式標(biāo)準(zhǔn))后，在核心網(wǎng)中向遠(yuǎn)端傳輸；在遠(yuǎn)端代碼轉(zhuǎn)換機(jī)中再次進(jìn)行代碼轉(zhuǎn)換，將PCM語(yǔ)音格式轉(zhuǎn)換成為一種適合在無(wú)線接口上傳送的編碼格式，以便在遠(yuǎn)端無(wú)線接口上發(fā)送，最后在終結(jié)的UE中解碼，這種呼叫連接在核心網(wǎng)內(nèi)進(jìn)行兩次代碼轉(zhuǎn)換，通常稱為級(jí)聯(lián)配置。在講述語(yǔ)音的呼叫流程前，我們先要了解幾個(gè)關(guān)鍵概念：編解碼器、TFO、TrFO、AMR聲碼器、RFCI。其中TFO/TrFO的出現(xiàn)是因?yàn)榫幗獯a器的級(jí)聯(lián)引入的兩次代碼轉(zhuǎn)換降低了語(yǔ)音質(zhì)量，當(dāng)語(yǔ)音編解碼器低速率工作時(shí)，這種影響尤為明顯。而TFO(Tandem Free Operation)和TrFO(Transcoder Free Operation)機(jī)制的應(yīng)用可以避免核心網(wǎng)內(nèi)的兩次代碼轉(zhuǎn)換，它們共同的特點(diǎn)都是TC不進(jìn)行碼轉(zhuǎn)換（匯接），不將AMR語(yǔ)音編碼轉(zhuǎn)化為64kbps PCM編碼，而是直接將AMR語(yǔ)音編碼在網(wǎng)絡(luò)中傳輸，從而大大地提高了語(yǔ)音QoS。216。 CODEC((COder and DECoder)編解碼器)用來(lái)對(duì)信息的原始表達(dá)方式進(jìn)行采樣，量化和編碼使其成為某種形式的碼流以及能將該碼流進(jìn)行解碼使其還原成為原始表達(dá)方式的一種設(shè)備。在3G網(wǎng)絡(luò)中，用于下行方向的編解碼器位于MSC；而用于上行的位于UE手機(jī)終端中。位于MSC和UE中的CODEC需要接收RNC的信令，以便根據(jù)RNC的要求來(lái)動(dòng)態(tài)地調(diào)節(jié)和使用編碼速率。(上行是通過(guò)空中接口的控制面協(xié)議進(jìn)行控制，對(duì)于下行，RNC通過(guò)Iu接口的用戶面協(xié)議進(jìn)行控制)。需要指出的是位于MSC中的編解碼器也稱為TranSCoder它用于將一種編碼方式的信息轉(zhuǎn)化成另一種不同的編碼方式。通常是將AMR編碼的壓縮語(yǔ)音轉(zhuǎn)換成PCM語(yǔ)音碼流，或是反之。 注意：通常網(wǎng)絡(luò)都具有ITU A律的編解碼器可將信息轉(zhuǎn)換成為64Kb/s PCM語(yǔ)音碼流。 216。 TFO(Tandem Free Operation)在GSM網(wǎng)絡(luò)發(fā)展的后期，出現(xiàn)了TFO機(jī)制，它是一種呼叫配置，在信號(hào)鏈路上物理地存在代碼轉(zhuǎn)換設(shè)備，但代碼轉(zhuǎn)換功能被繞過(guò)。這種做法被第三代移動(dòng)通信系統(tǒng)UMTS網(wǎng)絡(luò)繼承，但具體實(shí)現(xiàn)時(shí)又有差異，在兩端的呼叫建立階段完成之后，媒體網(wǎng)關(guān)中的代碼轉(zhuǎn)換機(jī)設(shè)備交換根據(jù)ITUT G。711 A律或μ律編碼的傳統(tǒng)64 kb/s PCM語(yǔ)音抽樣。代碼轉(zhuǎn)換機(jī)通過(guò)竊取(stealing)每第16個(gè)抽樣中的一個(gè)最不重要的比特位，交換TFO消息，進(jìn)行兩端UE中編解碼器的協(xié)商。如果兩端的UE中應(yīng)用了兼容的語(yǔ)音編解碼類型，代碼轉(zhuǎn)換機(jī)自動(dòng)激活TFO，傳輸壓縮語(yǔ)音的信道被映射在64 kb/s的PCM編碼的最不重要的比特位上。如果應(yīng)用了不兼容的語(yǔ)音編解碼類型，TFO就不能被立即激活，呼叫回到一般的代碼轉(zhuǎn)換級(jí)聯(lián)操作模式下。但是，代碼轉(zhuǎn)換機(jī)還一直監(jiān)視PCM信號(hào)中是否含有帶內(nèi)協(xié)商編解碼的TFO消息，如果由于某種呼叫配置的改變，例如，遠(yuǎn)端發(fā)生了切換等，可能滿足TFO建立的條件時(shí)，代碼轉(zhuǎn)換機(jī)將再次嘗試發(fā)起和建立TFO(在TD系統(tǒng)中，TRO是基本支持功能項(xiàng))。在一個(gè)連接中配置的兩個(gè)編解碼轉(zhuǎn)換器它們都支持TFO協(xié)議并且配置一致的編解碼類型。這樣能夠讓壓縮語(yǔ)音包在不進(jìn)行編解碼轉(zhuǎn)換的情況下直接插入并復(fù)寫(xiě)PCM幀碼流（見(jiàn)下圖）。從而有效地旁路了編解