孫延濤，劉承昕，李 琪，寧金枝

(1.北京交通大學(xué) a.計(jì)算機(jī)與信息技術(shù)學(xué)院，b.交通數(shù)據(jù)分析與挖掘北京重點(diǎn)實(shí)驗(yàn)室，北京 100044；2.航天東方紅衛(wèi)星有限公司，北京 100094)

衛(wèi)星通信在軍事上有著其他通信方式不可替代的作用，目前，世界主要航天國(guó)家正在開展天基信息網(wǎng)的研究，著眼于提高軍隊(duì)的信息戰(zhàn)能力，憑借這種奪取信息優(yōu)勢(shì)的關(guān)鍵武器在未來戰(zhàn)爭(zhēng)中獲得主控權(quán).我國(guó)的空間信息化建設(shè)正處于快速發(fā)展階段，對(duì)大規(guī)模衛(wèi)星通信有強(qiáng)烈需求.衛(wèi)星組網(wǎng)和衛(wèi)星路由的研究對(duì)于加強(qiáng)我國(guó)國(guó)防信息化建設(shè)，打好以?shī)Z取信息優(yōu)勢(shì)為目標(biāo)的陸、海、空、天、電一體化戰(zhàn)爭(zhēng)具有重要作用和重大意義[1-2].

衛(wèi)星根據(jù)其軌道高度可以分為地球同步軌道(Geosynchronous Earth Orbit，GEO)衛(wèi)星和非地球同步軌道衛(wèi)星兩類.其中地球同步軌道衛(wèi)星已廣泛應(yīng)用，但由于其軌道位置有限，資源日漸匱乏.而非地球同步軌道衛(wèi)星的近地軌道(Low Earth Orbit，LEO)衛(wèi)星有著傳輸延遲低、覆蓋范圍廣、通信損耗小的特點(diǎn)，慢慢成為世界各國(guó)研究的熱點(diǎn).

衛(wèi)星通信借鑒了地面的技術(shù)衍生出了星上處理技術(shù)和星間鏈路技術(shù)，使得衛(wèi)星網(wǎng)絡(luò)能像地面網(wǎng)絡(luò)一樣進(jìn)行通信[3]，然而卻也面臨很多的問題.由于衛(wèi)星網(wǎng)絡(luò)特有的衛(wèi)星節(jié)點(diǎn)負(fù)載有限、衛(wèi)星網(wǎng)絡(luò)拓?fù)渥兓l繁、軟硬件設(shè)備更新困難、通信距離長(zhǎng)等問題，常見的地面動(dòng)態(tài)路由算法在衛(wèi)星網(wǎng)絡(luò)的環(huán)境中適應(yīng)性很差，信息交換不及時(shí)導(dǎo)致的路由環(huán)路等問題造成網(wǎng)絡(luò)丟包嚴(yán)重，網(wǎng)絡(luò)吞吐量下降，傳輸延遲增加.為了解決上述問題，研究人員開始研究將軟件定義網(wǎng)絡(luò)技術(shù)應(yīng)用于衛(wèi)星通信網(wǎng)絡(luò)[4].

軟件定義網(wǎng)絡(luò)(Software-Defined Network，SDN)是一種新型的網(wǎng)絡(luò)架構(gòu)，它將數(shù)據(jù)平面和控制平面分離，數(shù)據(jù)平面的節(jié)點(diǎn)只需要根據(jù)流表規(guī)則進(jìn)行數(shù)據(jù)包的轉(zhuǎn)發(fā)，計(jì)算則由控制平面的控制器完成[5].

本文作者利用衛(wèi)星網(wǎng)絡(luò)運(yùn)行的規(guī)律性，提出了一種基于軟件定義網(wǎng)絡(luò)的衛(wèi)星網(wǎng)絡(luò)路由預(yù)置方法.在該方法中，SDN控制器提前獲知網(wǎng)絡(luò)拓?fù)淝闆r，計(jì)算路由路徑，然后下發(fā)流表?xiàng)l目.衛(wèi)星節(jié)點(diǎn)根據(jù)收到的流表?xiàng)l目轉(zhuǎn)發(fā)數(shù)據(jù)包，最終使得所有數(shù)據(jù)包能被轉(zhuǎn)發(fā)到地面站.這種方法不僅保證了網(wǎng)絡(luò)的正確運(yùn)行，提高了吞吐量，降低了傳輸延遲，同時(shí)也減少了衛(wèi)星上的路由計(jì)算開銷.

1 相關(guān)工作

