基于確定性網(wǎng)絡(luò)的網(wǎng)端一體流量交換機制

王晨陽，張亞生

(中國電子科技集團公司 第五十四研究所，石家莊 050081)

0 引言

衛(wèi)星通信就是以衛(wèi)星作為“基站”來中繼轉(zhuǎn)發(fā)信號的通信方式，可以在多個地面站之間通信，衛(wèi)星通信可以對地面的實現(xiàn)近乎無縫的覆蓋，由于地面基站在沙漠、極地、海洋等地形環(huán)境下難以建造，因此地面網(wǎng)在全球范圍內(nèi)的通信都受到了限制[1]，而衛(wèi)星工作于幾百甚至上萬公里的太空軌道上，因此覆蓋范圍相比于傳統(tǒng)的移動通信系統(tǒng)要大得多，解決地面網(wǎng)的問題。

低軌衛(wèi)星通信是衛(wèi)星通信的重要組成部分，各種類型的低軌通信衛(wèi)星組合在一起形成了低軌星座，其傳輸路徑包括衛(wèi)星之間的星間鏈路以及衛(wèi)星和地面站、用戶間的星地鏈路，低軌衛(wèi)星系統(tǒng)可以接入高軌通信網(wǎng)和地面核心網(wǎng)，實現(xiàn)地網(wǎng)互聯(lián)等，構(gòu)成空天一體的信息傳輸處理體系。

低軌衛(wèi)星的主要優(yōu)勢在于以下幾點。首先，由于低軌衛(wèi)星軌道高度較低[2]，與地面的通信鏈路和星間鏈路距離較短，因此信號的傳播路徑相較于中高軌衛(wèi)星較短，傳播時延和傳播損耗均減小；其次，數(shù)顆低軌衛(wèi)星構(gòu)成的低軌衛(wèi)星網(wǎng)絡(luò)可以完整的連續(xù)的實現(xiàn)對包括高緯度區(qū)域在內(nèi)的全球覆蓋；此外，低軌衛(wèi)星大多體積較小，因此發(fā)射成本更低，可以大量發(fā)射，這樣即便個別衛(wèi)星節(jié)點出現(xiàn)問題，仍能保證通信系統(tǒng)的運轉(zhuǎn)，并且成本低的小型化低軌衛(wèi)星更加便于衛(wèi)星功能重構(gòu)，達到更加靈活和部署和功能性。

但低軌衛(wèi)星系統(tǒng)仍然存在一些缺陷和問題。衛(wèi)星網(wǎng)絡(luò)相比較于地面網(wǎng)絡(luò)來說，有較大的衛(wèi)星通信距離，并且擁有眾多衛(wèi)星節(jié)點的無線多跳網(wǎng)絡(luò)使得傳播時延遠大于地面絡(luò)。另外，低軌衛(wèi)星具有高動態(tài)性的特點，星間鏈路和星地鏈路高頻切換，拓撲結(jié)構(gòu)容易變化[3]，因此傳播時延變化也大，時間同步也難以利用。另外由于傳輸距離和鏈路信道會受到各種干擾，傳輸數(shù)據(jù)的誤碼率也大于地面網(wǎng)絡(luò)。

本文針對低軌衛(wèi)星的問題，提出研究內(nèi)容的需求，即為追求衛(wèi)星通信系統(tǒng)的低時延、確定性和高可靠性。針對該需求，研究地面確定性網(wǎng)絡(luò)中的關(guān)鍵技術(shù)和相關(guān)技術(shù)標準[4]，分析其優(yōu)缺點和適應性，設(shè)計了一種流量交換機制，聚焦在ATS流量整形優(yōu)先級和隊列選擇，著重解決確定性傳輸中隊列擁塞和丟包的問題。最終借助NS3軟件仿真，測試結(jié)果在本文提出的流量控制機制下，星上交換的流量丟包率有明顯下降，且資源利用率得到了提高。

1 網(wǎng)端一體的流量控制機制

1.1 低軌衛(wèi)星通信系統(tǒng)的組成

低軌衛(wèi)星系統(tǒng)的主要組成一般是三部分，即為用戶段、空間段以及地面段[5]。這三段各自的組成個體也不相同，并且有各自的功能。

