PDF  PubReader

Kuklińnski , Tomaszewski , Kołakowski , and Chemouil: 6G-LEGO: A Framework for 6G Network Slices

Sławomir Kuklińnski , Lechosław Tomaszewski , Robert Kołakowski and Prosper Chemouil

6G-LEGO: A Framework for 6G Network Slices

Abstract: Abstract—Network slicing is a relatively recent paradigm that has become a subject of intensive research. Most of the existing approaches follow the ETSI NFV MANO model with some extensions related to multi-domain slicing, slice selection, etc. The framework is a part of the standalone variant of the 5G network standardized by 3GPP. However, the current implementation of network slicing in 5G has several limitations, especially regarding management and orchestration: The isolation of slice management is not appropriately addressed, the slice tenant management capabilities are limited, and the management and orchestration centralization raises serious scalability and reliability issues. Moreover, the slice-level operations are not well-separated from other processes due to a lack of proper separation of concerns. As a result, the overall network slicing architecture has complex interactions with many components of the 5G network. In this paper, we describe a new framework that uses an approach to sustain self-managed and self-orchestrated slices. To that end, we propose a modular architecture in which slices have embedded (in-slice) management and orchestration support, and multi-domain slices rely on multiple slice-agnostic orchestrators. The framework enables the composition of new slices as a combination of single domain-slices in a relatively easy, technology-independent manner.

Keywords: index terms—management , network slicing , nfv mano , orchestration , 5G , 6G


FOLLOWING the initial commercial deployments of 5G networks, both industry and academic entities have begun the work on the architecture, capabilities and requirements of 6G mobile networks. The 6G vision assumes deep incorporation of artificial intelligence (AI) in the network resulting in a transition from “connected things” to “connected intelligence”, and provision of global and instant connectivity [1] to a much larger number of devices than in the previous generation. The first 6G flagship project (6Genesis [2]), which is focused on the establishment of 6G targets based on market trends and the latest technological advances, has already started. So far, the key features of 6G include data rates up to 1 Tbps, trusted global and instant connectivity, latency below 1 ms in the control plane and below 0.1 ms in the user plane, very high downlink spectral efficiency (100 bps/Hz), as well as operation in sub-THz and THz bands. 6G networks should provide widely-accessible broadband, global network coverage by the integration of terrestrial and satellite systems, supporting lowenergy, battery-free IoT devices [1], [3]–[6].

The network slicing concept, leveraging virtualization techniques that allows for the creation of multiple, logicallyisolated network instances over a shared infrastructure, will be exploited in future 6G networks. The benefits of network slicing include the ability to customize slices to their service(s), the on-demand deployment of slices, and the delegation of slice management (partially or fully) to slice tenants. The economical aspect of infrastructure mutualization and multitenancy is also positive, since the capital expenditures associated with the creation of a single network slice and further operational costs should be lowered in comparison to the classical cases.

At present, most network slicing concepts, including the 3GPP one, consider a centralized management and orchestration approach defined by ETSI network functions virtualization (NFV) management and orchestration (MANO) framework [7]. In ETSI NFV, a network slice is simply considered as an NFV network service (NS), among others. The MANO framework is responsible for analysing the abstracted description of a slice, for providing optimal placement of slice virtual functions within the infrastructure, and for the dynamic allocation of resources to slices during their run-time. The 3GPP has defined for 5G networks a set of mechanisms and protocols that support network slicing operations like slice selection and attachment. The 3GPP approach, which is discussed in more details in Section II, has many limitations, e.g., it provides no separation of the management plane of slices, and it is significantly complex to implement. Its inclusion has an impact on multiple components and protocols of the 5G network architecture, while the centralization of slice management and orchestration functions raises significant scalability concerns. It is worth noting that this concept has never been commercially deployed yet.

The 6G-LEGO concept presented in the paper aims at solving some above-mentioned limitations of 5G network slicing. It provides a clear separation of management planes of deployed network slice instances (NSIs). To that end, each NSI has its own management as well as “in-slice” mechanisms of users’ authentication. Moreover, it allows for the creation of sub-network slices per domain, and their concatenation in order to obtain an end-to-end slice or to add services to slices. To efficiently achieve that goal, 6G-LEGO subnetwork (i.e., single domain) slices are self-contained and self-described. Due to the proposed separation of concerns, the interactions between functional blocks of the architecture are minimized. The structure of the paper is as follows. The existing concepts, relevant standardization efforts and research projects are presented in Section II. Section III is devoted to requirements and implementation options that drive our work. In Section IV, the proposed framework for distributed management and orchestration of slices for beyond 5G networks is described. Section V addresses some implementation remarks. Finally, Section VI summarizes our contribution and provides some research directions.


Network slicing is based on the widely cited approach of NGMN [8] where NSIs are built over a shared infrastructure composed of fully or partially isolated physical or logical resources (computation, storage and transport). NSIs are instantiated according to their templates as logical networks customized for the need of a specific service or a set of services. According to NGMN, the end-to-end NSI can be created as a concatenation of sub-network slice instances. The end-users’ services are external to NSIs, and the interactions with services can occur via application programming interfaces (APIs) exposed by NSIs. Such a separation of NSI and services implies NSI-independent lifecycle management of services. The NGMN concept has been adopted by ETSI in the NFV framework [9] and by the 3GPP 5G system (5GS) [10].

The ETSI NFV framework enables the dynamic deployment of network functions as software-only entities (termed as virtualized network functions, VNFs), abstracted from the underlying hardware, and is intended for telco-oriented implementation of softwarized communication networks. The ETSI NFV MANO [11] is responsible for the lifecycle management and dynamic resource allocation to network services (i.e., network slices in ETSI terminology) that are implemented as a set of interconnected VNFs. The NFV framework is VNF functionality agnostic and provides no specific support for network slicing except the “priority” parameter of network service deployment elavour for resource shortage conflict resolution [12]. The operations/business support system (OSS/BSS) that is placed atop of the MANO stack plays a key role in the whole ETSI NFV picture. It is responsible for run-time slice management. However, the functionality of OSS/BSS had not been defined by ETSI till NFV Release 3. This release [7] has introduced slice-related management functions of OSS/BSS (at the levels of communication service, network and sub-network slice) identically to the 3GPP vision [13]. Moreover, the OSS/BSS handles user subscriptions, performs the policy-based management of slices and services, provides key performance indicators (KPIs) monitoring for service level agreement (SLA) fulfilment, collects accounting data, etc.

The concept of network slicing, however, requires more mechanisms than those currently defined by NGMN or within NFV MANO. The gaps include mechanisms for slice description, slice selection and matching, interactions between the slice provider and slice tenants, to mention a few. Some of them can be also specific to the networking technology, e.g. the radio access network (RAN). Several of the mentioned issues have been solved by 3GPP, others are handled by the ITU-T study group 13, which has already published some recommendations [14]–[16].

Another facilitation of network slicing has been proposed by GSMA in [17] where the concept of generic network slice template (GST) has been introduced. It aims at simplifying the interaction between network slice customers and providers. In general, GST is a high-level template with a set of all potential attributes to characterize a network slice. Based on the specific use-case (service) requirements, GST is parametrized with attribute values and becomes a network slice type (NEST). The latter helps the operators to define how (sub-)network slices should be instantiated. For the most common use cases, standardized NESTs (S-NESTs) have been specified and made publicly available for inter-operability [17].

The 5G network slicing approach [10] proposed by 3GPP follows the NGMN and ETSI NFV concepts. It allows the user to be attached to up to 8 slices simultaneously [18]. The user plane function (UPF) chain may be considered as a “dedicated user plane”. The control plane, based on servicebase architecture (SBA), supports a flexible extension of the control plane but has also components that support network slicing-related operations.

