基于SDN架构的NFV技术在低轨卫星网络中的应用

侯筠仪，赵黎晔，申景诗，冯飞，王韶波

1. 山东航天电子技术研究所，烟台 264670

2. 航天东方红卫星有限公司，北京 100094

在5G生态系统的大背景下，地面用户数量和服务类型呈现爆发增长的趋势，星地网络的集成一体化被视为增强网络功能、完善网络部署的一种解决方案。目前，全球已有超过20个卫星通信系统在轨运行，以新一代的Oneweb系统、SpaceX系统等为代表的巨型星座网络[1]作为通信网络广域建设的一种补充，有效克服了地面网络基站的布设限制，旨在缓解全球剩余2/3人口的宽带上网问题。

在卫星网络领域，传统卫星通常将控制和数据转发功能集中于同一网络设备，卫星节点在进行数据传递前需先完成链路维持、状态监控、路由计算等多种网络控制功能，占用了大量星上载荷资源。面对未来网络不断增长的用户需求和异构化的应用程序，学术界提出了引入“软件定义网络”的概念进行卫星网络应用方案的研究。软件定义网络(software defined network, SDN)是网络虚拟化的一种实现方式，其核心是分离网络设备的数据平面与控制平面以实现网络流量的灵活控制。Ferrús等[2]在5G背景下在卫星地面段中引入SDN/NFV技术，实现星地间网络资源管理能力和业务敏捷性的提升。Tang 等[3]将路由计算和网络配置任务放在地面站，设计了一种基于OpenFlow的软件定义卫星网络架构。Xu等[4]设计了SoftSpace架构并讨论了SDN的故障发现机制和移动性管理能力。Kak等[5]研究了低小卫星在SDN网络体系下配置不同载波频率和轨道参数对时延和吞吐量的影响。Xu等[6]设计了一种3层分层控制器架构，并进一步提出了一种从控制器选择策略以促进成本降低和稳定性增强。传统SDN方案的共同点是利用全局统一的SDN控制平面实现路由计算，控制策略需要在全网进行刷新。然而卫星自身拓扑动态异构的特征会导致控制器的计算及同步负担很大。可见，低轨卫星空间段的软件定义网络架构设计依然有较大的研究潜力和应用价值。

针对上述问题，本文主要关注将SDN设计思想在卫星网络架构中进行扩展，简化卫星节点的工作负担、实现大量流量的高效传输，并融合网络功能虚拟化(NFV)技术以使该架构能够面对未来空间信息网络发展中可能遇到的挑战性问题。本文首先从低轨星座设计入手，从物理层面进行优化，使其通信水平的性价比最大化。基于该低轨卫星星座，进一步提出了软件定义卫星网络架构设计方案，设计了以星间链路为基础的虚拟化数据平面和多控制器的分布式控制平面，并给出了架构实现的关键技术方案，使其能够实现数据传递的高效动态分配。

1 低轨卫星星座设计

低轨星座设计是构建卫星通信系统的基础，星座构型的合理优化有助于低轨星座功能的最大化实现。卫星星座设计优化过程首先应根据目标场景选取基础星座构型。本文的设计背景为设计一种有效补充地面网络局限性、实现广域补充覆盖且能够搭建SDN架构的卫星星座。极轨道星座属于对称星座，轨道面分布均匀，每个轨道面上卫星数目相同，轨道面经过两极且与赤道面垂直，能够实现对全球的覆盖。极轨道星座中的卫星在运动过程中保持相对静止，可以通过固定的星间链路实现卫星间的切换与通信，且星间链路建设简单，易于维护，能够为SDN架构提供合理的物理基础。因而，本文采用极轨道作为星座基础构型。

