??? 摘??要: 針對NGN 的網(wǎng)絡(luò)體系結(jié)構(gòu)和業(yè)務(wù)特點,在深入分析下一代網(wǎng)絡(luò)" title="下一代網(wǎng)絡(luò)">下一代網(wǎng)絡(luò)QoS技術(shù)的基礎(chǔ)上, 闡述了VOIP 網(wǎng)絡(luò)中QoS的主要模型和關(guān)鍵技術(shù)，并以模擬實驗為依據(jù)比較了各種QoS的控制策略, 從系統(tǒng)的角度出發(fā),對下一代網(wǎng)絡(luò)的QoS保障機制進(jìn)行了討論。
??? 關(guān)鍵詞: NGN； QoS；VOIP；綜合服務(wù)；區(qū)分服務(wù)；MPLS；控制策略
?
???
下一代網(wǎng)絡(luò)NGN(Next Generation Network) 將是一個以軟交換為核心, 基于分組技術(shù)，可以支持?jǐn)?shù)據(jù)、語音、視頻和各種多媒體業(yè)務(wù)的綜合開放的網(wǎng)絡(luò)架構(gòu)。NGN來勢洶涌，主導(dǎo)了通信網(wǎng)的發(fā)展方向。
隨著NGN技術(shù)逐步發(fā)展，電信運營商業(yè)已擁有了能夠同時提供傳統(tǒng)的電信語音業(yè)務(wù)和新興的基于IP的多媒體業(yè)務(wù)的統(tǒng)一平臺。如何確保這個平臺穩(wěn)定運行, 保障不同類型客戶的服務(wù)質(zhì)量" title="服務(wù)質(zhì)量">服務(wù)質(zhì)量QoS(Quality of Service), 已成為首當(dāng)其沖的任務(wù)。QoS實現(xiàn)技術(shù)的研究對于部署NGN而言是一個意義非凡的挑戰(zhàn)。
1 VOIP 的 QoS需求
IP電話（VOIP）是下一代網(wǎng)絡(luò)中最有前途的技術(shù)之一，VOIP的運營業(yè)務(wù)正在許多國家弄潮于浪尖，并有席卷全球之勢，VOIP的成功并非由于其運營商的搖旗吶喊，而是與PSTN相經(jīng)確實有著不可替代的優(yōu)勢。VOIP承載網(wǎng)絡(luò)的利用效率高，一個PSTN電話需要獨占64kb/s的帶寬，而VOIP一般只需要復(fù)用6kb/s～8kb/s甚至更少； VOIP還為一些智能網(wǎng)增殖業(yè)務(wù)提供了應(yīng)用經(jīng)驗，比如多人視頻游戲、可視電話會議等,而且 VOIP網(wǎng)絡(luò)的網(wǎng)間結(jié)算費用較低，這可能是當(dāng)前政策的因素，但不論怎樣，低廉的運營成本對所有的運營商都是一個難以抵制的誘惑。
VOIP是典型的實時性業(yè)務(wù)，與QoS的聯(lián)系尤為密切，對于QoS有很高的要求。用戶在使用VOIP業(yè)務(wù)的時候，最關(guān)心的莫過于通話的語音質(zhì)量問題，這是其QoS問題的聚焦之處。
2 關(guān)于幾種QoS保證機制
2.1 綜合服務(wù)（IntServ）
綜合服務(wù)(IntServ)是根據(jù)每個IP 流的QoS 等級的精確描述,由資源預(yù)留協(xié)議(RSVP)和流的準(zhǔn)入控制支持IP 的QoS分類。一旦有業(yè)務(wù)流" title="業(yè)務(wù)流">業(yè)務(wù)流被分配給某類通信, 一個“PATH”消息將被一直發(fā)送至目的地址,以便確定網(wǎng)絡(luò)是否具有業(yè)務(wù)運轉(zhuǎn)時所必須的足夠資源 (如帶寬、緩沖空間等)。如果發(fā)現(xiàn)路徑上所有設(shè)備都可以提供所需資源,接收端則生成一個“RESV”消息返回給發(fā)送端,通知發(fā)送端可以開始傳輸數(shù)據(jù)。這一過程就是RSVP。IntServ的最大優(yōu)點就是能夠在多種業(yè)務(wù)并存的網(wǎng)絡(luò)環(huán)境下，通過RSVP與終端應(yīng)用交互，為對服務(wù)質(zhì)量有著不同要求的業(yè)務(wù)流提供滿足需要的服務(wù)，在理論上實現(xiàn)了絕對的服務(wù)質(zhì)量保證。IntServ的缺陷在于控制粒度過細(xì)而導(dǎo)致控制開銷過大，并且要求從發(fā)送者到接收者之間的所有路由器都支持諸如RSVP的信令協(xié)議，如果其中存在不支持的網(wǎng)元設(shè)備，雖然信令可以透明地通過，但已無法實現(xiàn)最佳的資源預(yù)留，不能完全保證服務(wù)質(zhì)量的有效提供。
2.2 區(qū)分服務(wù)（DiffServ）
DiffServ不是針對每一個業(yè)務(wù)流進(jìn)行資源預(yù)留分配，而是在用戶和業(yè)務(wù)網(wǎng)的接口處將業(yè)務(wù)分類，把具有相同的延遲、傳輸速率、抖動等服務(wù)質(zhì)量參數(shù)的業(yè)務(wù)流劃歸為一類，對同一類業(yè)務(wù)流采取一致的傳輸處理。在DiffServ網(wǎng)絡(luò)中，節(jié)點存儲的狀態(tài)信息數(shù)量與服務(wù)級別的多少成正比，而不是業(yè)務(wù)流的數(shù)量。DiffServ 的控制顆粒也只是少數(shù)幾類聚合業(yè)務(wù)流,無需專門的控制協(xié)議。業(yè)務(wù)流的分類和匯聚將在網(wǎng)絡(luò)邊緣完成，全過程由邊緣路由器負(fù)責(zé),核心路由器則根據(jù)業(yè)務(wù)流的標(biāo)記將它們發(fā)送到目的端而不必檢查每個分組頭的細(xì)節(jié)。在網(wǎng)絡(luò)規(guī)模擴(kuò)大和數(shù)據(jù)流量增加時，DiffServ不會像IntServ會引起網(wǎng)絡(luò)的狀態(tài)存儲和轉(zhuǎn)發(fā)處理開銷線性增加。但是，DiffServ對數(shù)據(jù)流的分類和優(yōu)先級簡化會降低它提供服務(wù)質(zhì)量的靈活性和準(zhǔn)確性，使得QoS的支持粒度“變粗”。也就是說，DiffServ不能知道某一特定應(yīng)用的QoS的具體需求細(xì)節(jié)，它提供的QoS能力可能高于也可能低于應(yīng)用需求。并且，當(dāng)應(yīng)用程序愿意更改起初發(fā)出的QoS請求（增高或降低QoS能力）的時候，DiffServ無法知道這一情況，也無法與終端應(yīng)用進(jìn)行通信協(xié)商。
2.3 多協(xié)議標(biāo)簽交換(MPLS)
MPLS是一種可在多種第二層媒質(zhì)上進(jìn)行標(biāo)記交換的網(wǎng)絡(luò)技術(shù)，它的基本思想就是將第三層的IP路由技術(shù)與第二層的交換轉(zhuǎn)發(fā)技術(shù)相結(jié)合，為進(jìn)入網(wǎng)絡(luò)中的IP 數(shù)據(jù)包分配標(biāo)記，并通過對標(biāo)記的交換來實現(xiàn)IP 數(shù)據(jù)包的快速轉(zhuǎn)發(fā)。MPLS的主要特點是：支持面向連接的QoS；支持流量工程和多種網(wǎng)絡(luò)協(xié)議。MPLS 技術(shù)利用顯式路由功能大大增強了在IP網(wǎng)絡(luò)中實施流量工程的能力，MPLS 流量工程可以根據(jù)流的服務(wù)質(zhì)量需求選擇優(yōu)化的路由，也能在MPLS域內(nèi)進(jìn)行負(fù)荷均衡，因而在宏觀上提供了保障QoS的基礎(chǔ)。由于MPLS 在業(yè)務(wù)流聚合、邊緣路由器/核心路由器的劃分等概念上和DiffServ 極為相似，再加上MPLS本身的諸多優(yōu)點，因此MPLS技術(shù)是一種用來實現(xiàn)DiffServ的絕佳選擇。
3 模擬實驗
此業(yè)務(wù)是基于SIP平臺的多媒體會議，其中有一個變音的分支功能，主要用于改變用戶語音的音色。實驗平臺由兩個呼叫軟終端、兩個交換機、兩臺路由器和變音服務(wù)器組成，終端與交換機之間經(jīng)10baseT連接，交換機和路由器之間經(jīng)100baseT連接，路由器A、B之間的鏈路速率為5Mb/s，路由器A、C、B之間的鏈路速率為4Mb/s，語音服務(wù)采用帶靜音壓縮的GSM編碼方案，路由器采取FIFO模式處理各種業(yè)務(wù)；在綜合服務(wù)模型里，所有節(jié)點都支持RSVP，普通呼叫和變音業(yè)務(wù)的預(yù)留帶寬為2 048B/s和4 096B/s；在差分" title="差分">差分服務(wù)模型里，可以根據(jù)IP分組中的某個字段——差分服務(wù)碼點(DSCP)來標(biāo)示該分組的優(yōu)先級，交換機根據(jù)該標(biāo)示來確定應(yīng)該將分組發(fā)送哪個路由器。在DiffServ實例中，將普通呼叫映射為低優(yōu)先級的路由選擇，將變音業(yè)務(wù)映射為高優(yōu)先級的路由選擇，路由器接口采用WFQ模式；在MPLS模型中，在每兩個路由器之間建立TE隧道，路由器查找滿足帶寬需求的標(biāo)簽交換路徑，當(dāng)因硬件原因?qū)е滤淼啦煌〞r，路由器會自動啟用另一條滿足條件的隧道，對兩類業(yè)務(wù)分別定義轉(zhuǎn)發(fā)等價類，建立兩條隧道，普通呼叫和變音業(yè)務(wù)隧道的帶寬分別設(shè)置為64kb/s和128kb/s，所有緩沖區(qū)設(shè)為512KB，實驗網(wǎng)絡(luò)的拓?fù)浣Y(jié)構(gòu)如圖1所示。
?
服務(wù)器與客戶端首先要為變音作準(zhǔn)備工作，此時是一對一的協(xié)商，即雙方都要在接到對方的確認(rèn)后才能繼續(xù)發(fā)送消息，經(jīng)此過程后服務(wù)器才開始處理含有語音流的數(shù)據(jù)。服務(wù)器的緩沖區(qū)里第一次接收到的數(shù)據(jù)格式一般如表1所示。
?
對緩沖區(qū)里數(shù)據(jù)的處理方式有兩種，如圖2所示。
?
實驗的結(jié)果由圖3、4、5所示。
?
從實驗的結(jié)果可以看出：在一個綜合若干類業(yè)務(wù)的網(wǎng)絡(luò)中，如果再采取盡力而為的服務(wù)將是不明智的，它造成的端到端" title="端到端">端到端平均延遲總是最大的，且起伏動蕩也相對明顯；而在綜合服務(wù)實例中實行帶寬、緩沖區(qū)等資源預(yù)留，在MPLS流量工程中為兩種業(yè)務(wù)分別建立效率不同的隧道，這實質(zhì)上是保證了給各類業(yè)務(wù)提供相對固定的帶寬服務(wù)，只是帶寬因業(yè)務(wù)而異，因此兩類業(yè)務(wù)可以并行不悖，服務(wù)質(zhì)量均有提高，結(jié)果與預(yù)期相符；在Diffserv實例中，由于采取了優(yōu)先級策略和WFQ隊列方案，使得控制粒度精細(xì)，運作靈活，兩種業(yè)務(wù)的服務(wù)質(zhì)量都有大幅改善，其中變音業(yè)務(wù)被賦予最高優(yōu)先級，其端到端的時延是最小的。
從圖中也可看出算法B的運行效率要高于算法A，但比起上述幾種QoS策略所帶來的服務(wù)質(zhì)量的高低起伏來，似乎僅僅起到了推波助瀾的作用。由此看來業(yè)務(wù)邏輯中采用的算法固然會對其運作效率產(chǎn)生一定的影響，不過起決定作用的還是資源的配置及路由的優(yōu)化，這是提高服務(wù)質(zhì)量的根源所在。
當(dāng)前，傳統(tǒng)網(wǎng)絡(luò)向NGN的演進(jìn)已成大勢所趨。而NGN的QoS已入議事日程，它的進(jìn)步對整個下一代網(wǎng)絡(luò)的部署與實現(xiàn)都有重大的意義。VOIP是傳統(tǒng)PSTN網(wǎng)絡(luò)向下一代網(wǎng)絡(luò)演進(jìn)的第一階段，雖然它已經(jīng)有了一定的運營規(guī)模，但由于目前的種種技術(shù)限制，VOIP離NGN的目標(biāo)尚有一段距離，它的服務(wù)質(zhì)量問題也有待探討。本文對VOIP網(wǎng)絡(luò)中采用的一系列QoS策略進(jìn)行了實例分析，并對其實施應(yīng)用進(jìn)行了探討，為下一代網(wǎng)絡(luò)的規(guī)劃和優(yōu)化提供了參考依據(jù)。QoS策略的制訂,必須從整體系統(tǒng)和業(yè)務(wù)的角度出發(fā),落實到端到端，才能為NGN業(yè)務(wù)的開展提供有力的保證。
參考文獻(xiàn)
[1] ?謝希仁.計算機網(wǎng)絡(luò)(第四版)[M].北京：電子工業(yè)出版社，2003.
[2] ?趙慧玲. IP QOS 研究的現(xiàn)狀與發(fā)展趨勢[EB].?http://www.crc.net.cn,2003.
[3] ?趙慧玲，葉華. 以軟交換為核心的下一代網(wǎng)絡(luò)技術(shù)[M].?北京：人民郵電出版社, 2002.
[4]? METZ C Y, IP交換技術(shù)協(xié)議與體系結(jié)構(gòu)[M].北京：機械工業(yè)出版社, 1999.
[5] ?YD/T1071-2000. IP電話網(wǎng)關(guān)設(shè)備技術(shù)要求[S].
[6] ?林闖，單志廣，任豐原. 計算機網(wǎng)絡(luò)的服務(wù)質(zhì)量[M]. 北京:清華大學(xué)出版社，2004.
[7] ?戶田巖. 網(wǎng)絡(luò)服務(wù)質(zhì)量技術(shù)[M]. 北京：科學(xué)出版社，2003.
[8] ?GB20600-2006.Framing structure, channel coding and?modulation for digital television terrestrial broadcasting system[S]. 2006.
[9] ?BLAKE S. An architecture for differentiated services[EB/OL]. RFC2475,1998-12.
[10] AWDUCHE D, MALCOLM J, AGOGBUA J. Requirements ?for traffic engineering over MPLS[S]. RFC2702, 1999.
?