劉尚昆

（中央廣播電視總臺(tái)，北京 100859）

0 引 言

隨著社會(huì)的發(fā)展，人們對(duì)于網(wǎng)絡(luò)和通信的要求已經(jīng)不局限于有線和基于通信基站的無線通信。目前在光纖覆蓋區(qū)域，高速、低延時(shí)的無線、有線通信網(wǎng)絡(luò)已經(jīng)能夠充分滿足各行各業(yè)對(duì)于數(shù)據(jù)傳輸?shù)男枨螅貏e針對(duì)媒體行業(yè)，大容量多媒體數(shù)據(jù)的傳輸在上述環(huán)境下已經(jīng)得以滿足。然而對(duì)于一些特殊行業(yè)而言，其工作場景往往較為復(fù)雜，在有線網(wǎng)絡(luò)尚未覆蓋或通信光纜暫未覆蓋的區(qū)域，如高山、沙漠、草原、海洋等環(huán)境下，網(wǎng)絡(luò)基礎(chǔ)設(shè)施不可能完全覆蓋。要想獲得高質(zhì)量的網(wǎng)絡(luò)通信服務(wù)，只能借助衛(wèi)星實(shí)現(xiàn)地空網(wǎng)絡(luò)的交互。傳統(tǒng)的衛(wèi)星通信環(huán)境較復(fù)雜，衛(wèi)星資源較緊張，因此，傳輸速率、傳輸時(shí)延都無法與有線網(wǎng)絡(luò)相比擬。隨著空間技術(shù)的發(fā)展，高速、低時(shí)延的寬帶衛(wèi)星網(wǎng)絡(luò)成為可能。隨著全球空間競賽的展開，各國開始利用低軌、中軌、高軌衛(wèi)星搭建覆蓋全球的通信網(wǎng)絡(luò)。對(duì)于很多場景而言，傳統(tǒng)的光纖通信網(wǎng)絡(luò)無法覆蓋到，只有借助衛(wèi)星網(wǎng)絡(luò)完成通信。

對(duì)于傳媒行業(yè)而言，利用網(wǎng)絡(luò)進(jìn)行大容量的多媒體數(shù)據(jù)傳輸是重要環(huán)節(jié)之一。高實(shí)時(shí)性的數(shù)據(jù)傳輸能夠有效確保信息的及時(shí)傳達(dá)，保障新聞資訊的時(shí)效性。因此，傳媒行業(yè)是最先利用衛(wèi)星通信方式進(jìn)行多媒體數(shù)據(jù)傳輸?shù)男袠I(yè)之一。以衛(wèi)星電視和直播為例，利用衛(wèi)星進(jìn)行全球?qū)崟r(shí)轉(zhuǎn)播，已經(jīng)成為很多重要賽事和活動(dòng)的首選傳播途徑。然而，當(dāng)前面對(duì)多媒體大容量數(shù)據(jù)，寬帶衛(wèi)星網(wǎng)絡(luò)還有諸多限制，比如時(shí)延較高、帶寬不足等問題。針對(duì)帶寬不足問題，實(shí)質(zhì)上只要部署足夠的衛(wèi)星資源即可應(yīng)對(duì)。然而，對(duì)于時(shí)延問題，則需要從多方面予以解決[1]。目前主流的思想是面向通信協(xié)議進(jìn)行時(shí)延優(yōu)化。本文將圍繞寬帶衛(wèi)星網(wǎng)絡(luò)多媒體大容量數(shù)據(jù)短時(shí)延傳輸進(jìn)行研究，對(duì)相應(yīng)的技術(shù)和方法進(jìn)行設(shè)計(jì)驗(yàn)證，進(jìn)而獲得更高的實(shí)時(shí)性。

1 衛(wèi)星網(wǎng)絡(luò)及其通信流程

衛(wèi)星網(wǎng)絡(luò)實(shí)質(zhì)上是以衛(wèi)星作為通信鏈路的中轉(zhuǎn)和路由設(shè)備，使得地面設(shè)備之間、空間設(shè)備與地面設(shè)備、空間設(shè)備之間能夠相互通信。圖1展示了一套完整的LEO寬帶衛(wèi)星網(wǎng)絡(luò)系統(tǒng)。