1)用戶段：主要組成部分是各種用戶，包括各種類型的終端設(shè)備，如手機、車載終端等，終端用戶是整個系統(tǒng)的最邊緣部分，主要就是向衛(wèi)星網(wǎng)絡(luò)提起各種業(yè)務(wù)請求，只要在衛(wèi)星某一天線的波束覆蓋內(nèi)，就可以于衛(wèi)星之間形成一條通信鏈路實現(xiàn)信息交互和傳輸[6]。

2)空間段：主要組成部分是低軌通信衛(wèi)星，由一定數(shù)量的衛(wèi)星組成了衛(wèi)星星座，每顆衛(wèi)星是組成整個網(wǎng)絡(luò)各自的節(jié)點。各位衛(wèi)星之間也是固定格式的衛(wèi)星數(shù)據(jù)幀在星間鏈路中傳播。低軌衛(wèi)星的軌道高度一般是500～2 000公里。

3)地面段：主要組成部分就是地面的信關(guān)站。信關(guān)站是地面網(wǎng)和衛(wèi)星網(wǎng)之間互聯(lián)的橋梁，是實現(xiàn)地面用戶信息向衛(wèi)星傳輸和接受自衛(wèi)星的信息的重要連接點。當信關(guān)站在衛(wèi)星的可視范圍內(nèi)時，衛(wèi)星和地面信關(guān)站之間就可以實現(xiàn)包括各種信令和業(yè)務(wù)信息等數(shù)據(jù)。當信關(guān)站和衛(wèi)星間信號強度較弱時，就會以一定的方案選擇切換至其他衛(wèi)星。

1.2 地面確定性網(wǎng)絡(luò)到衛(wèi)星網(wǎng)絡(luò)

在地面網(wǎng)絡(luò)中，許多新興的服務(wù)和應用對網(wǎng)絡(luò)的性能提出了很高的要求，智能制造、汽車自動駕駛、遠程醫(yī)療等，這些應用對網(wǎng)絡(luò)傳輸?shù)囊笠呀?jīng)不僅是傳輸速率和帶寬的問題，能夠?qū)崿F(xiàn)端到端的確定性服務(wù)同樣至關(guān)重要，這其中包括帶寬、時延、抖動和丟包等指標要求，因此確定性網(wǎng)絡(luò)應運而生，它是網(wǎng)絡(luò)技術(shù)的一種新型服務(wù)質(zhì)量保障技術(shù)。

衛(wèi)星網(wǎng)絡(luò)相較于地面網(wǎng)絡(luò)更加復雜，特別是低軌星座的星間拓撲頻繁變化導致數(shù)據(jù)傳輸容易震蕩，衛(wèi)星相對于地面的高速移動則帶來客戶端變化頻繁、網(wǎng)內(nèi)流量需求大規(guī)模變化的問題，因此想要在低軌星座間實現(xiàn)確定性傳輸更加困難。因此在衛(wèi)星網(wǎng)絡(luò)中，假如單獨依靠低時延星載交換技術(shù)等方法，無法完全保證傳輸質(zhì)量，因為地面終端設(shè)備如果不對自己傳輸行為進行控制，很容易造成星上交換機的擁塞。

網(wǎng)絡(luò)傳輸保證服務(wù)質(zhì)量的通常手段包括擴容、流量整形、隊列調(diào)度和擁塞控制等。本文提出的問題場景在于解決丟包的問題，因此提出一種流量反饋控制機制，借助地面設(shè)備終端的行為控制，并和星上交換設(shè)備一體化處理，形成星地融合、網(wǎng)端一體的網(wǎng)絡(luò)傳輸架構(gòu)，解決星上交換擁塞和丟包的問題。

1.3 流量隊列反饋控制機制

星載交換機上可用的存儲資源有限，因此當網(wǎng)絡(luò)流量過大或存在突發(fā)流量時很很容易造成隊列的擁塞從而造成丟包,為了支撐確定性的端到端傳輸，實現(xiàn)低丟包甚至零丟包，必須要進行動態(tài)、高效的網(wǎng)絡(luò)資源分配，因此有必要設(shè)計星地一體、網(wǎng)端協(xié)同的傳輸架構(gòu)體系。本文采用星上反饋地面設(shè)備的流量交換控制機制[7]，基于圖1所示的隊列模型，這種機制的主要工作就是將星上緩存隊列狀態(tài)信息反饋給地面設(shè)備，地面設(shè)備收到廣播信息根據(jù)隊列調(diào)度算法調(diào)整相應隊列的帶寬分配，通過這種方式緩解流量過大或突發(fā)流量帶來的星上緩存擁塞問題[8]。

