RM新时代网站-首页

您好,歡迎來電子發(fā)燒友網(wǎng)! ,新用戶?[免費(fèi)注冊]

您的位置:電子發(fā)燒友網(wǎng)>電子百科>通信技術(shù)>衛(wèi)星通信>

衛(wèi)星通信上的QoS分析

2010年03月13日 15:52 hljzzgx.com 作者:佚名 用戶評論(0

衛(wèi)星通信上的QoS分析

衛(wèi)星鏈路由于其固有的特點(diǎn)(長時延,非對稱環(huán)境)對QoS(QualityofService)提出新的要求和挑戰(zhàn),本文首先對兩種QoS策略進(jìn)行討論,然后對其在衛(wèi)星鏈路上的性能及以后研究的方向進(jìn)行了討論。

??? 關(guān)鍵詞衛(wèi)星通信區(qū)分服務(wù)資源預(yù)留協(xié)議CRED

??? 1、衛(wèi)星系統(tǒng)概述

??? GEO系統(tǒng)的衛(wèi)星位于地球赤道上35786km附近的地球同步赤道上,所以其單向傳輸時延在230-270ms之間,往返時延(roundtrIPdelay)長達(dá)540ms,約比地面鏈路上WAN的等待時間(latency)大一個數(shù)量級。衛(wèi)星鏈路的長時延增大了TCP端到端的時延,導(dǎo)致確認(rèn)信息的延緩。這種緩慢的反饋會減弱流量控制,降低了避免擁塞的性能,并會影響吞吐量。這樣就會造成大量的數(shù)據(jù)包停留在衛(wèi)星通信管道上,增加了包丟失概率,從而引起網(wǎng)絡(luò)的擁塞[1]。

??? 鏈路容易受到不同因素的影響(如干擾、衰落、陰影效應(yīng)和雨衰),因此會有很高的比特差錯率(BER)。大約為1O-6數(shù)量級,這遠(yuǎn)遠(yuǎn)高于高速有線媒質(zhì)(如光纖).高誤碼率嚴(yán)重削弱了衛(wèi)星信道可靠傳輸數(shù)據(jù)的性能,這是因為TCP是一個使用分組丟失來控制傳輸行為的丟失敏感協(xié)議,它無法區(qū)分由于傳輸錯誤造成的數(shù)據(jù)包錯誤還是由于擁塞造成的數(shù)據(jù)包丟失,對這兩種都無法確認(rèn),而被解釋成網(wǎng)絡(luò)擁塞的標(biāo)志。當(dāng)接收到一個損壞的數(shù)據(jù)包,即使沒有擁塞發(fā)生,窗口的大小隨即變?yōu)樵瓉淼囊话?,這就使得吞吐量大大減小。

??? 許多衛(wèi)星系統(tǒng)在前向和反向數(shù)據(jù)信道間有較大的帶寬不對稱性。從衛(wèi)星到地面的前向鏈路遠(yuǎn)大于反向鏈路??梢灾溃鄠€終端通過共享窄帶上行鏈路實(shí)現(xiàn)與衛(wèi)星的連接,這就可能導(dǎo)致?lián)砣?。在大多?shù)時間里上行鏈路傳輸?shù)氖羌兇獾?a target="_blank">ACK.而TCP是“selfclocking”:即。源端在接收到對應(yīng)已發(fā)數(shù)據(jù)的ACK之后發(fā)送新的數(shù)據(jù),這樣源端發(fā)送的新數(shù)據(jù)的速率和另一端返回的ACK的速率相匹配。可以理解為上行鏈路的ACK流速率控制著下行鏈路的吞吐量。在非對稱行鏈路上會出現(xiàn)下列問題:1)由于擁塞窗口的增加依靠ACK,因此,ACK的速率越低,擁塞窗口的增加就越慢,這就降低了慢啟動和擁塞避免的性能;2)由于反向信道的限制,可能使得ACK包出現(xiàn)擁塞和丟失,這也會導(dǎo)致吞吐量的降低。

??? 不對稱比率(返回路徑容量與前向路徑容量之比)大于ACK包尺寸于數(shù)據(jù)包尺寸之比時,反向鏈路較前向鏈路先達(dá)到容量值,從而造成擁塞,限制了前向鏈路的帶寬利用。這時會出現(xiàn)擁塞情況,造成ACK的延遲和導(dǎo)致不必要的重傳。

