語音業(yè)務(wù)雜音問題優(yōu)化指導(dǎo)書

1、語音業(yè)務(wù)雜音問題優(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ān)著作權(quán)法律的保護(hù)。未經(jīng)大唐移動(dòng)書面授權(quán)，任何人不得以任何形式復(fù)制、傳播、散布、改動(dòng)或以其它方式使用本資料的部分或全部內(nèi)容，違者將被依法追究責(zé)任。文檔更新記錄日期更新人版本備注2009-7-6趙敏V0.0.1創(chuàng)建模板2009-7-16王銳、李彥峰、馬忱、梁劍、楊蕾、施秉利、趙敏V0.0.2補(bǔ)充14、68章節(jié)內(nèi)容2009-7-22趙敏V1.0.0根據(jù)中試、NB同事反饋，

2、補(bǔ)充4.4、4.5、7.3章節(jié)的內(nèi)容。目錄 HYPERLINK l _Toc236019658 1概述4 HYPERLINK l _Toc236019659 2語音雜音問題評(píng)估4 HYPERLINK l _Toc236019660 2.1語音QoS指標(biāo)要求4 HYPERLINK l _Toc236019661 2.2可能的雜音情況7 HYPERLINK l _Toc236019662 3語音雜音問題CheckList7 HYPERLINK l _Toc236019663 4數(shù)據(jù)采集和分析8 HYPERLINK l _Toc236019664 4.1綜述8 HYPERLINK l _Toc236

3、019665 4.2NodeB側(cè)9 HYPERLINK l _Toc236019666 4.2.1 ATP抓日志的方法9 HYPERLINK l _Toc236019667 4.2.2 傳輸問題導(dǎo)致該現(xiàn)象的排查方法11 HYPERLINK l _Toc236019668 4.2.3 NODEB側(cè)告警抓取和分析方法12 HYPERLINK l _Toc236019669 4.3RNC側(cè)13 HYPERLINK l _Toc236019670 4.3.1 IMA物理傳輸?shù)腖OG抓取和分析方法13 HYPERLINK l _Toc236019671 4.3.2 RNC側(cè)QOS跟蹤LOG的抓取和分析方

4、法15 HYPERLINK l _Toc236019672 4.3.3 RNC側(cè)IUUP統(tǒng)計(jì)抓取和分析方法16 HYPERLINK l _Toc236019673 4.3.4 語音環(huán)回使用方法介紹17 HYPERLINK l _Toc236019674 4.3.5 VP環(huán)回使用方法介紹（FP層）18 HYPERLINK l _Toc236019675 4.3.6 VP環(huán)回使用方法介紹（IUUP層）18 HYPERLINK l _Toc236019676 4.4UE側(cè)19 HYPERLINK l _Toc236019677 4.4.1 SPAN Outum軟件抓取終端信令信息19 HYPERLI

5、NK l _Toc236019678 4.4.2 miniPTAS軟件聯(lián)芯log21 HYPERLINK l _Toc236019679 4.5CN側(cè)24 HYPERLINK l _Toc236019680 5案例24 HYPERLINK l _Toc236019681 5.1語音業(yè)務(wù)在切換過程中存在短暫的金屬雜音24 HYPERLINK l _Toc236019682 5.2貴州省移動(dòng)大樓語音質(zhì)量問題25 HYPERLINK l _Toc236019683 5.3上行語音質(zhì)量差26 HYPERLINK l _Toc236019684 5.4No DATA數(shù)據(jù)情況下出現(xiàn)噪音26 HYPERLI

6、NK l _Toc236019685 6總結(jié)27 HYPERLINK l _Toc236019686 7附錄27 HYPERLINK l _Toc236019687 7.1端到端QoS技術(shù)原理27 HYPERLINK l _Toc236019688 7.2RNC相關(guān)參數(shù)匯總35 HYPERLINK l _Toc236019689 7.2.1 Iu參數(shù)配置35 HYPERLINK l _Toc236019690 7.2.2 RRM算法全局參數(shù)40 HYPERLINK l _Toc236019691 7.2.3 功率控制參數(shù)40 HYPERLINK l _Toc236019692 7.2.4 上行

7、外環(huán)功率控制參數(shù)46 HYPERLINK l _Toc236019693 7.2.5 業(yè)務(wù)質(zhì)量測(cè)量參數(shù)47 HYPERLINK l _Toc236019694 7.2.6 業(yè)務(wù)同步參數(shù)50 HYPERLINK l _Toc236019695 7.2.7 業(yè)務(wù)QoS參數(shù)調(diào)度53 HYPERLINK l _Toc236019696 7.3NodeB相關(guān)參數(shù)匯總53 HYPERLINK l _Toc236019697 7.4其他業(yè)務(wù)QoS保證建議54 1 概述語音業(yè)務(wù)是傳統(tǒng)業(yè)務(wù)，衡量該業(yè)務(wù)的QoS指標(biāo)有以下幾個(gè)方面：1） 時(shí)延，端到端的傳輸時(shí)延2） 抖動(dòng)3） 誤碼率衡量這些指標(biāo)可以用MOS來評(píng)判。