圖1 衛(wèi)星網(wǎng)絡(luò)通信示意圖

如圖1所示，空中多個(gè)衛(wèi)星共同構(gòu)建了類似地面蜂窩網(wǎng)絡(luò)的星間鏈路，確保地面相應(yīng)區(qū)域始終有衛(wèi)星信號(hào)覆蓋。當(dāng)?shù)孛婊蚩臻g需要進(jìn)行網(wǎng)絡(luò)通信時(shí)，用戶側(cè)終端設(shè)備利用手持終端將數(shù)據(jù)發(fā)送至衛(wèi)星，由衛(wèi)星對(duì)數(shù)據(jù)包進(jìn)行接收、調(diào)解、交換、變頻，并進(jìn)一步選擇適當(dāng)?shù)穆酚蛇M(jìn)行傳遞，進(jìn)而將數(shù)據(jù)傳遞到目標(biāo)地址。該過程可表述為圖2。由此可看到，當(dāng)終端與用戶端建立連接后，衛(wèi)星網(wǎng)絡(luò)用戶之間的交互就可以單純通過衛(wèi)星網(wǎng)絡(luò)進(jìn)行，擺脫了對(duì)地面基礎(chǔ)設(shè)施的依賴。當(dāng)然，與傳統(tǒng)網(wǎng)絡(luò)進(jìn)行交互，還是要通過信關(guān)站進(jìn)行中轉(zhuǎn)[2]。

圖2 衛(wèi)星網(wǎng)絡(luò)通信關(guān)鍵流程

2 IP網(wǎng)絡(luò)時(shí)延及其構(gòu)成

網(wǎng)絡(luò)時(shí)延是指在通信網(wǎng)絡(luò)中一個(gè)報(bào)文從發(fā)出方到達(dá)目的地所需要的時(shí)間。網(wǎng)絡(luò)時(shí)延是任何類型網(wǎng)絡(luò)都不可避免的一個(gè)現(xiàn)象，通常被用來評(píng)估網(wǎng)絡(luò)質(zhì)量。圖3對(duì)網(wǎng)絡(luò)傳輸?shù)倪^程以及時(shí)延的分布進(jìn)行了列舉[3]。從網(wǎng)絡(luò)時(shí)延的構(gòu)成來看，網(wǎng)絡(luò)時(shí)延可分為節(jié)點(diǎn)時(shí)延以及傳輸時(shí)延。

圖3 網(wǎng)絡(luò)傳輸過程示意圖

節(jié)點(diǎn)時(shí)延是指在各個(gè)傳輸節(jié)點(diǎn)上所消耗的時(shí)間，可進(jìn)一步分為處理時(shí)延、排隊(duì)時(shí)延以及發(fā)送時(shí)延。當(dāng)數(shù)據(jù)包流向某個(gè)節(jié)點(diǎn)后，該節(jié)點(diǎn)首先對(duì)數(shù)據(jù)包頭部進(jìn)行解析，并進(jìn)一步校驗(yàn)數(shù)據(jù)包完整性、分配傳輸路徑，這些處理過程的耗時(shí)統(tǒng)一被稱為處理時(shí)延。當(dāng)數(shù)據(jù)包在節(jié)點(diǎn)上處理完成后，將進(jìn)入鏈路傳輸隊(duì)列，此時(shí)等待前序鏈路數(shù)據(jù)包傳輸完成的時(shí)間即為排隊(duì)時(shí)延。而發(fā)送時(shí)延則是路由節(jié)點(diǎn)將數(shù)據(jù)包完整發(fā)出到鏈路上所消耗的時(shí)間，該時(shí)間可通過鏈路傳輸速率和數(shù)據(jù)包大小來計(jì)算[4]。

傳輸時(shí)延是指數(shù)據(jù)包從一端路由設(shè)備到另一端路由設(shè)備的總耗時(shí)。該時(shí)延可通過兩路由間的距離、介質(zhì)傳輸速率來計(jì)算。

