語音業(yè)務(wù)雜音問題優(yōu)化說明書

100/100語音業(yè)務(wù)雜音問題優(yōu)化指導(dǎo)書(僅供內(nèi)部使用)項目名稱文檔編號版本號1.0.0作者RNC支撐項目組版權(quán)所有大唐移動通信設(shè)備有限公司本資料及其包含的所有內(nèi)容為大唐移動通信設(shè)備有限公司(大唐移動)所有,受中國法律及適用之國際公約中有關(guān)著作權(quán)法律的愛護(hù)。未經(jīng)大唐移動書面授權(quán)，任何人不得以任何形式復(fù)制、傳播、散布、改動或以其它方式使用本資料的部分或全部內(nèi)容，違者將被依法追究責(zé)任。文檔更新記錄日期更新人版本備注2009-7-6趙敏V0.0.1創(chuàng)建模板2009-7-16王銳、李彥峰、馬忱、梁劍、楊蕾、施秉利、趙敏V0.0.2補充1~4、6~8章節(jié)內(nèi)容2009-7-22趙敏V1.0.0依照中試、NB同事反饋，補充4.4、4.5、7.3章節(jié)的內(nèi)容。

目錄1 概述 42 語音雜音問題評估 42.1 語音QoS指標(biāo)要求 42.2 可能的雜音情況 73 語音雜音問題CheckList 74 數(shù)據(jù)采集和分析 84.1 綜述 84.2 NodeB側(cè) 94.2.1ATP抓日志的方法 94.2.2傳輸問題導(dǎo)致該現(xiàn)象的排查方法 114.2.3NODEB側(cè)告警抓取和分析方法 124.3 RNC側(cè) 134.3.1IMA物理傳輸?shù)腖OG抓取和分析方法 134.3.2RNC側(cè)QOS跟蹤LOG的抓取和分析方法 154.3.3RNC側(cè)IUUP統(tǒng)計抓取和分析方法 164.3.4語音環(huán)回使用方法介紹 174.3.5VP環(huán)回使用方法介紹（FP層） 184.3.6VP環(huán)回使用方法介紹（IUUP層） 184.4 UE側(cè) 194.4.1SPANOutum軟件抓取終端信令信息 194.4.2miniPTAS軟件聯(lián)芯log 214.5 CN側(cè) 245 案例 245.1 語音業(yè)務(wù)在切換過程中存在短暫的金屬雜音 245.2 貴州省移動大樓語音質(zhì)量問題 255.3 上行語音質(zhì)量差 265.4 NoDATA數(shù)據(jù)情況下出現(xiàn)噪音 266 總結(jié) 277 附錄 277.1 端到端QoS技術(shù)原理 277.2 RNC相關(guān)參數(shù)匯總 357.2.1Iu參數(shù)配置 357.2.2RRM算法全局參數(shù) 407.2.3功率操縱參數(shù) 407.2.4上行外環(huán)功率操縱參數(shù) 467.2.5業(yè)務(wù)質(zhì)量測量參數(shù) 477.2.6業(yè)務(wù)同步參數(shù) 507.2.7業(yè)務(wù)QoS參數(shù)調(diào)度 537.3 NodeB相關(guān)參數(shù)匯總 537.4 其他業(yè)務(wù)QoS保證建議 541

概述語音業(yè)務(wù)是傳統(tǒng)業(yè)務(wù)，衡量該業(yè)務(wù)的QoS指標(biāo)有以下幾個方面：1）

時延，端到端的傳輸時延2）

抖動3）

誤碼率衡量這些指標(biāo)能夠用MOS來評判。

本文針對語音業(yè)務(wù)在網(wǎng)絡(luò)優(yōu)化中經(jīng)常出現(xiàn)的雜音、甚至因為語音不清晰最終導(dǎo)致掉話、聲音小等問題，描述了排查方法、數(shù)據(jù)采集和分析方法，并給出一些案例講明和原理、背景知識介紹。

本文定位于開局網(wǎng)優(yōu)，比拼測試不在本文檔的范圍。

本文檔中所描述的內(nèi)容要緊基于目前產(chǎn)品版本：

RNC設(shè)備，TDR2000

RNC設(shè)備，TDR3000

相關(guān)工具和命令要緊基于目前產(chǎn)品版本：

LDT-R（RNC告警、日志的提取和分析；傳輸層和無線的信令跟蹤和分析；QOS跟蹤分析；RNC各子系統(tǒng)SHELL命令的查詢）。

LMT-B。2

語音雜音問題評估2.1

語音QoS指標(biāo)要求依照ITU相關(guān)規(guī)范，以下三個因素會阻礙話音質(zhì)量：

話音清晰度(VoiceClarity)；

話音效果，包括回聲(Echo)、斷續(xù)(Time-clipping)等；

時延(TimeDelay)。由于話音效果會直接阻礙話音清晰度，故清晰度和時延是評估的重點。時延是一個能夠精確到毫秒級的客觀指標(biāo)，在實際評估方面可不能有何爭議；相反，人們關(guān)于清晰度一直缺乏一種統(tǒng)一的評判標(biāo)準(zhǔn)。依照ITU規(guī)范，清晰度應(yīng)該考慮以下幾個因素：

受不同網(wǎng)絡(luò)制式中不同類型失真(Distortion)的阻礙；

與時延無關(guān)；

與回聲無關(guān)，因為回聲是對發(fā)送方而言，清晰度是對接收方而言；在實際網(wǎng)絡(luò)中阻礙清晰度的失真(Distortion)類型包括：1.

話音編解碼(EncodingandDecodingofVoice)；2.

斷續(xù)(Time-Clipping，也稱為Dropouts)；3.

延時抖動(Jitter)；4.

環(huán)境噪音(EnvironmentNoise)；5.

信號衰減(SignalAttenuation)；6.

電平削波(LevelClipping)；7.

傳輸信道誤碼(TransmissionChannelErrors)；其中2與時延和信道質(zhì)量相關(guān)，4－7都可歸結(jié)為傳輸質(zhì)量(BER/FER)如此分解成可量化的指標(biāo)要緊有3項：(1)網(wǎng)絡(luò)延遲：網(wǎng)絡(luò)延遲將引起語音會話過程的空白，帶來語音的變形和會話的中斷。E-Model關(guān)注的是End-to-End的網(wǎng)絡(luò)延遲。在實際應(yīng)用中，一般是如下幾個方面而導(dǎo)致了網(wǎng)絡(luò)延遲：傳播延時：取決于傳播的介質(zhì)和距離；傳輸延時：傳輸過程中在網(wǎng)絡(luò)設(shè)備上所用時刻；打包解包延時：用采納的Codec進(jìn)行數(shù)模轉(zhuǎn)換的時刻，不同的Codec所導(dǎo)致的延時是不一樣的，然而關(guān)于同一種Codec，其延時差不多是固定的；抖動緩沖延時：在作用在同意端，為保持住一個或多個接收的數(shù)據(jù)包，克服網(wǎng)絡(luò)抖動的阻礙。(2)網(wǎng)絡(luò)抖動：網(wǎng)絡(luò)抖動確實是網(wǎng)絡(luò)延時的變化，當(dāng)網(wǎng)絡(luò)抖動值大于50ms時，MOS值將急劇下降；然而在ITU-TG.107中，是如此講的：“抖動對語音傳輸質(zhì)量的阻礙還在作進(jìn)一步的研究，可通過在接收端增加抖動緩沖的量，則能夠有效地降低抖動的阻礙，然而卻增加了網(wǎng)絡(luò)延時。(3)FER或BER：FER是阻礙語音質(zhì)量和MOS值的關(guān)鍵因素，隨機(jī)出錯，假如量小，對語音質(zhì)量阻礙小；連續(xù)出錯：這是指連續(xù)一個以上的數(shù)據(jù)包的出錯，這對語音質(zhì)量的阻礙是明顯的。關(guān)于語音業(yè)務(wù)QoS來講，關(guān)鍵三點：時延、抖動、誤碼率。以下是參考《MTTFE2EQoS研究－WCDMAQoS網(wǎng)絡(luò)KPI測試規(guī)范v1.1》以及中移動2，3期應(yīng)標(biāo)外廠測試得出的一些量化值。

移動撥打固話(呼叫建立時延)CallSetupDelayCSCallSetupDelay-AMR(MobiletoPSTN)關(guān)閉鑒權(quán)<3s～3.5s打開鑒權(quán)<3s～4.5s此延遲定義為以下2條消息之間的時刻間隔：

RRCConnectionRequest(CS)sentbythemobile

RRCDownlinkDirectTransfer(CCAlerting)receivedbythemobile公式為：

固話撥打移動(呼叫建立時延)CallSetupDelayCSCallSetupDelay-AMR(PSTNtoMobile)關(guān)閉鑒權(quán)<3s～5s打開鑒權(quán)<5s～7s此延遲定義為以下2條消息之間的時刻間隔：

RANAP/PagingsentbytheMSC

RANAP/CCAlertingreceivedbytheMSC公式為：

移動撥打移動(呼叫建立時延)CallSetupDelayCSCallSetupDelay-AMR(PSTNtoMobile)關(guān)閉鑒權(quán)<4s～6s打開鑒權(quán)<5s～7s此延遲定義為以下2條消息之間的時刻間隔：

RRCConnectionRequest(CS)sentbythemobile

RRCDownlinkDirectTransfer(CCAlerting)receivedbythemobile公式為：

移動三期招標(biāo)中興/大唐(AMR呼叫建立時延比較)AMR呼叫建立時延(MobiletoMobile)項目(中興三期/大唐三期/大唐二期)關(guān)鑒權(quán)4.604/5.115/6.269開鑒權(quán)5.334/5.932/6.788

