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

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

目錄1 概述 42 語(yǔ)音雜音問(wèn)題評(píng)估 42.1 語(yǔ)音QoS指標(biāo)要求 42.2 可能的雜音情況 73 語(yǔ)音雜音問(wèn)題CheckList 74 數(shù)據(jù)采集和分析 84.1 綜述 84.2 NodeB側(cè) 94.2.1ATP抓日志的方法 94.2.2傳輸問(wèn)題導(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)計(jì)抓取和分析方法 164.3.4語(yǔ)音環(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ǔ)音業(yè)務(wù)在切換過(guò)程中存在短暫的金屬雜音 245.2 貴州省移動(dòng)大樓語(yǔ)音質(zhì)量問(wèn)題 255.3 上行語(yǔ)音質(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ì)量測(cè)量參數(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ǔ)音業(yè)務(wù)是傳統(tǒng)業(yè)務(wù)，衡量該業(yè)務(wù)的QoS指標(biāo)有以下幾個(gè)方面：1）

時(shí)延，端到端的傳輸時(shí)延2）

抖動(dòng)3）

誤碼率衡量這些指標(biāo)能夠用MOS來(lái)評(píng)判。

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

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

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

RNC設(shè)備，TDR2000

RNC設(shè)備，TDR3000

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

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

LMT-B。2

語(yǔ)音雜音問(wèn)題評(píng)估2.1

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

話音清晰度(VoiceClarity)；

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

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

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

與時(shí)延無(wú)關(guān)；

與回聲無(wú)關(guān)，因?yàn)榛芈暿菍?duì)發(fā)送方而言，清晰度是對(duì)接收方而言；在實(shí)際網(wǎng)絡(luò)中阻礙清晰度的失真(Distortion)類型包括：1.

話音編解碼(EncodingandDecodingofVoice)；2.

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

延時(shí)抖動(dòng)(Jitter)；4.

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

信號(hào)衰減(SignalAttenuation)；6.

電平削波(LevelClipping)；7.

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

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

RRCConnectionRequest(CS)sentbythemobile

RRCDownlinkDirectTransfer(CCAlerting)receivedbythemobile公式為：

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

RANAP/PagingsentbytheMSC

RANAP/CCAlertingreceivedbytheMSC公式為：

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

RRCConnectionRequest(CS)sentbythemobile

RRCDownlinkDirectTransfer(CCAlerting)receivedbythemobile公式為：

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

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

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

移動(dòng)三期招標(biāo)中興/大唐(AMR12.2切換時(shí)延時(shí)延比較)同一RNC內(nèi)不同NodeB間，AMR硬切換時(shí)延項(xiàng)目(中興三期/大唐三期/大唐二期補(bǔ)測(cè))信令面0.455/0.402/0.826誤碼率和傳輸抖動(dòng)，在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)于“抖動(dòng)”，一般都需要通過(guò)MOS(儀)測(cè)試，下面是寧波移動(dòng)在5月份進(jìn)行的抖動(dòng)測(cè)試數(shù)據(jù)。另外關(guān)于IUB接口的承載要區(qū)不ATM和IP，理論分析和正常測(cè)試都表明，IP傳輸比ATM傳輸時(shí)延要小。2.2

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

語(yǔ)音接入正常，切換時(shí)伴隨金屬雜音

語(yǔ)音接入至響鈴，振鈴間隙有雜音 3

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

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

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

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

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

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

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

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

提取公共日志（初始化日志、告警日志、數(shù)據(jù)一致性文件、動(dòng)態(tài)配置文件）、CCU41/43號(hào)日志、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的消息。文件自動(dòng)覆蓋條件，按照實(shí)際需求設(shè)置，一般取默認(rèn)值，能夠大些50M。2.