The 5GS exposes the control plane services to external systems via the network exposure function (NEF) [10], [19]. The network slice selection function [10], [20] plays an important role in the support of network slicing by assisting with the selection of the NSIs that will serve a particular user equipment UE. Another key function related to network slicing is the network slice-specific authentication and authorization function (NSSAAF), which provides assistance to the access and mobility management function (AMF) in the verification of UE’s rights to attach to a specific slice. The procedure is executed during the UE registration and is performed by means of the extensible authentication protocol [10], [21], [22]. Network slicing support is also provided by the session management function (SMF), which selects the appropriate UPF based on the single-network slice selection assistance information (S-NSSAI). The 5GS signalling procedures, e.g. admission control, handover, session management, are slice aware. Enhancements for RAN slicing have been studied [23]. The 3GPP approach to 5GS orchestration and management [24]– [26] supports network slicing (at the level of network function, sub-network slice, network slice and communication service management), referring to ETSI NFV mechanisms, except for slice selection and authentication mechanisms. The 3GPP management system architecture is complementary to the ETSI NFV MANO stack [23]. It allows the slice operator (tenant) to obtain selected management data and to subscribe to slice management operations [24].

Network slicing is also a subject of intensive research because there are still many unsolved problems concerning the scalability of management and orchestration of slices, slice selection and matching mechanisms, different ways and levels of isolation of slices, efficient slicing of the user plane, and multi-domain slicing [27], [28].

Within the 5G PPP H2020 research program of the European Union, several projects have been focusing on network slicing. They all consider NFV and software-defined networking (SDN) as enabling technologies. Project 5G NORMA [29] assumed that some control plane functions could be shared by multiple slices. The 5GEx project [30] was focused on multi-provider networks. It mainly targeted the multi-domain slicing by extending the ETSI NFV MANO framework towards peer-to-peer cross-domain orchestration and management. The 5G PPP 5G-transformer project [31] proposed a vertical slicer composed of the network slice manager (as part of OSS/BSS) and the service orchestrator, both acting at service and resource levels and providing a single and unified view of multiple underlying infrastructure domains with their managers.

In [32], the relations between the slice tenants and the slice providers have been outlined. In this paper, slices are split into two main categories. One is an “internal” category that is fully operated by the slice provider, whereas the other one includes slices offered to slice tenants (so-called “external slices”). In the latter case, the slice management can be performed by the tenant or by the slice provider. In [33], it has been proposed a multi-domain orchestration architecture for network slicing that has introduced the multi-domain service conductor, which provides service management across federated domains orchestrated by local orchestrators. Another entity of the architecture, the cross-domain coordinator, aligns cloud and networking resources across federated domains and accordingly carries out the lifecycle management (LCM) operations of a multi-domain slice configuring data transport. A similar approach to resource allocation on different network segments using a hierarchical orchestration scheme with per segment orchestrator has been presented in [34]. The endto- end orchestrator, called hyperstrator, coordinates the local orchestrators. The same concept is presented in [35]. Such a hierarchical approach is also exploited in the 6G-LEGO concept.

The architectural approach of the 5G!Pagoda project [36] serves as the basis for our work. This architecture allows for hierarchical orchestration, the tenants can directly manage their slices, and the management plane is a part of each slice [37]. Independent slicing of each plane (i.e., user, control and management planes) and recursive vertical stitching of them (further described in subsection IV-B2) are allowed. To that aim, the concept of a common slice, which consists of functions that can be used by any other slice, is introduced. Moreover, the entity called slice operation support (SOS) has been defined. The SOS is a part of the slice and handles slicelevel operations such as vertical or horizontal slice stitching (the operations are described in details in subsection IV-B), slice selection, matching or exposing an abstracted view of a slice. The approach described in our paper is an extension of this work. Therefore, more details concerning the components of the architecture, slice stitching and distributed run-time orchestration mechanisms are next provided.

Additional challenges about network slicing concepts can be found in surveys [28], [38]–[41]. The top-mentioned challenges of network slicing include scalability, arbitration of resources allocated to slices, multi-domain slicing, the definition of slice abstractions, and security.


In this section, we provide some critics related to the 5G approach to network slicing, and we also identify a list of features regarding network slicing in future mobile networks that are available or weakly supported in 5G. The analysis performed in this section will serve as a basis for the concept, which is further presented in Section IV.

A. 5G Network Slicing Shortcomings

The 3GPP approach to network slicing raises several concerns. They include:

· Centralized OSS/BSS issues. The fundamental principle of slice isolation should also include its management plane, as described in [42]. An OSS/BSS that is common for all the slices (i.e., the present ETSI and 3GPP approach) provides a very weak management plane of slices isolation and raises serious security issues. Moreover, the access of slice tenants to the operator’s OSS/BSS also raises many issues in terms of security, reliability and management performance. It has to be noted that in this approach, each deployed network slice requires dedicated counterparts in OSS/BSS (slice-specific run-time management plane) that are dynamically deployed in the OSS/BSS. The dynamic modification of the OSS/BSS is a new idea that may impact the performance as well as the security of the OSS/BSS. Additionally, such an operation is rather complicated since it has to be synchronized with slice deployment. This issue is currently ignored by 3GPP specifications.

· Single domain orchestration only. In the 3GPP network slicing approach, there exists a single OSS/BSS and MANO orchestrator that is used for the orchestration of the 5G core (5GC). RAN is, in fact, not orchestrated but provides RAN slices via APIs. An orchestration of other domains external to 5GS is impossible, e.g. the transport network that is used to connect customers or service providers whose servers are connected to a fixed network cannot be orchestrated. Moreover, there is no possibility to use multiple MANO orchestrators in 5GS. Such an approach may impact slice-related operations in countrywide mobile networks with multiple UPFs. In most cases, each technological domain requires a dedicated orchestrator as it has to interact with domain-specific operations or nodes, e.g., with physical network functions (PNFs). The interaction between multiple orchestrators is not defined in the 3GPP specifications.

· Reactive resource allocation. In the 3GPP concept, the resources required by a slice are allocated by the MANO orchestrator on the basis of their usage. Meanwhile, using sophisticated algorithms and information about the number of slice users, their location, their service requirements and the UE mobility, it is possible to predict the future resource consumption and proactively anticipate resource allocation. The lack of such mechanisms can cause inefficient resource utilization or slice KPI degradation. In order to support proactive resource allocation, an intelligent orchestration that exploits information from the control or application planes of a slice (e.g., from a car navigation system) needs to be deployed.

· Separated orchestration of network slices and their services. By definition, network slices are tailored for a specific service. Inclusion of the service functions into a slice provides multiple benefits, i.e., better servicenetwork cooperation, higher isolation and security. Using separated service platforms makes the overall system very complicated. A good example here is the integration of multi-access edge computing (MEC) and 5G network slicing, which raises security issues due to the fact that MEC Platform APIs are not slice aware. Moreover, several MEC and 5GC functions are overlapped (e.g., the authentication of users). Therefore, the integration of MEC with 5G network slices will need some adaptation of both solutions. A list of issues related to the integration of MEC and network slices can be found in [43], [44]. This topic is still a subject of discussion in standardization bodies. In fact, in most cases, adding services to serviceoriented slices during their run-time is not needed and can be avoided if the service platform is already included in the slice template.

· Complexity of the 3GPP solution. The approach to network slicing proposed by 3GPP is very complex in terms of functionalities of the system components, and their interactions use multiple protocols. Despite dedicated components for network slicing have been defined in 5GS, the other components of the architecture have also to be slice-aware. This is caused by a lack of a proper separation of concerns in the architecture, and as a result, the overall overhead to the network slicing seems to be unnecessarily huge.