圖1 隊列模型和流量控制機制

地面設(shè)備調(diào)整流量隊列借助一定的流量調(diào)度算法，對發(fā)送到星上的鏈路幀進行編排，按照一定的規(guī)則分配合適的邏輯隊列[9]，不同的邏輯隊列發(fā)送到星上交換設(shè)備后，轉(zhuǎn)發(fā)至交換設(shè)備輸出端口的順序和優(yōu)先級是不同的，當?shù)孛嬖O(shè)備收到星上的廣播以后，修改鏈路幀具體的字段和參數(shù)，以此來控制發(fā)送到星上后屬于不同的虛擬輸出隊列，從而達到應對突發(fā)流量，緩解星上交換部分短時間擁塞的問題，提高系統(tǒng)的吞吐量，減少丟包。

反饋信息有兩類，一是通知給地面設(shè)備降低較高次序邏輯隊列的發(fā)送帶寬，提高低次序邏輯隊列的發(fā)送帶寬，從而緩解高次序隊列的擁塞問題；二是通知給地面設(shè)備提高較高次序邏輯隊列的發(fā)送帶寬，相應的低次序帶寬就會提高。具體兩種反饋信息的判定依據(jù)是在星上的緩存隊列設(shè)置兩個閾值，最大閾值Qmax和最小閾值Qmin，當星上的較高次序緩存隊列到達最大閾值，即發(fā)送反饋信息一，降低高次序隊列資源分配；當星上較高次序緩存隊列到達最小閾值，即發(fā)送反饋信息二，提高高次序隊列資源分配。

1.4 ATS異步流量整形調(diào)度算法

衛(wèi)星通信網(wǎng)絡(luò)的數(shù)據(jù)流量很大[10]，并且由于異軌道星間距離處在不斷變化之中，導致基于時間同步的轉(zhuǎn)發(fā)機制性能受到影響，所以采用異步的流量整形機制，即不需要全網(wǎng)時鐘同步，選擇ATS異步流量整形算法為地面設(shè)備分配帶寬，對傳輸?shù)逆溌穾M行控制，實現(xiàn)提出的反饋控制機制。即如果去往某個輸出端口的業(yè)務(wù)量較大時，采取網(wǎng)端一體的流量控制機制，通過星地廣播流控幀，通知地面設(shè)備減少流入的業(yè)務(wù)量，特別是去往某個端口的業(yè)務(wù)量，減少星上分組丟棄。

IEEE 802.1Qcr標準提出了基于UBS的ATS調(diào)度機制。IEEE 802.1Qcr標準中指出實現(xiàn)ATS調(diào)度機制的交換設(shè)備都需要對以下組件進行支持：流過濾器、服務(wù)數(shù)據(jù)單元過濾器、流門控、整形器、整形器組和傳輸選擇算法[11]，其整體架構(gòu)如圖2所示。

圖2 ATS調(diào)度機制的整體架構(gòu)

本文將ATS整形調(diào)度算法應用于星地間的流量交換控制機制，在本文提出的流量控制機制中，整個流程在從流門控輸出以前的部分都設(shè)置于地面設(shè)備，首先當數(shù)據(jù)幀從地面設(shè)備發(fā)送前通過stream_handle(IEEE Std 802.1CB中流識別功能的一個子參數(shù))和priority(VLAN標簽[12]中的優(yōu)先級字段)，這兩個字段對數(shù)據(jù)流進行識別和匹配，根據(jù)這一步的處理決定后續(xù)進入合適的流過濾器，不同的流過濾器后是相對應的流門控整形器進程處理，隨后進入數(shù)據(jù)處理單元，數(shù)據(jù)處理單元的的主要任務(wù)是過濾控制一定大小的數(shù)據(jù)幀，不符合要求的數(shù)據(jù)幀在數(shù)據(jù)處理單元處就會被丟棄；符合數(shù)據(jù)單元大小限制的數(shù)據(jù)幀會按照之前流過濾器匹配的指定，進入相應的流門控；在指定的流門控內(nèi)，數(shù)據(jù)幀會被分配一個內(nèi)部優(yōu)先級該優(yōu)先級就用于星上的隊列控制。通過地面設(shè)備的這些部分，各個數(shù)據(jù)幀被分析處理并分配了合適的內(nèi)部優(yōu)先級，經(jīng)處理后的數(shù)據(jù)幀隨后將會被傳輸?shù)叫巧?，在星上將會進行后續(xù)的處理。