DSP之間相關(guān)消息跟蹤，打開菜單“消息跟蹤->測(cè)試消息設(shè)置”：O_M1FC_INSTANT_TS，分析物理層測(cè)量上報(bào)。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號(hào)FPCC。FP的11號(hào)FPRNC。FP的12號(hào)RNCFP。FP的13號(hào)CCFP，option3設(shè)置為255，分析CRCI譯碼結(jié)果。需要按照現(xiàn)場(chǎng)實(shí)際情況設(shè)置跟蹤的頻點(diǎn)號(hào)。3.

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

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

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

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

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

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

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

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

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

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

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

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

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

分析方法：drv_ima_ldt_group_count芯片號(hào),IMA組號(hào)//查看打印結(jié)果是否有丟棄計(jì)數(shù)，假如IMA組存在信元丟棄統(tǒng)計(jì)，下一步在RNC側(cè)才需要確認(rèn)是那些鏈路上有信元丟棄，需要查詢IMA組內(nèi)各個(gè)鏈路的信元統(tǒng)計(jì)情況；假如不存在，以下鏈路的統(tǒng)計(jì)命令則不需要執(zhí)行，講明該IMA組工作正常drv_ima_ldt_imalink_count芯片號(hào),鏈路號(hào)//查看打印結(jié)果中發(fā)送stuff信元個(gè)數(shù)，假如IMA組工作異常，查看RNC側(cè)STUFF信元發(fā)送統(tǒng)計(jì)，假如RNC側(cè)不發(fā)送STUFF信元（銀川IMA傳輸問(wèn)題），則講明RNC側(cè)IMA工作異常。drv_ima_ldt_task_count_print芯片號(hào),0,6//查看打印結(jié)果中IMA組添加、刪除的計(jì)數(shù)；當(dāng)出現(xiàn)IMA組工作異常后，需要查詢?cè)摻y(tǒng)計(jì)以確認(rèn)出現(xiàn)問(wèn)題時(shí)是否進(jìn)行過(guò)頻繁的刪除、添加操作依舊因?yàn)镮MA閃斷引起的IMA工作異常drv_ima_ldt_task_count_print芯片號(hào),1,9//查看打印結(jié)果中IMA鏈路添加、刪除的計(jì)數(shù)；當(dāng)出現(xiàn)IMA組工作異常后，需要查詢?cè)摻y(tǒng)計(jì)以確認(rèn)出現(xiàn)問(wèn)題時(shí)是否進(jìn)行過(guò)頻繁的刪除、添加操作依舊因?yàn)镮MA閃斷引起的IMA工作異常drv_ima_ldt_imalink_event芯片號(hào),鏈路號(hào)drv_ima_ldt_imalink_alarm芯片號(hào),鏈路號(hào)//查看打印結(jié)果中IMA鏈路的告警計(jì)數(shù)；當(dāng)IMA組統(tǒng)計(jì)有信元丟棄時(shí)，再采納該命令查看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，針對(duì)語(yǔ)音業(yè)務(wù)，28S內(nèi)的上下行TB塊數(shù)應(yīng)該保持一致，一般語(yǔ)音業(yè)務(wù)正常的TB塊數(shù)為4200個(gè)（28s/20ms*3（語(yǔ)音業(yè)務(wù)塊數(shù)）），假如上行有誤塊，講明傳輸或者NODEB到RNC的處理數(shù)據(jù)有問(wèn)題。如UE是否只在在切換過(guò)程中存在誤碼，首先在位置不變得情況下保持通話，看QOS跟蹤是否恒定在4200塊，沒(méi)有誤碼，現(xiàn)在移動(dòng)UE，使得UE發(fā)生切換（在UE的工程信息和OMT上的小區(qū)內(nèi)UE信息查詢都能夠查詢UE是否進(jìn)行了切換），然后看切換發(fā)生的28S內(nèi)是否存在誤碼，然后再保持一段時(shí)刻，看28S內(nèi)的數(shù)據(jù)塊和誤碼是否恢復(fù)正常，就能夠確定是否是切換引起的誤塊。4.3.3

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

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

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

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

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

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

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