· Lack of the tenants portal. The 3GPP has incorporated network slicing and described many related mechanisms, but within the 5GS management architecture, the definition of the tenants portal is missing. Such a portal is present in many research works and serves for interactions between tenants and the system operator for the purpose of network slice service exposure, negotiation, ordering, and lifecycle management [45]. Such an entity plays a crucial role in multi-tenant network slicing frameworks.

· Lack of the capability of the cooperation of the 5GS orchestrator with external orchestrators. The present solution cannot be used for the end-to-end orchestration of solutions in which the 5GS is only a part of the solution. It concerns, for example, the transport to remote servers and the deployment of virtual servers out of 5GS (such a use case is described in details in [33]).

B. New Functional Requirements

The developed network slicing solution should cover a variety of different aspects related to network slices and the services that are built on top of them, but also the operational relations between the network slice tenant and its provider, as well as the service provider itself. In that context, there exist several options for the implementation of slice orchestration and management. Other aspects such as isolation between slices, slice security, multi-domain slicing may also be taken into account, but in general, their specific implementations have no significant impact on the proposed framework. We can distinguish the following implementation variants:

· Service-related variants. Network slices can be created to support different types of services. In general, there are two options for the implementation of network slice services. In the first option, the network slice and the slice service platform form the same slice template. Such a type of slice has thus no interface to external service platforms. A slice template update mechanism can be used for the “immersive” orchestration of new services. In the second option, the services are external to a slice: Thus, there exists an interface between the slice and the external service platform. Each service is based on a service template and uses a service orchestrator for its deployment. The service deployment can be recursive in the sense that new services can be incrementally added to the slice.

· Slice tenant management variants. Network slices are created by the slice provider, using the MANO orchestrator typically, and in most cases, they are managed by the OSS/BSS of the provider. Meanwhile, there exist more options of slice management that depend on the slice type and the tenant’s management skills, as well as its business goals. When there is a lack of slice management by the slice tenant, the slice is managed by the slice provider. Such a case is typically applicable to relatively simple, short-lived slices or when the tenant delegates the slice management to the slice provider because of a lack of skills or interest in such activity. However, when the slice tenant has high-level slice management capabilities, he can make use of selected management functions in order to configure his slice (or services) and to monitor slice-related KPIs. In such a case, a tenant management interface has to be implemented. An ultimate case is the full slice management by its tenant. In this case, the tenant runs a fully-fledged management system that gives full control over his slice(s).

· Slice tenant orchestration variants. It is commonly assumed that the slice provider is responsible for the orchestration of slices and their services within. However, there are three cases in which slice tenants can be involved in slice or service orchestration. In the first one, the slice provider orchestrates slices and their services. In the second one, the slice provider orchestrates slices, but the slice tenant has the service orchestrator and orchestrates his services on top of his slice(s). In the last case, the slice tenant has the capability of slice and service orchestration. In this case, the slice tenant may become a slice provider that offers slices to its customers.

The requirements for management, orchestration and service implementation described in this section differ significantly from the capabilities currently available in ETSI NFV MANO, making problematic the direct use of the framework for network slicing as is. The present implementation of network slicing proposed by 3GPP for 5G is also not able to fulfil the mentioned requirements.


The different implementation options as well as the shortcomings of the current 3GPP approach to network slicing, as described in Section III, have been driving the development of the 6G-LEGO framework. The concept can be implemented in any type of networking solutions beyond 5G, and we see it as a candidate for 6G networks. Due to the fact that this concept considers slices as “bricks”, we have called it 6GLEGO. In order to do that efficiently, the term “slice” has been slightly redefined. In 6G-LEGO, a slice is a set of interconnected logical entities that are grouped for a specific purpose and are implemented using isolated resources. Such an extended meaning of slices enables the creation of not only the communication network but also the management or service platform in the form of a slice. Moreover, we are able to operate at the slice level by adding services to slices, etc. In contrast to the existing approaches, the framework defines the slice template as an object that is ready to be deployed with minimal external support.

The 6G-LEGO framework introduces the following novel features:

· We see the use of a common OSS/BSS for all slices as an obsolete approach inherited from hardware-based networking solutions that is raising scalability issues, provides weak isolation of slice management operations and requires OSS/BSS modifications. The added OSS/BSS functions should support the run-time management of each deployed slice instance. Instead, we propose that each slice has its management plane implemented as a part of the template, similarly to other planes of the slice. The local, in-slice OSS/BSS cooperates with a central (global) OSS/BSS to achieve the overall management goals. The in-slice OSS/BSS provides a management interface to the slice tenant that can be used for slice runtime management and for orchestration of additional slice functions. The local OSS/BSS is not generic, but it can be customized for a specific slice type (template). As it will be typically implemented using VNFs, its functionalities can be dynamically updated, providing that way management plane programmability. The in-slice OSS/BSS may interact with the MANO orchestrator in order to proactively allocate resources (based on QoS/QoE objectives) or to update the network slice template. The proposed feature increases the isolation between the slices and improves the overall system scalability as it reduces the interaction between the slice and the OSS/BSS. The role of the external (central) OSS/BSS system is significantly reduced, since it is now used mostly for the analysis of slice KPIs and accounting (a common practice of operators in current networks). The in-slice management (ISM) [45] concept simplifies the integration of a slice and makes the slice orchestrator slice agnostic. The slice template includes nearly all functionalities needed to run the slice. In the case of multi-domain slice management, a hierarchical approach is proposed in which the necessary inter-domain management functions are implemented as a set of VNFs that interacts with OSSes/BSSes of all singledomain (sub-network) slices (i.e., ISMs) that compose the end-to-end-slice.

· Due to the implementation of the in-slice OSS/BSS, the central OSS/BSS is slice agnostic and the orchestrator is focused mostly on resource-oriented operations. The orchestrator for the purpose of a specific slice can be driven by its in-slice OSS/BSS (ISM), allowing for the implementation of a proactive method (described earlier in the paper) of resource allocation. Such an approach improves the scalability of the orchestrator.

· The proposed definition of slices allows their concatenation in a horizontal and vertical way. The vertical slice concatenation corresponds to the attachment of services and management functions to slices of the same domain. The horizontal concatenation of sub-network slices can be used if the end-to-end slices are composed of multiple, single-domain slices. A sub-network slice is typically created in each technological or administrative domain. For concatenation of sub-network slices, the framework provides supporting functions, called slice operations support (SOS), that are part of each slice and are programmed during the end-to-end slice template preparation process.

· We propose a hierarchical end-to-end orchestration of slices, where the inter-domain orchestrator is playing a key role. This orchestrator is not a MANO orchestrator, but it is an entity that interacts with domainlevel orchestrators as slaves. Before slice deployment, it interacts with the sub-network slice configurator (SSC), which main role is the preparation of the end-to-end slice template. The preparation means the modification of some parts of the sub-network slice templates, especially the in-slice OSS/BSS and the SOS parts, according to the need for end-to-end slicing. For example, a selected sub-network slice may include mechanisms responsible for users’ authentication, whereas these mechanisms are removed for other slices. Furthermore, some mechanisms that enable stitching of neighbouring slices can be added to the slice template by the inter-domain orchestrator.

The proposed structure of 6G-LEGO slice together with slice-related operations is described in the next subsections.

A. The Structure of 6G-LEGO Slice Templates and their Usage

In order to minimize the interactions with other components of the framework, the slice template comprises a set of functions that implements autonomic operations of a slice or sub-network slice. To that aim, the slice template includes embedded functions responsible for the management and orchestration support of the slice (in-slice OSS/BSS), i.e., (ISM) [45]. The benefits of this approach are described later in this section.

