韓冰，龔文斌

（中科院上海微系統(tǒng)與信息技術(shù)研究所上海200050）

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

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

1 信息流模型

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

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

圖1 整星對外信息流

遙控信息和運控信息由地面站和運控站向可見衛(wèi)星發(fā)送，遙控信息負(fù)責(zé)管理衛(wèi)星的日常運行，運控信息則承載著衛(wèi)星的具體業(yè)務(wù)，這兩種信息流均很重要，故采用TCP模式進(jìn)行傳輸，故遙控和運控的信息流幀數(shù)構(gòu)成為:

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

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

2 TCP捎帶確認(rèn)模式設(shè)計

從對信息流的分析可知，確認(rèn)幀和重傳確認(rèn)幀并不承擔(dān)具體業(yè)務(wù)，卻大大增加了星間網(wǎng)絡(luò)的負(fù)擔(dān)，是網(wǎng)絡(luò)更為擁塞，應(yīng)將確認(rèn)幀作為首要優(yōu)化對象，把確認(rèn)幀所承載的信息放入正好要回傳的信息流（改良數(shù)據(jù)幀的幀頭，使其容納此確認(rèn)幀信息），該承載的信息流可以是運控轉(zhuǎn)發(fā)，遙控轉(zhuǎn)發(fā)，遙測信息中的任何一種。

TCP捎帶確認(rèn)方式的傳輸模式如圖2所示。

在這種模式下，星間網(wǎng)絡(luò)遙控和運控的信息流幀數(shù)構(gòu)成為:

圖2 TCP捎帶確認(rèn)模式

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

地面捎帶確認(rèn)模式和相關(guān)研究過于復(fù)雜，且沒有考慮星間網(wǎng)絡(luò)根據(jù)路由表時隙表傳輸?shù)奶攸c，并不適合星間網(wǎng)絡(luò)，我們需要重新實現(xiàn)星間網(wǎng)絡(luò)的捎帶確認(rèn)模式，以北斗30星為實驗背景，星間網(wǎng)絡(luò)的捎帶確認(rèn)模式，具體實現(xiàn)步驟為：

1）將每個衛(wèi)星遙控和運控的緩存細(xì)分為30個。本星的每個緩存對應(yīng)一個它星臨時存儲發(fā)送給此衛(wèi)星的星間數(shù)據(jù)包，并額外存儲對應(yīng)此衛(wèi)星的AS和AR兩個值。

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

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

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

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

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

注:由于星間網(wǎng)絡(luò)的特殊性，衛(wèi)星能力有限，通過設(shè)置ACK編號的方式來設(shè)計捎帶確認(rèn)模式開銷過大，并不十分可行，故采用計數(shù)方式。

3 仿真結(jié)果

本文實驗仿真數(shù)據(jù)是通過聯(lián)合軟仿進(jìn)行的北斗30星星間鏈路模擬的一周運轉(zhuǎn)仿真結(jié)果，傳輸速率設(shè)置為102.4 kbps。

其時延統(tǒng)計如表1所示，mode1為傳統(tǒng)TCP模式，mode2為TCP捎帶確認(rèn)模式。

由于更改傳輸模式的方法本質(zhì)是通過精簡信息流改善改善網(wǎng)絡(luò)擁塞狀況，以此來優(yōu)化時延特性，故我們增添傳輸速率為51.2 kbps時的實驗作為比較，使整網(wǎng)環(huán)境更為苛刻，網(wǎng)絡(luò)擁塞狀況更為嚴(yán)重，表2為51.2 kbps時的時延統(tǒng)計。

表1 102.4 kbps的傳輸時延

表2 51.2 kbps的傳輸時延

如表中所示，無論是境內(nèi)傳輸還是境外傳輸，TCP捎帶模式比TCP模式在時延特性上表現(xiàn)更為優(yōu)越，尤其是最大時延和平均時延特性的提升。而隨著整網(wǎng)環(huán)境的苛刻化，這種表現(xiàn)更為突出。

為了進(jìn)一步驗證實驗結(jié)果，本文在51.2 kbps的傳輸條件下，對上注信息傳輸?shù)臅r延分布做了相應(yīng)的統(tǒng)計，如圖3和圖4所示。

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

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

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

4 TCP捎帶確認(rèn)模式的改良

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

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

上表顯示TCP捎帶模式相對于傳統(tǒng)TCP模式，在重傳率上不增反降。網(wǎng)絡(luò)阻塞問題的緩解優(yōu)化了星間網(wǎng)絡(luò)環(huán)境，提升了時延性能，但是在重傳率上并未帶來理想的結(jié)果。

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

圖5 重傳包傳輸時延分析

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

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

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

具體步驟:

1）A星向B星傳送數(shù)據(jù)數(shù)據(jù)到達(dá)目的衛(wèi)星B后，衛(wèi)星B的對應(yīng)緩存在累計幀計數(shù)ARB的同時記錄系統(tǒng)時間戳與之綁定，只在ARB從0到非0的時候記錄，之后的累加不更新時間戳。

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

3）本次實驗閾值設(shè)置為30秒，根據(jù)是65秒重傳的設(shè)置，以及時隙表60秒會重復(fù)一次的特點。表4為此次實驗針對重傳率的結(jié)果。表5為實現(xiàn)切換策略之后的試驗統(tǒng)計，mode3為切換模式。

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

表5 51.2 kbps的傳輸時延

如上表所示，通過這種方法，降低了衛(wèi)星重傳率，進(jìn)一步改善了星間網(wǎng)絡(luò)環(huán)境，由此改善了時延特性。

5 結(jié)論

本文針對星間網(wǎng)絡(luò)運控和遙控信息流，提出一種適合星間網(wǎng)絡(luò)傳輸?shù)腡CP捎帶確認(rèn)模式，通過精簡信息流提升信息流利用率的方式，提升星間網(wǎng)絡(luò)的性能。并通過細(xì)分緩存和ACK計數(shù)的方式設(shè)計，使這種模式更為適配星間網(wǎng)絡(luò)。實驗數(shù)據(jù)表明，這種傳輸模式下星間網(wǎng)絡(luò)的時延特性，相對于傳統(tǒng)TCP模式有了顯著的提升。

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

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