8、本文針對(duì)語音業(yè)務(wù)在網(wǎng)絡(luò)優(yōu)化中經(jīng)常出現(xiàn)的雜音、甚至因?yàn)檎Z音不清晰最終導(dǎo)致掉話、聲音小等問題，描述了排查方法、數(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告警、日志的提取和分析；傳輸層和無線的信令跟蹤和分析；QOS跟蹤分析；RNC各子系統(tǒng)SHELL命令的查詢）。 LMT-B。2 語音雜音問題評(píng)估2.1 語音QoS指標(biāo)要求根據(jù)ITU相關(guān)規(guī)范，以下三個(gè)因素會(huì)影響話音質(zhì)量： 話音清晰度

9、(Voice Clarity)； 話音效果，包括回聲(Echo)、斷續(xù)(Time-clipping)等； 時(shí)延(Time Delay)。由于話音效果會(huì)直接影響話音清晰度，故清晰度和時(shí)延是評(píng)估的重點(diǎn)。時(shí)延是一個(gè)可以精確到毫秒級(jí)的客觀指標(biāo)，在實(shí)際評(píng)估方面不會(huì)有何爭議；相反，人們對(duì)于清晰度一直缺乏一種統(tǒng)一的評(píng)判標(biāo)準(zhǔn)。根據(jù)ITU規(guī)范，清晰度應(yīng)該考慮以下幾個(gè)因素： 受不同網(wǎng)絡(luò)制式中不同類型失真(Distortion)的影響； 與時(shí)延無關(guān)； 與回聲無關(guān)，因?yàn)榛芈暿菍?duì)發(fā)送方而言，清晰度是對(duì)接收方而言；在實(shí)際網(wǎng)絡(luò)中影響清晰度的失真(Distortion)類型包括：1. 話音編解碼(Encoding and D

10、ecoding of Voice)；2. 斷續(xù)(Time-Clipping，也稱為Dropouts)；3. 延時(shí)抖動(dòng)(Jitter)；4. 環(huán)境噪音(Environment Noise)；5. 信號(hào)衰減(Signal Attenuation)；6. 電平削波(Level Clipping)；7. 傳輸信道誤碼(Transmission Channel Errors)；其中2與時(shí)延和信道質(zhì)量相關(guān)，47都可歸結(jié)為傳輸質(zhì)量(BER/FER)這樣分解成可量化的指標(biāo)主要有3項(xiàng)：(1)網(wǎng)絡(luò)延遲：網(wǎng)絡(luò)延遲將引起語音會(huì)話過程的空白，帶來語音的變形和會(huì)話的中斷。E-Model關(guān)注的是End-to-End的網(wǎng)絡(luò)延

11、遲。在實(shí)際應(yīng)用中，一般是如下幾個(gè)方面而導(dǎo)致了網(wǎng)絡(luò)延遲：傳播延時(shí)：取決于傳播的介質(zhì)和距離；傳輸延時(shí)：傳輸過程中在網(wǎng)絡(luò)設(shè)備上所用時(shí)間；打包解包延時(shí)：用采用的Codec進(jìn)行數(shù)模轉(zhuǎn)換的時(shí)間，不同的Codec所導(dǎo)致的延時(shí)是不一樣的，但是對(duì)于同一種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)就是網(wǎng)絡(luò)延時(shí)的變化，當(dāng)網(wǎng)絡(luò)抖動(dòng)值大于50ms時(shí)，MOS值將急劇下降；但是在ITU-T G.107中，是這樣說的：“抖動(dòng)對(duì)語音傳輸質(zhì)量的影響還在作進(jìn)一步的研究，可通過在接收端增加抖動(dòng)緩沖的量，則可以有效地降低抖動(dòng)的影響，但是卻增

12、加了網(wǎng)絡(luò)延時(shí)。(3)FER或BER：FER是影響語音質(zhì)量和MOS值的關(guān)鍵因素，隨機(jī)出錯(cuò)，如果量小，對(duì)語音質(zhì)量影響?。贿B續(xù)出錯(cuò)：這是指連續(xù)一個(gè)以上的數(shù)據(jù)包的出錯(cuò)，這對(duì)語音質(zhì)量的影響是明顯的。對(duì)于語音業(yè)務(wù)QoS來說，關(guān)鍵三點(diǎn)：時(shí)延、抖動(dòng)、誤碼率。以下是參考MTTF E2E QoS研究WCDMA QoS網(wǎng)絡(luò)KPI測(cè)試規(guī)范v1.1以及中移動(dòng)2，3期應(yīng)標(biāo)外廠測(cè)試得出的一些量化值。 移動(dòng)撥打固話(呼叫建立時(shí)延)Call Setup DelayCS Call Setup Delay-AMR (Mobile to PSTN)關(guān)閉鑒權(quán)3s3.5s打開鑒權(quán)3s4.5s此延遲定義為以下2條消息之間的時(shí)間間隔： RR

13、C Connection Request (CS) sent by the mobile RRC DownlinkDirectTransfer (CC Alerting) received by the mobile公式為： 固話撥打移動(dòng)(呼叫建立時(shí)延)Call Setup DelayCS Call Setup Delay-AMR (PSTN to Mobile)關(guān)閉鑒權(quán)3s5s打開鑒權(quán)5s7s此延遲定義為以下2條消息之間的時(shí)間間隔： RANAP/Paging sent by the MSC RANAP/CC Alerting received by the MSC公式為： 移動(dòng)撥打移動(dòng)(呼叫

14、建立時(shí)延)Call Setup DelayCS Call Setup Delay-AMR (PSTN to Mobile)關(guān)閉鑒權(quán)4s6s打開鑒權(quán)5s7s此延遲定義為以下2條消息之間的時(shí)間間隔： RRC Connection Request (CS) sent by the mobile RRC DownlinkDirectTransfer (CC Alerting) received by the mobile公式為： 移動(dòng)三期招標(biāo)中興/大唐(AMR呼叫建立時(shí)延比較)AMR呼叫建立時(shí)延 (Mobile to Mobile)項(xiàng)目(中興三期/大唐三期/大唐二期)關(guān)鑒權(quán)4.604/5.115/6.

