天地一體化信息網(wǎng)絡(luò)的體系結(jié)構(gòu)與協(xié)議分析

劉立祥

(中國科學院 軟件研究所天基綜合信息系統(tǒng)重點實驗室，北京 100190)

0 引 言

隨著技術(shù)的發(fā)展和應(yīng)用需求的多樣化，功能單一、結(jié)構(gòu)規(guī)則、運行依賴于地面、相互之間孤立的衛(wèi)星系統(tǒng)已經(jīng)不能滿足人們對實時性、綜合性的服務(wù)需求，而具有多種功能、軌道互補、智能性高、自主運行、便于擴展的異構(gòu)衛(wèi)星組網(wǎng)成為新的發(fā)展方向。

天地一體化信息網(wǎng)絡(luò)[1](space-ground integrated information network, SGIIN)，簡稱一體化網(wǎng)絡(luò)，由通信、偵察[2-3]、導(dǎo)航[4]、氣象等多種功能的異構(gòu)衛(wèi)星/衛(wèi)星網(wǎng)絡(luò)、空間飛行器以及地面有線和無線網(wǎng)絡(luò)設(shè)施組成，通過星間、星地鏈路將地面、空中用戶、飛行器以及各種通信平臺緊密聯(lián)合。地面和衛(wèi)星之間可以根據(jù)應(yīng)用需求建立星間鏈路，進行數(shù)據(jù)交換[5]。它既可以是現(xiàn)有衛(wèi)星系統(tǒng)的按需集成，也可以是根據(jù)需求進行“一體化”設(shè)計的結(jié)果，具有多功能融合、組成結(jié)構(gòu)動態(tài)可變、運行狀態(tài)復(fù)雜、信息交換處理一體化等功能特點[6]。這種高度綜合性的異構(gòu)網(wǎng)絡(luò)系統(tǒng)打破了各自獨立的網(wǎng)絡(luò)系統(tǒng)間數(shù)據(jù)共享的壁壘，能夠有效地綜合利用各種資源(包括軌道資源、載荷資源、通信資源等)，不僅可以為作戰(zhàn)提供一體化的偵察、導(dǎo)航、作戰(zhàn)指揮等服務(wù)，也可以為海-陸-空通信、海洋氣象預(yù)報、導(dǎo)航、應(yīng)急救援等提供全方位的支持[7]。

從網(wǎng)絡(luò)特性看，一體化網(wǎng)絡(luò)具有典型的大時空尺度屬性，是一個大時空尺度網(wǎng)絡(luò)，其網(wǎng)絡(luò)特點具有如圖1所示的鮮明特征。

圖1 天地一體化網(wǎng)絡(luò)特點Fig.1 Features of space-ground integrated information network

從組網(wǎng)模式來看，一體化網(wǎng)絡(luò)包括全中繼模式，所有衛(wèi)星都是通過中繼星(如天鏈)進行信息交互，星間不存在鏈路；部分中繼模式，同類衛(wèi)星之間有星際鏈路，異構(gòu)衛(wèi)星之間通過中繼星進行互連；全連通模式，在可通信范圍內(nèi)衛(wèi)星與衛(wèi)星之間構(gòu)成一個全連通網(wǎng)絡(luò)。

1 目前研究的問題分析

1)組網(wǎng)對象較為簡單。目前研究的大多是同種類的衛(wèi)星構(gòu)成的規(guī)則星座結(jié)構(gòu)，但是天地一體化網(wǎng)絡(luò)中衛(wèi)星軌道的種類各異，包括單星、星座、編隊等，還有些需要根據(jù)任務(wù)進行臨時建立連接[8]。因此，需要研究復(fù)雜條件下的組網(wǎng)問題。

2)建鏈條件過于理想。目前考慮的建鏈條件過于簡單(如可見即可通)、閾值限制以及按照拓撲圖等理論基礎(chǔ)上的最佳路徑計算等，但實際上可見未必可通，應(yīng)該全局考慮通信質(zhì)量對路由的影響。

3)信息傳輸?shù)膬?yōu)先級問題未作考慮。天地一體化網(wǎng)絡(luò)作為軍民兩用網(wǎng)絡(luò)，安全與隔離是非常重要的需求。因此,應(yīng)該對傳輸信息進行分級和分類，要考慮信息的時效性、優(yōu)先級等。

4)節(jié)點或鏈路故障重路由問題。重路由是通信網(wǎng)絡(luò)或互聯(lián)網(wǎng)需要具備的重要能力。重路由策略是當拓撲發(fā)生改變時，重新建立一條路徑，信息從源端重傳。這種方式簡單但不適用于拓撲變化快的衛(wèi)星網(wǎng)絡(luò)，會造成系統(tǒng)效率低下的問題。應(yīng)該根據(jù)鏈路或衛(wèi)星的故障情況設(shè)計高效的重路由策略，不從源端重傳，減少衛(wèi)星資源消耗，提高傳輸效率。

5)負載均衡問題。衛(wèi)星網(wǎng)絡(luò)用戶分布不均勻，造成網(wǎng)絡(luò)負載失衡，出現(xiàn)部分節(jié)點發(fā)生擁塞而其他節(jié)點未被充分利用的情況，增加了數(shù)據(jù)包的排隊時延和丟失的概率，應(yīng)該根據(jù)用戶分布，應(yīng)用需求平衡網(wǎng)絡(luò)負載。

