WCDMA語音異常問題深度分析

徐惠明

摘 要：WCDMA網絡中，語音通信的質量也是衡量網絡優(yōu)劣的重要標準。文章對語音通信中出現(xiàn)的較為異常且極大影響用戶感受的網絡質量問題進行了深度分析，包括通話過程中出現(xiàn)的流水聲、雜音、單通及忙音等現(xiàn)象。文章主要針對其存在的一些問題進行簡要的分析與總結。

關鍵詞：WCDMA語音；存在問題；研究

1 語音傳遞相關過程

在WCDMA系統(tǒng)中，語音業(yè)務使用三個數(shù)據子流進行傳遞，RNC會針對這三個子流分配三個傳輸信道，分別對其進行加、解密，每個子流中的比特數(shù)對應為DCH傳輸塊大小，TTI為20ms，AMR語音子流的結構如表1。

表1

對于語音業(yè)務，在不通話期間為了防止給人以通話中斷的感覺，采取的措施是發(fā)送描述背景噪音的靜默幀（SID），在接收端根據靜默幀恢復出背景噪音。處理規(guī)則是：當檢測到語音靜默開始，后面連續(xù)7個20ms照舊發(fā)送語音幀，第8個20ms發(fā)送一個39比特幀，然后第9、10連續(xù)兩個20ms不發(fā)送數(shù)據，第11個20ms開始發(fā)送一個39比特靜默幀，然后連續(xù)7個20ms不發(fā)送幀，然后再發(fā)送一個39比特幀，以后都是每8個20ms中有一個39比特幀，直到在某個20ms中檢測到語音，立即停止DTX狀態(tài)，開始發(fā)送語音幀?？梢酝ㄟ^下面的圖參考一下，每個格子代表20ms中發(fā)送的一個幀，在最前面檢測到語音靜默。如表2所示。

表2

注：S為正常語音幀；F為第一個靜默幀39bits；N為空幀0bit；U為更新的靜默幀39bits。

另外語音在傳遞過程中會在空口進行加密，加密過程會涉及加密算法中一些相關參數(shù)，這些參數(shù)的變化有時也會引起語音質量的問題。WCDMA的空口加密算法如圖1。

與完整性保護算法類似，CK由核心網在Security Mode Command消息中給出，并在終端和核心網中同時保存；COUNT-C由HFN和RRC消息的序號SN構成，而HFN從業(yè)務建立過程中RRC連接最后一條消息RRC CONNECTION SETUP COMPLETE消息中得到；DIRECTION為了避免上下行加密算法的輸入內容出現(xiàn)相同，上行設置為0，下行設置為1；LENGTH用于指示生成的Keystream的長度；BEARER是每個無線承載的標識，用于區(qū)別所有無線承載使用同一組加密參數(shù)；最終根據f8算法計算出一個結果，這個結果會應用于需要加密的數(shù)據從而完成加密過程。

其中COUNT-C的結構可以分為確認模式、透明模式和非確認模式三種情況，如圖2所示。

圖2

對于語音業(yè)務而言，其RLC層采用的是透明傳輸模式，COUNT-C共32位，低8位的CFN在UE和RNC的MAC-d中維護，高24位為HFN，會隨著CFN的周期而增長。

2 語音異常問題

2.1 由于加密不一致導致的流水聲問題

3GPP R99/R4、R5 200403之前協(xié)議對于TS25.331 8.6.4.3/8.6.6.28的描述本身存在缺陷：8.6.4.3描述HFN使用RB SETUP COMPLETE消息中CS域的START值初始化后直接使用；但是8.6.6.28描述HFN在使用RB SETUP COMPLETE消息中CS域的START值初始化后還需要加1后才使用。

If the IE "Downlink DPCH info common for all radio links " is included in a message used to perform a Timing re-initialised hard handover， and ciphering is active for any radio bearer using RLC-TM， the UE shall， after having activated the dedicated physical channels indicated by that IE： increment HFN for RLC-TM by '1'。

