深空通信網(wǎng)絡(luò)體系結(jié)構(gòu)及相關(guān)研究問題.doc_第1頁
深空通信網(wǎng)絡(luò)體系結(jié)構(gòu)及相關(guān)研究問題.doc_第2頁
深空通信網(wǎng)絡(luò)體系結(jié)構(gòu)及相關(guān)研究問題.doc_第3頁
深空通信網(wǎng)絡(luò)體系結(jié)構(gòu)及相關(guān)研究問題.doc_第4頁
深空通信網(wǎng)絡(luò)體系結(jié)構(gòu)及相關(guān)研究問題.doc_第5頁
已閱讀5頁,還剩5頁未讀, 繼續(xù)免費閱讀

下載本文檔

版權(quán)說明:本文檔由用戶提供并上傳,收益歸屬內(nèi)容提供方,若內(nèi)容存在侵權(quán),請進行舉報或認領(lǐng)

文檔簡介

一, 深空通信網(wǎng)絡(luò)結(jié)構(gòu)IPN結(jié)構(gòu)及各個部分的特點空間技術(shù)的發(fā)展使火星探測等深空科學任務(wù)成為了現(xiàn)實。未來的空間探測任務(wù)會需要在行星,月球,衛(wèi)星,小行星,宇宙飛行器,和登陸車等之間進行通信。這些任務(wù)會產(chǎn)生大量的科學數(shù)據(jù),這些數(shù)據(jù)需要高速可靠的在航天器之間傳遞并傳送給地球。為了實現(xiàn)科學考察數(shù)據(jù)的有效傳輸和可靠的導航通信,NASA提出了發(fā)展下一代空間互聯(lián)網(wǎng)體系結(jié)構(gòu),下一代的深空網(wǎng)絡(luò)應(yīng)該是深空星際網(wǎng)絡(luò)的互聯(lián)網(wǎng),定義為星際互聯(lián)網(wǎng)IPN(InterPlaNetary Network)。星際互聯(lián)網(wǎng)可以提供科學考察數(shù)據(jù)的傳輸服務(wù)和未來深空探測任務(wù)的航天器與人造衛(wèi)星的導航服務(wù)。星際互聯(lián)網(wǎng)的可以提供的主要應(yīng)用包括:l 時間不敏感的科考數(shù)據(jù)傳輸。實現(xiàn)從地外行星和月球收集到的大量科考數(shù)據(jù)在空間中的實體間互相通信。l 時間敏感的科考數(shù)據(jù)傳輸。將大量的本地視頻和音頻數(shù)據(jù)傳輸給地球,在軌機器人,甚至是在軌的宇航員。l 任務(wù)狀態(tài)遙測數(shù)據(jù)傳遞。將任務(wù),飛行器或登錄器的狀態(tài)和健康報告?zhèn)鬏數(shù)街笓]中心或其它結(jié)點上。這個應(yīng)用需要一種周期性或事件驅(qū)動的不可靠的傳輸服務(wù)。l 指令和控制。另一種星際互聯(lián)網(wǎng)的重要應(yīng)用是對在軌單元的命令和控制。閉環(huán)命令和控制可以包括無線結(jié)點的直接或多跳通信,比如,地球基站控制在行星表面漫游的探測器,或者接近的結(jié)點,比如在行星軌道上控制登錄器。目前的internet應(yīng)用已經(jīng)非常廣泛,在internet技術(shù)的基礎(chǔ)上構(gòu)建空間互聯(lián)網(wǎng)既可以節(jié)省開支又有高質(zhì)量服務(wù)。因此,大多數(shù)深空探測用的網(wǎng)絡(luò)結(jié)構(gòu)都是基于internet技術(shù)的。NASA的空間互聯(lián)網(wǎng)通用結(jié)構(gòu)包括以下的結(jié)構(gòu)單元:l 骨干網(wǎng)絡(luò)。包括NASA的地面網(wǎng)絡(luò)和空間網(wǎng)絡(luò),NASA的以太網(wǎng)和虛擬私有網(wǎng)絡(luò),因特網(wǎng)和商用或者國外的通信系統(tǒng)。l 接入網(wǎng)絡(luò)。宇宙飛船和登陸車及其內(nèi)部網(wǎng)絡(luò)與骨干網(wǎng)的通信接口。l 宇宙飛船之間的網(wǎng)絡(luò)。宇宙飛船的一個飛行編隊或集群之間的網(wǎng)絡(luò)。l 臨近網(wǎng)絡(luò)。在無線多跳自組織網(wǎng)絡(luò)adhoc中分布的空間飛行器,登陸車,傳感器等??臻g因特網(wǎng)在被定義成因特網(wǎng)的網(wǎng)絡(luò),它用一個專用的長距離無線鏈路的深空骨干網(wǎng)絡(luò)與因特網(wǎng)連接。因特網(wǎng)或者因特網(wǎng)相關(guān)的協(xié)議可以用來組成低延時,環(huán)繞地球的相對低噪音環(huán)境的,飛行器內(nèi)部,環(huán)繞其它星球的網(wǎng)絡(luò)等本地網(wǎng)絡(luò)。在不同的環(huán)境中應(yīng)該設(shè)計特殊的協(xié)議以適應(yīng)特殊環(huán)境的限制。一個新的覆蓋協(xié)議的概念稱為“打包傳遞”,它將一些異構(gòu)的因特網(wǎng)聯(lián)系成一起,完成本地協(xié)議不能完成的功能。星際互聯(lián)網(wǎng)結(jié)構(gòu)如圖1中表示,包括星際骨干網(wǎng)絡(luò),星際內(nèi)部網(wǎng)絡(luò)和行星網(wǎng)絡(luò)。l 星際骨干網(wǎng)絡(luò)。它提供地球,外部空間行星,月球,衛(wèi)星和處于行星間引力穩(wěn)定點上的中繼站之間的一個通用通信設(shè)施。它包括長距離基本單元之間的數(shù)據(jù)鏈路(直接鏈路或多跳路徑)。行星際骨干網(wǎng)絡(luò)鏈路的最重要的特點如下述: 極長的傳播延時。深空通信鏈路具有極端長的傳播延時。長時延。例如:多數(shù)情況下低軌系統(tǒng)往返時延是40到50毫秒,中軌系統(tǒng)是120到260毫秒,地球同步衛(wèi)星軌道大約550毫秒,并且還受到星間路由選擇、星上處理以及緩存等因素的影響。而在星際骨干網(wǎng)中往返時延更高。例如:從地球到火星的距離在6000萬公里以上,傳輸?shù)耐禃r延從8到40分鐘之間,其它如木星和冥王星到地球的RTT范圍分別是81. 6到133. 3分鐘和593. 3到1044. 4分鐘之間。 高鏈路誤碼率。現(xiàn)有的衛(wèi)星信道誤碼率(Bit Error Ratios, BER)大約是10-6,最壞情況為10-4。在骨干網(wǎng)誤碼率更高,例如月球距地球約38萬公里,而其它行星距地球都在幾千萬公里以上。由于距離遠,使信號衰減造成信噪比降低,另外,某些行星存在的電磁輻射引起的干擾,使信噪比進一步下降,導致BER一般只能達到10-1數(shù)量級。 鏈路暫時中斷。因為行星的運動,小行星或者宇宙飛船的干涉造成的光線的不可見,周期性的鏈路中斷很可能發(fā)生。 不對稱帶寬。在一般情況下,前向和反向信道帶寬容量之比約為1000:1。在某些情況下,甚至是單向通信.l 行星際外部網(wǎng)絡(luò)。他包括在行星見的深空飛行的宇宙飛船,傳感器結(jié)點群,空間站群等。一些行星際外部網(wǎng)絡(luò)的結(jié)點還擁有遠距離通信的能力。l 行星網(wǎng)絡(luò)。包括行星衛(wèi)星網(wǎng)絡(luò)和行星表面網(wǎng)絡(luò)。如圖2中所描述。這種體系結(jié)構(gòu)可以在所有外部空間行星上實現(xiàn),提供了行星的衛(wèi)星和地面之間的互連接和互操作。 行星衛(wèi)星網(wǎng)絡(luò)。環(huán)繞行星飛行的衛(wèi)星可以在地球和外部空間行星之間的中繼服務(wù),同樣也為行星表面的單元進行通信和導航服務(wù)【55】。一些行星表面單位有跟衛(wèi)星通信的能力,報告本地地形結(jié)構(gòu),從衛(wèi)星接收指令和數(shù)據(jù)。行星衛(wèi)星網(wǎng)絡(luò)包括環(huán)行衛(wèi)星之間的鏈路,衛(wèi)星和地面單元之間的鏈路。它包括圖2中所述的多個層次,提供如下服務(wù):地球和行星之間的存儲和中繼服務(wù),執(zhí)行任務(wù)的單元之間的中繼服務(wù)和行星表面網(wǎng)絡(luò)的位置管理。 行星表面網(wǎng)絡(luò)。它提供了漫游者和登陸車等行星表面單元之間的通信服務(wù),他們可以與衛(wèi)星進行連接。他們還提供了行星表面的能力穩(wěn)定的無線骨干網(wǎng)絡(luò)。此外,行星表面網(wǎng)絡(luò)還包括不能直接與衛(wèi)星通信的行星表面單元。這些單元一般是由傳感器和氣球等,以集群方式分散分布組成一個無線多跳自組織網(wǎng)絡(luò)。如圖2示。目前,空間站和衛(wèi)星已經(jīng)部署了,可以很容易的整合到星際骨干網(wǎng)絡(luò)中去。同時,在不遠的將來,未來科學研究在深空中部署的傳感器結(jié)點就可以連接到星際骨干網(wǎng)絡(luò)上。根據(jù)【9】的說法,為火星表面探測任務(wù)計劃好的一些科學設(shè)備是為了深空探測的傳感器結(jié)點。這些設(shè)備可以根據(jù)星際網(wǎng)絡(luò)的結(jié)構(gòu)進行組織。這些設(shè)備所處的探測區(qū)域被稱為部落區(qū)域。在每個部落區(qū)域中都可以建立星際表面網(wǎng)絡(luò)。總的來說,圖1和2描述的行星際因特網(wǎng)體系結(jié)構(gòu)是被分解成了不同的子網(wǎng)。每個子網(wǎng)面臨不同的挑戰(zhàn),有自己特點的要求。因此需要有一個通用的協(xié)議棧來將不同的部分整合起來,將陸地上的因特網(wǎng)連接到星際互聯(lián)網(wǎng)中。同時,它也給開發(fā)適應(yīng)每個子網(wǎng)特殊環(huán)境的協(xié)議留下了很大的空間。二, CCSDS和DTN Bundle三, 傳輸層l 傳輸層的功能對于行星際因特網(wǎng)科考數(shù)據(jù)的可靠傳輸和多媒體信息的及時傳遞都是必要的。在圖1中所示的行星際因特網(wǎng)的結(jié)構(gòu)體系元素中,行星際骨干網(wǎng)絡(luò)是可靠傳輸和多媒體傳輸?shù)淖畲罄щy,它對整個行星際因特網(wǎng)的表現(xiàn)起著重要作用?,F(xiàn)有的為陸地,衛(wèi)星,無線和多跳自組織網(wǎng)絡(luò)的傳輸層協(xié)議可以通過一些適當?shù)男薷氖蛊鋺?yīng)用在圖1示的行星際外部網(wǎng)絡(luò)和行星網(wǎng)絡(luò)中。然而,行星際因特網(wǎng)面臨的挑戰(zhàn)需要特別制定的新的傳輸層協(xié)議來解決。4.1 行星際骨干網(wǎng)絡(luò)的可靠數(shù)據(jù)傳輸4.11 相關(guān)工作實現(xiàn)行星際因特網(wǎng)滿足深空任務(wù)通信的需求,現(xiàn)有的可靠傳輸協(xié)議在深空通信網(wǎng)絡(luò)的表現(xiàn)都很差。造成這種性能降低的主要原因就是深空鏈路的極高的延時。這是因為目前TCP協(xié)議在慢啟動和擁塞避免算法中使用的基于窗口的機制。在慢啟動算法中,擁塞窗口大小(W)直到慢啟動閾值(WSS)之前,每收到一個ACK增加一,此時W WSS。然而,這種方式持續(xù)很長時間浪費帶寬,持續(xù)時間與傳播延時成正比。如果WSS =20,RTT=20分鐘,慢啟動在120分鐘內(nèi)都不能完全的使用全部帶寬。這種低效率的利用鏈路帶寬的基于窗口的機制在慢啟動算法中也存在,此時WWSS。TCP的源端每一個RTT時間才增加1.如圖6所示,目前的基于窗口的TCP協(xié)議在鏈路帶寬為1MB/s,丟包率p=10-3,RTT=40分鐘時,只能達到10byte/s的吞吐量。換句話說,在連接建立階段,整個深空鏈路基本上沒有被利用。注意到RTT=40是地球和火星的通信鏈路的RTT范圍之內(nèi)的,基于所處軌道位置,約8.5-40分鐘。此外,目前的TCP協(xié)議是針對有線鏈路設(shè)計的,假定誤碼率是可忽略的。因此,基于丟包的擁塞探測機制就造成了無謂的速率瓶頸并導致在行星際骨干網(wǎng)絡(luò)中嚴重的吞吐量降低。近幾年為了解決在無線鏈路錯誤造成的吞吐量降低做了很多研究工作。然而,這些解決方案不能直接應(yīng)用于行星際骨干網(wǎng)絡(luò),原因是極高的傳播延時和前面所述的特性放大了問題的影響?;谛l(wèi)星鏈路提出了很多傳輸層協(xié)議,衛(wèi)星鏈路也有高帶寬延時積和高誤碼率。不過,這些研究幾乎都是對于地球同步軌道GEO衛(wèi)星鏈路的,典型的RTT大概是550ms,相對與深空通信鏈路的RTT小的很多。此外,由于鏈路中斷造成的丟包也同樣會誤導基于丟包的擁塞控制機制。在【53】,開發(fā)了為解決因為移動而導致的信號丟失的對TCP的擴展。然后,深空鏈路中的鏈路中斷的情形由于極高的傳播延時而更加復(fù)雜,因此【53】中的解決方案并不能直接應(yīng)用。行星際因特網(wǎng)傳輸協(xié)議還面臨很多別的挑戰(zhàn)需要去解決。如下:l 延遲的反饋。TCP期望對鏈路狀態(tài)做出反應(yīng)。這種期望在長延時環(huán)境中造成了問題,因為TCP使用端到端的信號作為它的控制回路。RTT越長,源端接收到的關(guān)于鏈路狀態(tài)的信息就越晚。因此,基于這樣過去時的信息的擁塞控制機制可能不會導致正確的行為。因此對瞬時丟包情況做出反應(yīng)的擁塞控制機制不會在大延時鏈路中作出合適的反應(yīng)。l 緩沖區(qū)大小。為了保證100%的可靠傳輸,重傳機制是不可避免的。然而,這就帶來了可觀的內(nèi)存容量的要求。例如,傳輸協(xié)議需要為RTT=20和平均發(fā)送速率為1MB/s的鏈路準備1.2GB的緩存。現(xiàn)在對深空背景通信網(wǎng)絡(luò)傳輸層協(xié)議的研究已經(jīng)很活躍。Space Communications Protocol Standards-Transport Protocol(SCPS-TP)是CCSDS為了深空通信而開發(fā)的TCP的擴展集合。SCPS-TP是為了滿足目前的通信環(huán)境和將來的空間任務(wù)而設(shè)計的。SCPS-TP是對目前的TCP協(xié)議進行一些修改和擴充來解決深空通信中的鏈路錯誤,不對稱帶寬和不持續(xù)連接等問題的。它可以根據(jù)任務(wù)的通信需求提供完整的,盡全力的最小限度的可靠性。SCPS-TP的能力基本上是目前TCP協(xié)議的結(jié)合體,而TCP已經(jīng)顯示并不能滿足星級骨干網(wǎng)絡(luò)的要求。例如,使用Vegas擁塞控制的SCPS-TP使用基于窗口的機制和使用了慢啟動算法。盡管使用基于速率的SCPS-TP正在開發(fā)當中,它不使用擁塞控制機制,通過用戶選擇的固定速率發(fā)送數(shù)據(jù)。另一方面,SCPS-TP使用TCP-Vegas使用基于RTT變化的擁塞決定機制。然而,因為TCP-Vegas的基于窗口的本質(zhì),它不能夠完全的使用鏈路帶寬,因為變化的RTT,它也不能感知擁塞。因此,基于RTT的變化的擁塞避免機制并不能提供很好的擁塞控制功能。此外,由于極高的延時,RTT的變化并不能精確的衡量,因此作為結(jié)果,擁塞控制行為也可能不精確。在【29】,CFDP也是用CCSDS開發(fā)的。這個協(xié)議可以在深空鏈路中達到可靠的文件傳輸。然而,它也不能解決如上的困難,它也不是一個擁有在行星際因特網(wǎng)實現(xiàn)高數(shù)據(jù)速率可靠傳輸功能的傳輸層協(xié)議。在【94】,介紹了包裹協(xié)議來解決不連續(xù)連接,大而可變的延遲和高誤碼率。如圖4所示,包裹層協(xié)議在應(yīng)用層和底層協(xié)議之間,在延時可容忍網(wǎng)絡(luò)中表現(xiàn)為一個基于保管的存儲和轉(zhuǎn)發(fā)方式。此外,這種方法中間路由器有很大的存儲空間來儲存數(shù)據(jù)。需要的存儲空間大小隨著鏈路延時的變大和發(fā)送數(shù)據(jù)速率的變快而增大。而且,如此巨大的緩存也需要有效和快速的緩存管理機制來防止傳輸被存儲轉(zhuǎn)發(fā)機制所影響。基于包裹層的存儲和轉(zhuǎn)發(fā)機制,DTN方法結(jié)合了捆綁的ARQ和捆綁的擁塞控制概念通過本地重傳和在區(qū)域內(nèi)擁塞控制來提供可靠傳輸,也就是在本地節(jié)點之間而不是端到端之間進行可靠和擁塞控制。盡管這種方法可以在不連續(xù)連接的鏈路上實現(xiàn)可靠傳輸,它還需要一個傳輸層協(xié)議,也是為了解決同樣的挑戰(zhàn),在兩個行星際因特網(wǎng)節(jié)點之間達到高吞吐量的包裹傳輸。在【45】,介紹了長距離傳輸協(xié)議(LTP)在包裹節(jié)點之間來傳輸包裹。LTP是目前正在開發(fā)中的協(xié)議,在【113】中描述,作為一個鏈路層的ARQ添加一些相關(guān)的CFDP文件傳輸協(xié)議的功能,而不是類似于TCP的傳輸協(xié)議。4.1.2 TP-Planet在【2】中,介紹了一個行星際因特網(wǎng)的傳輸協(xié)議,TP-Planet。TP-Planet是為了行星際骨干網(wǎng)絡(luò)而開發(fā)的,源端和接收器節(jié)點基本上都是行星際骨干網(wǎng)絡(luò)的節(jié)點,比如環(huán)繞行星的中繼衛(wèi)星或者有直接深空通信能力的地面站。它在因特網(wǎng)協(xié)議層IP之上,不需要對目前TCP/IP協(xié)議簇底層協(xié)議做任何修改。TP-Planet可以作為傳輸層協(xié)議使用在現(xiàn)行CCSDS協(xié)議棧和DTN包裹協(xié)議棧中。TP-Planet協(xié)議主要由初始狀態(tài)和穩(wěn)定狀態(tài)兩個新算法組成。1. 初始狀態(tài)。為了避免慢啟動算法對性能的影響,TP-Planet的初始狀態(tài)算法,包括兩個主要部分,直接啟動和跟隨增加。目的就是在可控制的形式下盡可能快的獲取可用鏈路資源。2. 新的基于速率的適應(yīng)AIMD機制?;谒俾实膿砣刂茩C制相對于基于窗口的機制對于過大的延時有更大的魯棒性。3. 新的擁塞控制。為了解決由于行星際骨干鏈路高誤碼率而導致的性能降低,TP-Planet在穩(wěn)定狀態(tài)實施了一個新的擁塞探測和控制算法。TP-Planet源端同事發(fā)出低和高優(yōu)先級的NIX段,比數(shù)據(jù)包要小,40字節(jié)。假定通路上的路由器都可以根據(jù)優(yōu)先級排隊,低優(yōu)先級NIX段的高丟失率就可以認為是擁塞的信號。節(jié)點接收器周期性的發(fā)回低優(yōu)先級的Nlow和高優(yōu)先級的NHigh接受到的數(shù)目。他們的比率=(Nlow/NHigh)由預(yù)先設(shè)定的閾值來測試,i和d,之后數(shù)據(jù)傳輸速率S通過圖7來增加或減少?!?】4. 暫時中斷狀態(tài)。為了減少暫時中斷的情況對吞吐量的影響,TP-Planet在協(xié)議行為中加入了了暫時中斷狀態(tài)程序。暫時中斷行為可以在【2】中看到。為了提供可靠傳輸,SACK選項被TP-Planet用了應(yīng)對突發(fā)的丟包。因為可能在很長的中斷狀態(tài)期間SACK選項域的SACK塊的數(shù)目不夠,TP-Planet還包括了超時機制。5. 延時的SACK。為了解決行星際骨干鏈路中不對稱帶寬的問題,TP-Planet使用了延時SACK的機制,降低了反向信道的流量,避免在反向信道上發(fā)生擁塞。在這個機制中,源端用一個延時因子d來控制發(fā)送SACK包。當出現(xiàn)一個新的丟包時,接收方立即發(fā)送SACK包。以這種方式,TP-Planet可以在行星際骨干鏈路上控制反向信道的流量。如【2】示,通過仿真實驗,TP-Planet在行星際骨干鏈路中提供了高的吞吐量表現(xiàn)解決了問題。42行星際骨干網(wǎng)絡(luò)中的多媒體傳輸除了可靠傳輸數(shù)據(jù),多媒體流量也是行星際因特網(wǎng)的總體流量的一部分【9】。一些聲音和可視化信息包括行星圖像和科學觀察資料等也會通過這些鏈路傳輸。多媒體流量不需要100%的可靠,但是對遲變異,最小帶寬和傳輸速率的迅速變化有很嚴格的要求。多媒體英語通常被分為兩類:實時的或存儲的多媒體流和實時的交互多媒體。明顯的,實時交互多媒體因為極端長的傳播延時是不可能在行星際因特網(wǎng)骨干鏈路上傳輸?shù)摹H欢?,實時的或存儲的多媒體流可以作為一部分流量在空間鏈路上傳輸。對多媒體流量的控制是一個棘手的問題,因為不受控的多媒體流量不但會擁塞網(wǎng)絡(luò),還會對其它數(shù)據(jù)傳輸造成不公平現(xiàn)象。4.2.1挑戰(zhàn)除了4章中提到的再行星際骨干網(wǎng)絡(luò)中可靠傳輸?shù)奶魬?zhàn)之外,多媒體傳輸還面臨其它的挑戰(zhàn)。如下所述:l 遲變異。數(shù)據(jù)包遇到的端到端的延時的變化被稱為遲變異。多媒體流量對遲變異有很嚴格的要求,因為延時的抖動可以在重組多媒體信息時產(chǎn)生問題。這個挑戰(zhàn)一般是通過在接收端使用一個緩存來解決的。l 最小帶寬。大部分多媒體應(yīng)用為了達到最小的媒體感知質(zhì)量要求最小帶寬。如果帶寬降到閾值以下,接收的媒體就不能被正確的察覺出來。l 平滑的流量。媒體速率的中斷和頻繁的波動可以造成接收媒體質(zhì)量的大幅降低。因此,多媒體傳輸協(xié)議的主要目標就不是主動的發(fā)現(xiàn)和使用帶寬,而是維持一個相對穩(wěn)定的媒體速率同時對擁塞作出反應(yīng)。l 錯誤控制。在行星際因特網(wǎng)傳輸?shù)亩嗝襟w流量可以被編碼成MPEG,動態(tài)JPEG或者H.26x。盡管錯誤恢復(fù)技術(shù)可以在視頻流中使用,壓縮的視頻流還是對數(shù)據(jù)丟失很敏感。4.2.2 相關(guān)工作很多多媒體傳輸協(xié)議是為了在陸地網(wǎng)絡(luò)中控制多媒體流量而提出的【17,52,54,77,89,90,100】。這些提出的協(xié)議可以大體上分成兩種類型的控制機制,基于AIMD的和基于方程的?基于AIMD的速率控制機制是對TCP兼容的,基于反饋信息保守的調(diào)整發(fā)送速率,相對公平的競爭。流控制協(xié)議SCP是TCP的修改版本,使用類似TCP-Vegas速率調(diào)整算法。TCP接收端模擬TEAR【90】,使用數(shù)據(jù)包到來,數(shù)據(jù)包丟失和超時等信號來決定接收方的接收速率。使用這些信號,TEAR在接受端模擬了包裹慢啟動,快速回復(fù)和擁塞避免的TCP流量控制功能。速率適應(yīng)協(xié)議RAP【89】是一個在有線和短距離網(wǎng)絡(luò)中基于速率的控制機制。速率控制機制RCS100是在高帶寬延時積和有損鏈路中的實時流量的速率控制機制。然而,所有這些現(xiàn)存的基于AIMD的速率控制機制都是基于傳播延時相對短的假設(shè),這并不適合于行星際骨干網(wǎng)絡(luò)鏈路。此外,AIMD機制造成了在鋸齒模式中媒體速率的中斷和頻繁的波動,這對于大多數(shù)的多媒體應(yīng)用來說都是不適用的?;诔绦虻乃俾士刂茩C制是在陸地網(wǎng)絡(luò)中為了提供相對平滑的多媒體流量傳輸而提出的。基于程序的擁塞控制的想法是在TCP對應(yīng)的雙方經(jīng)歷同樣的丟包率,往返時間和數(shù)據(jù)包大小時調(diào)整發(fā)送速率而不是吞吐量。TCP友好速率控制TFRC是一個在擁塞控制機制使用了簡單TCP吞吐量模型的基于程序的速率控制機制。MPEG-TFRCP【77】是另一個用來以一個TCP友好方式傳輸MPEG-2視頻基于程序的速率控制機制。不像TFRC,TFRCP在調(diào)整視頻速率時特別的將視頻的特性考慮進來。盡管使用TCP相應(yīng)功能確保了基于方程的控制機制與TCP長時間范圍內(nèi)的公平競爭,穩(wěn)定狀態(tài)下的TCP源端吞吐量模型還是對RTT非常敏感。因此,基于方程的速率控制機制也不能達到很高的鏈路利用率而且一次并不是在高傳播延時的行星際骨干網(wǎng)絡(luò)鏈路上很好的解決辦法。SCPS基于速率的協(xié)議是為了深空通信而提出的。然而,協(xié)議中沒有包含任何的擁塞控制算法。SCPS基于速率的協(xié)議源端的傳輸速率是由用戶和接收端的緩存大小限制決定的。換句話說,SCPS基于速率的協(xié)議不能根據(jù)網(wǎng)絡(luò)狀況調(diào)整發(fā)送速率。因此,如果發(fā)送速率大于可用帶寬,它就可能在行星際骨干網(wǎng)絡(luò)鏈路上造成擁塞。除了上面提到的速率控制機制,為了在陸地網(wǎng)絡(luò)上最小化視頻質(zhì)量的變化提出了層次化的方法。很大普遍使用的壓縮標準,比如MPEG-W,MPEG-4和H.263,都對層次化編碼有擴充。使用層次化的編碼,源端可以實現(xiàn)一個層次化的編碼流,一個基本層和多個加強層。速率控制在增加的或放棄增加的層中實現(xiàn)。如果可以使用更大的帶寬,更多的加強層可以用來改善視頻的質(zhì)量。另一方面,如果鏈路帶寬降低,一下加強層可以被放棄。在層次化的方式中,它要求所有的底層可以被正確的接受。在行星際因特網(wǎng)鏈路中,這樣的要求常常得不到滿足。此外,相對于不分層的方式,分層的方式也會造成很大的壓縮損失。因為這個原因,分層的方式并不適合于行星際因特網(wǎng)。圖4中描述的包裹協(xié)議,是深空通信中在傳輸層之上的【13,19】。如在4.1節(jié)所說,包裹協(xié)議的基本想法就是以一種存儲和轉(zhuǎn)發(fā)的模式運行。然而,多媒體流量對時間有很嚴格的要求,在一個指定點指定時間之后接收到的數(shù)據(jù)就沒用了。因此,存儲和轉(zhuǎn)發(fā)方式對于多媒體數(shù)據(jù)來說是不合適的。此外,中間路由器需要以存儲和轉(zhuǎn)發(fā)的模式緩存數(shù)據(jù),這會要求固定的存儲空間。假設(shè)一跳的RTT值為20分鐘,平均傳輸速率時1MBps,則路由器需要在它的緩存中保留1.2GB的空間。如果平均傳輸速率和RTT更大,需要的緩沖空間將更大。對于如此巨大的緩沖空間,對緩沖的操作要花很長的時間。結(jié)果,包裹協(xié)議并不適合于在行星際因特網(wǎng)中對于多媒體流量的速率控制。包路徑分散機制是為了在因特網(wǎng)上進行實時語音通信,在延時,數(shù)據(jù)丟失率和通話質(zhì)量之間折中而提出的一種機制。不在一個網(wǎng)絡(luò)通路中嚴格控制傳輸,而是在多個不同的不相關(guān)的通路上傳輸冗余的語音流信息,利用了不同鏈路之間不相關(guān)的丟包和延時特性。然而,因為行星際骨干網(wǎng)絡(luò)鏈路主要是點到點的鏈路,不太可能在不相關(guān)的鏈路上傳輸多個多媒體流。因此,這個機制對于行星際因特網(wǎng)也不可行。另一方面,盡管多媒體流量本身就具有容錯性,為了在現(xiàn)存的高誤碼率鏈路上維持一定的成功概率,還是需要差錯控制機制。然而,因為極高的傳播延時,基于重傳的ARQ機制還不能為了這個目的而在行星際骨干網(wǎng)絡(luò)鏈路中使用。因此,數(shù)據(jù)包級的前向錯誤糾正機制FEC【83】可以使用在行星際因特網(wǎng)中。這種使用數(shù)據(jù)包級的多媒體傳輸?shù)腇EC的一個重要參數(shù)就是它的編碼和解碼的時間。傳統(tǒng)的FEC機制比如Reed-Solomon編碼對于大的FEC數(shù)據(jù)塊有很慢的編碼和解碼時間,這將數(shù)據(jù)塊的大小限制得很小。結(jié)果是使FEC的冗余代價增加,這是在行星際因特網(wǎng)珍貴的通信資源中應(yīng)該避免的。另一方面,Tornado編碼【15】是基于隨機二部圖和異或操作的,這讓Tornado編碼在大規(guī)模數(shù)據(jù)上比標準的擦除性編碼運算更快。因此,Tornado編碼適合在行星際骨干網(wǎng)絡(luò)鏈路上的FEC數(shù)據(jù)塊大小數(shù)據(jù)包級別的FEC。盡管Tornado編碼需要稍微多一點的編碼包來重建原始數(shù)據(jù),因為較小的FEC開銷,這個缺點是可以被大的FEC數(shù)據(jù)塊所補償。因此,目前的速率控制機制不能解決行星因特網(wǎng)骨干網(wǎng)絡(luò)的困難。應(yīng)該提出適用于行星際因特網(wǎng)的新的多媒體傳輸協(xié)議。4.2.3 RCP-PlanetRCP-Planet【49】,一個速率控制機制,是為了解決如圖1示的源端和目的結(jié)點都基本上是環(huán)繞行星的中繼衛(wèi)星的行星際骨干網(wǎng)絡(luò)的多媒體傳輸?shù)睦щy而提出的。RCP-Planet運行在IP層,不需要對底層的TCP/IP協(xié)議簇做任何修改。RCP-Planet包括兩個狀態(tài),初始狀態(tài)和穩(wěn)定狀態(tài),如圖8所示。RCP-Planet的主要功能如下:1. 數(shù)據(jù)包級別FEC。為了恢復(fù)由于在行星際因特網(wǎng)中鏈路錯誤或者擁塞引起的數(shù)據(jù)包丟失,使用了Tornado編碼來進行數(shù)據(jù)包級別的FEC,原因是它很快的編碼和解碼速度。盡管Tornado編碼要求略微稍微rnado多的編碼包來重建原始數(shù)據(jù),由于比較小的FEC開銷,這個缺點還是可以通過大的FEC塊來補償?shù)摹4送?,Tornado編碼只使用異或運算,這是他們更好實現(xiàn)。FEC塊的大小根據(jù)不同的數(shù)據(jù)包丟失率來選擇,以使FEC開銷最小。2. 初始狀態(tài)。在初始狀態(tài),因為在開始時得不到任何鏈路信息,很難判斷初始的發(fā)送速率。保守的,我們設(shè)置初始多媒體速率為應(yīng)用程序要求的最小值來避免向網(wǎng)絡(luò)中發(fā)送過多的數(shù)據(jù)包。因為初始狀態(tài)的丟包率也是未知的,最近的歷史值pn作為目前丟包率的近似值來覺得FEC塊的長度n。然而,實際的丟包率可能不會是pn。為了應(yīng)對最壞的網(wǎng)絡(luò)狀況我們保守的選擇一個比pn大得多的丟包率p1作為更壞的網(wǎng)絡(luò)狀態(tài)來計算相應(yīng)的FEC塊的長度n,n是作為實際的FEC塊的長度來對數(shù)據(jù)進行編碼的。因為n-n的冗余數(shù)據(jù)包是對解決更壞情況的附加冗余,他們以低優(yōu)先級發(fā)送。低優(yōu)先級的包在擁塞時不會對正常的流量產(chǎn)生影響。剩下的n個數(shù)據(jù)包以高優(yōu)先級發(fā)送。3. 新的速率探測機制。速率探測是為了測量接收端的速率來決定可用帶寬的機制。這個新的速率探測機制在每個FEC塊中實現(xiàn),在每個FEC塊中,一定數(shù)量的被稱為探測序列的數(shù)據(jù)包以一個稱為探測速率rp的高速率發(fā)出。FEC塊中剩下的包使用目前的源端發(fā)送速率rs。一些探測包可以因為網(wǎng)絡(luò)帶寬的限制被被網(wǎng)關(guān)丟棄,接收端探測序列的觀察速率ro是可用帶寬。探測序列的長度是一個設(shè)計參數(shù)并可以適當?shù)倪x擇。另外一個設(shè)定參數(shù)是探測速率rp。在初始化狀態(tài),不能得到任何關(guān)于鏈路狀態(tài)的信息,因此rp被以一種可以盡快獲取可用帶寬的方式設(shè)置。在穩(wěn)定狀態(tài),探測速率根據(jù)網(wǎng)絡(luò)狀態(tài)而更新。4. 新的速率控制機制。為了平滑的傳輸多媒體信息,RCP-Planet實施了一個基于速率探測機制的新的速率控制機制。在從接收方收到ACK之上,當前的觀察速率ro可知,這顯示了可用帶寬。相對的可用的媒體帶寬ra可以從ro算出,這是當前媒體速率的上界。如果rarm,此時rm是當前的媒體速率,網(wǎng)絡(luò)帶寬并沒有完全使用,可以增加媒體速率。多出的數(shù)量(ra- rm)每個平滑線性的RTT增加1,為的是減少網(wǎng)絡(luò)出現(xiàn)擁塞的機會。另一方面如果ra rm,當前的媒體速率過高,發(fā)送端需要回退并減少它的媒體速率,因此媒體速率乘法降低。5. 暫時中斷狀態(tài)。為了減少因為暫時中斷對吞吐量降低的影響,RCP-Planet在協(xié)議中加入了暫時中斷狀態(tài)。發(fā)送端如果在一段時間內(nèi)收不到任何ACK,就推斷為暫時中斷并停止發(fā)送任何數(shù)據(jù)包。類似的,接收方也會推斷暫時中斷并開始發(fā)送稱為Zero的ACK。因為RTT非常大,暫時中斷對性能的影響根據(jù)發(fā)生暫時中斷的位置有關(guān)。Zero ACK和當暫時中斷時在傳輸過程中的ACK被發(fā)送方用來根據(jù)暫時中斷情況獲取準確信息和正確行動的標準。6. FEC數(shù)據(jù)塊級別的ACK。為了解決在行星際骨干鏈路中的不對稱帶寬的問題,

