一種基于全ＩＰ蜂窩網絡的實時業務傳輸機制

摘要：針對無線蜂窩網絡和Internet的業務特點，分析了在信道帶寬有限、傳輸誤碼率高的無線網絡中傳輸基于IP的實時業務所面臨的問題。針對下一代蜂窩網絡中基于IP技術實現多媒體業務要求，從無線網絡上實際傳送的碼流角度，結合ROHC機制提出一種在信道傳輸速率不變的條件下，提高碼流傳輸效率的方法，并且探究了空中鏈路的全IP機制。從采樣編碼后輸出的凈碼流和經過封裝后的碼流兩個角度來分析，提出了高效的針對全IP的蜂窩網絡的實時交互式語音業務的新方案。

關鍵詞：下一代蜂窩網絡； 實時IP業務； G.729； RTP； ROHC

中圖分類號：TN914文獻標志碼：A

文章編號：1001—3695(2007)03—0244—03

無線蜂窩技術和Internet是現在廣泛使用的兩種通信技術，兩者各有各的長處。一方面，無線蜂窩技術像GSM，CDMA，WCDMA使它的用戶無論在哪兒都能得到很好的服務，但這項技術所提供的主要服務是語音；另一方面，Internet從一開始就被設計用來提供多種多樣服務，并且它的靈活性和可擴展性使得所有的應用都可以成為它應用的擴展。今天的IP電話技術就是Internet提供服務的一個擴展，完全有理由相信，在即將到來的幾年里，IP技術將成為用來廣泛轉載話音業務的技術，并且未來的無線鏈路也采用基于IP的技術。兩者的結合使得無線通信技術變得具有更多的用途，將不只是支持音頻和視頻，而且還包括網頁瀏覽、E-mail和游戲等。現在研究的下一代蜂窩技術就是采用基于IP技術的方案。它能給其用戶提供語音、視頻、視頻會議、視頻E-mail和視頻短信等豐富多彩的多媒體業務。帶寬是無線網絡中最珍貴的資源，要實現下一代蜂窩網絡上的實時通信，就要提高網絡的傳輸效率，減小語音包傳輸的時延。這在一定程度上由無線網絡上語音包的大小決定。由于無線網絡上實際傳送的碼流是由編碼后輸出的凈碼流（語音包）和經過封裝后的碼流組成，可以在這兩部分分別采用壓縮技術來減小語音包的大小，在信道傳輸速率不變的情況下，充分利用現有的網絡資源，提高凈荷數據的傳輸效率，保證實時交互式業務。

1全IP機制

在全IP機制下的下一代蜂窩系統，其基本目標是給移動終端提供基于IP 的實時和非實時業務，從而達到頻譜效率和錯誤率要求。在實時語音情況下，頻譜效率和錯誤率在目前的蜂窩系統有個執行底線，要求全IP機制在語音服務時滿足這個存在的底線。為了實現基于IP的實時多媒體，在UTP/IP之上主要用RTP協議，參考文獻[1—6]。IPv4下，IP/UDP/RTP封裝后的頭的尺寸是40Bytes;IPv6下，至少60Bytes。當語音負載很短時，如比IP/UDP/RTP頭還短。顯然，如果這樣的語音包在空中接口被發送，不可能滿足要求的語音頻譜效率。所以，在空中接口正向和反向傳輸前，需要一些頭適配技術以減少IP/UDP/RTP頭的尺寸，并且恢復原始的頭。

1.1用戶平面適配

（1）全不透明

用戶平面適配不知道頭和負載的內部結構，在空中接口發送的IP/UDP/RTP頭沒有轉換。誤差防護用在頭的每一個位上，甚至負載的每一個位上。由于一個頭丟失就需要丟棄通信包，沒有錯誤隱藏或緩解應用在頭上，頭部分可能比負載部分更需要誤差防護。這種技術允許在端到端的基礎上支持IPSec協議，達到全透明。明顯的是，由頭部引起的高費用導致頻譜匱乏。

(2)負載不透明

這種情況下，UPA 只需要知道IP/UDP/RTP的內部結構，而不需要知道負載的結構。只有頭通過頭壓縮或頭拆除來達到適配。IP/UDP/RTP頭在傳輸到空中接口之前壓縮，并在接收端解壓縮，頭比負載需要更強的錯誤保護。考慮到以上因素，在下一代蜂窩系統中，頭壓縮算法參考文獻[2]。

1.2全IP機制結論

