一种星地协同任务管理系统的制作方法

本发明涉及通信技术领域，特别是指一种星地协同任务管理系统。

背景技术：

在卫星通信领域，随着激光链路以及中低轨高容量卫星的引入，天基高速卫星通讯网开始出现。现有技术中，卫星通讯网通常由多个卫星节点、多个地面节点（信关站）以及地面网管中心组成。其中，地面网管中心控制地面站连接一颗或者多颗卫星，从而通过地面站与星上节点进行通讯。在业务层面，卫星节点和地面站共同组成卫星通讯的业务传输骨干网络。

这种结构中，由于卫星位置的变化，地面节点无法长期与同一卫星保持连接，使得星地链路或者星间链路周期性地断开和重建，拓扑结构不断发生变更。此外，由于部署在地面的监测控制站的数量和位置限制，无法保障随时能够直接连通每一个卫星节点。这些因素使得卫星网络的维护以及网络状态的检测变得困难。

目前,通常通过地面测控信道，仅当卫星节点与地面站联通时，才能够上注链路规划信息，完成拓扑建立和路由表上注，而无法通过已有的链路实现重构。无论是采用ip静态路由或者基于路由协议的动态路由方式，均存在如下缺陷：

一方面控制面和业务面的传输没有分离，无法实现业务隔离、透明传输和可靠端到端带宽保障机制；

另一方面受限于硬件性能，软路由方式无法实现高吞吐率的数据传输。

技术实现要素：

有鉴于此，本发明提出一种星地协同任务管理系统，其采用新的任务组织方式以及管理架构，能够在节点自主协商机制不健全或者出现故障时，通过地面网管中心建立和恢复数据通信链路和卫星拓扑状态。

为了实现上述目的，本发明采用的技术方案为：

一种星地协同的任务管理系统，其包括地面信关站、地面网管中心以及由多个卫星组成的卫星网，每个卫星均具有控制模块、网管代理模块、数据交换设备和多台通信终端；

所述控制模块用于获取链路状态、实现路由协议和标签分配；

所述网管代理模块用于执行地面网管中心的任务执行命令，并将命令分发给星内的其他模块或设备；

所述数据交换设备根据控制模块生成的标签转发表执行业务数据转发；

所述通信终端用于星内和星地链接；

所述地面信关站用于与卫星建立连接；

所述地面网管中心通过地面网连接各地面信关站，从而对整个卫星网络进行集中管控；具体方式为：

地面网管中心对任务进行两次分解，第一次分解将任务分解为每个卫星所需要执行的节点任务，第二次分解将节点任务分解为星内设备的设备任务；其中，节点任务的跨星协同由地面网管中心负责，星内设备任务的协同由各卫星的网管代理模块负责。

进一步地，所述地面网管中心将所有节点任务一次性发往各网管代理模块，所述网管代理模块将节点任务的执行结果发给地面网管中心，节点任务间的依赖关系由网络拓扑、网络拓扑的可调整性以及任务本身的依赖性所决定。

进一步地，所述设备任务根据依赖关系形成依赖树，并以设备任务列表形式进行发送；

所述设备任务由前置任务列表、设备编号、设备命令字、命令内容，以及命令超时时间组成；

其中，前置任务列表为空时表示为根；

当父节点任务完成后，没有依赖的多个子节点任务并行执行；

一项任务的任意前置任务未完成或者失败，则导致任务执行失败。

进一步地，所述网管代理模块对于节点任务或设备任务的执行方式为原子性操作，即，要么完全执行完成，要么回退到执行前的状态。

进一步地，所述卫星、地面信关站和地面网管中心均作为卫星骨干网的节点；其中，地面网管中心作为节点0，为地面网与卫星网的唯一关口，统一负责地面网与卫星网的业务互通。

进一步地，所述卫星、地面信关站和地面网管中心的地址段均在一个固定范围中，不在该范围内的地址即为需要落地的业务，其出口节点为节点0。

采用上述技术方案的有益效果在于：

本发明的网管中心首先将任务分解为由每个节点处理的节点任务；对于每个节点任务，又分解为由节点内设备处理的设备任务。同一任务内的节点任务以依赖树形式组成，由网管中心负责与各节点的协同处理。同一节点任务内的设备任务也以依赖树形式组成，由网管中心一次性发往节点，节点负责与各设备协同交换，并将执行结果返回给地面控制中心。其采用新的任务组织方式以及管理架构，能够在节点自主协商机制不健全或者出现故障时，通过地面网管中心建立和恢复数据通信链路和卫星拓扑状态。

附图说明

图1是本发明实施例中系统的结构示意图；

图2是本发明实施例中星上设备的结构示意图；

图3是任务描述示意图；

图4是监控参数描述示意图；

图5是建立物理拓扑的流程示意图；

图6是建立物理拓扑的节点任务组成示意图；

图7是创建业务链路的流程示意图；

图8是创建业务链路的节点任务组成示意图。

具体实施方式

下面结合附图和具体实施方式对本发明做进一步的详细说明。

一种星地协同的任务管理系统，其包括地面信关站、地面网管中心以及由多个卫星组成的卫星网，每个卫星均具有控制模块、网管代理模块、数据交换设备和通信终端；

