面向深空通信的LTP多會話數據聚合策略

吳海濤 梁迎春

肇慶學院，廣東 526061

作為維系深空探測活動的紐帶，深空通信與地面通信及衛星通信相比[1]，不但要忍受極長且可變的時延，還要遭受各種干擾、損耗及衰減等交疊影響，更要面對由星體及探測器運動導致的頻繁鏈路斷續等問題，復雜多變的環境嚴重制約著數據傳輸效率。當前，通過增加發射功率、增大天線口徑等技術手段提升點對點鏈路的傳輸能力，已難以支撐未來空間科學活動的全面展開[2]。隨著探測任務深入開展、探測距離持續加大及載荷性能不斷提升，空間通信迫切需要一個互連、互操作且能提供容忍中斷、容忍延時服務的傳輸網絡。

如今，美國已建立了性能強大的深空測控網與火星中繼網絡，“洞察”號火星探測器成功著陸并回傳圖片，彰顯了其強大的測控能力。我國深空探測起步較晚，現階段已解決了深空點對點通信問題，“天鏈”系列數據中繼衛星組網、“鵲橋”月球中繼衛星及嫦娥四號的成功發射標志著我國正朝著網絡化傳輸發展。為了有效支撐未來更復雜、更遙遠的深空探測任務，滿足對數據傳輸效率的需求，人們正努力將CCSDS(Consultative Committee for Space Data Systems)空間通信協議簇，不斷移植到延時/中斷容忍網絡(Delay /Disruption-Tolerant Network，DTN)體系下，期望在極其艱難的星際環境中，DTN能提供如地面因特網般的服務。

眼下，DTN協議體系僅包含CCSDS正式頒布的BP(Bundle Protocol)、LTP(Licklider Transmission Protocol)等少數協議[3-4]。BP協議是核心覆蓋層協議，采用保管傳輸及存儲轉發機制，改善了端到端的可靠性。作為BP協議的一種匯聚層協議，LTP協議秉承了CFDP(CCSDS File Delivery Protocol)的設計思路，是專為深空長距離鏈路設計的點對點協議。LTP協議通過會話(Session)將應用數據以塊(Block)形式傳輸，既能提供類似TCP的可靠傳輸，也可提供如同UDP的盡力而為服務。

目前，空間TCP/IP協議體系已被證實無法適用于深空環境，CCSDS協議體系雖得到成功應用，但需針對不同場景人工選擇相應協議，DTN協議體系被視為解決深空通信面臨的長距離、大衰減及鏈路斷續等困難的有效手段[5-6]。

近幾年，在LTP協議方面出現了不少代表性的研究成果：1)根據LTP協議傳輸機理，利用實驗平臺在特定場景中對比驗證其傳輸性能。文獻[7-8]在上下行非對稱地月場景中，對比分析了LTP與TCP、UDP作為匯聚層協議的性能;2)通過數學建模，仿真估算會話傳輸時延。文獻[9-10]對LTP協議傳輸過程建模，在地火場景中仿真驗證了會話傳輸時延;3)將LTP協議與編碼結合設計傳輸協議，提升有效吞吐量。文獻[11-12]分別將Reed-Solomon碼、噴泉碼與LTP協議結合設計了新的傳輸協議，并分析了特定場景下的吞吐量;4)通過跨層聯合優化設計，以最小化文件傳遞時延等條件為約束，給出了在特定任務和環境下的數據單元大小優化方案[13-14]。

但研究工作大都集中在LTP協議的單會話性能比較、傳輸過程建模、提高吞吐量及數據單元優化等方面，對多會話傳輸及Bundle聚合研究較少。LTP單會話傳輸的延遲應答機制，在以長距離、斷續為顯著特征的深空鏈路中，會導致信道資源的利用率不足。因此，提高深空信道利用率就顯得尤為重要。

目前，作者對CFDP協議性能進行了深入研究，提出了一種改進方案并做了仿真對比驗證[15-17]；并在此基礎上建模分析了LTP會話傳輸過程，提出了異步加速重傳策略[18]。本文基于前期研究成果，采用多會話傳輸機制及Bundle聚合方法，提出一種多會話數據聚合策略，仿真分析其傳輸性能。

1 LTP單會話傳輸過程

首先，根據鏈路層的最大傳輸單元(Maximum Transmission Unit, MTU)大小，將要傳輸的整個文件數據塊分割為數據段(Segments)。邏輯上，既包含需基于重傳保障可靠傳輸的紅數據段，也包含無需可靠傳輸的綠數據段。按照實際傳輸需求，會話數據塊也可全為紅數據段或綠數據段。然后，按照紅數據段先發，綠數據段后發的原則依次發送。數據發送時，數據塊中的最后一個紅數據段被標記為紅數據結束(End of Red-Part, EORP)，用于指示數據塊中的紅數據傳輸完畢，并將其作為檢查點(CheckPoint, CP)，要求接收端一旦收到EORP后必須馬上回復接收報告(Report Segment, RS)。當發出EROP后，發送端立刻啟動一個定時器，以備EORP在定時器超時后的自動重傳。整個數據塊中的最后一個數據段也被標記為塊結束(End of Block, EOB)，表示整個會話數據塊傳輸完畢。

