天地一体化信息网络的体系结构与协议分析

刘立祥

(中国科学院 软件研究所天基综合信息系统重点实验室，北京 100190)

0 引 言

随着技术的发展和应用需求的多样化，功能单一、结构规则、运行依赖于地面、相互之间孤立的卫星系统已经不能满足人们对实时性、综合性的服务需求，而具有多种功能、轨道互补、智能性高、自主运行、便于扩展的异构卫星组网成为新的发展方向。

天地一体化信息网络[1](space-ground integrated information network, SGIIN)，简称一体化网络，由通信、侦察[2-3]、导航[4]、气象等多种功能的异构卫星/卫星网络、空间飞行器以及地面有线和无线网络设施组成，通过星间、星地链路将地面、空中用户、飞行器以及各种通信平台紧密联合。地面和卫星之间可以根据应用需求建立星间链路，进行数据交换[5]。它既可以是现有卫星系统的按需集成，也可以是根据需求进行“一体化”设计的结果，具有多功能融合、组成结构动态可变、运行状态复杂、信息交换处理一体化等功能特点[6]。这种高度综合性的异构网络系统打破了各自独立的网络系统间数据共享的壁垒，能够有效地综合利用各种资源(包括轨道资源、载荷资源、通信资源等)，不仅可以为作战提供一体化的侦察、导航、作战指挥等服务，也可以为海-陆-空通信、海洋气象预报、导航、应急救援等提供全方位的支持[7]。

从网络特性看，一体化网络具有典型的大时空尺度属性，是一个大时空尺度网络，其网络特点具有如图1所示的鲜明特征。

图1 天地一体化网络特点Fig.1 Features of space-ground integrated information network

从组网模式来看，一体化网络包括全中继模式，所有卫星都是通过中继星(如天链)进行信息交互，星间不存在链路；部分中继模式，同类卫星之间有星际链路，异构卫星之间通过中继星进行互连；全连通模式，在可通信范围内卫星与卫星之间构成一个全连通网络。

1 目前研究的问题分析

1)组网对象较为简单。目前研究的大多是同种类的卫星构成的规则星座结构，但是天地一体化网络中卫星轨道的种类各异，包括单星、星座、编队等，还有些需要根据任务进行临时建立连接[8]。因此，需要研究复杂条件下的组网问题。

2)建链条件过于理想。目前考虑的建链条件过于简单(如可见即可通)、阈值限制以及按照拓扑图等理论基础上的最佳路径计算等，但实际上可见未必可通，应该全局考虑通信质量对路由的影响。

3)信息传输的优先级问题未作考虑。天地一体化网络作为军民两用网络，安全与隔离是非常重要的需求。因此,应该对传输信息进行分级和分类，要考虑信息的时效性、优先级等。

4)节点或链路故障重路由问题。重路由是通信网络或互联网需要具备的重要能力。重路由策略是当拓扑发生改变时，重新建立一条路径，信息从源端重传。这种方式简单但不适用于拓扑变化快的卫星网络，会造成系统效率低下的问题。应该根据链路或卫星的故障情况设计高效的重路由策略，不从源端重传，减少卫星资源消耗，提高传输效率。

5)负载均衡问题。卫星网络用户分布不均匀，造成网络负载失衡，出现部分节点发生拥塞而其他节点未被充分利用的情况，增加了数据包的排队时延和丢失的概率，应该根据用户分布，应用需求平衡网络负载。

2 天地一体化信息网络协议体系

目前常用的网络协议体系包括TCP/IP(transmission control protocol/internet protocol)协议体系[9]、CCSDS(consultative committee for space data systems)协议体系[10]、DTN( delay-tolerant networking)协议体系和SDN(software defined network)协议体系，TCP/IP协议簇在地面Internet网络得到广泛应用，但由于卫星网络与地面Internet 的通信环境存在较大差别导致其无法直接应用于空间网络；CCSDS协议体系是针对空间通信的特点制定了空间通信协议标准，CCSDS的通信方案具有可行性，但是要对其路由、传输进行优化设计；DTN协议体系是一类特殊的网络，很适合天基环境特点，但是由于加入了包裹层和汇聚层，导致了其协议体系与地面以及其他网络在兼容性上存在一定的问题；SDN协议体系是一种新型网络技术，实现网络控制与转发能力分离，使得转发能力可以直接编程进行控制。SDN 技术可以增强控制层的智能边缘转发能力、骨干网络的高效承载能力以及网络能力的开放和协同。但其多域的组网以及大量转发设备的控制算法非常复杂，且还没有形成统一标准。