所述控制模块用于获取链路状态、实现路由协议和标签分配；

所述网管代理模块用于执行地面网管中心的任务执行命令，并将命令分发给星内的其他模块或设备；

所述数据交换设备根据控制模块生成的标签转发表执行业务数据转发；

所述通信终端用于星内和星地链接，可以采用激光通信终端或者微波通信终端；

所述地面信关站用于与卫星建立连接；

所述地面网管中心通过地面网连接各地面信关站，从而对整个卫星网络进行集中管控；具体方式为：

地面网管中心对任务进行两次分解，第一次分解将任务分解为每个卫星所需要执行的节点任务，第二次分解将节点任务分解为星内设备的设备任务；其中，节点任务的跨星协同由地面网管中心负责，星内设备任务的协同由各卫星的网管代理模块负责。

进一步地，所述地面网管中心将所有节点任务一次性发往各网管代理模块，所述网管代理模块将节点任务的执行结果发给地面网管中心，节点任务间的依赖关系由网络拓扑、网络拓扑的可调整性以及任务本身的依赖性所决定。

进一步地，所述设备任务根据依赖关系形成依赖树，并以设备任务列表形式进行发送；

所述设备任务由前置任务列表、设备编号、设备命令字、命令内容，以及命令超时时间组成；

其中，前置任务列表为空时表示为根；

当父节点任务完成后，没有依赖的多个子节点任务并行执行；

一项任务的任意前置任务未完成或者失败，则导致任务执行失败。

进一步地，所述网管代理模块对于节点任务或设备任务的执行方式为原子性操作，即，要么完全执行完成，要么回退到执行前的状态。

进一步地，所述卫星、地面信关站和地面网管中心均作为卫星骨干网的节点；其中，地面网管中心作为节点0，为地面网与卫星网的唯一关口，统一负责地面网与卫星网的业务互通。

进一步地，所述卫星、地面信关站和地面网管中心的地址段均在一个固定范围中，不在该范围内的地址即为需要落地的业务，其出口节点为节点0。

具体来说，该系统如图1所示。为实现业务建链等卫星网业务，在管理层面将管理架构分为地面网管中心和网管代理两部分，网管中心部署可以部署地面的任意位置，通常在一个地面站，网管中心在逻辑上独立于地面站。网管中心通过一个或者多个地面关口站（信关站）管理整网。

对于不同节点，网管中心可以通过不同的地面信关站与之通讯。网管中心负责卫星通信网络的运行维护，包括配置管理、状态监视、故障管理、性能管理等功能。

网管代理部署在卫星节点和信关站节点上，接收来自网管中心的管理指令，负责设备的数据采集和控制命令执行。

为方便描述，如图2所示，将卫星通讯网的协议栈设定下层为标签转发,由数据交换设备根据标签转发表负责数据转发。上层为ip路由，由控制设备执行路由协议，负责全网拓扑的发现，并根据业务请求和路由表配置数据交换设备的标签转发表从而实现业务通讯。管控数据可以通过在帧头定义特殊标记位传输，也可以插入每个帧的帧头某一个固定字段中，由数据分发设备识别抽取后转往控制模块或者网管代理。

为实现节点a到节点b的业务通信，则必须首先创建节点a到节点b的物理链路。然后由控制设备根据路由协议自动生成或由网管创建节点a到节点b的路由协议。当有业务数据需要通过节点a到达节点b时，则由控制面根据路由表向标签转发表添加条目或者由网管直接配置标签转发表。

为了实现当某个信关站与卫星链路发生中断时，业务数据仍然能够保持传输，需要业务落地点的自由选路。为此，所有卫星、地面信关站和地面网管中心在逻辑上均作为卫星网的节点。其中地面网管中心作为节点0，为地面核心网与卫星网的唯一关口，统一负责地面核心网与卫星网的业务互通。

为实现业务地址到节点的快速映射，每个节点的地址段设计为固定的范围。所有节点的地址段可以合并一个通用的地址段。不在节点地址段范围内的地址即为需要落地接入地面核心网的业务，其出口节点为节点0。

例如，可以设定一个节点内的业务段为2001:db8:0:{node_id}::/64，则所有不是2001:db8:0::/48的业务地址均为落地业务，也就是发往节点0。

在本系统中，将任务进行两层分解，跨星协调由地面网管中心负责。而星内与各设备的通信由节点内的网管代理负责。任务描述和监控参数描述如图3、4所示。

如上所述，地面网管中心将任务（诸如拓扑更新、建立业务链路等）分解为节点任务(nodetask),每个节点任务又会被分解为与不同星上设备交互的设备任务(devtask)。具体的任务内容既可以是配置，也可以是查询。配置既可以是对业务进行配置（如建立链路），也可以是订阅设备产生的事件。

为描述需要监控的参数，可将参数分为2个层次，节点级别（node）、节点内设备级别（device）。关于参数详情，分别由节点参数表和节点内设备参数表描述。