2 天地一體化信息網(wǎng)絡(luò)協(xié)議體系

目前常用的網(wǎng)絡(luò)協(xié)議體系包括TCP/IP(transmission control protocol/internet protocol)協(xié)議體系[9]、CCSDS(consultative committee for space data systems)協(xié)議體系[10]、DTN( delay-tolerant networking)協(xié)議體系和SDN(software defined network)協(xié)議體系，TCP/IP協(xié)議簇在地面Internet網(wǎng)絡(luò)得到廣泛應(yīng)用，但由于衛(wèi)星網(wǎng)絡(luò)與地面Internet 的通信環(huán)境存在較大差別導(dǎo)致其無法直接應(yīng)用于空間網(wǎng)絡(luò)；CCSDS協(xié)議體系是針對空間通信的特點制定了空間通信協(xié)議標準，CCSDS的通信方案具有可行性，但是要對其路由、傳輸進行優(yōu)化設(shè)計；DTN協(xié)議體系是一類特殊的網(wǎng)絡(luò)，很適合天基環(huán)境特點，但是由于加入了包裹層和匯聚層，導(dǎo)致了其協(xié)議體系與地面以及其他網(wǎng)絡(luò)在兼容性上存在一定的問題；SDN協(xié)議體系是一種新型網(wǎng)絡(luò)技術(shù)，實現(xiàn)網(wǎng)絡(luò)控制與轉(zhuǎn)發(fā)能力分離，使得轉(zhuǎn)發(fā)能力可以直接編程進行控制。SDN 技術(shù)可以增強控制層的智能邊緣轉(zhuǎn)發(fā)能力、骨干網(wǎng)絡(luò)的高效承載能力以及網(wǎng)絡(luò)能力的開放和協(xié)同。但其多域的組網(wǎng)以及大量轉(zhuǎn)發(fā)設(shè)備的控制算法非常復(fù)雜，且還沒有形成統(tǒng)一標準。

天地一體化信息網(wǎng)絡(luò)是一個復(fù)雜的巨系統(tǒng)。從建設(shè)上看，這樣的系統(tǒng)既包括已經(jīng)建成的系統(tǒng)，又包含即將建設(shè)的系統(tǒng)，不同系統(tǒng)之間的運行模式、協(xié)議體系都不盡相同。基于實際建設(shè)需求，利用2級網(wǎng)絡(luò)架構(gòu)來對系統(tǒng)進行構(gòu)建,如圖2所示。圖2中，一級網(wǎng)絡(luò)(骨干網(wǎng)絡(luò))節(jié)點主要是起到骨干傳輸作用的節(jié)點，包括骨干寬帶衛(wèi)星、中繼星以及地面網(wǎng)絡(luò)中的骨干路由器；二級網(wǎng)絡(luò)(接入網(wǎng)絡(luò))節(jié)點是指完成具體任務(wù)如信息獲取衛(wèi)星、小衛(wèi)星編隊網(wǎng)絡(luò)、專用星座、地面網(wǎng)絡(luò)中的非骨干節(jié)點。通過這種組網(wǎng)模式的構(gòu)建可以降低天基網(wǎng)絡(luò)路由傳輸和接入的復(fù)雜度，提升信息傳輸效率。

對于骨干網(wǎng)絡(luò)，為了更好地與異構(gòu)網(wǎng)絡(luò)進行互聯(lián)互通，其協(xié)議體系結(jié)構(gòu)采用標準的分層體系，對于接入網(wǎng)絡(luò)，其協(xié)議體系可以采用專用或通用的體系，如非結(jié)構(gòu)化的網(wǎng)絡(luò)體系[11]。這主要是保證二級網(wǎng)絡(luò)的高效性。天基網(wǎng)骨干網(wǎng)絡(luò)和接入網(wǎng)絡(luò)協(xié)議體系示意圖如圖3所示。

圖2 一體化網(wǎng)絡(luò)兩級架構(gòu)示意圖Fig.2 Schematic diagram of two level architecture of space-ground integrated information network

圖3 天基網(wǎng)骨干網(wǎng)絡(luò)和接入網(wǎng)絡(luò)協(xié)議體系示意圖Fig.3 Schematic diagram of space-based network backbone network and access network protocol system

在該協(xié)議體系中，為了與地面及其他網(wǎng)絡(luò)兼容，協(xié)議體系包含了常見的協(xié)議棧，還有一些針對天基骨干網(wǎng)專門設(shè)計的協(xié)議，如BTP(bulk transfer protocol)，BNP，BRP以及寬帶接入?yún)f(xié)議、安全認證協(xié)議等。在實際的傳輸過程中，可以根據(jù)具體的傳輸需求對該協(xié)議棧進行優(yōu)化，以達到高效傳輸?shù)哪康摹?/p>

接入網(wǎng)協(xié)議體系可以根據(jù)需要進行選擇，可以是層次化協(xié)議，也可以是非層次化協(xié)議體系，如：①DTN協(xié)議體系[12-13]；②TCP/IP協(xié)議體系；③CCSDS協(xié)議體系；④SDN協(xié)議體系；⑤非層次化協(xié)議體系等。針對不同的需求，如果是深空網(wǎng)絡(luò)節(jié)點，可以選擇DTN，地面可以選擇TCP/IP，衛(wèi)星集群組網(wǎng)可以選擇非層次化協(xié)議體系等。