接收端在收到第一個數據段后，立刻啟動會話接收過程。如果在接收過程中未發生數據錯誤或丟失的話，接收端一旦收到EORP立刻回復一個RS，并啟動一個定時器以便發送端無回應時自動重傳RS。發送端在成功收到RS后，馬上關閉對應的EORP定時器，即刻產生并發送一個回復報告(Report-Acknowledgment segment, RA)。接收端在收到RA后，立刻關閉RS定時器，會話結束。如果在數據傳輸過程中有紅數據段丟失，就會啟動重傳過程。接收端返回一個(或多個)詳細描述丟失數據的接收報告，并分別為每個RS開啟一個定時器。發送端在收到RS后，回復RA并重傳丟失的數據段，將重傳數據中的最后一個數據段標記為CP。接收端在收到RA后，關閉相應的RS定時器。當接收端收到CP后，再次統計收到的數據，如果仍有數據丟失，需不斷重復上述重傳過程，如果此時所有數據均被成功接收，會話結束。

2 LTP多會話傳輸機制與數據聚合方法

深空通信節點稀少、鏈路斷續及存儲轉發等特點要求必須高效地利用鏈路資源。如果LTP直至收到前一數據塊的回復信息，才繼續傳輸后面數據塊，就會造成可用傳輸時機的極大浪費。因此，須考慮開啟多個會話提高信道利用率。

2.1 LTP多會話傳輸機制

設想的一種LTP多會話傳輸機制如圖1所示。為方便闡述多會話傳輸機制，假設各會話中數據塊長度相同，都包含3個紅數據段和1個綠數據段。

由圖1可見，在會話1中，當數據塊Block1中標記為EOB的綠數據段傳輸完后，發送端需等待一段時間才收到回復的接收報告RS。如果需要等待的往返時間(Round Trip Time, RTT)很長，勢必導致珍貴鏈路資源的極大浪費。

圖1 LTP多會話傳輸機制

為此，在發送端的處理能力、存儲空間等條件允許的情況下，可在會話1中的綠數據段發出后準備開啟會話2。同樣地，在會話2的數據塊Block2發送完后開啟會話3，并以此方式依次開啟多個會話并發傳輸，充分利用等待接收報告RS的空閑期，可大大提高深空信道的利用率。理論上來說，雖然可通過不斷開啟新的會話獲得更大的吞吐量，但是實際深空通信節點的存儲及處理能力都是嚴重受限的。因此，只能開啟有限的并發會話數。

2.2 數據聚合方法

目前，深空通信的業務類型日趨多樣，載荷性能不斷增強，遙測數據日益增多，這為深空環境下的數據傳輸帶來了新的挑戰。在實際任務中，采用何種協議體系傳輸，以及將數據分割為多大的協議數據單元(Protocol Data Unit, PDU)來匹配信道特性，是一個需要考慮的問題。

通常在DTN協議體系中，應用數據首先在BP層被分割為具有一定長度的“Bundle”，并經由DTN節點不斷向LTP匯聚層轉發；其次，LTP匯聚層通過服務數據聚合(Service Data Aggregation, SDA)的方式，按照傳輸需求將一個或多個Bundle打包成一個數據塊Block；最后，LTP再根據數據鏈路層規定的MTU，將Block分割成多個一定長度的數據段(Segment)，并將其作為基本的數據傳輸單元。

深空通信的一個突出特點就是上下行傳輸速率非對稱，速率比可達1:1000，上行鏈路難免會對回復RS帶來較大的時延。有時，應用數據在BP層被分割為很多個小的Bundle，并要求為每個Bundle單獨回復，如果一個數據塊Block僅封裝一個如此小的Bundle的話，接收端產生的回復RS數就會增多，容易導致回復的接收報告RS得不到及時傳輸，并不斷累積繼而產生擁塞，嚴重影響到數據傳輸效率。在這種情況下，為了保證RS的及時傳輸，必須減少產生的RS數目，需要將BP層產生的多個小Bundle聚合為一個大的數據Block，以此降低回復的RS數目，減輕上行信道的壓力。

基于以上分析，提出了一種面向深空通信的LTP數據聚合方法，如圖2所示。首先，要傳輸的源數據在BP層被分成多個小Bundle；然后，LTP通過SDA將多個Bundle聚合為一個Block；最后，按照數據鏈路層的MTU將Block 分割為多個Segment。究竟將多少個小Bundle聚合為一個Block，以此提高深空環境下的數據傳輸效率，是接下來要討論的問題。

圖2 數據聚合方法

3 LTP多會話數據聚合策略

下面結合多會話傳輸機制及數據聚合方法，對LTP多會話數據聚合過程進行數學分析，并仿真驗證。

3.1 多會話數據聚合過程及數學分析

為了分析方便，做出如下假設：

