首頁>>>技術(shù)>>>VoIP

第三代移動網(wǎng)絡(luò)應(yīng)用中的VoIP技術(shù)

2009/09/02

　　VoIP技術(shù)不僅在固定網(wǎng)絡(luò)中獲得了巨大的成功，在移動網(wǎng)絡(luò)中也在穩(wěn)步前進(jìn)，特別是在向3G邁進(jìn)的今天，可以預(yù)見VoIP在未來會成為話音的主流技術(shù)。VoIPoW(VoIPover Wireless)即在移動網(wǎng)絡(luò)中的VoIP在有著廣闊發(fā)展前景的同時，也面臨著一些挑戰(zhàn)，比如QoS和如何有效的利用頻譜等。本文將先介紹VoIP在GPRS，UMTS中的應(yīng)用框架和關(guān)鍵技術(shù)，最后再談?wù)勂銺oS的問題。

　　1.VoIPin GPRS

　　VoIP在GPRS網(wǎng)絡(luò)中應(yīng)用，需要解決的2個關(guān)鍵技術(shù)是頭部壓縮和非標(biāo)準(zhǔn)的TBF。

　　1.1 頭部壓縮技術(shù)

　　IP包頭過長是影響其在無線網(wǎng)絡(luò)中應(yīng)用的一個重要問題，解決這一問題的方案是采用頭部壓縮技術(shù)(RFC2508，低速串行鏈路下IP/UDP/RTP數(shù)據(jù)包頭的壓縮)。

　　頭部壓縮技術(shù)的原理是：語音編碼器生成的語音數(shù)據(jù)被逐層封裝成RTP，UDP和IP包。這樣的語音幀頭部長度達(dá)到40 B，但是有效載荷只有15～30 B。這樣對于一個相同的語音流來說，在連續(xù)的語音包中就有較高的冗余度。要降低這種冗余，必須使用壓縮算法。

　　IETF提供了多種包頭壓縮的標(biāo)準(zhǔn)，cRTP就是最有影響力的一種，他可以將40 B的包頭最小壓縮至2 B。用cRTP進(jìn)行頭部壓縮，必須維護(hù)上下文信息(Context，即未壓縮的在通路兩端上一次發(fā)送的包頭)，這樣，頭部僅僅攜帶上下文信息的變化即可。但是如果發(fā)生丟包或包被損壞，接收端就無法正確地更新上下文信息。所以必須提供相應(yīng)的機(jī)制去監(jiān)測上下文錯誤并去修復(fù)他。cRTP可以發(fā)送上下文更新請求來修復(fù)上下文，但是鏈路上的往返時間會影響這種修復(fù)機(jī)制的效率。

　　另一種高效且更適應(yīng)蜂窩應(yīng)用的方法是ROCOO (Robust Checksum-based header Compression)。ROCCO在包頭提供了解壓縮器以及足夠的信息，使得可以在本地來修復(fù)上下文，即使在多個連續(xù)的包流失或損壞的情況下也是如此，這樣就消除了cRTP中會造成一些負(fù)面作用。

　　比較而言，ROCOO比cRTP具有更高的健壯性、壓縮比和容量，正是因為這些壓縮技術(shù)，才使得VoIP成為新的無線語音業(yè)務(wù)的選擇變得切實(shí)可行。

　　1.2 非標(biāo)準(zhǔn)的TBF

　　TBF(Temporary Block Flow)是建立在移動站和網(wǎng)絡(luò)之間的臨時數(shù)據(jù)通道，在理想情況下他的上行時間為100～150 ms，下行時間為60～100 ms。TBF假定大的應(yīng)用數(shù)據(jù)包會在一個TBF中發(fā)送，當(dāng)發(fā)送完畢后，他會釋放。當(dāng)語音包連續(xù)發(fā)送時，頻繁地釋放和重建。這樣顯然無法滿足實(shí)時應(yīng)用(如VoIP)端到端最小時延的要求，所以必須對TBF的釋放機(jī)制進(jìn)行修改。

　　一種選擇是建立一條半永久的TBF，即通話開始建立TBF，通話結(jié)束釋放TBF。在非活動狀態(tài)下(如靜音)，分配給TBF的資源可以被別的應(yīng)用復(fù)用。此外，還可以有永久性的TBF，他相當(dāng)于電路交換方式，即給MS分配一條永久性的PDTCH(Packet DataTraffic Channel)。永久性的TBF可以被優(yōu)化，來使實(shí)時數(shù)據(jù)(real time data)和普通數(shù)據(jù)(best effortdata)仍可被復(fù)用。

