深空中繼通信束聚合效能研究

趙 揚，陶孝鋒，荊元利，張大鵬

1 引言

傳統的地面傳輸協議已經不能滿足高延遲、高誤碼、非對稱帶寬、斷續鏈路的深空通信環境，需要研究深空通信協議為遠離地球的航天器、航天員回傳數據提供可靠保障。空間數據系統咨詢委員會(Consultative Committee for Space Data Systems，CCSDS)總結了4種可用于空間網絡的協議構架：自定義網絡協議、CCSDS的CFDP協議、IP協議和延遲容忍網絡(Delay/Disruption Tolerant Network，DTN)。 其中 DTN 被認為是最適合作為空間網絡互連的協議構架[1]。DTN體系構架的核心是束協議(Bundle Protocol，BP)和利克里德傳輸協議(Licklider Transmission Protocol，LTP)。

目前國際標準制定機構已制定出部分DTN相關標準，如ITEF(the Internet Engineering Task Force)[2-5]及 CCSDS[6-7]。科研人員對 BP/LTP協議進行了分析及仿真。Wang等[8]通過JPL實驗室的ION軟件搭建仿真平臺，在不同傳播時延與誤碼率條件下對地月通信中使用BP/LTPCL、BP/TCPCL、BP/UDPCL協議的性能進行仿真，得出LTPCL在傳播延遲大于4 s或誤碼率高于10-5時，性能明顯優于TCPCL，且整體性能優于UDPCL；Nikolaos等[9]在BP層不采取聚合策略推導出了LTP協議下束的重傳次數與誤碼率、LTP分段大小間的概率關系；Burleigh[10]認為確認鏈路帶寬一般較小，推薦將多個BP束進行聚合，作為一個數據塊進行傳輸，以降低回復應答的數量，避免回復鏈路阻塞，提高DTN網絡的傳輸效率；Nikolaos等[11]通過包含真實衛星鏈路及ION軟件的仿真測試床，對地球與火星間的數據傳輸DTN網絡性能進行仿真，重點關注LTP分段大小、BP束大小對傳輸時間、節點內存占用、額外開銷等指標的影響，并提出與文獻[10]相反的論斷：將多個BP束聚合到一個數據塊，利用LTP傳輸的策略是無用的；Yu等[12]基于ION搭建的仿真平臺針對非對稱信道上DTN網絡傳輸吞吐量進行仿真，提出由于確認鏈路帶寬極低引起的LTP協議接收方對數據段的確認消息(Report Segment，RS)阻塞導致DTN傳輸性能下降，需要采用BP束聚合傳輸策略，以降低RS發送數量；Hu等[13]針對深空不對稱鏈路的特點，給出避免應答鏈路阻塞的最小束匯聚值的計算方法；黃天雨[14]針對中繼通信環境中BP協議存儲轉發策略，要求必須接受完整束后才能繼續轉發，導致第二跳鏈路會出現浪費的情況，提出將BP協議中最小轉發粒度由一個完整束降到下層LTP協議中的數據段，以此提高兩跳傳輸效率，該方案與現有BP協議的設計理念不同：通過存儲轉發保證數據的可靠傳輸，非完整束傳輸也會帶來上層數據恢復管理的困難。

現有BP/LTP協議仿真及性能分析聚焦于傳輸性能，關注于單會話情況，即只考慮同時發送單個LTP數據塊，并且缺乏考慮中繼節點對BP/LTP協議傳輸的影響。而實際為了充分利用鏈路帶寬，LTP協議會盡可能多的開啟會話，并發傳輸。目前地月、地火通信傳輸存在中繼節點，后續更遠星系探測等任務數據通信可能會有更多中繼層次。針對目前研究人員對束聚合策略效能的2種不同態度[10-11]，本文考慮LTP層并發多會話傳輸，關注中繼深空通信環境下束聚合對傳輸性能的影響，通過建模及數值實驗在中繼深空通信環境下檢驗束聚合策略的效能。

2 DTN網絡簡介

2.1 BP/LTP協議

一個典型的深空通信協議棧如圖1所示[15]，BP/LTP協議為其最關鍵的2個協議。BP協議位于應用層與傳輸層間，覆蓋于不同網絡之上，通過調用不同匯聚層適配器實現異構網絡的互聯。LTP協議作為傳輸協議，解決Internet網絡中TCP傳輸協議在深空時斷網絡中存在低效問題，可為上層提供可靠高效的數據傳輸服務，可運行于UDP上，也可運行在CCSDS空間鏈路層協議上，甚至可以直接部署于鏈路層上。

圖1 深空中繼通信DTN網絡協議棧[15]Fig.1 DTN protocol stack of deep space relay communication[15]

2.2 文件劃分及匯聚策略

