3G手機VoIP話音的QoS實現技術研究

梁鴻斌

(成都三零瑞通移動通信有限公司，四川成都610005)

0 引言

隨著第三代移動通信網絡的普及和信號覆蓋的逐漸完善，基于3G系統的VoIP話音通信已具備了推廣應用的基礎。特別是HSPA網絡的廣泛應用，可以極大地提升VoIP話音通信質量。HSPA技術包括HSDPA(高速下行鏈路分組接入技術)和HSUPA(高速上行鏈路分組接入技術)，HSPA可以提供最快達14 Mb/s的數據傳輸速率［1］。目前市面上很多VoIP運營商推出了基于3G系統的VoIP話音通信業務，基于3G系統的VoIP話音通信業務采用SIP協議實現VoIP呼叫控制和話音傳送，這種基于SIP服務器和手機客戶端的VoIP話音通信業務在信號較好時，VoIP話音的QoS較好，但在信號較差或3G系統的使用高峰期(無線上網的用戶量大時)，VoIP話音的QoS明顯降低。文中就VoIP話音的QoS實現技術進行了探討并提出了一些實用化的解決思路。

1 3G手機VoIP話音QoS的主要實現技術

在網絡中，提供資源保證和服務差異化的能力，通常稱為服務質量(QoS)，QoS是VoIP話音通信是否能獲得成功的關鍵［2］。通常用戶對各種業務和應用體驗的滿意程度通過服務質量(QoS)來衡量［3］。為了保證3G手機VoIP話音通信的QoS，3G手機中采用的的主要實現技術包括:語音編碼技術、靜音檢測技術、回聲處理技術、抖動緩沖技術、丟包補償技術、舒適噪聲技術以及應用層實現的冗余傳輸技術，綜合運用以上實現技術可有效提升VoIP話音的QoS，明顯改善VoIP話音質量。VoIP話音QoS的主要實現技術從各個方面保證了VoIP話音的QoS，VoIP話音QoS的實現技術的具體內容包括如下。

(1)語音編碼技術

語音編碼技術是3G手機VoIP話音通信技術的一個重要組成部分。VoIP話音通信通過3G網絡進行話音數據傳輸，如果編碼速率高，對3G網絡資源要求就高，因此，VoIP話音通信需要在保證話音質量的前提下，盡可能地降低編碼比特率，這主要就依賴語音編碼技術來解決［4］。目前，比較主流的編碼技術如表1所示。

表1 幾種語音編碼算法的比較Table 1 Comparison of several speech coding algorithm

音頻編碼設計受編碼質量、應用限制條件、信號特性、實現復雜性和通信誤差容錯的影響。根據實際需要，表1中的編碼技術均可滿足不同條件下的3G手機VoIP話音通信要求。

此外，iLBC和SILK是專門為包交換網絡通信設計的編解碼，無論是在高丟包率條件下還是在沒有丟包的條件下，其語音質量都優于目前流行的G.723.1，G.729A 等標準編解碼，而且丟包率越大，使用iLBC和SILK的語音質量優勢越明顯。通常情況下，為了衡量IP網絡語音質量，將大于等于5%丟包率的網絡情況定義為VoIP的極限網絡條件。經過語音質量測試，即使在5%丟包率的情況下，iLBC和SILK仍然能夠提供相當于GSM手機的語音質量。鑒于iLBC和SILK良好的網絡適應能力，iLBC和SILK編解碼算法的應用范圍越來越廣泛。

(2)靜音檢測技術

靜音檢測(VAD－Voice Activity Detection)技術可以有效剔除靜默狀態信號，只傳輸有效的語音信號，從而使語音信號的占用帶寬可以大于50%。靜音檢測技術在VoIP話音通信中的運用，在3G網絡信道嚴重擁塞或信道突發誤碼嚴重的狀態下，對降低VoIP話音的時延，減少話音數據丟失，會有特別明顯的作用。