星上設(shè)備接收到帶有內(nèi)部優(yōu)先級的數(shù)據(jù)幀后，應用基于令牌桶的交織整形算法，整形后的數(shù)據(jù)幀會被分配一個合格時間，合格時間用于后續(xù)計算傳輸選擇算法，并分配不同級別的轉(zhuǎn)發(fā)隊列。在整形器之后，數(shù)據(jù)幀就會按照合格時間的映射進入不通過次序的隊列排隊發(fā)送，排隊發(fā)送的基于嚴格的優(yōu)先級調(diào)度，高次序隊列傳輸先于低次序隊列，相對高次序隊列當前首個數(shù)據(jù)幀合格時間小于當前時間則發(fā)送，并重新開始執(zhí)行從高次序到低次序的傳輸算法，假如出現(xiàn)合格時間判定異常，即為收到地面設(shè)備的處理后的地面設(shè)備的控制，則轉(zhuǎn)而發(fā)送下一較低次序的傳輸隊列中的數(shù)據(jù)幀[13]，按照這樣的排隊序列，可以保證從地面設(shè)備發(fā)出的數(shù)據(jù)幀，按照發(fā)出時數(shù)據(jù)幀所要求的傳輸次序，在星上轉(zhuǎn)發(fā)時，按照要求的次序傳輸?shù)叫巧辖粨Q輸出端口，從而達到緩解星上緩存隊列擁塞丟包的問題。

2 仿真系統(tǒng)設(shè)計

2.1 NS3仿真軟件

NS3作為一個離散事件網(wǎng)絡(luò)模擬器，有很強的可擴展性與易用性，提供各種用于網(wǎng)絡(luò)仿真的API，可以在腳本中調(diào)用這些API，來構(gòu)建自己的仿真模型[14]。NS3的核心架構(gòu)和各種網(wǎng)絡(luò)通信模型是用C++實現(xiàn)的，并且用Python語言綁定，這樣就可以用Python語言編寫腳本，NS3的組織結(jié)構(gòu)如圖3所示，內(nèi)核和Network模塊可以為網(wǎng)絡(luò)仿真提供一般性服務(wù)，上層模塊可以根據(jù)不同的仿真場景進行選擇搭配[15]。

圖3 NS3的組織結(jié)構(gòu)

NS3內(nèi)核定義了其核心功能[16]，包括隨機變量(random variables)的生成、追蹤(tracing)、智能指針(smart pointers)、日志(logging)、事件調(diào)度(event scheduler)、屬性(attribute)、回調(diào)(callbacks)和時間記錄(time arithmetic)。

NS3中的基本網(wǎng)絡(luò)組件可分為以下四類。節(jié)點：各類通信設(shè)備的抽象化描述，可以通過添加移動模型設(shè)置初始位置與移動特征，能夠添加應用、協(xié)議、外部接口等；網(wǎng)卡及其驅(qū)動：能實現(xiàn)網(wǎng)絡(luò)連接的硬件設(shè)備和軟件驅(qū)動的抽象化描述，有各種不同類型的網(wǎng)卡：PointToPointNetDevice、WifiNetDevice等；信道：節(jié)點通過相應的信道和其它節(jié)點通信，包括CsmaChannel、WifiChannel等；應用程序：提供了管理用戶應用并設(shè)置數(shù)據(jù)收發(fā)格式的各種方法，包括UdpEchoClientApplication、UdpServerApplication等。

借助Helper類，輸入?yún)?shù)來節(jié)點個設(shè)置、網(wǎng)絡(luò)設(shè)備添加、協(xié)議棧安裝、應用程序設(shè)置、信道配置等操作，構(gòu)成網(wǎng)絡(luò)通信的基本模型，如圖4所示。

圖4 NS3中網(wǎng)絡(luò)通信的基本模型