天地一体化信息网络是一个复杂的巨系统。从建设上看，这样的系统既包括已经建成的系统，又包含即将建设的系统，不同系统之间的运行模式、协议体系都不尽相同。基于实际建设需求，利用2级网络架构来对系统进行构建,如图2所示。图2中，一级网络(骨干网络)节点主要是起到骨干传输作用的节点，包括骨干宽带卫星、中继星以及地面网络中的骨干路由器；二级网络(接入网络)节点是指完成具体任务如信息获取卫星、小卫星编队网络、专用星座、地面网络中的非骨干节点。通过这种组网模式的构建可以降低天基网络路由传输和接入的复杂度，提升信息传输效率。

对于骨干网络，为了更好地与异构网络进行互联互通，其协议体系结构采用标准的分层体系，对于接入网络，其协议体系可以采用专用或通用的体系，如非结构化的网络体系[11]。这主要是保证二级网络的高效性。天基网骨干网络和接入网络协议体系示意图如图3所示。

图2 一体化网络两级架构示意图Fig.2 Schematic diagram of two level architecture of space-ground integrated information network

图3 天基网骨干网络和接入网络协议体系示意图Fig.3 Schematic diagram of space-based network backbone network and access network protocol system

在该协议体系中，为了与地面及其他网络兼容，协议体系包含了常见的协议栈，还有一些针对天基骨干网专门设计的协议，如BTP(bulk transfer protocol)，BNP，BRP以及宽带接入协议、安全认证协议等。在实际的传输过程中，可以根据具体的传输需求对该协议栈进行优化，以达到高效传输的目的。

接入网协议体系可以根据需要进行选择，可以是层次化协议，也可以是非层次化协议体系，如：①DTN协议体系[12-13]；②TCP/IP协议体系；③CCSDS协议体系；④SDN协议体系；⑤非层次化协议体系等。针对不同的需求，如果是深空网络节点，可以选择DTN，地面可以选择TCP/IP，卫星集群组网可以选择非层次化协议体系等。

3 传输和路由协议分析

为了获得不同协议的总体性能，本文重点分析前3类体系的空间网络协议，根据协议网络状态控制方式，进行分类比较，并推导出TCP协议组和单纯基于速率控制协议的理论边界。需要指出的是，这些理论结果适合于在协议达到稳定状态下，传输大文件的性能，但对小文件如命令或控制传输并不适用。推导的协议理论模型分别如下。

3.1 基于拥塞控制的TCP协议

首先对运行在高误码链路上基于拥塞控制的协议(TCP-SACK，SCPS-VJ和SCPS-vegas-congestion)进行分析，推导出其最大理论吞吐量如 (1) 式所示。需要指出的是，(1)式需要假设系统已达到了稳定状态，传输文件的类型为大文件，而不是命令或者控制文件等小文件。

Bandwidth=0.93×MSS/RTT×sqrt(p)

(1)

(1)式中：MSS表示最大分段大小；RTT表示往返时延；p表示数据包错误率。

在实验中，用户数据包大小设置为1 024 Byte。

在没有错误的环境下，最大吞吐量等于接收窗口除以RTT，如(2)式表示。(2)式假设了大文件传输在慢启动的时间消耗很小。

最大吞吐量=(窗口大小/RTT)

(2)

TCP-SACK测试窗口大小使用250 KByte, 2.85 MByte和5.7 MByte，延迟分别对应10 ms，250 ms和500 ms。并通过(2)式来进行计算。

为了计算包头开销对吞吐量的营销，假设包头开销设置为58 Byte(TCP包头为20 Byte，IP包头为20 Byte，以太包头为18 Byte)。因此，最大吞吐量需要除以1024/(1024+58)。

3.2 基于速率控制的协议

空间通信协议规范(space communications protocol specification,SCPS)纯速率控制选项不使用拥塞控制算法。发送速率取决于由用户与接收机缓存大小所定义的速率值。像TCP和SCPS-VJ测试，确认方式使用延迟ACK。如前所述SNACK选项，也可在纯速率控制中使用。

