卫星协同的天地一体化边缘计算网络架构

张馨元，刘 江，2，张 然，2，黄 韬，2

(1.北京邮电大学 网络与交换国家重点实验室，北京 100876；2.网络通信与安全紫金山实验室，江苏 南京 211111)

0 引言

近年来，由于天地一体化网络(Satellite-Terrestrial Networks,STNs)具有传统地面网络无法比拟的优势，如全球覆盖、抗自然灾害、低时延、高带宽等，在通信、导航、物联网等领域发挥着重要作用[1]。然而，随着增强现实/虚拟现实(AR/VR)、4K/8K视频和多方交互应用等新业务的出现，卫星网络仅作为远程地面数据中心的中继，无法提供高效的数据处理响应。因此，最近的研究考虑卫星上的计算能力，将边缘计算(Edge Computing,EC)与STNs相结合，提供在轨计算服务。

这种新模式有许多好处，在轨计算将传统云计算“随时计算”的承诺扩展为“随地随时计算”。具体来说，一方面，利用卫星的广播/组播特性，在卫星上预先缓存数据可以减少内容获取时延，避免相同内容的重传，大大减少了天地一体化网络的卫星下行流量。另一方面，将计算转移到更近的卫星计算平台，特别是在没有边缘站点的偏远地区，可以为延迟敏感和计算密集型应用提供更高效的服务保障。将部分天基数据 (如地球图像和天气观测) 的处理转移到卫星上，可以减少因天基数据回传而带来的星地链路的带宽浪费。

这种新的天地一体化边缘计算网络(Satellite-Terrestrial integrated Edge Computing Networks，STECNs)引起了研究者的极大兴趣。通过将卫星网络作为中继，远离边缘计算服务器的用户设备也可以享受全球计算服务[2-3]。此外，通过直接在卫星上处理任务，进一步减少了带宽浪费和访问延迟。文献[4]提出了一种多层异构的STECN架构；文献[5]提出了一种基于软件定义的STN架构，用于管理、整合网络、缓存和计算资源；文献[6]提出了一个由嵌入式硬件平台和微服务软件架构组成的5G STECN框架；文献[7]提出了服务于车联网的STECN架构；文献[8]介绍了一种用于遥感的纳米卫星在轨边缘计算体系架构。此外，对STECN中的计算卸载[9-10]、任务调度[11-12]、内容缓存[13]等具体问题也有进一步的研究。

虽然已有许多关于STECN的研究，但在这些研究工作中，每个卫星是作为独立个体参与任务处理的，换言之，一个计算任务被卸载到单颗卫星或远端数据中心执行。这些研究忽略了卫星协同边缘计算的可行性，即卫星间协同参与任务处理，一个计算任务被卸载到卫星协同计算群或远端数据中心执行。单颗卫星参与边缘计算的弊端有以下几点：首先，单颗卫星的计算资源和缓存能力有限，导致卸载到卫星的任务接受率很低；大量的任务数据被送回到地面数据中心继续处理，造成卫星能源消耗巨大和下行链路过载问题。其次，全球人口分布不均，大部分地球表面的人口分布稀少，因此，大量的低轨卫星计算资源在大部分时间都是闲置的，资源利用率较低。最后，卫星星座节点规模巨大，拓扑频繁变化，以单颗星为单位进行资源管理和任务分配，开销巨大且十分复杂。因此，基于以上挑战，需要提出新的卫星协同天地一体化边缘计算架构。

大量已有研究证明，边缘节点协同计算可以有效提高传输速率，减少处理延迟[14]，在多种场景中均有应用，如物联网设备[15]、无人机[16]、车辆[17]、蜂窝接入点[18]等。边缘节点协同计算的优势有以下四点：① 一个任务被分解为多个可并行化处理的子任务，同时在多个节点上处理，加快了任务处理速度；② 同一计算集群的节点间，可以复用相似任务的处理结果，减少多余的资源消耗，如对同一地理位置的遥感图像识别等；③ 计算集群可形成一个动态资源池，节点间灵活地共享资源，接受更多的任务，平衡资源利用；④ 边缘计算的任务分配、资源调度等问题，可以集群为单位进行优化求解，大大缩小了问题解空间的规模，提高求解效率。

尽管前人关于边缘节点协同计算的研究很有价值，但它们并不适用于卫星协同的天地一体化边缘计算场景。由于卫星节点资源有限、负载随时空变化、拓扑高度动态等特点，需要提出新的卫星协同天地一体化边缘计算网络架构。本文从卫星边缘计算硬件平台、管控架构及卫星协同计算机制三方面，阐述卫星协同下的天地一体化边缘计算网络架构，为后续天地一体化边缘计算研究奠定基础。