The 6G-LEGO slice template also includes functions responsible for slice operations - support for slice discovery,

Fig. 1.

Generic 6G-LEGO slice template structure.

users authentication, mobility, and proper traffic redirection for horizontal (for inter-domain operations) and vertical stitching of sub-network slices (e.g. for adding services to the deployed slices). In order to adapt the slice operations to the needs of the inter-slice communications, the functions responsible for slice operations have to be modified before the slice deployment by the orchestrator operator. These functions of a slice are grouped in the SOS [37].

Each 6G-LEGO slice template is composed of: i) The core slice components (CSC), ii) the slice management part, called the slice manager (SM), iii) the resource orchestration support (ROS), and iv) the SOS part. The role of each part of the sub-network slice is described below.

1) Core Slice Components: The core slice components (CSC) part of the slice represents the main functionality of a slice as requested by the slice tenant. This functionality is identical to the implementation in a non-sliced network. Following the concept defined in [37], the per-plane slicing of the CSC functions is allowed.

2) Slice Manager: The SM is an implementation of the ISM paradigm. It provides slice-specific run-time management, and it exposes an interface for the purpose of slice management to the slice tenant (I-TEN). This tenant-oriented interface provides the functionalities for KPIs monitoring, users management, policy-based slice management, slice security monitoring, etc. If a tenant is not interested in slice management, the interface is connected to OSS/BSS of the orchestration domain and the slice management is provided by the domain operator. SM is not CSC agnostic, and therefore, it should be defined together with the CSC and included in the slice template.

The SM functionalities can be modified during run-time, using the slice update mechanism. That allows for the dynamic deployment of management functionalities. In contrary to the 3GPP approach, 6G-LEGO hence makes the slice management programmable. The mechanism can be used, for example, for the dynamic addition of security functions to a slice. As outlined in [45], the preferred approach to the SM implementation is the automated/autonomic management paradigm, since the management of many slice instances cannot be done efficiently in a manual way. Using an AI-driven approach, ITEN can be defined as an intent-based interface providing a relatively easy management interface to the slice tenant, which in most cases is not a professional network operator. One of the benefits of the ISM paradigm is the minimization of involvement of the global OSS/BSS in slice management, which contributes to management scalability and reliability improvement. It also minimizes the OSS/BSS modifications that are generally required in order to efficiently support the management of each type of slice.

3) Resource Orchestration Support: The ROS part of a slice is a component that supports resource orchestration. It cooperates with SM in order to proactively allocate resources to a slice (using slice usage predictions) before the resource congestion occurs and enables QoE-driven resource allocation. By analysing the slice traffic, ROS can also request the relocation of a specific virtual function or the deployment of a new one. It may play the role of a dedicated VNFM of MANO and OSS/BSS that interacts with NFVO for slice update. After the sub-network slice deployment, ROS has the knowledge about the slice topology, the location of virtual functions and the allocation of resources to the sub-network slice. The initial information is obtained by ROS from the orchestrator. ROS plays an important role during the subnetwork initialization phase - it obtains the sub-network slice configuration details from the orchestrator and sends the data to SM, which configures all virtual functions of the subnetwork slice. ROS must be included in the sub-network slice template.

4) The Slice Operation Support: The Slice operation support (SOS) part can be seen as a set of slice-level control plane entities supporting slice stitching, authentication and selection. The SOS entities are the following:

· The border gateway(s) (BG) that supports the stitching of sub-network slices by providing proper adaptation and configuration of inter-slice protocols for the transport of the user and control planes. BGs can expose an abstracted slice view to other slices.

· The slice exposure function (SEF) that is used in order to describe the slice properties and configuration. In the case of a combination of several sub-network slices, SEF has to be appropriately updated. The role of SEF is similar to the NEF of 5G as defined by 3GPP [19].

· The slice authentication function (SAF) that is used for authentication of users and for mutual authentication of stitched sub-network slices. The slice users database (SUD) stores the information about the users that are attached to a slice. SEF and SAF take part in the process of slice selection. In case of horizontal stitching of several sub-network slices, only one of them implements the functionality.

· The mobility management function (MMF) that is used for handling mobility of users attached to the end-to-end slice as well as the “mobility” of slice entities, i.e., their relocation, in order to improve slice KPIs. The latter is realized via the ROS functionality. MMF also reflects the decisions made by the multi-domain orchestrator (MDO) regarding optimal slice placement by preparing the slice and its users for relocation.

The SOS functionality should be configured just before slice deployment according to slice- or tenant-specific needs. As a result of slice stitching, some functions of SOS of some sub network slices can be removed, e.g., in chained sub-network slices, only one of them may have SAF and SEF. More about the usage of SOS for slice stitching is presented in the next subsection.

5) Slice Chain Configurator: The Slice chain configurator (SCC) entity is used in case a slice is a member of any chain of sub-network slices. It keeps the identity of the chain and the identity and role of the sub-network slice of the chain.

6) Chain Manager: In each chain, there is a sub-network slice that has an entity called the chain manager (CM). It plays the manager role of the chain of sub-network slices by interacting with SMes of all sub-network slices that are members of the chain. Its role is described in details further on.

B. Operations on 6G-LEGO Sub-network Slices

Sub-network slice stitching is at the heart of the 6G-LEGO concept. In this section, we provide some details on how the stitching of slices contributes to the flexibility of the presented framework and how the functions of SOS support slice stitching.

1) Horizontal stitching of sub-network slices: The creation of the end-to-end slice over multiple technological or administrative domains can be problematic. In the case of different administrative domains being under the control of different operators, the issue is typically the reluctance of domain operators to share the details regarding their infrastructure that is needed to deploy slices. In the case of different technological domains, the issue is the necessity to use domain-specific orchestrators. These problems can be solved by defining a set of single-domain templates, which can be implemented by each operator upon request and later on stitched. Another motivation for sub-networks stitching is the split of the same technology domain into smaller orchestration domains for the sake of scalability. All the above-mentioned reasons enforce the motivation for the creation of end-to-end slices as a combination of domain-level sub-network slices. We call this operation the horizontal stitching of sub-network slices.

The operation is similar to the interconnection of multiple networking domains. In general, the use of horizontal slice stitching results in a less efficient implementation than the use of a single inter-domain orchestrator, yet it provides the above-mentioned advantages.

2) Vertical stitching of sub-network slices: There are multiple reasons to provide the so-called vertical stitching of slices, which lies on “piggybacking” of one slice to another alreadydeployed slice. There are two variants of vertical stitching:

· A recursive vertical stitching of slices that relies on the use of existing APIs (i.e., the slice exposure function, SEF) of a slice can be used to enrich its functionality by the addition of a sub-network slice in the same domain. Later on, the functions of both combined sub-network slices can be used by another sub-network slice, and this operation can be recursive. The described approach is of premium importance for incrementally composing advanced services.

· The disjoint vertical stitching of slices relies on piggybacking of many mutually-isolated slices to the same,

Fig. 2.

Stitching of several sub-network slices to compose an end-to-end chain (example).

shared sub-network slice. This case can be used for multiple short-time lived slices in order to reduce their footprint (some functions are common to all slices of the same type, fewer functions have to be instantiated for each slice instance) and to shorten their deployment time. Moreover, such an approach can be enforced due to the limitation in slicing of some technologies (legacy networks, RANs). Yet another approach of the concept is the management as a service (MaaS), i.e., the creation of a slice that has SM functions but is able to manage several slices of the same type (SM is not slice type agnostic). Such a set of common functions, sometimes referred to as a common slice (in opposite to dedicated slice [29], [36]), can be also used for the implementation of inter-slice operations. For example, functions, like authentication of users or slice selection, can be common to all slices or to a group of slices. Moreover, a common implementation of mobility management is beneficial when users have the capability of simultaneous attachment to multiple slices. In the presented concept, we have followed the common slice idea, i.e., all common functions are grouped together that is justified by the ease of management and the elegance of the overall approach. It should be noted, however, that common functions have a negative impact on isolation properties of slices.

