天基前向遙控應(yīng)用分析

聶琨坤，胡文靜

（北京空間信息中繼傳輸技術(shù)研究中心 北京 100094）

引言

未來的航天測控網(wǎng)將由天基測控網(wǎng)和地基測控網(wǎng)共同組成。隨著載人航天、深空探測等工程和科學(xué)應(yīng)用的增多以及天基網(wǎng)的全球覆蓋，天地一體化網(wǎng)絡(luò)［1］不僅能夠提供科學(xué)實驗數(shù)據(jù)、語音、運動圖形和靜止圖像等業(yè)務(wù)數(shù)據(jù)的傳輸，而且能夠提供長弧段的天基測控。天地一體化網(wǎng)絡(luò)的前向遙控方式與傳統(tǒng)遙控［2］方式有很多不同，它允許連接在天地一體化網(wǎng)絡(luò)中的用戶采用分包遙控［3］的方式使用天基網(wǎng)前向鏈路注入指令，可以實現(xiàn)便捷的長弧段控制，但同時也提出了許多應(yīng)用問題。本文在比較傳統(tǒng)遙控與基于中繼衛(wèi)星的天地一體化網(wǎng)絡(luò)前向遙控鏈路組成特點的基礎(chǔ)上，對覆蓋、鏈路功率、數(shù)據(jù)鏈路配合、時延以及可靠性等可能引入的多個應(yīng)用問題進(jìn)行分析，并給出應(yīng)用建議。

傳統(tǒng)的遙控方式有兩種:一種是遙控指令在地面站內(nèi)產(chǎn)生，在目標(biāo)飛行器可見的情況下通過射頻信道發(fā)送，時延主要來自空間射頻鏈路和發(fā)射接收設(shè)備；另一種是遙控指令在測控中心產(chǎn)生，測控中心通過地面因特網(wǎng)協(xié)議IP（Internet Protocol）鏈路或高級數(shù)據(jù)鏈路控制HDLC（High-Level Data Link Control）鏈路將遙控指令發(fā)送到目標(biāo)飛行器可見的地面站，再由地面站通過射頻信道向目標(biāo)飛行器發(fā)送。通常需要采用三取二比對及小環(huán)、大環(huán)比對方式來保證傳輸可靠性和指令正確。傳統(tǒng)遙控方式通信時延短，地面設(shè)備便于人員管理，系統(tǒng)設(shè)計和研制受到的制約條件少，系統(tǒng)的可維護(hù)性和可靠性高，其最主要的不足是覆蓋率低。美國覆蓋率最高的耗資達(dá)六億美元的載人航天網(wǎng)，在執(zhí)行阿波羅任務(wù)時，二十多個地面站在最有利的條件下也只能覆蓋不到30%的地球軌道［4］。

天基遙控方式測控中心可利用中繼衛(wèi)星前向信道，通過各系統(tǒng)間的信息交互與配合，完成對用戶飛行器的遙控。天基遙控的主要優(yōu)勢是高覆蓋率，它能夠?qū)崿F(xiàn)對近地航天器全軌道的遙控，這對載人航天任務(wù)（飛船、航天飛機(jī)、空間站）的遙控通信保障極為重要，它還能實現(xiàn)對多個用戶飛行器的同時測控和通信［5，6］，這對采用星座方式工作的用戶星目標(biāo)飛行器系統(tǒng)以及航天器的交會對接來說是十分重要的手段?；谥欣^衛(wèi)星的天基遙控鏈路由地面IP鏈路、天基網(wǎng)中心網(wǎng)關(guān)、天基網(wǎng)地面站網(wǎng)關(guān)、空地射頻鏈路、中繼衛(wèi)星轉(zhuǎn)發(fā)器和空空射頻鏈路等多段鏈路和多個節(jié)點構(gòu)成，各段鏈路及節(jié)點都會引入額外時延，增加鏈路的不可靠性。

1 應(yīng)用問題分析

1.1 覆蓋分析

中繼衛(wèi)星可以極大提高中低軌航天器的軌道覆蓋率。比如，中低軌航天器每天運行十幾圈，使用部署于我國境內(nèi)的S波段測控網(wǎng)每天僅可測控6～8圈，且每圈可見時間僅約為幾分鐘到十幾分鐘［7］。表1是使用仿真軟件以90°和65°傾角軌道為例仿真計算實現(xiàn)全球覆蓋所需的地基測控站臺數(shù)，結(jié)果表明當(dāng)軌道高度較低時很難實現(xiàn)全球覆蓋。