1 相关研究

文献[2]提出将天地一体化网络与边缘计算融合，用于服务质量的提升，使远离边缘计算基础设施的用户，也能通过卫星链路，享受边缘计算服务。在此架构中，低轨/中轨/高轨卫星都可以作为用户和地面骨干网之间的中继，具体卫星的选择根据时延、覆盖范围等需求决定。有基础设施覆盖、低级分布的用户，通过拥有大功率卫星天线的基站连接卫星。处于偏远地区、稀疏分布的用户，则通过个人的、功率有限的卫星终端天线连入低轨卫星。这些稀疏分布的用户，可以是高空飞行器和飞机、应急通信用户、偏远地区和海洋通信用户。除此之外，文献[2]还给出了网络资源虚拟化和协同计算任务卸载模型。

文献[4]在文献[2]的基础上，将卫星的在轨处理能力纳入考虑范围，提出了星上可计算的天地一体化边缘计算架构。在此架构中，用户设备可根据地理位置、业务需求，选择地面边缘计算平台、边缘计算集群(车辆集群、船只集群、高空飞行器集群等)以及卫星边缘计算平台、卸载计算任务。此外，文中还提出了天地一体化边缘计算网络中的关键技术挑战，如协同计算卸载、多节点任务规划、移动性管理等。

文献[5]则面向资源感知，提出了基于软件定义的(Software-defined Network,SDN)天地一体化网络架构。此架构中，卫星作为通信资源的一种，与网络资源、缓存资源、计算资源一起，用于动态管理和联合编排。文中还将资源分配问题建模为联合优化问题，使用马尔可夫决策过程和深度Q学习来求解最佳资源分配策略。

以上工作提供了宝贵经验，但都忽略了卫星协同计算的场景。基于以上研究，将卫星协同计算纳入考量，并针对卫星节点资源有限、负载随时空变化、拓扑高度动态等特点，深化卫星边缘计算硬件平台及管控架构的设计，给出新的卫星协同下的天地一体化边缘计算架构。

2 卫星边缘计算硬件平台

在一个计算协同域内，有资源管理和资源两种节点。图1给出了一个卫星计算协同域内的硬件资源平台。

图1 硬件平台Fig.1 Hardware platform

2.1 卫星资源节点硬件平台

卫星资源节点有多种类型，如GPU资源节点、FPGA资源节点、存储资源节点、通用资源节点等，卫星资源种类与卫星搭载的硬件平台有关。

GPU资源节点搭载GPU NVIDIA jetson芯片，这种芯片包含多个GPU核和CPU核，可提供GPU计算资源，主要用于图像处理、深度学习计算和其他计算密集型业务。

FPGA资源节点搭载Xilinx Zynq UltraScale + MPSoC FPGA平台，包含多个CPU核和FPGA可编程逻辑单元，支持在轨动态重配置，可作为多核处理器使用，支持加速处理视频/图像处理、深度学习、数据分析等业务。

存储资源节点搭载大容量的固态硬盘和CPU，支持大量数据的存储。

通用资源节点通常搭载CPU、内存、存储等多种硬件平台，支持通用化的业务处理。

无论何种资源节点，考虑到能耗问题，节点上搭载的都是基于精简指令集(RISC)的ARM CPU。相对于Intel X86处理器而言，ARM的指令集和硬件逻辑更加简单，因此能耗更低，适用于功率、散热受限的卫星节点。

每个卫星资源节点都使用基于容器的虚拟化技术，如Docker，用于自身资源的抽象。

除以上资源外，每个卫星资源节点还拥有支持SDN的网络接口，用于灵活的资源管理和配置。

2.2 卫星资源管理节点硬件平台

每个计算域内存在一个资源管理节点和多个备用资源管理节点，在资源管理节点故障时，迅速从备用资源管理节点中选出一个新代理节点，代替原节点工作。

通过资源节点中的资源虚拟化容器，资源节点将自身资源抽象，上报给资源管理节点。资源管理节点维护着高可靠性的数据库，存储计算域的资源信息，并将这些信息用于资源管理、业务部署、安全保障策略等。对各资源节点的配置则由资源管理节点通过SDN南向协议下发。

3 卫星边缘计算管控架构

3.1 分级分域的控制器放置

卫星边缘计算控制器的分级分域放置如图2所示，设计原则如下：

图2 卫星协同边缘计算架构Fig.2 Architecture of satellite cooperative edge computing

