聂琨坤，胡文静

（北京空间信息中继传输技术研究中心 北京 100094）

引言

未来的航天测控网将由天基测控网和地基测控网共同组成。随着载人航天、深空探测等工程和科学应用的增多以及天基网的全球覆盖，天地一体化网络［1］不仅能够提供科学实验数据、语音、运动图形和静止图像等业务数据的传输，而且能够提供长弧段的天基测控。天地一体化网络的前向遥控方式与传统遥控［2］方式有很多不同，它允许连接在天地一体化网络中的用户采用分包遥控［3］的方式使用天基网前向链路注入指令，可以实现便捷的长弧段控制，但同时也提出了许多应用问题。本文在比较传统遥控与基于中继卫星的天地一体化网络前向遥控链路组成特点的基础上，对覆盖、链路功率、数据链路配合、时延以及可靠性等可能引入的多个应用问题进行分析，并给出应用建议。

传统的遥控方式有两种:一种是遥控指令在地面站内产生，在目标飞行器可见的情况下通过射频信道发送，时延主要来自空间射频链路和发射接收设备；另一种是遥控指令在测控中心产生，测控中心通过地面因特网协议IP（Internet Protocol）链路或高级数据链路控制HDLC（High-Level Data Link Control）链路将遥控指令发送到目标飞行器可见的地面站，再由地面站通过射频信道向目标飞行器发送。通常需要采用三取二比对及小环、大环比对方式来保证传输可靠性和指令正确。传统遥控方式通信时延短，地面设备便于人员管理，系统设计和研制受到的制约条件少，系统的可维护性和可靠性高，其最主要的不足是覆盖率低。美国覆盖率最高的耗资达六亿美元的载人航天网，在执行阿波罗任务时，二十多个地面站在最有利的条件下也只能覆盖不到30%的地球轨道［4］。

天基遥控方式测控中心可利用中继卫星前向信道，通过各系统间的信息交互与配合，完成对用户飞行器的遥控。天基遥控的主要优势是高覆盖率，它能够实现对近地航天器全轨道的遥控，这对载人航天任务（飞船、航天飞机、空间站）的遥控通信保障极为重要，它还能实现对多个用户飞行器的同时测控和通信［5，6］，这对采用星座方式工作的用户星目标飞行器系统以及航天器的交会对接来说是十分重要的手段。基于中继卫星的天基遥控链路由地面IP链路、天基网中心网关、天基网地面站网关、空地射频链路、中继卫星转发器和空空射频链路等多段链路和多个节点构成，各段链路及节点都会引入额外时延，增加链路的不可靠性。

1 应用问题分析

1.1 覆盖分析

中继卫星可以极大提高中低轨航天器的轨道覆盖率。比如，中低轨航天器每天运行十几圈，使用部署于我国境内的S波段测控网每天仅可测控6～8圈，且每圈可见时间仅约为几分钟到十几分钟［7］。表1是使用仿真软件以90°和65°倾角轨道为例仿真计算实现全球覆盖所需的地基测控站台数，结果表明当轨道高度较低时很难实现全球覆盖。

表1 地基测控站实现全球覆盖台站数需求Table1 Number of ground control stations to achieve global coverage

利用一颗中继卫星，对200km轨道高度的航天器覆盖率就能达到52%以上，对2000km轨道高度的航天器覆盖率能达到68%以上，每圈的遥控时间达到半小时以上。如果使用多颗中继卫星，则可以为航天器提供更长的遥控时间。

不同于传统地基站遥控，我们使用STK仿真分析覆盖率［8］。以美国中继卫星TDRS为例，假设条件如下:

①中继卫星选用美国 TDRS-3（W275°）、TDRS-5（W171°）、TDRS-10（W40.9°）；

②轨道历元:北京时间2012-5-31 08:00:00；

③中继卫星星间链路天线在方位向、俯仰向可以达到几何可见范围；

④用户飞行器运行于圆形轨道上，设定其轨道高度分别为200km、500km、800km，轨道倾角分别为65°、90°；

⑤用户飞行器轨道的升交点赤经和平近点角为0°；

⑥不考虑用户飞行器中继终端的安装位置与条件限制。

用户飞行器轨道倾角为65°时的遥控覆盖率计算结果见表2。

表2 用户飞行器轨道倾角为65°时遥控覆盖率计算结果Table2 Telecommand coverage with 65°orbit inclination

用户飞行器轨道倾角为90°时的遥控覆盖率计算结果见表3。