SCPS纯速率控制还有使用“严格延迟ACK”的附加选项。ACK每隔延迟ACK计时器定义的时间发送一次，而不是每个数据包或每隔一个数据包发送一个ACK。在长延迟的环境中，经过较长的时间可能下一个数据包才能到达，使用延迟ACK计时器来触发ACK反馈是有益的。

针对基于速率控制的空间协议，首先通过对基于速率控制的协议的一阶近似，将一个文件总的传输时间等于传输该文件初始数据包的时间加上重传丢包需要的时间，一个往返时延等于一个链接建立之初时的3次握手时间。可以得出，最大吞吐量等于总的文件大小除以总的传输时间。如果假设，每一次丢失的数据包固定在第一次重传，考虑到包头开销对吞吐量的影响，最大吞吐量将减少。因此，错误链路下基于速率控制的协议最大吞吐量，计算公式可以表示为

吞吐量=1024×8×文件大小/(1024+58)/
((文件大小×8×p/P)+(文件大小×8/R)+RTT)

(3)

(3)式中：R表示用户速率；p表示数据包错误速率；RTT表示往返时延。

利用推导出的理论模型(2)式与(3)式分别进行仿真, 仿真场景设置为：传输文件数据量固定为100 MByte，延迟从10～500 ms变化，链路速率设定为100 Mbit/s，数据包大小为1 024 Byte。仿真结果如图4所示。图4分别显示了基于速率控制的协议以及基于拥塞控制的TCP协议的理论吞吐量。图4给出了基于速率控制协议的吞吐量的理论上界，同时显示了3种不同延迟下TCP的理论吞吐量。可以看出，其吞吐量受链路错误的影响很大。因此，基于速率控制的协议在高带宽环境下比TCP协议性能具有较大的优势。

图4 网络协议理论吞吐量对比Fig.4 Network protocol theory throughput comparison

3.3 传输协议仿真性能测试对比

3.3.1 测试环境和协议配置

本文搭建的仿真测试环境如图5所示，测试床环境由2个分开的网络组成，分别代表地面和空间网络。2个网络的连接通过多个虚拟电路，同时经过一个信道模拟器进行桥接，模拟器可以注入时间延迟和数据流随机比特错误。信道每一端网络由1个路由器和1个以太网交换机组成。该交换机用于进行LAN的服务。

图5 测试环境架构Fig.5 Test environment architecture

为了评估这些协议在空间环境的性能，包括长时延，链路易错的特点对性能的影响，将测试环境中的延迟RTT从10～500 ms进行变化，而BER设置为(0～1E-4)。具体参数配置如下。

单流测试中，TCP，SCPS-TP，MDP(multicast dissemination protocol)和MFTP(multiple fiel transfer protocol)协议用到的所有变量如下。

1)文件大小：100 KByte, 1 MByte, 10 MByte, 100 MByte；

2)数据包大小：1 024 Byte；

3)BER大小：0，1.00E-08，1.00E-07，1.00E-06，1.00E-05，1.00E-04。

选择TCP_SACK来进行测试。对于TCP_SACK测试，缺省数值使用Sun Solaris 7 Kernel中的多数TCP/IP参数。

对于SCPS协议的测试共有5种选项，分别如下。

1)Van Jacobson Congestion Control(SCPS-VJ)，每隔一个包确认一次；

2)Pure Rate Control(SCPS-Pure Rate Control, Option F2)，每隔一个包确认一次；

3)SCPS-Pure Rate Control, Option F0；

4)SCPS-Vegas-Congestion；

5)SCPS-Vegas-Corruption。

在进行多个数据流测试时，TCP-SACK, SCPS-VJ和SCPS-Vegas-Congestion采用单个数据流测试中的数据包大小，同时其他参数设置如下。

①文件大小固定为：50 MByte；

②往返时延固定为：500 ms；

③BER数值设置为0，1.00E-07和1.00E-05 3种；

④MDP选项：没有前向校验，速率设置为40 Mbit/s(服务器)；

⑤MFTP选项：最大数据单元设置为1 472(服务器)。

对于SCPS-VJ测试，为了与TCP测试一致，缺省延迟ACK定时器延迟设置为从50～200 ms。其余SCPS-TP参数不变。SCPS速率选择设置为80 Mbit/s和100 Mbit/s。由于平均吞吐量大小比100 Mbit/s略高，所以选择SCPS速率为100 Mbit/s作为测试。

