JP7724966B2 - Dynamic Management of Software-Defined Service Chains for Satellite Communications - Google Patents

Description

The embodiments described herein relate generally to satellite communications, and more specifically to dynamic management of software-defined service chains for satellite communications.

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

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

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 inhibits the ability to automate and scale the system-wide orchestration of services over satellite links, which is necessary to create and manage the service lifecycle.

Accordingly, a system and method are disclosed for dynamically managing software-defined service chains for satellite communications in an automated and scalable manner.

In an embodiment, a method includes receiving, by a software-defined network (SDN) controller, a service request including a service definition for 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.

The service request may be received from the service orchestration system via at least one network, and the method may further include, before receiving the service request, receiving, by the SDN controller, a request for service interface points from the service orchestration system via at least one network, and, 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 at least one network. Obtaining the list of available service interface points may include obtaining, via at least one network, a list of gateways and terminals via an application programming interface of the network management system.

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

The service definition may include one or more service parameters that identify 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, after instantiating the satellite network service chain, monitoring one or more key performance indicators of the satellite network service chain, and 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 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.

One or more of the parameters may be a link budget.

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

Initiating instantiation of the satellite network service chain may include sending a service chain request including the configuration to a network management system via at least one network. The method may further include receiving, by the network management system, the service chain request from the SDN controller via the at least one network, and sending an instantiation request to a network functions virtualization (NFV) orchestrator via 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 via the at least one network, and instantiating multiple 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.

The multiple 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.

The method further comprises:
This 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.

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

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

The plurality of virtual network functions may comprise a virtualized modem including at least one demodulator configured to demodulate waveforms in accordance with the 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. The virtualized modem may provide Carrier Ethernet services.

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

The details of the present invention, both as to its structure and operation, can be gleaned in part from a study of the accompanying drawings, in which like reference numerals refer to like parts, and in which:

1 illustrates an exemplary infrastructure in which one or more of the processes described herein may be implemented, according to an embodiment. 1 illustrates a process for dynamic management of software-defined service chains for satellite communications, according to an embodiment. 1 illustrates an exemplary service chain of an end-to-end service, according to an embodiment. 1 illustrates an exemplary service chain of an end-to-end service, according to an embodiment. 1 illustrates an exemplary service chain within a sandbox environment, according to an embodiment. 1 illustrates a process for satellite planning using a sandbox environment, according to an embodiment. 1 illustrates a process for automated management of satellite resources, according to an embodiment. 1 illustrates an exemplary processing system in which one or more of the processes described herein may be performed, according to an embodiment.

In embodiments, systems and methods 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 those skilled in the art how to implement the present invention in various alternative embodiments and 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. Accordingly, 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.

1. Introduction Embodiments utilize the concept of service orchestration to facilitate the automated creation of services that utilize satellite communications in a virtual (e.g., cloud) environment. Embodiments may dynamically adapt to the specifics 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 beam or antenna, payload electronics (e.g., transponders, regenerative systems, onboard dividers, onboard combiners, steerable antennas, etc.), and/or any other attributes specific to the satellite communications domain. Such automation may take into account factors affecting the satellite RF link, such as high latency, rain or atmospheric fading, 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).

In an embodiment, to address these satellite-specific factors, given the variability in configuration options 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 with the initial configuration into a service chain within a cloud computing environment, configuring the service chain to a production (day 1) configuration, and migrating the service to new (day N) configurations over the lifecycle of the service to meet service level agreements and/or key performance indicators (KPIs) required in the service definition.

Although embodiments are described herein primarily in the context of an 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.

1 illustrates an exemplary 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, satellites 120, a software-defined network (SDN) controller 125, an external resource manager 130, a network functions 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. While 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.

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. Service orchestration system 105 manages services on 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, telecommunications (telecom) domains, and/or other types of domains.