15、269開鑒權(quán)5.334/5.932/6.788 移動(dòng)三期招標(biāo)中興/大唐(CS 64K Streaming呼叫建立時(shí)延比較)CS 64k 呼叫建立時(shí)延項(xiàng)目(中興三期/大唐三期/大唐二期or大唐二期補(bǔ)測(cè))關(guān)鑒權(quán)4.181/5.187/未測(cè) or 5.603開鑒權(quán)5.046/6.228/6.472 or 6.586 移動(dòng)三期招標(biāo)中興/大唐(語音與H并發(fā)業(yè)務(wù)呼叫建立時(shí)延比較)HSDPA與R4 CS12.2k語音業(yè)務(wù)并發(fā)情況下，R4 CS12.2k語音業(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 移

16、動(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)，在TS 23.107中有明確的定義：AMR speech codec payload： Bit rate: 4,75 - 12,2 kbit/s Delay: end-to-end delay not to exceed 100ms (codec frame length is 20ms) BER: 10-4 for Class 1 bits 10-3 for Class 2 bitsfor som

17、e applications, a higher BER class (10-2) might be feasible. FER 10-3 - limited practical application對(duì)于“抖動(dòng)”，一般都需要通過MOS(儀)測(cè)試，下面是寧波移動(dòng)在5月份進(jìn)行的抖動(dòng)測(cè)試數(shù)據(jù)。另外對(duì)于IUB接口的承載要區(qū)別ATM和IP，理論分析和正常測(cè)試都表明，IP傳輸比ATM傳輸時(shí)延要小。2.2 可能的雜音情況目前已經(jīng)發(fā)現(xiàn)的雜音情況如下： 語音接入正常，音質(zhì)正常(沒有雜音或者間斷)但不是很清晰，通話能維持至結(jié)束； 語音接入正常，音質(zhì)正常(沒有雜音或者間斷)但不是很清晰，越來越差，但通話能維持至結(jié)

18、束； 語音接入正常，音質(zhì)正常(沒有雜音或者間斷)但不是很清晰，越來越差，不能維持(掉話)； 語音接入正常，一直伴隨有輕微雜音，通話能維持至結(jié)束； 語音接入正常，一直伴隨有輕微雜音，越來越差，但通話能維持至結(jié)束； 語音接入正常，一直伴隨有輕微雜音，越來越差，不能維持(掉話)； 語音接入正常，有突發(fā)雜音(若干次)，通話能維持至結(jié)束； 語音接入正常，有突發(fā)雜音(若干次)，不能維持(掉話)； 語音接入正常，聲音小，通話能維持至結(jié)束； 語音接入正常，聲音小，越來越小，但通話能維持至結(jié)束； 語音接入正常，聲音小，越來越小，不能維持(掉話)； 語音接入正常，背景音大(超出正常范圍)，通話能維持至結(jié)束； 語音

19、接入正常，背景音大(超出正常范圍)，不能維持(掉話)； 語音接入正常，音質(zhì)清晰但有間斷； 語音接入正常，音質(zhì)不清晰伴隨有間斷； 語音接入正常，音質(zhì)不清晰伴隨有雜音和間斷； 語音接入正常，切換時(shí)伴隨金屬雜音 語音接入至響鈴，振鈴間隙有雜音3 語音雜音問題CheckList針對(duì)UE、RAN（RNC/NB分開）、CN、IU口、其他，制定CheckList，方便現(xiàn)場快速縮小問題范圍和定位故障。檢查類別檢查項(xiàng)自檢1、UE檢查1.1 更換其它品牌終端是否還存在話音質(zhì)量問題1.2 出現(xiàn)問題終端在其它小區(qū)是否存在語音質(zhì)量問題1.3 是否使用耳機(jī)連線，不使用耳機(jī)連線是否還存在話音質(zhì)量問題。1.4使用固話撥打移動(dòng)

20、電話、移動(dòng)電話撥打固話是否有話音質(zhì)量問題2、RNC檢查2.1 抓取Qos跟蹤log，通過log初步分析是否有上行誤碼情況。備注：Qos跟蹤的每個(gè)統(tǒng)計(jì)周期(28S)的錯(cuò)誤塊數(shù)超過14塊時(shí)，一般會(huì)出現(xiàn)明顯話音質(zhì)量變差現(xiàn)象。2.2 提取對(duì)應(yīng)時(shí)間段性能統(tǒng)計(jì)，看該小區(qū)的上行TS ISCP測(cè)量是否偏高。備注：觀察ISCP平均和最大值，一般大于-90dBm就認(rèn)為有異常。2.3測(cè)試小區(qū)周邊小區(qū)相同時(shí)間段的TS ISCP是否異常。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è)

21、別link ICP幀錯(cuò)誤連續(xù)增加，說明IMA幀失步（ICP幀錯(cuò)）是CASA的IMA芯片產(chǎn)生。2.6 MSC如果是諾西設(shè)備，檢查RNC靜態(tài)參數(shù)中IU信息-IU信息（索引為8），是否含有Iu-RFCI信息3（對(duì)應(yīng)三個(gè)子流為全0的RFCI配置）。如果有，需要?jiǎng)h除。3、NB檢查3.1 LMT-B上是否有CRC檢驗(yàn)出錯(cuò)告警；3.2 LMT-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。查看IUU

22、P幀是否有抖動(dòng)，即IUUP幀號(hào)不連續(xù)，跳變。4.2 Log中是否存在丟幀情況。4.3 Log中是否存在Pay load CRC校驗(yàn)錯(cuò)。4.3 Log中是否有“錯(cuò)誤報(bào)告”的控制幀出現(xiàn)。4 數(shù)據(jù)采集和分析4.1 綜述語音業(yè)務(wù)在接入以及通話過程中會(huì)存在各種各樣的問題，但是問題定位和定位LOG的采集一般方法都很通用；(1) 語音業(yè)務(wù)接入過程中信令失敗的定位方法首先如果語音在接入過程中信令失敗，按照哪個(gè)網(wǎng)元返回失敗那個(gè)網(wǎng)元先定位的原則，如果信令過程是終端、NODEB、CN返回的失敗，一般除帶有明顯的錯(cuò)誤原因外，首先需要其他網(wǎng)元分析失敗的原因和抓取相應(yīng)的LOG進(jìn)行定位。其次如果接入過程是RNC返回失敗導(dǎo)致

