Dynamic Management of Software-Defined Service Chains for Satellite Communications

Abstract

Traditionally, software-based services that utilize satellites are configured, provisioned, activated, and calibrated with manual effort, as the complexity and variability of satellite links preclude automated and scalable service orchestration. Accordingly, a system and process for automated and scalable orchestration of services that utilize satellite links is disclosed. In response to a service request that includes a service definition of an end-to-end service, parameter(s) of the satellite link that satisfies the service definition may be calculated. Using these parameter(s), a configuration of a satellite network service chain that includes multiple virtual network functions may be selected from a service catalog. The selected configuration may then be used to instantiate the satellite network service chain in a cloud infrastructure. This process may be implemented in a software-defined network controller that dynamically manages the resources and configuration of the service chain.

Description

[Technical field]

[0001] FIELD OF THE DISCLOSURE

[0002] Embodiments described herein relate generally to satellite communications, and more specifically to dynamic management of software-defined service chains for satellite communications. [Background technology]

[0002] 2. Description of Related Art The telecommunications industry has moved to scalable service-oriented provisioning platforms, enabled by operational support systems (OSS), to fulfill customer end-to-end service requests. Service providers use OSS to drive the provisioning and activation of customer requested services across software subsystems, which use rule-based programming to configure the physical and virtual network elements that provide the communication circuits or paths to realize the services. This process is known as "service orchestration."

[0003] However, for services provided using satellite communications, such service orchestration has not been possible due to the variability, complexity, and often proprietary elements associated with satellite links. For example, satellite links are subject to a multitude of dynamic conditions that terrestrial links, including fixed links with known physical characteristics, are not subject to in the same way. Dynamic conditions that affect satellite links include radio frequency (RF) interference, atmospheric characteristics, antenna conditions, and path lengths, all of which can affect the throughput of the satellite link. Degradation of satellite links can result in violation of service level agreements (SLAs) between service providers and their customers. Furthermore, configuration and provisioning of satellite resources is even more complex than terrestrial networks, since new network elements cannot be easily and inexpensively added to or activated within a satellite to address changing conditions.

[0004] As a result, satellite-based services are typically configured, provisioned, activated, and calibrated using manual labor. Additionally, the closed system design and proprietary elements often used in services require providers to create custom middleware to interface with the proprietary elements. This hampers the ability to automate and extend the system-wide orchestration of services over satellite links, which is necessary to create and manage the service lifecycle. Summary of the Invention

[0005] Thus, a system and method for dynamically managing software-defined service chains for satellite communications in an automated and scalable manner is disclosed.

[0006] In an embodiment, a method includes receiving, by a software defined network (SDN) controller, a service request including a service definition of an end-to-end service; calculating one or more parameters of a satellite link that satisfies the service definition; selecting a configuration of a satellite network service chain from a service catalog based on the calculated one or more parameters, the satellite network service chain including a plurality of virtual network functions; and initiating instantiation of the satellite network service chain with the selected configuration.

[0007] The service request may be received from the service orchestration system via the at least one network, and the method may further include, prior to receiving the service request, receiving, by the SDN controller, a request for service interface points from the service orchestration system via the at least one network, and, in response to the request, obtaining a list of available service interface points and sending the list of available service interface points to the service orchestration system via the at least one network. Obtaining the list of available service interface points may include obtaining, via the at least one network, a list of gateways and terminals via an application programming interface of the network management system.

[0008] The service definition may define a Carrier Ethernet (CE) service.

[0009] The service definition may include one or more service parameters that identify the gateways and terminals and define a service level agreement. The one or more service parameters may include a committed information rate and an excess information rate. The one or more service parameters may further include a maximum information rate. The method may further include monitoring one or more key performance indicators of the satellite network service chain after instantiating the satellite network service chain, and if the one or more key performance indicators do not meet the service parameters, selecting a new configuration of the satellite network service chain from a service catalog based on the calculated one or more parameters, and updating the satellite network service chain to the new configuration. Updating the satellite network service chain may include instantiating a new satellite network service chain with the new configuration, migrating traffic from the satellite network service chain to the new satellite network service chain, and terminating the satellite network service chain in the configuration.

[0010] The one or more parameters may be a link budget.

[0011] The configuration may include one or more dimensions of computing resources to be allocated to multiple virtual network functions within the cloud computing environment.

[0012] Initiating instantiation of the satellite network service chain may include sending a service chain request including the configuration to a network management system over the at least one network. The method may further include receiving, by the network management system, the service chain request from the SDN controller over the at least one network, and sending an instantiation request to a network function virtualization (NFV) orchestrator over the at least one network in response to the service chain request. The method may further include receiving, by the NFV orchestrator, the instantiation request from the network management system over the at least one network, and instantiating the plurality of virtual network functions within the cloud computing environment in response to the instantiation request. The instantiation request may include a gateway configuration of the satellite service chain, and the method may further include sending, by the network management system, a terminal configuration of the terminal service chain to a terminal configuration service in response to the service chain request.

[0013] The virtual network functions may include one or both of an encapsulator and modulator that converts Ethernet packets into satellite frames and a demodulator and decapsulator that converts satellite frames into Ethernet packets.

[0014] The method further comprises: The method may include instantiating a satellite network service chain in a sandbox environment, where the plurality of virtual network functions includes one or more virtual network functions that simulate a satellite link, and obtaining performance parameters of the satellite network service chain in the sandbox environment.

[0015] The method may further include reconfiguring the satellite network service chain in the sandbox environment based on the obtained performance parameters.

[0016] The method may further include receiving, by the SDN controller, a service request including a service definition for the monitoring service, identifying a configuration of a monitoring service chain for the monitoring service, and initiating an instantiation of the monitoring service chain with the identified configuration, where the monitoring service chain performs analysis of digital signal streams within the satellite network service chain.

[0017] The virtual network functions may comprise a virtualized modem including at least one demodulator configured to demodulate a waveform in accordance with a Digital Video Broadcasting (DVB) standard, at least one modulator configured to modulate a waveform in accordance with the DVB standard, at least one encapsulator, and at least one decapsulator. The virtualized modem may provide Carrier Ethernet services.

[0018] Any of the above methods may be embodied, individually or in any combination, in executable software modules in a processor-based system or a distributed processor-based system and / or in executable instructions stored on a non-transitory computer-readable medium.

[0019] The details of the present invention, both as to its structure and operation, may be gleaned in part from study of the accompanying drawings, in which like reference numerals refer to like parts and in which: [Brief description of the drawings]

[0020] [Figure 1] 1 illustrates an exemplary infrastructure in which one or more of the processes described herein may be implemented, according to an embodiment. [Diagram 2]1 illustrates a process for dynamic management of software-defined service chains for satellite communications, according to an embodiment. [Figure 3A] 1 illustrates an exemplary service chain of an end-to-end service, according to an embodiment. [Figure 3B] 1 illustrates an exemplary service chain of an end-to-end service, according to an embodiment. [Figure 4] 1 illustrates an exemplary service chain within a sandbox environment, according to an embodiment. [Diagram 5] 1 illustrates a process for satellite planning using a sandbox environment, according to an embodiment. [Figure 6] 1 illustrates a process for automated management of satellite resources, according to an embodiment. [Figure 7] 1 illustrates an exemplary processing system in which one or more of the processes described herein may be performed, according to an embodiment. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0021] In the embodiments, a system and method are disclosed for dynamically managing software-defined service chains for satellite communications in an automated and scalable manner. After reading this description, it will become apparent to one of ordinary skill in the art how to implement the present invention in various alternative embodiments and alternative applications. However, while various embodiments of the present invention are described herein, it will be understood that these embodiments are presented by way of example and illustration only, and not limitation. Thus, this detailed description of various embodiments should not be construed as limiting the scope or breadth of the present invention, as set forth in the appended claims.

[0022] 1. Introduction Embodiments utilize the concept of service orchestration to facilitate the automated creation of services utilizing satellite communications in a virtual (e.g., cloud) environment. Embodiments may dynamically adapt to the peculiarities of the satellite RF environment by automatically adjusting services in response to changing characteristics of the satellite itself. These characteristics may include attributes of the beams or antennas, payload electronics (e.g., transponders, regenerative systems, on-board dividers, on-board combiners, steerable antennas, etc.), and / or any other attributes specific to the satellite communications domain. Such automation may take into account factors that affect the satellite RF link, such as, for example, high latency, fading due to rain or atmosphere, different orbital dynamics (e.g., satellite handoffs or inter-satellite communications links), and / or changing service traffic patterns (e.g., to optimize satellite payload resources).

[0023] In an embodiment, given the variability of configuration options to address these satellite-specific factors, and the utilization of an OSS layer in the satellite communications domain, a method may include defining an end-to-end service at the OSS layer, communicating an initial (day 0) configuration to the building blocks that make up the service, instantiating the building blocks into a service chain with the initial configuration within a cloud computing environment, setting the service chain to a production (day 1) configuration, and migrating the service to new (day 2) configurations over the lifecycle of the service to meet service level agreements and / or key performance indicators (KPIs) required in the service definition.

[0024] Although embodiments are described herein primarily in the context of OSS, it should be understood that embodiments may be implemented in other types of systems, for example, the disclosed embodiments may be implemented for mission data download and processing, telemetry, tracking, and command (TT&C), and / or data relay, etc.

[0025] 2. System Overview 1 illustrates an example infrastructure 100 in which one or more of the processes described herein may be implemented, according to an embodiment. The infrastructure 100 may include a service orchestration system 105, a payload controller 110, a satellite manager 115, a satellite 120, a software defined network (SDN) controller 125, an external resource manager 130, a network function virtualization (NFV) orchestrator 135, a network management system (NMS) 140, an external service designer 145, a satellite NFV infrastructure 150 supporting at least one service 170, and an edge NFV infrastructure 160 supporting at least one consumer 175. Although only one of each component of infrastructure 100 is shown, it should be understood that infrastructure 100 may comprise any number of any of the components including, for example, one or more of service orchestration system 105, payload controller 110, satellite manager 115, satellite 120, SDN controller 125, external resource manager 130, NFV orchestrator 135, network management system 140, external service designer 145, satellite NFV infrastructure 150, edge NFV infrastructure 160, services 170, and / or consumers 175. It should be understood that communication between the various components may be performed over one or more networks using standard and / or proprietary network communication protocols. Alternatively or additionally, some of the components may be hosted and / or executed in the same computing environment, in which case they may communicate with each other via inter-process communication.

[0026] The service orchestration system 105 performs the operational and functional processes necessary to manage end-to-end services within a domain, including designing, creating, deploying, and terminating those services. The service orchestration system 105 manages services at the top of the satellite communications (satcom) domain and may communicate with one or more service orchestration systems that manage services in other domains, such as other satellite communications domains, telecom domains, and / or other types of domains.