移動三期招標(biāo)中興/大唐(CS64KStreaming呼叫建立時延比較)CS64k呼叫建立時延項目(中興三期/大唐三期/大唐二期or大唐二期補測)關(guān)鑒權(quán)4.181/5.187/未測or5.603開鑒權(quán)5.046/6.228/6.472or6.586

移動三期招標(biāo)中興/大唐(語音與H并發(fā)業(yè)務(wù)呼叫建立時延比較)HSDPA與R4CS12.2k語音業(yè)務(wù)并發(fā)情況下，R4CS12.2k語音業(yè)務(wù)呼叫建立時延/單位：s項目(中興三期/大唐三期/大唐二期補測)關(guān)鑒權(quán)3.979/5.313/7.890開鑒權(quán)5.318/6.042/8.567

移動三期招標(biāo)中興/大唐(AMR12.2切換時延時延比較)同一RNC內(nèi)不同NodeB間，AMR硬切換時延項目(中興三期/大唐三期/大唐二期補測)信令面0.455/0.402/0.826誤碼率和傳輸抖動，在TS23.107中有明確的定義：AMRspeechcodecpayload：

Bitrate:4,75-12,2kbit/s

Delay:end-to-enddelaynottoexceed100ms(codecframelengthis20ms)

BER:

10-4forClass1bits

10-3forClass2bits forsomeapplications,ahigherBERclass(~10-2)mightbefeasible.

FER <0,5%(withgracefuldegradationforhighererasurerates)附：MPEG-4videopayload:

Bitrate:variable,averageratescalablefrom24to128kbit/sandhigher

Delay:

end-to-enddelaybetween150and400ms

videocodecdelayistypicallylessthan200ms

BER:

10-6-novisibledegradation

10-5-littlevisibledegradation

10-4-somevisibleartefacts

>10-3-limitedpracticalapplication關(guān)于“抖動”，一般都需要通過MOS(儀)測試，下面是寧波移動在5月份進(jìn)行的抖動測試數(shù)據(jù)。另外關(guān)于IUB接口的承載要區(qū)不ATM和IP，理論分析和正常測試都表明，IP傳輸比ATM傳輸時延要小。2.2

可能的雜音情況目前差不多發(fā)覺的雜音情況如下：

語音接入正常，音質(zhì)正常(沒有雜音或者間斷)但不是專門清晰，通話能維持至結(jié)束；

語音接入正常，音質(zhì)正常(沒有雜音或者間斷)但不是專門清晰，越來越差，但通話能維持至結(jié)束；

語音接入正常，音質(zhì)正常(沒有雜音或者間斷)但不是專門清晰，越來越差，不能維持(掉話)；

語音接入正常，一直伴隨有輕微雜音，通話能維持至結(jié)束；

語音接入正常，一直伴隨有輕微雜音，越來越差，但通話能維持至結(jié)束；

語音接入正常，一直伴隨有輕微雜音，越來越差，不能維持(掉話)；

語音接入正常，有突發(fā)雜音(若干次)，通話能維持至結(jié)束；

語音接入正常，有突發(fā)雜音(若干次)，不能維持(掉話)；

語音接入正常，聲音小，通話能維持至結(jié)束；

語音接入正常，聲音小，越來越小，但通話能維持至結(jié)束；

語音接入正常，聲音小，越來越小，不能維持(掉話)；

語音接入正常，背景音大(超出正常范圍)，通話能維持至結(jié)束；

語音接入正常，背景音大(超出正常范圍)，不能維持(掉話)；

語音接入正常，音質(zhì)清晰但有間斷；

語音接入正常，音質(zhì)不清晰伴隨有間斷；

語音接入正常，音質(zhì)不清晰伴隨有雜音和間斷；

語音接入正常，切換時伴隨金屬雜音

語音接入至響鈴，振鈴間隙有雜音 3

語音雜音問題CheckList針對UE、RAN（RNC/NB分開）、CN、IU口、其他，制定CheckList，方便現(xiàn)場快速縮小問題范圍和定位故障。檢查類不檢查項自檢1、UE檢查1.1更換其它品牌終端是否還存在話音質(zhì)量問題1.2出現(xiàn)問題終端在其它小區(qū)是否存在語音質(zhì)量問題1.3是否使用耳機(jī)連線，不使用耳機(jī)連線是否還存在話音質(zhì)量問題。1.4使用固話撥打移動電話、移動電話撥打固話是否有話音質(zhì)量問題2、RNC檢查2.1抓取Qos跟蹤log，通過log初步分析是否有上行誤碼情況。備注：Qos跟蹤的每個統(tǒng)計周期(28S)的錯誤塊數(shù)超過14塊時，一般會出現(xiàn)明顯話音質(zhì)量變差現(xiàn)象。2.2提取對應(yīng)時刻段性能統(tǒng)計，看該小區(qū)的上行TSISCP測量是否偏高。備注：觀看ISCP平均和最大值，一般大于-90dBm就認(rèn)為有異常。2.3測試小區(qū)周邊小區(qū)相同時刻段的TSISCP是否異常。2.4檢查對應(yīng)的傳輸IMA是否有告警連續(xù)有IMA幀失步（ICP幀錯）。2.5假如2.4有告警，在RNC的CASA板上做IMA組向RNC內(nèi)部環(huán)回，在OMT上讀ＭＡ組性能計數(shù)和狀態(tài)，看是否有個不linkICP幀錯誤連續(xù)增加，講明IMA幀失步（ICP幀錯）是CASA的IMA芯片產(chǎn)生。2.6MSC假如是諾西設(shè)備，檢查RNC靜態(tài)參數(shù)中IU信息->IU信息（索引為8），是否含有Iu-RFCI信息3（對應(yīng)三個子流為全0的RFCI配置）。假如有，需要刪除。3、NB檢查3.1LMT-B上是否有CRC檢驗出錯告警；3.2LMT-B上是否有DSP任務(wù)運行故障告警。3.3LMT_B上IMA鏈路是否有丟棄信元，STUFF信元發(fā)送是否正常增加3.4LMT-B上是否有DCH的FP出窗告警3.5LMT-B上是否有PCH的FP出窗告警4、IU口4.1假如能夠在IU口架表，能夠抓取用戶面Log。查看IUUP幀是否有抖動，即IUUP幀號不連續(xù)，跳變。4.2Log中是否存在丟幀情況。4.3Log中是否存在PayloadCRC校驗錯。4.3Log中是否有“錯誤報告”的操縱幀出現(xiàn)。4

數(shù)據(jù)采集和分析4.1

綜述語音業(yè)務(wù)在接入以及通話過程中會存在各種各樣的問題，然而問題定位和定位LOG的采集一般方法都專門通用；(1)語音業(yè)務(wù)接入過程中信令失敗的定位方法首先假如語音在接入過程中信令失敗，按照哪個網(wǎng)元返回失敗那個網(wǎng)元先定位的原則，假如信令過程是終端、NODEB、CN返回的失敗，一般除帶有明顯的錯誤緣故外，首先需要其他網(wǎng)元分析失敗的緣故和抓取相應(yīng)的LOG進(jìn)行定位。其次假如接入過程是RNC返回失敗導(dǎo)致業(yè)務(wù)接入失敗，那樣一般需要先抓取小區(qū)詳細(xì)級（帶有RNC內(nèi)子系統(tǒng)的信令交互過程，能夠方便定位是哪個子系統(tǒng)返回德失敗）信令跟蹤來分析，一般內(nèi)部失敗都會帶有失敗緣故，依照失敗緣故查找錯誤碼表，找到對應(yīng)的錯誤；另外需要依照失敗緣故采納對應(yīng)的SHELL命令查找核對對應(yīng)的資源信息，最后是依照失敗返回的子系統(tǒng)，在LDT上開啟對應(yīng)得打印消息，抓取打印分析；如此一般的RNC問題就能夠得到定位和解決。(2)語音業(yè)務(wù)通話過程中問題的定位方法一般語音業(yè)務(wù)保持過程中，會存在掉話、切換失敗、有雜音等問題，掉話和切換失敗一般同上面的信令失敗的定位方法，有雜音問題是在業(yè)務(wù)保持過程中存在丟棄數(shù)據(jù)包造成的，要緊是定位在那個接口（IU、UU、IUB）或者網(wǎng)元內(nèi)部丟棄了數(shù)據(jù)包造成，目前各個網(wǎng)元差不多都提供了定位的手段。RNC能夠通過QOS跟蹤來定位IUB口上行的數(shù)據(jù)是否存在丟包，假如存在丟包，則需要先查傳輸層是否有丟包，然后再依照業(yè)務(wù)處理的IUUP統(tǒng)計和業(yè)務(wù)處理計數(shù)器統(tǒng)計來定位是否在IUB口和RNC內(nèi)部存在問題；另外RNC提供了語音環(huán)回功能，能夠定位接入網(wǎng)內(nèi)是否有問題；NODEB也提供了數(shù)據(jù)環(huán)回功能，能夠定位空口到NODEB內(nèi)部是否有問題，另外NODEB也提供了動態(tài)查詢物理傳輸是否存在丟包的功能，能夠方便定位物理層是否有問題。終端問題一般比較難定位，一般方法確實是通過終端物理層抓取軟件（TT）和信令抓取軟件(outum)對終端物理層何信令進(jìn)行分析，另外也能夠通過不同廠家的網(wǎng)絡(luò)來進(jìn)行對比測試驗證，來定位是否是終端的問題。CN的問題一般接入網(wǎng)人員專門難定位，一般需要借助CN側(cè)專用分析工具才能夠解析LOG來分析定位，一般假如定位到CN問題，能夠找CN支持人員直接定位即可。語音排查流程圖如下：4.2