溫馨提示

  • 1. 本站所有資源如無特殊說明,都需要本地電腦安裝OFFICE2007和PDF閱讀器。圖紙軟件為CAD,CAXA,PROE,UG,SolidWorks等.壓縮文件請下載最新的WinRAR軟件解壓。
  • 2. 本站的文檔不包含任何第三方提供的附件圖紙等,如果需要附件,請聯(lián)系上傳者。文件的所有權(quán)益歸上傳用戶所有。
  • 3. 本站RAR壓縮包中若帶圖紙,網(wǎng)頁內(nèi)容里面會有圖紙預(yù)覽,若沒有圖紙預(yù)覽就沒有圖紙。
  • 4. 未經(jīng)權(quán)益所有人同意不得將文件中的內(nèi)容挪作商業(yè)或盈利用途。
  • 5. 人人文庫網(wǎng)僅提供信息存儲空間,僅對用戶上傳內(nèi)容的表現(xiàn)方式做保護處理,對用戶上傳分享的文檔內(nèi)容本身不做任何修改或編輯,并不能對任何下載內(nèi)容負責。
  • 6. 下載文件中如有侵權(quán)或不適當內(nèi)容,請與我們聯(lián)系,我們立即糾正。
  • 7. 本站不保證下載資源的準確性、安全性和完整性, 同時也不承擔用戶因使用這些下載資源對自己和他人造成任何形式的傷害或損失。

評論

0/150

提交評論