利用NS3平臺實現(xiàn)網(wǎng)絡(luò)仿真，有五個基本步驟。第一步是設(shè)計仿真場景、仿真參數(shù)，例如節(jié)點個數(shù)、開始時間和仿真時長等。第二步是創(chuàng)建網(wǎng)絡(luò)拓撲，借助Helper類在節(jié)點上添加網(wǎng)絡(luò)設(shè)備，安裝協(xié)議棧和應用、配置移動模型等。第三步是在調(diào)度器中添加事件，收集仿真相關(guān)參數(shù)。第四步是啟動調(diào)度器，在仿真時間內(nèi)處理離散事件，完成待定任務(wù)。最后進行結(jié)果分析，可以通過Tracing收集網(wǎng)絡(luò)數(shù)據(jù)[17]，例如數(shù)據(jù)傳輸速率、丟包率等，借助統(tǒng)計模塊等進行分析，也可使用Wireshark等工具進行網(wǎng)絡(luò)分析。

NS3具有良好的可擴展性，可以方便地自己開發(fā)需要的模塊或者構(gòu)建自己的通信場景，比如本文仿真的衛(wèi)星場景，就要首先設(shè)計一個衛(wèi)星通信的場景，之后要將地面移動通信體制進行修改，使其適應于衛(wèi)星通信系統(tǒng)。

2.2 衛(wèi)星仿真系統(tǒng)設(shè)計

衛(wèi)星星座的星地鏈路間存在傳輸時延與自由空間損耗，其中影響星地時延的主要是地面用戶和衛(wèi)星的距離，而星地損耗由信號頻率、傳播距離決定，最終的接收功率還與發(fā)射功率、多波束天線的增益、用戶接收增益有關(guān)[18]。

整個仿真系統(tǒng)，借助NS3的基礎(chǔ)模型，模擬整個衛(wèi)星通信系統(tǒng)，星地鏈路模型以傳播時延模型PropagationDelayModel和自由空間傳輸損耗模型FreeSpaceLossModel為基礎(chǔ)，衛(wèi)星模塊主要結(jié)構(gòu)分model、helper、examples、doc子部分，這幾部分主要是衛(wèi)星模型底層源碼、實現(xiàn)特定功能的Helper類、測試與仿真、文檔說明，模型實現(xiàn)星歷文件解析、軌跡獲取、波束設(shè)計等功能。Satellite-beam類完成波束數(shù)量、波束增益、波束增益最大指向位置等的設(shè)置，SatHelper提供創(chuàng)建衛(wèi)星場景的接口，主程序傳入仿真時間與用戶數(shù)目等可變參數(shù)，過程需要解析星歷文件，初始化衛(wèi)星相關(guān)參數(shù)，計算衛(wèi)星運動軌跡、判斷是否閑置衛(wèi)星等功能[19]，場景設(shè)計的不同在于衛(wèi)星數(shù)量與用戶規(guī)模，本文測試的場景是小范圍場景，且仿真時間短，只需要數(shù)量很少的地面用戶，同時衛(wèi)星只需要加載在仿真時間內(nèi)的可見衛(wèi)星。建立衛(wèi)星、波束節(jié)點、用戶節(jié)點后，安裝相應的移動模型與波束天線模型后，可通過NetDevice類來設(shè)置頻率、切換算法等參數(shù)，衛(wèi)星場景將按既定規(guī)則運行。用戶初始位置與移動模型可以通過MobilityHelper這個幫助類進行設(shè)置，將地表某個區(qū)域隨機分布的用戶三維坐標依次添加到鏈式位置分配器(ListPositionAllocator)中，用戶運動模型可選擇固定位置、固定速度、固定加速度、隨機游走等模型[20]。

2.3 衛(wèi)星仿真系統(tǒng)參數(shù)設(shè)置

在NS3中構(gòu)建網(wǎng)絡(luò)仿真環(huán)境，仿真參數(shù)：仿真時間t=10 s; 本文為了測試該流量控制機制的性能，設(shè)置仿真場景較簡單，星上交換設(shè)備輸入輸出端口數(shù)，Nin=1，Nout=1；地面設(shè)備發(fā)送帶寬W=300 Mbps；包長度Ldata=1 000 Byte；地面設(shè)備為去往星上交換機基本帶寬均為6%；源節(jié)點發(fā)送數(shù)據(jù)包的起始時間t0設(shè)為隨機數(shù)，t0服從均勻分布。

為了測試該流量控制機制的性能，設(shè)計了四個應用場景，在場景一中，設(shè)置星上緩存隊列長度L為200(packet); 星上緩存隊列閾值Qmax和Qmin分別為170、100。