衛(wèi)星組網(wǎng)路由方法一般使用動(dòng)態(tài)路由算法及其變種.文獻(xiàn)[6]提出基于優(yōu)先級(jí)的自適應(yīng)路由算法，該算法利用鏈路利用率和緩沖信息大小定義優(yōu)先級(jí)函數(shù)，最終選取鏈路流量小的路徑作為最優(yōu)路徑.文獻(xiàn)[7]提出分布式多路徑路由算法，該算法將業(yè)務(wù)流量分配到多條可行的路由路徑上，達(dá)到單源多路徑效果.但是這些算法實(shí)現(xiàn)復(fù)雜且在衛(wèi)星網(wǎng)絡(luò)環(huán)境下適應(yīng)性差.

鑒于星間通信具有移動(dòng)自組織網(wǎng)絡(luò)(Mobile Ad Hoc Networks，MANET)[8]的一些特性，部分研究使用MANET的路由協(xié)議進(jìn)行衛(wèi)星通信.主要使用的是先驗(yàn)性路由協(xié)議中的鏈路狀態(tài)路由協(xié)議(Optimized Link State Routing，OLSR)[9].但是OLSR需要不斷在衛(wèi)星之間交互鄰居表等信息，在大規(guī)模星群的環(huán)境下會(huì)占用大量網(wǎng)絡(luò)資源、增加端到端時(shí)延；且長(zhǎng)距離通信環(huán)境下，消息交換不及時(shí)會(huì)導(dǎo)致路由環(huán)路等問題.

現(xiàn)有一些研究將軟件定義網(wǎng)絡(luò)技術(shù)應(yīng)用于衛(wèi)星網(wǎng)絡(luò).已經(jīng)有不少研究提出了基于SDN的路由框架，文獻(xiàn)[10]將地面站和地球同步衛(wèi)星作為控制器，將近地軌道衛(wèi)星作為數(shù)據(jù)平面節(jié)點(diǎn)，但是并沒有實(shí)驗(yàn)驗(yàn)證.文獻(xiàn)[11]在此基礎(chǔ)上進(jìn)行了實(shí)驗(yàn)的驗(yàn)證，但是衛(wèi)星網(wǎng)絡(luò)規(guī)模較小，僅由66顆近地軌道衛(wèi)星構(gòu)成，對(duì)于大規(guī)模星群并沒有闡述其可行性.

對(duì)于衛(wèi)星拓?fù)涞穆酚蓡栴}，文獻(xiàn)[12]提出了基于變形蟲算法設(shè)計(jì)路由方案以及基于波紋擴(kuò)散算法設(shè)計(jì)路由方案.文獻(xiàn)[13]則結(jié)合了深度優(yōu)先搜索和Dijkstra算法進(jìn)行路由計(jì)算.但是這些方法相對(duì)復(fù)雜且并沒有充分利用衛(wèi)星運(yùn)動(dòng)的特點(diǎn)和軟件定義網(wǎng)絡(luò)的優(yōu)勢(shì).

針對(duì)控制器放置問題，文獻(xiàn)[14]提出了在近地軌道衛(wèi)星網(wǎng)絡(luò)中，間隔衛(wèi)星部署控制器的方式.文獻(xiàn)[15]提出了根據(jù)用戶活動(dòng)來動(dòng)態(tài)部署控制器的方法，將控制器部署在活動(dòng)強(qiáng)度較高的位置.文獻(xiàn)[16]將主控制器設(shè)置在地球同步衛(wèi)星上，并同時(shí)在近地軌道衛(wèi)星上選取一部分衛(wèi)星作為從控制器，完成對(duì)近地軌道衛(wèi)星全網(wǎng)的控制.文獻(xiàn)[17]結(jié)合了衛(wèi)星網(wǎng)絡(luò)和地面網(wǎng)絡(luò)，提出了一種控制器和網(wǎng)關(guān)聯(lián)合部署的策略.這些方法都試圖控制器部署在衛(wèi)星上，而并沒有考慮衛(wèi)星的處理能力缺乏一定的實(shí)用性.

總體而言，現(xiàn)有對(duì)軟件定義衛(wèi)星網(wǎng)絡(luò)的研究并沒有很好地解決大規(guī)模衛(wèi)星網(wǎng)絡(luò)的組網(wǎng)路由問題.

2 整體架構(gòu)

本文將SDN應(yīng)用于衛(wèi)星網(wǎng)絡(luò)中，根據(jù)衛(wèi)星運(yùn)動(dòng)軌跡對(duì)衛(wèi)星節(jié)點(diǎn)的路由進(jìn)行預(yù)先設(shè)置，從而避免由于衛(wèi)星網(wǎng)絡(luò)拓?fù)渥兓l繁引起的路由震蕩和丟包嚴(yán)重、通信延遲增加等網(wǎng)絡(luò)性能問題.