VP環(huán)回使用方法介紹（FP層）1）首先依照信令跟蹤分不找到主被叫用戶所在DSP：在RAB指派后RNC本地資源分析消息中，查看倒數(shù)第二個(gè)響應(yīng)消息，依照RDBS_RDBS_LC_ALLOCATE_RSP_MSG中的DSPAddr后三位確定用戶接入在1-2-13RTPA業(yè)務(wù)板,依照DSPIP的最后一個(gè)字節(jié)確認(rèn)在9號(hào)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ù)第二個(gè)響應(yīng)消息，依照RDBS_RDBS_LC_ALLOCATE_RSP_MSG中的DSPAddr后三位確定用戶接入在1-2-13RTPA業(yè)務(wù)板,依照DSPIP的最后一個(gè)字節(jié)確認(rèn)在9號(hào)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）能夠抓取終端的各項(xiàng)測(cè)量信息和層三信令抓取各項(xiàng)測(cè)量信息的方法。第一步：在outum軟件的選擇“Linechart”->在彈出的“Linechart”窗口->點(diǎn)擊右鍵選擇“屬性”->在彈出的“設(shè)置Chart屬性”窗口->點(diǎn)擊“修改”如下圖：第二步：在彈出的窗口中，在左側(cè)選中需要添加的測(cè)量IE，單擊“添加”->將選擇的IE添加到左側(cè)菜單中。在例子中添加一些測(cè)量值，具體測(cè)量值能夠依照需要進(jìn)行添加。第三步：?jiǎn)螕簟按_定”鍵后，完成添加，能夠在“Linechart”窗口看到測(cè)量結(jié)果，完成測(cè)試后保存LOG，能夠保存測(cè)試結(jié)果，供大伙兒分析。抓取層三信令的方法：第一步：在outum軟件的選擇“UU口消息”在彈出的窗口能夠看到UU口的消息，雙擊每條信令能夠看到每條信息的詳細(xì)IE，在“UU口消息”界面右鍵彈出列表后，點(diǎn)擊“ExportResults”能夠?qū)U口消息名、時(shí)刻戳等保存出來(lái)。右鍵點(diǎn)擊“UU口消息解碼”能夠?qū)⑿帕畋４嫦聛?lái)，共后臺(tái)分析。4.4.2

miniPTAS軟件聯(lián)芯log目前聯(lián)芯提供的miniPTAS版本，能夠抓取各層LOG，但只提供了LOG抓取功能，不能對(duì)LOG在軟件上進(jìn)行分析，只能發(fā)回聯(lián)芯進(jìn)行分析。第一步：?jiǎn)螕簟拔募?>“新建”->“測(cè)試工程”->選擇保存位置后，進(jìn)行保存。第二步：?jiǎn)螕簟拔募?>“新建”->“測(cè)試連接”->在彈出的界面上，查看是否是終端的鏈接->確認(rèn)后，完成測(cè)試連接的建立。第三步：點(diǎn)擊“連接”->在彈出菜單中->選擇“連接”->在輸出結(jié)果框中看到“差不多連上”代表連接建立成功。第四步：點(diǎn)擊“連接”->選擇“無(wú)線參數(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ā)人員來(lái)做。那個(gè)地點(diǎn)不作介紹。5

語(yǔ)音雜音問(wèn)題不同緣故分析5.1

語(yǔ)音保持過(guò)程中存在一直有雜音的情況1）

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

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

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