而對于RB DRD過程，R5版本前后分別屬于RB配置過程和硬切換過程，在R5版本前，在協(xié)議中，沒有明確這個過程是屬于RB階段還是硬切換過程，可是對于加密參HFN來說，在RB階段解密參數(shù)HFN不需要加1，而在硬切換過程中加密參數(shù)HFN需要加1，由于各個終端對協(xié)議理解上的不同，這里會出現(xiàn)終端和網絡側HFN不一致。有些廠商認為RB DRD階段是一個硬切換階段，所以HFN加1了，如果某些終端認為RB DRD過程是一個RB階段HFN不加1，導致終端和網絡側維護的HFN不一致，出現(xiàn)流水聲。由于各款終端和網絡側的實現(xiàn)不匹配、加密參數(shù)配置不一致導致的語音流水聲屬于協(xié)議本身的沖突，之后3GPP通過CR2284R1澄清，修改8.6.4.3描述，保持與8.6.6.28的處理一致，也就是說HFN加1后使用，來消除語音中流水聲的問題。

如下例中所示，R5版本之前的終端在RB建立過程中沒有對HFN進行加1，圖3。

圖4

2.2 由于傳輸時延導致的流水聲

語音業(yè)務通話過程中，由于IUB接口傳輸時延突發(fā)變大，造成大量下行數(shù)據幀延遲到達，并且落在NodeB的時間窗外，NodeB檢測到之后給RNC發(fā)送大量負的時間調整幀，使得RNC頻繁對所維護的下行CFN（Connection Frame Number）作調整，當下行CFN超過上行數(shù)據幀中使用的CFN一圈后，由于解密出現(xiàn)錯誤而導致語音流水聲問題。

所以對于同步系統(tǒng)而言，UE在物理信道重配置完成消息里攜帶的激活時間至少比UE發(fā)送時刻的CFN大200，并且是8的倍數(shù)。這主要是為了考慮到IUB口傳輸有較大的時延，有些終端可能沒有考慮到導致在IUB口有較大傳輸時延的情況下出現(xiàn)加密參數(shù)HFN網絡側和UE側維護的不一致，引入流水聲。

2.3 與終端兼容性問題導致單通和靜音

在擁塞小區(qū)用戶撥打非擁塞小區(qū)用戶過程中，如果小區(qū)打開AMRC功能，在擁塞的時候用戶接入會進行降速，以保證速率4.75kbps進行接入，這樣就會觸發(fā)高通某些老款終端的bug，高通會把速率低于10.2kbps時的語音數(shù)據從3個傳輸信道重配置至2個信道，但網絡側分配一直都是3個子流3個傳輸信道，這樣就會導致UE側MAC層接收數(shù)據包后出現(xiàn)異常，最終編解碼后表現(xiàn)為單通。

另外一種情況是高通某些版本終端在滿足AMRC條件時會發(fā)起上行速率調整，當RNC通過UU口發(fā)送TFC控制消息給UE要求其調整到目標速率時，RR/MAC層在向上層遞交消息的過程存在問題，導致UE在應用層按照12.2kbps的速率進行編解碼，但到了MAC層后卻會將12.2kbps的速率幀全部丟掉，最終出現(xiàn)靜音。

2.4 擾碼沖突導致流水聲

由于Node B鏈路的CFN是根據RNC下發(fā)參數(shù)frameoffset、chipoffset等計算出來的，NodeB在進行FP組包時獲取自己所維護的CFN值填入FP包中，RNC在進行多條鏈路的FP包合并時會根據該CFN進行合并。如果兩個更軟合并鏈路的幀偏移相差太大，會導致兩條鏈路CFN計算不一致，從而導致FP包中攜帶的CFN參數(shù)突變。