3 傳輸和路由協(xié)議分析

為了獲得不同協(xié)議的總體性能，本文重點分析前3類體系的空間網(wǎng)絡(luò)協(xié)議，根據(jù)協(xié)議網(wǎng)絡(luò)狀態(tài)控制方式，進行分類比較，并推導(dǎo)出TCP協(xié)議組和單純基于速率控制協(xié)議的理論邊界。需要指出的是，這些理論結(jié)果適合于在協(xié)議達到穩(wěn)定狀態(tài)下，傳輸大文件的性能，但對小文件如命令或控制傳輸并不適用。推導(dǎo)的協(xié)議理論模型分別如下。

3.1 基于擁塞控制的TCP協(xié)議

首先對運行在高誤碼鏈路上基于擁塞控制的協(xié)議(TCP-SACK，SCPS-VJ和SCPS-vegas-congestion)進行分析，推導(dǎo)出其最大理論吞吐量如 (1) 式所示。需要指出的是，(1)式需要假設(shè)系統(tǒng)已達到了穩(wěn)定狀態(tài)，傳輸文件的類型為大文件，而不是命令或者控制文件等小文件。

Bandwidth=0.93×MSS/RTT×sqrt(p)

(1)

(1)式中：MSS表示最大分段大?。籖TT表示往返時延；p表示數(shù)據(jù)包錯誤率。

在實驗中，用戶數(shù)據(jù)包大小設(shè)置為1 024 Byte。

在沒有錯誤的環(huán)境下，最大吞吐量等于接收窗口除以RTT，如(2)式表示。(2)式假設(shè)了大文件傳輸在慢啟動的時間消耗很小。

最大吞吐量=(窗口大小/RTT)

(2)

TCP-SACK測試窗口大小使用250 KByte, 2.85 MByte和5.7 MByte，延遲分別對應(yīng)10 ms，250 ms和500 ms。并通過(2)式來進行計算。

為了計算包頭開銷對吞吐量的營銷，假設(shè)包頭開銷設(shè)置為58 Byte(TCP包頭為20 Byte，IP包頭為20 Byte，以太包頭為18 Byte)。因此，最大吞吐量需要除以1024/(1024+58)。

3.2 基于速率控制的協(xié)議

空間通信協(xié)議規(guī)范(space communications protocol specification,SCPS)純速率控制選項不使用擁塞控制算法。發(fā)送速率取決于由用戶與接收機緩存大小所定義的速率值。像TCP和SCPS-VJ測試，確認方式使用延遲ACK。如前所述SNACK選項，也可在純速率控制中使用。

SCPS純速率控制還有使用“嚴格延遲ACK”的附加選項。ACK每隔延遲ACK計時器定義的時間發(fā)送一次，而不是每個數(shù)據(jù)包或每隔一個數(shù)據(jù)包發(fā)送一個ACK。在長延遲的環(huán)境中，經(jīng)過較長的時間可能下一個數(shù)據(jù)包才能到達，使用延遲ACK計時器來觸發(fā)ACK反饋是有益的。

針對基于速率控制的空間協(xié)議，首先通過對基于速率控制的協(xié)議的一階近似，將一個文件總的傳輸時間等于傳輸該文件初始數(shù)據(jù)包的時間加上重傳丟包需要的時間，一個往返時延等于一個鏈接建立之初時的3次握手時間?？梢缘贸?，最大吞吐量等于總的文件大小除以總的傳輸時間。如果假設(shè)，每一次丟失的數(shù)據(jù)包固定在第一次重傳，考慮到包頭開銷對吞吐量的影響，最大吞吐量將減少。因此，錯誤鏈路下基于速率控制的協(xié)議最大吞吐量，計算公式可以表示為

吞吐量=1024×8×文件大小/(1024+58)/
((文件大小×8×p/P)+(文件大小×8/R)+RTT)

(3)

(3)式中：R表示用戶速率；p表示數(shù)據(jù)包錯誤速率；RTT表示往返時延。

利用推導(dǎo)出的理論模型(2)式與(3)式分別進行仿真, 仿真場景設(shè)置為：傳輸文件數(shù)據(jù)量固定為100 MByte，延遲從10～500 ms變化，鏈路速率設(shè)定為100 Mbit/s，數(shù)據(jù)包大小為1 024 Byte。仿真結(jié)果如圖4所示。圖4分別顯示了基于速率控制的協(xié)議以及基于擁塞控制的TCP協(xié)議的理論吞吐量。圖4給出了基于速率控制協(xié)議的吞吐量的理論上界，同時顯示了3種不同延遲下TCP的理論吞吐量?？梢钥闯?，其吞吐量受鏈路錯誤的影響很大。因此，基于速率控制的協(xié)議在高帶寬環(huán)境下比TCP協(xié)議性能具有較大的優(yōu)勢。

圖4 網(wǎng)絡(luò)協(xié)議理論吞吐量對比Fig.4 Network protocol theory throughput comparison

3.3 傳輸協(xié)議仿真性能測試對比

3.3.1 測試環(huán)境和協(xié)議配置