表3 用户飞行器轨道倾角为90°时遥控覆盖率计算结果Table3 Telecommand coverage with 90°orbit inclination

由遥控覆盖率计算结果可知，在既定用户飞行器倾角条件下，随着用户飞行器轨道高度的增加，单颗中继卫星对用户飞行器的遥控覆盖率逐渐增加。三颗中继卫星组成的中继卫星星座对中、高轨道用户飞行器的遥控覆盖率能够达到100%，即可以进行全弧段遥控，这给很多应急处置及空间任务创造了很好的遥控条件。

1.2 链路分析

相比传统遥控，天基前向遥控需要增大发射功率［9］。下面以单颗中继卫星为例，分析用户飞行器和中继卫星进行前向遥控的全程链路的功率关系，如图1所示，本文假定用户飞行器使用同一天线、同一接收机接收中继卫星和用户地面站发来的遥控信号。

图1 天基前向遥控功率关系示意图Fig.1 The diagram of TDRSS forward link power relations

首先，在保证用户飞行器能解析出遥控指令的误码率BER下，用户飞行器的载噪比（C/N）0是一定的，无论是用户飞行器接收用户地面站遥控信号的上行载噪比（ ）C/Nusrg，还是接收中继卫星前向遥控信号的载噪比（C/N）sat，都必须大于等于（ ）C/N0。用户飞行器和中继卫星之间的链路载噪比与用户飞行器和用户地面站之间的载噪比相等，因此有如下关系

在进行前向遥控时，用户飞行器接收用户地面站信号或中继卫星信号均使用同一副天线、同一频率，因此两种情况具有相同的天线增益Gusr。假设用户飞行器由对地变为对中继卫星的路径损耗增量为ΔLΔp，它应为从用户飞行器到中继星的路径损耗Lpsat与从用户飞行器到用户地面站的路径损耗Lpusr之差，即

该变化过程引入的噪声增量ΔNΔ，等于中继星接收机噪声Nsat与用户飞行器接收机噪声Nusr之差，即

中继星与用户飞行器之间的通信还要多考虑一项天线指向误差Lusr。若忽略其它损耗，那么以分贝形式表示的用户地面站等效全向辐射功率EIRPusrg与中继卫星星间EIRPsat之间有如下关系

中继卫星星间EIRPsat为中继卫星向用户目标发射的前向功率，设Gsat为中继卫星星间天线增益，则中继卫星星间EIRPsat与转发器输出端功率Pout以分贝形式表示的关系如下

中继卫星前向转发器增益为Gt，其输入端功率Pin与输出端功率Pout的关系为

假设中继卫星星地天线增益为Gsg，前向链路星地路径损耗为Lpsg，混合损耗为Lmsg，则中继卫星转发器输入端功率Pin与中继卫星地面站前向EIRPgd有如下关系

将式（5）、式（6）代入式（7）得到如下关系

在设备和通信距离不变的情况下，式（8）中Gsat、Gsg、Lpsg、Lmsg均为固定值，因此只要在系统中调整EIRPgd和Gt的值就可以改变EIRPsat，进而达到通过天基网实施用户飞行器前向遥控的目的。

1.3 链路配合

采用天地一体化网络进行前向遥控时，引入的多段链路及节点给遥控的实施增加了很多不确定性，需要各节点的互相配合才能完成遥控。首先，在用户遥控源发送遥控指令之前，中继卫星要捕获用户飞行器，完成信号锁定和信息同步。然后，天基网通知用户遥控源前向链路可以工作，天基网中心网关在收到用户遥控源发送的遥控指令后进行安全检查，并根据当时任务情况将遥控指令选择发送到指定天基网地面站。最后，天基网地面站调制发送前向遥控指令，通过中继卫星转发器发送到用户飞行器。天基前向遥控过程如图2所示。另外，用户遥控源也可以控制天基前向遥控过程。

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

天基前向遥控链路配合主要有以下两个特点:

①天基网需要计算前向链路状态是否可用，并向用户返回该状态。而天基网无法代替用户遥控源向用户飞行器注入前向遥控指令，检查前向遥控信道是否可用，因此，中继卫星捕获用户飞行器后，只能通过返向链路的同步情况推断前向链路是否可用。由于空间前、返向链路并不对称，因此天基网前向链路可用状态的计算具有不确定性。为了弥补这种不确定性，天基网可以通过发射一段同步码来沟通前向链路。随着天基网的发展，可以在用户飞行器中继终端上加入前向链路可用的遥测反馈，消除前向链路可用状态计算的不确定性。