An example of stitching of several sub-network slices is shown in Fig. 2. In the presented case, the border gateways (BGs) of each SOS are used for the interconnection between pairs of sub-network slices (SNS). BGs provide the abstractions and interconnection of the different technological slices.

The goal of the abstraction is to minimize the dependence on the technology, which has been used for the creation of each sub-network slice. The mentioned figure can be interpreted in several ways:

· If SNS B, C and D are SNSes of different radio access technologies (RAT), e.g. WiFi, 4G, 5G, they provide in parallel connectivity to the 6G Core (SNS A) that has been configured during the deployment phase to authenticate the users and to also provide some other functions.

· SNSes C (RAN), A (core), D (cloud) can be considered as horizontally-stitched SNSes, whereas SNSes A and B, E and C, and F and D can be respectively seen as vertically stitched.

It has to be noted that the framework allows different access technologies to be used for the same slice and that

Fig. 3.

An example of usage of the common sub-network slice.

several 5G/6G core networks can be implemented using the proposed framework. This is a strong differentiator with the 5G network slicing in which a single 5GC (NSSF, AMF, etc.) has to support all other slices. Due to the proposed feature, the 6G-LEGO framework allows for RAN aggregation and RAN sharing.

In Fig. 3, we illustrate the usage of a common sub-network slice. In the presented case, the slice is responsible for the management (via SM), orchestration support (via ROS) and authentication of users (via SOS) of all sub-network slices and its users that are vertically attached to the slice. In this way, the footprint of the dynamically deployed sub-network slices is smaller and their deployment is faster.

In chaining sub-network slices, one of the chained subnetwork slices has to play the role of CM. CM keeps the information about the chained SNSes and defines their roles. This operation is supported by the SCC component of SOS.

A conditio sine qua non of the described concept is the creation of sub-network slice templates with the customized SOS part of each of them before the sub-network slice deployment.

In the proposed solution, the slices and their functions are mutually isolated. For the initial attachment of a user to a slice, it is necessary to provide a mechanism that informs the users about the deployed slices and their properties. For that purpose, we propose the creation of an end-to-end slice (a chain of sub-network slices) that interacts with the MDO in order to gather information about the deployed slices and their features. Such a slice can be seen as a “default slice” and is used for the initial interaction with the 6G-LEGO framework.

C. Management of the End-to-end Slices

In a classical ETSI NFV MANO case, applied also to 5G network slicing, the management of all deployed network services (i.e., network slices) is performed by an OSS/BSS, external to the slices, that interacts with NFVO and element managers (EMs) of VNFs of slices. As it has been described, the 6G-LEGO framework uses embedded sub-network slice management and the SM that is a part of a sub-network slice. SM exposes two management interfaces - the main management interface to slice tenant (I-TEN) and another one to the domain level OSS/BSS (I-OSS), mostly for SLA and accounting purposes.

In the case of chaining of several sub-network slices, there is a need, however, to provide the overall management of the chain. According to the 6G-LEGO philosophy, the interactions

Fig. 4.

Management of several sub-network slices that compose an end-to-end chain (example).

between sub-network slices should be minimized and as agnostic as possible. It is worth noting that in current networks, there exist multiple, domain-level management systems, but the interactions between them are non-existent or minimal (typically for KPIs exchange). In our proposal, the CM plays the role of a “higher-level” slice manager (inter-domain) that is managing the end-to-end slice via the interaction with all SMes of the sub-network slices that compose the chain.

The CM is also involved in the end-to-end KPI calculations, the policy-based management of a slice, etc. For predefined chains, the CM can be defined a priori by the template provider; however, the best solution would be a dynamic creation of the component. Unfortunately, the automatic creation of a CM for any chain of sub-network slices is a challenging task. The CM should be deployed in the same sub-network slice in which the chain master controller is implemented. Typical interactions between SMs and the CM are shown in Fig. 4. It has to be emphasized that during the slice run-time, the most involved entities in the slice management are the SMs, and the involvement of the CM is limited; therefore, even manual management in such a case is applicable. The CM interacts with the OSS/BSS that manages the sub-network slice, which has an embedded CM for the purpose of reporting of the chain (end-to-end slice) KPIs and accounting.

D. Orchestration of 6G-LEGO Network Slices

In this section, the 6G-LEGO orchestration is outlined. The main idea of 6G-LEGO lies on the use of domain-level slices or sub-network slices that are created by the domain level orchestrators in order to obtain end-to end-slices. The proposed approach is not tied to a specific orchestration technology. However, we will refer to the ETSI NFV MANO framework as a reference solution. The virtualized infrastructure is a classical infrastructure of virtualized resources (computing, storage and connectivity) of an administrative domain that can be allocated to multiple slices. In some cases, the infrastructure can include hardware entities (PNFs according to the ETSI NFV naming).

In 6G-LEGO, there is a functional split between the slicedependent management and the resource-oriented orchestration (slice agnostic). The management part of the sub-network (single domain slice), as well as resource orchestration support are both parts of the sub-network slice template (ROS component), which is in-line with the 6G-LEGO philosophy. The overall orchestration architecture is presented in Fig. 5.

Fig. 5.

Orchestration architecture of 6G-LEGO (only orchestration-related interfaces are shown).

For the lifecycle orchestration of slices, the generic MANO approach is still applicable with minor changes. First of all, the orchestration of multiple domains is made in a hierarchical way using the MDO on top of domain orchestrators (DOs) that are involved in the lifecycle and run-time orchestration of network slices. In the architecture, we also introduce the tenants portal and the sub-network slice configurator (SSC), which roles will be described in details further on. First, we describe the usage of the framework for the life cycle management of slices and later their role in the run-time orchestration of network slices.

1) Slice lifecycle orchestration: The orchestration component roles in the slice lifecycle orchestration are as follows:

· Tenants portal (TP). The portal is a single point of contact for tenants and is mainly used for the purpose of slice template selection and slice life cycle management (deployment, update, termination). For the slice selection procedure, the TP has a list of all slice templates (subnetwork templates or templates of chains) that can be deployed. Each sub-network slice or a chain has its descriptors and a list of configurable parameters that are available to the TP. Such a list is provided to the TP by the MDO. During the slice request dialogue, some slice deployment options can be negotiated. The TP can also be used for monitoring the slice KPIs by slice tenants if it is not directly provided by the embedded slice mechanisms, i.e., SM. For the purpose of KPI monitoring, the TP has a database that stores KPIs of each slice. KPIs are defined in the slice template and are calculated by the management components of a slice (SM). The TP may provide visualization of slice KPIs. A proposal for such slice-agnostic KPIs can be found in [46]. The portal also keeps all the accounting data concerning slice tenants. For that purpose, the requested and obtained slice KPIs are compared for SLA validation. On the one hand, the TP interacts with tenants, and on the other hand, it interacts with the MDO and indirectly with the SSC.

· MDO. The MDO performs multiple roles. This is the entity that is contacted for the deployment of all slices; it also provides the TP with information about KPIs of all already-deployed slices. It includes the database of all templates that can be used for slice deployment within the framework (even those which are used by other orchestrators of the framework). When a new slice request is sent to the multi-domain orchestrator, it analyses the feasibility and options of its deployment. All the operations can be qualified as a slice pre-deployment phase.