本文搭建的仿真測試環(huán)境如圖5所示，測試床環(huán)境由2個分開的網(wǎng)絡(luò)組成，分別代表地面和空間網(wǎng)絡(luò)。2個網(wǎng)絡(luò)的連接通過多個虛擬電路，同時經(jīng)過一個信道模擬器進行橋接，模擬器可以注入時間延遲和數(shù)據(jù)流隨機比特錯誤。信道每一端網(wǎng)絡(luò)由1個路由器和1個以太網(wǎng)交換機組成。該交換機用于進行LAN的服務(wù)。

圖5 測試環(huán)境架構(gòu)Fig.5 Test environment architecture

為了評估這些協(xié)議在空間環(huán)境的性能，包括長時延，鏈路易錯的特點對性能的影響，將測試環(huán)境中的延遲RTT從10～500 ms進行變化，而BER設(shè)置為(0～1E-4)。具體參數(shù)配置如下。

單流測試中，TCP，SCPS-TP，MDP(multicast dissemination protocol)和MFTP(multiple fiel transfer protocol)協(xié)議用到的所有變量如下。

1)文件大?。?00 KByte, 1 MByte, 10 MByte, 100 MByte；

2)數(shù)據(jù)包大?。? 024 Byte；

3)BER大小：0，1.00E-08，1.00E-07，1.00E-06，1.00E-05，1.00E-04。

選擇TCP_SACK來進行測試。對于TCP_SACK測試，缺省數(shù)值使用Sun Solaris 7 Kernel中的多數(shù)TCP/IP參數(shù)。

對于SCPS協(xié)議的測試共有5種選項，分別如下。

1)Van Jacobson Congestion Control(SCPS-VJ)，每隔一個包確認一次；

2)Pure Rate Control(SCPS-Pure Rate Control, Option F2)，每隔一個包確認一次；

3)SCPS-Pure Rate Control, Option F0；

4)SCPS-Vegas-Congestion；

5)SCPS-Vegas-Corruption。

在進行多個數(shù)據(jù)流測試時，TCP-SACK, SCPS-VJ和SCPS-Vegas-Congestion采用單個數(shù)據(jù)流測試中的數(shù)據(jù)包大小，同時其他參數(shù)設(shè)置如下。

①文件大小固定為：50 MByte；

②往返時延固定為：500 ms；

③BER數(shù)值設(shè)置為0，1.00E-07和1.00E-05 3種；

④MDP選項：沒有前向校驗，速率設(shè)置為40 Mbit/s(服務(wù)器)；

⑤MFTP選項：最大數(shù)據(jù)單元設(shè)置為1 472(服務(wù)器)。

對于SCPS-VJ測試，為了與TCP測試一致，缺省延遲ACK定時器延遲設(shè)置為從50～200 ms。其余SCPS-TP參數(shù)不變。SCPS速率選擇設(shè)置為80 Mbit/s和100 Mbit/s。由于平均吞吐量大小比100 Mbit/s略高，所以選擇SCPS速率為100 Mbit/s作為測試。

對于TCP-SACK和SCPS-VJ，測試文件大小為100 MByte，誤碼率環(huán)境為1.00E-05。其余測試文件大小分別為10 MByte，1 MByte，100 KByte。誤碼率環(huán)境設(shè)置為1E-4。

采用SCPS-RI 1.1.62版本進行SCPS-Vegas-Congestion測試，采用版本1.1.66作為SCPS-Vegas-Corruption測試。這兩者的區(qū)別在于SCPS版本1.1.66與1.1.62基本功能相似，但是版本1.66可以切換2種慢啟動機制。

考慮到仿真時間的限制，Vegas測試只采用10 MByte和100 MByte 2種文件大小，2種Vegas的最優(yōu)速率分別設(shè)置為60 Mbit/s、延遲設(shè)置為500 ms，以及80 Mbit/s、延遲設(shè)置為10 ms。

3.3.2 仿真結(jié)果

3.3.2.1 基于擁塞控制的協(xié)議性能

圖6顯示了不同協(xié)議在延時500 ms時的情況下分別發(fā)送10 MByte和100 MByte文件大小的平均吞吐量。圖7顯示了不同BER環(huán)境下，不同協(xié)議傳輸10 MByte文件的平均吞吐量?？梢钥闯?，3種基于擁塞的協(xié)議的總體特性相似。TCP-SACK和SCPS-VJ都使用了Van Jacobson Congestion Control算法，因此，SCPS-VJ和TCP-SACK的總體特性相似。而SCPS-Vegas-Congestion性能略優(yōu)于TCP-SACK。

在無誤碼率的環(huán)境下，大的文件傳輸比小的文件傳輸具有較高的吞吐量，這是因為慢啟動在文件越多的情況下影響越小，而在高誤碼率情況下，小的文件傳輸比大的文件傳輸具有更高的吞吐量。對于TCP-SACK和SCPS-VJ，這是因為加性增乘性減擁塞控制算法的作用。每當錯誤發(fā)生時SCPS-Vegas-Congestion的窗口減少一半，所以當網(wǎng)絡(luò)中發(fā)生錯誤時，SCPS-Vegas-Congestion的吞吐量下降比SCPS-Vegas-Corruption的吞吐量下降快。