②天基网前向遥控具有多个方向选择的特点。理论上接入天地一体化网络的所有用户遥控源都可以进行前向遥控，天基网有多颗中继卫星和多个天基网地面站，天基网中心需要根据具体任务情况，接收多个遥控源的前向遥控指令并选择合适的地面站发射。而该选择计算过程需要综合考虑用户飞行器对中继卫星的可见情况，地面站对中继卫星的可见情况以及其他链路问题。另外，来自于不同遥控源的前向遥控指令也存在时序和信道复用问题。为解决上述问题，可以在天基网中心根据CCSDS分包遥控［10］建议建立用户遥控源、用户飞行器、中继卫星和地面站信道的多重映射关系，再根据一定原则分发双方的前向遥控指令及状态。

1.4 时延

天基前向遥控各段链路及节点都会引入额外时延，增加链路的不可靠性。全程链路时延Ts主要由节点时延Tn和链路时延Tl两部分构成:

链路时延Tl由地面链路和空间链路两部分时延构成。地面链路通常使用成熟的交换设备和线路，在不发生网络故障的情况下时延相对固定；空间链路时延以同步卫星轨道高度计算约为270ms。

节点时延Tn由用户遥控源、天基网中心、地面站以及中继卫星转发器引入，由于这些节点使用的均是专用软硬件设备，且由不同单位生产，因此不确定因素较多。比如使用传输控制协议TCP（Transfer Control Protocol）［11］进行前向遥控指令传输时，常常会忽略TCP Nagle算法［12］的特性而引入意外时延及无关信息粘包。下面以某次任务为例说明这种意外情况。

TCP默认的Nagle算法为了避免网络中出现过多的小包数据，只允许在网络上有一包未被确认的数据，所以它会等待一段时间，将小包数据拼接成一个大包数据再向网络发送。而天基前向遥控指令往往都是小包数据，若用户遥控源或天基网中心不关闭该算法，则会引入意外时延。在TCP默认和关闭Nagle算法的情况下分别进行实验，结果如图3、图4所示。

图3 TCP协议默认使用方式时的时延抖动Fig.3 Time delay jitter on the condition of TCP default

图4 TCP协议NODELAY使用方式时的时延抖动Fig.4 Time delay jitter on the condition of TCP no-delay

TCP协议默认使用方式会根据接收方ACK反馈情况推迟小包数据发送，图3中数据时延抖动在0～300ms之间。使用NODELAY选项后，TCP协议会及时将数据发入网络，数据时延抖动在0～2ms之间，且基本是由于数据发送或处理过程时钟漂移所致。对于空间链路时延仅270ms的前向链路来说，300ms的附加时延是无法容忍的。

图5是中心至地面站间前向数据帧频不稳问题产生机理示意图。图5中标识的应答与数据间隔为250ms只是示意，实际在200ms左右；图中粗箭头为产生帧频不稳问题的关键帧。从以上分析可知，在TCP默认情况下，双方节点可能会因为数据与状态的时序问题，等待对方ACK反馈而产生时延，也有可能数据与状态在同一数据包内发送，产生数据粘包现象。几百毫秒的时延在互联网应用中或许可以忽略，但在进行前向遥控时却不得不考虑指令的实时性。因此，在进行天基前向遥控时，建议各TCP节点关闭Nagle算法。

1.5 可靠性

传统遥控方式是遥控指令由预先指定的主机或备机之一发送，主机和备机均处于在线状态，使用热备心跳检测主备状态，其中一台宕机由另一台接替。主备机均接收和处理数据，然后判决选择使用其一。遥控发送指令通常需要发送多次，通过比对确认数据的正确性，进而依靠前向纠检错和遥测反馈保证其可靠性。

天基前向遥控是以前/返向中继信道的方式向用户中心提供遥控指令及其反馈的通信通道，如前所述存在天基网与用户中心和空间目标之间的配合问题。由于各单位的职责分工及遥控指令的保密需求，天基网较难代替用户中心完成遥控指令的比对以及反馈纠错等职能，只能依靠传输通道本身的可靠性提高系统应用能力。

图5 中心至地面站间前向数据帧频不稳问题产生机理示意图Fig.5 Mechanism diagram of unstable frame rate problem between the center and station