· SSC. The SSC role is to modify optionally the subnetwork slice template according to the requirements of the chained sub-network slices. The SOS modifications correspond to the addition or removal from each subnetwork SOS components that are, respectively, necessary or not needed for a specific sub-network slice chain. The ROS of each sub-network slice obtains the SSC information about the initial configuration of each subnetwork slice that has to be deployed during the subnetwork slice initialization. The information about chainspecific configuration for known templates is stored in the SSC.

· DO. The DOs obtain the sub-network slice templates modified by the SSC (the modification typically concerns the SOS part of the slice template) from the MDO and are responsible for the deployment of each sub-network slice that compose an end-to-end slice. DOs are domainspecific orchestrators of resources combined with the domain OSS/BSS. The domain OSS/BSS part of a DO is focused on all the operations of its domain. It collects statistics related to resource usage, provides the inventory of running slices and their dependencies that are the implication of vertical and horizontal stitching of subnetwork slices, which are deployed within this domain. The OSS/BSS part provides FCAPS (fault, configuration, accounting, performance, security) functionalities for its domain, i.e., it may force the DO to implement a template in a specific way. It also provides an interface to the domain operator and to the MDO. The orchestration part of a DO is responsible for requesting from the Infrastructure resource allocation to a slice (or subnetwork slice) and the optimal placement of template virtual functions. However, the initial configuration of a deployed slice is performed by the SM of the slice, therefore, DOs are slice agnostic. The DO may have to collect all the information related to deployed slice performance and faults. After the deployment of each sub-network slice, its ROSes forward to respective SMes the slice configuration parameters that SMes have to use for configuring each component of the sub-network slice. During the deployment, each DO provides the ROS with information about the slice deployment configuration that includes the information about the deployment of each virtual function, its placement, resource allocation as well as the sub-network slice graph.

After the successful completion of the mentioned operations, the sub-network slice SM or, in the case of a chain, the CM reports to the TP that the slice is ready to be used, completing that way the slice deployment phase.

The slice termination phase details are omitted in the description as the operations of this phase are pretty simple. The only aspect specific to the 6G-LEGO framework operations is related to the transmission of all slice-related statistics via the MDO to the tenants portal for the purpose of accounting. It is noteworthy that the slice termination will also terminate the SM of the terminated slice.

2) Slice run-time orchestration: During the run-time phase, each SM of the sub-network slice carries out the performance analysis and, on that basis, it is trying to perform reconfigurations in order to maintain the slice KPIs at the required level. The SM, in cooperation with the ROS (which is aware of the sub-network slice graph, resource allocation and consumption), may propose to change the resource allocation or to relocate a certain virtual function from one data centre to another one for the sake of data transport efficiency. All slice template modifications or virtual function placement requests are sent via the ROS to the DO. After the change of the virtual function placement, the SM makes necessary configuration changes, and the ROS updates its slice deployment-related database. The mentioned SM-ROS cooperation allows for the application-driven (sometimes QoE-based) resource allocation that is hard to achieve in the current MANO architecture, and it provides an efficient extension to the classical management that assumes a fixed allocation of resources.


In the previous section, we have described the 6G-LEGO framework. In this section, we provide an analysis of its potential implementation. The proposed approach differs significantly from the 3GPP’s 5GC-centric one. We have proposed a different decomposition of functions with a much higher distribution level. Due to the embedding of many functions in the slice template, these functions do not need to be implemented as a part of the framework. Some 5GC functions can be reused by 6G-LEGO, even as a part of the slice template. Nonetheless, particular functions that do not exist in 5GS have to be developed and implemented from scratch. The set of these functions include the TP, the SSC and the MDO.

A. 6G-LEGO Slice Template Functions and Interfaces

In this section, some recommendations regarding the specification of slice interfaces as well as functionalities of selected entities of the proposed solution are provided. There is no need to specify the slice internal interfaces, as they are slicespecific. Yet, there is a need to specify all the interfaces that are used for the interaction of a slice with external entities.

The interfaces that need to be specified within a slice template include:

· SM-DO interface. This interface is mostly used for providing information about slice health and performance (KPIs).

· SM-tenant interface. This interface is a customized web interface. Therefore, its specification is not a critical one.

· ROS-DO interface. the ROS provides interfaces to the DO that deals with orchestration. It includes the VNFM of the MANO functionality and interacts with the NFVO using OSS/BSS-VNFO-like interfaces. Details of the modification of the interfaces have yet to be specified.

· BG interfaces. The SOS functions interact with the entities external to the slice. The BG has to provide an interface for data exchange in a slice chain. Typically, some standardized IP protocols will be used for that purpose.

The SEF may use the modified and extended concepts of the 3GPP NEF. The SAF functions can be taken from 3GPP, and it plays a similar role to the NSSF of 5GC. The slice CMs are slice specific and do not have to be specified.

B. 6G-LEGO Framework Components and their Interfaces

1) Tenants Portal: The TP provides the interaction between tenants and the MDO. It plays the role of the business portal used for triggering the operations related to the lifecycle management of the slices. The interface between the portal and the MDO has to be defined, but not standardized. It is used for passing to the TP the information about the possibility of slice deployment, and according to tenants portal requests, the MDO provides the lifecycle management of multi-domain slices. The GST/NEST templates proposed by GSMA (with extensions) can be used for negotiations with tenants.

2) Sub-Network Slice Configurator: The SSC converts the requests obtained from the MDO, and it thus compiles subnetwork slice templates with customized components of SOS. The SSC-MDO interface should be standardized.

3) Multi-Domain Orchestrator: The MDO interacts with the SSC, the DOs, the TP and the SMes of slices. Its main function is the deployment, termination and high-level monitoring of the status of the deployed slices. This is not a MANO orchestrator. The interaction of the MDO with the SSC and the TP has been already described. The MDO-DO interface is used for the deployment of a sub-network slice template in a specific domain. This interface should provide the lifecycle operations abstractions in order to deal with different types of DOs.

4) Domain Orchestrator: The DO is composed of two parts. The first one is the domain-level OSS/BSS that is master for all orchestration operations. It performs all FCAPSoriented operations. The second part of the DO is the resource orchestrator (MANO-like). The SM-DO interfaces used for triggering orchestration operations by an SM can follow the NFV specifications. For specific technological domains, different than MANO orchestrators should be used. The MDO should be aware of their specificity and capabilities.

5) Virtual Infrastructure: It is not specific to the 6G-LEGO framework. The ETSI MANO approach or other domainspecific approaches (e.g. for RAN) can be used.


In this paper, we have introduced a new and clean slate approach to network slicing that we believe to be applicable to beyond 5G networks, including 6G networks. Our concept aims at addressing some deficiencies of the ETSI NFV and 3GPP approaches to network slicing that we have described in Section III. We see those approaches as overly complex with a lack of proper separation of concerns, too centralized and with lack of some vital functionalities.

The 6G-LEGO model minimizes the external operations related to each slice and uses some programmable abstractions to simplify slice stitching and compose the end-to-end slices as a set of “bricks”. To achieve that goal, we looked at a cloud model considering a slice as a distributed application, which internals are not known to the cloud (infrastructure) or the orchestrator operator. Thus, we have proposed to include a programmable management plane of each slice in the slice template (e.g., the SM). Moreover, the slice template can be customized before its deployment, by adding necessary functions, such as support for slice selection and authentication. Using its orchestration-related function (ROS), the slice itself is able to provide proactive resource allocation and slice update (adding or removing slice functions). Additionally, we have considered the horizontal and vertical concatenation of sub-network slices. Such operations are possible due to the programmable interfaces of slices and the in-slice management concept that we introduced. The vertical and horizontal slice stitching allows for deploying multi-domain slices or adding virtualized service platforms to slices. 6G-LEGO is agnostic to radio access technologies (RATs). In fact, our approach enables the deployment of multiple, independent instances of a complete mobile network. The functionality of the orchestrator in 6G-LEGO has been simplified - it is slice agnostic, mostly used in the slice deployment phase, and it is focused on resources only. As compared to 5GS, the number of interfaces of 6G-LEGO that have to be standardized is reduced since there is no need to specify intra- and inter-slice interfaces.