对于TCP-SACK和SCPS-VJ，测试文件大小为100 MByte，误码率环境为1.00E-05。其余测试文件大小分别为10 MByte，1 MByte，100 KByte。误码率环境设置为1E-4。

采用SCPS-RI 1.1.62版本进行SCPS-Vegas-Congestion测试，采用版本1.1.66作为SCPS-Vegas-Corruption测试。这两者的区别在于SCPS版本1.1.66与1.1.62基本功能相似，但是版本1.66可以切换2种慢启动机制。

考虑到仿真时间的限制，Vegas测试只采用10 MByte和100 MByte 2种文件大小，2种Vegas的最优速率分别设置为60 Mbit/s、延迟设置为500 ms，以及80 Mbit/s、延迟设置为10 ms。

3.3.2 仿真结果

3.3.2.1 基于拥塞控制的协议性能

图6显示了不同协议在延时500 ms时的情况下分别发送10 MByte和100 MByte文件大小的平均吞吐量。图7显示了不同BER环境下，不同协议传输10 MByte文件的平均吞吐量。可以看出，3种基于拥塞的协议的总体特性相似。TCP-SACK和SCPS-VJ都使用了Van Jacobson Congestion Control算法，因此，SCPS-VJ和TCP-SACK的总体特性相似。而SCPS-Vegas-Congestion性能略优于TCP-SACK。

在无误码率的环境下，大的文件传输比小的文件传输具有较高的吞吐量，这是因为慢启动在文件越多的情况下影响越小，而在高误码率情况下，小的文件传输比大的文件传输具有更高的吞吐量。对于TCP-SACK和SCPS-VJ，这是因为加性增乘性减拥塞控制算法的作用。每当错误发生时SCPS-Vegas-Congestion的窗口减少一半，所以当网络中发生错误时，SCPS-Vegas-Congestion的吞吐量下降比SCPS-Vegas-Corruption的吞吐量下降快。

在高BER环境下，SCPS-Vegas-Corruption协议的性能比基于拥塞协议性能高。但是性能仍然不如基于速率控制的协议。

3.3.2.2 基于速率控制的协议性能

本测试不涉及拥塞控制机制，当在网络中没有拥塞的情况下，只能进行单个数据流的测试。首先给出该网络场景下3类协议的基本参数配置。

在单流测试中协议的参数配置如下。

1)SCPS基于速率控制协议。

SCPS Pure-Rate Control (SCPS-Pure-Rate-2)：每隔一个包确认一次。

Pure-Rate Control (SCPS-Pure-Rate-F0)：延迟确认。

对于SCPS-Pure-Rate-F2测试，将SCPS-RI版本1.1.51中的延迟ACK定时器改为50 ms。测试中最优速率为80 Mbit/s。

当使用SCPS-RI 1.1.51版本进行SCPS-Pure-Rate-F0调整测试时，确认包并不是按照默认ACK定时器规定的每隔200 ms进行发送，而是确认包的延迟大于200 ms。ACK最短往返时间为200 ms，最长可以在1～2 s。由于接收端窗口更新的速率并不及时，从而ACK返回的速率减少了接收窗口的大小。

图7 基于拥塞协议性能(10 MByte文件传输)Fig.7 Performance based on congestion protocol(10 MByte file transfer)

2)MFTP。

配置MFTP传输时应用的最大速率配置为50 Mbit/s。此外，指明2个系统的单播地址。设置MFTP服务器一次传输一个文件，但是在起始传输时间时，需要传输修复数据去应答客户NACKS高达100次。

3)MDP。

配置MDP使用单播地址传输时最优速率配置为40 Mbit/s。服务器传输数据块不进行前向校验，并且重传其负载。

通过仿真测试，结果如图8和图9所示。

图8 具有500 ms时延的Rate-based文件传输Fig.8 Performance based on congestion protocol(10 MByte file transfer)

图9 Rate-Based平均吞吐量与BER的对比Fig.9 Comparison of Rate-Based average throughput with BER

图8显示了在500 msRTT延时下不同基于速率控制协议的性能。当传输大文件时，可以看出，没有基于速率控制的协议可以与理论吞吐量吻合，这个可能跟协议实现的机理有关。尽管所有基于速率控制协议的吞吐量实验结果略低于理论数值，10 MByte MFTP在3种不同延迟下的曲线与理论数值曲线接近。在有BER和延迟的情况下，MDP的性能大概有35 Mbit/s，性能比SCPS-TP速率控制协议略好。但在高BER的环境下，吞吐量速率下降很快，与理论计算数值并不匹配。在低BER的环境下，与理论计算数值也不完全一致。尤其在高BER和高延时的情况下，接收机变得超负荷，与发送方不能保持一致。