本文所研究的衛(wèi)星網(wǎng)絡(luò)由地面站和LEO衛(wèi)星組成，是一個(gè)以地面站為核心的網(wǎng)絡(luò).其中，LEO衛(wèi)星負(fù)責(zé)采集氣象等業(yè)務(wù)信息和衛(wèi)星自身數(shù)據(jù)，定時(shí)發(fā)送給地面站，地面站負(fù)責(zé)信息數(shù)據(jù)的匯總與處理.為了達(dá)到更好的覆蓋收集效果，星群使用雙層甚至多層的衛(wèi)星軌道.同軌道的衛(wèi)星，其相對(duì)位置固定，使用激光與相鄰的衛(wèi)星進(jìn)行通信；異軌道的衛(wèi)星使用全向天線在一定的通信距離內(nèi)與臨近衛(wèi)星進(jìn)行通信.

該衛(wèi)星網(wǎng)絡(luò)具有一般衛(wèi)星網(wǎng)絡(luò)的特點(diǎn)：運(yùn)行軌跡固定、通信距離長(zhǎng)、路由跳數(shù)多.在該網(wǎng)絡(luò)中，地面站是每個(gè)衛(wèi)星的通信終點(diǎn)，每個(gè)衛(wèi)星利用其他衛(wèi)星作為中繼節(jié)點(diǎn)，把采集到的數(shù)據(jù)最終發(fā)送至地面站.

針對(duì)上述衛(wèi)星網(wǎng)絡(luò)，本文采用的SDN衛(wèi)星網(wǎng)絡(luò)架構(gòu)如圖1所示.

圖1 基于SDN的衛(wèi)星網(wǎng)絡(luò)架構(gòu)Fig.1 Satellite network architecture based on SDN

1)SDN控制器.SDN控制器設(shè)置于地面，負(fù)責(zé)為每一顆衛(wèi)星提前計(jì)算到達(dá)地面站的路由路徑，并將計(jì)算結(jié)果預(yù)先下發(fā)到相應(yīng)的LEO衛(wèi)星.

2)數(shù)據(jù)平面.由LEO衛(wèi)星組成，接收控制器下發(fā)流表項(xiàng)，并按照流表項(xiàng)對(duì)數(shù)據(jù)流進(jìn)行轉(zhuǎn)發(fā).LEO衛(wèi)星不需要進(jìn)行路由計(jì)算，大大減少了星上計(jì)算負(fù)擔(dān).

3)帶外控制信道.本文使用GEO衛(wèi)星作為帶外信道，用于Openflow控制平面和數(shù)據(jù)平面之間的控制消息交互.控制器通過帶外信道將流表?xiàng)l目等控制消息發(fā)送給數(shù)據(jù)平面的衛(wèi)星節(jié)點(diǎn).相比于帶內(nèi)方式，使用帶外方式交互控制消息，控制信道更為簡(jiǎn)單，通信時(shí)延更小.

3 路由預(yù)置方法

本文中使用的一些符號(hào)及其含義如表1所示.

表1 文中的符號(hào)及含義Tab.1 Symbols and meanings in this paper

3.1 基本思想

在衛(wèi)星網(wǎng)絡(luò)中，衛(wèi)星數(shù)量多且拓?fù)渥兓l繁，使用動(dòng)態(tài)路由算法很可能會(huì)出現(xiàn)信息更新不及時(shí)造成的路由環(huán)路等問題，影響衛(wèi)星網(wǎng)絡(luò)的正常運(yùn)行.引入SDN的思想雖然有助于解決錯(cuò)誤的路由，但是由于衛(wèi)星節(jié)點(diǎn)(后文簡(jiǎn)稱節(jié)點(diǎn))快速運(yùn)動(dòng)且和控制器之間距離較遠(yuǎn)，節(jié)點(diǎn)上報(bào)拓?fù)渥兓⒖刂破黜憫?yīng)計(jì)算和重新下發(fā)流表?xiàng)l目這3個(gè)步驟都需要一定的時(shí)間，造成較大的延遲.

針對(duì)上述問題，本文提出一種基于SDN的路由預(yù)先設(shè)置的方法，預(yù)先根據(jù)網(wǎng)絡(luò)拓?fù)渥兓?jì)算路由，并提前將流表?xiàng)l目下發(fā)到相應(yīng)的節(jié)點(diǎn)上.該方法的主要模塊構(gòu)成和工作流程如圖2所示.

圖2 路由預(yù)置方法模塊組成與工作流程Fig.2 Module composition and workflow of route presetting method