IP/UDP/RTP包需要適應無線鏈路來滿足頻譜效率和蜂窩系統的誤碼要求。全IP網的應用可以使用針對特定需求的不同承載類型。實時承載被分為基本語音(BV)和實時多媒體(RTMM)兩類。BV承載用來承載語音，等同于傳統蜂窩系統的一個服務;RTMM用來承載通常的多媒體業務，包括語音。對支持的全透明應用來說，純IP業務是可以預測的。

（1）BV在有效負載中使用具有不相等位保護的頭拆除和頭壓縮機制。

（2）RTMM 在有效負載中使用基于相等位保護的頭壓縮機制，而它支持有效負載中不相等位保護的可能性還有待研究。

（3）純IP服務將支持不轉換頭的數據傳輸。頭壓縮在純IP中也是可能的，純IP在有效負載中使用相等的位保護。在所有情況下，頭均要求有很好的誤碼保護。

2語音編碼技術

2．1話音凈荷特點和G.729的語音壓縮編碼

話音源產生的話音首先要經過語音編碼，對其進行采樣、編碼、壓縮，這里采用G.729編碼。1995年ITU批準了G.729的話音壓縮標準，在1996年又得到了進一步的優化改進，現在G.729成為最重要的話音壓縮標準。G.729標準采用的算法可以僅用8kbps傳輸話音。G.729算法（CS-ACELP）在標準PCM或線性PCM（PulsedCodeModulation，脈沖編碼調制）的話音采樣基礎上，每10ms生成一個10Bytes長的話音幀，能提供優秀的音質，并且時延很小[3]。

由于人耳的聽覺范圍在20—20 000Hz，根據采樣定律，要保證聲音不失真，就必須用44kHz左右的采樣頻率，但是人說話的范圍在300—3 400Hz，就要求用8kHz的采樣頻率對人的聲音采樣。G.729標準的8kbps速率加上包頭等開銷，單向語音的速率為11.2kbps。設每路IP語音需12kbps帶寬，它與超3G的20Mbps帶寬相比是極少的，也可以看出采用IP技術的下一代蜂窩通信有廣闊的發展前景。

2.2語音包到達概率

大量的研究表明，話音源由交替出現的講話間隔和停頓間隔組成，假設講話間隔和停頓間隔服從負指數分布。一般講話周期平均長度為352ms， 停頓周期平均長度為650ms。采用G.729編碼方式，在講話周期352ms里，10ms發送一個10Bytes的語音包。

在一個話音源的情況下，在講話間隔352ms里，有35個話音包要發送。假設s為話音源1在一個講話周期內生成的話音包數，數據包發送間隔計時器設為Timer=τ。若在后續τms內沒有任何話音包到達，即τms的起始處不落在s個話音包中任何一個之前的τms內，可得此話音源沒有話音再到達的概率為p=(1002-sτ)/1002，這里假設τ<10。由于在一個講話周期內，平均到達35個話音包，可得到一個話音源沒有話音到達的概率為

不同話音源認為是獨立的，在接收并封裝第一個到達的話音包后，在τms內任何話音源沒有話音包到達的概率：

2.3語音包編碼和封裝

原始到達的語音包經過G.729編碼，設編碼輸出速率為ν_Okbps，語音包大小為χbit，編碼速率ν_Bkbps，比特速率（編碼前語音包中單個比特的傳輸速率）νbit，語音包發送間隔τms，則編碼輸出速率為

其中，ν_bit/ν_B相當于卷積中的1/n，即編碼前和編碼后的符號個數比。

IP話音的實際碼流可估算如下：實際傳送碼流＝壓縮后的語音包/封裝效率，它由一個RTP包最多允許打進多少壓縮后的語音包決定。設封裝效率為η，打進的語音包個數為n，壓縮后的語音包為m，幀長為l，封裝效率的估算公式為

試驗表明，如一個RTP包打一個語音包，則實際傳送碼流為40kps，時延約為10ms；如打兩個語音包，則實際傳送碼流為24kps，時延為20ms；如打四個語音包，實際傳送碼流為16kps，時延為40ms。為保證編碼打包的時延，若將語音包的數量定為兩個，實際傳送碼流即24kps，而不是8kps。可見，采用不同的編碼器和不同的封裝形式所產生的實際傳送碼流是不同的，應根據需要選擇。

3頭壓縮

3．1包頭對傳輸的影響

由于IP技術是通過基于分組的網絡進行話音的傳輸，而目前廣泛使用RTP/RTCP進行實時業務的處理和控制，下面將分析RTP/UDP/IP的壓縮過程。