由上述兩類時(shí)延可看到，對(duì)于數(shù)據(jù)包較小的報(bào)文，其網(wǎng)絡(luò)時(shí)延中處理時(shí)延占比較高；而對(duì)于數(shù)據(jù)包較大的報(bào)文，傳輸時(shí)延占比較高。在網(wǎng)絡(luò)的傳輸距離和傳輸介質(zhì)（傳輸方式）既定的情況下，傳輸時(shí)延只能靠路由算法分配更短的傳輸距離來縮減，而處理時(shí)延則需要對(duì)現(xiàn)有的節(jié)點(diǎn)處理邏輯進(jìn)行優(yōu)化。

3 寬帶衛(wèi)星網(wǎng)絡(luò)對(duì)TCP性能的影響分析

TCP協(xié)議是一種典型的互聯(lián)網(wǎng)協(xié)議。在TCP連接建立過程中，發(fā)送與接收端將進(jìn)行三次握手，并通過握手?jǐn)?shù)據(jù)包判斷是否完成了建立，以及通道是否需要維持。這一過程中，TCP設(shè)置了一系列的指標(biāo)作為判斷和邏輯依據(jù)。在常規(guī)的地面網(wǎng)絡(luò)環(huán)境下，TCP協(xié)議能夠很好地支撐各類應(yīng)用。

與傳統(tǒng)網(wǎng)絡(luò)環(huán)境相比，衛(wèi)星網(wǎng)絡(luò)環(huán)境下的信道、傳輸模式往往更復(fù)雜，典型的影響如下。

3.1 傳輸時(shí)延顯著增加

首先，擁塞窗口會(huì)表現(xiàn)出增長緩慢的問題。TCP協(xié)議通常根據(jù)傳輸數(shù)據(jù)的大小對(duì)窗口容量進(jìn)行動(dòng)態(tài)調(diào)整。然而衛(wèi)星通信環(huán)境下，數(shù)據(jù)往返存在較大延遲，這就使得窗口的調(diào)整更加緩慢。這一現(xiàn)象使得TCP連接過程始終處于慢啟動(dòng)狀態(tài)，網(wǎng)絡(luò)帶寬無法高效利用。在多媒體大容量數(shù)據(jù)傳輸時(shí)，TCP整體的傳輸效率顯著降低[5]。

其次，丟失數(shù)據(jù)包檢測的時(shí)間會(huì)顯著拉長。TCP協(xié)議會(huì)根據(jù)數(shù)據(jù)包的超時(shí)情況判斷數(shù)據(jù)包是否丟失，并判斷是否進(jìn)行補(bǔ)發(fā)，以保證數(shù)據(jù)完整性。然而在地空通信中，往返時(shí)延（Round-Trip Time，RTT）值可能因衛(wèi)星網(wǎng)絡(luò)的高動(dòng)態(tài)性表現(xiàn)出跳動(dòng)較大的特性，這就使得TCP協(xié)議在測量RTT的時(shí)候無法獲得客觀精準(zhǔn)的數(shù)值，進(jìn)而做出不正確的重發(fā)，降低總體傳輸效率，提升總體時(shí)延。

最后，存在接收窗口受阻情況。前文提到，衛(wèi)星通信下，TCP協(xié)議可能長時(shí)間處于慢啟動(dòng)狀態(tài)，這就使得接收窗口大部分處于受阻狀態(tài)。式1表述了往返時(shí)延與窗口大小的關(guān)系。

式中：Tmax為傳輸速率，RTT為往返延時(shí)，Wmax為窗口大小。由式（1）可以看到，最大傳輸速率與RTT成反比，與Wmax成正比。對(duì)于TCP協(xié)議，單窗口傳輸上限為64k，在RTT無法顯著降低且窗口受阻的情況下，數(shù)據(jù)傳輸同樣存在限制。

3.2 數(shù)據(jù)存在更高的誤碼率

任何網(wǎng)絡(luò)通信都有一定的誤碼率。誤碼出現(xiàn)后，將會(huì)觸發(fā)重發(fā)機(jī)制，進(jìn)而增加時(shí)延。對(duì)于衛(wèi)星通信而言，可能存在兩種情形。