DTN網絡中發送數據劃分如圖2所示：應用層數據文件按照BP協議在覆蓋層被劃分為多個束(bundle)，各個 bundle相互獨立傳輸。然后bundle在傳輸層上按照LTP協議將一個或多個bundle聚合成一個數據塊(block)，LTP協議使用一個會話(session)傳輸一個block，為了最大化信道利用，LTP同時開啟多個會話。接著依照鏈路層MTU要求將各個block劃分為數據段(segment)，添加鏈路層幀頭在鏈路層上傳輸。LTP協議對于要求可靠傳輸的數據段設置為紅色數據段(red segment)，使用應答重傳機制，否則設為綠色數據(green segment)。接收方在接收到帶有檢查點(check point，CP)標記的數據段時需回復接收報告RS，標記數據段的接收情況，所有未接收成功的數據段需要重傳，每個block紅色段結尾被強制標記CP，以保證紅色部分數據的可靠傳輸。本文假設所有數據都是紅色數據段，即要求可靠傳輸，不考慮綠色數據段情況。

圖2 數據劃分Fig.2 Data partition

可以看出，bundle在聚合成LTP層的block時，聚合個數m代表了聚合程度，當m=1時，表示一個block容納一個bundle，即不聚合；當m＞1時，表示一個block容納多個bundle，即采用聚合策略。目前LTP標準中沒有聚合策略的描述[6]，即默認m=1。

表1 符號含義Table 1 Meaning of symbols

3 深空中繼通信傳輸時延分析

3.1 LTP協議傳輸流程

以圖1所示的典型深空中繼通信兩跳網絡，兩跳都采用BP/LTP協議為例，分析在該環境下束聚合策略對BP/LTP性能的影響。本文所用符號含義如表1所示，后文不再贅述。

傳輸層LTP協議將BP層的束以block為單位組織，以segment為最小顆粒傳輸數據，BP層接收到LTP發來的完整bundle后，為應用層組織恢復原數據。因為每個block在各自會話中獨立發送，互不影響，因此這里以一個block發送交互過程為例：一個block被分為多個segment在鏈路層上傳輸，發送方在block尾標記CP，接收方需對接收情況進行反饋RS，發送方對于RS中標記的未接收segment進行重新發送，在最后一個數據段尾標記CP，以此重復交互傳輸直至接收方回復的RS中表明所有segment都已成功接收。發送方發送的CP段及接收方回復的RS都有可能丟失或誤碼，因此發送方在發送CP、接收方在發送RS后會啟動定時器，當超時未接收到對方回復時，會重新進行發送，一般超時定時器設為2倍的傳播時延加發送處理時延。圖3給出了一個中繼通信中一個block的傳輸過程，當中繼節點接收到一個完整的block(包含若干bundle)時才能上交給BP層進行下一步操作。

1)聚合尺寸限制。當信道非對稱比很高，即確認信道容量比數據信道的容量小很多，確認信道容量有限，若傳輸大量RS確認信息，則會造成RS確認信息的阻滯延遲。Hu等研究給出LTP協議傳輸文件時避免確認信道上確認信息RS延遲的計算公式[13]，如式(1)所示：

式中，mmin為LTP協議中避免確認信道上確認信息RS擁塞延遲的block數據塊最小匯聚尺寸。

2)最大會話數。LTP的會話為成功傳輸一個block而進行的一些數據段的傳輸交互過程。為提高數據傳輸的速率和最大利用寶貴的深空通信鏈路資源，LTP協議能夠同時開啟多個會話，而不需要等到這一次會話結束才開啟下一次會話。一次會話發送一個LTP數據塊，在鏈路允許的情況下開啟的會話量盡可能多。這將允許在鏈路上以并行的方式發送多個數據塊。由于發送及接收節點的存儲空間是有限的，發送方能夠同時開啟的會話數也是有限的。最大會話數(NOS)計算見式(2)所示：

當所有的會話都處于占用狀態，后續數據塊將處于等待狀態，直到前面開啟的會話關閉。

3.2 傳輸時間分析

3.2.1 單會話傳輸時間

對于信道誤碼率為Perr的無線環境，長度為Lseg的幀的誤幀率Pseg=1-(1-Perr)Lseg，傳輸次數小于k次能成功傳輸的概率為k-1次全部失敗的補，即Pseg(TN ＜k)=1-(1-Pseg)k-1，其中TN表示傳輸次數。對于一個含有n個segment的block(最后一個帶有CP標記)，其在k次傳輸內能將所有segment成功傳輸的概率為(不包括CP段)Pblock(TN ＜ k)= [Pseg(TN＜k)]n-1=(1-Psegk-1)n-1，那么TN=k的概率[9]Pblock(TN=k)=Pblock(TN＜k+1)-Pblock(TN＜k)=(1-，因此一個block傳輸次數TN的期望見式(3)：

1)一個block發送時間Ttrans：一個block包含傳輸成功服從成功概率為1-Pseg的幾何分布，因此

2)一個 block傳播時延 Tprop_block如式(5)所示[16]：

3)CP段及 RS段超時時間如式(6)、(7)所示[16]：

由于最大會話數限制為NOS個，那么一次可發送的 block數為 NOS個，當中繼節點接收到LTP協議傳來的某個block的完整部分后，即可上交給BP層進行轉發。每個會話獨立傳輸，那么每個block的總傳輸時間在相同環境中獨立同分布，即其傳播時間服從獨立同分布，期望值都為Tblock。

