星間網絡中對TCP捎帶確認模式的驗證和改良

韓冰，龔文斌

（中科院上海微系統與信息技術研究所上海200050）

星間鏈路不同于地面鏈路，具有傳輸線路長，易受干擾的特點，而北斗的星間鏈路傳輸速率一般不超過51.2 kpbs，有明確的限制。加上既有的建鏈目的節點分布不均，路徑規劃不合理等問題，使得星間網絡極易產生阻塞的狀況，延遲特性差，最長時延超標的問題極為突出。這在境內衛星向境外衛星發送數據時尤為明顯。如何降低星間網絡延遲，提高星間網絡傳輸質量，已成為我國北斗衛星的戰略重點[1]。

文獻[2-3]通過優化路由算法，通過降低跳數和合理設計傳輸路徑的方式來提高整網的性能，文獻[4-5]從鏈路分配問題上入手，提出了更為合理的分配方式，文獻[6-7]則是針對Walker星座作了對應的優化，力圖設計更為合理的星座以改善整個整網的傳輸環境。這些研究大多是從星座結構、路徑優化和鏈路分配著手，來提升整網性能，少有研究針對星間鏈路信息流本身的傳輸模式。本文基于對現有星間網絡信息流組成結構的研究入手，針對性傳統TCP的傳輸模式有效信息流利用率太差的問題，設計一種適合星間網絡傳輸的TCP捎帶確認模式，期望通過精簡信息流，提高有效信息流利用率的方式來改善星間網絡擁塞的環境，改善時延特性。

1 信息流模型

衛星星間鏈路[8]主要有3種信息流[9]，遙控、遙測和運控信息，圖1為信息流模型。

相關定義如下:S1～S3為3種信息流的總幀數，SE為有效幀數，SA為確認幀數，SR為重傳幀數，SAR為重傳確認幀數。AS1～AS30為發送 ACK 計數值，AR1～AR30為接收ACK的計數值。

圖1 整星對外信息流

遙控信息和運控信息由地面站和運控站向可見衛星發送，遙控信息負責管理衛星的日常運行，運控信息則承載著衛星的具體業務，這兩種信息流均很重要，故采用TCP模式進行傳輸，故遙控和運控的信息流幀數構成為:

遙測信息無論是下發遙測還是星間傳輸，都具有一定的重復性，足以彌補誤碼率帶來的負面影響，故通常采用UDP模式傳輸。遙測的信息流構成為:

由此可見，相比遙測，遙控和運控的傳輸模式其有效信息流利用率不到一半，我們優化的重點在于對傳統TCP的傳輸模式的改良。

2 TCP捎帶確認模式設計

從對信息流的分析可知，確認幀和重傳確認幀并不承擔具體業務，卻大大增加了星間網絡的負擔，是網絡更為擁塞，應將確認幀作為首要優化對象，把確認幀所承載的信息放入正好要回傳的信息流（改良數據幀的幀頭，使其容納此確認幀信息），該承載的信息流可以是運控轉發，遙控轉發，遙測信息中的任何一種。

TCP捎帶確認方式的傳輸模式如圖2所示。

在這種模式下，星間網絡遙控和運控的信息流幀數構成為:

圖2 TCP捎帶確認模式

通過這種方式，我們可以節省確認幀和重傳確認幀的開銷。由于每次運控和遙控的信息我們都采用的是確認幀機制，所以理論上我們降低了運控和遙控的一半開銷。

地面捎帶確認模式和相關研究過于復雜，且沒有考慮星間網絡根據路由表時隙表傳輸的特點，并不適合星間網絡，我們需要重新實現星間網絡的捎帶確認模式，以北斗30星為實驗背景，星間網絡的捎帶確認模式，具體實現步驟為：

1）將每個衛星遙控和運控的緩存細分為30個。本星的每個緩存對應一個它星臨時存儲發送給此衛星的星間數據包，并額外存儲對應此衛星的AS和AR兩個值。

2）當A星向B星之間發送運控和遙控的信息流時，我們讓A星緩存中ASA的值+1。

3）B星收到來自A星的信息后，B星對應A星的緩存中ARB值+1。每次B星向外發送數據，均會征詢對應其他29星的運控和遙控緩存。

4）B星再次向A星發送數據時，若查到對應的ARB值不為0，會將此ARB的值放入發送的數據包，記錄所需回傳的ACK個數。

5）A星接收到B星的數據包以后，拆包查看包頭中裝有對應ARB的位置，讓ASA-ARB，以此確認收到多少個應收的ACK，并丟掉相應的已緩存的數據包。

6）若超過指定時間未收到ACK，則須開啟重傳機制[10]再次發送緩存的數據包；若再次發送仍未收到ACK，則扔掉緩存的數據包并將ASA值-1。

注:由于星間網絡的特殊性，衛星能力有限，通過設置ACK編號的方式來設計捎帶確認模式開銷過大，并不十分可行，故采用計數方式。

3 仿真結果

本文實驗仿真數據是通過聯合軟仿進行的北斗30星星間鏈路模擬的一周運轉仿真結果，傳輸速率設置為102.4 kbps。