在高BER環(huán)境下，SCPS-Vegas-Corruption協(xié)議的性能比基于擁塞協(xié)議性能高。但是性能仍然不如基于速率控制的協(xié)議。

3.3.2.2 基于速率控制的協(xié)議性能

本測試不涉及擁塞控制機制，當在網(wǎng)絡(luò)中沒有擁塞的情況下，只能進行單個數(shù)據(jù)流的測試。首先給出該網(wǎng)絡(luò)場景下3類協(xié)議的基本參數(shù)配置。

在單流測試中協(xié)議的參數(shù)配置如下。

1)SCPS基于速率控制協(xié)議。

SCPS Pure-Rate Control (SCPS-Pure-Rate-2)：每隔一個包確認一次。

Pure-Rate Control (SCPS-Pure-Rate-F0)：延遲確認。

對于SCPS-Pure-Rate-F2測試，將SCPS-RI版本1.1.51中的延遲ACK定時器改為50 ms。測試中最優(yōu)速率為80 Mbit/s。

當使用SCPS-RI 1.1.51版本進行SCPS-Pure-Rate-F0調(diào)整測試時，確認包并不是按照默認ACK定時器規(guī)定的每隔200 ms進行發(fā)送，而是確認包的延遲大于200 ms。ACK最短往返時間為200 ms，最長可以在1～2 s。由于接收端窗口更新的速率并不及時，從而ACK返回的速率減少了接收窗口的大小。

圖7 基于擁塞協(xié)議性能(10 MByte文件傳輸)Fig.7 Performance based on congestion protocol(10 MByte file transfer)

2)MFTP。

配置MFTP傳輸時應(yīng)用的最大速率配置為50 Mbit/s。此外，指明2個系統(tǒng)的單播地址。設(shè)置MFTP服務(wù)器一次傳輸一個文件，但是在起始傳輸時間時，需要傳輸修復(fù)數(shù)據(jù)去應(yīng)答客戶NACKS高達100次。

3)MDP。

配置MDP使用單播地址傳輸時最優(yōu)速率配置為40 Mbit/s。服務(wù)器傳輸數(shù)據(jù)塊不進行前向校驗，并且重傳其負載。

通過仿真測試，結(jié)果如圖8和圖9所示。

圖8 具有500 ms時延的Rate-based文件傳輸Fig.8 Performance based on congestion protocol(10 MByte file transfer)

圖9 Rate-Based平均吞吐量與BER的對比Fig.9 Comparison of Rate-Based average throughput with BER

圖8顯示了在500 msRTT延時下不同基于速率控制協(xié)議的性能。當傳輸大文件時，可以看出，沒有基于速率控制的協(xié)議可以與理論吞吐量吻合，這個可能跟協(xié)議實現(xiàn)的機理有關(guān)。盡管所有基于速率控制協(xié)議的吞吐量實驗結(jié)果略低于理論數(shù)值，10 MByte MFTP在3種不同延遲下的曲線與理論數(shù)值曲線接近。在有BER和延遲的情況下，MDP的性能大概有35 Mbit/s，性能比SCPS-TP速率控制協(xié)議略好。但在高BER的環(huán)境下，吞吐量速率下降很快，與理論計算數(shù)值并不匹配。在低BER的環(huán)境下，與理論計算數(shù)值也不完全一致。尤其在高BER和高延時的情況下，接收機變得超負荷，與發(fā)送方不能保持一致。

在圖9中，相比于各自在500 ms時的吞吐量曲線，SCPS-Pure-Rate-F2和 SCPS-Pure-Rate -F0在10 ms時延情況下的曲線與相應(yīng)的理論曲線非常接近。這更能說明這也許是個內(nèi)存管理問題。另外，SCPS在內(nèi)核層的實施能夠提升其性能。

3.3.2.3 多業(yè)務(wù)流時基于擁塞控制的協(xié)議性能

在單流實驗中，單個流可以利用全部帶寬。在多流實驗中，三對流競爭可用的帶寬。對于這些測試，在路由器的ATM(asynchronous transfer model)接口上將帶寬設(shè)置為15 Mbit/s。在時間限制上只允許一個有限的測試子集在具有500 msRTT時延上運行，該子集的BER分別為0，1.00E-07和1.00E-05，和一個大小為50 MByte的單獨文件。如圖10所示，與單流測試相似，SCPS-Vegas-Congestion 的表現(xiàn)僅比TCP-SACK好一點，而TCP-SACK的表現(xiàn)又比SCPS-VJ在0和特定BER同時具有500 msRTT時延情況下好一點點。在BER為1.00E-07 和1.00E-05情況下，在多流測試下的每一對流的吞吐量具有與單流情況下幾乎完全相似的性能。這是因為錯誤對吞吐量的影響遠比擁塞對吞吐量的影響大。

圖10 多個數(shù)據(jù)流吞吐量隨著BER的變化Fig.10 Throughput of multiple data streams varies with BER

需要注意的是，所有的平均吞吐量可能會超過網(wǎng)絡(luò)容量。這是因為三對流的隨機偏移開始次數(shù)，這里每個數(shù)據(jù)流都以隨機的時間間隔開始，使各自的流傳輸和完成時對可用信道帶寬的利用率都不同。在任意子集的全體平均吞吐量能夠超過15 Mbit/s,尤其在第一個和最后一個傳輸沒有太多交疊的情況下。