表1 地基測控站實現(xiàn)全球覆蓋臺站數(shù)需求Table1 Number of ground control stations to achieve global coverage

利用一顆中繼衛(wèi)星，對200km軌道高度的航天器覆蓋率就能達(dá)到52%以上，對2000km軌道高度的航天器覆蓋率能達(dá)到68%以上，每圈的遙控時間達(dá)到半小時以上。如果使用多顆中繼衛(wèi)星，則可以為航天器提供更長的遙控時間。

不同于傳統(tǒng)地基站遙控，我們使用STK仿真分析覆蓋率［8］。以美國中繼衛(wèi)星TDRS為例，假設(shè)條件如下:

①中繼衛(wèi)星選用美國 TDRS-3（W275°）、TDRS-5（W171°）、TDRS-10（W40.9°）；

②軌道歷元:北京時間2012-5-31 08:00:00；

③中繼衛(wèi)星星間鏈路天線在方位向、俯仰向可以達(dá)到幾何可見范圍；

④用戶飛行器運行于圓形軌道上，設(shè)定其軌道高度分別為200km、500km、800km，軌道傾角分別為65°、90°；

⑤用戶飛行器軌道的升交點赤經(jīng)和平近點角為0°；

⑥不考慮用戶飛行器中繼終端的安裝位置與條件限制。

用戶飛行器軌道傾角為65°時的遙控覆蓋率計算結(jié)果見表2。

表2 用戶飛行器軌道傾角為65°時遙控覆蓋率計算結(jié)果Table2 Telecommand coverage with 65°orbit inclination

用戶飛行器軌道傾角為90°時的遙控覆蓋率計算結(jié)果見表3。

表3 用戶飛行器軌道傾角為90°時遙控覆蓋率計算結(jié)果Table3 Telecommand coverage with 90°orbit inclination

由遙控覆蓋率計算結(jié)果可知，在既定用戶飛行器傾角條件下，隨著用戶飛行器軌道高度的增加，單顆中繼衛(wèi)星對用戶飛行器的遙控覆蓋率逐漸增加。三顆中繼衛(wèi)星組成的中繼衛(wèi)星星座對中、高軌道用戶飛行器的遙控覆蓋率能夠達(dá)到100%，即可以進(jìn)行全弧段遙控，這給很多應(yīng)急處置及空間任務(wù)創(chuàng)造了很好的遙控條件。

1.2 鏈路分析

相比傳統(tǒng)遙控，天基前向遙控需要增大發(fā)射功率［9］。下面以單顆中繼衛(wèi)星為例，分析用戶飛行器和中繼衛(wèi)星進(jìn)行前向遙控的全程鏈路的功率關(guān)系，如圖1所示，本文假定用戶飛行器使用同一天線、同一接收機(jī)接收中繼衛(wèi)星和用戶地面站發(fā)來的遙控信號。

圖1 天基前向遙控功率關(guān)系示意圖Fig.1 The diagram of TDRSS forward link power relations

首先，在保證用戶飛行器能解析出遙控指令的誤碼率BER下，用戶飛行器的載噪比（C/N）0是一定的，無論是用戶飛行器接收用戶地面站遙控信號的上行載噪比（ ）C/Nusrg，還是接收中繼衛(wèi)星前向遙控信號的載噪比（C/N）sat，都必須大于等于（ ）C/N0。用戶飛行器和中繼衛(wèi)星之間的鏈路載噪比與用戶飛行器和用戶地面站之間的載噪比相等，因此有如下關(guān)系

在進(jìn)行前向遙控時，用戶飛行器接收用戶地面站信號或中繼衛(wèi)星信號均使用同一副天線、同一頻率，因此兩種情況具有相同的天線增益Gusr。假設(shè)用戶飛行器由對地變?yōu)閷χ欣^衛(wèi)星的路徑損耗增量為ΔLΔp，它應(yīng)為從用戶飛行器到中繼星的路徑損耗Lpsat與從用戶飛行器到用戶地面站的路徑損耗Lpusr之差，即

該變化過程引入的噪聲增量ΔNΔ，等于中繼星接收機(jī)噪聲Nsat與用戶飛行器接收機(jī)噪聲Nusr之差，即

中繼星與用戶飛行器之間的通信還要多考慮一項天線指向誤差Lusr。若忽略其它損耗，那么以分貝形式表示的用戶地面站等效全向輻射功率EIRPusrg與中繼衛(wèi)星星間EIRPsat之間有如下關(guān)系