节点之间传送前向遥控数据时，通常使用用户数据包协议UDP（User Datagram Protocol）组播方式（如图6）或者TCP方式（如图7）。采用UDP组播方式时，收发双方均为在线主备机，发送方主机发送数据，备机不发送数据，接收方主备机均接收数据，但由于天基网不具有用户遥控指令解析的职能，因此，天基网主备机不进行用户遥控指令的解析比判处理，只进行主机接收转发数据处理，收发双方进行主备切换均不影响对方。这种方式发送方只向网络发送一次数据，由UDP组播特性来保证接收方的多点接收，提高数据传输可靠性。但是加入到UDP组地址内的计算机都能收到数据，这也带来了一定的安全问题，采用指定源组播的方式可以在一定程度上提高安全性，但也因为要给双方节点加入指定源［13］地址而增加了复杂性。

采用TCP方式时，收发双方均为在线主备机，发送方主机发送数据，备机不发送数据，且主机发送数据时要同时向接收方主备机发送。在这种方式下，用户中心除需要多次发送遥控指令外，还需要依据TCP主备机特点，向网络发送两倍数据，数据的反馈检查及比对主要由用户中心完成，天基网由于职能限制仅能提供通信通道。虽然TCP特性保证了数据的可靠性，但是增加了收发双方连接的复杂性。

图6 UDP组播方式Fig.6 UDP multicast way

图7 TCP方式Fig.7 TCP way

在可靠性要求极高的情况下，除了考虑收发双方节点的可靠性，还需要考虑通信链路的可靠性。如图6、图7所示，发送方同时向不同的路由发送数据，不同路由使用不同的通信链路，以此保证通信链路可靠性，但这却增加了节点的复杂性。因此，建议对可靠性要求进行分级，比如可根据失效的危险和严重性等级，将可能导致灾难性后果的应用采用主备机、多路由的高冗余方式，对导致严重性后果的采用单路由、主备机冗余方式，对一般应用采用单路由、单机方式。分级要求的方式，可以避免一般应用节点复杂性的增加，提高系统的可靠性。

2 结束语

本文分析了传统遥控和天基遥控链路组成情况及遥控方式的特点，对天基覆盖、链路功率、链路配合、时延及可靠性等不同于传统遥控的天基网前向遥控应用问题进行了研究，得到如下结论:

①只要提高中继卫星地面站的前向EIRP，或者调高中继卫星的转发器增益，就可以实现天基网前向遥控；

②在链路配合方面，可以在用户飞行器中继终端上加入前向链路可用的遥测反馈，消除前向链路可用状态计算的不确定性；

③在进行天基前向遥控时，建议各TCP节点关闭Nagle算法，以减小天基前向遥控时延；

④建议根据不同任务的可靠性要求进行分级实施，降低系统复杂性。

文中所述问题都是在实际任务中极易出现和忽略的问题，希望本文能为相关的工程应用和后续天基测控的研究提供参考。

［1］沈荣骏.我国天地一体化航天互联网构想［J］.中国科学工程，2006，8（10）:23～27.Shen Rongjun.Concept of China's Integrated Aerospace Internet［J］.China Engineering Science，2006，8（10）:23 ～27.

［2］刘蕴才.遥测遥控系统（下）［M］.北京:国防工业出版社，2000:30～35.Liu Yuncai.Telemetry and Telecommand System［M］.Beijing:National Defence Industry Press，2000:30 ～35.

［3］谭维炽.空间数据系统［M］.北京:中国科学技术出版社，2004:106～121.Tan Weichi.Space Data System［M］.Beijing:China Science and Technology Press，2004:106～121.

［4］刘嘉兴.航天测控技术的过去、现在和未来［J］.电讯技术，1999（2）:1～7.Liu Jiaxing.Past，Presence and Future of Aerospace TT&C Technology［J］.Telecommunication Engineering，1999（2）:1～7.

［5］王增利，王有政，孙宝升，等.中继卫星系统支持多目标系统链路仿真分析［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］王增利，孙宝升，王 瑛，等.中继卫星系统单址链路支持多目标用户容量［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］胡文静，聂琨坤，王 茹.天基网空间救援链路关系研究［C］//第四届航天电子对抗学术年会论文集，宁波，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］李于衡，刘宁宁.在轨跟踪与数据中继卫星测控关键技术（上）［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，Fenner B，Thyagarajan A.Internet Group Management Protocol Version 3［S］.IETF.RFC 3376，2002.10.