23、業(yè)務(wù)接入失敗，那樣一般需要先抓取小區(qū)詳細(xì)級(jí)（帶有RNC內(nèi)子系統(tǒng)的信令交互過程，可以方便定位是哪個(gè)子系統(tǒng)返回德失?。┬帕罡檨矸治?，一般內(nèi)部失敗都會(huì)帶有失敗原因，根據(jù)失敗原因查找錯(cuò)誤碼表，找到對(duì)應(yīng)的錯(cuò)誤；另外需要根據(jù)失敗原因采用對(duì)應(yīng)的SHELL命令查找核對(duì)對(duì)應(yīng)的資源信息，最后是根據(jù)失敗返回的子系統(tǒng)，在LDT上開啟對(duì)應(yīng)得打印消息，抓取打印分析；這樣一般的RNC問題就可以得到定位和解決。(2) 語音業(yè)務(wù)通話過程中問題的定位方法一般語音業(yè)務(wù)保持過程中，會(huì)存在掉話、切換失敗、有雜音等問題，掉話和切換失敗一般同上面的信令失敗的定位方法，有雜音問題是在業(yè)務(wù)保持過程中存在丟棄數(shù)據(jù)包造成的，主要是定位在那個(gè)接口

24、（IU、UU、IUB）或者網(wǎng)元內(nèi)部丟棄了數(shù)據(jù)包造成，目前各個(gè)網(wǎng)元基本都提供了定位的手段。RNC可以通過QOS跟蹤來定位IUB口上行的數(shù)據(jù)是否存在丟包，如果存在丟包，則需要先查傳輸層是否有丟包，然后再根據(jù)業(yè)務(wù)處理的IUUP統(tǒng)計(jì)和業(yè)務(wù)處理計(jì)數(shù)器統(tǒng)計(jì)來定位是否在IUB口和RNC內(nèi)部存在問題；另外RNC提供了語音環(huán)回功能，可以定位接入網(wǎng)內(nèi)是否有問題；NODEB也提供了數(shù)據(jù)環(huán)回功能，可以定位空口到NODEB內(nèi)部是否有問題，另外NODEB也提供了動(dòng)態(tài)查詢物理傳輸是否存在丟包的功能，可以方便定位物理層是否有問題。終端問題一般比較難定位，一般方法就是通過終端物理層抓取軟件（TT）和信令抓取軟件(outum)對(duì)

25、終端物理層何信令進(jìn)行分析，另外也可以通過不同廠家的網(wǎng)絡(luò)來進(jìn)行對(duì)比測(cè)試驗(yàn)證，來定位是否是終端的問題。CN的問題一般接入網(wǎng)人員很難定位，一般需要借助CN側(cè)專用分析工具才可以解析LOG來分析定位，一般如果定位到CN問題，可以找CN支持人員直接定位即可。語音排查流程圖如下：4.2NodeB側(cè)基站側(cè)需要做好的工作： 查詢基站軟件版本、固件版本、一單開站中的時(shí)鐘信息。 查詢小區(qū)的ID、頻點(diǎn)、碼字。 理清“頻點(diǎn)BBURRU”的對(duì)應(yīng)關(guān)系。 查看小區(qū)ISCP的情況。 提取公共日志（初始化日志、告警日志、數(shù)據(jù)一致性文件、動(dòng)態(tài)配置文件）、CCU41/43號(hào)日志、BBU全部日志、ATP消息。4.2.1 ATP抓日志的

26、方法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

27、_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)場實(shí)際情況設(shè)置跟蹤的頻點(diǎn)號(hào)。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

28、）后，搜索“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 傳輸問題導(dǎo)致該現(xiàn)象的排查方法1. 提取出現(xiàn)問題站點(diǎn)的告警日志。查看告警日志，具體操作方法參見4.2.3。檢查是否存在大量“FP下行DCH CRC校驗(yàn)錯(cuò)誤”和“FP收到TFI錯(cuò)誤”告警。說明：少量馬賽克，上述告警次數(shù)的量級(jí)在個(gè)位數(shù)的級(jí)別；明顯馬賽克，上述告警

29、次數(shù)量級(jí)在100以上；大量馬賽克，上述告警次數(shù)量級(jí)在1000次以上。2. 用-B連接問題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í)是否一定伴隨大量NB FP 的下行DCH CRC校驗(yàn)告警（注意要等待一個(gè)告警過濾周期的時(shí)間）。4. 可以在RNC上用命令行

30、查詢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)該問題。如果同時(shí)存在(1)(2)(3)中所描述現(xiàn)象，則重點(diǎn)懷疑是目前RNC側(cè)IMA傳輸（驅(qū)動(dòng)）發(fā)送的問題。4.2.3 NODEB側(cè)告警抓取和分析方法使用LMT-B工具。1） NODEB告警抓取方法如下圖：說明：登陸LMT-B后，選擇文件，然后上傳需要的各種日志2） 告警打開分析方法如下圖：3） NODEB常見告警分析一般通過NODEB告警可以看出物理傳輸層的問題和NDOEB本地小區(qū)以及載波是否存在問題，如果NODEB本地小區(qū)或者載波有問題，在告

31、警中也可以看到相應(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 芯片號(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),

32、鏈路號(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傳輸問題），則

33、說明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)問題時(shí)是否進(jìn)行過頻繁的刪除、添加操作還是因?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)問題時(shí)是否進(jìn)行過頻繁的刪除、添加操作還是因?yàn)镮MA閃斷引起的IMA工作異常drv_ima_ldt_imalink_event 芯片號(hào), 鏈路號(hào)drv_ima_l

34、dt_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è)務(wù)，28S內(nèi)的上下行TB塊數(shù)應(yīng)該保持一致，一般語音業(yè)務(wù)正常的TB塊數(shù)為4200個(gè)（28s/20ms*3（語音業(yè)務(wù)塊數(shù)），如果上行有誤塊，說明傳輸或者NODEB到RNC的處理數(shù)據(jù)有問題。如UE是否只在