[0027] The service orchestration system 105 may communicate directly or indirectly with the payload controller 110. The payload controller 110 may map or translate instructions from the service orchestration system 105 into procedures for the satellite manager 115. For example, the instructions may include configuration instructions for configuring the satellite 120. The satellite manager 115, which may be a satellite command and control (C2) system, then encodes these procedures into an RF link with the satellite 120 according to the satellite's specific control criteria. As one of many possible embodiments, the satellite manager 115 may comprise the Automated Real-Time Execution Suite (ARES) of the EPOCH® Integrated Product Suite (IPS) from Kratos Defense & Security Solutions, Inc. of San Diego, Calif. The satellite 120 decodes the procedures from the RF link and executes the procedures, which may include configuring one or more components within the payload of the satellite 120 to support the services managed by the service orchestration system 105. Thus, the service orchestration system 105 can manage the payload of the satellite 120 like any other network element to coordinate and optimize its operation.

[0028] An example of a method implemented by the payload controller 110 and / or the satellite manager 115 to reconfigure a satellite payload based on a payload model is disclosed in International Patent Publication No. PCT / US2021 / 037239, filed June 14, 2021, which is incorporated by reference herein as if set forth in its entirety. For example, the payload controller 110 may be a software-defined payload controller with a REST configuration protocol (RESTCONF) interface. The service orchestration system 105 may provide the payload configuration of the satellite 120 to the payload controller 110 via the RESTCONF interface, for example as a payload model defined in Yet Another Next Generation (YANG) data modeling language. The payload controller 110 may convert the payload model into one or more C2 procedures and communicate these C2 procedures to the satellite manager 115. For example, the payload controller 110 may format the C2 procedure into Extensible Markup Language (XML) and send the XML to the ARES / EPOCH interface using the Transmission Control Protocol (TCP) or another communication protocol.

[0029] The service orchestration system 105 may communicate with one or more of the SDN controllers 125. Each SDN controller 125 fulfills service requests from the service orchestration system 105. For each service request, the SDN controller 125 analyzes the service request and selects a suitable service chain from a catalog of service chains that can be used to address the request. A service operator may build and configure the service chain catalog required to fulfill the service request via an external service designer 145 or directly within the network management system 140. Specifically, the SDN controller 125 may identify which catalog elements are required to fulfill the service chain and then instruct the NFV orchestrator 135 on which elements are required to build the service chain. The SDN controller 125 may also terminate or destroy service chains and update them to an N-day configuration, for example, based on information provided by one or more external resource managers 130 and / or the network management system 140. The SDN controller 125 may manage the service chains through communication with one or more of the NFV orchestrators 135 and / or one or more of the network management systems 140. The SDN controller 125 may be implemented with the OpenSpace™ platform offered by Kratos Defense & Security Solutions, Inc. of San Diego, Calif. In an embodiment, the service orchestration system 105 may poll the SDN controller 125 at any time for the status of any service chains, and the SDN controller 125 may provide the status of the service chains to the service orchestration system 105 in response.

[0030] Each external resource manager 130 may monitor parameters of the service chain. For example, the external resource managers 130 may be resource controllers that monitor parameters of RF links to and from the satellites 120, load parameters on gateways, and / or other dynamic parameters related to the service chain. The external resource managers 130 report these parameters to the service orchestration system 105 and / or the SDN controller 125 to inform decisions (e.g., trigger actions) in the service orchestration system 105 and / or the SDN controller 125.

[0031] Each NFV orchestrator 135 may manage a satellite NFV infrastructure 150 on the service side of the satellite 120. The NFV orchestrator may act as a Virtual Network Function (VNF) manager that communicates with a Virtual Infrastructure Manager (VIM) 152 to instantiate one or more Virtual Network Functions (VNFs) 154 representing the satellite service chain 156 in the satellite NFV infrastructure 150. The NFV orchestrator 135 may also configure each instantiated VNF 154. The NFV controller 135 may be implemented with the OpenSpace™ platform offered by Kratos Defense & Security Solutions, Inc. of San Diego, California.

[0032] Each network management system 140 maintains information about the network, including a service catalog, an inventory of service interface points (SIPs) in the network, and / or attributes of the network's components (e.g., capabilities or class of network elements). The service catalog may include multiple service profiles, each representing a particular service chain configuration. Each service profile may include carrier symbol rates, gateways capable of supporting the service chain, frequencies, beams, beam spectral efficiency, beam RF power, beam Gain / Noise Temperature (G / T) for beam definitions, supported terminal classes (e.g., antenna size, amplifier size, output power, antenna gain, etc.), and / or computing resource dimensions. It should be appreciated that each service profile need not include all of the information used for service chaining, and that some of this information may be obtained and / or otherwise derived from other systems (e.g., service orchestration system 105, external resource manager 130, etc.) as needed instead of being stored in the service catalog. The service catalog may be indexed by one or more characteristics of the service request and / or one or more parameters derivable from the service request so that a service profile based on a service request can be easily retrieved from the service catalog. The inventory of service interface points may include an inventory of physical or virtual service termination points of the gateway and physical or virtual service termination points on remote terminals that are available in the network and managed by the network management system 140.

[0033] The network management system 140 may communicate with the NFV orchestrator 135 to instantiate and configure the satellite service chain 156 and may collect statistics from each VNF 154 in the satellite service chain 156 for reporting. The network management system 140 may also collect statistics about the NFV infrastructure 150 from the virtual infrastructure manager 152. In either case, the statistics may include key performance indicators (KPIs) and / or fault, configuration, accounting, performance, and security (FCAPS) data. The network management system 140 may communicate with a terminal configuration service 162 in the edge NFV infrastructure 160 to instantiate and configure the VNF 164(s) that make up the terminal service chain 166.

[0034] Each satellite NFV infrastructure 150 may comprise a virtual infrastructure manager 152 configured to manage the VNFs 154. Specifically, the virtual infrastructure manager 152 may instantiate a satellite service chain 156 including any number of VNFs 154, such as VNF 154A, VNF 154B, ..., VNF 154N. It should be appreciated that each of the serially connected VNFs 154 (e.g., VNFs 154A-154N) in a given satellite service chain 156 may perform a different function within that satellite service chain 156, and different satellite service chains 156 may comprise collections of VNFs 154 that are the same as or different from each other, depending on the services that each satellite service chain 156 supports. The satellite service chains 156 link the services 170 to the satellite 120. The satellite NFV infrastructure 150 may reside in a computing cloud where available resources are shared on demand by multiple applications. This computing cloud may be co-located on the premises of a teleport facility and interconnected with NFV infrastructure residing in a data center providing private cloud computing, or with NFV infrastructure residing in a public cloud computing environment (e.g., Microsoft Azure™). As an example, the virtual infrastructure manager 152 and / or the VNFs 154 may be implemented in the OpenSpace™ platform offered by Kratos Defense & Security Solutions, Inc. of San Diego, California.

[0035] Each edge NFV infrastructure 160 may comprise a terminal configuration service 162 configured to instantiate a terminal service chain 166. The terminal service chain 166 may comprise one or more VNFs 164, such as VNFs 164A, ..., VNFs 164N. The terminal service chain 166 links the consumers 175 to the satellites 120. The edge NFV infrastructure 160 may reside in a private computing cloud residing on a class of universal edge computing platforms. For example, the edge NFV infrastructure 160 may be implemented on the OpenSpace Edge™ platform offered by Kratos Defense & Security Solutions, Inc. of San Diego, California.

[0036] An end-to-end service is formed between the service 170 and the service consumer 175 via the satellite service chain 156, the satellite 120, and the terminal service chain 166. In other words, in one-way and two-way satellite communication, data flows from the service 170, through the satellite service chain 156, through the satellite 120, through the terminal service chain 166, to the consumer 175. It should be understood that in broadcast or multicast satellite communication, there may be multiple consumers 175. Furthermore, in two-way satellite communication, data flows from the consumer 175, through the terminal service chain 166, through the satellite 120, through the satellite service chain 156, to the service 170. In general, the consumer 175 may be a device such as an Internet router, a Wi-Fi™ access device, a computer, a telephone, a television, and / or a radio, and / or a software application contained within such a device and / or within a cloud computing environment.

[0037] 3. Process Overview 2 illustrates a process 200 for dynamic management of a software-defined service chain for satellite communications, according to an embodiment. Process 200 may be embodied in one or more software modules representing one or more of the components of infrastructure 100, which are executed by one or more hardware or virtual processors of one or more hardware systems. In particular, process 200 may be embodied in software modules distributed throughout infrastructure 100, as illustrated by corresponding sub-process numbers in FIG. 1 for illustrative purposes.

[0038] Although process 200 is shown with a particular arrangement and order of sub-processes, process 200 may be performed with fewer, more, or different sub-processes, as well as with a different arrangement and / or order of the sub-processes. Additionally, even if the sub-processes are described or illustrated in a particular order, any sub-process that is not dependent on the completion of another sub-process may be performed before, after, or in parallel with other independent sub-processes.

[0039] In sub-process 205, the service orchestration system 105 requests a list of available service interface points from the SDN controller 125, or from multiple SDN controllers 125 representing different physical or logical domains. For example, the SDN controller 125 may implement an application programming interface (API). The API may conform to Representational State Transfer (REST). In an embodiment, the API of the SDN controller 125 may utilize the Presto™ API of the Lifecycle Service Orchestration (LSO) Reference Architecture defined by the Metro Ethernet Forum (MEF). Thus, the service orchestration system 105 may make a remote procedure call to a GET function of the API of the SDN controller 125 to obtain a list of available service interface points. Each service interface point represents a potential endpoint of an end-to-end service (e.g., on a gateway and / or edge).

[0040] In sub-process 210, the SDN controller 125 retrieves currently available service interface points and at least a portion of the service catalog. The SDN controller 125 may retrieve these service interface points and the service catalog from the network management system 140. For example, the network management system 140 may implement an API such as the industry standard OpenAPI™. Thus, the SDN controller 125 may make a remote procedure call to a GET function of the network management system 140 API to retrieve the current service interface points and the current service catalog. The network management system 140 may respond with a list of service interface points (e.g., gateway service interface points and terminal service interface points) that are defined as connectable service endpoints, and a list of service profiles from the service catalog that are production-ready. Each service profile in the service catalog may be defined as a template file, such as a network service descriptor (NSD) defined as part of the European Telecommunications Standards Institute (ETSI) Management and Orchestration (MANO) specification. Each service profile may define the day-zero and day-one configuration of the VNFs 154 of the satellite service chain 156 to enable the corresponding service. The network management system 140 may also respond with attributes indicating the class (e.g., capabilities) of each service interface point representing a terminal. These attributes may include, but are not limited to, type, size, and / or link budget. The SDN controller 125 may respond to the request sent by the service orchestration system 105 in sub-process 205 based on the response from the network management system 140. The response may include a list of available service interface points.