??? 2、服務(wù)質(zhì)量QoS(QualityofService)

??? 現(xiàn)有的互聯(lián)網(wǎng)所提供的是“盡量做好”best-effort的服務(wù)在這種服務(wù)模型下所有的業(yè)務(wù)流被“一視同仁”地公平地競爭網(wǎng)絡(luò)資源。網(wǎng)絡(luò)只需盡快的完成服務(wù),而對業(yè)務(wù)的可靠性、延遲等不能提供任何保證,隨著IP技術(shù)和網(wǎng)絡(luò)的發(fā)展,IP網(wǎng)正在從當(dāng)初單純傳送數(shù)據(jù)向可傳送數(shù)據(jù)、語音、活動/靜止圖像的多媒體網(wǎng)絡(luò)轉(zhuǎn)變。我們可以把傳輸?shù)臉I(yè)務(wù)分成兩類:實(shí)時業(yè)務(wù)和非實(shí)時業(yè)務(wù)。實(shí)時業(yè)務(wù)是指需要端到端的服務(wù)保證,對資源的持續(xù)要求較高的媒體流傳輸業(yè)務(wù)。這些業(yè)務(wù)對帶寬、延遲、延遲抖動都有特殊要求。主要包括語音、視頻傳輸?shù)?;非?shí)時業(yè)務(wù)是指那些對傳輸時延要求較低、只需盡量將數(shù)據(jù)包發(fā)送到目的地的業(yè)務(wù),內(nèi)容包括Email、Ftp、Web瀏覽等。

??? 我們關(guān)注的就是這些業(yè)務(wù)在衛(wèi)星通信網(wǎng)傳輸之前,如何根據(jù)它們的特性將它們區(qū)分。以便區(qū)別的傳送。這就是QoS解決方案,QoS研究目標(biāo)是如何有效的為用戶提供端到端的服務(wù)質(zhì)量和保證。它無法創(chuàng)造帶寬,只是根據(jù)需求和網(wǎng)絡(luò)狀況來管理帶寬。具體可以量化為傳輸延遲、抖動、丟包率、帶寬要求、吞吐量、業(yè)務(wù)可用性等指標(biāo)。為了解決QoS問題,IETF提出了下面幾種服務(wù)模型和機(jī)制:集成服務(wù)和資源預(yù)留協(xié)議(IntServ/RSVP)、區(qū)分服務(wù)(DiffServ)、和多協(xié)議標(biāo)簽交換(Multiprotocollabelswitching,MPLS),本文主要討論資源預(yù)留協(xié)議和區(qū)分服務(wù)在衛(wèi)星鏈路上的應(yīng)用。

??? 2.1資源預(yù)留協(xié)議(Resourcereservationprotocol)

??? Intserv/RSVP服務(wù)模型在RFC1633中進(jìn)行了定義,其基本思想就是在傳送數(shù)據(jù)之前,根據(jù)業(yè)務(wù)的QoS需求進(jìn)行網(wǎng)絡(luò)資源預(yù)留,從而為該數(shù)據(jù)流提供端到端的QoS保證,資源預(yù)留協(xié)議是核心部分。它是一種信令協(xié)議,用來通知網(wǎng)絡(luò)節(jié)點(diǎn)預(yù)留資源,如果資源預(yù)留失敗,RSVP協(xié)議會向主機(jī)返回拒絕消息。使用RSVP信令建立數(shù)據(jù)發(fā)送路徑為業(yè)務(wù)流預(yù)留資源的過程為:在傳輸數(shù)據(jù)之前,發(fā)送端先向接收端發(fā)送一個對所傳輸業(yè)務(wù)流業(yè)務(wù)描述的PATH消息,它包括了數(shù)據(jù)包的目的地址和業(yè)務(wù)特征和和業(yè)務(wù)規(guī)格(所需的帶寬上下限、延遲、抖動等)。PATH消息在網(wǎng)絡(luò)連接的每個路由器上依次傳送。這樣就建立了一個路徑軟狀態(tài)。當(dāng)接收端接收到一個PATH消息后,它將根據(jù)業(yè)務(wù)特點(diǎn)和QoS來計算出所需的資源,并且沿相反路徑發(fā)送一個資源預(yù)留請求RESV消息,中間路由器在接受到RESV消息后,調(diào)用程序來決定是否接收該業(yè)務(wù)流。如果接受,就會分配相應(yīng)的帶寬和緩沖空間并記錄該流的相關(guān)狀態(tài)消息,然后繼續(xù)上傳該RESV消息。如果拒絕,則向接收端返回錯誤信息使接收端終止呼叫。最后的路由器接受到RESV消息并接受該請求時,它向接收端發(fā)回一個ACK。則在整個鏈路上逐點(diǎn)建立了業(yè)務(wù)流的資源預(yù)留軟狀態(tài)(softstate)。