本方法SDN網(wǎng)絡(luò)的控制平面主要由拓?fù)溆?jì)算模塊、路由計(jì)算模塊和流表下發(fā)模塊組成.拓?fù)溆?jì)算模塊通過模擬獲得網(wǎng)絡(luò)拓?fù)洌宦酚捎?jì)算模塊進(jìn)行轉(zhuǎn)發(fā)規(guī)則的計(jì)算；流表下發(fā)模塊負(fù)責(zé)將轉(zhuǎn)發(fā)規(guī)則下發(fā).

工作流程分為4個(gè)步驟：

①拓?fù)溆?jì)算模塊收到反饋的Tnext后開啟計(jì)時(shí)，到時(shí)間后通過模擬衛(wèi)星的運(yùn)動(dòng)，得到ΔT后網(wǎng)絡(luò)的拓?fù)淝闆r，并發(fā)送給路由計(jì)算模塊；

②路由計(jì)算模塊收到拓?fù)浜?，?jì)算新的轉(zhuǎn)發(fā)規(guī)則，將結(jié)果交給流表下發(fā)模塊；

③路由計(jì)算模塊計(jì)算下一次的計(jì)算時(shí)間Tnext并反饋給拓?fù)溆?jì)算模塊；

④流表下發(fā)模塊將收到的轉(zhuǎn)發(fā)規(guī)則以流表?xiàng)l目的形式下發(fā)給對(duì)應(yīng)的節(jié)點(diǎn).

經(jīng)過上述步驟后，數(shù)據(jù)平面上的節(jié)點(diǎn)最終根據(jù)收到的流表?xiàng)l目進(jìn)行數(shù)據(jù)報(bào)文的轉(zhuǎn)發(fā).

3.2 路由計(jì)算模塊

3.2.1 計(jì)算鏈路生存時(shí)間

衛(wèi)星網(wǎng)絡(luò)雖然是一個(gè)無線網(wǎng)絡(luò)，但是不同于地面無線網(wǎng)絡(luò)的是，每個(gè)衛(wèi)星的運(yùn)動(dòng)是規(guī)律的、可預(yù)知的.例如，可以預(yù)先知道每個(gè)衛(wèi)星的運(yùn)動(dòng)軌跡以及在其通信范圍內(nèi)的衛(wèi)星.

基于上述特點(diǎn)，本文提出鏈路生存時(shí)間的概念.由于節(jié)點(diǎn)不斷運(yùn)動(dòng)，網(wǎng)絡(luò)中相鄰節(jié)點(diǎn)之間的一條鏈路持續(xù)一段時(shí)間后會(huì)因?yàn)楣?jié)點(diǎn)間距離不斷增加而斷開，這段持續(xù)時(shí)間稱為該條鏈路的鏈路生存時(shí)間.具體定義如下：

鏈路生存時(shí)間需要根據(jù)衛(wèi)星的三維坐標(biāo)進(jìn)行矢量計(jì)算.根據(jù)節(jié)點(diǎn)A和B的運(yùn)動(dòng)軌道的方程式和位置隨時(shí)間的變化計(jì)算節(jié)點(diǎn)間的距離，得到距離小于最大通信距離的時(shí)間范圍.從而計(jì)算出LinkA?B的鏈路生存時(shí)間.

每次運(yùn)行路由算法前，需要完成對(duì)網(wǎng)絡(luò)中每條鏈路的鏈路生存時(shí)間的計(jì)算，在路由算法中使用.完成路由計(jì)算后，路由計(jì)算模塊需要計(jì)算出Tnext并反饋給拓?fù)溆?jì)算模塊.顯然，下一次計(jì)算需要在任意鏈路LinkA?B∈KL斷開之前完成，結(jié)合鏈路生存時(shí)間的定義，Tnext的計(jì)算式如下

(1)

3.2.2 計(jì)算最短路徑

在本文研究的衛(wèi)星網(wǎng)絡(luò)中，節(jié)點(diǎn)產(chǎn)生的所有的數(shù)據(jù)均是發(fā)往GS的，數(shù)據(jù)流的路由路徑會(huì)形成一個(gè)以GS為根的樹狀結(jié)構(gòu).根據(jù)這一特點(diǎn)，路由計(jì)算模塊使用Dijkstra算法計(jì)算每個(gè)節(jié)點(diǎn)到GS的最短路徑.Dijkstra算法是經(jīng)典的單源最短路徑算法，被廣泛應(yīng)用于最短路徑的路由計(jì)算中.