一個典型的IP話音包包括一個IP頭、一個UDP頭、一個RTP頭和話音凈荷部分。采用RTP傳輸時，基于IP技術的交互式語音分組如果由RTP來承載，包頭的總開銷包括：①對于IPv4來說，有一個IPv4頭（20Bytes）、一個UDP頭（8Bytes）和一個RTP頭（12Bytes），分組之前所使用的分組頭就有40Bytes。②對于IPv6來說，IPv6頭是40Bytes，分組頭就達到60Bytes，參見文獻[4，5]。報頭包含了源目的IP地址、UDP端口號、RTP時間戳、校驗信息以及為保證數據正確傳輸所需的其他協議信息。

在蜂窩網絡中傳輸實時業務，由于Internet只能提供盡力而為的服務，為了能夠提供有保證的實時音頻服務，一方面要分割IP包，這是因為Internet網絡的帶寬資源有限，為更好地保證IP電話的話音質量，應將IP包大小限制為不超過256Bytes；另一方面，在IP協議棧應用層采用RTP。但由上面分析可以看出，經過IP，UDP和RTP封裝后的碼流有一個龐大的頭部，而基于語音編碼的凈荷和所使用的幀的總和也不超過20Bytes。這正是無線鏈路基于IP技術所遇到的一個問題。

為了高效率地傳輸有效數據，必須減小頭的大小。然而，由于在返程時間（RTT）很大的大多數無線鏈路上，以前的壓縮算法（像CRTP算法）無法很好地工作。考慮到無線鏈路上丟失的每個分組均將導致后續的幾個分組的丟失，使得至少在一個RTT內，壓縮方和解壓方的關聯信息已經不再同步了。加上無線鏈路的有損特性，為了保證無線資源被有效地使用，必須承受1e—3的誤碼率(BER)；在某些情況下，誤碼率將高達1e—2，超3G蜂窩系統誤碼率也要。再加上無線鏈路較長的回程時間(RTT)，這個RTT可能高達100～200ms和不可忽略的殘留誤碼率。可見無線鏈路的特性使得以前的頭壓縮方案無法提供實時的傳輸。由于在蜂窩網中，帶寬是最寶貴的資源，頭標壓縮方案的壓縮比和魯棒性比它的執行和簡單的計算更重要。基于以上條件，RFC3095的ROHC算法由于很適合無線鏈路的情況，已被UMTSrelease4和5采納，并且被ETSI和3GPP采用作為3G移動電話的技術標準，本文也將其用于下一代蜂窩系統的頭壓縮編碼。

3．2ROHC算法

頭標壓縮的原理是基于分組間，尤其是連續的分組間的各個頭標域有很大的信息冗余這樣的事實。ROCH算法很適合于無線鏈路，它能夠把40Bytes或者60Bytes的包頭壓縮成1—3Bytes。它在壓縮方面有很好的性能，并能抵抗蜂窩鏈路的包丟失，在下一代蜂窩系統里可以采用這種包頭壓縮算法。

3．2.1頭分類

在本算法中，將每個IP，UDP和RTP頭域都分類，按照類型進行不同的處理。類型分為INFERRED，STATIC，STATIC-DEF，STATIC-KNOWN和CHANGING。除了分類為CHANGING的頭域，其他分類的頭域都有各自固定的處理方案。分類為CHANGING的頭域又被分為五個子類，即STATIC，SEMISTATIC，RARELY-CHANGING(RC)，ALTERNATING和IRREGULAR。基于現有的IPv4網絡、IPv4頭域、UDP頭域和RTP頭域分類如表1—3所示，表4統計了ROCH算法中IP/UDP/RTP頭域分類的總長度。

3.2.2頭分類的結論

經過分類，有很多域不變或很少改變，可以被輕松地壓縮。只有總共10Bytes的五個域需要更深層次的處理。這些域是：

（1）IPv4標志（16bits）IP-ID；

（2）UDP校驗和（16bits）；

（3）RTP標記（Marker）（1bit）Mbit；

（4）RTP序列號（16bits）SN;

（5）RTP時戳（32bits）TS。

4結束語

針對下一代蜂窩網絡上的實時交互式通信問題，本文分別從采樣輸出的凈碼流和經過封裝后的碼流兩部分的壓縮編碼技術來研究在信道傳輸速率不變的情況下，提出保證實時交互式語音業務的方法。提出的編碼方案充分考慮了提高網絡的傳輸效率、減小語音包傳輸時延及提高帶寬有效利用率，能夠提高有效語音數據的傳輸效率。

本文中所涉及到的圖表、注解、公式等內容請以PDF格式閱讀原文。