铱星系统是一种典型的极轨道通信卫星星座。但考虑未来通信系统所面临的高速率传输下，文献[7]基于轨道高度与边缘通信仰角的约束关系指出，低通信仰角的铱星系统无法满足宽带LEO星座卫星通信系统要求，需要通过提高轨道高度来解决这一问题。然而，在地面用户边缘通信相同的情况下，卫星的轨道高度越高则会导致单星所需要的点波束数量越多。考虑到软件定义卫星星座未来发展定位于卫星通信、导航、遥感等多方面星上功能的实现，本文参考由法国国家空间研究院和美国宇航局合作的第一个全球定位和数据采集系统Argos系统的星座设计理念，将星座轨道高度提升至850 km，以贴合多功能的星上实现需求。卫星通信仰角的设计需保证星座实现对全球的覆盖，但单颗卫星不应覆盖面积过大而造成功率指标的浪费，故本星座单颗卫星的边缘通信仰角设计为30°。根据全球覆盖星座原理[8]，在已知轨道高度和边远通信仰角的前提下能够计算出最优的卫星总数、轨道面数及每个轨道上的卫星数量，最终构建卫星星座。

该星座共有9个轨道平面，每个轨道面上分布11颗低轨卫星，轨道高度850 km，轨道倾角为86.4°。通过STK软件对星座的对地覆盖性能进行仿真，结果证明该星座对地覆盖率在全时段达到100%，满足任务所需的通信要求。

极轨道卫星星座网络的联通依赖于星间链路的构建。参考铱星星间链路的设计模式，该星座中的每一颗卫星都与其同一轨道的相邻卫星建立2条星间链路，并与相邻轨道上实时临近的卫星建立2条星间链路。第1轨道和第9轨道之间的反向旋转关系是一种例外情况，这两条轨道间的卫星不存在相邻轨道的星间链路。拓扑结构如图1所示。

图1 数据平面拓扑结构示意

卫星通信网络地面段网络拓扑采用“多点落地”的设计思想。仅依靠单一地面站接收全网卫星的下传数据这一模式在面对海量数据时易发生网络拥塞，而将多地面站引入卫星网络的路由规划能够充分利用地面网路资源。地面设备具有可维护、鲁棒性高的特点，通过光纤传输数据更为高效，分担了卫星网络的传输压力，体现了卫星网络与地面网络的互补性，实现了星地传输负载均衡。

如图2所示，本文选取三亚、佳木斯、喀什3处地面站为示例,图中标注了3处地面站的地理位置及当前时刻向对应地面站下传数据的卫星(圆标注)。图2给出了一条路由示例：当前时刻喀什地面站上空西侧的卫星(三角标注)作为源点进行数据传输，数据流在喀什地面站上空完成数据下传，经地面光纤网络传递至目的地三亚地面站。这样的传输路径有效减少了数据流在星间的传递跳数，降低了传输延迟与传输损耗。此外，“多点落地”结构能够有效解决极轨道星座反向缝两侧卫星无法建立星间链路导致路径规划复杂的问题。图2中佳木斯地面站上空，存在两个间隔反向缝的数据下传卫星(矩形标注)。虽然两颗卫星间无法完成东西向数据传输，但是能够通过将数据下传至佳木斯地面站，最终借由地面网络完成服务，避免了星上传输路径过长的问题。

图2 “多点落地”结构示例

2 基于低轨星座的软件定义网络架构设计与实现

SDN的核心在于控制平面和数据平面的分离，其基本架构如图3所示。

图3 SDN基本架构

2.1 数据平面

在低轨卫星网络中，卫星作为SDN交换机的载体可被视为数据平面的节点。低轨星座中所有卫星以节点形式构成完整的数据平面，依靠星间链路实现数据流的交换传输。数据平面的主要功能是通过一系列的链路操作对到来的数据分组进行处理，这些操作通常包括数据分组的收集和完整性检查。卫星网络这一场景的特点是底层物理资源有限，发射入轨后很难对交换机进行硬件设备的二次更新或功能变更维护，因而缺乏应对多种服务需求的灵活性。本文提出引入NFV技术，在数据平面上搭建虚拟的“环境抽象层”，用以解决数据平面的灵活性问题，并进一步阐明虚拟化转发功能的实现方式。