基于以上原因，將Dijkstra算法中的鏈路代價(jià)設(shè)置為鏈路生存時(shí)間的倒數(shù)，利用Dijkstra算法計(jì)算出以地面站為根的最短路徑樹.

在完成每個(gè)節(jié)點(diǎn)的路徑計(jì)算后，還需要計(jì)算路徑的持續(xù)時(shí)間，其目的一是流表下發(fā)模塊需要確定流規(guī)則的有效時(shí)間，二是為了更簡(jiǎn)單地確定Tnext并反饋給拓?fù)溆?jì)算模塊.為此，本文中提出了節(jié)點(diǎn)路徑持續(xù)時(shí)間的概念，定義如下：

路徑持續(xù)時(shí)間的計(jì)算則利用樹的遞歸特性，計(jì)算公式如下(假設(shè)B到GS的下一跳為A)：

(2)

計(jì)算出路徑持續(xù)時(shí)間后，Tnext的計(jì)算可以簡(jiǎn)化為(網(wǎng)絡(luò)拓?fù)鋱D表示為G=)

(3)

3.2.3 新舊最短路徑樹的合并

3.2.2節(jié)為每個(gè)節(jié)點(diǎn)計(jì)算了新的最短路徑樹，但是考慮到此時(shí)衛(wèi)星網(wǎng)絡(luò)中正在使用上次計(jì)算下發(fā)的舊路徑樹，而需要新的最短路徑的節(jié)點(diǎn)僅為受斷開的鏈路影響的節(jié)點(diǎn)集Naffected，其他節(jié)點(diǎn)仍可使用舊的最短路徑進(jìn)行轉(zhuǎn)發(fā).直接將路由算法的結(jié)果下發(fā)的方式效率很低，且控制開銷較大.

針對(duì)上述情況，本文提出了一種將新舊最短路徑樹合并的算法，如圖3所示.

圖3 鏈路斷開時(shí)的處理結(jié)果Fig.3 Processing results when the link is down

(4)

找到受影響節(jié)點(diǎn)后，在Tpre+Tnext時(shí)刻新一次路由計(jì)算得到圖3(b)的計(jì)算最短路徑樹,之后根據(jù)新計(jì)算的路由規(guī)則，找到Naffected中的節(jié)點(diǎn)到GS路徑上所經(jīng)過的所有節(jié)點(diǎn)，其集合為Nroute.

進(jìn)行路徑樹合并時(shí)，只需要修改Naffected和Nroute中的節(jié)點(diǎn)轉(zhuǎn)發(fā)規(guī)則，其他節(jié)點(diǎn)不需要修改,得到圖3(c)的新最短路徑樹.詳細(xì)算法如下

算法1：最短路徑樹合并算法

輸入：Tnext, 拓?fù)鋱DG，持續(xù)時(shí)間集合Tlast，下一跳集合nextHop

輸出：新的Tlast，nextHop

1. Naffected = {Ni，Tlast[Ni] == Tnext }

2. status = {};

3. for 0 ≤ i< n do

4. Tlast[i] = Tlast[i] - Tnext

5. if i ∈Naffected then

6. status[i] = 1;

7. else

8. status[i] = 0;

9. end if;

10. end for;

11. Dijkstra算法根據(jù)G得到集合next_comp, T_compute;

12. for Ni ∈Naffected do

13. tmp = next_comp[Ni];

14. nextHop[Ni] = next_comp[Ni];

15. Tlast[Ni] = T_compute[Ni];

16. whiletmp != Dst and status[tmp] == 0 do

17. nextHop[tmp] = next_comp[tmp];

18. Tlast[tmp] = T_compute[tmp];

19. status[tmp] = 1; tmp = next_comp[tmp];

20. end while

21. end for

22. 輸出Tlast, nextHop

算法中第11行對(duì)應(yīng)圖3中的“計(jì)算的最短路徑樹”，next_comp和T_compute分別對(duì)應(yīng)由路由算法得到的下一跳集合和路徑持續(xù)時(shí)間集合.第1行到第10行確定所有的Naffected并且在第3行開始的循環(huán)中利用集合status對(duì)其進(jìn)行標(biāo)識(shí).第12行到第21行主要進(jìn)行最短路徑樹的合并，其中第16行開始的循環(huán)通過下一跳集合確定Nroute，最終得到新最短路徑樹.