圖11顯示了每個TCP-SACK流測試組中的30次測試的吞吐量。測試反映了每個收發(fā)機組在BER=0情況下的特性，相同的結(jié)果也發(fā)生在SCPS-VJ 和SCPS-Vegas-Congestion測試中。對每組測試數(shù)據(jù)進行分析后發(fā)現(xiàn)，SCPS-Vegas-Congestion測試中沒有一個流的吞吐量低于3 Mbit/s。然而在TCP-SACK 和 SCPS-VJ 的測試中，30次測試中有20次測試的吞吐量低于3 Mbit/s。盡管在TCP-SACK 和SCPS-VJ測試中吞吐量分別是2.3 Mbit/s—7.9 Mbit/s和1.9 Mbit/s —7.5 Mbit/s，相應(yīng)地在SCPS-Vegas-Congestion的流測試中，最小吞吐量和最大吞吐量分別為3.2 Mbit/s和9.5 Mbit/s。

圖11 分別多流傳輸時各自吞吐量Fig.11 Respective throughput of multi stream transmission

對以上的結(jié)果進行分析可知：

1)在空間環(huán)境中，多個數(shù)據(jù)流和單個數(shù)據(jù)流測試結(jié)果顯示出SCPS-Vegas對TCP的增強可以提供性能改進。

2)在高RTT延遲下，即在具有高RTT延遲的錯誤敏感環(huán)境下，基于速率控制的協(xié)議性能是顯著下降的?，F(xiàn)有擁塞的傳輸協(xié)議雖然能滿足大多數(shù)任務(wù)需求，但是仍需要對其進行修改和優(yōu)化。

3.4 天基網(wǎng)絡(luò)路由協(xié)議性能分析

3.4.1 主要路由算法比較

目前衛(wèi)星網(wǎng)絡(luò)路由協(xié)議充分利用衛(wèi)星網(wǎng)絡(luò)拓撲變化的周期性和可預(yù)知性，減少路由協(xié)議對網(wǎng)絡(luò)資源的消耗，這樣處理后果是路由協(xié)議受限于衛(wèi)星網(wǎng)絡(luò)拓撲，一旦衛(wèi)星網(wǎng)絡(luò)拓撲結(jié)構(gòu)發(fā)生變化，如加入新節(jié)點、新軌道、新星座，則路由協(xié)議需要作出較大改變，擴展性并不強。

表1是對幾種典型衛(wèi)星網(wǎng)絡(luò)路由算法與地面無線傳感器網(wǎng)絡(luò)路由算法的比較。其中，N為網(wǎng)絡(luò)中節(jié)點數(shù)量，e為通信鏈路數(shù)量?？箽允侵府斁W(wǎng)絡(luò)中某鏈路或者節(jié)點失效后，路由能否快速作出反應(yīng)，選擇新的路徑。對于基于快照序列的衛(wèi)星網(wǎng)絡(luò)路由算法、Ekici分布式衛(wèi)星網(wǎng)絡(luò)路由算法、AODV、DREAM等路由協(xié)議，當發(fā)生鏈路或者節(jié)點失效時，均需要重新尋找路徑，產(chǎn)生大量網(wǎng)絡(luò)控制信息，而基于地理位置信息抗毀性路由協(xié)議在鏈路或者節(jié)點發(fā)生失效后能夠在本地快速做出反應(yīng)，選擇新的路徑。

3.4.2 性能指標分析

在高度基本相同的衛(wèi)星網(wǎng)絡(luò)場景下，按照衛(wèi)星網(wǎng)絡(luò)傳輸任務(wù)的特點，針對衛(wèi)星網(wǎng)絡(luò)路由算法分別從數(shù)據(jù)包轉(zhuǎn)發(fā)、系統(tǒng)復(fù)雜度以及可移植性3個方面進行性能分析，對衛(wèi)星網(wǎng)絡(luò)路由算法進行比較。數(shù)據(jù)包轉(zhuǎn)發(fā)方面主要包括延時、健壯性、穩(wěn)定性、正確性、公平性和最優(yōu)性等性能指標；系統(tǒng)復(fù)雜度方面主要包括衛(wèi)星網(wǎng)絡(luò)節(jié)點計算與存儲復(fù)雜度、對地面基站的復(fù)雜度要求等性能指標。具體對比參見表2—表4。

基于離散拓撲序列的衛(wèi)星網(wǎng)絡(luò)路由算法首先會建立衛(wèi)星節(jié)點間的虛鏈路，選取備選路徑中延時小和切換次數(shù)少的路徑作為最優(yōu)路徑，理論上時延抖動偏小，但網(wǎng)絡(luò)實際運行過程中，延遲小和切換次數(shù)少可能是2個相互沖突的條件，所以使用基于離散拓撲序列的路由算法的衛(wèi)星網(wǎng)絡(luò)實際運行過程中延遲抖動往往比理論分析要大。

基于地理位置的衛(wèi)星網(wǎng)絡(luò)路由算法沒有采用虛連接方式，由于選路存在不確定性，延時抖動不能保證。時延抖動相對嚴重。其中，基于地理位置的分布式抗毀路由算法在Ekici分布式衛(wèi)星網(wǎng)絡(luò)路由基礎(chǔ)上，優(yōu)先選擇地理位置更接近目標的鄰居作為下一跳，能獲得較好的端到端時延結(jié)果。