网管中心将节点任务一次性发往网管代理，由网管代理将节点任务的执行结果发给地面网管中心。网管代理可以将节点任务执行的中间结果提前返回网管中心。节点任务间的依赖关系由地面网管中心负责实施。节点内各设备任务间的依赖关系由星上代理负责实施。

节点任务间的依赖关系由网络拓扑、网络拓扑的可调整性以及任务本身的依赖性决定。地面网管中心始终维护到每个信关站的连通性、每个卫星的轨道位置信息，以及到每个卫星节点的可达性。

为保证节点具有可配置性，目标是保证任意节点在任意时刻到地面网管中心都至少有一条路径可达。例如，如果需要建立节点a到节点b的物理链路，则网管中心必须能够到达节点a和节点b，如果不能，则必须通过配置到达或者放弃建立物理链路。对于建立从节点a经节点b到节点c的业务链路，如果网管中心当前只能通过信关站到达节点b。如果节点b到节点c的物理链路可达，但是由于路由或者标签转发表错误，导致网控中心无法到达节点b，则网控中心需要通过节点b的配置，使得节点b到节点c的管理数据可达。如果节点b到节点a的物理链路出现故障，则网管中心则必须根据当前卫星网的拓扑情况，通过地面节点的逐条配置到达节点a，通过配置使得节点a到节点b的物理链路恢复。

对于发往节点的任务，以依赖树状结构进行组织。在发往节点时，以设备任务列表形式组织。对于每一项设备任务，由前置任务列表，设备编号（也即负责该设备任务的设备编号），设备命令字，命令内容，命令超时时间，命令是否重复及重复周期等组成。前置任务列表为空时表示为根。当父节点任务完成后，没有依赖的多个子节点任务可以并行执行。示例如下：

[

list<uint8>pre_tasks;

uint8dev_id;

uint8cmd_id;

bytescmd_str;

uint8timeout;

uint8repeat;

]

网管代理对于节点任务或设备任务的执行可以设置为原子性操作，即，要么完全执行完成，要么回退到执行前的状态。为实现原子操作，则任何对设备的配置均具有可逆性，所有可配置的内容必须可查询。

如图5所示，当需要更新星上拓扑时，先由地面网管中心构造出新的拓扑规划表，然后将新的拓扑规划表上传到卫星上进行更新。这里要注意，图中卫星a此刻与地面相连，故星地交互使用实线，卫星b实际通过卫星a与地面相连，故星地交互使用虚线。具体流程如下：

s1）地面网管中心构造拓扑规划表，上注到需要建立连接的卫星a和卫星b；

s2）网管代理通知激光通信终端拓扑规划表；

s3）网管代理通知控制设备拓扑规划表；

s4）激光通信终端根据拓扑规划表完成建链过程；

s5）激光通信终端通知控制设备链路状态变更；

s6）激光通信终端通知网管代理链路状态变更；

s7）控制平面通知网管代理链路状态变更；

s8）网管代理将新的链路状态通知地面网管中心。

整个任务分解为两个并行的节点任务，分别发往卫星a和卫星b。每个节点任务如图6所示，分为两个设备任务，分别为激光通信终端的拓扑建链任务，和控制设备的拓扑建链表更新任务。卫星内的两个设备任务为并行任务。

为了通过网管直接配置业务通信链路，如图7所示，需要建立一条卫星a到卫星c的链路。约定每颗卫星的管理ip在上星前已经固化，并且不可变更。在星上控制模块出现故障时，无法构建正常的路由表，因此也无法根据路由表构建相应的标签转发表，因此需要地面网管中心介入恢复数据通信连接。地面网管中心首先能够到达卫星a、b、c中的任意卫星。在此假定能够到达卫星a，所以卫星a与地面网管中心的交互使用实线代表，而卫星b，卫星c则均不能直接到达地面网管中心，所以与地面网管中心的交互使用虚线代表。整个过程依次对卫星a、卫星b、卫星c执行如下过程：

p1）将对卫星a的静态路由配置和标签转发表信息以复合消息的方式发往网管代理；

p2）网管代理向控制设备配置静态路由；

p3）控制设备响应静态路由配置结果；

p4）网管代理向数据交换设备配置标签转发表；

p5）数据交换设备响应标签转发表配置结果；

p6）网管代理将结果以组合消息的形式发回地面网管中心。

因此整个任务分解为3个节点任务，三个节点任务为串行任务，在执行完发往卫星a的任务后，地面网管中心才会执行发往卫星b的任务；执行完成卫星b的任务后才会执行发往卫星c的任务。

对于发往卫星a的节点任务，如图8所示，为3个设备任务，分别为：

（1）发往控制设备（控制面）的路由配置命令；

（2）发往数据交换设备（传输面）的标签转发表配置命令；

（3）发往网管代理的通知对端节点命令（该命令用于配置对端节点b到a的返向路由及返向标签转发表）。

其中（1）和（2）为并行任务，设备任务（3）依赖于任务（1）和（2）。

总之，本发明采用了新的任务组织方式以及管理架构，能够在节点自主协商机制不健全或者出现故障时，通过地面网管中心建立和恢复数据通信链路和卫星拓扑状态，是对现有技术的一种重要改进。