其一是數(shù)據(jù)包損壞引發(fā)的誤碼。在傳統(tǒng)地面?zhèn)鬏斶^程中，通常較難出現(xiàn)因傳輸導(dǎo)致的數(shù)據(jù)包損壞，而地空通信中，這一問題出現(xiàn)的概率更高。當(dāng)出現(xiàn)數(shù)據(jù)包損壞，TCP協(xié)議無法分辨，會(huì)認(rèn)為是擁塞導(dǎo)致的問題，因此會(huì)自動(dòng)降低傳輸速率。這就顯著提高了傳輸時(shí)延。

其二，在確實(shí)由于擁塞導(dǎo)致的數(shù)據(jù)包丟失情形下，TCP協(xié)議本身并無較好的處理方式，只能通過逐個(gè)確認(rèn)并恢復(fù)的機(jī)制對(duì)數(shù)據(jù)包進(jìn)行重發(fā)和補(bǔ)全，這會(huì)顯著增加處理時(shí)延。

3.3 收發(fā)速率不對(duì)稱

衛(wèi)星鏈路的不對(duì)稱是其天然特性之一。這是由于衛(wèi)星設(shè)備轉(zhuǎn)發(fā)資源昂貴且受限。這一現(xiàn)狀會(huì)使得發(fā)送端往往不能及時(shí)獲得反饋信息，數(shù)據(jù)包確認(rèn)慢。同時(shí)，由于雙向通信不對(duì)稱，可能觸發(fā)重發(fā)機(jī)制，降低通信效率。此外，數(shù)據(jù)突發(fā)也是其典型的現(xiàn)象之一。上述問題同樣會(huì)顯著拉長傳輸和處理時(shí)延。

4 基于TCP優(yōu)化的寬帶衛(wèi)星網(wǎng)絡(luò)多媒體大容量數(shù)據(jù)短時(shí)延傳輸方法

從上述論述可以看出，傳統(tǒng)TCP協(xié)議在衛(wèi)星寬帶通信中存在適應(yīng)性問題，特別是在衛(wèi)星通信環(huán)境下，傳統(tǒng)TCP協(xié)議會(huì)增加傳輸時(shí)延和處理時(shí)延。因此，針對(duì)多媒體大容量數(shù)據(jù)傳輸，要獲得更低的衛(wèi)星通信時(shí)延，就需要對(duì)TCP協(xié)議進(jìn)行適當(dāng)優(yōu)化。

4.1 TCP參數(shù)優(yōu)化

在時(shí)延優(yōu)化方面，首先可從降低節(jié)點(diǎn)處理時(shí)延的角度入手。對(duì)TCP協(xié)議而言，節(jié)點(diǎn)轉(zhuǎn)發(fā)中處理的內(nèi)容主要是TCP的頭。從前文的分析中可看到，在TCP協(xié)議中，窗口增加會(huì)顯著增加傳輸效率。目前較為常見的TCP協(xié)議有RFC1323協(xié)議和RFC2414協(xié)議。在進(jìn)行TCP協(xié)議優(yōu)化時(shí)，通過對(duì)RFC1323模塊進(jìn)行修改，增加窗口數(shù)，進(jìn)而擴(kuò)大吞吐量，是顯著提升傳輸效率的方法之一[6]。式（2）表示了窗口大小與擁塞之間的關(guān)系。

式中：MSS表示最大分段大小，W表示窗口大小。以式（2）為例，若在擴(kuò)大窗口時(shí)產(chǎn)生了擁塞，則自動(dòng)將窗口設(shè)置為1。利用這一規(guī)則，也可考慮通過修改TCP的RFC2414協(xié)議中的窗口初始參數(shù)，縮短設(shè)備啟動(dòng)時(shí)長，進(jìn)而提高TCP傳輸效率。

這一優(yōu)化思路不通過延遲對(duì)窗口進(jìn)行縮減，能夠顯著縮短啟動(dòng)時(shí)間。此時(shí)的啟動(dòng)時(shí)間可表達(dá)為式（3）。