場景二改變緩存隊列閾值: 最大閾值Qmax和最小閾值Qmin分別為150、50，該場景是為了測試當最大閾值和最小閾值都減小時，星上緩存隊列的變化。

場景三設(shè)置星上緩存隊列閾值Qmax和Qmin分別為170、130，該場景主要測試當最小閾值較大時，對星上緩存隊列的影響。

場景四測試緩存隊列長度變化對該控制機制的性能有何影響，因此星上緩存隊列長度 設(shè)置為150，星上緩存隊列閾值Qmax和Qmin分別為120、80。

3 實驗結(jié)果與分析

地面設(shè)備向上行鏈路發(fā)送數(shù)據(jù)鏈路幀，觀察星上輸入端口的虛擬輸出隊列長度Lq變化，隨著時間增加，星上輸入端口中高次序虛擬輸出隊列Lq1長度增大。星上輸入端口中高次序隊列Lq1和低次序隊列Lq2實時隊列長度變化情況如圖5所示，從圖中可以看出，高次序隊列在持續(xù)接受地面設(shè)備發(fā)來的鏈路幀一段時間后，達到星上緩存隊列的設(shè)置長度200后，會逐漸出現(xiàn)丟包情況。

圖5 反饋前輸入端口0中Lq1、Lq2實時隊列長度

之后測試當流量控子模塊程序啟動后，星上實時隊列的長度。如圖6所示，可以觀察到場景1到場景3在反饋后輸入端口隊列Lq1實時長度。

圖6 三個場景星上輸入端口中Lq1實時隊列長度

首先分析場景一，當Lq1到達最大閾值Qmax后，根據(jù)流量控制機制的流程，星載交換設(shè)備將會廣播隊列狀態(tài)信息，地面設(shè)備接收星上的反饋信息，高次序分配的帶寬資源減少，Lq1的鏈路幀數(shù)量明顯降低；隨著鏈路幀的持續(xù)減少，當Lq1到達最小閾值Qmin后，與之前方式相同，地面設(shè)備接收到反饋信息，增加高次序隊列的帶寬資源分配，隨后Lq1的實時隊列長度開始增加。

對于場景二來說，與場景一對比起來，場景二減小了最小閾值的大小，相比于場景一，隊列長度增加、減少的時間間隔較小，并且最大的實時隊列長度也較小，說明減小最大閾值確實限制了實時隊列長度，但是場景二最小閾值偏小，在調(diào)整至最低點的前后一小段時間內(nèi)，星上實時緩存隊列長度都保持較低的狀態(tài)，資源利用率較低。

場景三相較于場景一大幅提高了最小閾值的值，最大閾值和最小閾值相差較小，因此經(jīng)反饋后星上Lq1隊列長度變化范圍較小，說明最小閾值的設(shè)置限制了緩存隊列中鏈路幀的不斷減小，隊列長度不斷在小范圍內(nèi)波動變化，相較于大范圍內(nèi)波動來說，總吞吐量要更加大，因此資源利用率也較高，但是星載交換機需要不斷的向地面設(shè)備廣播緩存隊列狀態(tài)信息。

反饋后場景一、二、三中星上輸入端口Lq2的實時隊列長度變化情況如圖7所示。

圖7 三個場景中星上輸入端口到Lq2實時隊列長度

為了具體衡量資源利用情況，對三個場景在流量控制機制使用前后的兩個隊列的吞吐量和總吞吐量進行計算比較，結(jié)果如表1所示。(吞吐量(bps) =包數(shù)*包長* 8 /仿真時間)

表1 反饋前后吞吐量對比 bps

在流量控制機制的作用下，反饋前高次序隊列Lq1的丟包數(shù)為440包，低次序隊列Lq2的丟包數(shù)為0；反饋后三個場景中兩個隊列的丟包率均為0，因此該機制對解決丟包的問題效果顯著。由于地面設(shè)備受到反饋信息的控制，因此高次序隊列Lq1實時隊列的長度總是處在最大閾值和最小閾值之間，幾乎不存在隊列長度數(shù)值穩(wěn)定的情況，因此相較于反饋前，反饋后Lq1的總包數(shù)一定會減少，因此吞吐量也會減少，而由于Lq1的資源減少使得Lq2得到的資源分配增加，因此相較于反饋前，反饋后到低次序隊列Lq2的總包數(shù)有所增加；經(jīng)計算后總吞吐量相較于反饋前也有所增加，這驗證了該流量控制機制對于提高星上資源的利用有效。對于高次序隊列Lq1來說，場景三設(shè)置的最大最小閾值間隔較小的情況下，高次序隊列Lq1的吞吐量相較于場景一來說更有優(yōu)勢，但是低次序隊列Lq2的吞吐量和總吞吐量相較于場景一卻不再有優(yōu)勢。