3.2.3 中繼傳輸時間

1)當第一跳傳輸期望時間大于第二跳，那么整個應用數據經過中繼節點到達目標節點時，中繼節點會等待數據的到來，接著轉發至目標節點，總傳輸時間期望如式(9)所示：

2)當第一跳傳輸期望時間小于第二跳，那么中繼節點需緩存第一跳傳來尚不能發送往第二跳的數據，總傳輸時間期望如式(10)所示：

圖4 中繼傳輸Fig.4 Relay transmission

4 數值實驗

針對火星-中繼衛星-地球3節點深空網絡建立數值實驗：火星到中繼衛星傳播時間平均約為600 s，中繼衛星到地球傳播時間約為0.12 s；業務數據傳輸誤碼率要求為 10-6；Burleigh[10]建議bundle尺寸不大于60 KB，本文選擇40 KB；LTP協議的最優segment大小盡量接近鏈路層的MTU[11]為1500 B，本文設置為1400 B；協議中的bundle及segment頭長度分別為28 B和46 B；參考余倩[16]的前反向鏈路速率參數設置4 Kbps及2 Mbps，本文數值實驗的參數如表2所示。

表2 實驗參數Table 2 Experiment parameters

依據表2參數，由式(1)可得到最小匯聚尺寸mmin，復鏈路不會產生擁塞。后續試驗不再考慮回復鏈路擁塞情況。

圖5、圖6為單個會話中block一跳發送成功各部分占用的時間，可見在深空傳輸中，傳播時延占據了絕大多數時間花銷。隨著信道誤碼率從10-6惡化為10-5時，CP確認段傳輸時間占比有所增加，因為誤碼率的增大引起CP段誤碼或丟失導致發送超時，帶來2倍傳播時間的定時器超時時間花銷。

圖5 一個blcok發送成功所需各部分時間(P err=10-5)Fig.5 Time spent on sending a block by each part(P err=10-5)

圖6 一個block發送成功所需各部分時間(P err=10-6)Fig.6 Time spent on sending a block by each part(P err=10-6)

圖7 為誤碼率為10-6信道條件下，一個會話中的數據block發送成功所用時間，可見隨著束匯聚個數m的增大，每個會話需要成功傳輸的數據量變大，所需時間也隨之變大。特別是在m從1到10之間，所需時間增速最快，原因是期望傳輸交互次數Eblock(TN)在開始時增長較快，導致占據時間花費的主要部分Tprop_block迅速增長。

圖8為最大會話數NOS與束匯聚個數m的關系。由于BP協議的存儲轉發策略在成功發送完一個完整束之間節點需保存發送數據，隨著m的增大，數據block變大，因此節點能同時保存的數據block個數隨之降低，能開啟的最大會話數NOS減少。

圖7 一個block成功發送時間(P err=10-6)Fig.7 Total time spent on sending a block(P err=10-6)

圖8 NOS與束匯聚個數m關系Fig.8 Relationship between NOS and m

圖9 為整個文件從源經過中繼發送至目的節點的時間，可以看出隨著m的增大，總傳輸時間也隨之變大(其中的波動是因為最大會話數取下整導致)。由于每次可開啟NOS個會話，每批的NOS個block發送時間期望相同，因此近似的估計所有block需要的平均傳輸批次與束匯聚個數m無關，如式(11)所示：

總時間變化的原因是在最大化鏈路利用條件下，較大block的成功傳輸需要較多時間(圖7)，在總批次不變的前提下，總時間也隨之增大。

圖9 文件總傳輸時間Fig.9 Total time spent on file transmission

圖10 為不同緩存大小時的數據傳輸時間，可見提高節點緩存大小，能夠減小總傳輸時間，這是因為在實驗中傳播時延Tprop_block是影響總傳輸時間的決定性因素，越大的節點緩存，可以提高最大會話數量NOS，增大并發數據量，提升鏈路利用，因此總傳輸時間隨之下降。但總傳輸時間并不隨節點緩存C的增大一直下降，因為當節點緩存增大到一定程度后，同時傳輸量增過大，每個會話平均可用帶寬過低，數據發送時間Ttrans迅速增長成為主要因素，總傳輸時間此時會逐漸增大。

圖10 不同節點緩存能力下的總時間花費Fig.10 Total time spent for different cache capabilities

5 結論

針對深空中繼通信環境，分析了應用數據在不同束匯聚尺寸下的傳輸時間花費期望。

1)在節點固定緩存大小約束條件下，如果應答鏈路不阻塞，隨著束匯聚尺寸的增大，數據傳輸時間花費期望隨之增大，即越小的匯聚尺寸傳輸時間越小。因此選擇保證回復鏈路不阻塞的最小束匯聚尺寸，能帶來較高的傳輸效率。

2)隨著節點緩存大小的增加，數據傳輸效率隨之增高，但過大的緩存會導致并發回話數過多，帶寬不足成為主要限制，數據傳輸效率又會逐步降低。