延遲容忍網(wǎng)絡中的傳輸協(xié)議優(yōu)化設計
發(fā)布時間:2020-10-18 09:25
近年來,對宇宙空間的探索過程不斷幫助人類認識宇宙的本質,推動科技的發(fā)展,F(xiàn)有的深空通信傳輸層功能由LTP協(xié)議承載,而隨著人類的空間探索向深空發(fā)展,LTP協(xié)議已無法良好地解決深空通信環(huán)境面臨的長延時,高丟包率,中斷頻繁等諸多挑戰(zhàn)。近些年學者們通過對編碼技術的不斷創(chuàng)新,提出了很多適用于深空數(shù)據(jù)傳輸?shù)木幋a方案,其中LT碼由于其無固定碼率,低反饋的特性,得到了學者們的青睞,而BATS碼在LT碼的基礎上,結合了網(wǎng)絡編碼的特性,在面對對深空通信的網(wǎng)絡特性時,展現(xiàn)出了比LT碼更高的傳輸效率。LT碼和BATS碼雖然在編譯碼算法上趨于成熟,但在實際協(xié)議中的應用方案相對匱乏,因此如何將這些編碼技術結合到深空通信的傳輸協(xié)議中是學術界也是本文的重點研究內(nèi)容。本文通過對LTP協(xié)議以及LT碼和BATS碼的研究分析,提出了兩種基于編碼算法的LTP協(xié)議優(yōu)化方案,命名為LTP-LT協(xié)議及LTP-BATS協(xié)議。其中LTP-LT協(xié)議通過將LT碼的編譯碼算法結合到LTP協(xié)議的塊數(shù)據(jù)的傳輸過程中,最大限度的減少了LTP協(xié)議的反饋重傳次數(shù),極大的減少了深空通信中數(shù)據(jù)的可靠傳輸時延。而LTP-BATS協(xié)議則以LTP-LT協(xié)議為基礎,將BATS碼融入到協(xié)議中,克服了LT碼在多跳網(wǎng)絡傳輸中所面臨的累積丟包問題,相比LTP-LT協(xié)議而言,極大的提升了數(shù)據(jù)的傳輸效率。本文基于NASA開源的軟件協(xié)議棧ION實現(xiàn)了上述兩種協(xié)議,并以此為基礎搭建了地月通信仿真場景,通過仿真實驗證明了兩種協(xié)議的性能優(yōu)勢。最后,本文還基于BATS碼以及空間通信常用的滑動窗口傳輸方案,提出了一種基于均衡保護窗口的BATS碼文件傳輸方案。方案中利用小度值Batch對滑動窗口的非重疊區(qū)域進行編碼傳輸,并且采用不等滑動步長,實現(xiàn)了對滑動窗口的重疊部分和非重疊部分的均衡保護,使傳輸既具有較高可靠性,又具有較高的傳輸效率。文中通過仿真實驗證明了方案的性能優(yōu)勢。
【學位單位】:電子科技大學
【學位級別】:碩士
【學位年份】:2019
【中圖分類】:V443.1;V556;TN929.5
【部分圖文】:
第二章 DTN 網(wǎng)絡及其關鍵協(xié)議介紹protocol adaptor output,CLO)探測到與下一跳節(jié)點鏈接可用時,便會從傳輸隊列中取出 bundle 數(shù)據(jù)發(fā)送。接收方的匯聚層適配器(CLprotocol adaptor input,CLI)從遠端節(jié)點接收到數(shù)據(jù)后會根據(jù)協(xié)議字段來判定自己是否為目的節(jié)點,如果自身非目的節(jié)點,則會按照上述發(fā)送流程轉發(fā) bundle 數(shù)據(jù)。如果自身是目的節(jié)點,則會將這個 bundle 數(shù)據(jù)附加到交付隊列(delivery queue)中,上層應用層就會根據(jù)交付隊列中的數(shù)據(jù)來進行處理,在整個發(fā)送接收過程中,數(shù)據(jù)在模塊間的流動過程如下圖:
深空通信中,常采用滑動窗口方案來傳輸視頻等數(shù)據(jù),基本方法可以用下圖描述:圖5-1 傳統(tǒng)滑動窗口傳輸方案將需要傳輸?shù)臄?shù)據(jù)分為長度為 L 的分段,稱為一個窗口。對窗口 W1 內(nèi)的數(shù)據(jù)進行編碼傳輸,然后將窗口的起點向后移動 S 個符號,稱為滑動 S 步長,然后將該起點以后的新窗口 W2 內(nèi)的 L 個符號進行編碼傳輸。上圖中的 P 為前后兩個窗口的重疊部分。在基本的滑動窗口思路下,最直觀的基于 BATS 碼的滑動窗口方案為:根據(jù)文件特性劃分窗口長度,然后每一個窗口通過 BATS 碼編碼發(fā)送。這種思路雖然簡單清晰,但由于單次窗口一般都不會很長,因此會和 BATS 碼一樣面臨著傳輸效率無法逼近最優(yōu)的問題。因此
在保證發(fā)送成功率的情況下,對傳輸效率有很大的提升。分析其具體原因,上述窗口滑動方法是一種重疊滑動,如果連續(xù)采用這種重疊滑動,則可能出現(xiàn)部分數(shù)據(jù)有三重甚至多重重疊(如圖5-3所示),不僅嚴重影響了傳輸效率,而且數(shù)據(jù)的受保護程度也不同,重疊部分的窗口實際上是以數(shù)據(jù)的冗余傳輸實現(xiàn)對窗口滑動前后的重疊部分數(shù)據(jù)的增強保護,這部分數(shù)據(jù)的傳輸可靠性高于不重疊部分的數(shù)據(jù)。如果窗口連續(xù)滑動,則將出現(xiàn)更多的數(shù)據(jù)重疊,其中對不同重疊程度的數(shù)據(jù)的保護程度也是不同的。例如當滑動步長S小于重疊部分P的長度時,導致部分數(shù)據(jù)被過度保護,而其他部分保護的程度較低或沒有保護。如果對所有數(shù)據(jù)連續(xù)采用這種方式進行滑動,將會導致較多的不必要的數(shù)據(jù)冗余,同時也會造成窗口滑動太慢
【參考文獻】
本文編號:2846115
【學位單位】:電子科技大學
【學位級別】:碩士
【學位年份】:2019
【中圖分類】:V443.1;V556;TN929.5
【部分圖文】:
第二章 DTN 網(wǎng)絡及其關鍵協(xié)議介紹protocol adaptor output,CLO)探測到與下一跳節(jié)點鏈接可用時,便會從傳輸隊列中取出 bundle 數(shù)據(jù)發(fā)送。接收方的匯聚層適配器(CLprotocol adaptor input,CLI)從遠端節(jié)點接收到數(shù)據(jù)后會根據(jù)協(xié)議字段來判定自己是否為目的節(jié)點,如果自身非目的節(jié)點,則會按照上述發(fā)送流程轉發(fā) bundle 數(shù)據(jù)。如果自身是目的節(jié)點,則會將這個 bundle 數(shù)據(jù)附加到交付隊列(delivery queue)中,上層應用層就會根據(jù)交付隊列中的數(shù)據(jù)來進行處理,在整個發(fā)送接收過程中,數(shù)據(jù)在模塊間的流動過程如下圖:
深空通信中,常采用滑動窗口方案來傳輸視頻等數(shù)據(jù),基本方法可以用下圖描述:圖5-1 傳統(tǒng)滑動窗口傳輸方案將需要傳輸?shù)臄?shù)據(jù)分為長度為 L 的分段,稱為一個窗口。對窗口 W1 內(nèi)的數(shù)據(jù)進行編碼傳輸,然后將窗口的起點向后移動 S 個符號,稱為滑動 S 步長,然后將該起點以后的新窗口 W2 內(nèi)的 L 個符號進行編碼傳輸。上圖中的 P 為前后兩個窗口的重疊部分。在基本的滑動窗口思路下,最直觀的基于 BATS 碼的滑動窗口方案為:根據(jù)文件特性劃分窗口長度,然后每一個窗口通過 BATS 碼編碼發(fā)送。這種思路雖然簡單清晰,但由于單次窗口一般都不會很長,因此會和 BATS 碼一樣面臨著傳輸效率無法逼近最優(yōu)的問題。因此
在保證發(fā)送成功率的情況下,對傳輸效率有很大的提升。分析其具體原因,上述窗口滑動方法是一種重疊滑動,如果連續(xù)采用這種重疊滑動,則可能出現(xiàn)部分數(shù)據(jù)有三重甚至多重重疊(如圖5-3所示),不僅嚴重影響了傳輸效率,而且數(shù)據(jù)的受保護程度也不同,重疊部分的窗口實際上是以數(shù)據(jù)的冗余傳輸實現(xiàn)對窗口滑動前后的重疊部分數(shù)據(jù)的增強保護,這部分數(shù)據(jù)的傳輸可靠性高于不重疊部分的數(shù)據(jù)。如果窗口連續(xù)滑動,則將出現(xiàn)更多的數(shù)據(jù)重疊,其中對不同重疊程度的數(shù)據(jù)的保護程度也是不同的。例如當滑動步長S小于重疊部分P的長度時,導致部分數(shù)據(jù)被過度保護,而其他部分保護的程度較低或沒有保護。如果對所有數(shù)據(jù)連續(xù)采用這種方式進行滑動,將會導致較多的不必要的數(shù)據(jù)冗余,同時也會造成窗口滑動太慢
【參考文獻】
相關期刊論文 前1條
1 張乃通;李暉;張欽宇;;深空探測通信技術發(fā)展趨勢及思考[J];宇航學報;2007年04期
本文編號:2846115
本文鏈接:http://sikaile.net/kejilunwen/xinxigongchenglunwen/2846115.html
最近更新
教材專著