場景四在場景一的基礎(chǔ)上減小了星上緩存隊列長度為150，如圖8所示是場景四反饋前后，星上輸入端口中Lq1的實時隊列長度變化。

圖8 場景四反饋前后星上輸入端口Lq1實時隊列長度

從圖中可以看出，與場景三類似，場景四中減少最大最小閾值間隔，因此Lq1隊列長度不斷在小范圍內(nèi)波動變化，作為對比，反饋前后，星上輸入端口中Lq2的實時隊列長度變化情況如圖9。

圖9 場景四反饋前后星上輸入Lq2實時隊列長度

與其他場景類似，在流量控制機制的影響下，高次序隊列Lq1的帶寬分配降低就會帶來低次序隊列Lq2的帶寬資源增加。

場景四中，反饋前后上行鏈路發(fā)送至兩個輸出端口的兩個隊列的包數(shù)及上行鏈路總吞吐量對比如表2所示。

表2 場景四反饋前后吞吐量對比 bps

場景四反饋前隊列丟包數(shù)為400(packet)，隊列丟包數(shù)為0；反饋后隊列丟包數(shù)為15，隊列的丟包數(shù)為0。與場景一相比，場景四中反饋前后上行鏈路發(fā)往高次序隊列的吞吐量和反饋后上行鏈路總吞吐量都略有降低。值得關(guān)注的是，由于場景四中星上緩存空間有限，因此雖然反饋后，隊列的丟包問題得到改善，但是鏈路幀仍然有一定的溢出，這說明了星上緩存空間相比較于傳輸帶寬的極限仍較小時，就無法避免丟包的問題。

通過四個場景對流量控制機制進行仿真分析，首先本文提出的星地流量交換控制機制對解決星上交換的流量擁塞丟包問題有一定的優(yōu)化效果，但是參數(shù)設(shè)置會在一定程度上影響流量控制機制的性能。其中，星上緩存隊列的最大最小閾值影響很大。當最大閾值設(shè)置很大，逼近甚至超越星上緩存隊列時，流量控制機制就在一定程度上失效，星上的緩存隊列仍然解決不了丟包的問題；假如像場景二中，最大閾值設(shè)置過小，則隊列長時間處于一個空閑的狀態(tài)，因此資源利用率較低；假如像場景三中，最大閾值和最小閾值之間差距較小，則緩存隊列的長度會快速波動，這樣會產(chǎn)生一定不必要的開銷，同時對于整個鏈路的吞吐量增大沒用幫助；另外像場景四中測試分析的，星上初始的緩存隊列長度選擇也十分重要，應當接近傳輸帶寬的極限，假如星上緩存隊列長度相較于傳輸帶寬的極限仍然較小時，即便最大閾值設(shè)置合理，那么實際的隊列長度仍然可能逼近甚至超過星上設(shè)置的緩存隊列長度，因此會造成鏈路幀的溢出，產(chǎn)生丟包的問題。

4 結(jié)束語

為了節(jié)約寶貴的衛(wèi)星帶寬資源，提高衛(wèi)星網(wǎng)絡(luò)流量轉(zhuǎn)發(fā)的效率，減少丟包。本文深入研究了確定性網(wǎng)絡(luò)的相關(guān)技術(shù)標準，并結(jié)合低軌衛(wèi)星網(wǎng)絡(luò)和具體特點，提出一種適用于低軌衛(wèi)星的星地流量交換機制，借助ATS異步流量整形算法，提出了一種星地之間交互、網(wǎng)端一體的流量控制機制，并利NS3仿真，測試了該機制的性能并作出了相關(guān)分析。測試結(jié)果表明，在應用了該流量控制機制后，星上轉(zhuǎn)發(fā)效率得到提高，星上緩存資源得到充分利用，緩解了隊列擁塞的問題，解決了大流量下丟包的問題。