October 16, 2023
In a few days, the curtain will rise and the Software Development Group OpenSlice (SDG OSL), proudly backed by the European Telecommunications Standards Institute (ETSI), will make its grand debut. But before we dive into the details of this eagerly awaited kickoff, let’s take a moment to get acquainted with OpenSlice or in short OSL. So, what exactly is OpenSlice? OpenSlice is an open source, service-based Operations Support System (OSS) prototype for delivering Network Slice as a Service (NSaaS) and more widely, Network as a Service (NaaS) following specifications from main Standards Development Organizations (SDOs), including ETSI, TM Forum, GSMA, and 3GPP.
The first “code seeds” of OpenSlice started back in 2018 with the European project 5GinFIRE. However, It only became OpenSlice later on, when it was further developed and matured in the context of EU funded project 5G-VINNI (now completed). Since then, it has been adopted and received contributions from several other research projects. With its recent establishment as an ETSI SDG, OpenSlice aims to complement future network activities at ETSI (NFV, ZSM, OSM, TFS) by enabling prototyping, experimentation and validation of complex telco use cases. Within OSL we expect that early and regular feedback to standardization groups will contribute to higher quality standards and faster time to market.
Following the Anything-as-a-Service (XaaS) paradigm, strong attention has been drawn to the Network Slice-as- a-Service (NSaaS) model and in general NaaS Network as- a-Service (NaaS). NaaS is more of a business- oriented concept than a technological one, allowing on one side to automatically map service demands from a customer to functionalities, topology, policies, and parameters of a network slice, as well as to provide component-based and auto-configured network functionalities for operators to design and launch network services in a more convenient manner. Examples of NaaS models include the Generic Slice Template (GST) as defined by GSMA or the recent efforts of the Open Gateway initiative.
Moreover, one of the cornerstones of NaaS is network functions virtualization (NFV). ETSI NFV has defined an architectural framework, where the NFV technology contains the general-purpose processor platform, the cloud operating system, the hypervisor, distributed computing, and the software of network elements. It decouples software and hardware and shields the hardware details for virtual network functions (VNFs). More specifically, there is a management and orchestration (MANO) component, which controls the lifecycle of VNFs, as well as the connectivity among them. A customer orders a network slice from the OSS/BSS platform and that order is then passed onto the MANO platform to enable the brokering of NFV resources.
Thus, while models and APIs from GSMA (Generic Slice Template, Open Gateway initiative) and TMF ODA deal with the exposure and management of the network services, the NFV, 3GPP, IETF, ONF, O-RAN and Cloud Native models and APIs deal with the service realization. The goal is to deliver end-to-end network services to customers/consumers upon request while ensuring reproducibility and interoperability by incorporating the guidelines form telecom industry organizations, and the normative specifications from standards bodies.
Inline with the paradigms described in the previous sections, OpenSlice was designed and implemented following a service-based architecture following well-known standards to deliver Network Slices as Services. Figure 1 depicts how OpenSlice is positioned in the ETSI NFV architecture.
Figure 2 depicts how OpenSlice implements the NaaS Instantiation for the delivery of an E2E service, i.e. from radio to the core, involving Virtual and/or Physical Network Functions. There are three main phases during the instantiation, namely Service Ordering, Fulfillment, and Operation.
1) Service Ordering
It is assumed that Service Ordering is initiated from a 5G Vertical (a Network Service Customer), by ordering specific Service Specifications that are related to Network Services. These Service Specifications are located in a Service Catalog owned by the provider. Both Service Specification and Catalog follow the model described in TMF 633, which describes artifacts (e.g. models and dependencies) for the specification of Services. There are two types of Service Specifications: Customer Facing Services (CFS) and Resource Facing Services (RFS). CFSs are exposed through the catalog so users can order them. RFSs are internal and related to the underlying resources. Assuming these service specifications follow the GST model, the derived NEtwork Slice Types (NEST) are modeled as TMF Service Specifications. Thus, the Customer requests the Service Specification and creates a Service Order. Service Orders are modeled with the Service Ordering API (TMF 641), and include the selected Service Specifications as well as the instantiation parameters (e.g. Network Slice region, QoS, Number of UEs, etc.).
2) Service Fulfillment
The Service Fulfillment phase begins when the customer triggers a Service Order from the Service Catalog. In the Service Order, the customer provides a completed specification of the slice instance he wants, including information on slice topology (possibly extended with 3rd party VNFs) and slice attributes (filled in with values fitting use case requirements). To do that, the customer makes use of the Service Ordering API. The issued Service Order is then captured by the Service Order Management (SOM), which propagates it towards the corresponding g Service Orchestrator(s) again via TMF 641 API calls. Next, the Service Order is processed.
This processing consists in translating the received Service Order (CFS, handled by the Service Orchestrator) into a set of resource requirements for the network slice to be instantiated (RFS, handled by the NFVO). To successfully achieve this translation, the Service Orchestrator and NFVO exchange information through the ETSI NFV-SOL005 APIs. Once this translation is completed, the NFVO allocates the resources required by the slice instance, instructing the VIM for that end. In general, OpenSlice follows the 3GPP lifecycle management of a Network Slice instance as depicted in the next image, complemented with some additional points that help the service designer to affect the service provisioning:
At this stage we have the E2E Network Service running, potentially involving Radio, Core, Transport or any other desired Function (e.g. a firewall).
3) Slice Operation
TM Forum OpenAPIs allow customers not only to interact with the service catalog but also to consume the exposed capabilities. In the slice operation phase, the slice is already instantiated, and can be made available for operation. During this phase, the customer keeps track of the status of the slice instance, making use of the Service Inventory API (TMF 638), which defines standardized mechanisms for CRUD operations over the records, providing run-time information about deployed slice instances.
OpenSlice usage examples
OpenSlice has played a key role in several EU research activities, enabling multiple use cases of growing complexity, as we will see in the examples below.
5GinFIRE project
In the EU funded project 5GinFIRE (2017 - 2019), the first code seeds of what would later become OpenSlice were developed for exposing services in a multi-VIM environment. At this stage, the goal was to offer reproducible Network Service deployments in different geographically located infrastructures. A portal was developed to enable the simultaneous deployment of several services and functions in different locations while keeping the NFV artifacts (NS, VNFs) synchronized across them.
5G-VINNI project
In 5G-VINNI (2018-2021) the main challenge was to deploy 5G services on multiple sites in a Multi-vendor environment with commercial and opensource solutions. For that purpose, the TM FORUM models and APIs were incorporated and the OpenSlice name was adopted.
5GASP project
In the context of 5GASP project (2021 - 2023), OpenSlice supports a multi-site CI/CD DevOps cycle for Network Applications enabled by reproducible network service deployments. For this purpose, OpenSlice supports multiple NFVOs. Also, Service Test models as well as Product models are introduced to enable a network application marketplace.
As an ETSI SDG, OpenSlice will aim to further support 5G/6G research and network services, while developing standards alignment and providing regular feedback to standardization activities.
Now that we are familiar with the story behind OpenSlice, in future posts we will deep dive into its architecture and capabilities. Stay tuned!
