Introduction

Network Slicing [1] is about spawning multiple virtual and lightweight but, at the same time, full-blown telecommunication networks called Network Slice Instances (NSI) and their logical parts called Network Slice Subnet Instances (NSSI). The main goal of allocating NSIs/NSSIs by the Network Operators (NOP) is to guarantee Quality of Service (QoS) catered to specific requirements of various Services that shall be supported in the 5G and future 6G networks. The types of such envisioned Services include, but are not limited to: enhanced Mobile Broadband (eMBB), massive Internet of Things (mIoT), Ultra-Reliable Low-Latency Communication (URLLC), Vehicle-to-Everything (V2X), etc. [2], [3]. According to the original visions, NSIs/NSSIs should be possible to be allocated on-demand, in potentially massive quantities and for various durations of operation (permanent, short-lived, cyclic). At the highest technological maturity, the Network Slicing solutions are expected to enable dynamic management of 100s or even 1000s of NSIs/NSSIs, reaching a state in which each single Service utilizes dedicated NSI/NSSIs supporting its operation.

However, before a given NSI/NSSI can be allocated in the NOP’s premises, it needs to be appropriately designed to guarantee satisfaction of the QoS expectations specified by the Customer ordering NSI/NSSI from the NOP. Such requirements are specified in the form of high-level, and in many cases, abstract Service-Level Agreement (SLA) or more technically-oriented Service-Level Specification (SLS) statements that may pertain to, for example, the end-to-end latency threshold, mean throughput to be offered, count and density of devices to be supported, etc. Designing each single NSI/NSSI is about deciding on a range of complex technical details that are prerequisites for its provisioning and operation in the NOP’s infrastructure allowing satisfaction of the posed SLA/SLS requirements. The design details include: deciding on the structure and topology of NSI/NSSI’s internal building blocks, deciding on the fraction of their resources to be devoted for supporting appropriate operation of the currently designed NSI/NSSI (taking into account the already allocated ones), planning their optimized deployment in the cloud runtime environments, operational configurations, defining the end-to-end QoS assurance policies, etc. The design process is an essential stage of the NSI/NSSI lifecycle, performed during the preparation phase, as schematically depicted in Figure 1.

Figure 1.High-level organization of the NSI/NSSI allocation process involving manual design process.

According to the currently prevailing, traditional approaches, the design process is performed manually or in an assisted manner by a human Operator – an expert possessing the necessary domain knowledge and operational experience allowing appropriate interpretation of the Customer’s SLA/SLS requirements and their translation into a detailed technical specification of NSI/NSSIs capable of fulfilling such demands.

However, Network Slicing orchestration involving a non-automated design process is insufficient to satisfy the hopes placed in this technology mentioned earlier – in particular, regarding the flexibility and dynamicity of NSIs/NSSIs creation, scale of orchestrated deployments and, consequently, their widespread availability for the Customers in large quantities. It is because making the design decisions by a human Operator is a highly complex, potentially lengthy and error-prone process, complication of which increases with the scale of operated environments and the growing count of orchestrated NSIs/NSSIs. As such, fast handling of the incoming allocation requests in a manual or assisted manner is difficult, making the on-demand allocation of NSIs/NSSIs, even in small quantities, largely infeasible. Moreover, the operational expenditures (OPEX) of allocating NSIs/NSSIs involving their manual design are high.

Targeted area

In order to address the mentioned concerns, an alternative approach of NSIs/NSSIs allocation is promoted by the recently emerging trend of declarative style telco networks management and orchestration [4]. According to the declarative style principles, the NOP’s orchestration system should expose an Application Programming Interface (API) that allows to declare what final effect shall be achieved (e.g. a running NSI and its constituting NSSIs that satisfy a given set of QoS requirements), without the need of specifying how to achieve it on the technical level – it is the orchestration’s system responsibility to automatically devise a way to satisfy such request and apply it in the orchestrated environment. What is more, in the declarative style, the Customers may be allowed to trigger NSI/NSSI allocation by themselves, by interacting directly with the NOP’s orchestration system in a programmatic manner.

The declarative style is enforced, for example, by the signatures of the allocateNsi and allocateNssi operations [5] that shall be exposed in the API of standards-compliant orchestration systems utilized by the NOPs, as schematically depicted in Figure 2. The arguments to these operations are single ServiceProfile/SliceProfile data structures [6], which only convey high-level SLS requirements to be satisfied by the allocated NSI/NSSI, without providing any low-level details related to their technical realization.

Figure 2.High-level overview of the Network Slice/Subnet allocation according to the declarative style. Red badges indicate the challenges addressed in our tutorial: organization of the design process enabling its automation (A) and its outcomes (B).

Declarative style APIs make ordering NSIs/NSSIs very easy and convenient from the Customers’ perspective, not requiring any low-level telco domain knowledge to trigger their allocation. However, practical realization of the declarative style APIs is challenging for the NOPs due to a number of technical and organizational factors.