中繼衛(wèi)星星間EIRPsat為中繼衛(wèi)星向用戶目標(biāo)發(fā)射的前向功率，設(shè)Gsat為中繼衛(wèi)星星間天線增益，則中繼衛(wèi)星星間EIRPsat與轉(zhuǎn)發(fā)器輸出端功率Pout以分貝形式表示的關(guān)系如下

中繼衛(wèi)星前向轉(zhuǎn)發(fā)器增益為Gt，其輸入端功率Pin與輸出端功率Pout的關(guān)系為

假設(shè)中繼衛(wèi)星星地天線增益為Gsg，前向鏈路星地路徑損耗為Lpsg，混合損耗為Lmsg，則中繼衛(wèi)星轉(zhuǎn)發(fā)器輸入端功率Pin與中繼衛(wèi)星地面站前向EIRPgd有如下關(guān)系

將式（5）、式（6）代入式（7）得到如下關(guān)系

在設(shè)備和通信距離不變的情況下，式（8）中Gsat、Gsg、Lpsg、Lmsg均為固定值，因此只要在系統(tǒng)中調(diào)整EIRPgd和Gt的值就可以改變EIRPsat，進(jìn)而達(dá)到通過天基網(wǎng)實施用戶飛行器前向遙控的目的。

1.3 鏈路配合

采用天地一體化網(wǎng)絡(luò)進(jìn)行前向遙控時，引入的多段鏈路及節(jié)點給遙控的實施增加了很多不確定性，需要各節(jié)點的互相配合才能完成遙控。首先，在用戶遙控源發(fā)送遙控指令之前，中繼衛(wèi)星要捕獲用戶飛行器，完成信號鎖定和信息同步。然后，天基網(wǎng)通知用戶遙控源前向鏈路可以工作，天基網(wǎng)中心網(wǎng)關(guān)在收到用戶遙控源發(fā)送的遙控指令后進(jìn)行安全檢查，并根據(jù)當(dāng)時任務(wù)情況將遙控指令選擇發(fā)送到指定天基網(wǎng)地面站。最后，天基網(wǎng)地面站調(diào)制發(fā)送前向遙控指令，通過中繼衛(wèi)星轉(zhuǎn)發(fā)器發(fā)送到用戶飛行器。天基前向遙控過程如圖2所示。另外，用戶遙控源也可以控制天基前向遙控過程。

圖2 天基前向遙控互操作流程Fig.2 TDRSS forward telecommand interaction operation procedure

天基前向遙控鏈路配合主要有以下兩個特點:

①天基網(wǎng)需要計算前向鏈路狀態(tài)是否可用，并向用戶返回該狀態(tài)。而天基網(wǎng)無法代替用戶遙控源向用戶飛行器注入前向遙控指令，檢查前向遙控信道是否可用，因此，中繼衛(wèi)星捕獲用戶飛行器后，只能通過返向鏈路的同步情況推斷前向鏈路是否可用。由于空間前、返向鏈路并不對稱，因此天基網(wǎng)前向鏈路可用狀態(tài)的計算具有不確定性。為了彌補(bǔ)這種不確定性，天基網(wǎng)可以通過發(fā)射一段同步碼來溝通前向鏈路。隨著天基網(wǎng)的發(fā)展，可以在用戶飛行器中繼終端上加入前向鏈路可用的遙測反饋，消除前向鏈路可用狀態(tài)計算的不確定性。

②天基網(wǎng)前向遙控具有多個方向選擇的特點。理論上接入天地一體化網(wǎng)絡(luò)的所有用戶遙控源都可以進(jìn)行前向遙控，天基網(wǎng)有多顆中繼衛(wèi)星和多個天基網(wǎng)地面站，天基網(wǎng)中心需要根據(jù)具體任務(wù)情況，接收多個遙控源的前向遙控指令并選擇合適的地面站發(fā)射。而該選擇計算過程需要綜合考慮用戶飛行器對中繼衛(wèi)星的可見情況，地面站對中繼衛(wèi)星的可見情況以及其他鏈路問題。另外，來自于不同遙控源的前向遙控指令也存在時序和信道復(fù)用問題。為解決上述問題，可以在天基網(wǎng)中心根據(jù)CCSDS分包遙控［10］建議建立用戶遙控源、用戶飛行器、中繼衛(wèi)星和地面站信道的多重映射關(guān)系，再根據(jù)一定原則分發(fā)雙方的前向遙控指令及狀態(tài)。

1.4 時延