NodeB側(cè)基站側(cè)需要做好的工作：

查詢基站軟件版本、固件版本、一單開站中的時鐘信息。

查詢小區(qū)的ID、頻點、碼字。

理清“頻點－BBU－RRU”的對應(yīng)關(guān)系。

查看小區(qū)ISCP的情況。

提取公共日志（初始化日志、告警日志、數(shù)據(jù)一致性文件、動態(tài)配置文件）、CCU41/43號日志、BBU全部日志、ATP消息。4.2.1

ATP抓日志的方法1.

BCP消息跟蹤，打開菜單“消息跟蹤->跟蹤設(shè)置”：APB-PL、PL-APB、APS-APB、APB-APS、APB-FP，用于跟蹤BBU內(nèi)部信令流程。RNC-FP，用于抄出FPRNC、RNCFP的消息。GTS-L2，用于抄出FPCC的消息。PL-GTS，用于抄出PL的消息。文件自動覆蓋條件，按照實際需求設(shè)置，一般取默認(rèn)值，能夠大些50M。2.

DSP之間相關(guān)消息跟蹤，打開菜單“消息跟蹤->測試消息設(shè)置”：O_M1FC_INSTANT_TS，分析物理層測量上報。O_SJCC_DATA，分析上行數(shù)據(jù)解調(diào)結(jié)果。O_CCBC_VRU_DATA，分析CC給BC數(shù)據(jù)。O_FCBC_CONTROL_DATA，分析下行發(fā)送功率和上行功控命令字。O_CCFC_RL_SYNC_IND，分析FC同步結(jié)果。O_FPFC_SIR_TARGET，分析外環(huán)功控結(jié)果。CC的10號FPCC。FP的11號FPRNC。FP的12號RNCFP。FP的13號CCFP，option3設(shè)置為255，分析CRCI譯碼結(jié)果。需要按照現(xiàn)場實際情況設(shè)置跟蹤的頻點號。3.

確認(rèn)消息跟蹤完整出現(xiàn)問題后，不要立即關(guān)閉，等待10s左右關(guān)閉LOG。在日志中搜索“CRNC_CC_ID=”，找到出現(xiàn)問題的ID（能夠由RNC提供，也能夠找到完整消息后向RNC確認(rèn)CRNC-CommunicationContextID）。確認(rèn)ID（如49821）后，搜索“CRNC_CC_ID=49821”，找到第一條消息對應(yīng)的消息名應(yīng)該是O_APSAPB_RL_SETUP_REQ，最后一條消息對應(yīng)的消息名應(yīng)該是O_APSAPB_RL_DEL_REQ。如此，就找到了一個完整的消息。截取兩條消息之間的內(nèi)容，搜索各關(guān)鍵字，看各關(guān)鍵消息是否抓到。如M1FC、CCBC、RNCFP、CCAPB等。4.2.2

傳輸問題導(dǎo)致該現(xiàn)象的排查方法1.

提取出現(xiàn)問題站點的告警日志。查看告警日志，具體操作方法參見4.2.3。檢查是否存在大量“FP下行DCHCRC校驗錯誤”和“FP收到TFI錯誤”告警。講明：少量馬賽克，上述告警次數(shù)的量級在個位數(shù)的級不；明顯馬賽克，上述告警次數(shù)量級在100以上；大量馬賽克，上述告警次數(shù)量級在1000次以上。2.

用-B連接問題NB，查詢IMA信息->鏈路性能統(tǒng)計，刷新并關(guān)注各條激活I(lǐng)MA鏈路的“幀失步”和“接收非法ICP信元”、“接收STUFF信元數(shù)”統(tǒng)計。檢查是否存在某條或某幾條IMA鏈路的“幀失步”和“接收非法ICP信元”統(tǒng)計非零，統(tǒng)計值約為2個/秒的頻率；”、“接收STUFF信元數(shù)”統(tǒng)計值為0。假如存在則記錄下該IMA鏈路的“邏輯鏈路號”。以下是可選步驟：3.

在該站點下做VP業(yè)務(wù)，觀看每次做VP業(yè)務(wù)時是否一定伴隨大量NBFP的下行DCHCRC校驗告警（注意要等待一個告警過濾周期的時刻）。4.

能夠在RNC上用命令行查詢RNC的IMA發(fā)送統(tǒng)計信息，直接能夠看到發(fā)送stuff計數(shù)。假如某一路發(fā)送stuff統(tǒng)計一直為0，而其他統(tǒng)計參數(shù)正常，再結(jié)合步驟2）的結(jié)果即能夠確認(rèn)該問題。假如同時存在(1)(2)((3))中所描述現(xiàn)象，則重點懷疑是目前RNC側(cè)IMA傳輸（驅(qū)動）發(fā)送的問題。4.2.3

NODEB側(cè)告警抓取和分析方法使用LMT-B工具。1）

NODEB告警抓取方法如下圖：講明：登陸LMT-B后，選擇文件，然后上傳需要的各種日志2）

告警打開分析方法如下圖：3）

NODEB常見告警分析一般通過NODEB告警能夠看出物理傳輸層的問題和NDOEB本地小區(qū)以及載波是否存在問題，假如NODEB本地小區(qū)或者載波有問題，在告警中也能夠看到相應(yīng)的告警，如此就能夠推斷NODEB本地小區(qū)和載波是否有問題。4.3

RNC側(cè)使用LDT-R工具。4.3.1

IMA物理傳輸?shù)腖OG抓取和分析方法1）

在RNC側(cè)接口板主CPU的SHELL上查詢以下信息獵取傳輸層IMA組和IMA鏈路信息drv_ima_ldt_group_count芯片號,IMA組號drv_ima_ldt_imalink_count芯片號,鏈路號drv_ima_ldt_task_count_print芯片號,0,6drv_ima_ldt_task_count_print芯片號,1,9drv_ima_ldt_imalink_event芯片號,鏈路號drv_ima_ldt_imalink_alarm芯片號,鏈路號2）

分析方法：drv_ima_ldt_group_count芯片號,IMA組號//查看打印結(jié)果是否有丟棄計數(shù)，假如IMA組存在信元丟棄統(tǒng)計，下一步在RNC側(cè)才需要確認(rèn)是那些鏈路上有信元丟棄，需要查詢IMA組內(nèi)各個鏈路的信元統(tǒng)計情況；假如不存在，以下鏈路的統(tǒng)計命令則不需要執(zhí)行，講明該IMA組工作正常drv_ima_ldt_imalink_count芯片號,鏈路號//查看打印結(jié)果中發(fā)送stuff信元個數(shù)，假如IMA組工作異常，查看RNC側(cè)STUFF信元發(fā)送統(tǒng)計，假如RNC側(cè)不發(fā)送STUFF信元（銀川IMA傳輸問題），則講明RNC側(cè)IMA工作異常。drv_ima_ldt_task_count_print芯片號,0,6//查看打印結(jié)果中IMA組添加、刪除的計數(shù)；當(dāng)出現(xiàn)IMA組工作異常后，需要查詢該統(tǒng)計以確認(rèn)出現(xiàn)問題時是否進(jìn)行過頻繁的刪除、添加操作依舊因為IMA閃斷引起的IMA工作異常drv_ima_ldt_task_count_print芯片號,1,9//查看打印結(jié)果中IMA鏈路添加、刪除的計數(shù)；當(dāng)出現(xiàn)IMA組工作異常后，需要查詢該統(tǒng)計以確認(rèn)出現(xiàn)問題時是否進(jìn)行過頻繁的刪除、添加操作依舊因為IMA閃斷引起的IMA工作異常drv_ima_ldt_imalink_event芯片號,鏈路號drv_ima_ldt_imalink_alarm芯片號,鏈路號//查看打印結(jié)果中IMA鏈路的告警計數(shù)；當(dāng)IMA組統(tǒng)計有信元丟棄時，再采納該命令查看IMA組內(nèi)的那些IMA鏈路存在告警，以確認(rèn)IMA組內(nèi)的那些鏈路故障。4.3.2

RNC側(cè)QOS跟蹤LOG的抓取和分析方法1）

QOS跟蹤抓取方法如下圖：2）

QOS跟蹤分析方法如下圖：3）

分析方法：選擇QOS跟蹤界面的QOS分析，RNC側(cè)只能分析上行QOS，針對語音業(yè)務(wù)，28S內(nèi)的上下行TB塊數(shù)應(yīng)該保持一致，一般語音業(yè)務(wù)正常的TB塊數(shù)為4200個（28s/20ms*3（語音業(yè)務(wù)塊數(shù)）），假如上行有誤塊，講明傳輸或者NODEB到RNC的處理數(shù)據(jù)有問題。如UE是否只在在切換過程中存在誤碼，首先在位置不變得情況下保持通話，看QOS跟蹤是否恒定在4200塊，沒有誤碼，現(xiàn)在移動UE，使得UE發(fā)生切換（在UE的工程信息和OMT上的小區(qū)內(nèi)UE信息查詢都能夠查詢UE是否進(jìn)行了切換），然后看切換發(fā)生的28S內(nèi)是否存在誤碼，然后再保持一段時刻，看28S內(nèi)的數(shù)據(jù)塊和誤碼是否恢復(fù)正常，就能夠確定是否是切換引起的誤塊。4.3.3

RNC側(cè)IUUP統(tǒng)計抓取和分析方法1）

從LDT信令跟蹤上確認(rèn)需要環(huán)回語音的用戶所在RTPA和DSP號，具體方法如下：在RAB指派后RNC本地資源分析消息中，查看倒數(shù)第二個響應(yīng)消息，依照RDBS_RDBS_LC_ALLOCATE_RSP_MSG中的DSPAddr后三位確定用戶接入在1-2-13RTPA業(yè)務(wù)板,依照DSPIP的最后一個字節(jié)確認(rèn)在9號CPU（DSP）。2）