The service orchestration system 105 may communicate directly or indirectly with the payload controller 110. The payload controller 110 may map or translate commands from the service orchestration system 105 into procedures for the satellite manager 115. For example, the commands may include configuration commands 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) offered by Kratos Defense & Security Solutions, Inc. of San Diego, California. Satellite 120 decodes the procedure from the RF link and executes the procedure, which may include configuring one or more components within satellite 120's payload to support the service managed by service orchestration system 105. Thus, service orchestration system 105 may manage satellite 120's payload like any other network element to coordinate and optimize its operation.

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 as a payload model defined in, for example, 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 Transmission Control Protocol (TCP) or another communication protocol.

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 needed to implement 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 needed to implement the service chain and then instruct the NFV orchestrator 135 on which elements are needed 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. SDN controller 125 may manage the service chains through communication with one or more of NFV orchestrators 135 and/or one or more of network management systems 140. SDN controller 125 may be implemented with the OpenSpace™ platform offered by Kratos Defense & Security Solutions, Inc. of San Diego, California. In an embodiment, service orchestration system 105 may poll SDN controller 125 at any time for the status of any service chain, and SDN controller 125 may provide the status of the service chain to service orchestration system 105 in response.

Each external resource manager 130 may monitor parameters of the service chain. For example, the external resource manager 130 may be a resource controller that monitors parameters of the RF link to or from the satellite 120, load parameters on the gateway, and/or other dynamic parameters associated with the service chain. The external resource manager 130 reports these parameters to the service orchestration system 105 and/or the SDN controller 125 to inform decision-making (e.g., triggering actions) in the service orchestration system 105 and/or the SDN controller 125.

Each NFV orchestrator 135 may manage the satellite NFV infrastructure 150 on the service side of the satellite 120. The NFV orchestrator may function 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 within 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.

Each network management system 140 maintains information about the network, including a service catalog, an inventory of service interface points (SIPs) within 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 definition gain/noise temperature (G/T), supported terminal classes (e.g., antenna size, amplifier size, output power, antenna gain, etc.), and/or computing resource dimensions. It should be understood that each service profile need not include all of the information used for a service chain, 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 the 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 on gateways and physical or virtual service termination points on remote terminals available in the network and managed by network management system 140.

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 the terminal configuration service 162 in the edge NFV infrastructure 160 to instantiate and configure the VNF(s) 164 that comprise the terminal service chain 166.

Each satellite NFV infrastructure 150 may include 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 understood 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 include 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 chain 156 links 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 one example, the virtual infrastructure manager 152 and/or the VNF 154 may be implemented with the OpenSpace™ platform offered by Kratos Defense & Security Solutions, Inc. of San Diego, California.

Each edge NFV infrastructure 160 may include a terminal configuration service 162 configured to instantiate a terminal service chain 166. The terminal service chain 166 may include one or more VNFs 164, such as VNF 164A, ..., VNF 164N. The terminal service chain 166 links consumers 175 to satellites 120. The edge NFV infrastructure 160 may reside within 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.

An end-to-end service is formed between a service 170 and a 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 communications, data flows from the service 170, through the satellite service chain 156, through the satellite 120, and through the terminal service chain 166 to the consumer 175. It should be understood that in broadcast or multicast satellite communications, there may be multiple consumers 175. Furthermore, in two-way satellite communications, data flows from the consumer 175, through the terminal service chain 166, through the satellite 120, and 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.

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 may be executed by one or more hardware or virtual processors in one or more hardware systems. Specifically, process 200 may be embodied in software modules distributed throughout infrastructure 100, as illustrated by corresponding sub-process numbers in FIG. 1 .

Although process 200 is shown with a particular arrangement and order of subprocesses, process 200 may be performed with fewer, more, or different subprocesses, and with a different arrangement and/or order of the subprocesses. Furthermore, even if the subprocesses are described or illustrated in a particular order, any subprocess that is not dependent on the completion of another subprocess may be performed before, after, or in parallel with other independent subprocesses.

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).

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's 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) 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 0 and day 1 configurations of the VNFs 154 in 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.

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 and store the service interface points and service catalog from the network management system 140, so that the SDN controller 125 can 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 have access to a database of service interface points and/or service catalogs.