天基前向遙控各段鏈路及節(jié)點都會引入額外時延，增加鏈路的不可靠性。全程鏈路時延Ts主要由節(jié)點時延Tn和鏈路時延Tl兩部分構(gòu)成:

鏈路時延Tl由地面鏈路和空間鏈路兩部分時延構(gòu)成。地面鏈路通常使用成熟的交換設(shè)備和線路，在不發(fā)生網(wǎng)絡(luò)故障的情況下時延相對固定；空間鏈路時延以同步衛(wèi)星軌道高度計算約為270ms。

節(jié)點時延Tn由用戶遙控源、天基網(wǎng)中心、地面站以及中繼衛(wèi)星轉(zhuǎn)發(fā)器引入，由于這些節(jié)點使用的均是專用軟硬件設(shè)備，且由不同單位生產(chǎn)，因此不確定因素較多。比如使用傳輸控制協(xié)議TCP（Transfer Control Protocol）［11］進(jìn)行前向遙控指令傳輸時，常常會忽略TCP Nagle算法［12］的特性而引入意外時延及無關(guān)信息粘包。下面以某次任務(wù)為例說明這種意外情況。

TCP默認(rèn)的Nagle算法為了避免網(wǎng)絡(luò)中出現(xiàn)過多的小包數(shù)據(jù)，只允許在網(wǎng)絡(luò)上有一包未被確認(rèn)的數(shù)據(jù)，所以它會等待一段時間，將小包數(shù)據(jù)拼接成一個大包數(shù)據(jù)再向網(wǎng)絡(luò)發(fā)送。而天基前向遙控指令往往都是小包數(shù)據(jù)，若用戶遙控源或天基網(wǎng)中心不關(guān)閉該算法，則會引入意外時延。在TCP默認(rèn)和關(guān)閉Nagle算法的情況下分別進(jìn)行實驗，結(jié)果如圖3、圖4所示。

圖3 TCP協(xié)議默認(rèn)使用方式時的時延抖動Fig.3 Time delay jitter on the condition of TCP default

圖4 TCP協(xié)議NODELAY使用方式時的時延抖動Fig.4 Time delay jitter on the condition of TCP no-delay

TCP協(xié)議默認(rèn)使用方式會根據(jù)接收方ACK反饋情況推遲小包數(shù)據(jù)發(fā)送，圖3中數(shù)據(jù)時延抖動在0～300ms之間。使用NODELAY選項后，TCP協(xié)議會及時將數(shù)據(jù)發(fā)入網(wǎng)絡(luò)，數(shù)據(jù)時延抖動在0～2ms之間，且基本是由于數(shù)據(jù)發(fā)送或處理過程時鐘漂移所致。對于空間鏈路時延僅270ms的前向鏈路來說，300ms的附加時延是無法容忍的。

圖5是中心至地面站間前向數(shù)據(jù)幀頻不穩(wěn)問題產(chǎn)生機(jī)理示意圖。圖5中標(biāo)識的應(yīng)答與數(shù)據(jù)間隔為250ms只是示意，實際在200ms左右；圖中粗箭頭為產(chǎn)生幀頻不穩(wěn)問題的關(guān)鍵幀。從以上分析可知，在TCP默認(rèn)情況下，雙方節(jié)點可能會因為數(shù)據(jù)與狀態(tài)的時序問題，等待對方ACK反饋而產(chǎn)生時延，也有可能數(shù)據(jù)與狀態(tài)在同一數(shù)據(jù)包內(nèi)發(fā)送，產(chǎn)生數(shù)據(jù)粘包現(xiàn)象。幾百毫秒的時延在互聯(lián)網(wǎng)應(yīng)用中或許可以忽略，但在進(jìn)行前向遙控時卻不得不考慮指令的實時性。因此，在進(jìn)行天基前向遙控時，建議各TCP節(jié)點關(guān)閉Nagle算法。

1.5 可靠性

傳統(tǒng)遙控方式是遙控指令由預(yù)先指定的主機(jī)或備機(jī)之一發(fā)送，主機(jī)和備機(jī)均處于在線狀態(tài)，使用熱備心跳檢測主備狀態(tài)，其中一臺宕機(jī)由另一臺接替。主備機(jī)均接收和處理數(shù)據(jù)，然后判決選擇使用其一。遙控發(fā)送指令通常需要發(fā)送多次，通過比對確認(rèn)數(shù)據(jù)的正確性，進(jìn)而依靠前向糾檢錯和遙測反饋保證其可靠性。

