星間網(wǎng)絡(luò)中對(duì)TCP捎帶確認(rèn)模式的驗(yàn)證和改良

韓冰，龔文斌

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

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

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

1 信息流模型

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

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

圖1 整星對(duì)外信息流

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3 仿真結(jié)果

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

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

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

表1 102.4 kbps的傳輸時(shí)延

表2 51.2 kbps的傳輸時(shí)延

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

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

圖3 mode1在51.2 kbps速率下的時(shí)延分布

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

圖4 mode2在51.2 kbps速率下的時(shí)延分布

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

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

表3 兩個(gè)模式重傳率的比較

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

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

圖5 重傳包傳輸時(shí)延分析

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

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

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

具體步驟:

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

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

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

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

表5 51.2 kbps的傳輸時(shí)延

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

5 結(jié)論

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

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

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