① 若以单颗星为单位进行管控，则资源分配及任务规划计算复杂，节点资源状态更新时全网洪泛开销巨大，因此将整个卫星边缘计算平台划分为多个计算域，以域为单位进行资源分配和任务规划大大减少了求解复杂度，且将变动开销限制在域内，减少了带宽浪费。

② 每个计算域选举一个卫星计算域控制器，保证域内所有计算节点与控制器的时刻联通，不同卫星快照下，计算域控制器选举可变动。

③ 卫星全球分布，且低轨卫星的运动速度较快，若只在地面上放置一个卫星边缘计算平台控制器，则计算域控制器需要经过一整个星座周期才能与平台控制器进行一次通信，且通信时长十分有限，使新的配置要求无法迅速下发。因此，在地面上放置多个边缘计算平台控制器，增加星座周期内域控制器与平台控制器通信的机会，同时利用星间链路，向不在平台控制器视线内的域控制器下发指令。

④ 所有卫星边缘计算平台控制器与全局控制器相连，接受集中化的管理控制。

3.2 基于资源感知的多级控制器协同机制

基于资源感知的多级控制器协同机制流程如图3所示。

图3 卫星边缘计算管控流程Fig.3 Workflows among the framework of management and control of satellite edge computing

各级控制器功能如下：

卫星计算域控制器收集域内卫星计算节点资源状态及域内拓扑信息；域内资源管理、任务规划、移动性管理、故障恢复；根据域内决策下发配置；抽象出域内计算、缓存、网络资源视图，提供给卫星边缘平台控制器；接收卫星边缘计算平台控制器的指令。

卫星边缘计算平台控制器汇总多个计算域的资源状态及域间拓扑信息；下发指令给卫星计算域控制器；抽象出各域资源视图及域间拓扑，提供给全局控制器；接收全局控制器的指令。

全局控制器汇总各计算域的资源状态及整个卫星边缘计算平台的拓扑信息；面向业务需求的全局资源管理、任务规划、移动性管理、故障恢复；边缘计算业务登记、用户准入、业务周期管理等；向卫星边缘计算控制器下发决策。

此外，由应用向全局控制器提出需求，并由卫星计算节点提供实际边缘计算资源，就此完成基于资源感知的卫星边缘计算管控流程闭环，集中与分布式相结合，实现灵活性、最优性、可扩展性。

4 天地一体化边缘计算网络协同计算机制

4.1 层间协同计算

天地一体化边缘计算网络中各层间协同机制如图2所示。根据不同的场景和用户需求，用户设备产生计算任务。当本地资源(即设备本身的计算能力)充足时，计算任务在设备本地执行。若本地资源无法满足计算任务，则由用户设备决策，将计算粪污卸载到边缘计算层。

边缘计算层中有多种边缘计算平台，图2中所示的卫星边缘计算平台只是其中一种。除卫星边缘计算平台外，还有地面边缘计算平台、车辆边缘计算集群、飞行器边缘计算集群等[4]。当边缘计算平台收到计算任务后，立即进行处理，若单计算域的计算资源不足，则协同相邻计算域共同处理任务，如图2中卫星边缘计算域的域间协同。

若边缘计算域及其相邻域仍不具有充足的资源，则由边缘计算平台控制器决策，将计算任务卸载到云计算层的数据中心，数据中心具有足够充分的资源来处理任务。在任务处理结束后，处理结果返回给用户设备。

4.2 卫星边缘计算平台的协同计算

卫星边缘计算平台内部有两种协同计算形式，一是域间协同计算，发生在单个卫星计算域资源不足以进行任务处理时，由卫星边缘计算平台控制器进行域间协同计算规划；二是域内协同计算，发生在单个卫星计算节点资源不足时，由卫星计算域控制器进行资源分配和任务规划。

每个卫星计算节点的计算、存储、通信资源都将被放在所属卫星计算域的动态资源池里。计算域可以灵活调配域内的各种资源，支持任务协同计算，在提高资源利用率的同时，增加任务成功率。

4.3 卫星协同计算的关键保障机制

卫星协同计算需要由底层机制进行支持和保障，卫星协同计算的3种关键保障机制：协同计算域生成、任务规划和故障应对。

4.3.1 协同计算域生成

协同计算域的生成，是指预先规划好对整个卫星边缘计算平台的计算域划分情况，为用户的计算任务卸载及卫星边缘计算平台的任务分配决策提供基础。

协同计算域的生成以整个卫星边缘计算平台的收益最大化为优化目标，与以下几个因素有关：