　　2.VoIPin UMTS

　　UMTS(Universal Mobile TelecommunicationSystems)是3G組織提出的全球可漫游的移動通信系統(tǒng)。在UMTS中應(yīng)用VoIP，結(jié)果是在UMTS中產(chǎn)生一個端到端的、高帶寬的IP會話，這相當(dāng)于為移動終端用戶打開一個多媒體業(yè)務(wù)的集合，而這正是UMTS致力的一個目標(biāo)。

　　在UMTS中應(yīng)用VoIP，需要下列的網(wǎng)絡(luò)元素：MSCServer，SIPServer，UTRANMG，PSTNMG，SG，HSS，AAA，同時在網(wǎng)絡(luò)中使用SIP作為呼叫控制協(xié)議。

　　MGC通過H.248來控制MG，同時他也完成SIP和ISUP的信令轉(zhuǎn)換。UMTS使用GPRS來傳輸數(shù)據(jù)流，對于語音他使用GPRS隧道協(xié)議GTP(GPRSTunneling Protocol)，這是針對分組交換移動終端的，移動性問題可以通過GPRS協(xié)議來解決。用戶的個性業(yè)務(wù)可以通過兩種方式提供給虛擬家庭環(huán)境(VHE)，一種是在SIPServer上開發(fā)SSP，并把SIP的呼叫狀態(tài)模型映射到IN/CAMEL狀態(tài)模型(IN的移動版本，Customized Application for Mobile NetworksEnhanced Logic)，這種SSP叫做SoftSSP，這樣VoIP就可以支持INAP和CAMELApplication Protocol(CAP)，當(dāng)IN業(yè)務(wù)需要時就可以觸發(fā)給SCP;另一種則是通過強(qiáng)大的第三方呼叫控制機(jī)制來定義新業(yè)務(wù)，如CGI和CPL(CallProcessing Language)。

　　除了上述的網(wǎng)絡(luò)元素和協(xié)議外，AAA(Authentication，Authorization and Accounting)功能也是必備的。使用AAA功能可以滿足多個目的，如用戶的安全性、QoS和帳戶/計費(fèi)框架。AAA可以在自治域中為SIP呼叫建立提供QoS，也可以在用戶帳戶信息的基礎(chǔ)上來計費(fèi)。OSP(Open SettlementProtocol)協(xié)議可以被業(yè)務(wù)提供者用來授權(quán)和計費(fèi)。IPsec協(xié)議用來為IP電話網(wǎng)關(guān)授權(quán)。許可控制策略可以用COPS(Common Outsourcing ProtocolService)作為許可策略。QoS策略可以被策略服務(wù)器安裝到路由器(push方式)，也可以由邊緣路由器向策略服務(wù)器來詢問(pull方式)。

　　3.3G中VoIP的業(yè)務(wù)質(zhì)量

　　VoIP的語音質(zhì)量不僅取決于VoIP硬件本身，也取決于傳送他的廣域網(wǎng)。一個有突發(fā)性丟包，延遲和抖動的擁塞網(wǎng)絡(luò)，肯定會降低VoIP的質(zhì)量級別。

　　有4個指標(biāo)決定了VoIP的質(zhì)量需求，括號里是他們應(yīng)達(dá)到的要求。 (1)業(yè)務(wù)可用性(99.999%); (2)呼叫建立時間(本地呼叫小于2 s); (3)話音延遲(單向小于150 ms); (4)話音質(zhì)量(最小的回聲和干擾)。

　　這里面，話音延遲是最關(guān)鍵的問題。

　　3.1 延遲的原因

　　話音延遲會產(chǎn)生很多問題。首先是回聲，如果往返延遲(round-trip delay)小于50 ms，那么這個問題就被忽略，因為用戶不會察覺反射信號和先前語音的差別。反之，如果超出50 ms，這在VoIP網(wǎng)絡(luò)中是普遍存在的，那么回聲就會很明顯。所以VoIP網(wǎng)絡(luò)必須有回聲控制或?qū)崿F(xiàn)回聲消除的機(jī)制。另一個延遲問題就是話音交迭。當(dāng)單向延遲大于250 ms時，這個問題就會出現(xiàn)，所以必須對端到端的延遲進(jìn)行限制。延遲可以分為以下幾種類型：