First of all, making the design decisions requires expert domain knowledge, allowing for proper interpretation and translation of the high-level, Service-oriented SLS statements into a technical design-time description of an NSI/NSSI capable of meeting those requirements. Secondly, to support the key Slicing virtues, namely shareability and reuse of resources, the NSIs/NSSIs delivered to the Customers need to either be reused or be designed from a mixture of existing internal elements (if additional load may be still handled by them) and the ones to be newly spawned. Determining which of such elements to use to satisfy Customers’ expectations requires continuous tracking and planning of their SLS fulfillment and supervision of their QoS satisfaction capabilities. Finally, orchestration systems supporting declarative NBIs need to be prepared for prompt and dynamic handling of NSI/NSSI allocation requests that can be triggered by the Customers spontaneously. Hence, their timely handling is important to enable on-demand NSIs/NSSIs delivery, which excludes any manual steps in the allocation process. To embrace all this complexity and fully adhere to the declarative style allocation, appropriate models and methods enabling automated design of a suitable NSI/NSSI need to be devised and implemented inside of the NOP’s orchestration system.

The currently available standard specifications, however, besides dictating the signatures of the aforementioned, declarative operations [5], do not cover the mentioned design-time challenges. More specifically, the standards do not specify any design-time models (only runtime models are specified in [6]), making it unclear what information should be contained in a design-time description of an NSI/NSSI before its commissioning. It is also unspecified in what form should such a description be conveyed (see Figure 1, badge B). Furthermore, there is no specification of any design-time procedures that would transform the high-level SLS statements into a design-time description of an NSI/NSSI capable of fulfilling them (Figure 1, badge A). Due to these gaps in standardization, it is unclear how to organize a Slice/Subnet design process that would be aligned with the standardized, declarative allocation APIs. Also outside of standardization, among the state-of-the-art research, we observe the lack of common, acclaimed and vendor-agnostic guidelines that would clarify these crucial design-time issues in a generic, holistic and, preferably, standard-aligned manner.

We contribute to fill in this void with original concepts and systematizations that complement the up-to-date standards with a comprehensive elaboration of the Network Slicing design-time aspects. In our paper, we deliver a broad study of the evolution of Network Slice/Subnet provisioning approaches and offering modes, explaining their impact on the design phase. Next, we provide a generic taxonomy of building blocks out of which an NSI/NSSI may be designed, followed by proposing precise definitions of the design process and its expected outcomes. Then, by elaborating on those definitions, we explain, in a technology-agnostic manner, the activities comprising the design process and the results it shall produce. Based on these fundamentals, we describe the opportunities for automating the design process, essential to support the declarative provisioning style and to offer the “dynamic slicing” capabilities by the Slicing orchestrators. Moreover, throughout the tutorial, we provide numerous recommendations that allow to avoid pitfalls in the developed solutions. All of the elaborated systematizations and concepts are vendor-agnostic and fully standards-aligned which makes them practically usable in a wide range of Network Slicing orchestration solutions.

Paper info

The detailed elaboration of the outlined area can be found in our recent paper published in the second issue of the IEEE Communications Surveys and Tutorials (IEEE COMST) in 2024, available under the following links: https://doi.org/10.1109/COMST.2023.3341249 or https://ieeexplore.ieee.org/document/10375939. The study is an outcome of a collaboration between the researchers from the Samsung R&D Institute Poland and from the Faculty of Computer Science of the AGH University of Krakow, Poland.

It is worth noting that IEEE COMST is a highly prestigious academic journal, currently exhibiting the highest Impact Factor (IF) value in the world in the field of telecommunications (IF=34,5) and top 3 value in the field of computer science. Below, a quote by Dusit Niyato (Editor-in-Chief of IEEE COMST) about the merits of our paper is provided [7]:

“The complexity of designing and managing network slices in a standards-compliant manner remains a significant challenge, especially with the move towards automated systems and dynamic provisioning. In this context, this paper provides an exhaustive guide that addresses these challenges. It meticulously outlines the standardized design process for network slice and subnets, integrating a systematic approach with opportunities for automation. This tutorial not only navigates through the complexities of network slice design but also enhances understanding by linking theoretical aspects with practical implementation strategies. The authors delve into various design considerations including the structuring and topology of network slices, operational configurations, and the integration of service-level agreements into the technical framework. They also explore the automation of these processes, essential for supporting dynamic slicing capabilities necessary for future network deployments. This article is particularly invaluable for its comprehensive coverage and practical insights, making it a crucial resource for professionals involved in network management and orchestration within the rapidly evolving landscape of telecommunications.”

Citation information:
P. Wyszkowski, J. Kienig, K. Zieliński, Ł. Czekierda and M. Zawadzki, "Comprehensive Tutorial on the Organization of a Standards-Aligned Network Slice/Subnet Design Process and Opportunities for Its Automation," in IEEE Communications Surveys & Tutorials, vol. 26, no. 2, pp. 1386-1445, Secondquarter 2024, doi: 10.1109/COMST.2023.3341249