In sub-process 215, service orchestration system 105 receives a response to its request from SDN controller 125, including a list of available service interface points, and creates a service request based on the response. Service orchestration system 105 may store the list of available service interface points returned by SDN controller 125 in a database of possible endpoints, which is used to define Carrier Ethernet (CE) services for the customer. Service orchestration system 105 may also collect information about any existing CE Ethernet Virtual Connection (EVC) states. Although the services described herein are primarily described as CE services, it should be understood that 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 may be 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.

The service orchestration system 105 may create a provisioning order (e.g., at the OSS layer) that associates two or more service interface points, service parameters, and/or transport attributes with a service definition (e.g., a CE service definition) based on information in the response from the SDN controller 125. For a CE E-Line service, the service interface point 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 point 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.

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

In sub-process 225, SDN controller 125 executes the service request received from service orchestration system 105. Specifically, 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 the link budget of the satellite link. 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., are 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 satellite 120 can correspond to the terminal's location. Once SDN controller 125 identifies the variables necessary to satisfy the service request, 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.

In 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 the 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 network management system 140's API to submit the service chain request.

A 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 for the service chain, such as the specific VNFs and specific placement of VNFs to use, dimensions of the VNF service chain (e.g., satellite service chain 156 and/or terminal service chain 166), allowed cloud zones or regions, mode, teleport uplink, and/or satellite allocation. 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. Dimensions may be selected as one of multiple predefined performance tiers based on service parameters in the service definition. Allowed cloud zones or regions may also be selected based on restrictions in the service definition (e.g., specifications for secure cloud, public cloud, or other enclave definitions).

In sub-process 235, the network management system 140 submits an instantiation request for 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. Within 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 a 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.

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 lifecycle 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-154N) that comprise 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 understood that NFV orchestrator 135 may instantiate satellite service chain 156 according to the dimensions of the cloud zone or cloud region and/or mode (e.g., production environment or sandbox environment) specified in the configuration. It should be further understood that NFV orchestrator 135 may have or instantiate satellite service chain 156 in different configurations based on the service request, and that the only limitation on the number of instances of satellite service chain 156 is the amount of resources available to satellite service chain 156 within satellite NFV infrastructure 150, as the amount of resources available is determined by the amount of resources within the cloud computing environment (e.g., within a particular cloud zone or cloud region) and any other applicable constraints.

In subprocess 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 VNF 154A to VNF 154N) in the satellite service chain 156.

In sub-process 250, the network management system 140 generates an appropriate configuration for the terminal using service interface point pairing 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.

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 the API of the service orchestration system 105, the SDN controller 125, and/or the external service management system to send the statistics.

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 in 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 transmit the parameters.

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 the service definition) associated with the services implemented 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 implemented by the service chain. A determination of whether a service chain meets its 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.

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

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.

In an embodiment, if subprocess 265 is unable to update the service chain to be satisfactory (e.g., meet 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., maximizing performance toward an associated service level agreement).

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 needed. 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. Service chain updates may then be scheduled. In either case, process 200 enables fully automated deployment and scaling of service chain management in the satellite communications domain. Advantageously, the level of autonomy provided in infrastructure 100 can be tuned to the requirements of each particular service provider, anywhere along the spectrum between no autonomy and full autonomy.

4. Exemplary Service Chains 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, the service chain may provide communications with a satellite as an endpoint, for example, for TT&C and/or mission data download.

Figure 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 operate in parallel, and separate service chains 300 may have different arrangements from one another. In other words, service orchestration system 105 and/or SDN controller 125 may manage multiple different and/or independent service chains 300 simultaneously.

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 service chains 300 based on the service lifecycle defined for each service chain 300 at the OSS layer. At any point in the service lifecycle, the SDN controller 125 accepts 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., satellite service chain 156) and release the underlying computing elements that were deployed when the service was created.

Endpoint 310A may be communicatively connected to one or more gateway switches 330A via a network 320 (e.g., including the Internet or a private communications backbone). Two sets of one or more VNFs 154 may provide bidirectional communication, including a transmit path and a receive path, between gateway switches 330A and 330B. It should be understood that in embodiments in which service chain 300 provides only unidirectional communication, VNFs 154 may provide only a transmit path without providing a receive path.