其時延統計如表1所示，mode1為傳統TCP模式，mode2為TCP捎帶確認模式。

由于更改傳輸模式的方法本質是通過精簡信息流改善改善網絡擁塞狀況，以此來優化時延特性，故我們增添傳輸速率為51.2 kbps時的實驗作為比較，使整網環境更為苛刻，網絡擁塞狀況更為嚴重，表2為51.2 kbps時的時延統計。

表1 102.4 kbps的傳輸時延

表2 51.2 kbps的傳輸時延

如表中所示，無論是境內傳輸還是境外傳輸，TCP捎帶模式比TCP模式在時延特性上表現更為優越，尤其是最大時延和平均時延特性的提升。而隨著整網環境的苛刻化，這種表現更為突出。

為了進一步驗證實驗結果，本文在51.2 kbps的傳輸條件下，對上注信息傳輸的時延分布做了相應的統計，如圖3和圖4所示。

圖3 mode1在51.2 kbps速率下的時延分布

如圖所示，如兩組時延分布圖所示，TCP捎帶模式的運控信息和遙控信息的高時延信息分布均有下降，更多的信息被及時傳到。

圖4 mode2在51.2 kbps速率下的時延分布

4 TCP捎帶確認模式的改良

本文針對另一個較為重要的屬性，重傳率，對兩者進行了比較，如表3所示。

表3 兩個模式重傳率的比較

上表顯示TCP捎帶模式相對于傳統TCP模式，在重傳率上不增反降。網絡阻塞問題的緩解優化了星間網絡環境，提升了時延性能，但是在重傳率上并未帶來理想的結果。

故有必要進一步跟蹤重傳包，并分析其原因（見圖5）。

圖5 重傳包傳輸時延分析

由此可見，由于傳統TCP模式接收到信息立刻發送確認幀，而TCP捎帶模式接收到信息后，并不是立即發送回傳的ACK，而是等待目的衛星回傳的信息捎帶回傳ACK，是一種延時回傳機制。由于衛星的規律性并不能保證目的衛星時刻可見，且需要根據時隙表和路由表配合傳送數據，故會造成小部分信息等待回傳的時間過長，這種情況一方面會導致衛星內部緩存積壓，另一方面會導致回傳超時，觸發重傳，變相增加運行于星間網絡的信息流總量，從而惡化星間網絡。

同時，我們發現，星間網絡的重傳幀大量集中于傳輸延時超過15秒的幀，而這些幀本身占比也很少，故僅針對這類數據，設置合適的閾值[11-13]，切換回傳統TCP模式，可以緩解重傳率的問題。但切換回傳統TCP模式后，重傳率雖大為改善，這部分切換回去的信息流并未得到精簡，因為回傳的ACK幀和重傳幀一樣都增加了信息流總量。

由于本文設計的捎帶確認傳輸已經是一種延時回傳的策略，所以與Block-ACK[14-16]延時回傳策略有良好的兼容性，即在達到時間閾值之后，將積壓的ACK打包成一幀進行發送。鑒于現在使用的是ACK計數的方式，故只需發送并清零ARB即可，可確保這部分的信息幀得到大量的精簡，雖然不如捎帶確認方式，但相對于傳統TCP模式，仍然有效提升了信息流利用率。

具體步驟:

1）A星向B星傳送數據數據到達目的衛星B后，衛星B的對應緩存在累計幀計數ARB的同時記錄系統時間戳與之綁定，只在ARB從0到非0的時候記錄，之后的累加不更新時間戳。

2）當A星對B星可見時，意味著此時可以發送相應的數據，B星掃描自己的緩存，找到ARB對應的時間戳，將此時的系統時間與緩存中的時間戳作比較，若超過閾值，則切換為Block-ACK延時回傳策略，單獨回傳攜帶ARB的確認幀，僅需發送一幀。

3）本次實驗閾值設置為30秒，根據是65秒重傳的設置，以及時隙表60秒會重復一次的特點。表4為此次實驗針對重傳率的結果。表5為實現切換策略之后的試驗統計，mode3為切換模式。

表4 兩種方式在重傳率上的比較

表5 51.2 kbps的傳輸時延

如上表所示，通過這種方法，降低了衛星重傳率，進一步改善了星間網絡環境，由此改善了時延特性。

5 結論

本文針對星間網絡運控和遙控信息流，提出一種適合星間網絡傳輸的TCP捎帶確認模式，通過精簡信息流提升信息流利用率的方式，提升星間網絡的性能。并通過細分緩存和ACK計數的方式設計，使這種模式更為適配星間網絡。實驗數據表明，這種傳輸模式下星間網絡的時延特性，相對于傳統TCP模式有了顯著的提升。

同時，針對延時回傳的模式造成一小部分確認信息回傳不及時的特點，本文用設置簡化過的閾值，并引入Block-ACK延時回傳策略，實現新模式與Block-ACK模式的靈活切換。實驗數據表明，這種切換模式能有效削減重傳率，并進一步提升網絡性能。

至于是否能進一步優化，不用切換模式也能解決等待時間過長的問題，還須進一步的研究。