The presented concept still remains at a high level, and thus requires significant work before it can be materialized. We list hereafter the most critical issues that have to be solved before obtaining a deployable 6G-LEGO framework. More work on the MaaS approach, i.e., common management of several or all slices based on the same template, is needed. The MaaS (as an option) can efficiently address the drawbacks of the proposed solution, i.e., the increased slice footprint caused by adding the management plane to the slice. The slice template creation and preparation entity also plays a significant role in 6G-LEGO. Such a complex and intelligent entity has to be developed from scratch. The 6G-LEGO orchestrator can be seen as a redefined MANO orchestrator with reduced functionality. This redefinition has yet to be specified in details, and the existing solution appropriately modified. The SOS entities responsible for slice selection, authentication and mobility have to use standardized interfaces to interact with the end-users equipment. The MDO requires a more detailed specification of its internal functions. The slice stitching operation needs further investigation regarding slice exposure and handling of the dependencies between vertically stitched slices. An interesting challenge is the automatic generation of the Chain Management components that can provide end-to-end slice management through the interaction with slice managers.

All these issues are open and left for future work. In this regard, the paper provides some research directions for the efficient implementation of slices in 6G networks.


Sławomir Kuklińnski

Sławomir Kuklińnski Sławomir Kuklińnski received his Ph.D. with honours from Warsaw University of Technology in 1994, and since then, he is Assistant Professor there. He teaches Mobile and Wireless Systems Security. From 2003 he has also been working for Orange Polska as Research Expert focused on mobile and wireless systems, focusing on selfmanaged and AI-driven solutions. At present, he works on network slicing. He led many national research projects and was involved in many international projects, including European projects FP6 MIDAS, FP7 EFIPSANS, FP7 4WARD, FP7 ProSense, Celtic COMMUNE, EU-Japanese project 5G!Pagoda and EU-China project 5G-DRIVE. He is currently involved in two EU projects, 5G!Drones and MonB5G. He is engaged in ITU-T (Study Group 13) standardization of SDN and network slicing. Sławomir Kuklińnski has published more than 80 conferences and journal papers, and gave several invited keynotes on network management and network slicing.


Lechosław Tomaszewski

Lechosław Tomaszewski received M.Sc. Eng. with honors (1996) and Ph.D. (2005) from the Silesian University of Technology in Gliwice, Poland. He has been with Orange Polska (formerly Telekomunikacja Polska) since 1996. His industrial experience and expertise cover the following domains: Transmission systems; mobile core and IMS; network & service probes and management systems; OSS and operational processes of network & service management/development. He is interested in various aspects of 5G system and beyond, network slicing and AI-supported network management, and is currently involved in H2020 EU 5G!Drones and EU MonB5G projects.


Robert Kołakowski

Robert Kołakowski received his B.Sc. (2018) and M.Sc. (with honours, 2019) in Telecommunications with specialization in Radiocommunications and Multimedia Technology from the Warsaw University of Technology. He has been working for Orange Polska since 2019. His industrial experience and expertise include RAN protocol analysis, network & service management and mobile core. His research interests cover various aspects of 5G and next-generation mobile networks, with emphasis on network management and network slicing technology. Currently, he is pursuing his Ph.D. thesis related to SDN and traffic engineering algorithms in the context of the future mobile networks UP and is involved in H2020 EU 5G!Drones and EU MonB5G projects.


Prosper Chemouil