基于離散拓撲序列的衛(wèi)星網(wǎng)絡(luò)路由算法采用虛通道機制，面向連接的傳送方式比較穩(wěn)定，但路由表無法根據(jù)網(wǎng)絡(luò)實際情況實時更新，在鏈路狀態(tài)發(fā)生變化時，需要首先由地面站節(jié)點重新計算路由，然后根據(jù)衛(wèi)星拓撲結(jié)構(gòu)變化選擇合適時間向上發(fā)送路由信息，更新星上路由表，健壯性不夠好?；诳煺盏男l(wèi)星網(wǎng)絡(luò)路由算法在ATM機制的基礎(chǔ)上加入了備選路徑處理，衛(wèi)星優(yōu)化切換時路徑選取，算法穩(wěn)定性加強，但是由于備選路徑有限，如果備選路徑全部失效，路由表仍然需要延遲更新，而且由于衛(wèi)星需要存儲大量備選路徑，極大地增加節(jié)點存儲復(fù)雜度，算法健壯性仍然較差。目前，基于離散拓撲序列的衛(wèi)星網(wǎng)絡(luò)路由算法由于無法實時獲取網(wǎng)絡(luò)狀態(tài)，所以往往不考慮公平性等需要實時信息的性能指標，僅將最短延遲和最少切換次數(shù)作為路由決策標準，在網(wǎng)絡(luò)負載較重情況下性能不佳，在同一時間片內(nèi)很可能出現(xiàn)網(wǎng)絡(luò)中部分衛(wèi)星負載很重，而另外一部分衛(wèi)星基本沒有網(wǎng)絡(luò)負載。雖然時間片間路由算法能夠根據(jù)獲取信息進行相應(yīng)調(diào)整，但是需要等待時間片時間，所以反應(yīng)速度較慢。

表1 路由算法比較Tab.1 Comparison of routing algorithms

表2 衛(wèi)星網(wǎng)絡(luò)路由算法數(shù)據(jù)包轉(zhuǎn)發(fā)對比Tab.2 Comparison of routing algorithms for packet transmission in satellite networks

表3 系統(tǒng)復(fù)雜度對比Tab.3 Comparison of system complexity

基于地理位置的衛(wèi)星網(wǎng)絡(luò)路由算法采用實時尋路，根據(jù)收集到的衛(wèi)星網(wǎng)絡(luò)實時狀況選擇數(shù)據(jù)傳輸路徑，對網(wǎng)絡(luò)狀況實時變化反應(yīng)靈敏。但是由于分布式特性，很難使用全局信息進行路由判斷，而是使用局部信息選取最優(yōu)路徑，這種路由選擇方式無法保證全局最優(yōu)。基于地理位置的衛(wèi)星網(wǎng)絡(luò)路由算法根據(jù)實時情況選擇通路，重視效率，局部處理公平性和最優(yōu)性，能夠獲得較好的公平性。

基于離散拓撲序列的衛(wèi)星網(wǎng)絡(luò)路由算法需要地面站根據(jù)衛(wèi)星網(wǎng)絡(luò)的離散拓撲序列計算每個時間間隔內(nèi)的衛(wèi)星網(wǎng)絡(luò)的最優(yōu)路徑，并上傳至網(wǎng)絡(luò)中的所有衛(wèi)星。當網(wǎng)絡(luò)發(fā)生故障的時候，地面站無法及時獲取信息，在發(fā)生故障狀況時也需要重新計算,計算復(fù)雜度高。對于衛(wèi)星節(jié)點，由于要存儲大量路由表，存儲復(fù)雜度高，但只需按標簽轉(zhuǎn)發(fā)，路由計算復(fù)雜度低。

基于地理位置的衛(wèi)星網(wǎng)絡(luò)路由算法地面站不需要預(yù)先計算路由表，各個衛(wèi)星節(jié)點實時計算數(shù)據(jù)傳輸路徑，地面基站計算復(fù)雜度以及存儲復(fù)雜度都降低。衛(wèi)星節(jié)點由于不需要接收與存儲地面站發(fā)送給衛(wèi)星的路由信息，網(wǎng)絡(luò)數(shù)據(jù)傳輸負擔以及衛(wèi)星節(jié)點存儲負擔均明顯降低。但衛(wèi)星節(jié)點需要實時計算數(shù)據(jù)傳輸路徑，因此衛(wèi)星計算復(fù)雜度較高。隨著計算附加條件增加及衛(wèi)星網(wǎng)絡(luò)環(huán)境的復(fù)雜度提高，衛(wèi)星節(jié)點計算復(fù)雜度明顯上升。

基于離散拓撲序列的衛(wèi)星網(wǎng)絡(luò)路由算法，衛(wèi)星節(jié)點需要不斷接收地面站發(fā)送來的路由信息與網(wǎng)絡(luò)負載。對于地面站節(jié)點，當新加入或者移出衛(wèi)星或衛(wèi)星系統(tǒng)，地面站需要重新計算整網(wǎng)路由，對地面站計算能力要求很高。同時由于是地面站集中控制，所以算法移植性很好，衛(wèi)星網(wǎng)絡(luò)系統(tǒng)的改變僅需要對地面站中央控制節(jié)點作出反應(yīng)，其余衛(wèi)星節(jié)點不需要做任何改變。

