徐惠明
摘 要:WCDMA網(wǎng)絡中,語音通信的質量也是衡量網(wǎng)絡優(yōu)劣的重要標準。文章對語音通信中出現(xiàn)的較為異常且極大影響用戶感受的網(wǎng)絡質量問題進行了深度分析,包括通話過程中出現(xiàn)的流水聲、雜音、單通及忙音等現(xiàn)象。文章主要針對其存在的一些問題進行簡要的分析與總結。
關鍵詞:WCDMA語音;存在問題;研究
1 語音傳遞相關過程
在WCDMA系統(tǒng)中,語音業(yè)務使用三個數(shù)據(jù)子流進行傳遞,RNC會針對這三個子流分配三個傳輸信道,分別對其進行加、解密,每個子流中的比特數(shù)對應為DCH傳輸塊大小,TTI為20ms,AMR語音子流的結構如表1。
表1
對于語音業(yè)務,在不通話期間為了防止給人以通話中斷的感覺,采取的措施是發(fā)送描述背景噪音的靜默幀(SID),在接收端根據(jù)靜默幀恢復出背景噪音。處理規(guī)則是:當檢測到語音靜默開始,后面連續(xù)7個20ms照舊發(fā)送語音幀,第8個20ms發(fā)送一個39比特幀,然后第9、10連續(xù)兩個20ms不發(fā)送數(shù)據(jù),第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由核心網(wǎng)在Security Mode Command消息中給出,并在終端和核心網(wǎng)中同時保存;COUNT-C由HFN和RRC消息的序號SN構成,而HFN從業(yè)務建立過程中RRC連接最后一條消息RRC CONNECTION SETUP COMPLETE消息中得到;DIRECTION為了避免上下行加密算法的輸入內容出現(xiàn)相同,上行設置為0,下行設置為1;LENGTH用于指示生成的Keystream的長度;BEARER是每個無線承載的標識,用于區(qū)別所有無線承載使用同一組加密參數(shù);最終根據(jù)f8算法計算出一個結果,這個結果會應用于需要加密的數(shù)據(jù)從而完成加密過程。
其中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)終端和網(wǎng)絡側HFN不一致。有些廠商認為RB DRD階段是一個硬切換階段,所以HFN加1了,如果某些終端認為RB DRD過程是一個RB階段HFN不加1,導致終端和網(wǎng)絡側維護的HFN不一致,出現(xiàn)流水聲。由于各款終端和網(wǎng)絡側的實現(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ù)據(jù)幀延遲到達,并且落在NodeB的時間窗外,NodeB檢測到之后給RNC發(fā)送大量負的時間調整幀,使得RNC頻繁對所維護的下行CFN(Connection Frame Number)作調整,當下行CFN超過上行數(shù)據(jù)幀中使用的CFN一圈后,由于解密出現(xiàn)錯誤而導致語音流水聲問題。
所以對于同步系統(tǒng)而言,UE在物理信道重配置完成消息里攜帶的激活時間至少比UE發(fā)送時刻的CFN大200,并且是8的倍數(shù)。這主要是為了考慮到IUB口傳輸有較大的時延,有些終端可能沒有考慮到導致在IUB口有較大傳輸時延的情況下出現(xiàn)加密參數(shù)HFN網(wǎng)絡側和UE側維護的不一致,引入流水聲。
2.3 與終端兼容性問題導致單通和靜音
在擁塞小區(qū)用戶撥打非擁塞小區(qū)用戶過程中,如果小區(qū)打開AMRC功能,在擁塞的時候用戶接入會進行降速,以保證速率4.75kbps進行接入,這樣就會觸發(fā)高通某些老款終端的bug,高通會把速率低于10.2kbps時的語音數(shù)據(jù)從3個傳輸信道重配置至2個信道,但網(wǎng)絡側分配一直都是3個子流3個傳輸信道,這樣就會導致UE側MAC層接收數(shù)據(jù)包后出現(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是根據(jù)RNC下發(fā)參數(shù)frameoffset、chipoffset等計算出來的,NodeB在進行FP組包時獲取自己所維護的CFN值填入FP包中,RNC在進行多條鏈路的FP包合并時會根據(jù)該CFN進行合并。如果兩個更軟合并鏈路的幀偏移相差太大,會導致兩條鏈路CFN計算不一致,從而導致FP包中攜帶的CFN參數(shù)突變。
NodeB側CFN突變會引起以下兩個問題:RNC側的上行MDC合并根據(jù)CFN進行,異常的CFN導致合并失敗,從而引起丟包,由于是部分丟包,所以UE側的效果可能是噪音;RNC側的加解密參數(shù)HFN會根據(jù)CFN進行相應的變化(每個CFN周期255結束HFN遞增),異常的CFN導致異常的HFN,HFN錯誤就引起加解密錯誤,從而引起流水聲,而在正常情況下,兩條更軟合并鏈路的frameoffset應該是相等或只相差一的,由于frameoffset以及chipoffset是UE根據(jù)RNC所配鄰區(qū)的基準定時進行測量上報的,而擾碼則是UE區(qū)分小區(qū)的依據(jù)。如果出現(xiàn)擾碼沖突,UE測量時采用另一個相同擾碼小區(qū)的基準定時,不同基站之間的定時相差較大,這就會使UE上報與原鏈路相差較大的frameoffset以及chipoffset值,導致NodeB側CFN突變,進而引起流水聲。
2.5 其他原因導致的單通問題
掉話產(chǎn)生的假單通問題:通話過程中因為質量差,發(fā)生了一側掉話的情況,另一側需要等到手機一定時器超時才能釋放電路,此時該側用戶聽不到任何聲音,感覺象單通,實際為掉話;如果用戶不主動拆鏈,最終會產(chǎn)生掉話,大部分發(fā)生掉話的另一側用戶可能主動掛機。
手機電量低導致的單通情況:該影響產(chǎn)生的單通為電量低手機的通話對方;另外還可能導致掉話,一般電量低的客戶堅持一段時間后會主動關機。
Iu接口中繼鏈路問題:Iu 接口中繼鏈路如果存在問題(如:鴛鴦線問題)可以導致一個通話的來去兩路話音中,有一路可以送達對端,而另一路不能正確的送達對端,引起單通。通話過程中,呼叫切換時如果被分配到有問題的Iu接口中繼的時隙上,將導致該呼叫在通話中突然發(fā)生單通。這樣整個基站控制器管轄區(qū)域下將出現(xiàn)一定比率的單通。
上下行干擾問題:如果一個小區(qū)上行或下行受到嚴重干擾,那么呼叫切入時,就可能導致質量好的一個方向聽得到聲音,而質量差的另一個方向聽不到聲音,形成單通。當然,也有可能是在沒有任何切換的情況下,手機逐漸遠離基站或進入室內,接收電平變差,一個方向的接收質量先于另一個方向惡化,形成通話中的單通。
分布系統(tǒng)的干放引起的單通問題:分布系統(tǒng)的干放對分布系統(tǒng)覆蓋區(qū)域中所有的上行和下行信號進行放大,再傳送到基站。如果干放中的上行或下行放大器存在問題,或放大參數(shù)存在問題,將導致一個方向的信號被正常放大,而另一個方向的信號不能被相應正常的放大。呼叫切入時,將導致單通現(xiàn)象。
手機元器件問題:有些手機使用年限長了,一些電子元器件老化,可能導致通話時揚聲器不發(fā)聲或麥克風不傳聲的問題。這種問題如果在通話過程中發(fā)生,將導致通話中的單通現(xiàn)象。
其它的手機問題:現(xiàn)在網(wǎng)絡中手機的種類越來越多,由手機引發(fā)的問題也越來越多。部分手機的問題十分隱蔽,而且往往和特定的網(wǎng)絡功能有關,不容易查找。
用戶誤操作問題:有些高端手機,在通話時手機屏幕上有靜音按鈕(部分手機為觸摸屏手機),用戶在通話時容易不經(jīng)意的碰到該鍵,引起單通。
3 結束語
本文旨在討論和匯總3G網(wǎng)絡相關語音類問題,其中涉及到流水聲、雜音、單通等現(xiàn)象,網(wǎng)絡中的這些現(xiàn)象在很多情況下會極大的影響用戶的使用感受,對品牌的提升和業(yè)務的正常使用產(chǎn)生較大的負面效果。文中所匯總的只是在現(xiàn)有經(jīng)驗基礎上得出的相關結論,由于異常語音類問題涉及端到端的整個過程,定位和分析都極其復雜,因此不能排除本文之外的其他場景導致的異常情況的出現(xiàn)。在網(wǎng)絡發(fā)展過程中出現(xiàn)類似問題,本文可以為分析和解決問題提供一種思路。