寬帶衛星網絡多媒體大容量數據短時延傳輸方法

劉尚昆

（中央廣播電視總臺，北京 100859）

0 引 言

隨著社會的發展，人們對于網絡和通信的要求已經不局限于有線和基于通信基站的無線通信。目前在光纖覆蓋區域，高速、低延時的無線、有線通信網絡已經能夠充分滿足各行各業對于數據傳輸的需求，特別針對媒體行業，大容量多媒體數據的傳輸在上述環境下已經得以滿足。然而對于一些特殊行業而言，其工作場景往往較為復雜，在有線網絡尚未覆蓋或通信光纜暫未覆蓋的區域，如高山、沙漠、草原、海洋等環境下，網絡基礎設施不可能完全覆蓋。要想獲得高質量的網絡通信服務，只能借助衛星實現地空網絡的交互。傳統的衛星通信環境較復雜，衛星資源較緊張，因此，傳輸速率、傳輸時延都無法與有線網絡相比擬。隨著空間技術的發展，高速、低時延的寬帶衛星網絡成為可能。隨著全球空間競賽的展開，各國開始利用低軌、中軌、高軌衛星搭建覆蓋全球的通信網絡。對于很多場景而言，傳統的光纖通信網絡無法覆蓋到，只有借助衛星網絡完成通信。

對于傳媒行業而言，利用網絡進行大容量的多媒體數據傳輸是重要環節之一。高實時性的數據傳輸能夠有效確保信息的及時傳達，保障新聞資訊的時效性。因此，傳媒行業是最先利用衛星通信方式進行多媒體數據傳輸的行業之一。以衛星電視和直播為例，利用衛星進行全球實時轉播，已經成為很多重要賽事和活動的首選傳播途徑。然而，當前面對多媒體大容量數據，寬帶衛星網絡還有諸多限制，比如時延較高、帶寬不足等問題。針對帶寬不足問題，實質上只要部署足夠的衛星資源即可應對。然而，對于時延問題，則需要從多方面予以解決[1]。目前主流的思想是面向通信協議進行時延優化。本文將圍繞寬帶衛星網絡多媒體大容量數據短時延傳輸進行研究，對相應的技術和方法進行設計驗證，進而獲得更高的實時性。

1 衛星網絡及其通信流程

衛星網絡實質上是以衛星作為通信鏈路的中轉和路由設備，使得地面設備之間、空間設備與地面設備、空間設備之間能夠相互通信。圖1展示了一套完整的LEO寬帶衛星網絡系統。

圖1 衛星網絡通信示意圖

如圖1所示，空中多個衛星共同構建了類似地面蜂窩網絡的星間鏈路，確保地面相應區域始終有衛星信號覆蓋。當地面或空間需要進行網絡通信時，用戶側終端設備利用手持終端將數據發送至衛星，由衛星對數據包進行接收、調解、交換、變頻，并進一步選擇適當的路由進行傳遞，進而將數據傳遞到目標地址。該過程可表述為圖2。由此可看到，當終端與用戶端建立連接后，衛星網絡用戶之間的交互就可以單純通過衛星網絡進行，擺脫了對地面基礎設施的依賴。當然，與傳統網絡進行交互，還是要通過信關站進行中轉[2]。

圖2 衛星網絡通信關鍵流程

2 IP網絡時延及其構成

網絡時延是指在通信網絡中一個報文從發出方到達目的地所需要的時間。網絡時延是任何類型網絡都不可避免的一個現象，通常被用來評估網絡質量。圖3對網絡傳輸的過程以及時延的分布進行了列舉[3]。從網絡時延的構成來看，網絡時延可分為節點時延以及傳輸時延。

圖3 網絡傳輸過程示意圖

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

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

由上述兩類時延可看到，對于數據包較小的報文，其網絡時延中處理時延占比較高；而對于數據包較大的報文，傳輸時延占比較高。在網絡的傳輸距離和傳輸介質（傳輸方式）既定的情況下，傳輸時延只能靠路由算法分配更短的傳輸距離來縮減，而處理時延則需要對現有的節點處理邏輯進行優化。

3 寬帶衛星網絡對TCP性能的影響分析

TCP協議是一種典型的互聯網協議。在TCP連接建立過程中，發送與接收端將進行三次握手，并通過握手數據包判斷是否完成了建立，以及通道是否需要維持。這一過程中，TCP設置了一系列的指標作為判斷和邏輯依據。在常規的地面網絡環境下，TCP協議能夠很好地支撐各類應用。