天基前向遙控是以前/返向中繼信道的方式向用戶中心提供遙控指令及其反饋的通信通道，如前所述存在天基網(wǎng)與用戶中心和空間目標(biāo)之間的配合問題。由于各單位的職責(zé)分工及遙控指令的保密需求，天基網(wǎng)較難代替用戶中心完成遙控指令的比對以及反饋糾錯等職能，只能依靠傳輸通道本身的可靠性提高系統(tǒng)應(yīng)用能力。

圖5 中心至地面站間前向數(shù)據(jù)幀頻不穩(wěn)問題產(chǎn)生機(jī)理示意圖Fig.5 Mechanism diagram of unstable frame rate problem between the center and station

節(jié)點之間傳送前向遙控數(shù)據(jù)時，通常使用用戶數(shù)據(jù)包協(xié)議UDP（User Datagram Protocol）組播方式（如圖6）或者TCP方式（如圖7）。采用UDP組播方式時，收發(fā)雙方均為在線主備機(jī)，發(fā)送方主機(jī)發(fā)送數(shù)據(jù)，備機(jī)不發(fā)送數(shù)據(jù)，接收方主備機(jī)均接收數(shù)據(jù)，但由于天基網(wǎng)不具有用戶遙控指令解析的職能，因此，天基網(wǎng)主備機(jī)不進(jìn)行用戶遙控指令的解析比判處理，只進(jìn)行主機(jī)接收轉(zhuǎn)發(fā)數(shù)據(jù)處理，收發(fā)雙方進(jìn)行主備切換均不影響對方。這種方式發(fā)送方只向網(wǎng)絡(luò)發(fā)送一次數(shù)據(jù)，由UDP組播特性來保證接收方的多點接收，提高數(shù)據(jù)傳輸可靠性。但是加入到UDP組地址內(nèi)的計算機(jī)都能收到數(shù)據(jù)，這也帶來了一定的安全問題，采用指定源組播的方式可以在一定程度上提高安全性，但也因為要給雙方節(jié)點加入指定源［13］地址而增加了復(fù)雜性。

采用TCP方式時，收發(fā)雙方均為在線主備機(jī)，發(fā)送方主機(jī)發(fā)送數(shù)據(jù)，備機(jī)不發(fā)送數(shù)據(jù)，且主機(jī)發(fā)送數(shù)據(jù)時要同時向接收方主備機(jī)發(fā)送。在這種方式下，用戶中心除需要多次發(fā)送遙控指令外，還需要依據(jù)TCP主備機(jī)特點，向網(wǎng)絡(luò)發(fā)送兩倍數(shù)據(jù)，數(shù)據(jù)的反饋檢查及比對主要由用戶中心完成，天基網(wǎng)由于職能限制僅能提供通信通道。雖然TCP特性保證了數(shù)據(jù)的可靠性，但是增加了收發(fā)雙方連接的復(fù)雜性。

圖6 UDP組播方式Fig.6 UDP multicast way

圖7 TCP方式Fig.7 TCP way

在可靠性要求極高的情況下，除了考慮收發(fā)雙方節(jié)點的可靠性，還需要考慮通信鏈路的可靠性。如圖6、圖7所示，發(fā)送方同時向不同的路由發(fā)送數(shù)據(jù)，不同路由使用不同的通信鏈路，以此保證通信鏈路可靠性，但這卻增加了節(jié)點的復(fù)雜性。因此，建議對可靠性要求進(jìn)行分級，比如可根據(jù)失效的危險和嚴(yán)重性等級，將可能導(dǎo)致災(zāi)難性后果的應(yīng)用采用主備機(jī)、多路由的高冗余方式，對導(dǎo)致嚴(yán)重性后果的采用單路由、主備機(jī)冗余方式，對一般應(yīng)用采用單路由、單機(jī)方式。分級要求的方式，可以避免一般應(yīng)用節(jié)點復(fù)雜性的增加，提高系統(tǒng)的可靠性。

2 結(jié)束語

本文分析了傳統(tǒng)遙控和天基遙控鏈路組成情況及遙控方式的特點，對天基覆蓋、鏈路功率、鏈路配合、時延及可靠性等不同于傳統(tǒng)遙控的天基網(wǎng)前向遙控應(yīng)用問題進(jìn)行了研究，得到如下結(jié)論:

①只要提高中繼衛(wèi)星地面站的前向EIRP，或者調(diào)高中繼衛(wèi)星的轉(zhuǎn)發(fā)器增益，就可以實現(xiàn)天基網(wǎng)前向遙控；