在普通電話通話過程中，通常兩個人的會話是采用半雙工的方式進行，一方講話時另一方處于靜默狀態，并且講話過程中有大量明顯的停頓。平均統計，一方說話的時間只占整個通話時間的一半，即有一半時間是在聽對方說話，計算講話中的停頓時間，任一方真正只占用40%的線路時間。在VoIP話音通信中，利用靜音檢測技術，可以檢測出雙方通話過程中的靜默時段，通過減少發送的IP話音數據包，從而提高帶寬利用率。

采用靜音檢測技術并不意味著完全不傳輸靜音，如果完全不傳輸靜音，雖然最大限度的節省了信道資源，但對用戶體驗會造成一定的影響，因此，在采用靜音檢測技術檢測到靜音時，適當的傳輸背景噪聲，會一定程度上改善用戶體驗。

(3)回聲抵消技術

在3G手機VoIP話音通信中，由于手機揚聲器播放出來的聲音被麥克風拾取后發回遠端，這就使得遠端談話者能聽到自己的聲音，由于回聲時延較大，說話方感覺非常明顯，因此，通過3G網絡進行VoIP話音通信，回聲抵消技術的采用非常重要。

3G手機VoIP話音通信中的回聲為聲學回聲，一般采用聲學回聲消除器(AEC－Acoustic Echo Canceller)來消除回聲?；芈暤窒夹g可以較好的消除回聲，并降低回聲對話音質量的影響。

(4)抖動緩沖技術

抖動是不同數據包到達接收端的不同延遲造成的。3G手機VoIP話音通信實際是通過IP網絡進行，而IP網絡的一個特征就是網絡延時和抖動，為了防止網絡抖動造成失真，就要在接收端設置緩沖區，將收到的話音數據包緩存在緩沖區中，通過對緩沖區中的話音數據包進行處理，使得這些話音數據包經過處理后盡量保持和發送端一樣的波形。對話音數據包的處理和緩存會引入一定的時延，緩沖區隊列大小的設計是要考慮的重要因素。過小的緩沖區隊列將導致溢出和數據包丟失，從而影響語音質量，過大的緩沖區隊列將增加語音的延時。

顯然，消除抖動和減小時延是相互矛盾的，根據信道特點，采用動態的策略來平衡以上矛盾。通常采用自適應方法調節緩沖區的長度，時延增加時，減少緩沖區的長度，在抖動加大時增加緩沖區的長度，從而在時延和抖動之間取得平衡。此外，還必須限制緩沖區的最大長度，因為時延超過一定時間，通話雙方根本不能進行正常的交流，注意設法提供最低限度的延遲和抖動，盡可能地改善服務質量。

(5)丟包補償技術

通過3G網絡進行IP數據的傳輸，丟包是常見的問題［5］，VoIP話音通過IP網絡傳輸時采用UDP包進行傳送，目前網絡中對UDP包的傳輸不提供任何可靠保證，由于網絡原因大量頻繁的丟包會對話音質量造成嚴重影響。

數據通信中丟失的數據包可以通過相關的數據通信協議來保證丟失數據包的恢復，包括數據的多次重傳，而語音通信由于是實時通信，對于話音數據丟包與數據通信丟包采用的方法不同。數據通信要求傳輸的數據不允許任何誤碼或丟包，而語音通信卻能容忍一定的語音數據丟包。當丟包率小于5%時，對話音通信影響較小。當網絡狀況惡化，丟包率過高，會嚴重影響通話質量。主要的解決方法包括:狀態插值法、交織法、增加冗余度等方法對丟包進行補償，通過丟包補償技術，可有效減少和掩蓋語音分組丟失對語音質量的影響。根據信道條件和終端資源，可以采用一種或多種丟包補償技術來改善丟包對通話造成的影響。