上述合并算法可以在變動(dòng)最少的情況下，保證更新節(jié)點(diǎn)的路徑最優(yōu)、其他節(jié)點(diǎn)的路徑不差于舊規(guī)則.分3種情況討論：①對(duì)于Naffected和Nroute中的節(jié)點(diǎn)(圖3中白色節(jié)點(diǎn)I、J、K以及灰色節(jié)點(diǎn)B、D、E、F、G)，其轉(zhuǎn)發(fā)路徑是根據(jù)最新拓?fù)涫褂肈ijkstra算法計(jì)算的最佳路徑.②對(duì)于其他節(jié)點(diǎn)，若其路徑上沒有灰色節(jié)點(diǎn)(圖3中黑色節(jié)點(diǎn)A、C)，則轉(zhuǎn)發(fā)規(guī)則為舊的最短路徑.③若其經(jīng)過灰色節(jié)點(diǎn)(圖3中的黑色節(jié)點(diǎn)H)，由于GS到G的路徑符合情況1，G到H的路徑符合情況2，所以H的路徑優(yōu)于舊路徑.

綜上，最短路徑樹合并算法既確保了全網(wǎng)節(jié)點(diǎn)的轉(zhuǎn)發(fā)效率；同時(shí)也減少了需要修改的節(jié)點(diǎn)的數(shù)量.

3.2.4 設(shè)置觀測(cè)時(shí)間

雖然合并算法減少了控制平面和數(shù)據(jù)平面之間控制消息的數(shù)量，但是帶來了一個(gè)問題.很多時(shí)候會(huì)出現(xiàn)幾條屬于KL的鏈路，它們鏈路生存時(shí)間相近，就需要在斷開的時(shí)候分別進(jìn)行計(jì)算.如果能將這幾次時(shí)間相近的計(jì)算同時(shí)完成，將可以大大減少控制平面的計(jì)算量.

為了解決上述問題，設(shè)置觀測(cè)時(shí)間Tinterval，然后將所有的鏈路生存時(shí)間全部統(tǒng)一為Tinterval的倍數(shù)，不到Tinterval的則刪除，再進(jìn)行節(jié)點(diǎn)路由路徑的計(jì)算，如圖4所示,其中Tinterval=100 s.

(a)指示鏈路生存時(shí)間的網(wǎng)絡(luò)拓?fù)鋱D(單位:s)(b)指示觀測(cè)時(shí)間倍數(shù)的網(wǎng)絡(luò)拓?fù)鋱D(單位:Tinterval)

圖4利用觀測(cè)時(shí)間統(tǒng)一鏈路生存時(shí)間

Fig.4 Unifying link lifetime using observation time

將所有時(shí)間統(tǒng)一為倍數(shù)之后，在每次計(jì)算完成過后，至少會(huì)經(jīng)過Tinterval的時(shí)間才會(huì)需要進(jìn)行下一次的計(jì)算，不會(huì)出現(xiàn)很短時(shí)間后就需要再次計(jì)算的情況.

最后是Tinterval的取值問題，如果太大，會(huì)消除掉過多的鏈路，增加到終點(diǎn)的跳數(shù)；如果太小則會(huì)削弱Tinterval的作用.因此需要在這之間做折中，根據(jù)實(shí)驗(yàn)確定.

3.3 流表下發(fā)模塊

路由預(yù)先設(shè)置的另一個(gè)問題是每個(gè)節(jié)點(diǎn)中流表的同步生效問題.如果更新的節(jié)點(diǎn)出現(xiàn)部分使用舊規(guī)則，部分使用新規(guī)則的情況很容易導(dǎo)致路由環(huán)路.因此如何保證所有新規(guī)則同步生效決定了衛(wèi)星網(wǎng)絡(luò)的傳輸效率.工作流程如圖5所示.

圖5 流表修改過程Fig.5 Flow table modification process

為了使得不同節(jié)點(diǎn)中的規(guī)則能夠同時(shí)生效，本文將Openflow協(xié)議流表項(xiàng)中的優(yōu)先級(jí)(priority)和有效時(shí)間(hard_timeout)結(jié)合使用.優(yōu)先級(jí)需要先為每個(gè)節(jié)點(diǎn)定義一個(gè)優(yōu)先級(jí)pN，同時(shí)定義一個(gè)范圍Pbottom到Ptop作為路由預(yù)置的使用范圍.有效時(shí)間則為節(jié)點(diǎn)的路徑持續(xù)時(shí)間加上從計(jì)算到生效所需要的時(shí)間ΔT，這里利用觀測(cè)時(shí)間Tinterval，規(guī)定路由路徑的計(jì)算在生效前Tinterval進(jìn)行，這樣ΔT=Tinterval.整個(gè)過程分為

1)將每個(gè)節(jié)點(diǎn)的優(yōu)先級(jí)pN初始化為Pbottom；