②在鏈路配合方面，可以在用戶飛行器中繼終端上加入前向鏈路可用的遙測反饋，消除前向鏈路可用狀態(tài)計算的不確定性；

③在進(jìn)行天基前向遙控時，建議各TCP節(jié)點關(guān)閉Nagle算法，以減小天基前向遙控時延；

④建議根據(jù)不同任務(wù)的可靠性要求進(jìn)行分級實施，降低系統(tǒng)復(fù)雜性。

文中所述問題都是在實際任務(wù)中極易出現(xiàn)和忽略的問題，希望本文能為相關(guān)的工程應(yīng)用和后續(xù)天基測控的研究提供參考。

［1］沈榮駿.我國天地一體化航天互聯(lián)網(wǎng)構(gòu)想［J］.中國科學(xué)工程，2006，8（10）:23～27.Shen Rongjun.Concept of China's Integrated Aerospace Internet［J］.China Engineering Science，2006，8（10）:23 ～27.

［2］劉蘊(yùn)才.遙測遙控系統(tǒng)（下）［M］.北京:國防工業(yè)出版社，2000:30～35.Liu Yuncai.Telemetry and Telecommand System［M］.Beijing:National Defence Industry Press，2000:30 ～35.

［3］譚維熾.空間數(shù)據(jù)系統(tǒng)［M］.北京:中國科學(xué)技術(shù)出版社，2004:106～121.Tan Weichi.Space Data System［M］.Beijing:China Science and Technology Press，2004:106～121.

［4］劉嘉興.航天測控技術(shù)的過去、現(xiàn)在和未來［J］.電訊技術(shù)，1999（2）:1～7.Liu Jiaxing.Past，Presence and Future of Aerospace TT&C Technology［J］.Telecommunication Engineering，1999（2）:1～7.

［5］王增利，王有政，孫寶升，等.中繼衛(wèi)星系統(tǒng)支持多目標(biāo)系統(tǒng)鏈路仿真分析［J］.遙測遙控，2010，31（5）:17～21.Wang Zengli，Wang Youzheng，Sun Baosheng，et al.System Link Simulation and Analysis of TDRSS Supporting Multiple-targets［J］.Journal of Telemetry，Tracking and Command，2010，31（5）:17 ～21.

［6］王增利，孫寶升，王 瑛，等.中繼衛(wèi)星系統(tǒng)單址鏈路支持多目標(biāo)用戶容量［C］//第十七屆中國遙測遙控科技大會論文集，騰沖，2013.Wang Zengli，Sun Baosheng，Wang Ying，et al.The Capacity of Multi-objects by Single Access Link Based on TDRSS［C］//17 th Telemetry，Tracking and Command Technology Conference，Tengchong，2013.

［7］胡文靜，聶琨坤，王 茹.天基網(wǎng)空間救援鏈路關(guān)系研究［C］//第四屆航天電子對抗學(xué)術(shù)年會論文集，寧波，2012:226～230.Hu Wenjing，Nie Kunkun，Wang Ru.The Study of the Space-Link Relationship for Rescuing User Based on TDRSS［C］//4th Aerospace Electronic Warfare Conference，Ningbo，2012:226 ～230.

［8］李于衡，劉寧寧.在軌跟蹤與數(shù)據(jù)中繼衛(wèi)星測控關(guān)鍵技術(shù)（上）［J］.上海航天，2006（4）:1～7.Li Yuheng，Liu Ningning.Key Techniques of TT&C for On-Orbit TDRS（Part1）［J］.Shanghai Space，2006（4）:1 ～7.

［9］Jack Kreng，Sieu Do，Ashok Mathur.USBCommand Link via TDRSS to Satellites and Possibly Space Launch Vehicles［C］//26 th International Communications Satellite Systems Conference（ICSSC），10-12 June 2008，San Diego，CA，AIAA 2008～5408.

［10］Recommendation for Space Data System Standards.CCSDS 232.0-B-1 TC Space Data Link Protocol［S］.Washington，D.C.，CCSDS，2003.

［11］Postel J.Transmission Control Protocol［S］.IETF.RFC 793，1981.9.

［12］Nagle J.Congestion Control in IP/TCP Inter networks［S］.IETF.RFC 896，1984.1.

［13］Cain B，Deering S，Kouvelas I，F(xiàn)enner B，Thyagarajan A.Internet Group Management Protocol Version 3［S］.IETF.RFC 3376，2002.10.