式中：Tss表示慢啟動(dòng)時(shí)間，WA表示最大允許接收窗口，W1表示初始窗口。

這一機(jī)制能夠?qū)Υ翱谶M(jìn)行動(dòng)態(tài)調(diào)整，以適應(yīng)特殊情形，縮短慢啟動(dòng)周期，提升處理和傳輸效率，降低時(shí)延。然而，這一修改可能導(dǎo)致誤碼率的增加，因此還需要進(jìn)一步對(duì)協(xié)議進(jìn)行優(yōu)化。

4.2 協(xié)議優(yōu)化

單純提高吞吐性能無法解決誤碼率問題，因此還需要對(duì)協(xié)議進(jìn)行優(yōu)化、完善。

4.2.1 利用ACK字節(jié)確定擁塞窗口大小

TCP協(xié)議的擁塞控制對(duì)發(fā)送端設(shè)置了擁塞窗口（cwnd），其表示發(fā)送端在未經(jīng)接收方反饋確認(rèn)的情況下可發(fā)送的最大數(shù)據(jù)量。發(fā)送端根據(jù)cwnd的大小提供相應(yīng)的硬件緩沖資源。增大cwnd，能夠有效提升發(fā)送效率。同時(shí)，TCP通信中設(shè)置了確認(rèn)字符（ACK），主要用于通知發(fā)送方已接收到數(shù)據(jù)?；谶@一原理，將cwnd的確定方式修改為受限字節(jié)計(jì)數(shù)方式，即基于收到的受限的ACK字節(jié)數(shù)調(diào)整cwnd，通過該方式有約束地動(dòng)態(tài)調(diào)整阻塞窗口的大小，能夠在穩(wěn)定安全的前提下降低丟包率，提升傳輸效率。

4.2.2 引入選擇確認(rèn)機(jī)制（SACK）

選擇確認(rèn)機(jī)制（SACK）是TCP協(xié)議針對(duì)失序數(shù)據(jù)包設(shè)計(jì)的一種確認(rèn)機(jī)制。若TCP數(shù)據(jù)包按順序收到，則接收方會(huì)返回ACK；若接收方收到的數(shù)據(jù)包并未按編號(hào)順序，則接收方會(huì)返回SACK。發(fā)送方接到SACK后，可以通過自己的已發(fā)送數(shù)據(jù)包記錄找到前序丟失的數(shù)據(jù)包，并補(bǔ)充發(fā)送。通過這一機(jī)制，系統(tǒng)能夠在數(shù)據(jù)丟失的RTT內(nèi)，自動(dòng)進(jìn)行檢測和恢復(fù)。傳統(tǒng)的確認(rèn)機(jī)制是逐一確認(rèn)，此次優(yōu)化可利用選擇確認(rèn)機(jī)制，降低不必要的確認(rèn)數(shù)據(jù)包，進(jìn)而提升TCP的處理響應(yīng)效率。

4.2.3 應(yīng)用Lincoln鏈路層方案

Lincoln鏈路層方案是為了應(yīng)對(duì)衛(wèi)星信道動(dòng)態(tài)切換問題而提出的。該方案通過對(duì)幀進(jìn)行分塊、選擇和重組，改變了原有的穩(wěn)定鏈路下的數(shù)據(jù)包轉(zhuǎn)發(fā)邏輯。該方案下，數(shù)據(jù)信息得以快速獲取，數(shù)據(jù)的恢復(fù)率和時(shí)效性大大提升，進(jìn)而降低了重發(fā)重試比例，對(duì)于數(shù)據(jù)傳輸延時(shí)有明顯的降低作用。同時(shí)，這一機(jī)制對(duì)于誤碼和丟失進(jìn)行了應(yīng)對(duì)，避免了數(shù)據(jù)擁塞。星鏈自身的特點(diǎn)是動(dòng)態(tài)信道遷移，在這一場景下鏈路常常會(huì)發(fā)生變動(dòng)，誤碼和丟失可能頻發(fā)。通過Lincoln鏈路層方案對(duì)幀的特殊處理機(jī)制，可進(jìn)一步降低數(shù)據(jù)傳輸延遲。