Prosper Chemouil is an Adjunct Senior Researcher in the "Networks & IoT Systems" (ROC) at Cedric, Cnam in Paris, France. He is retired of Orange Labs, the R&D Unit of the Orange Group, where he was a Research Director and Chief Scientist on Networks and Systems. In his last position, he was the Expert Program Leader on Future Networks for the whole Orange Group. His research interests are with the design and management of new networks and technologies and their impact on network architecture, traffic engineering and control, and performance. In the last 15 years, he has been then focusing on cognitive management and network softwarization. In 2016, he has become the Co-Chair of the IEEE SDN Initiative and is now a member of the IEEE ComSoc Industry Communities Board and Industry Outreach Board, representing the SDN/NFV/Cloud area. Within the IEEE SDN Initiative, he launched NetSoft, the IEEE International Conference on Network Softwarization, in 2015. He has been involved as the general or TPC co-chair in many events dealing with network design and management. He has also served as a Board Member, an Associate Editor, and the Guest Editor of various journals, including IEEE Communications Magazine, IEEE Transactions on Network and Service Management, IEEE Journal on Selected Areas on Communications, IEEE Networks, and Annals of Telecommunications. Prosper received the M.Sc. and Ph.D. degrees in control theory from École Centrale de Nantes, in 1976 and 1978, respectively. He was a recipient of several awards, such as the Blondel Medal in 1996, the Ampère Medal in 2003, the Salah Aidarous Memorial Award in 2014, and Arne Jensen Lifetime Achievement Award in 2015. He was a runner-up as French Senior Engineer of the Year in 1995 and became a Fellow of France Telecom R&D in 1998. He is a Life Fellow of IEEE and a Fellow of SEE, the French Society of Electrical and Electronical Engineers.


  • 1 K. B. Letaief, W. Chen, Y. Shi, J. Zhang, Y.-J. A. Zhang, "The roadmap to 6G: AI empowered wireless networks," IEEE Commun. Mag, vol. 57, no. 8, pp. 84-90, Aug, 2019.custom:[[[-]]]
  • 2 M. Katz, M. Matinmikko-Blue, M. Latva-Aho, "6Genesis flagship program: Building the bridges towards 6G-enabled wireless smart society and ecosystem," in Proc. IEEE LATINCOM, 2018;custom:[[[-]]]
  • 3 Y. Xing, T. S. Rappaport, "Propagation measurement system and approach at 140 GHz-moving to 6G and above 100 GHz," in Proc. IEEE GLOBECOM, 2018;custom:[[[-]]]
  • 4 K. David, H. Berndt, "6G vision and requirements: Is there any need for beyond 5G?," IEEE Veh. Technol. Mag., Sep, vol. 13, no. 3, pp. 72-80, 2018.custom:[[[-]]]
  • 5 E. Calvanese Strinati et al., "6G: The next frontier: From holographic messaging to artificial intelligence using subterahertz and visible light communication," IEEE Veh. Tech. Mag., Sep, vol. 14, no. 3, pp. 42-50, 2019.custom:[[[-]]]
  • 6 F. Tariq, M. R. A. Khandaker, K.-K. Wong, M. A. Imran, M. Bennis, M. Debbah, "A speculative study on 6G," IEEE Wireless Commun, vol. 27, no. 4, pp. 118-125, Aug, 2020.custom:[[[-]]]
  • 7 ETSI GS NFV-EVE 012 Network functions virtualization (NFV); evolution and ecosystem; report on network slicing support with ETSI NFV architecture framework, V3.1.1 ETSI NFV ISG Group Specification NFV-EVE 012, Dec, 2017.custom:[[[-]]]
  • 8 Description of network slicing concept. NGMN alliance, V1.0, Jan. 2016. Available:, https://www.ngmn.org/wp-content/uploads/160113_NGMN_Network_Slicing_v1_0.pdf.Accessed:Mar.25,2021
  • 9 ETSI GS NFV 002 Network functions virtualisation (NFV); architectural framework, V1.2.1. ETSI NFV ISG group specification NFV 002, Dec, 2014.custom:[[[-]]]
  • 10 System architecture for the 5G system (5GS), v17.1.1 3GPP TS 23.501 Jun, 2021.custom:[[[-]]]
  • 11 ETSI GS NFV-MAN 001 Network functions virtualisation (NFV); management and orchestration, V1.1.1 ETSI NFV ISG group specification NFV-MAN 001, Dec, 2014.custom:[[[-]]]
  • 12 ETSI GS NFV-IFA 014 Network functions virtualisation (NFV) Release 3; management and orchestration; network service templates specification, V3.4.1 ETSI NFV ISG Group Specification NFV-IFA 014 Jun, 2020.custom:[[[-]]]
  • 13 Management and orchestration; architecture framework, v16.7.0 3GPP TS 28.533, Apr, 2021.custom:[[[-]]]
  • 14 Y, 3110 IMT-2020 network management and orchestration requirements (09/17), ITU-T recommendation Y .3110 Sep, 2017.custom:[[[-]]]
  • 15 Y, 3111 IMT-2020 network management and orchestration framework (09/17), ITU-T recommendation Y .3111 Sep, 2017.custom:[[[-]]]
  • 16 Y, 3112 Framework for the support of multiple network slicing (05/18), ITU-T recommendation Y .3112, May, 2018.custom:[[[-]]]
  • 17 GSMA NG.116 generic network slice template, GSM association NG.116, V3.0, May 2020. Available:, https://www.gsma.com/newsroom/wp-content/uploads/NG.116-v3.0.pdf.Accessed:Mar.25,2021
  • 18 NR; Overall description; Stage-2, v16.6.0 3GPP TS 38.300 Jun, 2021.custom:[[[-]]]
  • 19 5G system; network exposure function northbound APIs; Stage 3, v17.2.0 3GPP TS 29.522 Jun, 2021.custom:[[[-]]]
  • 20 5G system; network slice selection services; Stage 3, v17.1.0 3GPP TS 29.531 Jun, 2021.custom:[[[-]]]
  • 21 Security architecture and procedures for 5G system, v17.2.1 3GPP TS 33.501 Jul, 2021.custom:[[[-]]]
  • 22 5G system; network slice-specific authentication and authorization (NSSAA) services; Stage 3, v17.1.0 3GPP TS 29.526 Jun, 2021.custom:[[[-]]]
  • 23 Study on enhancement of radio access network (RAN) slicing for NR, v17.0.0 3GPP TR 38.832 Jul, 2021.custom:[[[-]]]
  • 24 Management of network slicing in mobile networks; concepts, use cases and requirements v17.1.0 3GPP TS 28.530, Apr, 2021.custom:[[[-]]]
  • 25 Management and orchestration; provisioning, v17.0.0 3GPP TS 28.531 Jun, 2021.custom:[[[-]]]
  • 26 Management and orchestration; generic management services, v16.8.1 3GPP TS 28.532 Jun, 2021.custom:[[[-]]]
  • 27 C. J. Bernardos et al., Network virtualization research challenges, "", Internet Research Task Force RFC 8568, Apr, 2019.custom:[[[-]]]
  • 28 X. Foukas, G. Patounas, A. Elmokashfi, M. K. Marina, "Network slicing in 5G: Survey and challenges," IEEE Commun. Mag, vol. 55, no. 5, pp. 94-100, May, 2017.custom:[[[-]]]
  • 29 B. Sayadi et al., SDN for 5G mobile networks: NORMA perspective, "", in Proc. CROWNCOM . ´ NSKI et al..: 6G-LEGO: A FRAMEWORK FOR 6G NETWORK SLICES 453, 2016.custom:[[[-]]]
  • 30 C. J. Bernardos et al., "5GEx: Realising a Europe-wide multidomain framework for software-defined infrastructures," Trans. Emerg. Telecommun. Techn., Jul, vol. 27, no. 9, pp. 1271-1280, 2016.custom:[[[-]]]
  • 31 A. de la Oliva et al., "5G-TRANSFORMER: Slicing and orchestrating transport networks for industry verticals," IEEE Commun. Mag, vol. 56, no. 8, pp. 78-84, Aug, 2018.custom:[[[-]]]
  • 32 L. M. Contreras, D. Lopez, IEEE Softwarization (Online), Jan. 2018. Available:, https://sdn.ieee.org/newsletter/january-2018/a-networkservice-provider-perspective-on-network-slicing.Accessed:Mar.25,2021
  • 33 T. Taleb, I. Afolabi, K. Samdanis, F. Z. Yousaf, "On multidomain network slicing orchestration architecture and federated resource control," IEEE Netw., vol. 33, no. 5, pp. 242-252, 2019.custom:[[[-]]]
  • 34 J. F. Santos et al., "Breaking down network slicing: Hierarchical orchestration of end-to-end networks," IEEE Commun. Mag, vol. 58, no. 10, pp. 16-16, 2020.custom:[[[-]]]
  • 35 K. Katsalis, N. Nikaein, A. Edmonds, "Multi-domain orchestration for NFV: Challenges and research directions," in Proc. IUCC-CSS, 2016;custom:[[[-]]]
  • 36 5G!Pagoda, "D3.1 - slice components design - ver. 1.0," Project, Aug, 2017.custom:[[[-]]]
  • 37 S. Kuklińnski et al., "A reference architecture for network slicing," in Proc. IEEE NetSoft, 2018;custom:[[[-]]]
  • 38 A. Kaloxylos, "A Survey and an analysis of network slicing in 5G networks," IEEE Commun. Stand. Mag., vol. 2, no. 1, pp. 60-65, Mar, 2018.custom:[[[-]]]
  • 39 I. Afolabi, T. Taleb, K. Samdanis, A. Ksentini, H. Flinck, "Network slicing and softwarization: A survey on principles, enabling technologies, and solutions," IEEE Commun. Surveys Tuts.3rd quarter, vol. 20, no. 3, pp. 2429-2453, 2018.custom:[[[-]]]
  • 40 A. A. Barakabitze, A. Ahmad, R. Mijumbi, A. Hines, "5G network slicing using SDN and NFV: A survey of taxonomy, architectures and future challenges," Comput. Netw., p. 106984, vol. 167, Feb, 2020.custom:[[[-]]]
  • 41 L. M. Contreras, Slicing challenges for operators, "", in Emerging Automation Techniques for the Future Internet M. Boucadair and C. Jacquenet (Eds.) IGI Global, 2019.custom:[[[-]]]
  • 42 A. J. Gonzalez et al., "The isolation concept in the 5G network slicing," in Proc. EuCNC, 2020;custom:[[[-]]]
  • 43 L. Tomaszewski, S. Kuklińnski, R. Kołakowski, "A New Approach to 5G and MEC Integration", in: I. Maglogiannis, L. Iliadis, E. Pimenidis (eds.)," Artificial Intelligence Applications and Innovations. AIAI IFIP WG 12.5 International Workshops. AIAI IFIP Advances in Information and Communication Technology, Springer, Cham, doi: 10.1007/978-3-030-49190-1_2, vol. 585, 2020.custom:[[[-]]]
  • 44 S. Kuklińnski, L. Tomaszewski, R. Kołakowski, "On O-RAN, MEC, SON and network slicing integration," in Proc. IEEE GLOBECOM Workshops, 2020;custom:[[[-]]]
  • 45 S. Kuklińnski, L. Tomaszewski, "DASMO: A scalable approach to network slices management and orchestration," in Proc. IEEE/IFIP NOMS, 2018;custom:[[[-]]]
  • 46 S. Kuklińnski, L. Tomaszewski, "Key performance indicators for 5G network slicing," in Proc. NetSoft, 2019;custom:[[[-]]]