??? 2.2區(qū)分服務(wù)(differentiatedservices)

??? 區(qū)分服務(wù)的思想就是將用戶的數(shù)據(jù)流按照服務(wù)質(zhì)量要求來劃分等級,在網(wǎng)絡(luò)出現(xiàn)擁塞的時候,級別高的數(shù)據(jù)流在排隊和占用資源時后擁有更高的優(yōu)先權(quán)[3]。

??? 實(shí)際上,區(qū)分服務(wù)提供了一種在一個子網(wǎng)絡(luò)域內(nèi)實(shí)施QoS的框架結(jié)構(gòu)。當(dāng)業(yè)務(wù)流到達(dá)域的邊界路由器時,邊界節(jié)點(diǎn)根據(jù)用戶的流規(guī)格、和用戶與Internet服務(wù)供應(yīng)商簽訂的服務(wù)等級協(xié)定SLA(service1evelagreement)對到達(dá)的業(yè)務(wù)流進(jìn)行分類、整形、標(biāo)記、聚合為不同的流聚集。將流聚集信息寫在IP包頭中的區(qū)分服務(wù)標(biāo)記域中(DSfield)即:DSCP(differ code point)。每種DSCP對應(yīng)一種“逐跳行為”(Per-hop-behavior,PHB),這里的PHB本質(zhì)上是一種相對優(yōu)先級機(jī)制,其描述單個節(jié)點(diǎn)為特定流資源分配資源的方式。目前已定義的PHB有加速性轉(zhuǎn)發(fā)(Expedited forwarding)、確保型轉(zhuǎn)發(fā)(assured forwarding)、缺省型BE(best effort)、兼容ip優(yōu)先級的類選擇型CS(Class selector)。

??? 核心路由器在調(diào)度IP包時以流聚集為服務(wù)對象。根據(jù)IP包頭的DSCP,具有相同的DSCP的業(yè)務(wù)流組成宏流。核心路由器中保存簡單的DSCP和PHB機(jī)制。不同的DSCP提供不同的轉(zhuǎn)發(fā)服務(wù)質(zhì)量。

??? 目前,區(qū)分服務(wù)提供下面幾種服務(wù)類型:

??? 1)獎賞服務(wù)(Premiumservice,Ps),為用戶提供低延時、低丟失率及保證帶寬的端到端或者是網(wǎng)絡(luò)邊界到邊界的傳輸服務(wù)。這種“三低一保證”服務(wù)承諾使得用戶可以享受類似專線的服務(wù)質(zhì)量,因此獎賞服務(wù)也稱為“虛擬專線”服務(wù),這是目前所定義的服務(wù)級別最高的區(qū)分服務(wù)種類。

??? 2)確保服務(wù)AS(assuredservice),其出發(fā)點(diǎn)是無論是否擁塞,都能保證用戶占有預(yù)約的最低限量的帶寬;其著眼點(diǎn)是帶寬和丟包率,而不太注重延遲和抖動。只要采用簡單的標(biāo)記和丟棄機(jī)制就能實(shí)現(xiàn)IPQoS,實(shí)現(xiàn)機(jī)制簡單。

??? 3、對衛(wèi)星鏈路的QoS分析

??? 3.1長延時問題