35、在切換過程中存在誤碼，首先在位置不變得情況下保持通話，看QOS跟蹤是否恒定在4200塊，沒有誤碼，此時(shí)移動(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)回語音的用戶所在RTPA和DSP號(hào)，具體方法如下：在RAB指派后RNC本地資源分析消息中，查看倒數(shù)第二個(gè)響應(yīng)消息，根據(jù)RDBS_RDBS_LC_ALLOCATE_RSP_MSG中的DS

36、PAddr后三位確定用戶接入在1-2-13 RTPA業(yè)務(wù)板,根據(jù)DSPIP的最后一個(gè)字節(jié)確認(rèn)在9號(hào)CPU（DSP）。2） 在1-2-13 9CPU的模擬shell上敲：rnc_tpss_iuup_shell3） 分析方法：一般查看語音從正常到有雜音前后IUUP統(tǒng)計(jì)那些錯(cuò)誤統(tǒng)計(jì)項(xiàng)有變化。當(dāng)語音正常沒有誤碼時(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 語音環(huán)回使用方法介紹1） 從LDT信令跟蹤上確認(rèn)需要環(huán)回語音的用戶所在RTPA和DSP號(hào)，具體方法如下：在RAB指派后RNC本地資源分析消息中，查看倒數(shù)第二個(gè)響應(yīng)消息，根據(jù)RDBS

37、_RDBS_LC_ALLOCATE_RSP_MSG中的DSPAddr后三位確定用戶接入在1-2-13 RTPA業(yè)務(wù)板,根據(jù)DSPIP的最后一個(gè)字節(jié)確認(rèn)在9號(hào)CPU（DSP）。2） 在1-2-13 9CPU的模擬shell上敲：rnc_tpss_iuup_sm_loop_para_set 1,UEID這樣可以打開此用戶的語音環(huán)回功能，其他用戶不受影響。rnc_tpss_iuup_sm_loop_para_set 0,UEID則關(guān)閉此用戶的語音環(huán)回功能。4.3.5 VP環(huán)回使用方法介紹（FP層）1）首先根據(jù)信令跟蹤分別找到主被叫用戶所在DSP：在RAB指派后RNC本地資源分析消息中，查看倒數(shù)第二個(gè)

38、響應(yīng)消息，根據(jù)RDBS_RDBS_LC_ALLOCATE_RSP_MSG中的DSPAddr后三位確定用戶接入在1-2-13 RTPA業(yè)務(wù)板,根據(jù)DSPIP的最后一個(gè)字節(jié)確認(rèn)在9號(hào)CPU（DSP）。2） 在RNC FP層進(jìn)行環(huán)回：打開環(huán)回：在用戶所在DSP的模擬shell窗口中敲：rnc_tpss_fp_vp_loop UeID, 0, 16777216, 0 （UEID根據(jù)信令跟蹤中確定）關(guān)閉環(huán)回：在用戶所在DSP的模擬shell窗口中敲：rnc_tpss_fp_vp_loop UeID, 0, 0, 04.3.6 VP環(huán)回使用方法介紹（IUUP層）1） 首先根據(jù)信令跟蹤分別找到主被叫用戶所在

39、DSP在RAB指派后RNC本地資源分析消息中，查看倒數(shù)第二個(gè)響應(yīng)消息，根據(jù)RDBS_RDBS_LC_ALLOCATE_RSP_MSG中的DSPAddr后三位確定用戶接入在1-2-13 RTPA業(yè)務(wù)板,根據(jù)DSPIP的最后一個(gè)字節(jié)確認(rèn)在9號(hào)CPU（DSP）。2）在RNC IUUP層進(jìn)行環(huán)回：打開環(huán)回：在用戶所在DSP的模擬shell窗口中敲：rnc_tpss_iuup_vp_loop UeID, 0, 16777216, 0 （UEID根據(jù)信令跟蹤中確定）關(guān)閉環(huán)回：在用戶所在DSP的模擬shell窗口中敲：rnc_tpss_iuup_vp_loop UeID, 0, 0, 04.4 UE側(cè)目前U

40、E側(cè)數(shù)據(jù)采集一般可以使用兩種軟件：1. SPAN Outum 5.02. miniPTAS4.4.1 SPAN Outum軟件抓取終端信令信息Outum軟件（SPAN Outum 5.0）可以抓取終端的各項(xiàng)測(cè)量信息和層三信令抓取各項(xiàng)測(cè)量信息的方法。第一步：在 outum軟件的選擇“Line chart”-在彈出的“Line chart”窗口-點(diǎn)擊右鍵選擇“屬性”-在彈出的“設(shè)置Chart屬性”窗口-點(diǎn)擊“修改”如下圖：第二步：在彈出的窗口中，在左側(cè)選中需要添加的測(cè)量IE，單擊“添加”-將選擇的IE添加到左側(cè)菜單中。在例子中添加一些測(cè)量值，具體測(cè)量值可以根據(jù)需要進(jìn)行添加。第三步：單擊“確定”鍵后

41、，完成添加，可以在“Line chart”窗口看到測(cè)量結(jié)果，完成測(cè)試后保存LOG，可以保存測(cè)試結(jié)果，供大家分析。抓取層三信令的方法：第一步：在 outum軟件的選擇“UU口消息”在彈出的窗口可以看到UU口的消息，雙擊每條信令可以看到每條信息的詳細(xì)IE，在“UU口消息”界面右鍵彈出列表后，點(diǎn)擊“Export Results”可以將UU口消息名、時(shí)間戳等保存出來。右鍵點(diǎn)擊“UU口消息解碼”可以將信令保存下來，共后臺(tái)分析。4.4.2 miniPTAS軟件聯(lián)芯log目前聯(lián)芯提供的miniPTAS版本，可以抓取各層LOG，但只提供了LOG抓取功能，不能對(duì)LOG在軟件上進(jìn)行分析，只能發(fā)回聯(lián)芯進(jìn)行分析。第一

42、步：單擊“文件”-“新建”-“測(cè)試工程”-選擇保存位置后，進(jìn)行保存。第二步：單擊“文件”-“新建”-“測(cè)試連接”-在彈出的界面上，查看是否是終端的鏈接-確認(rèn)后，完成測(cè)試連接的建立。第三步：點(diǎn)擊“連接”-在彈出菜單中-選擇“連接”-在輸出結(jié)果框中看到“已經(jīng)連上”代表連接建立成功。第四步：點(diǎn)擊“連接”-選擇“無線參數(shù)”-在彈出的窗口選擇需要抓取的LOG。第五步：使用終端發(fā)起業(yè)務(wù)，如果看到LOG數(shù)有變化，說明已經(jīng)抓取了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ù)采集需