NodeB側CFN突變會引起以下兩個問題：RNC側的上行MDC合并根據CFN進行，異常的CFN導致合并失敗，從而引起丟包，由于是部分丟包，所以UE側的效果可能是噪音；RNC側的加解密參數(shù)HFN會根據CFN進行相應的變化（每個CFN周期255結束HFN遞增），異常的CFN導致異常的HFN，HFN錯誤就引起加解密錯誤，從而引起流水聲，而在正常情況下，兩條更軟合并鏈路的frameoffset應該是相等或只相差一的，由于frameoffset以及chipoffset是UE根據RNC所配鄰區(qū)的基準定時進行測量上報的，而擾碼則是UE區(qū)分小區(qū)的依據。如果出現(xiàn)擾碼沖突，UE測量時采用另一個相同擾碼小區(qū)的基準定時，不同基站之間的定時相差較大，這就會使UE上報與原鏈路相差較大的frameoffset以及chipoffset值，導致NodeB側CFN突變，進而引起流水聲。

2.5 其他原因導致的單通問題

掉話產生的假單通問題：通話過程中因為質量差，發(fā)生了一側掉話的情況，另一側需要等到手機一定時器超時才能釋放電路，此時該側用戶聽不到任何聲音，感覺象單通，實際為掉話；如果用戶不主動拆鏈，最終會產生掉話，大部分發(fā)生掉話的另一側用戶可能主動掛機。

手機電量低導致的單通情況：該影響產生的單通為電量低手機的通話對方；另外還可能導致掉話，一般電量低的客戶堅持一段時間后會主動關機。

Iu接口中繼鏈路問題：Iu 接口中繼鏈路如果存在問題（如：鴛鴦線問題）可以導致一個通話的來去兩路話音中，有一路可以送達對端，而另一路不能正確的送達對端，引起單通。通話過程中，呼叫切換時如果被分配到有問題的Iu接口中繼的時隙上，將導致該呼叫在通話中突然發(fā)生單通。這樣整個基站控制器管轄區(qū)域下將出現(xiàn)一定比率的單通。

上下行干擾問題：如果一個小區(qū)上行或下行受到嚴重干擾，那么呼叫切入時，就可能導致質量好的一個方向聽得到聲音，而質量差的另一個方向聽不到聲音，形成單通。當然，也有可能是在沒有任何切換的情況下，手機逐漸遠離基站或進入室內，接收電平變差，一個方向的接收質量先于另一個方向惡化，形成通話中的單通。

分布系統(tǒng)的干放引起的單通問題：分布系統(tǒng)的干放對分布系統(tǒng)覆蓋區(qū)域中所有的上行和下行信號進行放大，再傳送到基站。如果干放中的上行或下行放大器存在問題，或放大參數(shù)存在問題，將導致一個方向的信號被正常放大，而另一個方向的信號不能被相應正常的放大。呼叫切入時，將導致單通現(xiàn)象。

手機元器件問題：有些手機使用年限長了，一些電子元器件老化，可能導致通話時揚聲器不發(fā)聲或麥克風不傳聲的問題。這種問題如果在通話過程中發(fā)生，將導致通話中的單通現(xiàn)象。

其它的手機問題：現(xiàn)在網絡中手機的種類越來越多，由手機引發(fā)的問題也越來越多。部分手機的問題十分隱蔽，而且往往和特定的網絡功能有關，不容易查找。

用戶誤操作問題：有些高端手機，在通話時手機屏幕上有靜音按鈕（部分手機為觸摸屏手機），用戶在通話時容易不經意的碰到該鍵，引起單通。

3 結束語

本文旨在討論和匯總3G網絡相關語音類問題，其中涉及到流水聲、雜音、單通等現(xiàn)象，網絡中的這些現(xiàn)象在很多情況下會極大的影響用戶的使用感受，對品牌的提升和業(yè)務的正常使用產生較大的負面效果。文中所匯總的只是在現(xiàn)有經驗基礎上得出的相關結論，由于異常語音類問題涉及端到端的整個過程，定位和分析都極其復雜，因此不能排除本文之外的其他場景導致的異常情況的出現(xiàn)。在網絡發(fā)展過程中出現(xiàn)類似問題，本文可以為分析和解決問題提供一種思路。