與傳統網絡環境相比，衛星網絡環境下的信道、傳輸模式往往更復雜，典型的影響如下。

3.1 傳輸時延顯著增加

首先，擁塞窗口會表現出增長緩慢的問題。TCP協議通常根據傳輸數據的大小對窗口容量進行動態調整。然而衛星通信環境下，數據往返存在較大延遲，這就使得窗口的調整更加緩慢。這一現象使得TCP連接過程始終處于慢啟動狀態，網絡帶寬無法高效利用。在多媒體大容量數據傳輸時，TCP整體的傳輸效率顯著降低[5]。

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

最后，存在接收窗口受阻情況。前文提到，衛星通信下，TCP協議可能長時間處于慢啟動狀態，這就使得接收窗口大部分處于受阻狀態。式1表述了往返時延與窗口大小的關系。

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

3.2 數據存在更高的誤碼率

任何網絡通信都有一定的誤碼率。誤碼出現后，將會觸發重發機制，進而增加時延。對于衛星通信而言，可能存在兩種情形。

其一是數據包損壞引發的誤碼。在傳統地面傳輸過程中，通常較難出現因傳輸導致的數據包損壞，而地空通信中，這一問題出現的概率更高。當出現數據包損壞，TCP協議無法分辨，會認為是擁塞導致的問題，因此會自動降低傳輸速率。這就顯著提高了傳輸時延。

其二，在確實由于擁塞導致的數據包丟失情形下，TCP協議本身并無較好的處理方式，只能通過逐個確認并恢復的機制對數據包進行重發和補全，這會顯著增加處理時延。

3.3 收發速率不對稱

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

4 基于TCP優化的寬帶衛星網絡多媒體大容量數據短時延傳輸方法

從上述論述可以看出，傳統TCP協議在衛星寬帶通信中存在適應性問題，特別是在衛星通信環境下，傳統TCP協議會增加傳輸時延和處理時延。因此，針對多媒體大容量數據傳輸，要獲得更低的衛星通信時延，就需要對TCP協議進行適當優化。

4.1 TCP參數優化

在時延優化方面，首先可從降低節點處理時延的角度入手。對TCP協議而言，節點轉發中處理的內容主要是TCP的頭。從前文的分析中可看到，在TCP協議中，窗口增加會顯著增加傳輸效率。目前較為常見的TCP協議有RFC1323協議和RFC2414協議。在進行TCP協議優化時，通過對RFC1323模塊進行修改，增加窗口數，進而擴大吞吐量，是顯著提升傳輸效率的方法之一[6]。式（2）表示了窗口大小與擁塞之間的關系。

式中：MSS表示最大分段大小，W表示窗口大小。以式（2）為例，若在擴大窗口時產生了擁塞，則自動將窗口設置為1。利用這一規則，也可考慮通過修改TCP的RFC2414協議中的窗口初始參數，縮短設備啟動時長，進而提高TCP傳輸效率。

這一優化思路不通過延遲對窗口進行縮減，能夠顯著縮短啟動時間。此時的啟動時間可表達為式（3）。

式中：Tss表示慢啟動時間，WA表示最大允許接收窗口，W1表示初始窗口。

這一機制能夠對窗口進行動態調整，以適應特殊情形，縮短慢啟動周期，提升處理和傳輸效率，降低時延。然而，這一修改可能導致誤碼率的增加，因此還需要進一步對協議進行優化。

4.2 協議優化

單純提高吞吐性能無法解決誤碼率問題，因此還需要對協議進行優化、完善。

4.2.1 利用ACK字節確定擁塞窗口大小

TCP協議的擁塞控制對發送端設置了擁塞窗口（cwnd），其表示發送端在未經接收方反饋確認的情況下可發送的最大數據量。發送端根據cwnd的大小提供相應的硬件緩沖資源。增大cwnd，能夠有效提升發送效率。同時，TCP通信中設置了確認字符（ACK），主要用于通知發送方已接收到數據。基于這一原理，將cwnd的確定方式修改為受限字節計數方式，即基于收到的受限的ACK字節數調整cwnd，通過該方式有約束地動態調整阻塞窗口的大小，能夠在穩定安全的前提下降低丟包率，提升傳輸效率。

4.2.2 引入選擇確認機制（SACK）