4.2.4 增加錯(cuò)誤檢測機(jī)制

傳統(tǒng)TCP中對(duì)于鏈路擁塞錯(cuò)誤并未分類處理，常規(guī)情況下就是重發(fā)重試。當(dāng)遇到擁塞，往往動(dòng)態(tài)降低窗口數(shù)，進(jìn)而降低鏈路速率，縮短阻塞。然而擁塞原因較多，只有通過增加錯(cuò)誤檢測機(jī)制，對(duì)實(shí)際引發(fā)擁塞的機(jī)制進(jìn)行排查，才能夠有效應(yīng)對(duì)錯(cuò)誤[7]。

4.3 TCP Vegas算法優(yōu)化

Vegas算法本身是一種擁塞評(píng)估算法。通過觀測RTT值的變化，對(duì)網(wǎng)絡(luò)鏈路擁塞情況進(jìn)行評(píng)估，進(jìn)而對(duì)網(wǎng)絡(luò)進(jìn)行適當(dāng)調(diào)整。Vegas算法的關(guān)鍵參數(shù)有期望傳輸速率、實(shí)際傳輸速率以及實(shí)際傳輸帶寬。式（4）表示了期望傳輸速率：

式中：RE表示期望速率，Wc(t)表示t時(shí)刻擁塞窗口大小cwnd，Tb為所觀測到的鏈路中的最小往返時(shí)間（RTT）。式5表示了實(shí)際傳輸速率：

式中：RA表示實(shí)際速率，Tr為實(shí)際往返時(shí)間，Wc(t)表示t時(shí)刻擁塞窗口大小cwnd。式（6）則表示了實(shí)際傳輸帶寬：

式中：Δ表示當(dāng)前預(yù)估帶寬?；谶@一數(shù)據(jù)為基礎(chǔ)來評(píng)估擁塞情況，并動(dòng)態(tài)調(diào)整窗口，進(jìn)而控制速率，平衡傳輸與擁塞。

然而，星鏈的動(dòng)態(tài)性使得網(wǎng)絡(luò)變化頻率大大增加。以LEO衛(wèi)星網(wǎng)絡(luò)為例，傳輸距離始終隨著距離變化而變動(dòng)，這就使得RTT隨時(shí)處于動(dòng)態(tài)更新的狀態(tài)。對(duì)極軌道星座而言，衛(wèi)星之間高速的相互運(yùn)動(dòng)，以及衛(wèi)星與極地之間的高速位置變化，使得網(wǎng)絡(luò)拓?fù)浣Y(jié)構(gòu)有較高的變化頻率，極端情況下每20 s就可能變動(dòng)一次。上述情形使得通信延時(shí)顯著增加[8]。

針對(duì)上述現(xiàn)狀，本文提出對(duì)Vegas算法的優(yōu)化方法。根據(jù)前文所述，因星鏈的特殊性，通信延時(shí)中傳播延時(shí)是隨機(jī)波動(dòng)的，因此在降低延時(shí)的過程中，主要考慮從星上處理時(shí)延方面入手。對(duì)Vegas算法而言，只有通過對(duì)擁塞情況進(jìn)行真實(shí)評(píng)估，才能夠有效降低處理時(shí)延[9]。具體應(yīng)對(duì)方案如下。

4.3.1 修改時(shí)間戳的功能與組成

新增進(jìn)隊(duì)列時(shí)間in_time、出隊(duì)列時(shí)間out_time、節(jié)點(diǎn)處理時(shí)間node_time記錄，以及最大節(jié)點(diǎn)處理時(shí)間max_node_time。這些信息需在原有TCP協(xié)議時(shí)間戳部分額外增加，長度共計(jì)16 bytes。

4.3.2 記錄星上處理時(shí)延

當(dāng)信息被傳遞到下一個(gè)星鏈節(jié)點(diǎn)時(shí)，下一個(gè)星鏈節(jié)點(diǎn)同樣記錄本次時(shí)間，并用本次處理時(shí)間對(duì)比最大處理時(shí)間。若本次時(shí)間大于最大處理時(shí)間，則替換該值。通過這一機(jī)制確保這里記錄的是整個(gè)鏈路上節(jié)點(diǎn)處理的最大值。