43、要由CN研發(fā)人員來做。這里不作介紹。5 語音雜音問題不同原因分析5.1 語音保持過程中存在一直有雜音的情況1） 當(dāng)語音業(yè)務(wù)保持過程中一直存在雜音時(shí)，首先需要檢查傳輸是否正常，按照4.2.2節(jié)描述的排查IUB傳輸是否有問題2） 如果傳輸正常，雜音還存在，需要根據(jù)4.1節(jié)描述的問題定位流程進(jìn)行排查5.2 語音保持過程中突然出現(xiàn)單通或者雙方都聽不到聲音1） 首先根據(jù)4.3.2節(jié)描述獲取QOS跟蹤，確認(rèn)是否誤碼較大2） 提取ISCP15分鐘統(tǒng)計(jì)值，檢查ISCP是否有突變的情況3） 檢查NODEB告警是否有DSP故障告警4） 如果NDOEB存在DSP告警，一般是NODEB的BBU板卡出現(xiàn)問題，可以嘗試替

44、換BBU進(jìn)行測(cè)試，確認(rèn)問題返修有問題的BBU5） 如果問題還不能解決需要按照4.1節(jié)流程進(jìn)行排查5.3 語音保持雙方靜默時(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） 如果問題還不能解決需要按照4.1節(jié)流程進(jìn)行排查6 案例6.1 語音業(yè)務(wù)在切換過程中存在短暫的金屬雜音問題描述：語音業(yè)務(wù)在接力切換過程中存在短暫的金屬雜音問題分析：1） 傳輸排查：登陸LMT-B查看基

45、站IMA鏈路是否有“接收非法ICP信元錯(cuò)誤”和“幀失步”，STUFF信元發(fā)送統(tǒng)計(jì)是否在增加，判斷傳輸層是否有信元丟棄；經(jīng)定位沒有發(fā)現(xià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)上有問題。3） 查看小區(qū)切換方式，配置為接力切換，此時(shí)跟蹤到的QoS切換誤碼范圍為1026塊，修改小區(qū)切換方式為硬切換，QoS跟蹤發(fā)現(xiàn)切換時(shí)誤碼明顯減少，范圍為09，切換過程中雜音現(xiàn)象改善較大；經(jīng)RNC研發(fā)確認(rèn)RNC在接力切換目前的實(shí)現(xiàn)上存在問題，需要優(yōu)化處理。4） 查看基站測(cè)告警進(jìn)行分析，發(fā)現(xiàn)有DCH出窗告警，經(jīng)

46、基站研發(fā)分析告警LOG，認(rèn)為基站對(duì)于上行丟幀的處理方式和上行譯碼錯(cuò)誤情況的處理方式需要改善；5） 檢查無線環(huán)境，是否服務(wù)小區(qū)和臨區(qū)RSCP值相當(dāng)，這樣需要優(yōu)化無線環(huán)境解決方法：1） RNC側(cè)處理：判斷對(duì)于語音業(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è)處理方式 對(duì)于上行丟幀的處理方式（此情況對(duì)應(yīng)于終端應(yīng)正常發(fā)送上行數(shù)據(jù)，但基站未能檢測(cè)到的情況）：a.PL層未通

47、過激活檢測(cè)門限判斷，即SJ上報(bào)CC的數(shù)據(jù)指示未通過激活檢測(cè)；b.PL層通過激活檢測(cè)，但CC對(duì)TFCI譯碼后，判斷TFCI值超出建鏈參數(shù)的最大范圍；對(duì)于以上兩種情況，CC上報(bào)FP丟幀（CRCI填寫為0 xff），F(xiàn)P上報(bào)RNC的數(shù)據(jù)幀中的CRCI指示為1，但QE值固定填寫為218（對(duì)應(yīng)0-255的協(xié)議值范圍）。 對(duì)于上行譯碼錯(cuò)誤情況的處理方式：PL層通過激活檢測(cè)，且CC對(duì)TFCI譯碼在合理的范圍內(nèi)，但對(duì)傳輸信道的TB塊譯碼后CRC校驗(yàn)錯(cuò)；對(duì)于這種情況，CC上報(bào)FP的CRCI為0 x80，誤比特率BER值按照實(shí)際計(jì)算值上報(bào)，F(xiàn)P將BER值填寫在QE位置供RNC使用。6.2 貴州省移動(dòng)大樓語音質(zhì)量問

48、題問題描述:移動(dòng)李總反映在新華苑（貴州移動(dòng)辦公大樓）14樓語音模糊不清晰。移動(dòng)投訴語音質(zhì)量模糊不清楚的問題，復(fù)現(xiàn)情況描述如下：1） T網(wǎng)-G網(wǎng)，通話10分鐘左右，突然上行出現(xiàn)單通，下行正常；2） T網(wǎng)-G網(wǎng)，通話兩到三分鐘，出現(xiàn)雙方都聽不到對(duì)方講話。問題分析:測(cè)試人員在新華苑14樓進(jìn)行了問題復(fù)現(xiàn)，我們發(fā)現(xiàn)語音質(zhì)量模糊不清晰時(shí)占用的是茅臺(tái)金波TD-1小區(qū)信號(hào)，通過RNC側(cè)QoS信令跟蹤發(fā)現(xiàn)上行誤塊率高，基站側(cè)發(fā)現(xiàn)時(shí)隙干擾ISCP異常，上站提取告警發(fā)現(xiàn)同時(shí)有DSP任務(wù)運(yùn)行故障告警，因此懷疑基站BBU板卡處理問題。解決方法:將茅臺(tái)金波站的BBU板更換到紅邊門站測(cè)試時(shí)多次復(fù)現(xiàn)了語音質(zhì)量問題，在茅臺(tái)金波

49、站更換其他BBU板，大量測(cè)試下來語音質(zhì)量良好，但偶爾仍有毛刺，經(jīng)分析發(fā)現(xiàn)，新華苑為單HSDPA 配置，旁邊的新華社為雙HSDPA配置，HSDPA干擾了R4，將新華社改為單HSDPA配置后，再次經(jīng)過大量測(cè)試，沒有發(fā)現(xiàn)語音質(zhì)量問題，語音模糊不清晰的原因就是基站BBU板卡和HSDPA干擾了R4業(yè)務(wù)。其它:將茅臺(tái)金波站出現(xiàn)問題的BBU板已經(jīng)反饋給北京研發(fā)分析定位。6.3 上行語音質(zhì)量差問題描述:使用TD手機(jī)通話過程中出現(xiàn)語音不清晰現(xiàn)象問題分析:現(xiàn)場定位：第一：正常撥打語音電話，主被叫同時(shí)監(jiān)聽語音質(zhì)量；存在語音不清晰現(xiàn)象，但出現(xiàn)概率很低，兩天測(cè)試才抓到4次這樣的現(xiàn)象。第二：撥打語音電話，然后觸發(fā)小區(qū)間切

50、換、NB間切換；容易出現(xiàn)語音不清晰現(xiàn)象，比例大概在30%到40%。第三：撥打測(cè)試，主被叫同時(shí)監(jiān)聽語音質(zhì)量。中間涉及到的變動(dòng)包括更換基站版本、更換RRU、更換BBU槽位、更換基站（整站）、跳過室分系統(tǒng)、關(guān)閉外環(huán)功率控制。結(jié)果顯示都存在話音不清晰問題。現(xiàn)場定位總結(jié)：1、接入后就會(huì)出現(xiàn)不清晰的現(xiàn)象，但沒有切換觸發(fā)的語音不清晰的概率高。2、語音不清晰的時(shí)候，從空口上看RSCP、C/I、UE發(fā)射功率均正常。3、室內(nèi)分布3個(gè)基站（包含移動(dòng)大樓）有語音不清晰問題，室外基站測(cè)試了2個(gè)小時(shí)沒有出現(xiàn)語音不清晰的現(xiàn)象。4、從NB和RNC聯(lián)合分析的結(jié)論：Iub口傳輸沒有問題。研發(fā)定位：單機(jī)測(cè)試環(huán)境下，模擬組織上行語音

51、幀處理。由于考慮到該問題主要頻繁出現(xiàn)在觸發(fā)切換后（切換時(shí)容易出現(xiàn)時(shí)間抖動(dòng)），因此模擬抖動(dòng)情況進(jìn)行測(cè)試。模擬組織上行語音幀，測(cè)試發(fā)現(xiàn)發(fā)送到CN的語音幀幀號(hào)錯(cuò)誤，第一幀語音數(shù)據(jù)的幀號(hào)不為0，且后續(xù)的幀號(hào)不連續(xù)，這樣就會(huì)導(dǎo)致CN在接收到語音幀并進(jìn)行幀號(hào)檢查時(shí)發(fā)現(xiàn)幀號(hào)錯(cuò)誤，做出幀號(hào)異常情況處理，進(jìn)而造成語音不清晰。代碼走查發(fā)現(xiàn)，在目前的處理機(jī)制中，主調(diào)函數(shù)中每隔一個(gè)20ms調(diào)用一次上行數(shù)據(jù)處理函數(shù)。用戶實(shí)體建立成功后，上行數(shù)據(jù)處理函數(shù)第一次被調(diào)用時(shí)沒有判斷是否是真正的數(shù)據(jù)，就當(dāng)作是第一幀數(shù)據(jù)賦予初始幀號(hào)，這樣的話，當(dāng)?shù)谝粠嬲臄?shù)據(jù)到來時(shí)幀號(hào)已經(jīng)不是初始值。而且在第一幀數(shù)據(jù)到來時(shí)，沒有存儲(chǔ)當(dāng)前的rfn