在1-2-139CPU的模擬shell上敲：rnc_tpss_iuup_shell3）

分析方法：一般查看語音從正常到有雜音前后IUUP統(tǒng)計那些錯誤統(tǒng)計項有變化。當(dāng)語音正常沒有誤碼時，IUUP錯誤統(tǒng)計項維持不變，當(dāng)發(fā)生切換等產(chǎn)生誤碼后，IUUP錯誤統(tǒng)計項統(tǒng)計發(fā)生變化，講明有誤碼產(chǎn)生。4.3.4

語音環(huán)回使用方法介紹1）

從LDT信令跟蹤上確認(rèn)需要環(huán)回語音的用戶所在RTPA和DSP號，具體方法如下：在RAB指派后RNC本地資源分析消息中，查看倒數(shù)第二個響應(yīng)消息，依照RDBS_RDBS_LC_ALLOCATE_RSP_MSG中的DSPAddr后三位確定用戶接入在1-2-13RTPA業(yè)務(wù)板,依照DSPIP的最后一個字節(jié)確認(rèn)在9號CPU（DSP）。2）

在1-2-139CPU的模擬shell上敲：rnc_tpss_iuup_sm_loop_para_set1,UEID如此能夠打開此用戶的語音環(huán)回功能，其他用戶不受阻礙。rnc_tpss_iuup_sm_loop_para_set0,UEID則關(guān)閉此用戶的語音環(huán)回功能。4.3.5

VP環(huán)回使用方法介紹（FP層）1）首先依照信令跟蹤分不找到主被叫用戶所在DSP：在RAB指派后RNC本地資源分析消息中，查看倒數(shù)第二個響應(yīng)消息，依照RDBS_RDBS_LC_ALLOCATE_RSP_MSG中的DSPAddr后三位確定用戶接入在1-2-13RTPA業(yè)務(wù)板,依照DSPIP的最后一個字節(jié)確認(rèn)在9號CPU（DSP）。2）

在RNCFP層進(jìn)行環(huán)回：打開環(huán)回：在用戶所在DSP的模擬shell窗口中敲：rnc_tpss_fp_vp_loopUeID,0,16777216,0（UEID依照信令跟蹤中確定）關(guān)閉環(huán)回：在用戶所在DSP的模擬shell窗口中敲：rnc_tpss_fp_vp_loopUeID,0,0,04.3.6

VP環(huán)回使用方法介紹（IUUP層）1）

首先依照信令跟蹤分不找到主被叫用戶所在DSP在RAB指派后RNC本地資源分析消息中，查看倒數(shù)第二個響應(yīng)消息，依照RDBS_RDBS_LC_ALLOCATE_RSP_MSG中的DSPAddr后三位確定用戶接入在1-2-13RTPA業(yè)務(wù)板,依照DSPIP的最后一個字節(jié)確認(rèn)在9號CPU（DSP）。2）在RNCIUUP層進(jìn)行環(huán)回：打開環(huán)回：在用戶所在DSP的模擬shell窗口中敲：rnc_tpss_iuup_vp_loopUeID,0,16777216,0（UEID依照信令跟蹤中確定）關(guān)閉環(huán)回：在用戶所在DSP的模擬shell窗口中敲：rnc_tpss_iuup_vp_loopUeID,0,0,04.4

UE側(cè)目前UE側(cè)數(shù)據(jù)采集一般能夠使用兩種軟件：1.

SPANOutum5.02.

miniPTAS4.4.1

SPANOutum軟件抓取終端信令信息Outum軟件（SPANOutum5.0）能夠抓取終端的各項測量信息和層三信令抓取各項測量信息的方法。第一步：在outum軟件的選擇“Linechart”->在彈出的“Linechart”窗口->點擊右鍵選擇“屬性”->在彈出的“設(shè)置Chart屬性”窗口->點擊“修改”如下圖：第二步：在彈出的窗口中，在左側(cè)選中需要添加的測量IE，單擊“添加”->將選擇的IE添加到左側(cè)菜單中。在例子中添加一些測量值，具體測量值能夠依照需要進(jìn)行添加。第三步：單擊“確定”鍵后，完成添加，能夠在“Linechart”窗口看到測量結(jié)果，完成測試后保存LOG，能夠保存測試結(jié)果，供大伙兒分析。抓取層三信令的方法：第一步：在outum軟件的選擇“UU口消息”在彈出的窗口能夠看到UU口的消息，雙擊每條信令能夠看到每條信息的詳細(xì)IE，在“UU口消息”界面右鍵彈出列表后，點擊“ExportResults”能夠?qū)U口消息名、時刻戳等保存出來。右鍵點擊“UU口消息解碼”能夠?qū)⑿帕畋４嫦聛恚埠笈_分析。4.4.2

miniPTAS軟件聯(lián)芯log目前聯(lián)芯提供的miniPTAS版本，能夠抓取各層LOG，但只提供了LOG抓取功能，不能對LOG在軟件上進(jìn)行分析，只能發(fā)回聯(lián)芯進(jìn)行分析。第一步：單擊“文件”->“新建”->“測試工程”->選擇保存位置后，進(jìn)行保存。第二步：單擊“文件”->“新建”->“測試連接”->在彈出的界面上，查看是否是終端的鏈接->確認(rèn)后，完成測試連接的建立。第三步：點擊“連接”->在彈出菜單中->選擇“連接”->在輸出結(jié)果框中看到“差不多連上”代表連接建立成功。第四步：點擊“連接”->選擇“無線參數(shù)”->在彈出的窗口選擇需要抓取的LOG。第五步：使用終端發(fā)起業(yè)務(wù)，假如看到LOG數(shù)有變化，講明差不多抓取了LOG第六步：保存后，發(fā)給聯(lián)芯進(jìn)行分析4.5

CN側(cè)CN側(cè)能夠進(jìn)行內(nèi)部數(shù)據(jù)采集，但較苦惱，采集數(shù)據(jù)必須CN研發(fā)人員用專門的解碼工具轉(zhuǎn)換后方可看，解碼工具不公開。因此，CN側(cè)的數(shù)據(jù)采集需要由CN研發(fā)人員來做。那個地點不作介紹。5

語音雜音問題不同緣故分析5.1

語音保持過程中存在一直有雜音的情況1）

當(dāng)語音業(yè)務(wù)保持過程中一直存在雜音時，首先需要檢查傳輸是否正常，按照4.2.2節(jié)描述的排查IUB傳輸是否有問題2）

假如傳輸正常，雜音還存在，需要依照4.1節(jié)描述的問題定位流程進(jìn)行排查5.2

語音保持過程中突然出現(xiàn)單通或者雙方都聽不到聲音1）

首先依照4.3.2節(jié)描述獵取QOS跟蹤，確認(rèn)是否誤碼較大2）

提取ISCP15分鐘統(tǒng)計值，檢查ISCP是否有突變的情況3）

檢查NODEB告警是否有DSP故障告警4）

假如NDOEB存在DSP告警，一般是NODEB的BBU板卡出現(xiàn)問題，能夠嘗試替換BBU進(jìn)行測試，確認(rèn)問題返修有問題的BBU5）

假如問題還不能解決需要按照4.1節(jié)流程進(jìn)行排查5.3

語音保持雙方靜默時，主被叫均能夠聽到明顯有節(jié)奏的噪音。若雙方進(jìn)行通話后，噪音會逐漸減輕1）

首先需要確認(rèn)CN是那個廠商的設(shè)備，是否支持RFCI為NO_DATA（3個子流全0）的情況2）

假如CN支持RFCI為NO_DATA，則需要將RNC側(cè)rIuRfci表里面的RFCI對應(yīng)子流為0的字段刪掉3）

假如問題還不能解決需要按照4.1節(jié)流程進(jìn)行排查6

案例6.1

語音業(yè)務(wù)在切換過程中存在短暫的金屬雜音問題描述：語音業(yè)務(wù)在接力切換過程中存在短暫的金屬雜音問題分析：1）

傳輸排查：登陸LMT-B查看基站IMA鏈路是否有“接收非法ICP信元錯誤”和“幀失步”，STUFF信元發(fā)送統(tǒng)計是否在增加，推斷傳輸層是否有信元丟棄；經(jīng)定位沒有發(fā)覺傳輸問題。2）

業(yè)務(wù)QOS統(tǒng)計：對用戶進(jìn)行多次切換QoS跟蹤，發(fā)覺切換前后的上行誤碼都為0，只有在發(fā)生切換時的28S內(nèi)有誤碼產(chǎn)生；初步懷疑接力切換在實現(xiàn)上有問題。3）

查看小區(qū)切換方式，配置為接力切換，現(xiàn)在跟蹤到的QoS切換誤碼范圍為10~26塊，修改小區(qū)切換方式為硬切換，QoS跟蹤發(fā)覺切換時誤碼明顯減少，范圍為0~9，切換過程中雜音現(xiàn)象改善較大；經(jīng)RNC研發(fā)確認(rèn)RNC在接力切換目前的實現(xiàn)上存在問題，需要優(yōu)化處理。4）

查看基站測告警進(jìn)行分析，發(fā)覺有DCH出窗告警，經(jīng)基站研發(fā)分析告警LOG，認(rèn)為基站關(guān)于上行丟幀的處理方式和上行譯碼錯誤情況的處理方式需要改善；5）

檢查無線環(huán)境，是否服務(wù)小區(qū)和臨區(qū)RSCP值相當(dāng)，如此需要優(yōu)化無線環(huán)境解決方法：1）