Switch 330A and switch 330B may each be a physical or virtual Gigabit Ethernet (GigE) switch. Switch 330A and switch 330B are shown as separate switches, with switch 330A residing at the boundary between network 320 and satellite VNF infrastructure 150, and switch 330B residing at the boundary between satellite VNF infrastructure 150 and components providing links to satellite 120. However, it should be understood that switch 330A and switch 330B may be implemented in the same switch. In either case, switch 330A may perform transport from network 320 to the 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, switch 330A itself may represent a UNI as defined by the applicable MEF E-Tree or E-LAN service standard.

From the perspective of endpoint 310A, it is apparent that endpoint 310A is simply communicating with switch 330A. The fact that switch 330A provides communications via satellite 120 is immaterial to endpoint 310A and does not need to be known by endpoint 310A. Thus, satellite communications are available via 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.

The collection of VNFs 154(s) (e.g., implementing a gateway) on the forward path from switch 330A to switch 330B toward the link to satellite 120 may comprise or consist of, in order from switch 330A to switch 330B, a traffic handler, an encapsulator (e.g., implementing generic stream encapsulation (GSE)), a modulator (e.g., the OpenSpace™ wideband software modulator offered by Kratos Defense & Security Solutions, Inc., San Diego, California), 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 into baseband frames and provide the baseband frames to the modulator. The encapsulator may form the baseband frames in accordance with the DVB-S2x standard 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 subprocesses) that perform 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 rewriting (e.g., rewriting ingress/egress Ethernet frames based on MEF definitions), Ethernet Virtual Connection over-the-air (OTA) transport header compression (e.g., Robust Header Compression (ROHC)), and/or OTA optimization (e.g., Space Communications Protocol Specification (SPCS)/TCP acceleration). The modulator may convert baseband frames into signal data packets (e.g., according to the standards of the Digital Intermediate Frequency Interoperability (DIFI)/DIFI Consortium of the Institute of Electrical and Electronics Engineers (IEEE) 1.0 specification). 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.

The collection of VNFs 154(s) on the reverse path from switch 330B to switch 330A, away from the link to satellite 120, may comprise or comprise, in the order from switch 330B to switch 330A, a digital channelizer (e.g., an OpenSpace™ wideband channelizer from Kratos Defense & Security Solutions, Inc. of San Diego, California), a demodulator (e.g., an OpenSpace™ wideband software receiver from Kratos Defense & Security Solutions, Inc. of San Diego, California), and a decapsulator. This collection of VNFs 154(s) on the receive path may convert the digital signals into Ethernet packets. For example, the channelizer may receive a digital signal from digitizer 340A, which converted an analog signal to a digital signal, via switch 330B, and split the digital signal into signal data packets. The demodulator may convert the signal data packets into baseband frames and provide the baseband frames to the decapsulator. The decapsulator may convert the baseband frames into 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 in a vModem as a single VNF 154, 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 the modulator/demodulator.

In embodiments in which 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 that are 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) back 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. While a digital satellite broadcasting standard such as the DVB standard is used as an example, the vModem may also be configured to modulate and demodulate waveforms in accordance with other standards for wideband digital communications, such as orthogonal frequency division multiplexing (OFDM).

In an embodiment, satellite service chain 156 may be a composite service chain utilizing 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, composite satellite service chain 156 is composed of first service chain 156A or first service chain 156B associated with a particular service 170 and second service chain 156C, which may be shared by multiple services. For example, both first service chain 156A and first service chain 156B may utilize second service chain 156. Switch 330C may then route data between service chain 156A and service chain 156C, as well as between service chain 156B and service chain 156C. First service chain 156A and first service chain 156B may represent different services or different instances of the same service. While only two are shown, it should be understood that any number of first service chains may similarly be linked to second service chain 156C. In an embodiment, second service chain 156C may have a longer life cycle than either of the first service chains (e.g., 156A and 156B), such that second service chain 156C persists while multiple first service chains are instantiated, linked to second service chain 156C, and then terminated based on demand for one or more services 170. First service chain 156A and 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).

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

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