环境抽象层将设备的物理功能分割为更轻量级的网络虚拟功能，通过映射机制将用户需求的虚拟资源与物理资源相对应，能够有效地节省底层的物理资源，实现卫星平台的长期可用性。如图4所示，Intel公司开发的一种数据平面开发套件(data plane development kit, DPDK)能够很好地实现网络功能的虚拟化。该套件提供了数据平面库和轮询模式的Linux用户空间网卡驱动，通过间接的API提供队列管理、缓存管理和流量分组功能，使得上层应用和控制平面可以直接调用这些环境抽象层的功能来完成相关计算和转发。通过虚拟化交换机(即环境抽象层)，端口在传递流表时不再需要硬件设计提前预留专用的缓存队列存储空间，其缓存空间由CPU管理的内存动态化临时分配。在数据转发过程中，仅通过表头的地址匹配字段送入CPU进行地址匹配，待完成匹配后才会在需要转发时将完整数据包输出网络端口。

图4 数据平面I/O结构

卫星网络数据平面的虚拟化计算类功能的实现方式与普通星载计算机运行应用程序的方式完全相同，而虚拟化的转发类功能则有比较大的变化。在SDN网络设备中，网络层功能虚拟化的本质是通过流表抽象数据平面，通过流表可以精确地匹配和识别业务类型，完成对流的操作。数据转发形成的流表由多个基础流表构成，基础流表包含了地址匹配字段、计数字段、操作字段3项功能，如图5所示。考虑到卫星网络是一种无线网络，其转发和资源分配均基于终端，传统的SDN可能造成1个卫星终端的不同流会使用相同的信道和窗口。本方案在传统SDN协议基础上扩展性地引入IEEE 802.11e协议，该协议通过对流量的窗口和帧间间隔区别对待,能够赋予流不同的优先级。

图5 SDN流表项

随着星载载荷处理能力的提高，在支持基础数据包的转发之外，数据平面还需支持流量优先级的分类功能，以便针对不同类型数据实现SLA(服务级别协议)。通过采用DPI(深度包检测)[9]，应用能够确定转发决策的优先级，进而满足QoS(服务质量)要求。数据平面的虚拟化处理缓解了CPU的压力，使得这些服务有了实现的可能。

2.2 控制平面

卫星网络的控制功能由SDN控制器实现，其任务是更新数据平面设备(即星上SDN交换机)的转发规则。目前，大量的研究成果集中于将控制器放置于地面站或静止轨道卫星上，且数量较少。然而，随着网络流量需求的提升和数据平面的扩大，控制器数量不足将难以满足星地无线网络高动态、大跨度的路径配置计算需求，进而使得配置转发规则所需的流建立时间增长，用于改善网络延迟的相关规则下发失效，因而需要增加控制器布设数量来减少流建立时间[10]。此外，控制器放置于地面站或静止轨道卫星上意味着控制平面与数据平面之前存在巨大的数据传输损耗，并需要建立更为庞大的拓扑分析库来处理网络拓扑的动态化问题[11]。基于上述背景问题，本文提出将多控制器直接部署于低轨卫星上构成分布式控制平面。这样的控制器部署方式，一方面保证了控制器数量能够满足功能实现的需求，另一方面控制平面与数据平面的拓扑一致化减少了控制平面的数据处理压力。

根据改进的NSGA-Ⅱ的多控制器初始化部署算法[12]可知，控制器与卫星节点数量比例为0.3～0.4时，网络端到端时延将至最低。因此本文的控制器静态放置方案将控制器数量选取为36，每条轨道可有4个控制器，分别位于该轨道的1号、4号、7号、10号卫星。如图6所示，被放置SDN控制器的卫星同时具备数据交换和网络控制的功能，控制器与控制器之间由东西向接口相互连通，形成一个物理上分散、逻辑上集中的控制平面。每个控制域内约有2～3颗卫星。这样的部署方式不仅减少了星地间的数据传输损耗，还降低了控制器与交换机之间的数据传播时延。此外，集群式控制器通过虚拟化设计能进一步实现多功能平台的分割，提升卫星平台对载荷的支撑能力，更好地把握全网资源视图，改善通信资源的交付质量。

图6 控制平面组网示例

多控制器的部署意味着同时还需解决控制器动态放置问题[13]。控制器动态放置问题即控制域界定问题，该问题可被公式化为ILP算法，其优化目标是使得配置转发规则所需的平均流建立时间最小化，并通过Gurobi优化器进行求解。与控制器放置问题相关的约束表述如下。