RNC側(cè)處理：推斷關(guān)于語音業(yè)務(wù)，假如基站FP數(shù)據(jù)幀中的QE值上報為218的話，丟棄該數(shù)據(jù)包，不向CN發(fā)送，但外環(huán)功控的BLER統(tǒng)計需要正常累加。RNC推斷在切換狀態(tài)下，假如兩個小區(qū)上報的數(shù)據(jù)幀一個正確一個錯誤，選擇正確的上報CN；假如兩個小區(qū)上報的數(shù)據(jù)幀都錯誤，推斷QE值，選擇BER低上報CN。2）

基站側(cè)處理方式

關(guān)于上行丟幀的處理方式（此情況對應(yīng)于終端應(yīng)正常發(fā)送上行數(shù)據(jù)，但基站未能檢測到的情況）：a.PL層未通過激活檢測門限推斷，即SJ上報CC的數(shù)據(jù)指示未通過激活檢測；b.PL層通過激活檢測，但CC對TFCI譯碼后，推斷TFCI值超出建鏈參數(shù)的最大范圍；關(guān)于以上兩種情況，CC上報FP丟幀（CRCI填寫為0xff），F(xiàn)P上報RNC的數(shù)據(jù)幀中的CRCI指示為1，但QE值固定填寫為218（對應(yīng)0-255的協(xié)議值范圍）。

關(guān)于上行譯碼錯誤情況的處理方式：PL層通過激活檢測，且CC對TFCI譯碼在合理的范圍內(nèi)，但對傳輸信道的TB塊譯碼后CRC校驗錯；關(guān)于這種情況，CC上報FP的CRCI為0x80，誤比特率BER值按照實際計算值上報，F(xiàn)P將BER值填寫在QE位置供RNC使用。6.2

貴州省移動大樓語音質(zhì)量問題問題描述:移動李總反映在新華苑（貴州移動辦公大樓）14樓語音模糊不清晰。移動投訴語音質(zhì)量模糊不清晰的問題，復(fù)現(xiàn)情況描述如下：1）

T網(wǎng)->G網(wǎng)，通話10分鐘左右，突然上行出現(xiàn)單通，下行正常；2）

T網(wǎng)->G網(wǎng)，通話兩到三分鐘，出現(xiàn)雙方都聽不到對方講話。問題分析:測試人員在新華苑14樓進(jìn)行了問題復(fù)現(xiàn)，我們發(fā)覺語音質(zhì)量模糊不清晰時占用的是茅臺金波TD-1小區(qū)信號，通過RNC側(cè)QoS信令跟蹤發(fā)覺上行誤塊率高，基站側(cè)發(fā)覺時隙干擾ISCP異常，上站提取告警發(fā)覺同時有DSP任務(wù)運行故障告警，因此懷疑基站BBU板卡處理問題。解決方法:將茅臺金波站的BBU板更換到紅邊門站測試時多次復(fù)現(xiàn)了語音質(zhì)量問題，在茅臺金波站更換其他BBU板，大量測試下來語音質(zhì)量良好，但間或仍有毛刺，經(jīng)分析發(fā)覺，新華苑為單HSDPA配置，旁邊的新華社為雙HSDPA配置，HSDPA干擾了R4，將新華社改為單HSDPA配置后，再次通過大量測試，沒有發(fā)覺語音質(zhì)量問題，語音模糊不清晰的緣故確實是基站BBU板卡和HSDPA干擾了R4業(yè)務(wù)。其它:將茅臺金波站出現(xiàn)問題的BBU板差不多反饋給北京研發(fā)分析定位。6.3

上行語音質(zhì)量差問題描述:使用TD手機(jī)通話過程中出現(xiàn)語音不清晰現(xiàn)象問題分析:現(xiàn)場定位：第一：正常撥打語音電話，主被叫同時監(jiān)聽語音質(zhì)量；存在語音不清晰現(xiàn)象，但出現(xiàn)概率專門低，兩天測試才抓到4次如此的現(xiàn)象。第二：撥打語音電話，然后觸發(fā)小區(qū)間切換、NB間切換；容易出現(xiàn)語音不清晰現(xiàn)象，比例大概在30%到40%。第三：撥打測試，主被叫同時監(jiān)聽語音質(zhì)量。中間涉及到的變動包括更換基站版本、更換RRU、更換BBU槽位、更換基站（整站）、躍過室分系統(tǒng)、關(guān)閉外環(huán)功率操縱。結(jié)果顯示都存在話音不清晰問題?，F(xiàn)場定位總結(jié)：1、接入后就會出現(xiàn)不清晰的現(xiàn)象，但沒有切換觸發(fā)的語音不清晰的概率高。2、語音不清晰的時候，從空口上看RSCP、C/I、UE發(fā)射功率均正常。3、室內(nèi)分布3個基站（包含移動大樓）有語音不清晰問題，室外基站測試了2個小時沒有出現(xiàn)語音不清晰的現(xiàn)象。4、從NB和RNC聯(lián)合分析的結(jié)論：Iub口傳輸沒有問題。研發(fā)定位：單機(jī)測試環(huán)境下，模擬組織上行語音幀處理。由于考慮到該問題要緊頻繁出現(xiàn)在觸發(fā)切換后（切換時容易出現(xiàn)時刻抖動），因此模擬抖動情況進(jìn)行測試。模擬組織上行語音幀，測試發(fā)覺發(fā)送到CN的語音幀幀號錯誤，第一幀語音數(shù)據(jù)的幀號不為0，且后續(xù)的幀號不連續(xù)，如此就會導(dǎo)致CN在接收到語音幀并進(jìn)行幀號檢查時發(fā)覺幀號錯誤，做出幀號異常情況處理，進(jìn)而造成語音不清晰。代碼走查發(fā)覺，在目前的處理機(jī)制中，主調(diào)函數(shù)中每隔一個20ms調(diào)用一次上行數(shù)據(jù)處理函數(shù)。用戶實體建立成功后，上行數(shù)據(jù)處理函數(shù)第一次被調(diào)用時沒有推斷是否是真正的數(shù)據(jù)，就當(dāng)作是第一幀數(shù)據(jù)給予初始幀號，如此的話，當(dāng)?shù)谝粠嬲臄?shù)據(jù)到來時幀號差不多不是初始值。而且在第一幀數(shù)據(jù)到來時，沒有存儲當(dāng)前的rfn值，如此導(dǎo)致計算后續(xù)幀號時前一個rfn和當(dāng)前rfn的差值diffrfn過大，由此計算出來的幀號不連續(xù)。解決方法:修改上行數(shù)據(jù)處理函數(shù)。在第一幀數(shù)據(jù)處理之前增加是否是真正數(shù)據(jù)的推斷，只有真正的數(shù)據(jù)才給予幀號。在第一幀數(shù)據(jù)處理中增加存儲當(dāng)前的rfn值，如此才能保證后續(xù)計算幀號時diffrfn為固定的差值，計算出來的幀號確實是連續(xù)值。其他:該案例發(fā)生于2009年6月13日保定移動大樓。6.4

NoDATA數(shù)據(jù)情況下出現(xiàn)噪音

問題描述：

手機(jī)互打，雙方靜默時，主被叫均能夠聽到明顯有節(jié)奏的噪音。若雙方進(jìn)行通話后，噪音會逐漸減輕。CN測發(fā)送NO_DATA數(shù)據(jù)（即3個子流全部為0）的情況下，在終端會有雜音。

定位過程：

推斷CN是哪家的設(shè)備，因為有些廠家支持RFCI為NO_DATA（3個子流全0）的情況。假如CN不發(fā)NO_DATA數(shù)據(jù)，語音清晰。

阿爾卡特的CN支持全0的情況，而RNC在IUUP初始化消息里面攜帶了RFCI為全0的情況，因此CN認(rèn)為RNC支持RFCI為NO_DATA，會下發(fā)全0的數(shù)據(jù)?，F(xiàn)在雙方靜默時，主被叫均能夠聽到明顯有節(jié)奏的噪音，推斷可能是RNC對NO_DATA數(shù)據(jù)處理有問題，經(jīng)與研發(fā)溝通，定位過程如下：只模擬發(fā)送下行12.2k語音幀，數(shù)據(jù)處理正常；只模擬發(fā)送下行靜默幀（子流長度為39、0、0）數(shù)據(jù)處理正常；模擬發(fā)送下行NO_DATA數(shù)據(jù)（子流長度為0、0、0）數(shù)據(jù)處理有誤；模擬有抖動的情況下交替發(fā)送數(shù)據(jù)幀和靜默幀，則數(shù)據(jù)不能正常發(fā)送。這是由于語音處理有2個緩存交替存儲數(shù)據(jù)。正常情況下，只有一個緩存有數(shù)據(jù)，IU口每20ms來一包數(shù)據(jù)存下來。每20msMAC調(diào)度一次，MAC依照IUUP通知的數(shù)據(jù)量通知進(jìn)行TFC選擇，然后MAC依照選擇結(jié)果從IUUP取數(shù)據(jù)，MAC加頭之后交給FP處理，F(xiàn)P發(fā)送數(shù)據(jù)。

異常情況下（有抖動），兩個緩存都有數(shù)據(jù)（語音數(shù)據(jù)和靜默數(shù)據(jù)），由于當(dāng)前緩存處理完畢之后IUUP通知MAC剩余數(shù)據(jù)量（下一個緩存的數(shù)據(jù)長度）有誤，導(dǎo)致MACTFC選擇有誤，當(dāng)前緩存下的數(shù)據(jù)不能發(fā)送，導(dǎo)致語音質(zhì)量差。

解決方法：