Digitizer 340A communicates with antenna 350A. Specifically, digitizer 340A provides a transmit signal to antenna 350A, which transmits the transmit signal to satellite 120. Additionally, in bidirectional communication, antenna 350A receives a receive signal from satellite 120 and provides the receive signal to digitizer 340A.

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 to or identical to antenna 350A, and therefore any description of antenna 350A applies equally to antenna 350B and will not be redundantly described herein. Similarly, digitizer 340B may be functionally similar to or identical to digitizer 340A, and therefore any description of digitizer 340A applies equally to digitizer 340B and will not be redundantly described herein.

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 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 as 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 signal frames into Ethernet packets, and the transmit path may comprise an encapsulator followed by a modulator to convert Ethernet packets into signal frames. The encapsulators, decapsulators, modulators, and demodulators may all be similar or identical to those described with respect to satellite service chain 156, and therefore the description of these components with respect to satellite service chain 156 applies equally to these components in terminal service chain 166 and will not be redundantly described herein in this regard.

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 bidirectional communication, an encapsulator in terminal services chain 166 may receive an Ethernet packet from endpoint 310B. Thus, service chain 300 enables unidirectional or bidirectional communication between endpoint 310A and endpoint 310B over the satellite link.

It should be understood that service chain 300 is a single, non-limiting example of a service chain. In an alternative embodiment, the terminal side of satellite 120 may be identical to the gateway side of satellite 120 shown in FIGS. 3A and 3B, whereby 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 identical to the terminal side of satellite 120 shown in FIGS. 3A and 3B, whereby satellite service chain 166 communicates directly with digitizer 340A and endpoint 310A instead of via switch 330 and/or network 320. The service chain may also be configured in any number of other different ways.

The service chain 300 may include one or more software-defined components (e.g., a VNF and/or a digitizer) 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 are incorporated by reference herein as if fully set forth.

Advantageously, utilizing VNF and software-defined components (e.g., digitizer 340A and digitizer 340B) to perform various functions of service chain 300 promotes automation and scalability. Specifically, service chain 300 minimizes the presence of physical hardware components, allowing components of service chain 300 to be dynamically reconfigured (e.g., added, updated, discarded, increased or decreased in dimensions, etc.) in real time, primarily using in-band network communications, to adapt to the unique, multivariate satellite communications environment (e.g., RF interference, atmospheric characteristics, antenna conditions, path length, etc.).

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 by service chain 300 on demand to ensure service chain 300 satisfaction, 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 service chain 300, thereby causing service chain 300 to provide significantly better performance than required by a service level agreement. In that case, SDN controller 125 can determine (e.g., in subprocess 260) that service chain 300 is unsatisfactory and update service chain 300 (e.g., in subprocess 265) to reduce the resources used by service chain 300 (e.g., by reducing RF bandwidth usage, resizing one or more VNFs, replacing service chain 300 with a reduced-dimension service chain, etc.). This is in contrast to traditional hardware-based service chains, where unused resources simply remain idle or ignored, representing a sunk cost that cannot be recovered.

5. Sandbox In embodiments, 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 the 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 network management system 140's web services to build the service chain in the sandbox environment. As used herein, the term "sandbox" refers to a test environment that isolates a service chain from a production environment so that the service chain can be safely evaluated without affecting any components of the production environment.