1)不考慮收發節點的存儲能力；

2)EORP、CP、RS及RA錯誤概率為0；

3)數據塊大小相同，會話間無等待時延；

4)接收端每次只產生一個回復報告RS；

5)無前向糾錯機制。

文中分析用到的記號規定見表1。

表1 符號定義

LTP多會話數據聚合過程如圖3所示。可見，在整個數據傳輸過程中，當會話S1中的EORP/CP發送完畢后，發送端無需等待回復的信息，可立即開啟會話S2，并依次開啟S3等多個會話，且每個會話數據塊Block長度一樣，都由一定數目的小Bundle聚合而成，且滿足LBlock=N·LBundle。當會話數據塊中的EORP/CP到達接收端后，就會觸發接收端回復RS，發送端在收到RS后就會啟動重傳過程，重傳的數據如圖3中的黑塊所示，所需的重傳回合數可視具體情況設定。每個會話皆按前述LTP單會話的過程將數據可靠傳輸，直至全部會話結束。

如前所述，聚合而成的數據塊Block依據鏈路層的MTU大小，被分割為多個一定長度的數據段Segment，并以此為單位進行傳輸。假設會話中每個數據段的錯誤概率恒定，在整個多會話數據傳輸過程中，接收報告RS均以會話“數據塊”的粒度產生，其大小由數據塊所含紅數據量的多少決定。在重傳階段中，由于是以“數據段”的粒度實現可靠傳輸的，重傳數據量的多少由數據段的長度及數量決定。

下面以會話S1和S2為例，簡要分析多會話數據聚合過程。在會話S1中，接收端在收到EORP后，需要產生回復用的接收報告RS，其長度由錯誤數據的多少及范圍決定。為了分析方便，將數據段發生錯誤或丟失的錯誤概率大小，以及數據塊的長度集中映射到RS的報告長度內，即用RS數據段的長短來表征錯誤數據量的多少。記會話S1中RS初次產生的時刻為初始0時刻。根據假設，會話S1與S2間無等待時延，會話S2中初次產生RS的時刻即為TBlock。若忽略收發兩端的排隊處理時延，為了避免RS的累積導致擁塞，接收端須做到在會話S2的RS產生前，將會話S1產生的RS傳輸完畢，即滿足：

圖3 多會話數據聚合過程

TRS≤TBlock

(1)

易知，RS的發送時間為：

(2)

會話Block的發送時間為：

(3)

將公式(2)、(3)代入公式(1)，可得：

(4)

又可表示為：

(5)

定義上下行信道速率比為：

(6)

公式(5)可表示為：

(7)

可得，

(8)

綜上可見，采用多會話傳輸時，需要聚合的Bundle數目N與上下行信道速率比、RS長度及Bundle長度有著密切的關系。

3.2 仿真分析

下面通過仿真對影響Bundle聚合數目的因素進行分析，討論Bundle聚合數的下界，仿真場景參數如表2所示，仿真結果如圖4所示。

表2 仿真場景參數設置

由圖4(a)可以看出，在地火場景中Bundle的聚合數與接收報告RS長度為線性變化，且隨CR的增大而不斷減小；在地月場景中，Bundle聚合數目因CR較大變化不太明顯。從圖4(b)可見，不管是地月還是地火場景中，在RS長度為30B的情況下，Bundle聚合數都隨Bundle長度的增大而減少，并逐漸趨于1。當Bundle長度為4KB時，不同CR(1∶50,1∶100,1∶200和1∶400)下的Bundle聚合數分別為1、1、2和3個。圖4(c)及(d)分別描述了地月、地火場景中，在不同Bundle長度情況下，Bundle聚合數與RS長度的變化關系。當Bundle長度為2KB時，Bundle聚合數隨RS長度成階梯上升變化。然而，當Bundle長度增大到16KB時，Bundle聚合數為1，這意味著Bundle較長時無需聚合。

綜上可得，當Bundle長度及CR較大時，需要聚合的Bundle數目較小甚至無需聚合；反之，當Bundle長度及CR較小時，才需采用聚合手段。既不能簡單地認為每個會話Block中僅含一個Bundle，也不能一味地通過聚合來減輕上行信道壓力，需要根據實際傳輸需求采取合適的聚合策略。

圖4 影響Bundle聚合的因素

4 結論

深空通信正朝著業務多樣化、數據海量化及傳輸網絡化的趨勢發展，這對提高數據傳輸效率提出了更高的要求，需要一個能容忍延時/中斷且能提供互連、互操作服務的網絡架構及協議體系。DTN網絡架構及傳輸協議為深空通信面臨的諸多挑戰提供了解決方案。本文提出了一種面向未來深空通信的LTP多會話數據聚合策略，可為我國航天測控中的深空通信傳輸協議設計提供參考。下一步將結合節點存儲空間受限的實際情況，分析數據傳輸過程中存儲空間的動態變化，確定能開啟的并發會話數，對深空環境下的LTP多會話數據聚合策略進行更深入的研究。