在图9中，相比于各自在500 ms时的吞吐量曲线，SCPS-Pure-Rate-F2和 SCPS-Pure-Rate -F0在10 ms时延情况下的曲线与相应的理论曲线非常接近。这更能说明这也许是个内存管理问题。另外，SCPS在内核层的实施能够提升其性能。

3.3.2.3 多业务流时基于拥塞控制的协议性能

在单流实验中，单个流可以利用全部带宽。在多流实验中，三对流竞争可用的带宽。对于这些测试，在路由器的ATM(asynchronous transfer model)接口上将带宽设置为15 Mbit/s。在时间限制上只允许一个有限的测试子集在具有500 msRTT时延上运行，该子集的BER分别为0，1.00E-07和1.00E-05，和一个大小为50 MByte的单独文件。如图10所示，与单流测试相似，SCPS-Vegas-Congestion 的表现仅比TCP-SACK好一点，而TCP-SACK的表现又比SCPS-VJ在0和特定BER同时具有500 msRTT时延情况下好一点点。在BER为1.00E-07 和1.00E-05情况下，在多流测试下的每一对流的吞吐量具有与单流情况下几乎完全相似的性能。这是因为错误对吞吐量的影响远比拥塞对吞吐量的影响大。

图10 多个数据流吞吐量随着BER的变化Fig.10 Throughput of multiple data streams varies with BER

需要注意的是，所有的平均吞吐量可能会超过网络容量。这是因为三对流的随机偏移开始次数，这里每个数据流都以随机的时间间隔开始，使各自的流传输和完成时对可用信道带宽的利用率都不同。在任意子集的全体平均吞吐量能够超过15 Mbit/s,尤其在第一个和最后一个传输没有太多交叠的情况下。

图11显示了每个TCP-SACK流测试组中的30次测试的吞吐量。测试反映了每个收发机组在BER=0情况下的特性，相同的结果也发生在SCPS-VJ 和SCPS-Vegas-Congestion测试中。对每组测试数据进行分析后发现，SCPS-Vegas-Congestion测试中没有一个流的吞吐量低于3 Mbit/s。然而在TCP-SACK 和 SCPS-VJ 的测试中，30次测试中有20次测试的吞吐量低于3 Mbit/s。尽管在TCP-SACK 和SCPS-VJ测试中吞吐量分别是2.3 Mbit/s—7.9 Mbit/s和1.9 Mbit/s —7.5 Mbit/s，相应地在SCPS-Vegas-Congestion的流测试中，最小吞吐量和最大吞吐量分别为3.2 Mbit/s和9.5 Mbit/s。

图11 分别多流传输时各自吞吐量Fig.11 Respective throughput of multi stream transmission

对以上的结果进行分析可知：

1)在空间环境中，多个数据流和单个数据流测试结果显示出SCPS-Vegas对TCP的增强可以提供性能改进。

2)在高RTT延迟下，即在具有高RTT延迟的错误敏感环境下，基于速率控制的协议性能是显著下降的。现有拥塞的传输协议虽然能满足大多数任务需求，但是仍需要对其进行修改和优化。

3.4 天基网络路由协议性能分析

3.4.1 主要路由算法比较

目前卫星网络路由协议充分利用卫星网络拓扑变化的周期性和可预知性，减少路由协议对网络资源的消耗，这样处理后果是路由协议受限于卫星网络拓扑，一旦卫星网络拓扑结构发生变化，如加入新节点、新轨道、新星座，则路由协议需要作出较大改变，扩展性并不强。

表1是对几种典型卫星网络路由算法与地面无线传感器网络路由算法的比较。其中，N为网络中节点数量，e为通信链路数量。抗毁性是指当网络中某链路或者节点失效后，路由能否快速作出反应，选择新的路径。对于基于快照序列的卫星网络路由算法、Ekici分布式卫星网络路由算法、AODV、DREAM等路由协议，当发生链路或者节点失效时，均需要重新寻找路径，产生大量网络控制信息，而基于地理位置信息抗毁性路由协议在链路或者节点发生失效后能够在本地快速做出反应，选择新的路径。