Building a service chain in a sandbox environment may be similar to building a service chain in a production environment. Specifically, as in subprocess 220, service orchestration system 105 may send a service request to 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, which includes the sandbox indication, SDN controller 125 may define a day-zero configuration for the service chain based on the service requirements. This day-zero configuration may include parameters for the satellite and RF link so that VNFs representing the satellite and RF link can be defined. SDN controller 125 may submit an instantiation request to NFV orchestrator 135 to instantiate the entire service chain in the day-zero configuration within the sandbox environment. In response to the instantiation request, NFV orchestrator 135 may instantiate the service chain in accordance with the day-zero configuration in the sandbox environment. For example, the entire sandbox environment, including 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 the parameters of the satellite and RF link in a day-zero configuration).

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. Switches 330A and 330B may each be Gigabit Ethernet (GigE) switches. While switches 330A and 330B are shown as separate switches, it should be understood that switches 330A and 330B may be implemented in the same physical or virtual switch. An operator can test or evaluate the service chain 400 by running a simulation that passes data through the service chain 400 between switches 330A and 330B according to the link budget and/or traffic characteristics of the scenario for which the service chain 400 is being 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 fluctuations of traffic over time. Performance parameters of the simulated service chain 400 may be obtained and analyzed to assess the expected performance of the service chain 400 in a given scenario.

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 set of VNFs 154(s) and set of VNFs 164(s) may be used to construct these portions of the service chain 400. The primary 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 set of VNFs 154(s) and/or 164(s) may be tested in a sandbox environment with or without modeling of the physical components.

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 satellite (VSAT) ground station, the terminal VNF 410B may simulate a VSAT ground station. 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 backoff/output backoff (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.

Channel VNFs 420A and 420B may model the 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.

The satellite payload VNF 450 may model the satellite 120, including the name and location of the satellite 120 and 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 frequencies (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. 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).

In embodiments, 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-zero configuration, such 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 a sandbox environment before deploying it in a production environment. Furthermore, 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.

Once the operator is satisfied with the performance of the service chain 400, the operator may store the configuration of the service chain based on the 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 the service orchestration system 105 via the SDN controller 125. Alternatively or additionally, in embodiments, the operator may deploy the service chain directly from the sandbox environment to the production environment (e.g., via a configuration interface in the SDN controller 125).

Advantageously, deploying service chain 400 from a sandbox environment to a production environment can be identical to deploying service chain 300 directly to a production environment. Thus, using a sandbox environment not only enables testing and tuning of the service chain, but also enables testing and tuning of the deployment of the service chain. Specifically, issues that arise during the deployment of a service chain from a sandbox environment to a production environment can be resolved so that they do not occur when the service chain is deployed directly to a production environment. This is notably impossible in traditional environments that utilize dedicated hardware.

Figure 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 simulations in the sandbox environment to finalize the service chain configuration, and saves and/or schedules the service chain.

Although process 500 is shown with a particular arrangement and order of subprocesses, process 500 may be performed with fewer, more, or different subprocesses, and with a different arrangement and/or order of the subprocesses. Furthermore, even if the subprocesses are described or illustrated in a particular order, any subprocess that is not dependent on the completion of another subprocess may be performed before, after, or in parallel with other independent subprocesses.

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), another system (e.g., via an API), and/or 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, which may represent a service level agreement, a class of terminal, a location of the terminal, and/or an operational schedule for the service.

At sub-process 510, process 500 checks for and applies regulatory constraints. These regulatory constraints may be based on the location of the terminal within 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.

In subprocess 515, process 500 calculates variables to apply to the service. These calculations may be constrained by regulatory constraints applied in subprocess 510. The calculated variables may include variables representing the ground station (e.g., at gateway VNF 410A and terminal VNF 410B), the RF link (e.g., at channel VNFs 420A and 420B), the satellite payload (e.g., at satellite payload VNF 430), margin requirements, and/or link budget.

In 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 no existing service exists, 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" in sub-process 520), process 500 proceeds to sub-process 525. Alternatively, if allocation is not needed (i.e., "Yes" in sub-process 520), process 500 proceeds to sub-process 545.

In sub-process 525, process 500 identifies satellite 120 and/or satellite bandwidth allocations 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, on satellite 120. Optimizations may be performed on bandwidth and/or power according to general or customer-specific constraints.

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

Subprocess 540 may include notifying the requestor that received the service definition in subprocess 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 internal process, the notification may include providing a response message to the other system or internal process.

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 necessary 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 service template database.

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.

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

In 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 in sub-process 555 or until 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 another 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 another iteration of re-planning. If it is determined to proceed with another iteration of re-planning (i.e., "Yes" in sub-process 560), process 500 may proceed to sub-process 565. Alternatively, if it is determined not to proceed with another iteration of re-planning (i.e., "No" in sub-process 560), process 500 may reject the request in sub-process 540.

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

At sub-process 570, process 500 may store the service chain determined to be satisfactory in sub-process 555 as a service profile in a service catalog described elsewhere herein. Furthermore, deployment of the service chain may be scheduled according to the operational schedule of the service definition.

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.

