The three ontologies shown in Figure 1 have been defined to extend the current notion of Network Slicing, whose classes and properties are based on the common taxonomy proposed by the NGMN Alliance (described in click here) and the suggestions provided by Riegel in click here on network instantiation. To the best of our knowledge, the ontology-based formal models presented here are the first ones proposed in the literature.

All these ontologies are detailed in the next Network Slice Ontologies block, from where can also be downloaded.

The Network Slice Blueprint Ontology (shown at the bottom left of Figure 1) focuses on the definition of the different components making up the Network Slicing concept, which are oriented to ensure the provisioning of heterogeneous services. The main class of this ontology is NetworkSlice that represents the instantiation of every element contained by the Network Slice Blueprint Ontology. A given Network Slice has specific requirements, represented by the Requirement class, which are accomplished by one or more Sub-networks being responsible for the provisioning of services. They are maintained by service providers, represented by the Provider class. The Service class is relevant because links all the concepts that describe the services being offered to users. Providers could be a Network Operator or a Third Party, although this class could be extended to other types of providers. Finally, the User class represents people consuming the service (or services) ensured by the Network Slice.

On the other hand, the Sub-network Blueprint Ontology (shown at the bottom right of Figure 1) is able to create sub-networks to form one or more Network Slices. The Sub-network class is the main concept of this ontology and it can be comprised by other sub-networks. A Sub-network has one or more Network Functions running on top of the Physical/Virtual Resources, either physical or virtual such as Physical Network Functions (PNF) or Virtual Network Function (VNF), respectively. The NetworkFunction class includes every kind of resource that can be used or deployed within a given IT infrastructure, which can be related to computation, storage, or networking, for example. A given Sub-network represents a way of reusing a combination of fundamental Network Functions that provide similar features being shared by different Network Slices. The combination of all this information represents a Sub-network Blueprint, which is a type of template of how to deploy a Sub-network that meets the Network Slice requirements.

Finally, the Network Slice Management Ontology (shown at the top of Figure 1) aims to manage the dynamism of the critical components represented by the NetworkSlice, Service, Sub-network, and NetworkFunction classes defined in the two previous ontologies, all of them being instances of the ManagedElement main class. It is worth noting that all these elements included in the three ontologies have been modeled by following the Common Information Model (CIM) language, formally defined by the DMTF as a standard. CIM provides a common definition of management information for systems, networks, applications, and services. As a consequence, all these elements are defined as instances of the ManagedElement class, which is the main element for a given model in CIM.

The ManagedElement class identifies a generic entity that has some features, represented by the Metric, Location, and Capability classes. The Metric class refers to any indicator useful so as to measure the performance of the Network Slices and their elements. For example, this indicator can refer to Quality of Service (QoS) values in case the managed entity is a service. As a proof of concept, we defined four different metrics: CPUEff indicating the percentage of CPU used by the managed elements; CommLat denoting the latency experienced by the communications; PktLossFreq (packet loss frequency) pointing out the availability and QoS of the Network Slices communications; and ProvTime reflecting the time required to provide a given service or Network Slice. On the other hand, the Location class shows information about the position in the environment concerned. In addition, as depicted in the figure, the Capability class includes other subclasses such as PowerSettings and Mobility, among others. While the former enables the optimization of energy efficiency, the latter has a key role when services are provided in highly dynamic environments.

The complete definition of the Network Slice ontologies, including the three ontologies shown in Figure 1, can be downloaded below.

The automation of the provisioning of innovative services needs to rely on an agile architecture able to adapt to a highly dynamic context. This architecture to manage the Network Slices is shown in Figure 2, whose elements has been developed starting from the ETSI reference model and on which we included the necessary functionality to meet the different requirements established by the scenario concerned by means of the Network Slicing paradigm. The elements represented on a blue background correspond to the ETSI reference model, while the orange ones is the new contribution to highlight the way of managing the Network Slices and their resources dynamically with a policy-based approach.

The Virtualized Infrastructure Manager (VIM) is responsible for the Network Functions Virtualization Infrastructure (NFVI) management and the resource monitoring. The VIM is able to create, control, monitor, and dismantle the whole life cycle of Virtual Machines (VM) that are instantiated on generic Physical Resources or equipment making up the Network Slices through the Virtualization Sublayer. Physical and Virtual Resources can range from computation and storage elements to SDN-oriented network infrastructure such as virtual switches and SDN Controllers so as to decouple data and control planes.

The Virtual Network Function Manager (VNFM) is in charge of the configuration, management, and monitoring of all the VNFs that make up the Network Slices. This manager is able to deploy, dismantle, and configure VNFs on-demand with the functionality provided by the Network Slices. The VNFs run on top of the VMs that are deployed in the NFVI. On the other hand, the SDN paradigm has the ability to decouple the data plane, where forwarding elements are located, from the control plane, where routing decisions are made. The control element is called SDN Controller, which manages multiple network elements belonging to the data plane. The SDN Controller allows the architecture to control in real time the network communications between the elements of the Network Slices with the goal of ensuring aspects such as security, privacy, QoS, etc.

The Orchestrator automatizes the management of the aforementioned elements. This component communicates with the VIM, the VNFM, and the SDN Controller to schedule their tasks as well as to receive information about the state of the scenario, thus updating its catalogs. Finally, the Orchestrator is linked to the Operations Support System/Business Support System (OSS/BSS) that serves the customer services.

As a special element in the architecture of Figure 2, which can be considered as an extension to the ETSI reference model, the Network Slice Management (NSMan) component includes several elements that directly deal with the life cycle of the Network Slices. The Automation Policy Engine is the component in charge of making decisions about the management of the Network Slices. This manages intra- or inter-actions taken into account the policies defined by the network administrator as well as the Network Slice context information and the location of the resources, which are considered by our architecture to control the Network Slices and their resources dynamically. The decisions made by the Automation Policy Engine are processed and automated by the Orchestrator, which we empower with innovative features. In fact, it becomes responsible for the automation of the processes related to the Network Slices management based on the outcomes chosen by the Automation Policy Engine. Specifically, once an intra- or inter-slice policy is triggered by the Automation Policy Engine the Orchestrator communicates with the Network Slice Manager to perform the corrective measures to the given Network Slice. This manager manages the different Network Slices and Sub-networks and it monitors their state.