??? 在衛(wèi)星鏈路上的長延時會出現(xiàn)大量的未被確認(rèn)的包停留在鏈路管道上,如果我們采用RSVP協(xié)議,通過我們上面介紹的工作原理可以發(fā)現(xiàn),在傳輸業(yè)務(wù)流之前,必須建立傳輸路徑。在鏈路上傳輸PATH消息并等待收端的RESV的確認(rèn)消息返回。這無疑增加了用戶的等待時間。大大增加了短時流在衛(wèi)星網(wǎng)絡(luò)中的傳播時間,降低了網(wǎng)絡(luò)的他吞吐量;而在區(qū)分服務(wù)模型中,我們可以通過設(shè)置ISP和用戶之間的服務(wù)等級協(xié)定SLA。通過對某些特定的業(yè)務(wù)(實(shí)時業(yè)務(wù))設(shè)置相對高的優(yōu)先級。通過在衛(wèi)星邊界路由器的數(shù)據(jù)包的整形和相對高的優(yōu)先級。我們可以優(yōu)化實(shí)時業(yè)務(wù)在長時延鏈路的傳輸性能。

??? 3.2帶寬不對稱

??? 在衛(wèi)星鏈路上帶寬的不對稱,反向鏈路的延時和擁塞影響ACK的正確傳輸,如果采用RSVP協(xié)議,可能使情況變得更糟,因為在網(wǎng)絡(luò)中每一個路由器的預(yù)流信息是“軟”的,必須由接收者周期的更新。這樣?,F(xiàn)有RESV更新、新、舊業(yè)務(wù)的ACK在反向信道的傳輸,增加了擁塞的可能,所以,我們可以得出結(jié)論,RSVP可能加重帶寬不對稱帶來的煩惱。

??? 在使用區(qū)分服務(wù)的情況下,我們可以賦予ACK更高的優(yōu)先級。這樣,他可以在其余的業(yè)務(wù)流之前傳送,保證了ACK的準(zhǔn)確傳送。

??? 3.3誤碼率高

??? 這兩種QoS解決方案都不能有效的解決這個問題。但是我們可以在鏈路層采用更加強(qiáng)有力的前向糾錯方案,這樣就會使可用帶寬減小,我們知道與RSVP協(xié)議相比。區(qū)分服務(wù)占有的網(wǎng)絡(luò)資源相對較少,這使得我們傾向使用區(qū)分服務(wù)協(xié)議。

??? 另外,在衛(wèi)星鏈路上采用資源預(yù)留協(xié)議就必須提供更高的帶寬。如果過多用戶都要求資源預(yù)留,這將大大增加路由器的負(fù)擔(dān),因為狀態(tài)信息隨業(yè)務(wù)流數(shù)量增長而增長,沿途的路由器要為每個數(shù)據(jù)流都維持一個“軟狀態(tài)”,而路由器的存儲容量有限,可以保存軟狀態(tài)信息是由限的。而區(qū)分服務(wù)只在內(nèi)部節(jié)點(diǎn)進(jìn)行簡單的調(diào)度轉(zhuǎn)發(fā),流狀態(tài)信息的保存和流監(jiān)控的實(shí)現(xiàn)等只在邊界節(jié)點(diǎn)進(jìn)行。并且其服務(wù)對象使流聚集而非單個流。還有,我們可以動態(tài)和靈活的對業(yè)務(wù)流進(jìn)行分類和整形。所以我們可以得出結(jié)論,區(qū)分服務(wù)能夠在衛(wèi)星鏈路充分利用帶寬,提供相對較好的服務(wù)質(zhì)量保證。

??? 下面我們研究區(qū)分服務(wù)的確保服務(wù)類型。它通常采用RED隊列管理機(jī)制[2]。RED機(jī)制通過隨即丟棄數(shù)據(jù)分組??刂破骄犃虚L度,避免網(wǎng)絡(luò)擁塞與全網(wǎng)同步重發(fā)。能夠有效的減輕緩沖溢出從而增加衛(wèi)星吞吐量;RIO是RED的改進(jìn)算法:邊界路由器監(jiān)視每個進(jìn)入網(wǎng)絡(luò)的用戶數(shù)據(jù)流,根據(jù)它們的服務(wù)規(guī)格對包進(jìn)行標(biāo)識,預(yù)約帶寬以內(nèi)的標(biāo)為IN(inprofile),超出的標(biāo)為OUT(outprofile)。在擁塞的路由器上,OUT包被丟棄的概率要大于IN包,從而在一定程度上保護(hù)IN包。WRED是CISCO公司提出的一種支持區(qū)分服務(wù)的AQM機(jī)制。與RIO一樣,WRED基本思路也是在IP包頭按照某種策略進(jìn)行標(biāo)記,丟包優(yōu)先級基于該標(biāo)記。

