Friday, 02 September 2016 15:53

VITAL Architecture Overview Featured

In this short article, we present the high-level view of the overall architecture for SDN/NFV-enabled satellite ground segment systems (also presented in the deliverable D2.3 [available here for download]), illustrating its functional building blocks and the reference points among them.


The VITAL system architecture is composed of the following building blocks:

  • Physical network infrastructure with virtualization support: This building block consists of the virtualization-capable physical network elements on top of which Virtualised Satellite Networks (VSNs) are deployed. This infrastructure includes:
    • NFV Infrastructure-Point(s) of Presence (NFVI-PoP(s)) for the deployment of VNFs. The main resources in these NFVI-PoPs are network, computing (CPU) and storage. There could be several distributed NFVI-PoPs, including a lightweight NFVI-PoP at the satellite terminal side. Resources in each NFVI-PoP are managed by a Virtualisation Infrastructure Manager (VIM). NVFI-PoPs can also include SDN and non-SDN based network elements, which provides the programmable network interfaces that will provide the connectivity establishment and will support the VNF chaining within a NFVI PoP.
    • Satellite Baseband Gateway (SBG) Physical Network Function (SBG-PNF). A SBG-PNF hosts the non-virtualised part of the satellite baseband gateway and is directly connected to the ODUs for satellite signal transmission/reception.
    • Transport network between the several NFVI-PoPs (backhaul), between the NFVI-PoP where the VNFs are run and the location that hosts SBG-PNFs (fronthaul), and cross-domain interconnection links. Each transport network segment is managed by a WAN Infrastructure Manager (WIM), potentially including the SDN and non-SDN network control.
    • Satellite Terminals (STs), which provide the satellite connectivity and interworking between the satellite connection and a premises network on the terminal side. A lightweight NFVI-PoP can be co-located with the satellite terminal.
  • Virtualised Satellite network (VSN): The VSN is a satellite communications network in which most of its functions are supplied as VNFs running in one or several of the NFVI-PoPs of the physical network infrastructure. Several isolated VSNs can be deployed over the same physical network infrastructure. The non-virtualised functions of a VSN are provided through one or several SBG-PNFs, which could be dedicated to a given VSN or shared among several VSNs. The operation of each VSN could be delegated to the customer/tenant, acting as a satellite virtual network operator (SVNO). Each of the VSNs may be customized to the customer/tenant’s needs, including a variety of different network services running as VNFs (e.g. PEP, VPN, etc.).A detailed description of this building block is provided in Section 5.
  • Management components: This contains the set of functional entities needed for the provision and lifecycle management of the VSNs. In particular, VSNs can be instantiated, terminated, monitored, and modified (e.g. scaled up/down, VNFs added/removed, satellite carriers added/removed, etc.) through the following management entities:
    • NFV Manager. This is the entity responsible for the management of the VNFs that form part of the VSN, taking care of the instantiation, the dimensioning and the termination of the VNFs. The NFV manager receives appropriate commands from Service Orchestrator (SO), which include the Network Service (NS) descriptors. The NFV Manager maintains a complete view of the whole virtualization infrastructure of the domain; it keeps a record of installed and available resources, as well as of the infrastructure topology. For scalability, the NFV Manager maintains only a high-level view of the resources and the services, while the detailed mapping of services to resources is undertaken by the local managers of each NFVI-PoP (e.g. Virtual Infrastructure Manager - VIM).
    • Service Orchestrator (SO). The role of the Service Orchestrator (SO) within the VITAL architecture, is mainly to provide service composition and to provide support for the OSS/BSS functionalities independently of the nature of the service (virtualised or not). Regarding the service composition, the SO decides, for example, on the capabilities and the composition (VNFs and PNFs configuration) of the VSN. On the other hand, regarding the OSS/BSS functionality support, this means that the SO will provide support for the FCAPS functionalities of VSNs. The SO which normally closely interacts with (or ideally is integrated in) the SNO’s OSS/BSS, which may include other components such as dashboards/customer portals that the customers of the SNO can use to order the provisioning of VSNs and related SLA management.
    • Federation Network Resource Manager (FNRM). This element is in charge of multi-domain service orchestration. It consists of two separate components:  a Federation Manager (FM) and a Federation Agent (FA). The FM hosts the logic to federate different domains and orchestrating Multi-Domain Network Services (MD-NSs). It is assumed that each domain is (usually) capable to orchestrate its own intra-domain NSs. Indeed, the FM acts as a super-orchestrator, having an overall view of the underlying orchestrators and domains. On the other hand, the FA is a component intended to handle the heterogeneity of the various underlying orchestrators and management entities of each domain, interfacing them with the FM. In addition to the FM and FA, a dashboard/customer portal is included as part of the FNRM to perform MD-NSs deployment, instantiation and orchestration.
    • SBG-PNF Controller (SBGC). The SBGC manages the pool of SGB-PNFs. Through the SBGC, the SO can request the allocation of SGB-PNFs resources (e.g. forward/return channels) for a given VSN. To that end, the SBGC is in charge of slicing the resources of the SBG-PNF so that a logically isolated portion of those resources is allocated to a particular VSN. In addition, the SBGC may provide a SDN abstraction of the allocated resources so that control and management of these resources can be integrated within the VSN.

The main reference points between the above components of the system architecture are outlined in the table below.


# Interface Definition Input/output south/north
1 SO-NFVM Related to NSD instantiation/orchestration (through the NFV Manager) SO / NFV Manager
2 SO-SBGC Reference point related to the orchestration of the VNS for the part related to the SBG physical functions SO / SBG-PNF controller
3 SO-VSN Reference point supporting the OSS/BSS functionalities of the VSN. SO / EM of deployed VNFs
4 SBGC-VSN a reference point between the SBG-PNF Controller and the control apps and/or SDN controller within each VSN  
5 SBGC-SBG    
6 Ve-Vnfm-em a reference point between EM and VNFM  
7 Ve-Vnfm-vnf a reference point between VNF and VNFM  
8 Nf-Vi a reference point between NFVI and VIM  
9 Or-Vi a reference point between NFVO and VIM  
10 Vi-Vnfm a reference point between VIM and VNFM  
11 xD-FA-SO a reference point for the interaction of SO entities into the Federator Federation Agent / Service Orchestrator
12 xD-C&N-itf a generic reference point between control applications and SDN controllers across different domains for multi-domain SDN-based control and management  
13 xD-FM-FA Reference point starting from the Federation Manager in order to deploy/manage multi-domain network services Federation Manager / Federation Agent


A detailed description of each of the VITAL system architecture building blocks is provided separately in the deliverable D2.3,

further detailing the functional elements within each block and the reference points among the different elements.