經(jīng)過以上過程，新下發(fā)流規(guī)則后，節(jié)點(diǎn)的流表中會(huì)有優(yōu)先級(jí)高的舊規(guī)則，和優(yōu)先級(jí)低的新規(guī)則，在舊規(guī)則到期被移除后新規(guī)則就會(huì)自動(dòng)接力，實(shí)現(xiàn)每個(gè)節(jié)點(diǎn)之間的同步更新.

4 仿真結(jié)果及分析

實(shí)驗(yàn)使用RYU 4.34控制器和Riverbed Modeler 18.6仿真軟件聯(lián)合完成，對(duì)提出的路由預(yù)置方法進(jìn)行驗(yàn)證.目前Riverbed中的SDN交換機(jī)模型僅支持地面上的有線通信，本文對(duì)該交換機(jī)進(jìn)行修改，增加了無線通信功能，并支持根據(jù)導(dǎo)入的衛(wèi)星軌道進(jìn)行運(yùn)動(dòng).搭建大規(guī)模星群仿真場(chǎng)景，使用Riverbed中的SITL接口連通仿真環(huán)境和外部RYU控制器.實(shí)驗(yàn)中設(shè)計(jì)多個(gè)場(chǎng)景評(píng)估本文提出的路由預(yù)置方法的性能.由于常見的動(dòng)態(tài)路由協(xié)議中，OLSR路由協(xié)議發(fā)揮了MANET的特性，在衛(wèi)星網(wǎng)絡(luò)中的表現(xiàn)更好，因此將實(shí)驗(yàn)結(jié)果與OLSR路由協(xié)議進(jìn)行對(duì)比.

4.1 仿真參數(shù)設(shè)定

本文設(shè)計(jì)了60、120和180個(gè)節(jié)點(diǎn)3個(gè)不同規(guī)模的仿真實(shí)驗(yàn)場(chǎng)景，全網(wǎng)所有節(jié)點(diǎn)發(fā)送的業(yè)務(wù)總量大小從1.1～1.5 Mbps.雙層衛(wèi)星軌道，高度分別為500和700 km.地面站設(shè)置在西安.參數(shù)設(shè)置如下：仿真時(shí)間為3 600 s；同軌道面通信距離為4 500 km，異軌道面為1 200 km；同軌道面鏈路速率為1 Gbps，異軌道面為8 Mbps.

4.2 算法性能

本文的路由預(yù)置方法在控制器端的運(yùn)行時(shí)間如表2所示.

表2 算法執(zhí)行時(shí)間Tab.2 Algorithm execution time

表2結(jié)果顯示本文方法可以在5～10 ms內(nèi)完成對(duì)所有節(jié)點(diǎn)路由路徑的計(jì)算，幾乎不會(huì)對(duì)從計(jì)算到生效所需的時(shí)間ΔT產(chǎn)生影響，因此不會(huì)影響流規(guī)則中hard_timeout的準(zhǔn)確性.

表3展示了180個(gè)節(jié)點(diǎn)場(chǎng)景中不同觀測(cè)時(shí)間下采用新舊最短路徑樹合并的方法和直接下發(fā)新規(guī)則的方法，在下發(fā)的流表?xiàng)l目數(shù)量上作對(duì)比，其中Tinterval=1 s可以視為沒有設(shè)置觀測(cè)時(shí)間.可以看到采用合并的方法可以使控制器下發(fā)的流表?xiàng)l目數(shù)量降低50%以上，大大減少了網(wǎng)絡(luò)中控制消息的數(shù)量，減輕帶外信道通信鏈路的負(fù)擔(dān).

表3 每100 s下發(fā)的流表?xiàng)l目數(shù)量Tab.3 Numbers of stream per 100 s table entries distributed

另外，隨著Tinterval的增大，流表?xiàng)l目數(shù)量在逐漸減少，這是因?yàn)樵O(shè)置了Tinterval后，合并了時(shí)間相近的計(jì)算，減少了路由計(jì)算的次數(shù).從Tinterval=60 s開始，流表項(xiàng)數(shù)量的減少開始進(jìn)入瓶頸，變化趨于平穩(wěn).

表4展示了全網(wǎng)節(jié)點(diǎn)到地面站的最短路徑的跳數(shù)和Tinterval的關(guān)系，其中跳數(shù)隨著Tinterval增大而增大.這是設(shè)置Tinterval后，刪除拓?fù)渲械牟糠宙溌匪鶐淼挠绊?結(jié)合前面對(duì)流表?xiàng)l目數(shù)量的討論，本文后續(xù)的實(shí)驗(yàn)中，將Tinterval設(shè)置為60 s.