　　(1)積累延遲或算法延遲(Accumulation Delay/Algorithmic Delay)

　　語音編碼器生成的語音采樣幀的大小是不同的，他既和語音編碼器的類型有關(guān)，也和采樣時間有關(guān)(從125μs～ms級)。

　　(2)處理延遲

　　編碼和收集語音樣本到包中所需要的時間。編碼時間和處理器的處理時間有關(guān)，也和算法類型有關(guān)。而且，一般來說，一個數(shù)據(jù)包中要包括多個語音編碼幀以減少冗余。例如，一個分組可能包括3個G.729編碼幀，相當(dāng)于30 ms的話音。這樣，在處理和收集中就會產(chǎn)生延遲。 (3)網(wǎng)絡(luò)延遲網(wǎng)絡(luò)的物理介質(zhì)和協(xié)議是造成延遲的另一個因素。網(wǎng)絡(luò)延遲是鏈路容量和網(wǎng)絡(luò)轉(zhuǎn)發(fā)處理的函數(shù)。 (4)抖動延遲

　　抖動延遲是消除抖動而使用緩沖造成的延遲。為了滿足靈活性，系統(tǒng)必須有多種策略來使在消除抖動的前提下，動態(tài)調(diào)整緩沖區(qū)的大小，使其最小化并減少延遲。一種方法是在一段時間里測量分組間隔的變化，并且不斷地使緩沖區(qū)大小適應(yīng)計算出的抖動。這種方法當(dāng)網(wǎng)絡(luò)抖動具有固定的特性時工作得很好，比如說ATM。另一種方法是計算晚到分組的數(shù)目，并計算他們和成功處理分組數(shù)目之間的比例。這個比例用來調(diào)整抖動緩沖區(qū)以達(dá)到預(yù)定的、允許的遲到分組比例。這種方法當(dāng)分組到達(dá)間隔變化非常大時，如IP網(wǎng)絡(luò)，工作的非常好。

　　3.2 解決QoS問題的方法

　　簡而言之，用來使VoIP滿足QoS需求的方法有兩種，發(fā)送端的和接收端的。我們先介紹發(fā)送端的： 頭部壓縮 如上面提到的cRTP和ROCOO方法。

　　排隊策略 基本的排隊策略可以被描述成FIFO，即先入先出。這會導(dǎo)致話音分組排在其他不重要的分組的后面。一種替代方法是WFQ，有權(quán)重的公平排隊，他有多個隊列，不同的隊列對應(yīng)不同的類型，每一種類型的隊列分配相同的帶寬。這使得語音分組可以在其他一些高帶寬消耗程序，如FTP應(yīng)用的同時，得以通過。

　　RSVP 通過RSVP，連接的端點(diǎn)就可以告知網(wǎng)絡(luò)他所需要的QoS種類。這讓端點(diǎn)可以要求所需的帶寬和延遲。使用RSVP的應(yīng)用程序可以得到反饋，看看自己的需求是否滿足，然后決定是否做出其他選擇。RSVP的一個缺點(diǎn)是他的應(yīng)用規(guī)模，即無法大規(guī)模的在網(wǎng)絡(luò)中實(shí)現(xiàn)。 現(xiàn)在，介紹一些在接收端獲得QoS的方法：

　　分組丟失補(bǔ)償 可以采用插入新的語音分組，發(fā)送冗余信息，及兩者混合的方法。

　　回聲補(bǔ)償 ITU的G.165標(biāo)準(zhǔn)定義了回聲消除器的操作需求�；芈曄鞅容^收到的語音數(shù)據(jù)和先前發(fā)送的語音數(shù)據(jù)，一個數(shù)字過濾器會把收到的語音數(shù)據(jù)中屬于曾經(jīng)發(fā)送的語音數(shù)據(jù)消除。

慧聰網(wǎng)


相關(guān)鏈接:
Google Voice可能將改變打電話的成本結(jié)構(gòu) 2009-09-01
借鑒歐美 俄羅斯尋求VoIP監(jiān)管之路 2009-09-01
淺談國內(nèi)VOIP網(wǎng)絡(luò)電話發(fā)展演變 2009-08-27
從用戶角度看網(wǎng)絡(luò)電話如何贏得市場 2009-08-21
如何用Asterisk構(gòu)建企業(yè)級的電話系統(tǒng) 2009-08-12