In sub-process 580, process 500 may save the payload configuration in the service chain. Further, reconfiguration of the satellite 120's payload may be scheduled according to the service-defined operational schedule. According to the operational schedule, the satellite 120's payload 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.

6 shows 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 service orchestration system 105. Essentially, process 600 determines whether a service is achievable, available, and supportable, and reconfigures the satellite 120 payload as needed.

Although process 600 is shown with a particular arrangement and order of subprocesses, process 600 may be performed with fewer, more, or different subprocesses, and with a different arrangement and/or order of the subprocesses. Furthermore, even if the subprocesses are described or illustrated in a particular order, any subprocess that is not dependent on the completion of another subprocess may be performed before, after, or in parallel with other independent subprocesses.

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

In subprocess 505, a service definition is received. First, in subprocess 610, process 600 determines whether a satisfactory service profile is available in the service catalog. Subprocess 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 exists in the service catalog (i.e., "Yes" at subprocess 610), process 600 may proceed to subprocess 520. Alternatively, if a satisfactory service profile does not exist in the service catalog (i.e., "No" at subprocess 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.

In sub-process 520, process 600 determines whether allocation is required. If allocation is required (i.e., "No" in sub-process 520), process 600 proceeds to sub-process 525. Alternatively, if allocation is not required (i.e., "Yes" in sub-process 520), process 600 proceeds to sub-process 620.

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.

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

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), at sub-process 545, process 600 may send a service request to SDN controller 125 to instantiate and run the service in the production environment. 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.

7. Monitoring Through a Service Chain In embodiments, 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 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 the digital signal stream, it may record all RF data in short-term or long-term buffers to aid in troubleshooting transient events (e.g., by analyzing historical RF data leading up to the transient event).

In an embodiment, if a service chain is determined to be unsatisfactorily performing (e.g., "No" at subprocess 260), one or more instances of a monitoring 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 monitoring 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.

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. Again, 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 those service chain(s) to detect any problems.

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 needed (e.g., at subprocess 265). As an example, the monitoring service chain may detect a source of interference within the service chain and trigger a frequency change within 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.

Furthermore, because the monitoring service chains are virtualized, they can be dynamically deployed to increase RF monitoring capacity or dynamically destroyed to decrease RF monitoring capacity (and prevent underutilization of resources) as needed due to changing conditions. This is simply not possible with conventional satellite communications infrastructures with current technology. For example, assume that a modem in service chain 300 temporarily loses lock on satellite 120. When the modem relocks to satellite 120, the modem's throughput is only 20% of what it was before lock was lost. In conventional satellite communications infrastructures, 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.

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, 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 infrastructure 100, including 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. System 700 may be a server, or any conventional personal computer, or any other processor-enabled device capable of wired or wireless data communication. Those skilled in the art will appreciate that other computer systems and/or architectures may be used.

System 700 preferably includes one or more processors 710. Processor(s) 710 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, specialized microprocessors (e.g., digital signal processors) having architectures suitable for fast execution of signal processing algorithms, secondary processors (e.g., back-end processors) subordinate to the main processing system, additional microprocessors or controllers for dual-processor or multi-processor systems, and/or coprocessors. 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 N.V. of Eindhoven, The Netherlands.

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, an Industry Standard Architecture (ISA), an Extended Industry Standard Architecture (EISA), a MicroChannel Architecture (MCA), a 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.

System 700 preferably includes main memory 715 and may also include secondary memory 720. Main memory 715 provides storage of instructions and data for programs executed by processor 710, such as any of the software discussed herein. It will be appreciated that the programs stored in memory and executed by 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. Main memory 715 is typically 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).

Secondary memory 720 is a non-transitory computer-readable medium that stores computer-executable code (e.g., any of the software disclosed herein) and/or other data. The computer software or data stored in secondary memory 720 is loaded into main memory 715 for execution by processor 710. Secondary memory 720 may include, for example, semiconductor-based memory such as 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).

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.

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 that allows 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.