52、值，這樣導(dǎo)致計(jì)算后續(xù)幀號(hào)時(shí)前一個(gè)rfn和當(dāng)前rfn的差值diffrfn過大，由此計(jì)算出來的幀號(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ì)算出來的幀號(hào)就是連續(xù)值。其他:該案例發(fā)生于2009年6月13日保定移動(dòng)大樓。6.4 No DATA數(shù)據(jù)情況下出現(xiàn)噪音 問題描述： 手機(jī)互打，雙方靜默時(shí)，主被叫均可以聽到明顯有節(jié)奏的噪音。若雙方進(jìn)行通話后，噪音會(huì)逐漸減輕。CN測(cè)發(fā)送NO_DATA數(shù)據(jù)（即3個(gè)子流全部為0）的情況下，在終端會(huì)有雜音。

53、 定位過程： 判斷CN是哪家的設(shè)備，因?yàn)橛行S家支持RFCI為NO_DATA（3個(gè)子流全0）的情況。如果CN不發(fā)NO_DATA數(shù)據(jù)，語音清晰。 阿爾卡特的CN支持全0的情況，而RNC在IUUP初始化消息里面攜帶了RFCI為全0的情況，所以CN認(rèn)為RNC支持RFCI為NO_DATA，會(huì)下發(fā)全0的數(shù)據(jù)。此時(shí)雙方靜默時(shí)，主被叫均可以聽到明顯有節(jié)奏的噪音，判斷可能是RNC對(duì)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ù)處理有誤；