??? 可以知道,我們可以根據(jù)用戶要求提供的服務(wù)質(zhì)量。對某些業(yè)務(wù)流(如實(shí)時業(yè)務(wù)、需要連續(xù)或交互的業(yè)務(wù)流)設(shè)置較高的優(yōu)先級。從而保證該業(yè)務(wù)流的傳輸。這樣。在衛(wèi)星鏈路上。我們能夠為所有的應(yīng)用程序設(shè)定服務(wù)次序。西安電子科技大學(xué)孫恩昌博士的碩士畢業(yè)論文的CRED算法就是典型的區(qū)分服務(wù)模型算法,其思想可以概括為,區(qū)分不同的業(yè)務(wù)(TCP、UDP),區(qū)分不同業(yè)務(wù)的不同階段(TCP的慢啟動和擁塞避免階段)或帶寬波動程度(UDP業(yè)務(wù))對于其給定的拓?fù)浣Y(jié)構(gòu),我們將其應(yīng)用在衛(wèi)星鏈路上,獲得了極大的成功。

??? 可以看出,對于TCP業(yè)務(wù),CRED的平均吞吐量明顯高于FRED和RED的,而對于音頻、視頻等多媒體業(yè)務(wù),CRED的平均吞吐量略高于FRED,但該兩者的吞吐量要高于RED的。對于UDP-others和UDP-large,CRED的吞吐量最低,其次是FRED,RED最高。總之,由以上仿真圖形可以看出,CRED通過對業(yè)務(wù)置不同優(yōu)先級,能夠保證衛(wèi)星鏈路上較好的傳輸TCP業(yè)務(wù),并且音頻、視頻業(yè)務(wù)也能夠得到較好的傳輸。

??? 4、結(jié)論

??? 在本文中,我們首先介紹了網(wǎng)絡(luò)QoS保證中常見的兩種措施:RSVP(資源預(yù)留協(xié)議)和DiffServ(區(qū)分服務(wù))的詳細(xì)概念,并且分析了各自在衛(wèi)星系統(tǒng)上的優(yōu)劣之處。我們注意到,在RSVP架構(gòu)下,所有的信息流經(jīng)過的節(jié)點(diǎn)都需要對每一個信息流保持一個狀態(tài),并且作監(jiān)控和管理。這將造成延展性(scaling)問題。

??? 區(qū)分服務(wù)在開始預(yù)算了幾種服務(wù),將封包分類一起聚集處理,提供相同的品質(zhì)保證,將復(fù)雜的流量調(diào)節(jié)功能放在網(wǎng)絡(luò)邊界的路由器里。這樣加快了網(wǎng)絡(luò)傳輸?shù)乃俣取?/P>

??? 結(jié)合衛(wèi)星網(wǎng)絡(luò)的固有特點(diǎn),作者通過詳細(xì)的分析,認(rèn)為區(qū)分服務(wù)更加適合在衛(wèi)星網(wǎng)絡(luò)中提供較為優(yōu)質(zhì)的QoS。

??? 參考文獻(xiàn)

??? 1J.Touch,S.Ostermann,D.Glover,et.al.“OngoingTCPResearch Related to Satellites”,RFC 2760,IETF,F(xiàn)ebruary 2000

??? 2姜明.浙江大學(xué)Internet主動式隊列管理機(jī)制綜述文章來源:賽迪網(wǎng)2002年11月08日S.Blake,D.Black,M.Carlson,E.Davies,Z.Wang,andW.Weiss,“An Architecture for Differentiated Services,”RFC2475,Dicembre 1998.

非常好我支持^.^

(0) 0%

不好我反對

(0) 0%

( 發(fā)表人:admin )

      發(fā)表評論

      用戶評論
      評價:好評中評差評

      發(fā)表評論,獲取積分! 請遵守相關(guān)規(guī)定!

      ?
      RM新时代网站-首页