约束1：用于确保要放置在网络中的控制器总数为K。

式中：C为控制器集合(该集合中元素c为控制器集合中各控制器的编号)；K为控制器放置数量；yc为一个二进制变量，指示是否将控制器放置在c∈C上，yc为1表示控制器在控制器集合C中，yc为0表示控制器不在控制器集合C中。

约束2：用于确保只有c号控制器处于活动状态时，s号卫星才会被c号控制器控制。

xs,c≤yc,∀s∈S,∀c∈C

(2)

式中：S为卫星集合(该集合中元素s为卫星集合中各卫星的编号)；xs,c为一个二进制变量，指示是否将卫星节点s分配给c∈C上，xs,c为1表示将卫星节点s分配给c∈C，xs,c为0表示不将节点s分配给c∈C。

约束3：用于确保每个卫星s被有且只有一个控制器c控制。

约束4：如果两个卫星属于不同的控制器集群，则需要给他们分配给不同的控制器。约束4给出一种辅助的二进制变量zc,s,k用于量化这种情况，将卫星划分为不同的控制域。

zc,s,k=xs,c·xk,c,∀s∈S,∀k∈S,∀c∈C

(4)

约束5：为使该约束能被线性优化器运算解决，由约束5的3个公式进行替代。

本文所设计的由多控制器共同构成的控制平面经东西向接口相互连通形成，物理上分离但逻辑上集中。在此基础上，结合NFV技术进一步提出了对控制平面的软件层面功能切割。经虚拟化处理，控制平面基于卫星通信需求设计为3个平台和2个数据库：请求指令平台、负载均衡平台、控制器系统平台、全网视图库、路由算法库。其中，全网视图库包含了拓扑分析库、链路分析库、网络状态库。为适应卫星拓扑的动态性，引入拓扑快照的方法，每分钟检查一次网络状态变化并形成快照集，每小时计算一次由于卫星移动而产生的所有网络拓扑。

通过南向接口，控制平面必须处理3类流量控制信息：流量配置信息、流量重新配置信息和迁移信息。如图7所示，数据平面收到新业务请求后向控制平面发送流量配置信息，控制平面的请求指令平台接收该信息，并将任务分发至相关的全部控制器。流量配置信息仅提供源地址及目的地址信息，不包含业务的转发相关内容。当网络中某卫星节点或多卫星节点因数据传输任务过量而出现拥塞状态时，发生拥塞的卫星节点向控制平面发送流量重新配置信息，请求指令平台收到此类信息后将其转发至负载均衡平台，触发卫星路由重构。该过程中，控制平面将更新全网视图库，负载均衡算法库调用更新后的链路状态和数据平面上传的数据传输任务需求重新计算路由，新的路由规则由控制器下发至数据平面。此外，每一次流量传输过程完成后，起点交换机和目的交换机分别向所属控制器发送第一流量配置信息时间和传输结束时间，由起止时间的差值除以路由传输跳数计算出平均流建立时间。若平均流建立时间超过系统规定阈值，同样视为发生网络拥塞，由目的交换器向控制平面发出流量重新配置信息，降低该路由途径的分配权重。

图7 控制平面实现流程

考虑到控制器系统平台内包含数量较多的控制器，本文采用Zookeeper系统框架[14]实现该平台内部的管理。每台搭载控制器的卫星对应于不同的控制域(多颗交换机卫星)，同时在多颗控制器的卫星中选举出一个Leader(图中为控制器1，实际通过选举规则设定为地面站过顶卫星所搭载的控制器，以实现更好的星地交互)，负责与收集全网的信息并发送给全网视图库进行更新，确保流量传输资源不被复用。其余搭载控制器的卫星作为Member负责控制其所属控制域内卫星上的交换机进行数据传递，并通过迁移信息将各控制域内的网络状态信息发送给Leader。由于卫星拓扑的动态性，各控制器卫星所属控制域内所需控制的卫星节点动态变化，需采用一种基于度的均衡控制节点部署算法[15]实现对控制卫星控制域的自适应动态划分。该算法调用全网视图库，生成星座交换机节点链表并设置链表的遍历方向参数，最终获得每个控制器对应控制域的卫星交换机节点集合。卫星控制器系统平台上的控制器通过调用全网视图库和路由算法库进行路由规划，并负责向其控制域内的交换机下发路由表。