表4 全網(wǎng)節(jié)點(diǎn)到地面站的跳數(shù)Tab.4 Number of hops from the whole network node to the ground station

圖6展示了Tinterval=1 s和Tinterval=60 s時(shí)，流表?xiàng)l目數(shù)量隨節(jié)點(diǎn)數(shù)量的變化情況.可以看到直接下發(fā)方法和新舊合并方法的流表?xiàng)l目數(shù)量都和節(jié)點(diǎn)數(shù)量呈線性正比關(guān)系，因此前面對(duì)Tinterval取值的討論可以適用于不同大小的網(wǎng)絡(luò)規(guī)模.

圖6 節(jié)點(diǎn)數(shù)量和流表?xiàng)l目數(shù)量的關(guān)系Fig.6 Relationship between node number and flow table entry number

4.3 仿真結(jié)果

為了避免可能的隨機(jī)性帶來的影響，對(duì)比實(shí)驗(yàn)的數(shù)據(jù)均為運(yùn)行10次的平均值，3種不同規(guī)模實(shí)驗(yàn)場(chǎng)景的數(shù)據(jù)為不同業(yè)務(wù)量大小下的平均值.

圖7展示了3種場(chǎng)景大小下，路由預(yù)置方法和OLSR的端到端時(shí)延的變化趨勢(shì)；圖8則為180節(jié)點(diǎn)場(chǎng)景下時(shí)延隨業(yè)務(wù)量大小的變化.可以看到OLSR的時(shí)延隨業(yè)務(wù)量和網(wǎng)絡(luò)規(guī)模變化明顯，而路由預(yù)置方法則非常平穩(wěn)，都在100 ms左右.這是因?yàn)镺LSR的控制開銷會(huì)占用通信鏈路的帶寬，增加隊(duì)列阻塞的概率，且動(dòng)態(tài)路由算法的結(jié)果并非最優(yōu)；而本文的方法使用帶外信道的方式傳輸控制命令，不會(huì)對(duì)通信鏈路的帶寬造成影響，且使用Dijkstra算法計(jì)算路徑，是當(dāng)前拓?fù)湎碌淖顑?yōu)解.

圖7 網(wǎng)絡(luò)節(jié)點(diǎn)數(shù)量和時(shí)延的關(guān)系Fig.7 Relationship between the number of network nodes and delay

圖8 業(yè)務(wù)發(fā)送量和時(shí)延的關(guān)系Fig. 8 Relationship between service transmission volume and delay

兩種方法在3種場(chǎng)景大小下，丟包率的變化趨勢(shì)如圖9所示.由于OLSR的控制開銷和節(jié)點(diǎn)數(shù)量呈正比，節(jié)點(diǎn)數(shù)量增加后，控制開銷的數(shù)量也迅速增加，極大地占用了通信鏈路的資源，導(dǎo)致OLSR的丟包率隨節(jié)點(diǎn)數(shù)量的增加大幅上升.而路由預(yù)置方法采用集中式的控制方法，對(duì)節(jié)點(diǎn)數(shù)量的變化不敏感，因此相對(duì)平穩(wěn)，丟包率僅為0.3%.

圖9 網(wǎng)絡(luò)節(jié)點(diǎn)數(shù)量和丟包率的關(guān)系Fig. 9 Relationship between the number of network nodes and packet loss rate

路由預(yù)置方法和OLSR路由協(xié)議都需要一定的控制開銷，但是考慮到OLSR的控制開銷占用通信鏈路，而路由預(yù)置方法使用的是帶外信道，因此本文不對(duì)二者的控制開銷進(jìn)行對(duì)比.

5 結(jié)論

1)提出了一種衛(wèi)星網(wǎng)絡(luò)的路由預(yù)置方法，基于軟件定義網(wǎng)絡(luò)的思想提出了相應(yīng)的網(wǎng)絡(luò)架構(gòu)，并提出了路由計(jì)算和流表下發(fā)的策略.本文方法與OLSR方法進(jìn)行對(duì)比，在多種網(wǎng)絡(luò)規(guī)模和不同業(yè)務(wù)大小的場(chǎng)景下比較了丟包率和端到端時(shí)延.

2)結(jié)果表明，本文的路由預(yù)置方法具有更低的時(shí)延和丟包率，在衛(wèi)星網(wǎng)絡(luò)下的表現(xiàn)更好.

本文中的路由方法僅考慮了鏈路的生存時(shí)間，而并未考慮鏈路的負(fù)載量等因素，因此下一步的工作將在本文基礎(chǔ)上，結(jié)合軟件定義網(wǎng)絡(luò)的負(fù)載均衡做進(jìn)一步的研究.