基于地理位置的衛(wèi)星網(wǎng)絡(luò)路由算法可以不預(yù)先計算路由表，各衛(wèi)星節(jié)點實時計算并傳輸數(shù)據(jù)信息，地面站不需要進行大量計算得出整網(wǎng)路由信息，并將大量路由信息發(fā)送到每個衛(wèi)星節(jié)點，網(wǎng)絡(luò)負擔輕。但是傳統(tǒng)的基于地理位置的衛(wèi)星網(wǎng)絡(luò)路由算法都考慮某一個特定網(wǎng)絡(luò)模型，而且衛(wèi)星邏輯地址是按照特定系統(tǒng)與地球表面所決定的，如Iridium和Teledesic系統(tǒng)，當新增或者減少衛(wèi)星導(dǎo)致衛(wèi)星星座不是預(yù)先設(shè)定規(guī)則星座時，路由算法可能無法正常工作。如果組成的新系統(tǒng)網(wǎng)絡(luò)拓撲不夠規(guī)則，無法滿足算法預(yù)先設(shè)計好的規(guī)則拓撲，則路由算法根本無法運行，因此可移植性較差。而基于地理位置的分布式抗毀路由算法充分考慮了不同的網(wǎng)絡(luò)拓撲變化對路由的影響，具有較好的可移植性。

表4 算法可移植性對比Tab.4 Comparison of algorithm portability

4 總 結(jié)

本文總結(jié)和討論了天地一體化信息網(wǎng)路的特點和主要研究問題。重點分析了一體化網(wǎng)絡(luò)的協(xié)議體系并進行了比較分析，通過對不同的協(xié)議體系分析，我們認為，CCSDS協(xié)議體系可以作為未來天基骨干網(wǎng)的協(xié)議體系。但是，其中的傳輸層、網(wǎng)絡(luò)層以及鏈路層的功能都要進行適應(yīng)性改造和優(yōu)化以滿足天地一體化信息網(wǎng)絡(luò)傳輸?shù)囊?。另外，對一體化網(wǎng)絡(luò)的路由問題進行了深入地討論，比較分析了主流的路由機制與優(yōu)缺點。

[1] 劉立祥.天地一體化網(wǎng)絡(luò)[M].北京:科學出版社,2015.

LIU L X. Space-ground integrated network [M]. Beijing: Science Press, 2015.

[2] DU J, JIANG C, WANG J, et al. Stability analysis and resource allocation for space-based multi-access systems[C]// IEEE Global Communications Conference. San Diego, CA, USA：IEEE, 2015:1-6.

[3] 劉春保.2015年全球?qū)Ш叫l(wèi)星發(fā)展回顧[J].國際太空,2016(2):29-35.

LIU C B. 2015 year in review: global navigation satellites[J]. Space International, 2016(2):29-35.

[4] 劉春保.2016年國外導(dǎo)航衛(wèi)星發(fā)展回顧[J].國際太空,2017(2):34-42.

LIU C B. 2016 year in review: Foreign navigation satellites[J]. Space International, 2017(2):34-42.

[5] HE J F, JIANG Y, ZHANG G X, et al. Topology and route production scenario of walker satellite constellation network with inter-satellite link[J]. Journal of Pla University of Science & Technology,2009,10(5):409-413.

[6] 盧勇，趙有健，孫富春,等.衛(wèi)星網(wǎng)絡(luò)路由技術(shù)[J].軟件學報,2014,25(5):1085-1100.

LU Y, ZHAO Y J, SUN F C, et al. Routing techniques on satellite networks[J]. Journal of Software, 2014, 25(5):1085-1100.

[7] JIN X, ZHANG P, YAO H. A communication framework between backbone satellites and ground stations[C]// International Symposium on Communications and Information Technologies.Qingdao,China:IEEE,2016:479-482.

[8] 劉基余.北斗衛(wèi)星導(dǎo)航系統(tǒng)的現(xiàn)況與發(fā)展[J].遙測遙控,2013,3(34):1-8.

LIU J Y. Status and Development of the Beidou Navigation Satellite System[J]. Journal of telemetry, tracking and command, 2013, 3(34): 1-8.

[9] Space communications protocol standards (SCPS) [EB/OL].[2017-08-08]. http://www.scps.org.

[10] CERF V, BURLEIGH S, HOOKE A, et al. Delay-tolerant networking architecture: IETFRFC 4838, informational[S]. [S.l.]: Network Working Group, 2007.

[11] CHIANG M, LOW S H, CALDERBANK A R, et al. Layering as optimization decomposition: a mathematical theory of network architectures[J]. Proceedings of the IEEE, 2007, 95(1):255-312.

[12] SABBAGH A, WANG R, ZHAO K, et al. Bundle protocol over highly asymmetric deep-space channels[J]. IEEE Transactions on Wireless Communications, 2017, 16(4):2478-2489.

[13] SHI L, JIAO J, SABBAGH A, et al. Integration of reed-solomon codes to licklider transmission protocol (LTP) for space DTN[J]. IEEE Aerospace and Electronic Systems Magazine, 2017, 32(4):48-55.

(編輯：魏琴芳)