在當(dāng)時RNC沒有升級的情況下，假如CN支持RFCI為NO_DATA，則需要將RNC側(cè)rIuRfci表里面的RFCI對應(yīng)子流為0的字段刪掉；RNC升級版本后可不能出現(xiàn)該問題。其他：該案例發(fā)生于2009年7月1日長春。7

總結(jié)本文針對語音業(yè)務(wù)網(wǎng)絡(luò)優(yōu)化中出現(xiàn)的語音不清晰甚至掉話、語音聲音小、突發(fā)噪音等問題，描述了如何一步步排查這些問題的方法、以及需要采集的數(shù)據(jù)和抓取的log，并如何進(jìn)行數(shù)據(jù)分析，最終問題解決。本文還給出了一些案例分析，通過這些案例積存關(guān)于我們解決類似問題也給出了專門好的借鑒。另外也介紹了相關(guān)技術(shù)原理和背景知識。依照后續(xù)更多案例分析以及問題定位方法等積存，能夠再進(jìn)一步完善本文檔。8

附錄介紹相關(guān)背景知識、以及一些原理性知識。8.1

端到端QoS技術(shù)原理在描述E2E的QoS之前，我們先了解一下語音的呼叫流程。在TD-SCDMA系統(tǒng)中，一個呼叫的建立，首先是通過終端與網(wǎng)絡(luò)側(cè)的信令交互，也確實是操縱面的過程，完成用戶面連接的建立。在一般的UMTS系統(tǒng)，一個標(biāo)準(zhǔn)的移動到移動的語音呼叫，原始信號(語音數(shù)據(jù))首先在發(fā)起側(cè)UE中編碼，通過無線接口的傳送，在本地代碼轉(zhuǎn)換機(jī)中轉(zhuǎn)換成A律或者μ律PCM編碼(符合ITU-TG.711制式標(biāo)準(zhǔn))后，在核心網(wǎng)中向遠(yuǎn)端傳輸；在遠(yuǎn)端代碼轉(zhuǎn)換機(jī)中再次進(jìn)行代碼轉(zhuǎn)換，將PCM語音格式轉(zhuǎn)換成為一種適合在無線接口上傳送的編碼格式，以便在遠(yuǎn)端無線接口上發(fā)送，最后在終結(jié)的UE中解碼，這種呼叫連接在核心網(wǎng)內(nèi)進(jìn)行兩次代碼轉(zhuǎn)換，通常稱為級聯(lián)配置。在講述語音的呼叫流程前，我們先要了解幾個關(guān)鍵概念：編解碼器、TFO、TrFO、AMR聲碼器、RFCI。其中TFO/TrFO的出現(xiàn)是因為編解碼器的級聯(lián)引入的兩次代碼轉(zhuǎn)換降低了語音質(zhì)量，當(dāng)語音編解碼器低速率工作時，這種阻礙尤為明顯。而TFO(TandemFreeOperation)和TrFO(TranscoderFreeOperation)機(jī)制的應(yīng)用能夠幸免核心網(wǎng)內(nèi)的兩次代碼轉(zhuǎn)換，它們共同的特點差不多上TC不進(jìn)行碼轉(zhuǎn)換（匯接），不將AMR語音編碼轉(zhuǎn)化為64kbpsPCM編碼，而是直接將AMR語音編碼在網(wǎng)絡(luò)中傳輸，從而大大地提高了語音QoS。

CODEC((COderandDECoder)編解碼器)用來對信息的原始表達(dá)方式進(jìn)行采樣，量化和編碼使其成為某種形式的碼流以及能將該碼流進(jìn)行解碼使其還原成為原始表達(dá)方式的一種設(shè)備。在3G網(wǎng)絡(luò)中，用于下行方向的編解碼器位于MSC；而用于上行的位于UE手機(jī)終端中。位于MSC和UE中的CODEC需要接收RNC的信令，以便依照RNC的要求來動態(tài)地調(diào)節(jié)和使用編碼速率。(上行是通過空中接口的操縱面協(xié)議進(jìn)行操縱，關(guān)于下行，RNC通過Iu接口的用戶面協(xié)議進(jìn)行操縱)。需要指出的是位于MSC中的編解碼器也稱為TranSCoder它用于將一種編碼方式的信息轉(zhuǎn)化成另一種不同的編碼方式。通常是將AMR編碼的壓縮語音轉(zhuǎn)換成PCM語音碼流，或是反之。注意：通常網(wǎng)絡(luò)都具有ITUG.711A-律的編解碼器可將信息轉(zhuǎn)換成為64Kb/sPCM語音碼流。

TFO(TandemFreeOperation)在GSM網(wǎng)絡(luò)進(jìn)展的后期，出現(xiàn)了TFO機(jī)制，它是一種呼叫配置，在信號鏈路上物理地存在代碼轉(zhuǎn)換設(shè)備，但代碼轉(zhuǎn)換功能被繞過。這種做法被第三代移動通信系統(tǒng)UMTS網(wǎng)絡(luò)繼承，但具體實現(xiàn)時又有差異，在兩端的呼叫建立時期完成之后，媒體網(wǎng)關(guān)中的代碼轉(zhuǎn)換機(jī)設(shè)備交換依照ITU-TG。711A律或μ律編碼的傳統(tǒng)64kb/sPCM語音抽樣。代碼轉(zhuǎn)換機(jī)通過竊取(stealing)每第16個抽樣中的一個最不重要的比特位，交換TFO消息，進(jìn)行兩端UE中編解碼器的協(xié)商。假如兩端的UE中應(yīng)用了兼容的語音編解碼類型，代碼轉(zhuǎn)換機(jī)自動激活TFO，傳輸壓縮語音的信道被映射在64kb/s的PCM編碼的最不重要的比特位上。假如應(yīng)用了不兼容的語音編解碼類型，TFO就不能被立即激活，呼叫回到一般的代碼轉(zhuǎn)換級聯(lián)操作模式下。然而，代碼轉(zhuǎn)換機(jī)還一直監(jiān)視PCM信號中是否含有帶內(nèi)協(xié)商編解碼的TFO消息，假如由于某種呼叫配置的改變，例如，遠(yuǎn)端發(fā)生了切換等，可能滿足TFO建立的條件時，代碼轉(zhuǎn)換機(jī)將再次嘗試發(fā)起和建立TFO(在TD系統(tǒng)中，TRO是差不多支持功能項)。在一個連接中配置的兩個編解碼轉(zhuǎn)換器它們都支持TFO協(xié)議同時配置一致的編解碼類型。如此能夠讓壓縮語音包在不進(jìn)行編解碼轉(zhuǎn)換的情況下直接插入并復(fù)寫PCM幀碼流（見下圖）。從而有效地旁路了編解碼轉(zhuǎn)換的功能。而一旦兩個編解碼轉(zhuǎn)換器有一個不支持TFO協(xié)議或是編解碼類型不匹配，則“Tandem”匯接操作就會發(fā)生：編解碼轉(zhuǎn)換器將對一側(cè)的編碼方式進(jìn)行匯接，轉(zhuǎn)換成為另一側(cè)所需要的編碼方式。也確實是前面曾提到的AMR編碼的壓縮語音和PCM碼流之間的轉(zhuǎn)換。TFO有以下特點：

編解碼類型和模式的協(xié)商是通過帶內(nèi)信令來進(jìn)行的，換句話講是在呼叫建立之后進(jìn)行的；

編解碼轉(zhuǎn)換（Transcoder）在呼叫通路中保留；

在兩個編解碼轉(zhuǎn)換設(shè)備之間一定采納的是PCM64Kb/s承載連接；

TFO能夠減少部分編解碼的過程，因此語音質(zhì)量有所提高。但關(guān)于帶寬和TC設(shè)備的節(jié)約并沒有什么關(guān)心；

支持WB-AMR；

適用于GSM和UMTS互連互通（也確實是TFO與TrFO互操作）；

TrFO(TranscoderFreeOperation)TrFO是3G系統(tǒng)所特有的，它同樣要求移動兩端所用的編解碼器類型相一致，但它所進(jìn)行的編解碼協(xié)商是一種帶外機(jī)制，編解碼器的協(xié)商發(fā)生在呼叫建立時期，也可能發(fā)生在呼叫中(由于其他某種緣故，如切換等)，首先在呼叫發(fā)起時，進(jìn)行編解碼器的協(xié)商，以試圖建立TrFO操作。發(fā)起側(cè)的UE在IAM消息中攜帶其所支持的編解碼器類型列表，通過無線接口、Iu接口(RNC和MSC之間)到達(dá)發(fā)起MSCServer，發(fā)起MSCServer從列表中剔除不支持的編解碼類型后再將其發(fā)給傳輸網(wǎng)絡(luò)；同樣地，傳輸網(wǎng)絡(luò)也從中剔除他不支持的類型后接著發(fā)向終結(jié)的MSCServer，終結(jié)MSCServer也執(zhí)行同樣的操作后將該列表發(fā)向終結(jié)UE，由終結(jié)UE結(jié)合此列表和自身的編解碼情況選擇一個最優(yōu)公共的編解碼類型，并依次向前返回給終結(jié)MSCServer、傳輸網(wǎng)絡(luò)、發(fā)起MSCServer和UE，通知他們當(dāng)前所選用的編解碼類型，如此在此編解碼器基礎(chǔ)上，開始分配建立承載。假如終結(jié)UE在選擇最優(yōu)公共編解碼器時失敗，即沒有公共的編解碼器可供使用，那么就選擇缺省的PCM編碼格式，發(fā)起側(cè)MSC應(yīng)在來自發(fā)起側(cè)UE的路徑上插入一個代碼轉(zhuǎn)換機(jī)?，F(xiàn)在，對終結(jié)UE的編解碼器選擇在終結(jié)MSC中選擇，他獨立于發(fā)起側(cè)MSC，這確實是TrFO建立失敗時的情況。若成功的建立承載，在Iu接口用戶平面上開始初始化過程，以確定傳輸壓縮語音的幀格式，初始化信息從發(fā)起的RNC向后傳向終結(jié)的RNC，在此鏈路上確定統(tǒng)一的幀格式，包括Nb接口(2個媒體網(wǎng)關(guān)之間的接口)，初始化完成后，壓縮語音就能夠在用戶平面內(nèi)傳送，移動到移動的TrFO的連接就完全建立起來了。(使用TrFO)通話過程中在兩個源編解碼器之間的通路上沒有涉及任何編解碼轉(zhuǎn)化。TrFO有以下特點：