選擇確認機制（SACK）是TCP協議針對失序數據包設計的一種確認機制。若TCP數據包按順序收到，則接收方會返回ACK；若接收方收到的數據包并未按編號順序，則接收方會返回SACK。發送方接到SACK后，可以通過自己的已發送數據包記錄找到前序丟失的數據包，并補充發送。通過這一機制，系統能夠在數據丟失的RTT內，自動進行檢測和恢復。傳統的確認機制是逐一確認，此次優化可利用選擇確認機制，降低不必要的確認數據包，進而提升TCP的處理響應效率。

4.2.3 應用Lincoln鏈路層方案

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

4.2.4 增加錯誤檢測機制

傳統TCP中對于鏈路擁塞錯誤并未分類處理，常規情況下就是重發重試。當遇到擁塞，往往動態降低窗口數，進而降低鏈路速率，縮短阻塞。然而擁塞原因較多，只有通過增加錯誤檢測機制，對實際引發擁塞的機制進行排查，才能夠有效應對錯誤[7]。

4.3 TCP Vegas算法優化

Vegas算法本身是一種擁塞評估算法。通過觀測RTT值的變化，對網絡鏈路擁塞情況進行評估，進而對網絡進行適當調整。Vegas算法的關鍵參數有期望傳輸速率、實際傳輸速率以及實際傳輸帶寬。式（4）表示了期望傳輸速率：

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

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

式中：Δ表示當前預估帶寬。基于這一數據為基礎來評估擁塞情況，并動態調整窗口，進而控制速率，平衡傳輸與擁塞。

然而，星鏈的動態性使得網絡變化頻率大大增加。以LEO衛星網絡為例，傳輸距離始終隨著距離變化而變動，這就使得RTT隨時處于動態更新的狀態。對極軌道星座而言，衛星之間高速的相互運動，以及衛星與極地之間的高速位置變化，使得網絡拓撲結構有較高的變化頻率，極端情況下每20 s就可能變動一次。上述情形使得通信延時顯著增加[8]。

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

4.3.1 修改時間戳的功能與組成

新增進隊列時間in_time、出隊列時間out_time、節點處理時間node_time記錄，以及最大節點處理時間max_node_time。這些信息需在原有TCP協議時間戳部分額外增加，長度共計16 bytes。

4.3.2 記錄星上處理時延

當信息被傳遞到下一個星鏈節點時，下一個星鏈節點同樣記錄本次時間，并用本次處理時間對比最大處理時間。若本次時間大于最大處理時間，則替換該值。通過這一機制確保這里記錄的是整個鏈路上節點處理的最大值。

4.3.3 可用帶寬估算算法修改

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

此時，可由式（8）來評估當前的網絡負載情況：

式中：Δ表示負載指數，Tpmax表示當前最大排隊時延，Tq為星上最大排隊延時。

根據該數據，進一步評估窗口調整算法，如式（9）所示：

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

4.4 優化效果評估

為對本次所設計的衛星寬帶多媒體大容量低時延傳輸方法性能進行驗證，利用仿真模型對吞吐、時延進行研究。

本次建立的實驗仿真拓撲結構如圖4所示。設置衛星緩存為50 packets，星上轉發速率為10 Mb·s-1，星間鏈路與星地帶寬為25 MHz和15 MHz。報文定義為200 bit，初始窗口設定為25。

圖4 仿真拓撲結構

基于上述仿真環境，對本次所設計的TCP優化下的Vegas算法和傳統Vegas算法分別進行仿真，可看到吞吐量和時延的顯著變化，具體如圖5所示。可以看到，優化的Vegas算法，其吞吐率可基本穩定在0.6左右，相比于傳統Vegas算法頻繁波動且低于0.2的平均吞吐率而言，優化的Vegas算法更加穩定。從表1可看出，兩種算法的延時分布情況較顯著，優化后的Vegas算法延時穩定在9～16 ms，而傳統Vegas算法延時則在12～35 ms，大容量傳輸時延控制有效。

圖5 仿真吞吐率

表1 算法仿真時延分布對比

5 結 語

本文圍繞大容量多媒體數據在寬帶衛星網絡中的傳輸時延問題進行了研究，特別針對短時延傳輸方法提出對TCP協議進行優化，同時對于擁塞評估和處理算法Vegas進行優化。對于傳媒行業而言，本文方法能夠顯著提升數據的傳輸性能，在無有線網絡覆蓋的區域能夠獲得高實時性的數據傳輸服務，進而提升媒體信息的時效性。本次所研究的相關方法能夠進一步推廣至其他衛星網絡應用場景，使得寬帶衛星網絡的場景適應性更強。