3.4.2 性能指标分析

在高度基本相同的卫星网络场景下，按照卫星网络传输任务的特点，针对卫星网络路由算法分别从数据包转发、系统复杂度以及可移植性3个方面进行性能分析，对卫星网络路由算法进行比较。数据包转发方面主要包括延时、健壮性、稳定性、正确性、公平性和最优性等性能指标；系统复杂度方面主要包括卫星网络节点计算与存储复杂度、对地面基站的复杂度要求等性能指标。具体对比参见表2—表4。

基于离散拓扑序列的卫星网络路由算法首先会建立卫星节点间的虚链路，选取备选路径中延时小和切换次数少的路径作为最优路径，理论上时延抖动偏小，但网络实际运行过程中，延迟小和切换次数少可能是2个相互冲突的条件，所以使用基于离散拓扑序列的路由算法的卫星网络实际运行过程中延迟抖动往往比理论分析要大。

基于地理位置的卫星网络路由算法没有采用虚连接方式，由于选路存在不确定性，延时抖动不能保证。时延抖动相对严重。其中，基于地理位置的分布式抗毁路由算法在Ekici分布式卫星网络路由基础上，优先选择地理位置更接近目标的邻居作为下一跳，能获得较好的端到端时延结果。

基于离散拓扑序列的卫星网络路由算法采用虚通道机制，面向连接的传送方式比较稳定，但路由表无法根据网络实际情况实时更新，在链路状态发生变化时，需要首先由地面站节点重新计算路由，然后根据卫星拓扑结构变化选择合适时间向上发送路由信息，更新星上路由表，健壮性不够好。基于快照的卫星网络路由算法在ATM机制的基础上加入了备选路径处理，卫星优化切换时路径选取，算法稳定性加强，但是由于备选路径有限，如果备选路径全部失效，路由表仍然需要延迟更新，而且由于卫星需要存储大量备选路径，极大地增加节点存储复杂度，算法健壮性仍然较差。目前，基于离散拓扑序列的卫星网络路由算法由于无法实时获取网络状态，所以往往不考虑公平性等需要实时信息的性能指标，仅将最短延迟和最少切换次数作为路由决策标准，在网络负载较重情况下性能不佳，在同一时间片内很可能出现网络中部分卫星负载很重，而另外一部分卫星基本没有网络负载。虽然时间片间路由算法能够根据获取信息进行相应调整，但是需要等待时间片时间，所以反应速度较慢。

表1 路由算法比较Tab.1 Comparison of routing algorithms

表2 卫星网络路由算法数据包转发对比Tab.2 Comparison of routing algorithms for packet transmission in satellite networks

表3 系统复杂度对比Tab.3 Comparison of system complexity

基于地理位置的卫星网络路由算法采用实时寻路，根据收集到的卫星网络实时状况选择数据传输路径，对网络状况实时变化反应灵敏。但是由于分布式特性，很难使用全局信息进行路由判断，而是使用局部信息选取最优路径，这种路由选择方式无法保证全局最优。基于地理位置的卫星网络路由算法根据实时情况选择通路，重视效率，局部处理公平性和最优性，能够获得较好的公平性。

基于离散拓扑序列的卫星网络路由算法需要地面站根据卫星网络的离散拓扑序列计算每个时间间隔内的卫星网络的最优路径，并上传至网络中的所有卫星。当网络发生故障的时候，地面站无法及时获取信息，在发生故障状况时也需要重新计算,计算复杂度高。对于卫星节点，由于要存储大量路由表，存储复杂度高，但只需按标签转发，路由计算复杂度低。

基于地理位置的卫星网络路由算法地面站不需要预先计算路由表，各个卫星节点实时计算数据传输路径，地面基站计算复杂度以及存储复杂度都降低。卫星节点由于不需要接收与存储地面站发送给卫星的路由信息，网络数据传输负担以及卫星节点存储负担均明显降低。但卫星节点需要实时计算数据传输路径，因此卫星计算复杂度较高。随着计算附加条件增加及卫星网络环境的复杂度提高，卫星节点计算复杂度明显上升。

基于离散拓扑序列的卫星网络路由算法，卫星节点需要不断接收地面站发送来的路由信息与网络负载。对于地面站节点，当新加入或者移出卫星或卫星系统，地面站需要重新计算整网路由，对地面站计算能力要求很高。同时由于是地面站集中控制，所以算法移植性很好，卫星网络系统的改变仅需要对地面站中央控制节点作出反应，其余卫星节点不需要做任何改变。