As previously mentioned, system 700 may include a communications interface 740. Communications interface 740 allows software and data to be transferred between system 700 and an external device, network, or other information source. For example, computer software or executable code may be transferred to system 700 from a network server via communications interface 740. Examples of communications interface 740 include an internal network adapter, a network interface card (NIC), a Personal Computer Memory Card International Association (PCMCIA) network card, a Card Bus 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 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.

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

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.

As used herein, the term "computer-readable medium" refers 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 network information servers or other network devices). These non-transitory computer-readable media are means for providing software and/or other data to system 700.

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 communication interface 740. In such embodiments, the software is loaded into the system 700 in the form of electrical communication signals 755. When executed by the processor 710, the software preferably causes the processor 710 to perform one or more of the processes and functions described elsewhere herein.

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, touchscreens or other touch-sensitive devices, cameras, biometric sensing 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, a display may combine input and output devices, such as in the case of a touch-sensitive display (e.g., in a smartphone, tablet, or other mobile device).

System 700 may also include any wireless communication components that facilitate wireless communication over a voice network and/or a data network. Wireless communication components include an antenna system 770, a radio system 765, and a baseband system 760. In system 700, radio frequency (RF) signals are transmitted and received over the air by antenna system 770 under the control of radio system 765.

In an embodiment, 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 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 radio system 765.

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

The foregoing description of 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 invention. It should therefore be understood that the description and drawings presented herein represent presently preferred embodiments of the invention and, therefore, represent the broadly contemplated subject matter of 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.

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 refer to A only, B only, C only, A and B, A and C, B and C, or A, 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 (23)

1. A method, comprising :
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 satellite network service chain configuration 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 in a selected configuration ;
A method comprising: The service request is received from a service orchestration system via at least one network, and the method further includes, before receiving the service request, by the SDN controller:
receiving a service interface point request 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: The method of claim 2, wherein obtaining the list of available service interface points includes obtaining a list of gateways and terminals via an application programming interface of a network management system via the at least one network. The method of claim 1, wherein the service definition defines a Carrier Ethernet (CE) service. 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. The method of claim 5, wherein the one or more service parameters include a committed information rate and an excess information rate. The method of claim 6, wherein the one or more service parameters further include a maximum information rate. After instantiating the satellite network service chain,
monitoring one or more key performance indicators of the satellite network service chain;
when 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: 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 with the configuration; and
The method of claim 8, comprising: The method of claim 1, wherein the one or more parameters is a link budget. 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. The method of claim 1, wherein initiating instantiation of the satellite network service chain includes sending a service chain request including the configuration to a network management system over at least one network. 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 functions virtualization (NFV) orchestrator over the at least one network in response to the service chain request;
The method of claim 12 further comprising: 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;
14. The method of claim 13, further comprising: The method of claim 13, wherein the instantiation request may include a gateway configuration for a satellite service chain, and the method further includes, by the network management system, sending a terminal configuration for a terminal service chain to a terminal configuration service in response to the service chain request. the plurality of virtual network functions,
an encapsulator and modulator for converting 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: instantiating the satellite network service chain in a sandbox environment, the plurality of virtual network functions including one or more virtual network functions that simulate the satellite link;
obtaining performance parameters of the satellite network service chain in the sandbox environment;
The method of claim 1 further comprising: 20. The method of claim 17 , further comprising reconfiguring the satellite network service chain in the sandbox environment based on the obtained performance parameters. The SDN controller
receiving a service request including a service definition for a monitoring service;
Identifying a monitoring service chain configuration of the monitoring service;
Initiating an instantiation of the monitoring service chain with the identified configuration , the monitoring service chain performing analysis of digital signal streams within the satellite network service chain;
The method of claim 1 further comprising: 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 the 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. The method of claim 20, wherein the virtualized modem provides Carrier Ethernet services. 1. A system comprising:
at least one hardware processor;
one or more software modules , which 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 satellite network service chain configuration 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 in a selected configuration ;
a software module configured to execute
A system comprising : A non-transitory computer-readable medium having instructions stored therein , the instructions, when executed by a processor, causing the processor to:
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 satellite network service chain configuration 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 in a selected configuration ;
A non- transitory computer-readable medium for causing the execution of