2.3 初步验证

该验证基于本文第2节设计的低轨星座，对所设计的多控制器架构与传统地面站控制架构，在反向缝区域发生路由重构情况的路由重构查询时延进行仿真验证对比。

本文随机选取某时刻卫星拓扑快照对卫星节点查询时延进行计算。假设反向缝位于北京地面站上空，因而地面站选取为北京地面站。在该时刻下，传统地面站控制架构所对应的地面站过顶卫星为第9轨道3号卫星(卫星编号91，卫星-地面站跳数记为0)。通过STK软件仿真可以获得该时刻下卫星网络中各节点位置及其间距，并假设每颗卫星节点数据转发处理时间为1 ms。而本文所设计的多控制器架构在该场景下，每颗卫星发送路由重构查询请求仅需1跳或0跳即可将请求发送至控制器。假设数据传输速度为光速，计算得到各节点重构路由所需的查询时延，并以卫星-过顶卫星间隔跳数作为分组依据计算均值进行对比。

如图8所示，传统意义上地面控制器的部署架构受反向缝影响大，间隔跳数越大的卫星所需的路由重构查询时延越大，而低轨部署多控制器的SDN架构则具有较低且稳定的路由重构查询时延。在传统地面站控制架构，该时刻全网卫星节点通过地面站控制器实现路由重构的查询时延均值为82.97 ms。而在本文设计的低轨道多控制器部署架构下，路由重构的单跳查询时延稳定在14.58 ms。该仿真结果说明该架构可以较好实现路由的动态调整，快速实现路由收敛重构。

图8 各节点不同架构下所需路由重构查询时延

本文进一步对控制器数量对网络端到端时延的影响做出仿真。网络端到端时延为星上交换机-控制器平均时延及控制器-控制器平均时延的总和。交换机-控制器平均时延为所有交换机与其控制器间最短星间链路数据传输时延的平均值。控制器-控制器平均时延为所有控制器与控制器之间最短控制链路传输时延的平均值。最短路径通过STK软件仿真可以得到。

如图9所示，可以看出随着控制器数量的增加，网络端到端时延不断降低，在控制器数量为4时达到最低值，继续部署控制器会导致时延呈现上升趋势。这主要是因为当控制器数量较少时，星上交换机与控制器之间所需的最短传输路径较长，导致路由重构请求发送时延较长。随着控制器数量的增加，星上交换机与控制器间所需最短路径减少，网络端到端时延不断下降直至达到最佳的控制器部署比例。随着控制器数量的继续增加，网络端到端时延出现上升趋势的原因是控制器部署数量冗余，此时交换机-控制器间已达到最短路径，过多的控制器反而增加了网络负担，网络端到端时延主要由控制器间控制链路的传输时延组成。

图9 控制器数量对网络端到端时延的影响

3 结束语

从体系结构的角度出发，可以预见SDN作为一种解决方案能够为未来卫星网络带来可编程的灵活性和控制部署的自适应功能。本文提出了一种基于低轨卫星网络的SDN架构设计。在低轨卫星网络合理优化设计的背景下，该架构充分结合NFV技术，实现了在控制平面与数据平面相分离的基础上对各平面功能的二次切分。数据平面基于NFV技术构建环境抽象层，将计算和转发功能虚拟化，实现了缓存的实时分配，有效提高数据传输效率。控制平面由多控制器共同构成集群，物理上分离但逻辑上集中，经虚拟化处理设计为3个平台和两个数据库用以高效生成流量配置规则并下发，同时进一步实现了控制器系统平台内的自适应动态重构。该SDN架构设计对未来软件定义卫星网络架构建设具有重要的参考意义。在后续研究中，作者团队将进一步研究虚拟化平面运行隔离的问题，进一步提升SDN架构的可靠性。