由MSC-S操縱；

通過帶外編解碼協(xié)商來實現(xiàn)，換句話講是在呼叫建立之前進(jìn)行的；

需要ATM或是IP做為承載連接；

關(guān)于語音質(zhì)量，帶寬和TC的節(jié)約都有專門大的改善和提高；

支持WB-AMR；

適用于UMTS。注意：目前一般使用NB-AMR(與WB-AMR區(qū)不在于支持的語音速率較少)。

AMR聲碼器聲碼器是一種對話音進(jìn)行分析和合成的編、譯碼器，也稱話音分析合成系統(tǒng)或話音頻帶壓縮系統(tǒng)。它是壓縮通信頻帶和進(jìn)行保密通信的有力工具。聲碼器在發(fā)送端對語言信號進(jìn)行分析，提取出語言信號的特征參量加以編碼和加密，以取得和信道的匹配，經(jīng)信息道傳遞到同意端，再依照收到的特征參量恢復(fù)原始語言波形。分析可在頻域中進(jìn)行，對語言信號作頻譜分析，鑒不清濁音，測定濁音基頻，進(jìn)而選取清-濁推斷、濁音基頻和頻譜包絡(luò)作為特征參量加以傳送。分析也可在時域中進(jìn)行，利用其周期性提取一些參數(shù)進(jìn)行線性預(yù)測，或?qū)φZ言信號作相關(guān)分析。依照工作原理，聲碼器能夠分成：通道式聲碼器、共振峰聲碼器、圖案聲碼器、線性預(yù)測聲碼器、相關(guān)聲碼器、正交函數(shù)聲碼器。 人講話時，氣流通過喉頭形成聲源信號，然后激勵由口、鼻腔構(gòu)成的聲道，產(chǎn)生話音信號。聲碼器發(fā)信端的分析器首先對話音信號進(jìn)行分析，提取要緊話音參數(shù)：①聲源特性，如聲帶“振動-不振動”（濁-清音）、聲帶振動時的差不多頻率（基頻）；②聲道傳輸聲源信號的特性。這些話音參數(shù)變化專門慢，它們所占的總頻帶比話音本身的頻帶窄得多，因而對這些參數(shù)采樣編碼時總數(shù)碼率只有幾千甚至幾百比特／秒，只有直接由話音信號采樣編碼的數(shù)碼率的十幾分之一，能夠通過一個一般電話信道來傳輸。收信端的合成器利用這些參數(shù)來合成話音。 在第三代移動通信系統(tǒng)中，TD使用自適應(yīng)多速率(AMR：AdaptiveMulti-Rate)聲碼器來傳送話音，該聲碼器包括8種不同的聲碼器速率(在RNC側(cè)看到的確實是8種RAB子流組合)。AMR語音編碼分為三個子流是考慮到語音編碼中的信息的不同的重要性，及不同的差錯容忍性，每一個子流需要使用不同的QOS保證。子流1最重要，子流2其次，子流3最不重要。子流1在空中接口上需要使用更強的信道編碼來保證其正確性。其中的nodata速率是沒有講話時的編碼，而SID(靜默幀)則是用此幀來標(biāo)示目前語音沒有激活。在3G系統(tǒng)中AMR的引入是基于以下2點來考慮的：通過AMR模式操縱（AMRC）一方面能夠采納降低語音的速率來增強語音的質(zhì)量，另外一方面，能夠有效地減輕系統(tǒng)的負(fù)荷。因為在一定的無線負(fù)載情況下，為獲得用戶對語音質(zhì)量的最佳主觀感受，最合適的AMR語音速率不是最高速率，而是某一個合適的中間速率。因此，通過對負(fù)載的衡量，AMR模式操縱（AMRC）能夠做到：

負(fù)載重的情況下，降低AMR的語音速率，如此既減輕了系統(tǒng)的負(fù)載，又相對改善了語音的質(zhì)量

負(fù)載輕的情況下，增加AMR語音的速率，如此就盡量提高了QoS。另外，關(guān)于上行覆蓋受限的情況，降低AMR的語音速率能夠有效地擴(kuò)大上行的覆蓋范圍。

RFCI(RABsub-FlowCombinationIndicator)從上面聲碼器的圖中能夠看出，目前有10種聲碼器速率組合，每種速率組合中都含有3個子流速率，這種組合就稱之為RAB子流組合，每個RAB子流組合都有一個編號，確實是RFC指示(RFCI)，RNC與CN之間交互的每一幀語音數(shù)據(jù)頭上都會攜帶RFCI，用以告知對方數(shù)據(jù)的速率組合種類，以供對方使用(譬如關(guān)于RNC，將依照RFCI將CN發(fā)送的一個RAB語音幀拆分成3個子流數(shù)據(jù)，通過RB發(fā)送給UE，反之相同)。下面分析語音的端到端QoS。關(guān)于高性價比的移動通信網(wǎng)絡(luò)，既要求有較高的網(wǎng)絡(luò)容量，又要求良好的無線覆蓋以有效保證用戶的各種業(yè)務(wù)及QoS需求，因此系統(tǒng)端到端的分析(E2E)與實施為網(wǎng)絡(luò)中電路域和數(shù)據(jù)域的網(wǎng)絡(luò)缺陷和不足提供了可靠的依據(jù)。

QoS不同的網(wǎng)絡(luò)應(yīng)用對網(wǎng)絡(luò)傳輸時延、時延抖動和數(shù)據(jù)包丟失等指標(biāo)的要求不同。比如FTP對數(shù)據(jù)包丟失率比較敏感，而對傳輸時延、時延抖動要求不高；視頻點播VOD則正好相反。從全然上講QoS包括所有那些為網(wǎng)絡(luò)治理者提供操縱網(wǎng)絡(luò)傳輸時延、時延抖動和數(shù)據(jù)包丟失率的機(jī)制，這些機(jī)制使網(wǎng)絡(luò)能夠提供網(wǎng)絡(luò)視頻會議等實時、多媒體業(yè)務(wù)，在廣域網(wǎng)上為不同的業(yè)務(wù)、網(wǎng)絡(luò)應(yīng)用、組織甚至數(shù)據(jù)流提供不同的服務(wù)等級。從本質(zhì)上講存在兩種形式的QoS:資源預(yù)留(ResourceReservation),資源以業(yè)務(wù)的QoS要求為依照進(jìn)行分配，同時服從于資源治理策略；優(yōu)先級劃分(Priontization),依照資源治理策略，將各種應(yīng)用加以劃分，附以不同的優(yōu)先級不(對那些QoS要求較高的應(yīng)用分配高優(yōu)先級；反之分配低優(yōu)先級)。這兩種QoS并不互斥而是可配合使用。隨著VoIP、VOD、視頻以及多媒體業(yè)務(wù)的廣泛應(yīng)用，E2EQos操縱，即網(wǎng)絡(luò)數(shù)據(jù)從源端到目的端過程中如何保證時延、抖動和丟失率等指標(biāo)日益受到關(guān)注。數(shù)據(jù)流通過的各個層面、模塊都必須提供QoS能夠配置(基于QoS規(guī)范)、資源確保(基于QoS操縱協(xié)議)和可維護(hù)(基于監(jiān)視機(jī)制)，缺少任何一點，都不能真正保證E2EQoS。傳輸時延、時延抖動和誤碼率是衡量語音質(zhì)量的廣義基準(zhǔn)，我們在實際測試中，會對這三個范疇進(jìn)一步細(xì)化。譬如傳輸時延就會被拆分成語音呼叫建立時延、建立成功后的語音傳輸時延等等，關(guān)于語音業(yè)務(wù)的QoS，針對不同的傳輸環(huán)境，這些拆分后的步驟都有明確的量化指標(biāo)。這些量化指標(biāo)稱為KPI。

KPI性能指標(biāo)(KeyPerformanceIndicator)是網(wǎng)絡(luò)性能的度量值。通過性能指標(biāo)能夠全面地反映網(wǎng)絡(luò)質(zhì)量，使運營商充分掌握網(wǎng)絡(luò)的整體運行狀況為網(wǎng)絡(luò)的進(jìn)一步建設(shè)和優(yōu)化提供參考。其中關(guān)鍵性能指標(biāo)(KeyPerformanceIndicator)是所有性能指標(biāo)中最重要且最能體現(xiàn)網(wǎng)絡(luò)性能的關(guān)鍵參數(shù),它不僅滿足網(wǎng)絡(luò)運行質(zhì)量考核的需求，同時滿足網(wǎng)絡(luò)調(diào)整、網(wǎng)絡(luò)優(yōu)化和網(wǎng)絡(luò)維護(hù)的需求，實現(xiàn)無線網(wǎng)絡(luò)的調(diào)整包括：組網(wǎng)；網(wǎng)絡(luò)調(diào)整前的預(yù)測；網(wǎng)絡(luò)調(diào)整后的評估等等，同時還能解決網(wǎng)絡(luò)維護(hù)過程中發(fā)覺的問題。KPI包括呼叫建立特性、呼叫保持特性、移動治理特性和資源統(tǒng)計特性四類。TD-SCDMA系統(tǒng)的承載業(yè)務(wù)又能夠分為4類：會話類業(yè)務(wù)、流類業(yè)務(wù)、交互類業(yè)務(wù)、背景類業(yè)務(wù)。從業(yè)務(wù)質(zhì)量指標(biāo)方面考慮無線接入網(wǎng)UTRAN的性能指標(biāo)參數(shù)通常按照上述4類承載業(yè)務(wù)分不進(jìn)行統(tǒng)計。