4.3.3 可用帶寬估算算法修改

星上處理時(shí)延數(shù)據(jù)通過ACK回傳至發(fā)送端，即可獲得真實(shí)的擁塞情況[10]。此時(shí)，原Vegas算法中的吞吐量評(píng)估算法需要進(jìn)行修改。這里需要借助排隊(duì)延時(shí)對(duì)吞吐量進(jìn)行評(píng)估：定義S為星上緩存大小，定義Vr為發(fā)射速率，定義Tq為星上最大排隊(duì)延時(shí)，則有：

此時(shí)，可由式（8）來評(píng)估當(dāng)前的網(wǎng)絡(luò)負(fù)載情況：

式中：Δ表示負(fù)載指數(shù)，Tpmax表示當(dāng)前最大排隊(duì)時(shí)延，Tq為星上最大排隊(duì)延時(shí)。

根據(jù)該數(shù)據(jù)，進(jìn)一步評(píng)估窗口調(diào)整算法，如式（9）所示：

式中：Wc(t)為t時(shí)刻的窗口大小。

4.4 優(yōu)化效果評(píng)估

為對(duì)本次所設(shè)計(jì)的衛(wèi)星寬帶多媒體大容量低時(shí)延傳輸方法性能進(jìn)行驗(yàn)證，利用仿真模型對(duì)吞吐、時(shí)延進(jìn)行研究。

本次建立的實(shí)驗(yàn)仿真拓?fù)浣Y(jié)構(gòu)如圖4所示。設(shè)置衛(wèi)星緩存為50 packets，星上轉(zhuǎn)發(fā)速率為10 Mb·s-1，星間鏈路與星地帶寬為25 MHz和15 MHz。報(bào)文定義為200 bit，初始窗口設(shè)定為25。

圖4 仿真拓?fù)浣Y(jié)構(gòu)

基于上述仿真環(huán)境，對(duì)本次所設(shè)計(jì)的TCP優(yōu)化下的Vegas算法和傳統(tǒng)Vegas算法分別進(jìn)行仿真，可看到吞吐量和時(shí)延的顯著變化，具體如圖5所示?？梢钥吹?，優(yōu)化的Vegas算法，其吞吐率可基本穩(wěn)定在0.6左右，相比于傳統(tǒng)Vegas算法頻繁波動(dòng)且低于0.2的平均吞吐率而言，優(yōu)化的Vegas算法更加穩(wěn)定。從表1可看出，兩種算法的延時(shí)分布情況較顯著，優(yōu)化后的Vegas算法延時(shí)穩(wěn)定在9～16 ms，而傳統(tǒng)Vegas算法延時(shí)則在12～35 ms，大容量傳輸時(shí)延控制有效。

圖5 仿真吞吐率

表1 算法仿真時(shí)延分布對(duì)比

5 結(jié) 語

本文圍繞大容量多媒體數(shù)據(jù)在寬帶衛(wèi)星網(wǎng)絡(luò)中的傳輸時(shí)延問題進(jìn)行了研究，特別針對(duì)短時(shí)延傳輸方法提出對(duì)TCP協(xié)議進(jìn)行優(yōu)化，同時(shí)對(duì)于擁塞評(píng)估和處理算法Vegas進(jìn)行優(yōu)化。對(duì)于傳媒行業(yè)而言，本文方法能夠顯著提升數(shù)據(jù)的傳輸性能，在無有線網(wǎng)絡(luò)覆蓋的區(qū)域能夠獲得高實(shí)時(shí)性的數(shù)據(jù)傳輸服務(wù)，進(jìn)而提升媒體信息的時(shí)效性。本次所研究的相關(guān)方法能夠進(jìn)一步推廣至其他衛(wèi)星網(wǎng)絡(luò)應(yīng)用場景，使得寬帶衛(wèi)星網(wǎng)絡(luò)的場景適應(yīng)性更強(qiáng)。