基于地理位置的卫星网络路由算法可以不预先计算路由表，各卫星节点实时计算并传输数据信息，地面站不需要进行大量计算得出整网路由信息，并将大量路由信息发送到每个卫星节点，网络负担轻。但是传统的基于地理位置的卫星网络路由算法都考虑某一个特定网络模型，而且卫星逻辑地址是按照特定系统与地球表面所决定的，如Iridium和Teledesic系统，当新增或者减少卫星导致卫星星座不是预先设定规则星座时，路由算法可能无法正常工作。如果组成的新系统网络拓扑不够规则，无法满足算法预先设计好的规则拓扑，则路由算法根本无法运行，因此可移植性较差。而基于地理位置的分布式抗毁路由算法充分考虑了不同的网络拓扑变化对路由的影响，具有较好的可移植性。

表4 算法可移植性对比Tab.4 Comparison of algorithm portability

4 总 结

本文总结和讨论了天地一体化信息网路的特点和主要研究问题。重点分析了一体化网络的协议体系并进行了比较分析，通过对不同的协议体系分析，我们认为，CCSDS协议体系可以作为未来天基骨干网的协议体系。但是，其中的传输层、网络层以及链路层的功能都要进行适应性改造和优化以满足天地一体化信息网络传输的要求。另外，对一体化网络的路由问题进行了深入地讨论，比较分析了主流的路由机制与优缺点。

[1] 刘立祥.天地一体化网络[M].北京:科学出版社,2015.

LIU L X. Space-ground integrated network [M]. Beijing: Science Press, 2015.

[2] DU J, JIANG C, WANG J, et al. Stability analysis and resource allocation for space-based multi-access systems[C]// IEEE Global Communications Conference. San Diego, CA, USA：IEEE, 2015:1-6.

[3] 刘春保.2015年全球导航卫星发展回顾[J].国际太空,2016(2):29-35.

LIU C B. 2015 year in review: global navigation satellites[J]. Space International, 2016(2):29-35.

[4] 刘春保.2016年国外导航卫星发展回顾[J].国际太空,2017(2):34-42.

LIU C B. 2016 year in review: Foreign navigation satellites[J]. Space International, 2017(2):34-42.

[5] HE J F, JIANG Y, ZHANG G X, et al. Topology and route production scenario of walker satellite constellation network with inter-satellite link[J]. Journal of Pla University of Science & Technology,2009,10(5):409-413.

[6] 卢勇，赵有健，孙富春,等.卫星网络路由技术[J].软件学报,2014,25(5):1085-1100.

LU Y, ZHAO Y J, SUN F C, et al. Routing techniques on satellite networks[J]. Journal of Software, 2014, 25(5):1085-1100.

[7] JIN X, ZHANG P, YAO H. A communication framework between backbone satellites and ground stations[C]// International Symposium on Communications and Information Technologies.Qingdao,China:IEEE,2016:479-482.

[8] 刘基余.北斗卫星导航系统的现况与发展[J].遥测遥控,2013,3(34):1-8.

LIU J Y. Status and Development of the Beidou Navigation Satellite System[J]. Journal of telemetry, tracking and command, 2013, 3(34): 1-8.

[9] Space communications protocol standards (SCPS) [EB/OL].[2017-08-08]. http://www.scps.org.

[10] CERF V, BURLEIGH S, HOOKE A, et al. Delay-tolerant networking architecture: IETFRFC 4838, informational[S]. [S.l.]: Network Working Group, 2007.

[11] CHIANG M, LOW S H, CALDERBANK A R, et al. Layering as optimization decomposition: a mathematical theory of network architectures[J]. Proceedings of the IEEE, 2007, 95(1):255-312.

[12] SABBAGH A, WANG R, ZHAO K, et al. Bundle protocol over highly asymmetric deep-space channels[J]. IEEE Transactions on Wireless Communications, 2017, 16(4):2478-2489.

[13] SHI L, JIAO J, SABBAGH A, et al. Integration of reed-solomon codes to licklider transmission protocol (LTP) for space DTN[J]. IEEE Aerospace and Electronic Systems Magazine, 2017, 32(4):48-55.

(编辑：魏琴芳)