① 用户需求。由于卫星围绕地球旋转，每颗卫星服务的用户流量随空间、时间变化。空间上的变化是指地球上人口分布密集的区域，流量普遍较大，反之较小；时间上的变化是指单个用户产生的流量在一天内各时段波动。卫星服务的用户流量随时空变化，若用户流量超过卫星自身计算资源，则卫星需要将多余的计算任务分给同一计算域的其他卫星；若用户流量少于卫星资源，则卫星愿意协同分担同一计算域中其他卫星的计算任务。通过卫星间协同计算，卫星尽可能地将协同计算域覆盖的用户流量，在本计算域内处理完毕，避免因资源不足而卸载给地面数据中心，减少下行链路带宽消耗，以及租用数据中心计算资源的开销。

② 网络拓扑。卫星拓扑处于高度动态，星间链路频繁通断。采用快照思想，假设单个快照内，卫星网络拓扑保持静态，则必须保证在此快照下的协同计算域拓扑连通。拓扑连通，是实现卫星计算域控制器实时管控、卫星间协同计算、数据传输的基本条件。若某时刻拓扑不连通，则需要重新选举计算域控制器，带来控制器迁移开销；且在断掉链路上传输的数据需要重传到其他计算节点，带来重传开销。

③ 拓扑可靠性。拓扑可靠性与拓扑的连通度、边的冗余程度等有关。因平台抖动、天线对准等问题，卫星链路的质量不稳定，容易带来链路突然断掉或链路丢包率很高等突发故障。此时，若与故障链路相连的卫星节点周围没有其余节点可分担计算任务，则需要将这部分计算任务卸载到地面数据中心，带来业务迁移开销，造成卫星边缘计算平台收益的下降。

由于卫星节点数目众多，协同计算域生成的计算复杂度很高，可以基于以上模型，用启发式算法进行离线求解。求出的协同计算域方案可作为后续任务规划问题的输入。

4.3.2 任务规划

卫星边缘计算平台的任务规划及分配，需结合各计算域的资源利用情况、计算任务特性进行，有以下4种任务分配方式：

① 一个卫星对应一个任务。一对一是最简单的任务分配方式，若单个卫星有充足的资源支持任务处理，则可选择这种方式。

② 多个卫星对应一个任务。一个可以被并行化分解的计算任务，可以分配到多个卫星上同时处理，以加快处理速度。

③ 一个卫星对应多个任务。通常来说，覆盖相邻地理区域的卫星节点收到的计算任务相似，如针对同一区域的大气层进行观测，并对观测图像进行处理分析。一个卫星对多个同类计算任务的计算结果可复用，如一段时间内对云层的识别结果，这种方式可以节约计算资源。

④ 多个卫星对应多个任务。这种混合业务模式是多个卫星对应一个任务和一个微型对应多个任务的结合，是最普遍的卫星协同计算任务分配方式，是任务规划问题求解的主要形式。

对卫星协同计算任务规划问题的求解，可以以离线形式，对提前已知需求的多项任务做规划；也可以以在线形式，对新到来的任务做增量式规划。

4.3.3 故障应对

如前文所述，当链路故障发生时，需进行任务迁移。实际上，任务迁移在卫星拓扑改变、突发链路故障两种情况下均会发生。由于卫星拓扑改变是规律性变化，可提前预知，可以由卫星计算域控制器或计算节点自发地提前做好数据备份、在变动时刻前后切换路径。然而，突发链路故障不可预知，需要迅速应对，减少对任务处理时延的影响。

① 故障检测。故障检测以控制器周期性探测和节点主动上报的形式进行。控制器周期性发包，询问计算节点的链路状况，周期越小，探测到故障的速度越快，但相应地会带来探测开销大的弊端，需要在二者之间做权衡。另一种方式为节点检测到端口异常，主动发包给控制器上报故障。

② 路由计算。计算域控制器检测到域内故障，通过控制器维持的域内资源视图及拓扑视图，计算出业务迁移路径，即新的协同计算节点、节点间的数据传输路径。若域内控制器判断当前域的资源和拓扑条件无法支持业务迁移，则与相邻域控制器通信，计算得到跨域的任务迁移方案。

③ 故障恢复。域控制器下发指令给相关计算节点，若新旧协同计算节点之间存在链路，则可由旧节点将已得到的计算结果和未计算的数据传给新节点；若不存在，则由源计算节点将所有需要计算的数据传给新节点。

5 结论

近年来，天地一体化的边缘计算网络受到广泛关注。本文提出了卫星协同的天地一体化边缘计算网络架构，从卫星边缘计算硬件平台、卫星边缘计算管控架构、天地一体化边缘计算网络协同计算机制三方面对架构进行阐述，并在最后针对卫星协同边缘计算的挑战，提出了三种协同计算关键保障机制。本文拓展了以往天地一体化边缘计算的研究，为后续工作打下基础。