54、模擬有抖動(dòng)的情況下交替發(fā)送數(shù)據(jù)幀和靜默幀，則數(shù)據(jù)不能正常發(fā)送。這是由于語音處理有2個(gè)緩存交替存儲(chǔ)數(shù)據(jù)。正常情況下，只有一個(gè)緩存有數(shù)據(jù)，IU口每20ms來一包數(shù)據(jù)存下來。每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ù)（語音數(shù)據(jù)和靜默數(shù)據(jù)），由于當(dāng)前緩存處理完畢之后IUUP通知MAC剩余數(shù)據(jù)量（下一個(gè)緩存的數(shù)據(jù)長度）有誤，導(dǎo)致MAC TFC選擇有誤，當(dāng)前緩存下的數(shù)據(jù)不能發(fā)送，導(dǎo)致語音質(zhì)量差。 解決方法： 在當(dāng)時(shí)RNC沒有升級(jí)的情況下，如果CN支持R

55、FCI為NO_DATA，則需要將RNC側(cè)rIuRfci表里面的RFCI對(duì)應(yīng)子流為0的字段刪掉；RNC升級(jí)版本后不會(huì)出現(xiàn)該問題。其他：該案例發(fā)生于2009年7月1日長春。7 總結(jié)本文針對(duì)語音業(yè)務(wù)網(wǎng)絡(luò)優(yōu)化中出現(xiàn)的語音不清晰甚至掉話、語音聲音小、突發(fā)噪音等問題，描述了如何一步步排查這些問題的方法、以及需要采集的數(shù)據(jù)和抓取的log，并如何進(jìn)行數(shù)據(jù)分析，最終問題解決。本文還給出了一些案例分析，通過這些案例積累對(duì)于我們解決類似問題也給出了很好的借鑒。另外也介紹了相關(guān)技術(shù)原理和背景知識(shí)。根據(jù)后續(xù)更多案例分析以及問題定位方法等積累，可以再進(jìn)一步完善本文檔。8 附錄介紹相關(guān)背景知識(shí)、以及一些原理性知識(shí)。8.1

56、端到端QoS技術(shù)原理在描述E2E的QoS之前，我們先了解一下語音的呼叫流程。在TD-SCDMA系統(tǒng)中，一個(gè)呼叫的建立，首先是通過終端與網(wǎng)絡(luò)側(cè)的信令交互，也就是控制面的過程，完成用戶面連接的建立。在一般的UMTS系統(tǒng)，一個(gè)標(biāo)準(zhǔn)的移動(dòng)到移動(dòng)的語音呼叫，原始信號(hào)(語音數(shù)據(jù))首先在發(fā)起側(cè)UE中編碼，經(jīng)過無線接口的傳送，在本地代碼轉(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)行兩次代碼

57、轉(zhuǎn)換，通常稱為級(jí)聯(lián)配置。在講述語音的呼叫流程前，我們先要了解幾個(gè)關(guān)鍵概念：編解碼器、TFO、TrFO、AMR聲碼器、RFCI。其中TFO/TrFO的出現(xiàn)是因?yàn)榫幗獯a器的級(jí)聯(lián)引入的兩次代碼轉(zhuǎn)換降低了語音質(zhì)量，當(dāng)語音編解碼器低速率工作時(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語音編碼轉(zhuǎn)化為64kbps PCM編碼，而是直接將AMR語音編碼在網(wǎng)絡(luò)中傳輸，從而大大地提高了語音QoS。 CODEC(COder a

58、nd DECoder)編解碼器)用來對(duì)信息的原始表達(dá)方式進(jìn)行采樣，量化和編碼使其成為某種形式的碼流以及能將該碼流進(jìn)行解碼使其還原成為原始表達(dá)方式的一種設(shè)備。在3G網(wǎng)絡(luò)中，用于下行方向的編解碼器位于MSC；而用于上行的位于UE手機(jī)終端中。位于MSC和UE中的CODEC需要接收RNC的信令，以便根據(jù)RNC的要求來動(dòng)態(tài)地調(diào)節(jié)和使用編碼速率。(上行是通過空中接口的控制面協(xié)議進(jìn)行控制，對(duì)于下行，RNC通過Iu接口的用戶面協(xié)議進(jìn)行控制)。需要指出的是位于MSC中的編解碼器也稱為TranSCoder它用于將一種編碼方式的信息轉(zhuǎn)化成另一種不同的編碼方式。通常是將AMR編碼的壓縮語音轉(zhuǎn)換成PCM語音碼流，或是反

59、之。注意：通常網(wǎng)絡(luò)都具有ITU G.711 A-律的編解碼器可將信息轉(zhuǎn)換成為64Kb/s PCM語音碼流。 TFO(Tandem Free Operation)在GSM網(wǎng)絡(luò)發(fā)展的后期，出現(xiàn)了TFO機(jī)制，它是一種呼叫配置，在信號(hào)鏈路上物理地存在代碼轉(zhuǎn)換設(shè)備，但代碼轉(zhuǎn)換功能被繞過。這種做法被第三代移動(dòng)通信系統(tǒng)UMTS網(wǎng)絡(luò)繼承，但具體實(shí)現(xiàn)時(shí)又有差異，在兩端的呼叫建立階段完成之后，媒體網(wǎng)關(guān)中的代碼轉(zhuǎn)換機(jī)設(shè)備交換根據(jù)ITU-T G。711 A律或律編碼的傳統(tǒng)64 kb/s PCM語音抽樣。代碼轉(zhuǎn)換機(jī)通過竊取(stealing)每第16個(gè)抽樣中的一個(gè)最不重要的比特位，交換TFO消息，進(jìn)行兩端UE中編解碼器

60、的協(xié)商。如果兩端的UE中應(yīng)用了兼容的語音編解碼類型，代碼轉(zhuǎn)換機(jī)自動(dòng)激活TFO，傳輸壓縮語音的信道被映射在64 kb/s的PCM編碼的最不重要的比特位上。如果應(yīng)用了不兼容的語音編解碼類型，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é)議并且配置一致的編解碼類型。這樣能夠讓壓縮語音包在不進(jìn)行編解碼轉(zhuǎn)換的