[0041] In the illustrated embodiment, the SDN controller 125 waits to receive a request from the service orchestration system 105 before retrieving the current service interface points and service catalog from the network management system 140. In an alternative embodiment, the SDN controller 125 may periodically (e.g., according to a time interval) retrieve the service interface points and service catalog from the network management system 140 and store them, so that the SDN controller 125 may respond to the service orchestration system 105 based on the most recently stored service interface points and service catalog without necessarily having to first communicate with the network management system 140. As another alternative, the SDN controller 125 may itself store or access a database of service interface points and / or service catalogs.

[0042] In sub-process 215, the service orchestration system 105 receives a response to its request from the SDN controller 125, including a list of available service interface points, and creates a service request based on the response. The service orchestration system 105 may store the list of available service interface points returned by the SDN controller 125 in a database of possible endpoints, which is used to define Carrier Ethernet (CE) services for the customer. The service orchestration system 105 may also collect information about any existing CE Ethernet Virtual Connection (EVC) state. It should be understood that although the services described herein are primarily described as CE services, the disclosed embodiments may be utilized for other types of services, such as other Layer 2 or Layer 3 TCP / IP services, where the service definition is expressed as a combination of service interface points, maximum bit rates and / or committed bit rates, Single Channel Per Carrier (SCPC) services, Frequency Division Multiple Access (FDMA) network services, Time Division Multiple Access (TDMA) network services, mission data download and processing, and / or TT&C services.

[0043] The service orchestration system 105 may create a provisioning order (e.g., at the OSS layer), which associates two or more service interface points, service parameters, and / or transport attributes with a service definition (e.g., a definition of a CE service) based on information in the response from the SDN controller 125. For a CE E-Line service, the service interface points may include or consist of a gateway and a terminal. For a CE E-Tree service or a CE E-LAN ​​service, the service interface points may include any number of service interface points. Examples of service parameters include, but are not limited to, bit rate values ​​(e.g., megabits per second (Mbps)), such as a maximum information rate (MIR), a committed information rate (CIR), and / or an excess information rate (EIR). These service parameters may represent a service level agreement. Examples of transport attributes include, but are not limited to, a user-network interface or a network-network interface, a class of service, allowed virtual local area networks (VLANs), and / or other criteria.

[0044] In sub-process 220, the service orchestration system 105 packages the service definition into a service request and submits the service request to the SDN controller 125 for activating the lifecycle of the requested service (e.g., a CE service). For example, the service orchestration system 105 may make a remote procedure call to a POST or PUT function of the API of the SDN controller 125 to send the service request.