此外，通過舒適噪聲技術、冗余傳輸技術等，也可一定程度的改善話音質量，提高用戶的實際體驗。以上3G手機VoIP話音QoS的主要實現技術，在對話音質量造成影響的各個方面分別起到了相應的改善作用，在3G網絡信號較好的情況下，VoIP話音的QoS較好，但在信號較差或3G網絡的使用高峰期(無線上網的用戶量大時)，VoIP話音的QoS明顯降低。

2 實時反饋的話音傳輸策略

在3G網絡中，影響VoIP話音質量最主要的因素之一是空口傳輸IP語音數據包的可靠性和穩定性，同時手機用戶上網的高峰期，也會對VoIP話音質量造成一定影響。由于無線通信信道的特點(突發誤碼嚴重)和手機用戶上網的使用習慣(集中在一個時段上網)，在成熟的VoIP話音QoS的主要實現技術的基礎上，有必要研究一些新的QoS的實現技術，從而提高3G手機VoIP話音的QoS。文中提出一種新的QoS的實現技術:實時反饋的話音傳輸策略，實時反饋的話音傳輸策略包括三部分的內容:動態實時的端到端反饋機制、語音編碼器的選擇和RTP包發送策略。

2.1 動態實時的端到端反饋機制

RTCP實時傳輸控制協議利用與數據包相同的傳輸機制向參與者周期性發送控制包，從而對RTP的傳輸進行監測和控制，各種RTCP包格式都是為了反饋數據傳輸質量。RTCP其主要功能是為了提供丟包率統計、以及數據包達到的間隔時間抖動等。按RTCP協議RTCP包的發送間隔較長，并且當無線信道突發誤碼嚴重或上網高峰期，發送端收到的反饋信息就會嚴重滯后，嚴重影響發送端采用相應的話音QoS實現技術的實際效果。

采用帶內反饋機制，將丟包率和信道擁塞等關鍵指標通過每個RTP包實時反饋給發送端，不僅使發送端可根據實時反饋的關鍵指標對RTP的傳輸進行控制，而且不明顯增加信道帶寬。如圖1所示為增加反饋數據的RTP包格式。反饋數據包括丟包率和擁塞度，長度為1字節，丟包率和擁塞度各為4比特。

圖1 RTP包的格式Fig.1 RTP packet format

每隔一段時間T(1 s或500 ms)，計算丟包率和擁塞度。丟包率(PLR)計算如式(1)所示，擁塞度(CODR)計算如式(2)所示。

式中，Nq是時間T內根據實際收到的RTP包的序號計算的應該收到的RTP包總數，Nd是根據RTP包頭的序號計算的丟掉的RTP包。

式中，Ne是時間T內期望收到的RTP包，Nr是實際收到的RTP包。

2.2 語音編碼器的選擇

根據接收端反饋的丟包率和擁塞度，發送端可動態地選擇語音編碼速率以適配不同的網絡情況。根據不同的編碼速率，如果動態地選擇不同的語音編碼器，頻繁的在不同的語音編碼器之間切換，將會嚴重影響話音質量。因此，選擇一種語音編碼器，只需要選擇不同的編碼速率，將編碼速率動態的變化對話音質量的影響降至最低。

SILK是Skype公司研制的語音編碼器，其編碼速率范圍為6～20 b/s，同時，SILK還可以根據預計的信道誤碼率在編碼時進行冗余編碼，以便在收端根據冗余編碼恢復丟失的話音數據，SILK在不同網絡條件下的綜合評分優于其他的語音編碼器。其大范圍的編碼速率，特別適用于基于3G手機的VoIP話音通信。

2.3 RTP包發送策略

根據反饋數據發送端制定合理的發送策略，結合丟包率、擁塞度，控制發送端的編碼速率、預計的信道誤碼率 EFR、RTP包在應用層的冗余重發(RSEND)(一個話音包重發次數)等，發送策略如表2所示。

表2 RTP包發送策略Table 2 Strategy of sending RTP packet