首先依照4.3.2節(jié)描述獵取QOS跟蹤，確認(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）

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

語(yǔ)音保持雙方靜默時(shí)，主被叫均能夠聽到明顯有節(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）

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

案例6.1

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

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

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

查看小區(qū)切換方式，配置為接力切換，現(xiàn)在跟蹤到的QoS切換誤碼范圍為10~26塊，修改小區(qū)切換方式為硬切換，QoS跟蹤發(fā)覺(jué)切換時(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ā)覺(jué)有DCH出窗告警，經(jīng)基站研發(fā)分析告警LOG，認(rèn)為基站關(guān)于上行丟幀的處理方式和上行譯碼錯(cuò)誤情況的處理方式需要改善；5）

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

RNC側(cè)處理：推斷關(guān)于語(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è)處理方式

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

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

貴州省移動(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)雙方都聽不到對(duì)方講話。問(wèn)題分析:測(cè)試人員在新華苑14樓進(jìn)行了問(wèn)題復(fù)現(xiàn)，我們發(fā)覺(jué)語(yǔ)音質(zhì)量模糊不清晰時(shí)占用的是茅臺(tái)金波TD-1小區(qū)信號(hào)，通過(guò)RNC側(cè)QoS信令跟蹤發(fā)覺(jué)上行誤塊率高，基站側(cè)發(fā)覺(jué)時(shí)隙干擾ISCP異常，上站提取告警發(fā)覺(jué)同時(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ā)覺(jué)，新華苑為單HSDPA配置，旁邊的新華社為雙HSDPA配置，HSDPA干擾了R4，將新華社改為單HSDPA配置后，再次通過(guò)大量測(cè)試，沒(méi)有發(fā)覺(jué)語(yǔ)音質(zhì)量問(wèn)題，語(yǔ)音模糊不清晰的緣故確實(shí)是基站BBU板卡和HSDPA干擾了R4業(yè)務(wù)。其它:將茅臺(tái)金波站出現(xiàn)問(wèn)題的BBU板差不多反饋給北京研發(fā)分析定位。6.3

上行語(yǔ)音質(zhì)量差問(wèn)題描述:使用TD手機(jī)通話過(guò)程中出現(xiàn)語(yǔ)音不清晰現(xiàn)象問(wèn)題分析:現(xiàn)場(chǎng)定位：第一：正常撥打語(yǔ)音電話，主被叫同時(shí)監(jiān)聽語(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)聽語(yǔ)音質(zhì)量。中間涉及到的變動(dòng)包括更換基站版本、更換RRU、更換BBU槽位、更換基站（整站）、躍過(guò)室分系統(tǒng)、關(guān)閉外環(huán)功率操縱。結(jié)果顯示都存在話音不清晰問(wèn)題?，F(xiàn)場(chǎng)定位總結(jié)：1、接入后就會(huì)出現(xiàn)不清晰的現(xiàn)象，但沒(méi)有切換觸發(fā)的語(yǔ)音不清晰的概率高。2、語(yǔ)音不清晰的時(shí)候，從空口上看RSCP、C/I、UE發(fā)射功率均正常。3、室內(nèi)分布3個(gè)基站（包含移動(dòng)大樓）有語(yǔ)音不清晰問(wèn)題，室外基站測(cè)試了2個(gè)小時(shí)沒(méi)有出現(xiàn)語(yǔ)音不清晰的現(xiàn)象。4、從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ā)覺(jué)發(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ā)覺(jué)幀號(hào)錯(cuò)誤，做出幀號(hào)異常情況處理，進(jìn)而造成語(yǔ)音不清晰。代碼走查發(fā)覺(jué)，在目前的處理機(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)差不多不是初始值。而且在第一幀數(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)確實(shí)是連續(xù)值。其他:該案例發(fā)生于2009年6月13日保定移動(dòng)大樓。6.4

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

問(wèn)題描述：

手機(jī)互打，雙方靜默時(shí)，主被叫均能夠聽到明顯有節(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ù)?，F(xiàn)在雙方靜默時(shí)，主被叫均能夠聽到明顯有節(jié)奏的噪音，推斷可能是RNC對(duì)NO_DATA數(shù)據(jù)處理有問(wèn)題，經(jīng)與研發(fā)溝通，定位過(guò)程如下：只模擬發(fā)送下行12.2k語(yǔ)音幀，數(shù)據(jù)處理正常；只模擬發(fā)送下行靜默幀（子流長(zhǎng)度為39、0、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依照IUUP通知的數(shù)據(jù)量通知進(jìn)行TFC選擇，然后MAC依照選擇結(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)致MACTFC選擇有誤，當(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í)版本后可不能出現(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ò)這些案例積存關(guān)于我們解決類似問(wèn)題也給出了專門好的借鑒。另外也介紹了相關(guān)技術(shù)原理和背景知識(shí)。依照后續(xù)更多案例分析以及問(wèn)題定位方法等積存，能夠再進(jìn)一步完善本文檔。8

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

端到端QoS技術(shù)原理在描述E2E的QoS之前，我們先了解一下語(yǔ)音的呼叫流程。在TD-SCDMA系統(tǒng)中，一個(gè)呼叫的建立，首先是通過(guò)終端與網(wǎng)絡(luò)側(cè)的信令交互，也確實(shí)是操縱面的過(guò)程，完成用戶面連接的建立。在一般的UMTS系統(tǒng)，一個(gè)標(biāo)準(zhǔn)的移動(dòng)到移動(dòng)的語(yǔ)音呼叫，原始信號(hào)(語(yǔ)音數(shù)據(jù))首先在發(fā)起側(cè)UE中編碼，通過(guò)無(wú)線接口的傳送，在本地代碼轉(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語(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(TandemFreeOperation)和TrFO(TranscoderFreeOperation)機(jī)制的應(yīng)用能夠幸免核心網(wǎng)內(nèi)的兩次代碼轉(zhuǎn)換，它們共同的特點(diǎn)差不多上TC不進(jìn)行碼轉(zhuǎn)換（匯接），不將AMR語(yǔ)音編碼轉(zhuǎn)化為64kbpsPCM編碼，而是直接將AMR語(yǔ)音編碼在網(wǎng)絡(luò)中傳輸，從而大大地提高了語(yǔ)音QoS。

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

TFO(TandemFreeOperation)在GSM網(wǎng)絡(luò)進(jìn)展的后期，出現(xiàn)了TFO機(jī)制，它是一種呼叫配置，在信號(hào)鏈路上物理地存在代碼轉(zhuǎn)換設(shè)備，但代碼轉(zhuǎn)換功能被繞過(guò)。這種做法被第三代移動(dòng)通信系統(tǒng)UMTS網(wǎng)絡(luò)繼承，但具體實(shí)現(xiàn)時(shí)又有差異，在兩端的呼叫建立時(shí)期完成之后，媒體網(wǎng)關(guān)中的代碼轉(zhuǎn)換機(jī)設(shè)備交換依照ITU-TG。711A律或μ律編碼的傳統(tǒng)64kb/sPCM語(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ǔ)音的信道被映射在64kb/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é)議同時(shí)配置一致的編解碼類型。如此能夠讓壓縮語(yǔ)音包在不進(jìn)行編解碼轉(zhuǎn)換的情況下直接插入并復(fù)寫PCM幀碼流（見下圖）。從而有效地旁路了編解碼轉(zhuǎn)換的功能。而一旦兩個(gè)編解碼轉(zhuǎn)換器有一個(gè)不支持TFO協(xié)議或是編解碼類型不匹配，則“Tandem”匯接操作就會(huì)發(fā)生：編解碼轉(zhuǎn)換器將對(duì)一側(cè)的編碼方式進(jìn)行匯接，轉(zhuǎn)換成為另一側(cè)所需要的編碼方式。也確實(shí)是前面曾提到的AMR編碼的壓縮語(yǔ)音和PCM碼流之間的轉(zhuǎn)換。TFO有以下特點(diǎn)：

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

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

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

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

支持WB-AMR；

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

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

由MSC-S操縱；

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

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

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

支持WB-AMR；

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

PSEQ2000年5