[0045] In sub-process 225, the SDN controller 125 executes the service request received from the service orchestration system 105. Specifically, the SDN controller 125 calculates one or more parameters of the satellite link that satisfy the service definition, for example, based on the service interface points, service parameters, and / or transport attributes in the service definition. These parameter(s) may represent a link budget of the satellite link. The SDN controller 125 identifies which service profile(s) in the service catalog can satisfy the calculated parameter(s), correspond to the terminal's location, and correspond to the terminal's class (e.g., compatible with the terminal's performance or other parameters). Identifying the service profile(s) that can correspond to the terminal's location may include identifying which beam (e.g., X, Y, Z, etc.) of the satellite 120 can correspond to the terminal's location. Once the SDN controller 125 identifies the variables necessary to satisfy the service request, the SDN controller 125 may store the service request as an EVC definition. If none of the service profiles in the service catalog can fulfill the service request, the SDN controller 125 may respond to the service orchestration system 105 with an indication that none of the service profiles can fulfill the service request.

[0046] At sub-process 230, the SDN controller 125 submits a service chain request to the network management system 140 to instantiate a suitable satellite service chain 156. Specifically, the SDN controller 125 may select a service profile from a service catalog, generate a configuration based on the selected service profile, and package the configuration into a service chain request. The SDN controller 125 may then make a remote procedure call to a PUT function of the API of the network management system 140 to submit the service chain request.

[0047] The configuration may be generated by extracting parameters from the service profile and combining the extracted parameters with other information that may be collected by the SDN controller 125. The configuration may include parameters of the service chain, including the specific VNFs to use and the specific placement of the VNFs, dimensions of the VNF service chain (e.g., satellite service chain 156 and / or terminal service chain 166), allowed cloud zones or cloud regions, modes, teleport uplinks, and / or satellite allocations, etc. The dimensions may include, but are not limited to, the number of virtual CPUs (vCPUs) provided to the service chain, the amount of memory provided to the service chain, the disk storage provided to the service chain, and / or the network throughput provided to the service chain, etc. The dimensions may be selected as one of multiple predefined performance tiers based on the service parameters in the service definition. The allowed cloud zones or regions may also be selected based on restrictions in the service definition (e.g., designation of secure cloud, public cloud, or other enclave definitions).

[0048] In sub-process 235, the network management system 140 submits a request to instantiate the requested service chain to the NFV orchestrator 135. For example, the NFV orchestrator 135 may implement an interface according to the Os-Ma-Nfvo reference point of MANO. Thus, the network management system 140 may send a network service instantiation message for the desired satellite service chain 156 via this interface to the NFV orchestrator 135. In the network service instantiation message, the satellite service chain 156 may be represented as a network service descriptor. The NFV orchestrator 135 may include a VNF manager, and the network management system 140 may submit the one-day configuration of the satellite service chain 156 defined in the instantiation request to the VNF manager. In an alternative embodiment, the SDN controller 125 may generate and submit the service chain instantiation request directly to the NFV orchestrator 135 instead of using the network management system 140 as an intermediary.

[0049] In sub-process 240, the NFV orchestrator 135 instantiates the satellite service chain 156. For example, the VNF manager of the NFV orchestrator 135 may send a life cycle management (LCM) instantiation message to the appropriate virtual infrastructure manager 152 of the target satellite NFV infrastructure 150. The virtual infrastructure manager 152 executes the message to instantiate the appropriate set of one or more virtual network functions 154 (e.g., VNFs 154A-N) that make up the satellite service chain 156. Once the satellite service chain 156 is ready, the virtual infrastructure manager 152 may send a message to the NFV orchestrator 135 indicating that the satellite service chain 156 is ready and / or including a reference to the VNFs 154 in the satellite service chain 156. It should be appreciated that the NFV orchestrator 135 may instantiate the satellite service chain 156 according to the dimensions of the cloud zone or cloud region and / or mode (e.g., production or sandbox) specified in the configuration. It should be further understood that the NFV orchestrator 135 may have or instantiate the satellite service chain 156 in different configurations based on the service request, and that the only limitation on the number of instances of the satellite service chain 156 is the amount of resources available to the satellite service chain 156 in the satellite NFV infrastructure 150, as determined by the amount of resources available in the cloud computing environment (e.g., in a particular cloud zone or cloud region) and any other applicable constraints.

[0050] In sub-process 245, the NFV orchestrator 135 configures each VNF 152 in the satellite service chain 156. For example, when the NFV orchestrator 135 receives a message from the virtual infrastructure manager 152 indicating that the satellite service chain 156 is ready, the NFV orchestrator 135 may directly configure each VNF 154 (e.g., each of VNFs 154A-VNFs 154N) in the satellite service chain 156.

[0051] In sub-process 250, the network management system 140 generates an appropriate configuration for the terminal using the pairing of service interface points and submits the generated configuration to the terminal configuration service 162 of the edge NFV infrastructure 160. The network management system 140 may submit the configuration to the terminal configuration service 162 via one or more out-of-band channels. It should be understood that sub-process 250 may be performed before, in parallel with, or after any of sub-processes 235, 240, and 245. In an alternative embodiment, sub-process 350 may be performed by the SDN controller 125.

[0052] In sub-process 255, the network management system 140 monitors the lifecycle status of the entire service chain from the service 170 to the consumer 175. Specifically, the network management system 140 may collect statistics from each VNF 154 in the satellite service chain 156 and / or each VNF 164 in the terminal service chain 166. These statistics may include key performance indicators and FCAPS data for each VNF. The network management system 140 may provide these statistics to the service orchestration system 105, the SDN controller 125, and / or an external service management system at the OSS layer. For example, the network management system 140 may make a remote procedure call to a PUT function of an API of the service orchestration system 105, the SDN controller 125, and / or the external service management system to send the statistics.

[0053] Additionally or alternatively, in sub-process 255, one or more external resource managers 130 may monitor parameters indicative of the satellite link (e.g., changes in payload), the load of the satellite service chain 156 and / or the terminal service chain 166 (e.g., for load balancing), etc. Each external resource manager 130 may provide these parameters to the service orchestration system 105, the SDN controller 125, and / or an external service management system at the OSS layer. For example, the external resource manager 130 may make a remote procedure call to a PUT function of an API of the service orchestration system 105, the SDN controller 125, and / or the external service management system to send the parameters.

[0054] In sub-process 260, a decision maker determines whether the current service chain is satisfactory based on statistics provided by the network management system 140 and / or parameters provided by the external resource manager(s) 130. The decision maker may be the service orchestrator 105, the SDN controller 125, or an external service management system at the OSS layer, depending on the specific implementation. A service chain may be determined to be satisfactory if the statistics and / or parameters indicate that the service chain meets the service level agreements and / or one or more key performance indicators (e.g., defined by service parameters in a service definition) associated with the services performed by the service chain. Conversely, a service chain may be determined to be unsatisfactory if the statistics and / or parameters indicate that the service chain does not meet (or significantly exceeds) the service level agreements and / or key performance indicator(s) associated with the services performed by the service chain. A determination of whether a service chain meets an associated service level agreement or key performance indicator(s) may be defined by whether the service chain meets the MIR, CIR, and / or EIR bitrate value(s) in the service request.

[0055] If the current service chain is determined to be satisfactory (i.e., “Yes” at sub-process 260), the service chain continues to be monitored at sub-process 255. Alternatively, if the current service chain is determined to be unsatisfactory (i.e., “No” at sub-process 260), the service chain is updated at sub-process 265. For example, if the decision maker is the service orchestration system 105, the service orchestration system 105 may update the service chain configuration via one or more update messages to the SDN controller 125. On the other hand, if the SDN controller 125 is the decision maker, the SDN controller 125 may directly update the service chain configuration. In some cases, the decision maker may depend on the issue, some issues are managed by the service orchestration system 105, other issues are managed directly by the SDN controller 125, and / or other issues require input from an operator. In either case, the SDN controller 125 may send one or more messages representing the configuration change(s) for the satellite service chain 156 to the VNF manager of the NFV orchestrator 135. The VNF manager may then issue the changes to all affected VNFs 154 in the satellite service chain 156. Similarly, the SDN controller 125 may send one or more messages representing the configuration change(s) for the terminal service chain 166 to the network management system 140, which may then issue the changes to all affected VNFs 164 in the terminal service chain 166 via the terminal configuration service 162. Alternatively, the SDN controller 125 may send all configuration changes for both the satellite service chain 156 and the terminal service chain 166 to the network management system 140, which may update the service chains similar to how the network management system 140 instantiated the service chains in sub-processes 235 and 250.It should be understood that the decision maker may send configuration changes to multiple elements of the satellite services chain 156 and / or the terminal services chain 166, where the configuration changes were created by the decision maker or are subsequently designed to be under the control of the decision maker.

[0056] Thus, as changes occur in monitored statistics and / or parameters, the service chain may be updated to the N-day configuration in real time to ensure that the service chain always meets the service level agreements associated with the service. It should be understood that the term "real time" as used herein also refers to a near real time occurrence, which may be delayed by normal latencies in processing and / or network communications, etc. In some instances, updating a service chain may include instantiating a new service chain, migrating the service's traffic from the old service chain to the new service chain, and terminating the old service chain after the traffic has been migrated.

[0057] In an embodiment, if sub-process 265 is unable to update the service chain to be satisfactory (e.g., meets a service level agreement or key performance indicator(s)), SDN controller 125 may return an error to service orchestration system 105. In that case, SDN controller 125 may also provide an error message indicating the unsatisfactory condition to network management system 140 for historical reporting and / or alert triggering to one or more recipients (e.g., other systems and / or human operators). Alternatively, SDN controller 125 may autonomously update the service chain to a more acceptable configuration. The more acceptable configuration may be one that brings the service chain closer to being satisfactory (e.g., maximizes performance toward an associated service level agreement).

[0058] Sub-processes 255, 260, and 265 may be fully autonomous and thus require no human intervention. In other words, the service chain is automatically monitored and updated in real-time as necessary. Alternatively or additionally, sub-processes 255, 260, and 265 may be executed programmatically (e.g., by service orchestration system 105), for example based on planned changes to service definitions at the OSS layer. Updates to the service chain may then be scheduled. In either case, process 200 allows for fully automated deployment and scaling of service chain management in the satellite communications domain. Advantageously, the level of autonomy provided in infrastructure 100 may be tuned to the requirements of each particular service provider, at any point along the spectrum between no autonomy and full autonomy.

[0059] 4. Exemplary Service Chain Although the service chains are shown as communications links between services 170 and consumers 175, the service chains may represent any meaningful communications link between two points. However, in contemplated embodiments, each service chain includes a link through satellite 120. In other words, each service chain may be a satellite network service chain. As an alternative example, a service chain may provide communications with a satellite as an endpoint, such as for TT&C and / or mission data download.

[0060] 3A illustrates an exemplary service chain 300 between endpoints 310A and 310B, according to an embodiment. For example, endpoint 310A may correspond to service 170, and endpoint 310B may correspond to consumer 175. However, it should be understood that service chain 300 may include other arrangements of endpoints 310 and / or other components than those shown. Furthermore, multiple service chains 300 may be constructed and run in parallel, and separate service chains 300 may have different arrangements from each other. In other words, service orchestration system 105 and / or SDN controller 125 may manage multiple different and / or independent service chains 300 simultaneously.

[0061] In an embodiment, the service orchestration system 105 may poll the SDN controller 125 at any time for the status of any service chain 300. The service orchestration system 105 may work with the SDN controller 125 to create, provision, administratively disable, or terminate a service chain 300 based on a service lifecycle defined for each service chain 300 at the OSS layer. At any point in the service lifecycle, the SDN controller 125 may honor a request by the service orchestration system 105 to change the lifecycle or state of the service by updating the corresponding service chain associated with that service. If the request is to destroy a deployed service, the SDN controller 125 may request the NFV orchestrator 135 to terminate the service chain (e.g., the satellite service chain 156) and release the underlying computing elements that were deployed when the service was created.

[0062] The endpoint 310A may be communicatively connected to one or more switches 330A of the gateway via a network 320 (including, for example, the Internet or a private communication backbone). The two sets of one or more VNFs 154 may provide bidirectional communication, including a transmit path and a receive path, between the gateway switches 330A and 330B. It should be appreciated that in embodiments where the service chain 300 provides only unidirectional communication, the VNFs 154 may provide only a transmit path without providing a receive path.

[0063] Each of the switches 330A and 330B may be a physical or virtual Gigabit Ethernet (GigE) switch. The switches 330A and 330B are shown as separate switches, with the switch 330A at the boundary between the network 320 and the satellite VNF infrastructure 150, and the switch 330B at the boundary between the satellite VNF infrastructure 150 and the components that provide the link to the satellite 120. However, it should be understood that the switches 330A and 330B may be implemented in the same switch. In either case, the switch 330A may perform transport from the network 320 to a user network interface (UNI) of a directly connected VNF 154 in the satellite service chain 156, as defined by the applicable MEF E-Line or E-Access service standard. Alternatively, the switch 330A itself may represent a UNI, as defined by the applicable MEF E-Tree or E-LAN ​​service standard.

[0064] From the perspective of endpoint 310A, endpoint 310A is simply communicating with switch 330A. The fact that switch 330A provides communications via satellite 120 is of no importance to endpoint 310A and does not need to be known by endpoint 310A. Thus, satellite communications are available through network 320 in the same way as any other type of communications, allowing for seamless integration of satellite communications into network 320. In essence, satellite 120 can be treated like any other switch in network 320.

[0065] The collection of VNFs 154(s) on the forward path from switch 330A to switch 330B toward the link to satellite 120 (e.g., implementing a gateway) may comprise or comprise, in the order from switch 330A to switch 330B, a traffic handler, an encapsulator (e.g., implementing generic stream encapsulation (GSE)), a modulator (e.g., OpenSpace™ wideband software modulator provided by Kratos Defense & Security Solutions, Inc., San Diego, Calif.), and a combiner. This collection of VNFs 154(s) on the transmission path may convert Ethernet packets into digital signals. For example, the traffic handler may process traffic at the data link layer (e.g., layer 2 or L2 of the Open Systems Interconnection (OSI) model) and / or the network layer (e.g., layer 3 or L3 of the OSI model) and provide the processed Ethernet frames to the encapsulator. The encapsulator may convert the Ethernet frames to baseband frames and provide the baseband frames to the modulator. The encapsulator may form baseband frames in accordance with the DVB-S2x standard as set forth in European Telecommunications Standards Institute (ETSI) European Standard (EN) 302 307-1 v1.4.1 (2014-11). The encapsulator may comprise one or more VNFs 154 (or software sub-processes) performing one or more of the following functions: frame chopping, forward modulation selection (e.g., via Adaptive Coding and Modulation (ACM)), Ethernet bridging (e.g., Media Access Control (MAC) tables, smart bridging / learning / relaying, etc.), Address Resolution Protocol (ARP) (e.g., Ethernet MAC discovery), MEF service delimiter type rewrite (e.g., rewrite ingress / egress Ethernet frames based on MEF definitions), Over-the-Air (OTA) Transport Header Compression (e.g., Robust Header Compression (ROHC)) of Ethernet Virtual Connections, and / or OTA optimization (e.g., Space Communications Protocol Specification (SPCS) / TCP acceleration).The modulator may convert the baseband frames into signal data packets (e.g., according to standards of the Digital Intermediate Frequency Interoperability (DIFI) / Institute of Electrical and Electronics Engineers (IEEE) 1.0 Specification DIFI Consortium). In an embodiment, the encapsulator and modulator may be implemented as a single VNF 154 referred to as a virtualized modem (vModem). The combiner may combine the signal data packets into a digital signal and provide the digital signal to digitizer 340A via switch 330B, which converts the digital signal to an analog signal.

[0066] The collection of VNFs 154(s) on the reverse path, away from the link to the satellite 120, from switch 330B to switch 330A, may comprise or consist of, in order from switch 330B to switch 330A, a digital channelizer (e.g., an OpenSpace™ wideband channelizer from Kratos Defense & Security Solutions, Inc., San Diego, Calif.), a demodulator (e.g., an OpenSpace™ wideband software receiver from Kratos Defense & Security Solutions, Inc., San Diego, Calif.), and a decapsulator. This collection of VNFs 154(s) on the receive path may convert digital signals to Ethernet packets. For example, the channelizer may receive digital signals from digitizer 340A, which converted the analog signals to digital signals, via switch 330B, and split the digital signals into signal data packets. The demodulator may convert the signal data packets to baseband frames and provide the baseband frames to the decapsulator. The decapsulator may convert the baseband frames to Ethernet frames, which may be transmitted to endpoint 310A via switch 330A and network 320. It should be understood that the demodulator performs the inverse function(s) of the modulator, and the decapsulator performs the inverse function(s) of the encapsulator. In an embodiment, the decapsulator and demodulator may be implemented as a single VNF 154 in a vModem, e.g., along with the encapsulator and modulator. In other words, a vModem may consist of a single VNF 154 that implements all of the functionality of the encapsulator / decapsulator and modulator / demodulator.

[0067] In an embodiment in which the satellite service chain 156 implements a vModem, the vModem may comprise one or more modulators configured to modulate a waveform in accordance with a digital satellite broadcasting standard and / or one or more demodulators configured to demodulate a waveform in accordance with a digital satellite broadcasting standard. Such a vModem may provide CE services, in which case the vModem may comprise one or more encapsulators that convert Ethernet frames into baseband frames modulated into a waveform by the modulator(s) and one or more decapsulators that convert the baseband frames demodulated from the waveform by the demodulator(s) into Ethernet frames. The digital satellite broadcasting standard may be a digital satellite television broadcasting standard, such as the DVB-S2X standard managed by the Digital Video Broadcasting (DVB) project. Although a digital satellite broadcasting standard such as the DVB standard is used as an example, the vModem may be configured to modulate and demodulate waveforms in accordance with other standards for wideband digital communications, such as Orthogonal Frequency Division Multiplexing (OFDM).

[0068] In an embodiment, the satellite service chain 156 may be a composite service chain that utilizes two or more independently instantiated service chains. FIG. 3B illustrates an example of a composite service chain according to an embodiment. In the illustrated example, the composite satellite service chain 156 is composed of a first service chain 156A or a first service chain 156B associated with a particular service 170, and a second service chain 156C that may be shared by multiple services. For example, both the first service chain 156A and the first service chain 156B may utilize the second service chain 156. In that case, the switch 330C may route data between the service chain 156A and the service chain 156C, as well as between the service chain 156B and the service chain 156C. The first service chain 156A and the first service chain 156B may represent different services or different instances of the same service. Although only two are shown, it should be understood that any number of first service chains may be linked to the second service chain 156C in a similar manner. In an embodiment, the second service chain 156C may have a longer life cycle than either of the first service chains (e.g., 156A and 156B), such that the second service chain 156C persists while multiple first service chains are instantiated, linked to the second service chain 156C, and then terminated based on demand for one or more services 170. The first service chain 156A and the first service chain 156B may be instantiated in the same satellite NFV infrastructure 150 (i.e., 150A and 150B are the same) or in different satellite NFV infrastructures 150 (i.e., 150A and 150B are different). Similarly, the second service chain 156C may be instantiated in the same satellite NFV infrastructure 150 as one or more of the first service chains (i.e., 150C is the same as 150A and / or 150B) or in a different satellite NFV infrastructure 150 than either of the first service chains (i.e., 150C is different from 150A and 150B).

[0069] In a specific embodiment, the first service chain 156A and the first service chain 156B may each comprise a collection of VNFs 154 including an encapsulator and a modulator (e.g., an OpenSpace™ wideband transmitter from Kratos Defense & Security Solutions, Inc., San Diego, Calif.) on the forward path and a demodulator and a decapsulator on the reverse path, while the second service chain 156C may comprise a digital combiner (e.g., an OpenSpace™ wideband combiner from Kratos Defense & Security Solutions, Inc., San Diego, Calif.) on the forward path and a digital channelizer (e.g., an OpenSpace™ wideband channelizer from Kratos Defense & Security Solutions, Inc., San Diego, Calif.) on the reverse path. In this embodiment, the second service chain 156C may have only a single VNF 154 on each of the forward and reverse paths and may persist for the lifecycle of multiple first service chains.

[0070] The switch 330B communicates with the software-defined digitizer 340A. Specifically, the switch 330B transmits digital signals from the combiners in the satellite service chain 156 to the digitizer 340A, and in a bidirectional communication, relays digital signals from the digitizer 340A to the channelizers in the satellite service chain 156. The digitizer 340A converts digital signals output by the combiners in the satellite service chain 156 to analog transmit signals for communication to the satellite 120, and digitizes analog receive signals from the satellite 120 to digital signals for use by the channelizers in the satellite service chain 156. The digitizer 340A may be software-defined. As an example, the digitizer 340A may be a SpectralNet™ carrier-grade RF digitizer provided by Kratos Defense & Security Solutions, Inc. of San Diego, California.

[0071] Digitizer 340A is in communication with antenna 350A. Specifically, digitizer 340A provides transmit signals to antenna 350A, which transmits the transmit signals to satellite 120. Additionally, in a two-way communication, antenna 350A receives receive signals from satellite 120 and provides the receive signals to digitizer 340A.

[0072] Satellite 120 relays signals from antenna 350A to antenna 350B. In two-way communication, satellite 120 also relays signals from antenna 350B to antenna 350A. Antenna 350B may be functionally similar or identical to antenna 350A, and thus any description of antenna 350A applies equally to antenna 350B and will not be redundantly described herein. Similarly, digitizer 340B may be functionally similar or identical to digitizer 340A, and thus any description of digitizer 340A applies equally to digitizer 340B and will not be redundantly described herein.

[0073] The digitizer 340B may communicate directly with the terminal services chain 166 of the edge VNF infrastructure 160. The terminal services chain 166 may comprise a collection of VNFs 164(s) forming a receive path from the signal processor 340B to the endpoint 310B. In a bidirectional communication, the terminal services chain 166 may also comprise a collection of VNFs 164(s) forming a transmit path from the endpoint 310B to the digitizer 340B. The receive and transmit paths may be the same or similar to the receive and transmit paths described with respect to the satellite services chain 156. For example, the receive path may comprise a demodulator followed by a decapsulator to convert the signal frames into Ethernet packets, and the transmit path may comprise an encapsulator followed by a modulator to convert the Ethernet packets into the signal frames. The encapsulators, decapsulators, modulators, and demodulators may all be similar or identical to those described with respect to the satellite services chain 156, and thus the descriptions of these components with respect to the satellite services chain 156 apply equally to these components in the terminal services chain 166 and will not be redundantly described in this specification in this regard.

[0074] Terminal services chain 166 may communicate with endpoint 310B. For example, a decapsulator in terminal services chain 166 may send an Ethernet packet to endpoint 310B. Additionally, in a bidirectional communication, an encapsulator in terminal services chain 166 may receive an Ethernet packet from endpoint 310B. Thus, service chain 300 allows for unidirectional or bidirectional communication between endpoints 310A and 310B over the satellite link.

[0075] It should be understood that service chain 300 is a non-limiting single example of a service chain. In an alternative embodiment, the terminal side of satellite 120 may be the same as the gateway side of satellite 120 shown in Figures 3A and 3B, such that digitizer 340B communicates with switch 330B, which relays data between digitizer 340B and terminal service chain 166, which communicates with endpoint 310B over network 320 via switch 330A. In another alternative embodiment, the gateway side of satellite 120 may be the same as the terminal side of satellite 120 shown in Figures 3A and 3B, such that satellite service chain 156 communicates directly with digitizer 340A and endpoint 310A instead of via switch 330 and / or network 320. The service chain may be configured in any number of other different ways.

[0076] The service chain 300 may include one or more of the software-defined components (e.g., VNFs and / or digitizers) described in International Patent Application No. PCT / US2021 / 033867, filed May 24, 2021, International Patent Application No. PCT / US2021 / 033875, filed May 24, 2021, International Patent Application No. PCT / US2021 / 033905, filed May 24, 2021, and International Patent Application No. PCT / US2021 / 062689, filed December 9, 2021, all of which international patent applications are incorporated by reference herein as if fully set forth.

[0077] Advantageously, utilizing VNFs and software-defined components (e.g., digitizer 340A and digitizer 340B) to perform various functions of service chain 300 promotes automation and scalability. In particular, service chain 300 minimizes the presence of physical hardware components, such that components of service chain 300 can be dynamically reconfigured (e.g., added, updated, dropped, increased or decreased dimensions, etc.) in real time using primarily in-band network communications to adapt to the unique, multivariate satellite communications environment (e.g., RF interference, atmospheric characteristics, antenna conditions, path lengths, etc.).

[0078] In particular, dynamic reconfiguration of VNFs in a cloud computing environment can be used not only to scale up the dimensions of computing resources (e.g., number of vCPUs, amount of memory and / or disk storage, network throughput, etc.) used for the service chain 300 on demand to ensure the satisfaction of the service chain 300, but also to scale down the dimensions of computing resources on demand to optimize hardware utilization. For example, favorable changes in the satellite communications environment can improve the performance of the service chain 300, such that the service chain 300 provides significantly better performance than required by a service level agreement. In that case, the SDN controller 125 can determine (e.g., at subprocess 260) that the service chain 300 is not satisfactory and can update (e.g., at subprocess 265) the service chain 300 to reduce the resources used by the service chain 300 (e.g., by reducing RF bandwidth usage, resizing one or more VNFs, replacing with a service chain 300 with reduced dimensions, etc.). This is in contrast to traditional hardware-based service chains, where unused resources simply sit idle or are ignored, representing a sunk cost that cannot be recovered.

[0079] 5. Sandbox In an embodiment, an entire service chain (e.g., service chain 300) may be created in a virtual sandbox environment for testing or evaluation. For example, an operator of a service may want to specifically tune a service before deployment. In that case, the operator may interact with service orchestration system 105 through a graphical user interface provided by network management system 140 or another system that interfaces with the web services of network management system 140 to build the service chain in the sandbox environment. As used herein, the term "sandbox" refers to a test environment that isolates the service chain from a production environment so that the service chain can be safely evaluated without affecting any components of the production environment.

[0080] Building a service chain in a sandbox environment may be similar to building a service chain in a production environment. Specifically, as in sub-process 220, the service orchestration system 105 may send a service request to the SDN controller 125. The service request may include a mode indicating that the service should be built in a sandbox environment. In response to the service request including the sandbox indication, the SDN controller 125 may define a zero-day configuration of the service chain based on the service requirements. The zero-day configuration may include parameters of the satellite and the RF link such that VNFs representing the satellite and the RF link can be defined. The SDN controller 125 may submit an instantiation request to the NFV orchestrator 135 to instantiate the entire service chain in the zero-day configuration in the sandbox environment. In response to the instantiation request, the NFV orchestrator 135 may instantiate the service chain according to the zero-day configuration in the sandbox environment. For example, the entire sandbox environment including the service chains 156 and 166 may be instantiated in a computing cloud. This service chain may be constructed using multiple VNFs, including, for example, VNF 154 of satellite service chain 156 and VNF 164 of terminal service chain 166. Hardware components, including those representing the functionality of satellite 120, may be represented by appropriate VNFs that simulate the functionality of the hardware components (e.g., according to parameters of the satellite and RF links in a day zero configuration).

[0081] FIG. 4 illustrates an exemplary service chain in a sandbox environment 400, according to an embodiment. The service chain 400 may be accessible on the gateway side through switch 330A and on the terminal side through switch 330B. Each of the switches 330A and 330B may be a Gigabit Ethernet (GigE) switch. Although the switches 330A and 330B are shown as separate switches, it should be understood that the switches 330A and 330B may be implemented in the same physical or virtual switch. An operator may test or evaluate the service chain 400 by running a simulation that passes data through the service chain 400 between the switches 330A and 330B according to the link budget and / or traffic characteristics of a scenario for which the service chain 400 is to be evaluated. For example, the scenario may represent normal operation of the service chain 400 in a production environment, with the specified link budget and traffic characteristics representing normal levels and variations in traffic over time. To assess the expected performance of the service chain 400 in a given scenario, performance parameters of the simulated service chain 400 may be obtained and analyzed.

[0082] The satellite service chain 156 and the terminal service chain 166 may be constructed in the same manner as described elsewhere herein. In other words, the same collection of VNFs 154(s) and collection of VNFs 164(s) may be used to construct these portions of the service chain 400. The main difference between the sandbox service chain 400 and the production service chain is that physical components such as the antenna 350 and the satellite 120 may be replaced with VNFs that model these physical components. However, this is not a requirement in any embodiment, as the collection of VNFs 154(s) and / or 164(s) may be tested in a sandbox environment with or without modeling of the physical components.

[0083] The gateway VNF 410A and the terminal VNF 410B may model RF attributes of the gateway and the terminal, respectively. For example, assuming that the terminal in the production environment is intended to be a very small area antenna (VSAT) ground station, the terminal VNF 410B may simulate a VSAT ground station. The RF attributes may include, but are not limited to, antenna attributes such as gain and G / T profile, pointing error, feed list, polarization, and / or frequency antenna schedule (pointing), amplifier attributes such as power response (input back-off / output back-off (IBO / OBO)), amplitude modulation (AM) / AM characteristics, and / or AM / phase modulation (PM) characteristics, frequency converter attributes such as attenuation and / or nonlinearity, and / or channelizer attributes such as gain. Additionally, the gateway VNF 410A and the terminal VNF 410B may model the location of each ground station, including any regulatory constraints corresponding to the location of each ground station.

[0084] Channel VNFs 420A and 420B may model an RF link with satellite 120. Modeled attributes of the RF link may include, but are not limited to, free space path loss, atmospheric loss, rain attenuation, and / or availability.

[0085] The satellite payload VNF 450 may model the satellite 120, including the name and location of the satellite 120, as well as attributes of its payload. The modeled attributes of the payload may include, but are not limited to, beam attributes such as orientation (e.g., up or down), type (e.g., Effective Isotropically Radiated Power or Equivalent Isotropically Radiated Power (EIRP), G / T, Saturation Flux Density (SFD), etc.), polarization, frequency band, and / or coverage chart, transponder attributes such as start and stop frequency (bandwidth), frequency offset, power response (IBO / OBO), AM / AM characteristics, and / or AM / PM characteristics, transponder schedules such as mode (e.g., automatic level control (ALC), fixed gain mode (FGM), standby, off, etc.), attenuation, level, and / or total power, and / or beam transponder schedules such as connectivity and / or beam position, etc. In particular, the satellite payload VNF 430 and / or the channel VNFs 420A and 420B may be configured to model various characteristics of the satellite link, including, but not limited to, co-polar interference, adjacent beam interference, cross-polar interference, power equivalent bandwidth (PEB), and / or channel effects (e.g., multi-channel effects and / or multi-signal effects).

[0086] In an embodiment, the SDN controller 125 may provide a configuration interface (e.g., an API of the SDN controller 125) that allows an operator to adjust parameters of the day-0 configuration, so that the service chain 400 can be adjusted based on the performance of the service chain 400 during simulation. Thus, an operator may fine-tune the service chain in the sandbox environment before deploying it in a production environment. Additionally, as with any other service chain 300, the service orchestration system 105 may poll the SDN controller 125 at any time for the status of the service chain 400. During simulation in the sandbox environment, an operator may manually and / or the service orchestration system 105 may automatically measure and optimize various settings of the service chain 400, including, but not limited to, gateway settings, terminal settings, channel settings, satellite settings, network throughput, and / or link throughput.

[0087] Once an operator is satisfied with the performance of service chain 400, the operator may store the configuration of the service chain based on service chain 400 as a service profile in the service catalog. The service profile may include a one-day configuration of the service chain. The service chain may then be deployed at any time from the service catalog by service orchestration system 105 via SDN controller 125. Alternatively or additionally, in an embodiment, an operator may deploy the service chain directly from the sandbox environment to the production environment (e.g., via a configuration interface of SDN controller 125).

[0088] Advantageously, deploying the service chain 400 from a sandbox environment to a production environment can be identical to deploying the service chain 300 directly to a production environment. Thus, the use of a sandbox environment not only allows for testing and tuning of the service chain, but also allows for testing and tuning of the deployment of the service chain. In particular, issues that arise during the deployment of the service chain from a sandbox environment to a production environment can be resolved such that they do not occur when the service chain is deployed directly to a production environment. This is notably not possible in conventional environments that utilize dedicated hardware.

[0089] 5 illustrates a process 500 for satellite planning using a sandbox environment, according to an embodiment. Process 500 may be embodied in one or more software modules representing external service designer 145 and / or service orchestration system 105. Essentially, process 500 receives and calculates parameters to configure a service chain, runs a simulation in the sandbox environment to finalize the configuration of the service chain, and saves and / or schedules the service chain.

[0090] Although process 500 is shown with a particular arrangement and order of sub-processes, process 500 may be performed with fewer, more, or different sub-processes, as well as with a different arrangement and / or order of the sub-processes. Additionally, even if the sub-processes are described or illustrated in a particular order, any sub-process that is not dependent on the completion of another sub-process may be performed before, after, or in parallel with other independent sub-processes.

[0091] At sub-process 505, process 500 receives a service definition that defines the service. The service definition may be received from an operator (e.g., by manually entering the service definition into a graphical user interface), from another system (e.g., via an API), and / or from an internal process (e.g., in response to an event). The service definition may include required bit rate values ​​for MIR, CIR, and / or EIR that represent service level agreements, class of terminal, location of terminal, and / or operation schedule of the service, etc.

[0092] At sub-process 510, process 500 checks for and applies regulatory constraints. These regulatory constraints may be based on the location of the terminal in the service definition. For example, a regulatory model may be retrieved from a database of regulatory models based on the location of the terminal, and a set of one or more constraints may be derived from the retrieved regulatory model.

[0093] At sub-process 515, process 500 calculates variables to apply to the service. These calculations may be constrained by regulatory constraints applied at sub-process 510. The calculated variables may include variables representing ground stations (e.g., at gateway VNF 410A and terminal VNF 410B), RF links (e.g., at channel VNFs 420A and 420B), satellite payloads (e.g., at satellite payload VNF 430), margin requirements, and / or link budgets, etc.

[0094] At sub-process 520, process 500 determines whether satellite 120 and / or satellite bandwidth needs to be allocated to a service. If an existing service is being updated, there may be an existing bandwidth (e.g., frequency) allocation. If neither more nor less bandwidth is needed, it may be determined that no bandwidth needs to be allocated to the service. Alternatively, if there is no existing service or if an existing service needs more or less bandwidth, it may be determined that bandwidth needs to be allocated to the service. If allocation is needed (i.e., “No” at sub-process 520), process 500 proceeds to sub-process 525. Alternatively, if allocation is not needed (i.e., “Yes” at sub-process 520), process 500 proceeds to sub-process 545.

[0095] In sub-process 525, process 500 identifies satellite 120 and / or satellite bandwidth allocation for the service. Sub-process 525 may include determining whether there are enough satellite frequencies available on satellite 120 for the bandwidth required by the service, and if not, determining whether satellite 120 can be reconfigured to create the bandwidth required by the service. A carrier allocation database may be consulted to identify optimal allocations of bandwidth and power, if any, for satellite 120. Optimization may be performed on bandwidth and / or power according to general or customer-specific constraints.

[0096] In sub-process 530, process 500 determines whether an allocation was identified in sub-process 525. If an allocation is available (i.e., "Yes" in sub-process 530), the satellite, bandwidth, and power identified in sub-process 525 are allocated to the service in sub-process 535. Alternatively, if an allocation is not available (i.e., "No" in sub-process 530), process 500 may deny the request in sub-process 540.

[0097] Sub-process 540 may include notifying the requestor that received the service definition in sub-process 505. If the requestor is an operator, the notification may be provided via a graphical user interface and / or other communication means. If the requestor is another system or an internal process, the notification may include providing a response message to the other system or internal process.

[0098] At sub-process 545, process 500 sends a service request to SDN controller 125 to instantiate and run the service in the sandbox environment. The service request may have configuration including end-to-end link data required to model the service and an indication that the service should be simulated in the sandbox environment. The service request may be generated based on an applicable template in the database of service templates.

[0099] At sub-process 550, process 500 receives performance data obtained during a simulation of the service in the sandbox environment. Specifically, as described elsewhere herein, SDN controller 125 may instantiate and execute a service chain representing the simulation of the service in the sandbox environment. SDN controller 125 may then collect performance data based on the simulation and return the performance data to process 500.

[0100] At sub-process 555, process 500 determines whether the performance data indicates that the service chain is satisfactory. For example, the service chain may be determined to be satisfactory if the performance data meets the service level agreements expressed in the service definition. If the service chain is not satisfactory (i.e., "No" at sub-process 555), process 500 proceeds to sub-process 560. Alternatively, if the service chain is satisfactory (i.e., "Yes" at sub-process 555), process 500 proceeds to sub-process 570.

[0101] At sub-process 560, process 500 determines whether to perform re-planning of the service chain. Re-planning may be performed repeatedly until a satisfactory configuration is identified at sub-process 555 or a stopping condition is met. In an embodiment, the stopping condition may be a threshold number of iterations. For example, if the number of iterations has not yet reached or exceeded the threshold, sub-process 560 may decide to proceed with one more iteration of re-planning. On the other hand, if the number of iterations has reached or exceeded the threshold, sub-process 560 may decide not to proceed with one more iteration of re-planning. If it is determined to proceed with one more iteration of re-planning (i.e., “Yes” at sub-process 560), process 500 may proceed to sub-process 565. Alternatively, if it is determined not to proceed with one more iteration of re-planning (i.e., “No” at sub-process 560), process 500 may reject the request at sub-process 540.

[0102] In sub-process 565, re-planning is performed. Re-planning may include reconfiguring the ground station and / or the satellite payload by adjusting one or more parameters. Examples of adjustable parameters include, but are not limited to, rainfall and SLA margins, gateway options, cost-performance tradeoffs at the terminal, satellite configurations, power-bandwidth tradeoffs, ACM, and / or uplink power control. Sub-process 565 may utilize a database of pre-defined payload configurations (e.g., defined in YANG) during re-planning. In at least some iterations, re-planning may also include execution of sub-process 525 to identify new allocations of satellites, bandwidth, and / or power. Sub-process 565 may have a manual mode (e.g., an operator adjusts the parameter(s)) and an automatic mode (e.g., the parameter(s) are adjusted automatically). Once a new configuration is generated, process 500 may return to sub-process 545 to reconfigure the service chain via SDN controller 125, as well as collect performance data for the reconfigured service chain in sub-process 550.

[0103] At sub-process 570, process 500 may store the service chains determined to be satisfactory at sub-process 555 as service profiles in a service catalog, described elsewhere herein. Further, deployment of the service chains may be scheduled according to the operational schedule of the service definition.

[0104] At sub-process 575, process 500 may request approval of the payload configuration in the service chain determined to be satisfactory at sub-process 555. The approval request may be made to an operator (e.g., via a graphical user interface), to another system (e.g., via the system's API), and / or to another internal process. If approval is received (i.e., "Yes" at sub-process 575), process 500 may proceed to sub-process 580 and then at sub-process 585, approve the request initiated at sub-process 505. Alternatively, if approval is not received or disapproval is received ("No" at sub-process 575), process 500 may reject the request at sub-process 540.

[0105] In sub-process 580, process 500 may save the payload configuration in the service chain. Further, reconfiguration of the payload of the satellite 120 may be scheduled according to the operational schedule of the service definition. According to the operational schedule, the payload of the satellite 120 is reconfigured (e.g., via communication between the service orchestration system 105 and the payload controller 110), and the service chain saved in sub-process 570 is instantiated and executed in the production environment, rather than the sandbox environment.

[0106] 6. Payload Orchestration 6 illustrates a process 600 for automated management of satellite resources, according to an embodiment. Process 600 may be embodied in one or more software modules representing the service orchestration system 105. Essentially, process 600 determines whether a service is achievable, available, and supportable, and reconfigures the payload of satellite 120 as necessary.

[0107] Although process 600 is shown with a particular arrangement and order of sub-processes, process 600 may be performed with fewer, more, or different sub-processes, as well as with a different arrangement and / or order of the sub-processes. Additionally, even if the sub-processes are described or illustrated in a particular order, any sub-process that is not dependent on the completion of another sub-process may be performed before, after, or in parallel with other independent sub-processes.

[0108] In the illustrated embodiment, process 600 reuses many of the sub-processes described with respect to process 500. Thus, a sub-process of process 500 will not be redundantly described when it is repeated in process 600. Rather, it should be understood that any description of that sub-process with respect to process 500 may be equally applied to that sub-process of process 600.

[0109] At sub-process 505, a service definition is received. Initially, at sub-process 610, process 600 determines whether a satisfactory service profile is in the service catalog. Sub-process 610 may be performed in consultation with SDN controller 125. For example, service orchestration system 105 may communicate with SDN controller 125 as described elsewhere herein to determine whether a suitable service chain is already available in the service catalog. If a satisfactory service profile is present in the service catalog (i.e., “Yes” at sub-process 610), process 600 may proceed to sub-process 520. Alternatively, if a satisfactory service profile is not present in the service catalog (i.e., “No” at sub-process 610), process 600 may perform the entire process 500 to potentially define a new service profile, which is added to the service catalog and scheduled for deployment as a service chain.

[0110] At sub-process 520, process 600 determines whether allocation is required. If allocation is required (i.e., "No" at sub-process 520), process 600 proceeds to sub-process 525. Alternatively, if allocation is not required (i.e., "Yes" at sub-process 520), process 600 proceeds to sub-process 620.

[0111] In sub-process 525, process 600 identifies an allocation, and then in sub-process 530, process 600 determines whether an allocation was identified in sub-process 525. If an allocation is available (i.e., "Yes" in sub-process 530), the allocation is made in sub-process 535. Alternatively, if an allocation is not available (i.e., "No" in sub-process 530), process 600 may deny the request in sub-process 540.

[0112] In sub-process 620, process 600 determines whether the allocation in sub-process 535 requires a satellite reconfiguration. If a satellite reconfiguration is required (i.e., “Yes” in sub-process 620), a new configuration of the payload for satellite 120 is defined in sub-process 630. Alternatively, if a satellite reconfiguration is not required (i.e., “No” in sub-process 620), process 600 in sub-process 545 sends a service request to SDN controller 125 to instantiate and run the service in a production environment.

[0113] At sub-process 575, process 600 may request approval of the payload configuration defined at sub-process 630. If approval is received (i.e., “Yes” at sub-process 575), process 600 may proceed to sub-process 580 to save the payload reconfiguration and schedule the payload reconfiguration, and then at sub-process 585, approve the request initiated at sub-process 505. Additionally (e.g., in parallel), process 600 may send a service request to SDN controller 125 to instantiate and run the service in the production environment at sub-process 545. Alternatively, if approval is not received or disapproval is received (“No” at sub-process 575), process 600 may reject the request at sub-process 540.

[0114] 7. Monitoring via Service Chains In an embodiment, a service chain for monitoring other service chains may be instantiated and managed like any other service chain. This monitoring service chain may sample the inputs and / or outputs of the channelizers in one or more other service chains and perform RF analysis on the sampled signals. For example, the monitoring service chain may perform RF analysis on a digital signal stream to detect or identify problems in the service chain. This is in contrast to traditional RF analysis on hardware-based channelizers, which requires physical access to the hardware and cannot be performed automatically or at scale. Advantageously, because the monitoring service chain is monitoring a digital signal stream, it may record all RF data in short-term or long-term buffers to help troubleshoot transient events (e.g., by analyzing past RF data leading up to the transient event).

[0115] In an embodiment, if a service chain is determined to be unsatisfactorily performing (e.g., “No” at subprocess 260), one or more instances of the monitored service chain may be automatically instantiated by service orchestrator 105 or SDN controller 125 (e.g., via network management system 140 and / or NFV orchestrator 135). Once instantiated, the monitored service chain may sample the inputs and / or outputs of the channelizers in the failed service chain and perform RF analysis on the sampled streams to identify the problem with the failed service chain.

[0116] In additional or alternative embodiments, in response to detecting that a service chain is not performing satisfactorily, the monitoring service chain may operate continuously to monitor one or more service chains, rather than being instantiated. In this case, the monitoring service chain may be instantiated in parallel with the service chain(s) being monitored. As before, the monitoring service chain may sample the inputs and / or outputs of the channelizers in the service chain(s) and perform RF analysis on the sampled streams in these service chain(s) to detect any problems.

[0117] In either case, if a problem is identified or detected, the monitoring service chain may report the problem, directly or indirectly, to a decision maker, such as service orchestration system 105 or SDN controller 125. The decision maker may then responsively update the affected service chain to correct the problem as necessary (e.g., at subprocess 265). As an example, the monitoring service chain may detect a source of interference in the service chain and trigger a frequency change in the service chain to prevent further interference. In particular, one or more monitoring service chains may be instantiated, updated, and terminated just like any other service chain. Thus, advantageously, the monitoring service chain may be integrated into infrastructure 100 and treated just like any other service chain.

[0118] Furthermore, because the monitoring service chains are virtualized, they can be dynamically deployed to increase RF monitoring capacity or dynamically discarded to decrease RF monitoring capacity (and prevent under-utilization of resources) as needed due to changing conditions. This is simply not possible in a conventional satellite communications infrastructure with current technology. For example, assume that a modem in the service chain 300 temporarily loses lock with the satellite 120, and when the modem relocks to the satellite 120, the modem's throughput is only 20% of what it was before lock was lost. In a conventional satellite communications infrastructure, monitoring hardware would have to be migrated away from the normal monitoring plan and dedicated to troubleshooting the problem. In contrast, in the disclosed infrastructure 100, events can be detected and used to automatically trigger the instantiation of one or more monitoring service chains in the same manner as described herein for any service chain. For example, a first monitoring service chain can be instantiated to focus on the current degraded service, and a second monitoring service chain can be instantiated to replay the event and analyze the RF data to identify the cause of the lock loss in the first place.

[0119] 8. Exemplary Processing Device 7 is a block diagram illustrating an exemplary wired or wireless system 700 that may be used in connection with various embodiments described herein. For example, the system 700 may be used as or in combination with one or more of the functions, processes, or methods (e.g., for storing and / or executing software) described herein, and may represent or host components of the infrastructure 100, including the service orchestration system 105, payload controller 110, satellite manager 115, satellite 120, SDN controller 125, external resource manager 130, NFV orchestrator 135, network management system 140, external service designer 145, satellite NFV infrastructure 150, terminal NFV infrastructure 160, services 170, and / or consumers 175. The system 700 may be a server, or any conventional personal computer, or any other processor-enabled device capable of wired or wireless data communication. Other computer systems and / or architectures may be used, as will be apparent to those skilled in the art.

[0120] System 700 preferably includes one or more processors 710. Processor 710(s) may comprise a central processing unit (CPU). Additional processors may be provided, such as a graphics processing unit (GPU), auxiliary processors for managing input / output, auxiliary processors for performing floating point mathematical operations, special purpose microprocessors (e.g. digital signal processors) having an architecture suitable for fast execution of signal processing algorithms, secondary processors (e.g. back-end processors) subordinate to a main processing system, additional microprocessors or controllers for dual or multi-processor systems, and / or co-processors. Such auxiliary processors may be discrete processors or may be integrated with processor 710. Examples of processors that may be used in system 700 include, but are not limited to, any of the processors available from Intel Corporation of Santa Clara, California (e.g., Pentium™, Core i7™, Xeon™, etc.), any of the processors available from Advanced Micro Devices, Incorporated (AMD) of Santa Clara, California, any of the processors available from Apple Inc. of Cupertino (e.g., A-series, M-series, etc.), any of the processors available from Samsung Electronics Co., Ltd. of Seoul, Korea (e.g., Exynos™), and / or any of the processors available from NXP Semiconductors NV of Eindhoven, The Netherlands.

[0121] The processor 710 is preferably connected to a communications bus 705. The communications bus 705 may include a data channel for facilitating information transfer between storage and other peripheral components of the system 700. Additionally, the communications bus 705, including a data bus, an address bus, and / or a control bus (not shown), may provide a collection of signals used to communicate with the processor 710. The communications bus 705 may comprise any standard or non-standard bus architecture, such as, for example, Industry Standard Architecture (ISA), Extended Industry Standard Architecture (EISA), MicroChannel Architecture (MCA), Peripheral Component Interconnect (PCI) local bus, and / or a bus architecture conforming to a standard promulgated by the IEEE, including IEEE 488 General Purpose Interface Bus (GPIB), IEEE 696 / S-100, etc.

[0122] The system 700 preferably includes a main memory 715 and may also include a secondary memory 720. The main memory 715 provides storage of instructions and data for programs executed by the processor 710, such as any of the software discussed herein. It will be appreciated that the programs stored in the memory and executed by the processor 710 may be written and / or compiled according to any suitable language, including, but not limited to, C / C++, Java, JavaScript, Perl, Visual Basic, and .NET. The main memory 715 is typically a semiconductor-based memory, such as dynamic random access memory (DRAM) and / or static random access memory (SRAM). Other semiconductor-based memory types include, for example, synchronous dynamic random access memory (SDRAM), Rambus dynamic random access memory (RDRAM), and ferroelectric random access memory (FRAM), including read-only memory (ROM).

[0123] Secondary memory 720 is a non-transitory computer-readable medium on which computer-executable code (e.g., any of the software disclosed herein) and / or other data is stored. The computer software or data stored in secondary memory 720 is read into main memory 715 for execution by processor 710. Secondary memory 720 may include semiconductor-based memory such as, for example, programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable read-only memory (EEPROM), and flash memory (a block-oriented memory similar to EEPROM).

[0124] Secondary memory 720 may optionally include internal media 725 and / or removable media 730. Removable media 730 may be read from and / or written to in any known manner. Removable storage media 730 may be, for example, a magnetic tape drive, a compact disc (CD) drive, a digital versatile disc (DVD) drive, other optical drive, and / or a flash memory drive.

[0125] In alternative embodiments, secondary memory 720 may include other similar means for allowing computer programs or other data or instructions to be loaded into system 700. Such means may include, for example, a communications interface 740 for allowing software and data to be transferred to system 700 from an external storage medium 745. Examples of external storage medium 745 include an external hard disk drive, an external optical drive, and / or an external magneto-optical drive.

[0126] As mentioned above, the system 700 may include a communications interface 740. The communications interface 740 allows software and data to be transferred between the system 700 and an external device, network, or other information source. For example, computer software or executable code may be transferred to the system 700 from a network server via the communications interface 740. Examples of the communications interface 740 include an internal network adapter, a network interface card (NIC), a Personal Computer Memory Card International Association (PCMCIA) network card, a cardbus network adapter, a wireless network adapter, a universal serial bus (USB) network adapter, a modem, a wireless data card, a communications port, an infrared interface, an IEEE 1394 Firewire, and any other device capable of interfacing the system 700 with a network or another computing device. Communications interface 740 preferably implements industry promulgated protocol standards such as the Ethernet IEEE 802 standard, Fibre Channel, Digital Subscriber Line (DSL), Asynchronous Digital Subscriber Line (ADSL), Frame Relay, Asynchronous Transfer Mode (ATM), Integrated Services Digital Network (ISDN), Personal Communications Services (PCS), Transmission Control Protocol / Internet Protocol (TCP / IP), and Serial Line Internet Protocol / Point-to-Point Protocol (SLIP / PPP), although customized or non-standard interface protocols may be implemented as well.

[0127] The software and data transferred via communications interface 740 is typically in the form of electrical communications signals 755. These signals 755 may be provided to communications interface 740 via communications channel 750. In an embodiment, communications channel 750 may be a wired or wireless network, or any of a variety of other communications links. Communications channel 750 conveys signals 755 and may be implemented using a variety of wired or wireless communications means, including wire or cable, optical fiber, conventional telephone line, a cellular phone link, a wireless data communications link, a radio frequency ("RF") link, or an infrared link, to name a few.

[0128] Computer-executable code (e.g., computer programs such as the disclosed software) is stored in main memory 715 and / or secondary memory 720. Computer-executable code may also be received via communications interface 740 and stored in main memory 715 and / or secondary memory 720. Such computer programs, when executed, enable system 700 to perform various functions of embodiments of the present disclosure as described elsewhere herein.

[0129] The term "computer-readable medium" is used herein to refer to any non-transitory computer-readable storage medium used to provide computer-executable code and / or other data to or within system 700. Examples of such media include main memory 715, secondary memory 720 (including internal memory 725 and removable media 730), external storage media 745, and any peripheral devices communicatively connected to communication interface 740 (including a network information server or other network device). These non-transitory computer-readable media are means for providing software and / or other data to system 700.

[0130] In embodiments implemented using software, the software may be stored on a computer readable medium and loaded into the system 700 via the removable medium 730, the I / O interface 735, or the communications interface 740. In such embodiments, the software is loaded into the system 700 in the form of electrical communications signals 755. The software, when executed by the processor 710, preferably causes the processor 710 to perform one or more of the processes and functions described elsewhere herein.

[0131] In an embodiment, I / O interface 735 provides an interface between one or more components of system 700 and one or more input and / or output devices. Exemplary input devices include, but are not limited to, sensors, keyboards, touch screens or other touch-sensitive devices, cameras, biosensing devices, computer mice, trackballs, and / or pen-based pointing devices. Examples of output devices include, but are not limited to, other processing devices, cathode ray tubes (CRTs), plasma displays, light-emitting diode (LED) displays, liquid crystal displays (LCDs), printers, vacuum fluorescent displays (VFDs), surface-conduction electron emitter displays (SEDs), and / or field emission displays (FEDs). In some cases, input and output devices may be combined, such as in the case of touch-panel displays (e.g., in smartphones, tablets, or other mobile devices).

[0132] System 700 may also include any wireless communication components that facilitate wireless communication over voice and / or data networks, including antenna system 770, radio system 765, and baseband system 760. Radio frequency (RF) signals are transmitted and received over the air by antenna system 770 under the control of radio system 765.

[0133] In an embodiment, the antenna system 770 may include one or more antennas and one or more multiplexers (not shown) that perform a switching function to provide transmit and receive signal paths for the antenna system 770. In the receive path, the received RF signal may be passed from the multiplexer to a low noise amplifier (not shown), which amplifies the received RF signal and transmits the amplified signal to the radio system 765.

[0134] In alternative embodiments, the radio system 765 may comprise one or more radios configured to communicate over various frequencies. In an embodiment, the radio system 765 may combine a demodulator (not shown) and a modulator (not shown) into one integrated circuit (IC). The demodulator and modulator may be separate components. In the incoming path, the demodulator strips off the RF carrier signal, leaving a baseband receive audio signal, which is transmitted from the radio system 765 to the baseband system 760.

[0135] The above description of the embodiments of the present disclosure is provided to enable any person skilled in the art to make or use the invention. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles described herein may be applied to other embodiments without departing from the spirit or scope of the present invention. It should therefore be understood that the description and drawings presented herein represent presently preferred embodiments of the invention, and thus represent the subject matter broadly contemplated by the present invention. It will be further understood that the scope of the present invention fully encompasses other embodiments that may become apparent to those skilled in the art, and that the scope of the present invention is therefore not limited.

[0136] Combinations described herein, such as "at least one of A, B, or C," "one or more of A, B, or C," "at least one of A, B, and C," "one or more of A, B, and C," and "A, B, C, or any combination thereof," include any combination of A, B, and / or C, and may include multiple As, multiple Bs, or multiple Cs. Specifically, "at least one of A, B, or C," "one or more of A, B, or C," "at least one of A, B, and C," "one or more of A, B, and C," and "A, B, C, or any combination thereof" may be A only, B only, C only, A and B, A and C, B and C, or A and B and C, and any such combination may include one or more of the components A, B, and / or C of the combination. For example, a combination of A and B may include one A and multiple Bs, multiple A and one B, or multiple A and multiple Bs.

Claims

1. Software-defined network (SDN) controller receiving a service request including a service definition of an end-to-end service; calculating one or more parameters of a satellite link that satisfies the service definition; selecting a configuration of a satellite network service chain from a service catalog based on the calculated one or more parameters, the satellite network service chain including a plurality of virtual network functions; initiating an instantiation of the satellite network service chain with the selected configuration; and A method comprising:

2. The service request is received from a service orchestration system via at least one network, and the method further comprises, before receiving the service request, by the SDN controller: receiving a request for a service interface point from the service orchestration system via the at least one network; In response to the request, obtaining a list of available service interface points and transmitting the list of available service interface points to the service orchestration system via the at least one network; The method of claim 1 , comprising:

3. 3. The method of claim 2, wherein obtaining the list of available service interface points comprises obtaining a list of gateways and terminals via an application programming interface of a network management system over the at least one network.

4. The method of claim 1 , wherein the service definition defines a Carrier Ethernet (CE) service.

5. The method of claim 1 , wherein the service definition includes one or more service parameters that identify gateways and terminals and define a service level agreement.

6. The method of claim 5 , wherein the one or more service parameters include a committed information rate and an excess information rate.

7. The method of claim 6 , wherein the one or more service parameters further include a maximum information rate.

8. After instantiating the satellite network service chain, monitoring one or more key performance indicators of the satellite network service chain; if the one or more key performance indicators do not satisfy the service parameters, selecting a new configuration of the satellite network service chain from the service catalog based on the calculated one or more parameters, and updating the satellite network service chain to the new configuration; The method of claim 5 further comprising:

9. updating the satellite network service chain instantiating a new satellite network service chain with the new configuration; and migrating traffic from the satellite network service chain to the new satellite network service chain; terminating the satellite network service chain of the configuration; and The method of claim 8 , comprising:

10. The method of claim 1 , wherein the one or more parameters is a link budget.

11. The method of claim 1 , wherein the configuration includes one or more dimensions of computing resources allocated to the plurality of virtual network functions within a cloud computing environment.

12. 2. The method of claim 1, wherein initiating instantiation of the satellite network service chain comprises sending a service chain request including the configuration over at least one network to a network management system.

13. The network management system receiving the service chain request from the SDN controller via the at least one network; sending an instantiation request to a network function virtualization (NFV) orchestrator over the at least one network in response to the service chain request; The method of claim 12 further comprising:

14. The NFV orchestrator receiving the instantiation request from the network management system over the at least one network; instantiating the plurality of virtual network functions within a cloud computing environment in response to the instantiation request; The method of claim 13 further comprising:

15. 14. The method of claim 13, wherein the instantiation request may include a gateway configuration of a satellite service chain, the method further comprising: sending, by the network management system, a terminal configuration of a terminal service chain to a terminal configuration service in response to the service chain request.

16. the plurality of virtual network functions, an encapsulator and modulator for converting the Ethernet packets into satellite frames; a demodulator and decapsulator for converting satellite frames into Ethernet packets; The method of claim 1 , comprising one or both of:

17. instantiating the satellite network service chain in a sandbox environment, the plurality of virtual network functions including one or more virtual network functions simulating the satellite link; obtaining performance parameters of the satellite network service chain in the sandbox environment; and The method of claim 1 further comprising:

18. The method of claim 1 , further comprising reconfiguring the satellite network service chain in the sandbox environment based on the obtained performance parameters.

19. The SDN controller receiving a service request including a service definition for a monitoring service; identifying a monitoring service chain configuration of said monitoring service; initiating an instantiation of the monitoring service chain with the identified configuration, the monitoring service chain performing an analysis of digital signal streams within the satellite network service chain; The method of claim 1 further comprising:

20. 2. The method of claim 1, wherein the plurality of virtual network functions comprises a virtualized modem including at least one demodulator configured to demodulate waveforms in accordance with a Digital Video Broadcasting (DVB) standard, at least one modulator configured to modulate waveforms in accordance with the DVB standard, at least one encapsulator, and at least one decapsulator.

21. 21. The method of claim 20, wherein the virtualized modem provides Carrier Ethernet services.

22. at least one hardware processor; one or more software modules; A system comprising: The one or more software modules, when executed by the at least one hardware processor, receiving a service request including a service definition of an end-to-end service; calculating one or more parameters of a satellite link that satisfies the service definition; selecting a configuration of a satellite network service chain from a service catalog based on the calculated one or more parameters, the satellite network service chain including a plurality of virtual network functions; initiating an instantiation of the satellite network service chain with the selected configuration; and The system is configured to execute the following:

23. A non-transitory computer-readable medium having instructions stored thereon, the instructions, when executed by a processor, receiving a service request including a service definition of an end-to-end service; calculating one or more parameters of a satellite link that satisfies the service definition; selecting a configuration of a satellite network service chain from a service catalog based on the calculated one or more parameters, the satellite network service chain including a plurality of virtual network functions; initiating an instantiation of the satellite network service chain with the selected configuration; and The non-transitory computer-readable medium causes the processor to execute.

Images