發送策略的原則包括:根據反饋數據，丟包率越高，發送端在編碼時插入的冗余編碼數據越多，以便于收端恢復更多的丟失話音數據;擁塞度越大，說明越擁塞，采取動態降低語音編碼速率，同時在應用層不采取冗余傳輸的方法，以減小占用帶寬，緩解擁塞。表2中的具體判定條件是在RTP包發送策略的原則基礎上，根據實際測試的情況確定的。

3 測試驗證

根據文中提出的3G手機VoIP話音QoS新的實現技術，采用開源的客戶端軟件Sipdroid(SOLD)和在客戶端軟件Sipdroid基礎上增加了文中提出的新的實現技術的軟件(Snew)，在基于Android的智能手機上進行了對比測試。由于在3G手機信號較好的情況下，SOLD和Snew沒有區別，因此專門選擇兩個3G手機使用比較典型的場景(信號變化大和信道擁塞)進行測試，SOLD和Snew表現出了明顯的差別，具體場景包括:

1)場景1:選擇手機信號一直較差的區域，該區域信號顯示小于－95 dbm，并且信號變化較大。

2)場景2:在3G網絡的使用高峰期(無線上網的用戶量大時)，選擇在晚上8到9點的時間段。

測試結果如表3所示。

表3 話音質量測試Table 3 Voice quality test

通過兩個3G手機使用比較典型的場景的直觀對比測試，采用實時反饋的話音傳輸策略時的VoIP話音通信質量明顯優于沒有采用實時反饋的話音傳輸策略時的VoIP話音通信質量，該測試說明了實時反饋的話音傳輸策略增強了VoIP話音對網絡環境的快速變化的適應能力，具有較強的實用價值。

發送端的RTP包發送策略還可以根據具體的傳輸情況，提高相應的發送控制精細度，以便更好的適應不同的環境要求。

4 結語

文中在分析既有3G手機VoIP話音QoS的實現技術的基礎上，根據3G網絡VoIP話音通信的具體特點，提出了實時反饋的話音傳輸策略的新思路?；贏ndroid的智能手機，綜合利用既有3G手機VoIP話音的實現技術，同時結合文中提出的實時反饋的話音傳輸策略，實現了VoIP話音QoS的控制。通過在不同的網絡環境條件下的對比測試，說明了采用實時反饋的話音傳輸策略的VoIP客戶端軟件網絡適應能力更強。下一步工作準備通過大量試驗提高發送控制精細度，從而進一步提高VoIP話音的QoS。

［1］龐韶敏，李亞波.3G UMTS與4G LTE核心網 －CS，PS，EPC，IMS［M］.北京:電子工業出版社，2011:3 －4.PANG Shao－min，LI Ya － bo.3G UMTS and 4G LTE Core Network－CS，PS，EPC，IMS［M］.Beijing:Publishing House of Electronics Industry，2011:3 －4.

［2］李剛.3G無線網絡中的 QoS研究［J］.科技信息，2009(08):541－542.LI Gang.Research on 3G wireless network in QoS ［J］.Science ＆ Technology Information，2009，(08):541 －542.

［3］文浩，林闖，任豐原，等.無線傳感器網絡的QoS體系結構［J］.計算機學報，2009，32(03):432－440.WEN Hao，LIN Chuang，REN Feng － yuan，et al.QoS Architecture for Wireless Sensor Network［J］.Journal of Computer ，2009，32(03):432 －440.

［4］張春紅，裘曉峰，弭偉，等.P2P技術全面解析［M］.北京:人民郵電出版社，2010:186.ZHANG Chun – hong，QIU Xiao － feng，MI Wei，JI Yang，et al.Comprehensive Analysis of P2P Technology［M］.Beijing:Posts＆ Telecomm Press，2010:186.

［5］何兵，陳鍵.分組語音傳輸的丟包應對回顧［J］.計算機工程，2002，28(07):44 －46.HE Bin，CHEN Jian.Packet Loss to Cope with Packet Voice Transmission Review［J］.Computer Engineering，2002，28(07):44 －46.