呼叫建立特性(通過呼叫建立特性類性能指標(biāo)體現(xiàn))呼叫接通率是反映TD-SCDMA系統(tǒng)性能最重要的指標(biāo)也是運營商十分關(guān)注的指標(biāo)。一個完整的呼叫接通率有多個層次：尋呼成功率、RRC連接建立成功率和RAB指派成功率。UE從接收到CN發(fā)來的尋呼消息到RAB指派完成，完成一個完整的被叫呼叫流程。

RRC連接建立成功率反映了RNC或者小區(qū)的UE接納能力。RRC連接建立成功意味著UE與網(wǎng)絡(luò)建立了信令連接，RRC連接建立能夠分兩種情況：與業(yè)務(wù)相關(guān)的RRC連接建立和業(yè)務(wù)無關(guān)(如位置更新、系統(tǒng)間小區(qū)重選、注冊等的RRC連接建立。前者是衡量呼叫接通率的一個重要指標(biāo)，其結(jié)果能夠作為調(diào)整信道配置的依據(jù)；后者可用于考察系統(tǒng)負(fù)荷情況。處于空閑模式下的UE收到非接入層請求建立信令連接時UE將發(fā)起RRC連接建立過程，UTRAN收到RRC建立請求之后決定是否建立以及是建立在專用信道依舊公共信道上。RRC連接建立成功率(與業(yè)務(wù)相關(guān))用RRC連接建立次數(shù)和RRC連接建立嘗試次數(shù)的比來表示，對應(yīng)的信令分不為RNC收到的RRCCONNECTIONCOMPLETE次數(shù)和RNC收到的RRCCONNECTIONREQ次數(shù)。該指標(biāo)要求按不同業(yè)務(wù)類型分不進(jìn)行統(tǒng)計，做為PI。其計算公式為：RRC連接建立成功率=RRC連接建立成功次數(shù)/RRC連接建立嘗試次數(shù)*100%

RAB指派功率是成功為用戶分配了用戶平面的連接，是建立業(yè)務(wù)連接的最后一個步驟，直接反映了RNC或小區(qū)的接納能力。RAB指派由CN發(fā)起，UTRAN執(zhí)行。RAB是指用戶平面的承載，用于UE和CN之間傳送語音數(shù)據(jù)及多媒體業(yè)務(wù)，UE首先要完成RRC連接建立然后才能建立RAB，當(dāng)RAB建立成功以后一個差不多的呼叫即建立，UE進(jìn)入通話過程。RAB指派成功率用RAB指派成功響應(yīng)次數(shù)和RAB指派嘗試次數(shù)的比表示。對應(yīng)的信令分不為RABASSIGNMENTRESPONSE(RAB指派成功)和RABASSIGNMENTREQUEST(RAB建立請求).RAB建立成功率關(guān)于CS域和PS分不統(tǒng)計，該過程參見TS25.413和TS23.107，該指標(biāo)同時要求按不同RAB速率分不進(jìn)行統(tǒng)計，做為PI。其計算公式為：RAB指派成功率=RAB指派成功次數(shù)/RAB指派請求次數(shù)*100%

無線接通率從綜合的角度考慮接通率，把RRC連接建立成功率和RAB指派成功率聯(lián)合起來，其計算公式為：無線接通率=RAB建立成功率*RRC連接建立成功率

呼叫保持特性(通過呼叫保持特性類性能指標(biāo)體現(xiàn))掉話率反映了系統(tǒng)業(yè)務(wù)的通訊保持能力，是用戶直接感受的重要性能指標(biāo)之一。在其統(tǒng)計周期內(nèi)掉話的RAB數(shù)目與話務(wù)量的比值，其計算公式為：掉話率=(RNC請求釋放的電路域掉話的RAB數(shù)目+RNC請求釋放的分組域掉線的RAB數(shù)目)/(電路域RAB指派建立成功的RAB數(shù)目+分組域RAB指派建立成功的RAB數(shù)目)*100%

移動治理特性(通過移動性治理特性類性能指標(biāo)體現(xiàn))TD-SCDMA采納接力切換技術(shù)。切換是系統(tǒng)移動性治理的重要組成部分，切換成功率也是系統(tǒng)移動性治理性能的重要指標(biāo)。切換成功率全面地反映系統(tǒng)的切換性能，切換成功率反映切換的成功情況，通過切換能夠保證UE通信質(zhì)量。切換失敗在專門大程度上會引起無線鏈路失敗，進(jìn)而會導(dǎo)致用戶掉話的發(fā)生。該指標(biāo)通常是網(wǎng)規(guī)網(wǎng)優(yōu)調(diào)整無線參數(shù)的重要依據(jù)，而且是用戶能夠直接感受的最為重要性能指標(biāo)之一，其計算公式為：切換成功率=切換成功次數(shù)/切換嘗試次數(shù)*100%此項KPI指標(biāo)針對每個小區(qū)進(jìn)行統(tǒng)計時只考慮本小區(qū)的切換成功率，針對UTRAN進(jìn)行統(tǒng)計時，要將所有小區(qū)的切換成功次數(shù)、切換嘗試次數(shù)分不求和進(jìn)行計算。

資源統(tǒng)計特性(通過系統(tǒng)資源治理類性能指標(biāo)體現(xiàn))資源統(tǒng)計特性通常包括接口流量統(tǒng)計、上行誤塊率統(tǒng)計、小區(qū)碼資源利用率、尋呼擁塞率、業(yè)務(wù)擁塞率等。流量統(tǒng)計指標(biāo)反映了系統(tǒng)的負(fù)荷情況。系統(tǒng)的性能指標(biāo)在不同的負(fù)荷情況下的會有不同，在一定負(fù)荷情況下系統(tǒng)的性能表現(xiàn)被認(rèn)為是比較可信的。同時一定的系統(tǒng)負(fù)荷也能夠檢驗系統(tǒng)的穩(wěn)定性。而上行傳輸信道的誤塊率是反映無線接口上的信號傳輸質(zhì)量的重要指標(biāo)，是進(jìn)行一系列無線資源治理操縱的依據(jù)，阻礙著系統(tǒng)的切換、功控、接納等方面的性能。誤塊率指標(biāo)還體現(xiàn)了網(wǎng)絡(luò)的干擾狀況，是網(wǎng)絡(luò)規(guī)劃質(zhì)量的一個間接反映指標(biāo)。小區(qū)碼資源利用率反映碼資源的使用情況，為網(wǎng)規(guī)網(wǎng)優(yōu)提供依據(jù)。尋呼擁塞率間接反映了無線側(cè)尋呼信道的資源利用情況，是用戶可感受的指標(biāo)之一。業(yè)務(wù)擁塞率間接反映了無線和設(shè)備資源的利用情況，可輔助對網(wǎng)絡(luò)的容量利用率進(jìn)行推斷分析。在某種角度上，業(yè)務(wù)擁塞率與無線接通率所能反映的網(wǎng)絡(luò)狀況有一定重復(fù)，實際中如何使用還有待于網(wǎng)絡(luò)經(jīng)驗的積存。

MOS(平均主觀分?jǐn)?shù))作為第一種語音評估技術(shù)，MOS幾乎成為語音評估的代名詞。它實際上是一批人依照主觀感受對同一段語音進(jìn)行打分(OpinionScores)，然后再計算平均值(MeanValue)。具體的實現(xiàn)方法和評判標(biāo)準(zhǔn)在ITUP.800有相應(yīng)規(guī)定，在ITUP.830中提供了更詳細(xì)的操作方法。它的結(jié)果確實是我們現(xiàn)在熟知的1—5，具體定義如下：級不MOS分值用戶中意度優(yōu)5.0特不行，聽得專門清晰，無失真感，無延遲感良4.0稍差，聽得清晰，延遲小，有點雜音中3.0還能夠，聽不太清晰，有一定延遲，有雜音，有失真差2.0牽強，聽不太清，有較大雜音或斷續(xù)，失真嚴(yán)峻劣1.0極差，靜音或完全聽不清晰，雜音專門大這種早期的質(zhì)量評判方法現(xiàn)在來看是有明顯的缺陷：首先這是一種主觀測聽，完全依仗評判人的感受和經(jīng)驗，而感受、經(jīng)驗受測試人情緒、態(tài)度等客觀因素阻礙專門大，評估結(jié)果不可能完全公正，僅這一點就無法讓被評判對象信服；另外因為語音質(zhì)量測試可能是隨時隨地的(也希望如此)，因此就使得MOS這種評判實施起來專門困難，成本也特不昂貴，無法用于日常網(wǎng)絡(luò)質(zhì)量評估。基于如此的客觀現(xiàn)實，用機(jī)器來代替人對語音質(zhì)量進(jìn)行評判，就變得特不迫切了，因此出現(xiàn)了PSEQ算法，此算法的KEY依舊是時延、抖動和誤碼率，以及對應(yīng)的儀表(也確實是我們現(xiàn)在使用的MOS分析儀)。

PSEQ2000年5