Mr Mrs Gladys Diaz

Christophe

The development and the emergence of the Fifth Generation of Mobile Networks (5G) use cases has led to the adoption of a new approach of network management and service instantiation called Network Slicing. This technology allows the dynamic selection and lifecycle management of the appropriate cloud and network resources and their arrangement in isolated logical networks sharing the same physical infrastructure and called Network Slices (NSs). A NS is particularly instantiated to fulfill one or several predefined use cases or services with similar Quality of Service (QoS) requirements.

For example, the remote surgery use case requires ultra-high reliability and at the same time ultra-low latency communications. These same network characteristics are required by the vehicle-to-everything (V2X) use case for autonomous/assisted driving in addition to a high speed communication for entertainment purposes such as accessing the internet from the vehicule. Because of such conflicting and extremely diversified requirements of the new emerging services, the traditional "one-size-fits-all" network approach is no longer efficiently feasible.

Network Slicing is supported by innovative technologies such as Software-Defined Networking (SDN) and Network Function Virtualization (NFV). Together they are enabling network programmability and accelerating the deployment of new services. In this context, the objectives of our thesis are threefold. First, bringing forth an end-to-end 5G network slicing model that serves as a reference to researchers and developers for the realization of their NS solutions. Second, analysing the requirements and the design of the resource-facing solution responsible for the NS subnet management. Last, based on the aforementioned works, we propose the inter-slice bandwidth resource sharing, a novel mechanism to address the resource optimization challenge in slice-based infrastructures.

The benefits of this concept is demonstrated by the implementation and the evaluation of our solution called InterS.

Résumé

Le développement et l'émergence des cas d'usage des réseaux mobiles de cinquième génération (5G) ont conduit à l'adoption d'une nouvelle approche de gestion de réseau et d'instanciation de services appelée "Network Slicing". Cette technologie permet d'une façon dynamique la sélection et la gestion du cycle de vie des ressources cloud et réseau appropriées et leur organisation en réseaux logiques isolés et partageant la même infrastructure physique appelés "Network Slices" (NSs). Un NS est particulièrement instancié pour répondre à un ou plusieurs cas d'usages ou services prédéfinis avec des exigences similaires en qualité de service (QoS) .

Par exemple, la chirurgie à distance est un cas d'usage qui nécessite une fiabilité ultra-élevée et en même temps des communications à latence ultra-faible. Ces mêmes caractéristiques de réseau sont requises par le cas d'usage des véhicules connectés (V2X) pour la conduite autonome/assistée en plus d'une communication haut débit à des fins de divertissement telles que l'accès à Internet depuis le véhicule. En raison de ces exigences conflictuelles et extrêmement diversifiées des nouveaux services émergents, l'approche traditionnelle du réseau "one-size-fits-all" n'est plus réalisable de manière efficace. la technologie "Network Slicing" est supportée par des technologies innovantes telles que les réseaux définis par logiciel (SDN) et la virtualisation des fonctions réseau (NFV).

Ensemble, ils permettent la programmabilité du réseau et accélèrent le déploiement de nouveaux services. Dans ce contexte, les objectifs de notre thèse sont triples.

Premièrement, faire émerger un modèle de "Network Slicing" de 5G de bout en bout qui sert de référence aux chercheurs et développeurs pour la réalisation de leurs solutions de NS. Deuxièmement, analyser les exigences et la conception de la solution orientée ressources responsable de la gestion des "NS Subnets". Enfin, sur la base des travaux susmentionnés, nous proposons le partage de ressources de bande passante entre "Network Slices", un nouveau mécanisme pour relever le défi d'optimisation des ressources dans vi les infrastructures à bases de NS. Les avantages de ce concept sont démontrés par la mise en oeuvre et l'évaluation de notre solution appelée InterS.

List of Tables

Problem Statement

N

etwork Slicing is a common-sense approach to cope with the explosion of services, business and customer demands of the Fifth Generation of Mobile Networks (5G) era and beyond. In fact, NGMN [1] has already developed a non-exhaustive list of 25 prominent mobile broadband use cases with their highly diversified requirements in order to support its vision for the 5G networks. "Remote surgery" is an example of a customer use case that requires ultra-high reliability and at the same time ultra-low latency communications. Because of the high variety of new emerging services, their conflicting and their extremely diversified requirements, the traditional "one-size-fits-all" network approach is no longer efficiently feasible.

Therefore, network slicing is proposed as a key feature that allows multiple dedicated virtual networks, called network slices (NSs) to operate on a common physical network infrastructure. a Network Slice (NS) is a logical isolated network instantiated over multi-domain, multi-technology physical networks that provides resource guarantees.

Built on top of emerging technologies such as software defined networking (SDN)

and network function virtualisation (NFV), network slicing should select the appropriate compute, storage and network resources and manage them such as to meet the customer service requirements [2]. In contrast to the traditionnel model where all types of services are provided through a single network, NSs are specifically designed and instantiated to target one or several predefined use cases with similar quality of service requirements.

Likewise, it is possible to accommodate the new 5G services in a traditional network model but, at the expense of the operator cost in terms of Operational and Capital

Expenditures (OPEX and CAPEX) and the complexity of network management. The main reason behind such high cost is the underuse of network resources. As an example, it is common for an operator to serve high resource demanding applications and reserve excessive amounts of resources that may be slightly solicited. Therefore, shifting from the traditional "one size fits all" to the Network Slicing model opens up opportunities for service providers and operators to increase their revenue while improving network scalability, flexibility, efficiency and management [3]. However, to fulfil its promises, the NSs implementation is constrained by overcoming many challenges such as isolation, modelization, security and the efficient share of compute and network resources [3].

Research Challenges

The works of our thesis are particularly oriented towards the network slicing technology modelization as well as the resource optimization challenge in slice-based infrastructures (Figure 1.1). Our objective is to bring forth an up-to-date end-to-end (E2E) 5G network slicing model that guides researchers and developers in the building of their future NS implementations. We also aim to develop and integrate a novel mechanism at the post-deployement phase of NSs that provides them with the charachteristics of elasticity and self-adaptability. Hence, a NS is automatically scaled up/down during its operation time with free resources of its neighbor slices in order to optimally accommodate difficult network conditions. • Network Slicing Modelization: This a crucial phase that must be carried on any technology before its realization. The state of art in the network slicing field is lacking for an explicit 5G end-to-end network slicig model that can be refered to by researchers and developers for the management of NSs under their NS solutions.

Furthermore, network slicing standardization is led by different organizations having each a different vision on network slicing and targeting only a specific part of the network infrastructure. Therefore, our first and second contributions answer respectively to the following research questions:

-RQ-1: How to define an end-to-end network slicing model that provides a unified vision of the life-cycle management process of NSs ?

-RQ-2: How to build SDN/NFV-based solutions enabling the management and the orchestration of NSs ?

• Optimization of NS Resources: resource optimization is one of the top priorities of network operators since it increases their revenue while improving the network scalability. The shift to the network slicing model will require the adoption of new mechanisms of network resource optimization. NS reconfiguration is actualy proposed to augment NS resources or to simply improve the network usage rate. However these operations follow an expensive two-phase strategy that should be frequently repeated all along the operation time of the network. Our third contribution answers the following interrogation by providing a novel mechanism to optimize bandwidth resources of NSs:

-RQ-3: How to optimize netwok resources in slice-based environnements ?

Context

SDN, NFV and network orchestration technologies are the key enablers of network slicing. In this section we briefly define each of them and explain how they relate to each other in the fast delivery of new services.

Software-Defined Networking (SDN) [4]

The main motivation for the adoption of the SDN technology is the complexity of traditional networks. In fact, adding new features is very difficult. It can be achieved only through the installation of new firmware or updates to the operating system of the network equipment. Moreover, these functionalities are introduced in specialized, expensive and very difficult to configure equipments (middleboxes) such as firewalls, loadbalancers, intrusion detection system.

To cope with these challenges, the SDN approach separate the control plane of network devices from data plane and centralize it in a SDN controller (Figure 1.2). On the one hand, the controller, acting as a network operating system opens the network to applications and enables network programmability. On the other hand, it creates flow rules in the data plane via a southbound protocol such as openflow [START_REF] Mckeown | OpenFlow: enabling innovation in campus networks[END_REF] in order to It is mainly composed of 3 parts: • Virtual Network Functions (VNFs): It is the virtualization of a certain network function in one or more virtual machines. Each VNF operates independently from the others and can be divided into several sub-functions called VNF components (VNFCs). VNFs are supervised by Elemental Management Systems (EMs).

• NFV Infrastructure (NFVI): this part includes all the necessary software and hardware resources for the deployment, operation and supervision of the VNFs.

The virtualization layer is vital here since it allows the abstraction of hardware resources (processing, storage, network connectivity). This layer also ensures the independence of the VNF software from the hardware.

• NFV Management and Orchestration (NFV MANO): It is made up of 3 components. First, the Virtualized Infrastructure Manager (VIM) which manages the interaction of VNFs with the physical resources under its control (allocation, release, inventory). Second, the VNF Manager (VNFM) which is responsible for the life cycle management (initialization, suspension and termination) of VNFs.

Finally the NFV Orchestrator (NFVO), the element responsible for the realization of network services in the NFVI.

SDN/NFV [6]

SDN and NFV technologies are often discussed as being a single technology (SDN/NFV), this is due to the fact that they are complementary and able to provide a single network solution allowing a shift to opensource hardware and software. SDN can provide connectivity between VNFs in a flexible and automated manner while NFV makes use of SDN as part of Service Function Chaining (SFC). In this case, SDN controllers and management applications can run as VNFs in a scalable environment and therefore benefit from essential features such as availability, reliability and elasticity.

Network Resources and Service Orchestration [7]

Orchestration is the automation of tasks associated with the arrangement, management and coordination of services deployed across different technology/administrative domains with the objective of exposing them as a single service instance. It also consists in guaranteeing an adequate service performance throughout the duration of the delivery despite the concurrent use of resources between users and breakdowns of service. This is performed by the monitoring function of orchestration. Specifically, the orchestrator, based on feedback from monitoring tools, is also responsible for managing exceptions or deviations from workflows and thus adjusting the resources allocated to recover from failures or degradation of services [START_REF] Martini | Cross-Functional resource orchestration in optical telco clouds[END_REF].

An end-to-end NS solution cannot be achieved without end-to-end orchestration and management. As it will be explained later on this thesis, NS life cycle management involves a set of workflows between the service provider and operators. The delivery of the network services depends highly on the successful automation and coordination of these workflows. Therefore, in the context of the European 5G exchange project [START_REF]5G Exchange Project[END_REF], an

End-to-End Orchestration and Management (E2E MANO) reference architecture [START_REF]View on 5G Architecture version 1.0[END_REF] was proposed (Figure 1.4). The architecture distinguishes three layers:

• The resources layer: includes different domains (eg. SDN networks, Data center)

exposing an abstraction of their resources on interface 5.

• The single-domain orchestration layer: compromises multiple domain orchestrators (DOs) performing resource and/or service orchestration based on the abstraction exposed on interface 5.

• The multi-domain orchestration layer: composed of several multi-domain orches-trators (MDOs) that interact with DOs via interface 3, thus performing each resource and/or service orchestration in an administrative domain (eg.operator).

Interface 2 is a business-to-business interface allowing provisioning and orchestration of resources across administrative domains. Lastly, Interface 1 that allows the interaction with business customers and the specification of their service requirements.

An example of a resource/service orchestrator is the NFVO defined in the aforementioned NFV framework. The functionality of the NFVO may be split into two main functional blocks. First, a resources orchestrator allocating NFVI resources (compute, storage, network) to be consumed by VNFs and network services. Second, a service orchestrator responsible for the life cycle management of network services as well as the instantiation of VNFs in coordination with the VNFM.

The NFVO is able to perform both resource and service orchestration and can be placed in the aforementioned E2E MANO reference architecture either as a DO or an MDO. Furthermore, two options related to the split of the NFVO's main functionalities (service and resource orchestration) are proposed in the ETSI NFV-IFA group specification [START_REF]Network Functions Virtualisation (NFV); Management and Orchestration; Report on Architectural Options[END_REF]. The first use case address a network operator offering its infrastructure to different administrative domains (within the same operator). This leads to a separate implementation of the service orchestrator (NFVO) from resource orchestrators placed in each administrative domain. By comparison to the first option, the second one brings the operator services to the different administrative domains. Hence, a top service orchestrator called Umbrella NFVO is introduced interacting with NFVOs in each domain and taking in charge the composition of network services.

One of the challenges of orchestration is the ability to coordinate and manage resources and services in different technology/administrative domains, also called multidomain orchestration. For this end, the Control Orchestration Protocol (COP) has been proposed and developed as part of the STRAUSS project [START_REF]Control orchestration protocol: Unified transport API for distributed cloud and network orchestration[END_REF]. The latter offers a set of transport services (topology service, connectivity provisioning, path calculation) shared between several control/orchestration systems.

The COP allows the interworking of heterogeneous control plane paradigms (Open-Flow, GMPLS / PCE). It provides a common north/south interface for SDN controllers allowing multiple implementations to be orchestrated by a single common protocol.

Our Contributions

The objective of our thesis is to tackle the resources optimization issue in slice-based infrastructures at the post deployement of NSs. This will be achieved by the design and the development of a NS solution that adopt a novel optimization mechanism.

However, before any implementation, we require the definition of an network slicing model that details the life cycle management process of NSs from the service order request to the NS deployement. This model is meant to serve particularly as a reference for our implementation and eventually for others as well. We note that our vision on the network slicing model is based on the standards developped by the leading standards Developing Organizations (SDOs) in the field.

A NS is composed of several units within the network infrastructure called NS subnets. The management of a NS comes down to the coordinated management of all its subnets. Since the NS subnet management function is resource-facing and is directly related to our solution, we study the design and the requirements to be satisfied NSs [START_REF] Chahbar | A Comprehensive Survey on the E2E 5G Network Slicing Model[END_REF].

A NS Subnet Management Framework

Current NS demonstrations are not fully aligned with the ongoing standardization activities, particularly with the Network Slice Subnet Management Function (NSSMF) defined by the 3rd Generation Partnership Project (3GPP). Our contribution provides a novel Framework for NS Subnet Management, called NESSMA, that satisfies a list of requirements derived from our vision on the end-to-end network slicing model detailed in chapter 2. The Framework is designed to jointly manage NS Subnets and their supported services having in mind its integration with NFV-MANO [START_REF] Chahbar | NESSMA: Network Slice Subnet Management Framework[END_REF].

The Inter-Slice Bandwidth Resource Sharing Mechanism

Our third contribution presents the inter-slice bandwidth resources sharing, a novel mechanism for NS resource optimization based on the IETF Common Operations and Management on network Slices (COMS) information model. A proof of concept (PoC) is realized to demonstrate the benefit of the proposed approach. To the best of our knowledge, our PoC, so-called InterS, is the first to implement the COMS data model and evaluate the performance of the concept via realistic intensive experiments in a Software Defined Network (SDN). Thus, InterS allows a congested NS to temporarily acquire all or a part of the free bandwidth resources of neighbor slices and use them to serve its own traffic. Experiments have shown that InterS can significantly improves the operator's network bandwidth usage as well as the flow acceptance rates. [START_REF] Chahbar | InterS: Towards Inter-Slice Bandwidth Resource Sharing[END_REF].

Thesis outline

Our thesis is organized as follows:

• Chapter 2: we provide an E2E 5G network slicing model based on an in-depth analysis of the modelization works published by the leading SDOs such ETSI, Global System for Mobile Communications Association (GSMA), 3GPP and IETF.

First, we start by providing a general architecture of network slicing common to the different SDOs. The latter serves as a stepping-stone to set the primary foundation of network slicing before diving deep into domain-specific visions.

Second, we explain the two different visions of ordering a NS among SDOs. Third, we detail exhaustively the network slicing process in each of the RAN, the Core and the transport networks. Last, we address some of the open standardization issues as well as the future research directions in this area.

• Chapter 3: we provide a list of requirements that should be satisfied by a NS subnet management framework. We derive the requirements as well as the design of the framework called NESSMA from an exhaustive analysis of up-to-date standards from 3GPP, ETSI and IETF SDOs. NESSMA is designed to manage NS Subnets as well as their supported services' life cycles taking into account its integration with NFV-MANO

• Chapter 4: we realize a proof of concept of the inter-slice bandwidth resource sharing approach based on the COMS NS information model. Our implementation is based on the modelization works presented in previous contributions. Our PoC, so called InterS, allows the instantiation of a NS either as exclusive or shared.

Our PoC includes two main implementations. The first one allows a congested NS to acquire free bandwidth resources from at most one neighbor NS. The second implementation, allows the congested NS to acquire and aggregate fragments of free resources from multiple neighbor NSs.

• Chapter 5: we conclude the thesis and discuss the perspective of our work. It summarizes the contributions, discuss the obtained results and highlights the remaining gaps that are subject to future investigations.

Introduction

Network slicing is an ongoing standardization work performed by different SDOs targeting each a specific part of the network slicing architecture. E2E NS implementations have to be aligned with the SDOs' standards particularly with the NS information models.

These models describe all the NS management entities as well as their relationships from the perspective of operators and service providers. Currently, an E2E network slicing model is not yet explicitly provided but need to be derived based on an exhaustive analysis of all the SDOs' contributions particularly their proposed NS information/data models to this day.

In our work presented in [START_REF] Chahbar | Towards a Unified Network Slicing Model[END_REF] we observed that the issued contributions may potentially be unified and represented in a common architecture and terminologies.

Network Slicing: A General Vision

This section provides the main NS workflows, functions, interfaces and the managed objects that are supposed to be common, to a large extent, to different SDOs, administra-tive and technology domains. The goal is to provide a general architecture that clarifies the basic E2E network slicing functionality before diving deep into domain-specific visions. The need for such a general vision was first identified by ETSI NGP workgroup and then led to the adoption of the reference network slicing architecture [START_REF]Next Generation Protocols (NGP); E2E Network Slicing Reference Framework and Information Model. Group report GR NGP 011[END_REF] depicted in Figure 2.1. This architecture comprises three actors:

• Tenants that consume the service supported by a NS. The service can itself be a NS, commonly known by the term NS as a Service (NSaaS).

• NS Providers (NSPs) that provide access to the NS instances.

• NS Agents (NSAs) that have the complete view and control of their own network domain. Firstly, a tenant prepares a service profile that describes its desired NS. It comprises a service graph and some additional service attributes such as the service type, service profile identifier and the service subscribing entity. The service graph, represents the tenant's view of the NS so that on the one hand it describes the nodes in terms of compute, storage and service instance type, e.g., firewall and load balancer. On the other hand it defines the edges as the slice constraints, also called slice characteristics such as link bandwidth and packet loss. Service endpoints are additional attributes of the service profile that describe the entry and termination point of a service. The tenant uses then that service profile to order the creation of a NS.

Within the NSP, the resource database (DB) aggregates the exposed topological information from several domains in the underlying infrastructure along with their constraints and their belonging domain as shown in figure 2.1. Therefore, the resources DB provides the NSP with the full view of the abstracted underlying physical infrastructure from many NSAs. At the NSA level, a resources broker is in charge of gathering the domain-specific topology information (links, nodes) along with the constraints such as links cost, bandwidth, and latency. Then, for security reason these topological data are abstracted and exported to the resources DB at the NSP domain. This is done through the subnet discovery function located in each NSA.

The NSP creates the NS Instance (NSI) as an instantiation of the service profile once received from the tenant. The new created object will represents the NSP's own view of the NS. In fact, the aim of the NSI is to compute the mappings of the service profile to the abstracted infrastructure elements stored in the resources DB taking into consideration the tenant constraints. This is done using the following two functions defined in the ETSI slicing architecture: the resources computation and NS mapping functions. Table 2.1 overviews the high level network functions performed by NSP and NSA of this architecture.

The bindings of the service graph to the physical resources are then stored in the runtime service context object within the NSI. The usage of the term NSI here is relative to ETSI NGP and is not aligned with the other SDOs. To clear up this confusion, it is necessary here to differentiate the term NS from NSI. The former is a definition of a logical network in terms of a managed set of resources and network functions. An NSI is an activated NS, a set of resources and network functions forming a deployed logical network that satisfies the tenant's service requirements [START_REF] Geng | Network Slicing Architecture. Internet-Draft draft-geng-netslicesarchitecture-02[END_REF].

After computation and mapping functions are successful, the final step, at the NSP level, towards the deployment of the NS is to distribute the so-called segments (also called subnets by other SDOs) to NSAs. This is done through the NS delegation function.

NS functions Brief description

Subnet Discovery

Exports an abstracted topology of the NSA domain to the resource DB.

Resource Computation

Determines the adequate resources for a specific service graph.

NS Mapping

Associates infrastructure elements with the logical ones.

NS delegation

Delegates segments to NSAs for mapping, encapsulation and segment interconnection.

Report aggregation

Monitor characteristics from different slice subnets for accounting and performance for business model.

Service assurance

Monitors each flow in a NS by NSP and takes decisions in order to provide service assurance.

Subnet augment

Allows the tenant to request an increase or a decrease of its allocated resources.

Providing that a NS may span across several NSA domains, a segment is the set of paths and nodes a NSI is allocating to a specific NSA. After a NSA receives the segment associated to a NS, it first computes the mapping of abstract to concrete resources from the subnet resource broker with the help of a child path compute element (PCE) and stores them on the subnet service context run-time object. NS segments are not meant to be deployed separately, they are all part of the same logical E2E NS. Hence, a NS Gateway is needed to perform segments interconnection. Also, its is exported as a node to the NSP during the discovery process with the next hop information pointing to the adjacent network domain.

The possible modes that describes the flow of tenant traffic within its assigned NS, as defined by the ETSI architecture, are threefold. First, E2E encapsulation where the tenant flow undergo the same encapsulation type such as MPLS, VXLAN, etc, along all the segments. Although, this mode appears to be simple, it does not promote the technology agnostic approach and leads to scale related issues. In contrast to the first mode, segmented encapsulation allow each NSA to independently choose its encapsulation technique. For example, the same tenant flow is encapsulated using VXLAN in some segment and MPLS in another one thanks to some of the NS Gateway functions [START_REF] Homma | Gateway Function for Network Slicing[END_REF].

Once a segment on a NSA's domain is successfully deployed, the resource broker inside the NSA updates the NSP information using the subnet discovery function.

Furthermore, service characteristics should be collected at each segment throughout the slice life-cycle, and then reported to the NSP. Collecting statistics and aggregating performance metrics about both the slice subnets and also the flows in the context of a NSI is the role of the report aggregation and the service assurance functions respectively.

They provide a complete E2E monitoring framework for accounting, performance, Quality of Service (QoS) of the business model and service assurance.

Network slicing includes also exposing the capability to the tenant in order to scale up or down its allocated resources at run-time. This resources augmentation is performed by the subnet augment function. A tenant augment request may be a change on the latency constraint from 10 ms to 5 ms for instance. This may lead to some additional operations that could affect the system stability. In particular, if the current path does not support the new latency constraint, the operations include setting up a new path to meet the new requirements, then moving flows from the older path to the new one and finally deprovisioning of the participating nodes in the abandoned path.

The subnet augment function requires a set of operations and corresponding interface to the underlying infrastructure. These are covered by the tenant operated network service function. For example, the tenant uses the "augment" operation to modify its constraints associated with a path or a node in the service graph.

To conclude, the ETSI network slicing architecture, following the NGMN conceptual outline [START_REF]Description of network slicing Concept[END_REF], includes three layers: a service layer where the service graph is built, then the NS instance layer where the service graph to abstract resources mappings happens and lastly the resource layer where segments are delegated and deployed on the underlying infrastructure. Concerning the NS life-cycle, we can refer to the 3GPP specification that considers 4 phases: Preparation phase including design and pre-provisioning, an "instantiation, configuration and activation" phase, a run-time phase including supervision and reporting, as well as upgrade, reconfiguration and scaling, and a decommissioning phase. These phases are similar for all the SDOs.

Ordering a NS: Service Graph or NS Template ?

In the ETSI NGP architecture, the tenant is not necessarily an end customer, it may play the role of a service provider that offer its own services on top of the ordered NS instance (NSaaS model). This explains why the tenant is ordering a NS and playing in some sort the same role as the NSP. However, an end customer is rather interested in the fulfilment of a service whether it is supported by a NS in the underlying infrastructure or not.

While the ETSI NGP uses a service graph to order a NS, GSMA has entirely a different vision. GSMA is investigating all the potential service attributes, also called NS characteristics, from several enterprises and vertical industries, and gathering them in a template called Generic Slice Template (GST). The goal is to define a template (see table 2.2) that helps both the NS customer (NSC) and NSP to identify a NS [START_REF]5G network slicing Report: From Vertical Industry Requirements to NS Characteristics[END_REF].

The GST will be used as a reference by vendors, operators, providers and customers in order to deploy a NS that accommodate a certain use case. Thereafter, to order the deployment of a NS, a NSC needs to fill some or all the GST template attributes with its desired values and/or ranges depending on the NS use case. The obtained template is then called NEST (NS Type).

NS templates Brief description

GST A template containing a set of attributes that characterize any slice.

NEST A GST filled with values to define and identify slices.

S-NEST

A NEST template that defines a standardized slice.

P-NEST

Operator-specific NEST created based on negotiation between an operator and its customers.

In fact, the GSMA approach has several advantages. First, it gives the mean for a NSC to express its NS service requirements and at the same time allows operators and providers to fulfill any possible use case. Second, Standardized slice types (SSTs)

are defined for the most popular use cases in standard NEST templates (S-NEST)

and diffused to all operators around the world. Third, service capabilities offered to a user inside its home operator are conserved when it roams to a visited network. This could simply happens by exporting the NEST templates from the home network to the visited one. That is, NEST is a generic template that aims at describing the service requirements of a use case that will later help an operator to select an appropriate NS template (NST) [START_REF]5G network slicing Report: From Vertical Industry Requirements to NS Characteristics[END_REF] [27] also referred to as NS blueprint in [START_REF]Description of network slicing Concept[END_REF].

The NST contains the network functions, their interconnections and the necessary configurations to meet the service requirements described in the NEST. As it is depicted in figure 2.2, a NST may correspond to one or multiple NESTs and is further instantiated to realize a NSI. The detailed list of all the GST attributes as well as their explanations are provided in [START_REF]Generic NS Template[END_REF].

After this introduction of the network slicing general vision and how ordering a NS can be done with the use of the service graph or the NS template. The next section, will provide an in-depth exploration of the E2E network slicing information models within the RAN, CN and TN specific domains.

Network Slicing: A Domain-Specific Vision

For a given 5G customer service, an E2E NS that spans across the RAN, the CN and the TN needs to be established. Following the set up of the RAN and core sub-slices (subnets) by the 3GPP orchestration system, one or many transport NSs (TNS) has or have to be provisioned within the TNS provider as a set of connections with Service Level Agreements (SLAs) that connects together RAN and core sub-slices [START_REF] Rokui | IETF Definition of Transport Slice[END_REF].

RAN and CN

RAN and CN slicing is still under standardization by 3GPP. In fact, 3GPP is tremendously contributing to the NS standardization work through several working groups particularly SA1 (service requirements), SA2 (Architecture), SA3 (Security), SA5 (Network Management). In order to get deeper insights on NSs, their implementation and life-cycle management we focus in this section on the 3GPP NS information model [START_REF]Management and orchestration; 5G Network Resource Model (NRM); Stage 2 and stage 3, version 15.5[END_REF].

The SA5 group has defined the entities that compose a NS and the way they interact with each other using the information model depicted on figure 2.3. The NS also makes reference to its constituents subnets (this term is interchangeable with segments) which may recursively be composed of other subnets. Likewise, several slice profiles are associated to each subnet. The reason behind the modelling of a NS/NS subnet supporting multiple service/slice profiles is that multiple communication services may share the same NS. The data model describing all the entities in figure 2.3 except the ones in dark color are given in yang data modeling language in 3GPP TS 28.541 [START_REF]Management and orchestration; 5G Network Resource Model (NRM); Stage 2 and stage 3, version 15.5[END_REF].

The service profile has many common attributes with the slice profile, some of them have reference in GSMA GST such as User Equipment (UE) mobility level.

A NS subnet, that aggregates a list of managed functions, is supported by at most one network service. A managed function is realized by one or many virtualized network functions (VNFs). A network service is a composition of the subnet's VNFs and PNFs (physical network functions) according to one or many forwarding graphs. The entities network service, VNF and PNF are out of the scope of 3GPP working groups. Thus, their descriptions are delegated to ETSI NFV-IFA VNF and network service information models [31] [32].

The 3GPP NS information model's entities are consumed, managed and provided by different actors. Each actor may play more than one role depending on the NS management use case. 3GPP has defined three main NS management roles (see table 2.3):

Communication Service Customer (CSC), Communication Service Provider (CSP) and Network Operator (NOP). Network-as-aservice Provider

Network Operator Provides NS and NS Subnet(s).

There are other business roles defined by 3GPP in [2] such as hardware supplier, NFVI supplier, network equipment provider, data center service provider, and virtualization infrastructure service provider.

A business agreement must be created between two actors in order to interact with each other. Commonly, real NS management use cases includes actors having multiple roles, therefore reducing the number of needed mutual relationships. For example an actor "NS Tenant" may simultaneously plays both the role of a Communication Service Customer (CSC) and a Communication Service provider (CSP).

The deployment and management of a NS in a NOP's infrastructure based on the customer's SLA are performed by three main 3GPP functions as illustrated in Mobile Network (PLMN). This is to say that a NSI is defined in one operator while its constituents NSSIs may be associated from different ones. Communication Services are generally managed by a CSP but might also be managed by the customer or the NOP so that there is a direct communication interface between them. Therefore, the CSMF might be placed at each of the CSP, the customer or the NOP depending respectively on the previously mentioned options.

The 3GPP NS information model defined in [START_REF]Management and orchestration; 5G Network Resource Model (NRM); Stage 2 and stage 3, version 15.5[END_REF] lists all the attributes defining NSs. In the following of this section, we introduce the most relevant attributes for the understanding of the 3GPP network slicing vision. In the 3GPP data model, a NSI refers to a unique NSSI through the NetworkSliceSubnetRef attribute instead of multiples NSSIs. This is due to the modelling of each of the NS and the NS Subnet entities. As shown in figure 2.3, a NS is modelled as being composed of a unique NS Subnet.

A NSI may be well deployed and working but administratively configured by the operator to not serve any user [START_REF]Telecommunication management; State management data definition Integration Reference Point (IRP); Information Service (IS)[END_REF]. Therefore the state of a NSI/NSSI is described by two attributes, the operational state and the administrative state.

A NS Subnet refers to its constituents subnets and supported managed functions respectively through the NetworkSliceSubnetRef and ManagedFunctionRef attributes.

The NSInfo attribute provides real-time information of a NSI that corresponds to a NSSI. This attribute contains many information such as the reference to the flavour of the network service descriptor (NSD) used to instantiate the network service and the reference to all information on network service's constituents VNFs and PNFs. An exhaustive definition of all the information provided by the NSInfo attribute is given by ETSI GS NFV-IFA 013 [START_REF]Management and Orchestration; Os-Ma-Nfvo reference point-Interface and Information Model Specification[END_REF].

A same NS service may be provided by different operators so a user may roams from its home PLMN to one or multiple serving PLMNs without any service interruption.

The PLMNs that support a NS or a NS subnet are identified respectively in each of the service profile and the slice profile as PLMNIdList.

The service profile includes the attributes of the slice profile in addition to the the SST and the NS availability attributes. The SST refers to the expected NS behaviour in terms of features and services [START_REF]System architecture for the 5G System (5GS)[END_REF] 3GPP distinguishes three options for the definition of a S-NSSAI that is comprised of:

• A standardized SST value and no SD.

• A standardized SST value and a SD.

• A non-standardized SST value and no SD.

The service and slice profiles are comprised of a collection of S-NSSAIs values also referred to as a NSSAI. The later indicates the different NS behaviours that can be accommodated by the NS/NS subnet. An NSSAI may be configured, requested or allowed.

A given user can have at most eight S-NSSAIs. During the registration procedure, the UE includes an NSSAI in its request to the PLMN. The later verifies the requested NSSAI against the subscription information. If the match is successful, the UE obtains the allowed NSSAI from the PLMN which may include one or many S-NSSAIs. In addition, the latter can be used simultaneously by the UE. Finally, a NS and a NSI can now be selected for that UE. Also a service/slice profile includes a list of performance requirements that are defined for each standardized SST value (e.g., low latency and high reliability) [START_REF]Service requirements for the 5G system[END_REF]. In addition, they comprises other characteristics that can be considered as NS/Subnet-level attributes such as Maximum Number of UEs, UE mobility level, latency [START_REF]Management and orchestration; 5G end to end Key Performance Indicators (KPI)[END_REF].

Transport Network Slicing

Definition

A transport NS provides a set of connections between a group of VNFs or/and PNFs from both the RAN and the CN. Each connection has its own deterministic SLAs and is implemented in the underlying transport network (TN) using any technology type (IP, optics, microwave, etc), any tunnel type such as IP/MPLS and any Layer service type (L0, L1, L2, L3).

Depending on the RAN deployment, there might be multiple transport sub-slices per a single E2E NS:

• In the case of the distributed RAN deployment, in addition to the TN connecting together the RAN and the CN, another TN (i.e., Internet) connects the users' mobile applications to the CN. This is a common deployment in 4G and 5G networks.

• An additional transport network is introduced in the case of the centralized RAN (C-RAN) between the RAN's two functional units, the base-band unit (BBU) and the radio unit (RU), called Front-haul network. The BBU is further divided in the case of cloud RAN to include two separated units called the centralized and the distributed units (CU and DU). The former is hosted in the cloud while the latter remains close to the antenna. An additional transport network is then introduced in this case called Mid-haul in order to connect the DU to the CU.

In total, there might be a maximum of four transport sub-slices (Figure 2.5) per an E2E NS depending on the aforementioned deployment options [START_REF] Rokui | 5G Transport Slice Connectivity Interface[END_REF].

Network slicing standardization in the transport domain is under the IETF realm.

Actually, continuous efforts are being made to model the network slicing technology and consequently to define a standardized architecture in the TN domains. In fact there are multiple mechanisms and data models covering different parts of the transport domain architecture that may be applied to the network slicing use case. However, there is no consensus within IETF on the use of this model or that one. In addition, it is not clear how they can be applied to network slicing. In the remaining of this section, we will list in a technology-independent manner all the candidate works within IETF that have the potential to accommodate network slicing in the the TN domain. Then, in the next section we will present our vision in this context.

ACTN Architecture

The most likely candidate architecture to accommodate network slicing is the one of the Abstraction and Control of Traffic Engineered (TE) Networks (ACTN) defined by the IETF TEAS (Traffic Engineering Architecture and Signaling) workgroup in [START_REF] Ceccarelli | Framework for Abstraction and Control of TE Networks (ACTN)[END_REF]. ACTN is a set of management and control functions that facilitates the presentation of virtual networks built from abstractions [START_REF] Farrel | Problem Statement and Architecture for Information Exchange between Interconnected Traffic-Engineered Networks[END_REF] The information exchanged in each of the cited interfaces are governed by a set of data models [START_REF] Pras | On the Difference between Information Models and Data Models[END_REF] structured by IETF into yang language modules. These models are in this chapter the network slicing concept is surveyed in a technology-independent way, those models will not be covered in the following of this section. However, we will address all the other data models that we consider as enablers of the network slicing technology located in either the CMI or the MPI. Then, in section 2.6 we will explain our vision on how they may relate to each other in order to instantiate and manage NSs.

The CNC request the instantiation of a Virtual Network Service (VNS) to the MDSC via the CMI interface. The MDSC is at the core of the ACTN model obviating the need of the underlying technologies for network and service control while helping the E2E NS consumer to express the desired TNS by the mean of SLAs. This is achieved in the MDSC by the implementation of network-related functions such as multi-domain coordination, abstraction and service-related functions like service mapping/translation and virtual network service coordination.

From a bottom-up perspective, each PNC exposes an abstracted topology to the MDSC. The MDSC merges then all the advertised topologies at the MPI into its native network topology. Therefore, the MDSC provides an abstracted topology based on its view to the customer. It is worth mentioning that a hierarchy of MDSCs is very likely to be envisaged in real world deployments. In that case lower-level MDSCs (MDSC-Ls) are connected to higher-level ones (MDSC-Hs) using the MPI interface.

Likewise, each MDSC-L advertises an abstract topology to the MDSC-H. The PNC may be implemented as an SDN controller, e.g., an active PCE-based or P4 controller to dynamically manage a network domain. We note that the ACTN Framework resumes most of the NS functions defined in section 2.2 by ETSI NGP with more focus and details on the abstraction functions.

TE Topology Model [44]

The TE topology model describes the provider's data store of abstract TE topologies provided to customers independently to any specific underlying technology. Indeed, a TE topology may be hierarchical so each network element of an overly topology is mapped to the next underlay topology until reaching the provider's native one. Within the data store, a TE topology comes with a set of TE informations related to nodes and links that are used for the selection of a TE path. Certain TE information along with the provider's policy or a negotiated customer-provider policy (bandwidth, shortest path, etc) are given as inputs to the abstraction process in order to produce selective information representing the potential ability to connect across the domain [START_REF] Farrel | Problem Statement and Architecture for Information Exchange between Interconnected Traffic-Engineered Networks[END_REF].

The Virtual Network (VN) Model [45]

In the ACTN architecture, a type 1 and type 2 Customer VNSs allow respectively the creation of type 1 and type 2 VNs defined by the VN model. A type 1 VN is a set of edge-to-edge abstract links (also called VN members) modelled as an abstract node along with a set of Virtual Network Access Points (VNAPs). In a type 2 VN, the provider disclose a detailed abstract topology as an underlay to the one abstract node, allowing customers to configure explicit path for some of the VN members.

The COMS Data Model [46]

An other data model outside the IETF TEAS working group called COMS [47] [48] is proposed for the technology-independent management of NSs. Similar to the TE topology model, COMS augments also the data model for network topologies [START_REF] Clemm | A YANG Data Model for Network Topologies[END_REF] but with the essential entities facilitating configuration of QoS, reporting of statistics, QoS threshold monitoring, services instances, and description of compute and storage resources. As a result of the last augmentation, a node will make references to a list of compute units, storage units and service instances (e.g., firewall and load-balancer). This is illustrated in figure 2.7 with dashed arrows. Also, a termination-poin entity is described with configuration and statistic attributes. Lastly, a link is augmented with QoS attributes. The content of the augmenting entities is listed in table 2.5.

The TE Tunnel Data Model [51]

Categorized as a network configuration model, it describes the PNC's TE tunnel data store as it is seen and influenced by the MDSC. The later computes a VNS against the abstract view provided by the PNC then request the instantiaion of the computed TE links as TE tunnels in the PNC's domain.

The Performance Telemetry Data Model (PTISA) [52]

The transport NS consumer may want to subscribe to the monitoring of a set of Key Performance Indicators (KPIs) of its interest at the NS level (VN 1 type). For this aim the PTISA model can be used. Performance Telemetry data in the PTISA is divided into VN-level and tunnel-level data. Hence, The VN and the tunnel models are separately augmented with KPI telemetry data.

The ACTN Common Interfaces Information Model (ACTN C2IM) [53]

Finally, the ACTN C2IM models the CMI and MPI by providing respectively their required VN and TE tunnel primitives.

Our Vision on the E2E 5G Network Slicing Model

In this section, we look at the aforementioned studies described in section 2.4.2 as foundations of the network slicing technology in the transport domains. Therefore, we provide our vision on the network slicing architecture in the TN domain by analysing and explaining, in a technology-independent manner, how the different models and techniques work together within the ACTN framework in order to provide TNS services.

Then, our vision on the TNS customer service model is provided. Finally, a unified E2E 5G network slicing architecture is proposed based on the different outputs of the SDOs. Examples of customer service models include L2SM [START_REF] Wen | A YANG Data Model for Layer 2 Virtual Private Network (L2VPN) Service Delivery[END_REF] and L3SM [START_REF] Wu | YANG Data Model for L3VPN Service Delivery[END_REF] which allow respectively the presentation of L2VPN [START_REF] Himanshu | YANG Data Model for MPLS-based L2VPN[END_REF] and L3VPN [START_REF] Jain | Data Model for BGP/MPLS L3 VPNs[END_REF] services to a customer by an operator.

Enable Network Slicing Within the ACTN Framework

In alignment with the service model architecture provided in the context of SDN in [START_REF] Wu | Service Models Explained[END_REF], we adopt the functional split of the MDSC between a service orchestrator (SO) Customer service models and service delivery models are sub-types of the service model. In general, the latter describes the service in a technology-agnostic way so that the customer has no knowledge of how the service is engineered in the underlying technologies. However, the level of service abstraction at the SO-NO interface is lower in comparison to the CMI. Particularly, a service delivery model is network centric and may be aware of many features such as topology, technology and operator policy [START_REF] Wu | Service Models Explained[END_REF].

The service orchestrator communicates the computed TNS (based on its abstract view) to the network orchestrator as a VN over the SO-NO interface. Recursively, the network orchestrator segments the virtual network service received on its northbound interface then requests the instantiation of the resulting virtual services to the concerned PNCs over the MPI. This is done using network configurations models. The PNC configures and manages the resources under its control domain. It establishes the tunnels in the network infrastructure as part of the virtual service segment received at the MPI.

It is important to note that the transport slice service received by the MDSC at the CMI is progressively mapped and translated at each layer until its realization as connectivity tunnels in the underlying infrastructure. The multi-layer/multi-domain service mapping function addressed here is an essential brick of the network and service automation architecture [START_REF] Wu | A Framework for Automating Service and Network Management with YANG[END_REF]. Indeed, the later is to be bound to the ACTN framework for the sake of network slicing fulfillment.

The data models needed to support the ACTN architecture in order to enable network slicing can be as follows:

i. The yang data model for TE topologies [START_REF] Liu | YANG Data Model for Traffic Engineering (TE) Topologies[END_REF] to support the ACTN abstraction function.

ii. The yang data model for VN operation to request the instantiation of the TNS and its constituent subnets [START_REF] Lee | A YANG Data Model for VN Operation[END_REF].

iii. The technology independent information model for common operation and management of network slicing (COMS) [START_REF] Qiang | Technology Independent Information Model for Network Slicing[END_REF]. iv. The NS Subnet stitching data model [START_REF] Xavier De Foy | Interconnecting (or Stitching) Network Slice Subnets. Internet-Draft draft-defoy-coms-subnet-interconnection-03[END_REF].

v. The yang data model for TE tunnels and interfaces [START_REF] Saad | A YANG Data Model for Traffic Engineering Tunnels, Label Switched Paths and Interfaces[END_REF].

vi. The yang data models for VN and TE-tunnel performance telemetry and scaling intent autonomics (PTSIA) [START_REF] Lee | YANG models for VN/TE Performance Monitoring Telemetry and Scaling Intent Autonomics[END_REF].

vii. The ACTN common interfaces information model (ACTN C2IM) [START_REF] Lee | Information Model for Abstraction and Control of TE Networks (ACTN)[END_REF].

In the context of network slicing, the TE topology model is used at MPIs, the SO-NO interface as well as the CMI. We consider the TE topology as an auxiliary model for the service delivery and the customer service models.

According to both 3GPP and GSMA, the NSP orders a NS service using a set of Service Level Specifications (SLSs), also called NS related requirements, without specifying any service graph. It comes to the NOP to map those SLSs, using the NSMF, to RAN/CN/TN slice profiles. The NSSMF of each domain is then the responsible for translating those profiles to topology and network service models to be instantiated in the underlying infrastructure.

Following the same modeling, a transport slice profile should be defined in terms of a set of parameters, metrics and thresholds, along with the customer (operator) access points of the transport slice service. Therefore we believe that there is no need for a service graph in the customer service model but a type 1 VN. This is referred to as a type 1 virtual network service (VNS) in the ACTN framework.

A type 1 VN is the easiest way for customers to express E2E connectivity so they do not deal with service graphs or any technical detail. Consequently, in addition to the slice profile, the customer service model has to refer to an abstract node with the different VNAPs along with a connectivity matrix. The use of the VN model in the ACTN is addressed only at the CMI. However, we propose to use it also at the SO-NO interface allowing the service orchestrator to request the instantiation of a VN to the network orchestrator. In addition, the VN model needs to be used in an eventual implementation of layered MDSCs at the MPI interface between a MDSC-H and MDSC-Ls in order to segment the VNS to NS subnets. Clearly, the VNS used outside the CMI is of type 2 (more concrete than Type 1). We consider the VN model as a service delivery model. Indeed, it relies on the TE topology model to refer to a VN abstract topology. This is achieved in the yang module using the attributes: vn-topology-id and abstract-node.

Since we categorize the COMS data model as service delivery model, it becomes necessary to explain the specificities of this model in comparison with the VN and the TE topology ones. We show in figure 2.10 how all of them can be integrated together in the whole network slicing process. The COMS model comes with a new data store which provides a complete and unified view of NSs. Without COMS, a NS is stored in the TE topology data store and there is no way to recognize it as slice only through the VN data store. However, the VN model provides only a mechanism for VN instantiation and does not include NS provisioning and management operations. Furthermore, managing a NS as TE topology is a heavy task because of its numerous contained TE information necessary to compute a NS but useless for its maintenance and life-cycle management.

Another strong point about COMS is its integration with the ETSI NFV MANO (management and orchestration) framework so that it describes compute, storage and network resources relayed on by the VNFs purchased with a NS [START_REF] Geng | COMS Architecture. Internet-Draft draft-geng-coms-architecture-02[END_REF] [START_REF] Qiang | The Use Cases of Common Operation and Management of Network Slicing[END_REF].

For all these reasons, we propose to use the TE topology model only for the provider's domain abstractions and the computation of a NS based on the received customer service In this context, an ongoing project is recently lunched under the opensource Open Network Operating System (ONOS) controller in partnership with several telecom operators (e.g., Huawei and SK Telecom) [START_REF]ONF's ACTN (Abstraction and Control of TE networks) project[END_REF]. It aims at the implementation of the ACTN framework. Since the project is not intended in a first place for TNS implementation it is actually involving only the TE topology and the TE tunnel yang data models. Nevertheless, the framework if extended by a NS engine and an implementation of the COMS and the VN models, can serve as a reference platform for the TNS experimentation.

Afterwards, the VNS (type 2) received by each low level MDSC is mapped to the tunnel network configuration model [START_REF] Bryskin | TE Topology and Tunnel Modeling for Transport Networks[END_REF] so that one or multiple tunnels are sent to the concerned PNCs in order to be deployed in the underlying domains.

Finally, the MDSC-H requests the subscription for subnets level (VN 2 type) telemetry data from multiple MDSC-Ls. Recursively, the MDSC-L maps the received VN KPI telemetry subscription request to multiple tunnel KPI telemetry subscription requests sent to one or many concerned PNCs. Besides, tunnel telemetry data is derived from low-level data collected via performance monitoring counters in network elements and pulled up to the PNC using the device configuration model. Moreover, the PTISA model provides a mechanism for the CNC, the MDSC-H and the MDSC-L to respectively configure automatic scale-in and scale-out of a NS (VN type 1), a NS subnet (VN type 2) and a TE tunnel.

TNS Customer Service Model

Section 2.4 rises an important question about the customer service model that should be used to order NSs: Does it carry a service graph as stated by ETSI NGP or rather a NS template as affirmed by GSMA? This is the major difference between SDOs' vision.

3GPP is aligned with the GSMA vision and is already considering many of the GST attributes in the definition of its service/slice profile. Table 2.6 lists those commonly used attributes and their reference to GSMA GST fields. Another transport slice data model is proposed in [START_REF] Liu | IETF Network Slice YANG Data Model[END_REF] in order to support network slicing as a service between a customer and a provider. The later augments the data model of network topologies. Truly, after the request of a NS service and that later is implemented in the underlying network infrastructure, the TNS provider is required to expose the NSI management capability to the customer for operational state retrieval and any augmentation in the NSI resources. The transport slice data model provide the means to serve that goal. The model operates at the CMI, and may be considered as service customer model to be activated after the creation of the NSI for management capability exposure purposes.

Furthermore, an analysis was performed on the GST's 35 attributes in order to decide on their impact on the transport network since some of them target either the RAN or the CN [START_REF] Luis | IETF Network Slice Use Cases and Attributes for Northbound Interface of IETF Network Slice Controllers[END_REF]. The end goal is to define the functionality required on the northbound interface of the MDSC (CMI). As result, GSMA GST attributes were categorized as directly impactive, indirectly impactive and non-impactive attributes. This work is definitely an important step toward the definition of a NS customer model.

We believe that the TNS provisioning request at the CMI is an abstract intentbased request following the same modeling of 3GPP in the provisioning of RAN and CN sub-slices. Thus, the NS customer service model would be based on GST SLAs, most likely the ones with direct impact on the transport network, along with customer endpoints as explained in section 2.4.2. Further, this model may be augmented with the TE service mapping model [START_REF] Lee | Traffic Engineering and Service Mapping Yang Model[END_REF] as proposed in [START_REF] King | Applicability of Abstraction and Control of Traffic Engineered Networks (ACTN) to Network Slicing[END_REF]. The goal is to record the mapping between a requested NS service and its instantiation in the underlying infrastructure in terms of either a VN, a TE topology or tunnels. This will allow to view the NS service instantiations outside the MDSC from either an operator for diagnostics purposes or to give an idea to customers on how their services are instantiated in the transport domains.

Another point, we propose to use the TE topology model only for the provider's domain abstractions and the computation of a NS based on the received customer service model. The TE computed network can be then stored in the COMS data store with the augmenting entities resumed in section 2.4.2.5 as a NS. This how the COMS service delivery model is derived from the customer service one. In the network slicing case, instead of pointing out to a TE topology, the VN model refers to the COMS topology network at the SO-NO interface for the provisioning and management of a NS.

Finally, the discussion on the TNS provision model is an open topic within IETF and requires more feedback and reviews from standardization bodies and vertical customers.

Currently, three NS provision models are envisaged: The SaaS-like, the PaaS-like and the IaaS-like models [START_REF] Homma | Network Slice Provision Models[END_REF]. The former is the model adopted by GSMA and 3GPP to respectively request and provide a NS service. In the PaaS-like model the tenant's request carries a representation of the NS as a set of nodes, their interconnections along with connectivity configurations. This is aligned with the ETSI NGP vision.

Tenants in the IaaS-like model have direct control over the underlying infrastructure so they order NSs with concrete resource configurations. The latter model is not aligned with the common network slicing vision. Yet, no use case was cited in the related work in order to prove its usefulness. Table 2.7 summarizes the aforementioned similarities and differences between the different SDOs'visions. Regarding the service order management, the REST open API specification provided by the TM Forum can be used to place an order at each of the CMI as well as the interface between the E2E NSC and the NSP (operator) [START_REF][END_REF]. Also, authors in [START_REF] Boucadair | Dynamic Service Negotiation: The Connectivity Provisioning Negotiation Protocol (CPNP)[END_REF] have provided a specification of Connectivity Provisioning Negotiation Protocol (CPNP) which is meant for exchanging and negotiating dynamically connectivity provisioning parameters between a customer and a provider (or only between providers). By comparison to the TM Forum REST API, this protocol introduces the concept of "Offer" that allows the service provider to accommodate received orders beyond monolithic yes/no answers. CPNP can also be used at the aforementioned interfaces to order a NS service.

Towards a Unified Network Slicing Model

We have observed that the issued standards are generally completing each other and may potentially be unified as presented in our work published in [START_REF] Chahbar | Towards a Unified Network Slicing Model[END_REF]. In this context, ETSI ZSM workgroup is building an E2E NS federated solution [START_REF]Zero-touch Network and Service Management (ZSM); End to end management and orchestration of network slicing[END_REF] by making use of all the aforementioned outputs from ETSI, 3GPP, IETF and GSMA and stitching them to the ZSM architecture [START_REF]Zero-touch network and Service Management (ZSM)[END_REF]. For instance, 3GPP has introduced interesting concepts for the RAN and the CN that could be mapped and applied to the transport network such as NSMF/NSSMF, service/slice profile, NSI/NSSI. All those terminologies could be mapped to the TN so that we define the transport-NSSMF, transport slice profile, and transport NSSI as illustrated in figure 2.11. Finally, a NS life-cycle management REST API [START_REF]G riders on the storm catalyst[END_REF] is developed by the 5G riders on the storm catalyst [START_REF]Catalyst projects, 5G riders on the storm catalyst[END_REF] and provided as a proposal to the TM Forum (API-1284). The latter binds together the data model work from 3GPP SA5, a JSON version of the GST and TM Forum API guideline.

Since orchestration is a key enabler of Network Slicing, we map the major SDOs'aforementioned contributions to the End-to-End Management and Orchestration reference architecture (MANO) [START_REF]View on 5G Architecture version 1.0[END_REF], proposed in the context of the 5G Exchange project, as depicted in We propose by this figure an architecture that binds together all the standardization works on network slicing including NS informations models. The end goal of this first proposal is to clarify our vision on the E2E network slicing process from the service order request to the NS deployement and management.

Challenges and Future Research Directions

In this section, we discuss some open issues related to the GSMA GST template as well as we highlight the security and isolation problem brought by the network slicing technology.

Enhancing the GST

The 5G riders on the storm catalyst project promoted by the TM Forum [START_REF]Catalyst projects, 5G riders on the storm catalyst[END_REF] have a different vision on how the GST should be structured based on its ongoing demonstrations as well as the Huawei's operational experience with NS management. The project focuses on an operational NS use case that support emergency services provided to first responders during extreme weather events such as flooding or storms. As a result a reviewed GST [START_REF]5G riders on the storm catalyst. A JSON version of the GSMA GST[END_REF] is proposed that includes the following contributions: iv. The catalyst is also enhancing the GST with new attributes from NGMN and 3GPP such as the use case type and activity factor.

v. All the GST attributes are reorganized into profiles.

NS Security and Isolation

Nevertheless, the network slicing concept brings new security issues. In particular, providing and demonstrating the adequate NS isolation level is one of the biggest challenges faced by the 5G operators [START_REF] Kotulski | On end-to-end approach for slice isolation in 5G networks. Fundamental challenges[END_REF]. In fact, 3GPP architecture demonstrates a requirement for authenticating users of network slice resources. There is however a need for separate per-slice security policies, e.g. having different authentication requirements between IoT and broadband. Inter-operation between NSs is a major issue related to VNFs isolation at L2 or L3 levels. Moreover, the IETF COMS model already presented in details in section 2.4.2.5 includes a set of isolation attributes covering the following areas: traffic, bandwidth, processing, storage. However, COMS is not a customer-facing model.

According to GSMA, a NS instance may be fully or partly, logically and/or physically, isolated from another network slice instance. These properties are included in the GSMA GST under the "isolation level" attribute. Finally, the NSP has to assure the NSC with evidence that confirms the NS isolation existence. This should be achieved by the measurements of the isolation properties in the operator's infrastructure as well as NS orchestration functions such as the report aggregation and service assurance functions proposed by ETSI NGP. The IETF PTSIA model may also be used to verify NS isolation since it allows a NSC (operator) to subscribe to transport NSs and NS subnets telemetry data. This is an interesting and complicated research direction that should be coupled with the frameworks designs in the future.

Conclusion

In this chapter, current NS modellings works in RAN, CN and transport network domains were bound together in order to bring forth the implicitly expressed 5G E2E network slicing model from the SDOs' technical specifications.

We started by introducing the network slicing general vision and how ordering a NS can be done with the use of the service graph. An in-depth exploration of the E2E network slicing information models within the RAN, CN and TN specific domains is then provided. We have analyzed and resumed most important models, their attributes and functions that are required for maintaining NSs at all its possible life-cycle phases.

We tried to simplify the comprehension of all the complicated operations and the relationship between the elements of different layers or different domains via tables, figures and diagrams accompanied by brief descriptions. Our vision on how all these models and frameworks can be merged, completed and augmented together for an efficient E2E network slicing management has been proposed that is the real benefit of this work.

Introduction

According to the standardization activities mainly driven by 3GPP, ETSI and IETF, an end-to-end NS instance may span across multiple network domains. In that case, the end-to-end NS is composed of multiples NS instances running each on a specified domain. The single domain NS instances called "NS Subnets" cannot run separately from each other and are interconnected using NS gateways [START_REF] Homma | Gateway Function for Network Slicing[END_REF] in order to form the end-to-end NS.

In addition, the aforementioned SDOs'activities [START_REF] Flinck | Network Slicing Management and Orchestration[END_REF], [2], [START_REF]Concepts, use cases and requirements[END_REF] on Network Slicing state that the NS Subnet Management Function (NSSMF) is performed separately from the NS Management Function (NSMF). However, prior works do not include any demonstration for the NSSMF as well as current experimentations of NSs do not highlight this separation neither clarify the scope of the two functions on their architectures [START_REF] Kukliński | A reference architecture for network slicing[END_REF]. Furthermore, understading the NSSMF as well as the implementation of its internal components is necessary to build a resource-facing NS solution.

Therefore, the aim of this chapter is to realize the NSSMF by providing a novel framework founded on a set of requirements derived from an exhaustive analysis of up-to-date standards from 3GPP, ETSI and IETF (Section 3.2). The framework is designed to manage NS Subnets as well as their supported services'life cycles taking into account its integration with NFV-MANO [START_REF]Group specification GS NFV-MAN 001[END_REF] (Section 3.3).

This chapter is organized as follows. Section 3.2 list all the requirements that need to be fulfilled by the NESSMA framework. Section 3.3 explains the NESSMA overall architecture then provides its system design. Section 3.4 concludes the chapter.

Requirements on the NESSMA Framework

The NESSMA framework is based on the E2E MANO reference architecture as well as the ETSI umbrella NFVO implementation option both explained in section 1.1.4. The NSSMF is realized by the resources and the single-domain orchestration layers of the E2E MANO architecture. Its scope is highlighted in green color in figure 3.1.

In this section, we discuss all the requirements related to the NSSMF that need to be satisfied by our framework. They are derived from our vision of the E2E network slicing model presented in the previous chapter. [START_REF]Next Generation Protocols (NGP); E2E Network Slicing Reference Framework and Information Model. Group report GR NGP 011[END_REF], [START_REF] Xavier De Foy | Interconnecting (or Stitching) Network Slice Subnets. Internet-Draft draft-defoy-coms-subnet-interconnection-03[END_REF]: Concatenating Subnets with each other is inevitable in order to form the end-to-end slice. NS Subnets are not meant to be deployed separately, they are all part of the same logical network (NS). Hence, the ETSI as well as other SDOs have defined the term Network Slice Gateway to refer to the logical node that mainly performs Subnets interconnection.

NS Subnet Stitching

4. Subnet Encapsulation [START_REF]Next Generation Protocols (NGP); E2E Network Slicing Reference Framework and Information Model. Group report GR NGP 011[END_REF]: In order to achieve service isolation between slices (thus Subnets), an encapsulation (e.g., MPLS, VXLAN, etc) need to be set for each tenant by the NSA. Two possible encapsulation modes are envisaged: End-to-end encapsulation and Segmented encapsulation. Traffic flow may also be forwarded without any encapsulation across all the Subnets with only egress and ingress port mappings with consideration for slice constraints.

5. Subnet monitoring [START_REF]Next Generation Protocols (NGP); E2E Network Slicing Reference Framework and Information Model. Group report GR NGP 011[END_REF], [START_REF] Qiang | Technology Independent Information Model for Network Slicing[END_REF]: The goal of monitoring is to support accounting and charging operations as well as provide service assurance by continuously reporting any violation of an already set threshold parameter within the Subnet, such as the packet loss, the availability (of NS), the link throughput and jitter associated to a NS. [START_REF] Qiang | Technology Independent Information Model for Network Slicing[END_REF]: ports in each node (e.g., switch, router) participating in the Subnet are configured with packet rate, packet loss probability. Statistics include the number of received and sent packets in a period of time for each port participating in the Subnet. Also, it covers the current throughput, latency and jitter of the links contributing to the Subnet.

Subnet configuration and statistics

7. Subnet augmentation [START_REF]Next Generation Protocols (NGP); E2E Network Slicing Reference Framework and Information Model. Group report GR NGP 011[END_REF]: Network Slicing includes exposing the capability to the tenant in order to increase or decrease its allocated resources at runtime.

Typically, NS augmentation is performed in two steps. First, an augment request is sent from the tenant to the NSP. Then, the latter identifies the Subnets concerned with the resources augmentation and order the responsible NSAs to apply the new changes.

8. Subnet sharing [START_REF]Concepts, use cases and requirements[END_REF]: A NS creation event may trigger either the instantiation of a new Subnet or the use of an existing one with an eventual modification.

Accordingly, Subnets support NSs and are shared between them. Consequently, the life cycle of a NS instance (NSI) and its contained NS Subnet instances (NSSIs)

are not necessarily the same. For example, when a NSI is deleted, one or many of its constituents NSSIs still exist because they are belonging to other NSIs. 9. Managing NS Subnet services [START_REF]Management and orchestration; 5G Network Resource Model (NRM); Stage 2 and stage 3[END_REF]: The 3GPP NS data model indicates clearly that a NS Subnet support multiple services. More specifically, the Network Service entity describes the interconnection between the Subnet defined network functions (VNFs: Virtualized Network Functions and PNFs: Physical Network Functions)

following one or many service topologies called Forwarding Graphs (FGs). Also, a NS Subnet is independently managed from its supported services'life cycles. We highlight that the NSSMF includes the management of the NS Subnet as well as its supported services [START_REF] Flinck | Network Slicing Management and Orchestration[END_REF]. The architecture also adopts the Umbrella NFVO approach [START_REF]Network Functions Virtualisation (NFV); Management and Orchestration; Report on Architectural Options[END_REF] since the latter offers NFV service composition which is aligned with the Network Slicing use case. In the NESSMA Architecture, the NFVO cannot communicate directly with the SDN controller to install flow rules on the forwarding devices as it is the case in the NFV-MANO, instead all the network related operations are requested to the NSSM. The latter will contextualize the NS Subnets in the forwarding devices by the mean of a flow table partitioning virtualization. Moreover, a NSSM can act as a multi-SDN orchestrator

(NSSM 2)
or what is called the WAN Infrastructure manager (WIM) enabling a unified NS orchestration of different transport domains. However, traditional WIMs [START_REF] Yoshida | SDN-Based Network Orchestration of Variable-Capacity Optical Packet Switching Network Over Programmable Flexi-Grid Elastic Optical Path Network[END_REF] allows only for the provisioning of end-to-end services (connections) and do not deal with the NS orchestration and management. Lastly, we mention that the NSM is out of scope of the proposed NESSMA framework described in the Following section.

NESSMA's System Design

According to the requirements identified in section 3.2, we define the necessary system components of the NESSMA framework within each of the NSSM (Figure 3.4) and the SDN controller. We highlight that one of the main feature (resulting from the 9th requirement) of our framework is the joint management (provisioning, augmentation, monitoring, etc) of NS Subnets as well as their supported services'life cycles. The NESSMA system components are as follow: To perform these functions it communicates with the underlying SDN controller via Rest APIs and also websockets to handle monitoring events.

• Subnet Service controller: responsible for the realization of the FGs (described in the Network Service entity) received by either the NFVO (e.g. VNF interconnection) or the NSM (e.g. transport connectivity) ordering the installation of the appropriate flow rules in the appropriate Subnet. Similarly to the Subnet controller it also performs service's life cycle management.

• Path subsystem: provides path computation services to any form of networks. It may be a generic path finder algorithm based on some optimization techniques or a path Computation Element (PCE) [START_REF] Farrel | An Architecture for Use of PCE and the PCE Communication Protocol (PCEP) in a Network with Central Control[END_REF] where the shortest path is one particular case. In the NESSMA framework it coordinates with a parent path element, e.g., PCE, located at the NSM using a northbound protocol. It also operates on the TED to compute the mappings of the delegated Subnets (from the NSM) to the physical infrastructure.

• Resource Broker: defined in ETSI NS architecture, it allows the exposing of an abstracted network domain's topology to the NSM based on the TED and with the help of a path computation algorithm.

• Subnet database: it stores all the running Subnets as virtual networks along with their mapping to the physical infrastructure. This virtualization is performed by the SDN controller once it receives the Subnet provisioning request. The controller acknowledge the creation of the Subnet to the NSSM by sending back the elements'identifiers (IDs) of the virtual network.

• Subnet Service database: stores informations about the running services received either by the NFVO or the NSM, thus enabling to track their corresponding installed flow rules for an eventual augmentation or even a termination.

• Traffic Engineering database (TED): stores topology informations along with their constraints (e.g.bandwidth, latency) and status of resources (e.g.up/down, residual/unreserved) [START_REF] King | A PCE-Based Architecture for Application-Based Network Operations[END_REF]. It is populated and continuously updated by the SDN controller.

• Coordinator: coordinates the aforementioned system components allowing the NSM and the NFVO to jointly provision NS Subnets on the physical infrastructure.

NS Subnet Managment requires the introduction of a NS Subnet layer in the SDN controller on top of the resource abstraction layer, extending the controller framework with 3 blocks:

1. APIs: The NESMA framework defines a set of Restconf APIs (provisioning, augmentation and statistics) that allows the NSSM to manage the life cycle of NS Subnets as well as the services running inside them. More specifically, Subnet and service APIs are accessed respectively by the Subnet and the Service controllers using the Restconf protocol. In addition, Subnet and service event handlers sends out periodically notifications to respectively the Subnet and Service controllers using websockets.

2. Virtualization: Allows to contextualize NS Subnets on the physical infrastructure enabling their management by the upper-layer (NSSM) in an abstract and a flexible manner. In our framework, it is achieved by a Subnets-views data store and a Flow-table partitioner.

First, a Subnet provisioning request from the NSSM carries within the concrete forwarding elements participating in the Subnet (including the NS gateways) along with their endpoints and the necessary configurations. This results in the creation of a tenant context (e.g.virtual switch) in each participating element by allocating flow tables and setting queues. Next, the newly created virtual network along with its mapping to the physical network is maintained in the Subnets-views data store.

Authentication:

A tenant authentication application (e.g.Extensible Authentication over LAN) is necessary to control the access of end-users to NSs. If the authentication is successful, the application installs a flow rule in the edge physical switch context that sets a tenant ID in the tenant end users traffic. An other flow rule that match that ID will redirect the traffic to a virtual switch context.

Finally, for the sake of implementation all the NSSM's functional blocks can be developed from scratch except for the PCE and the resource broker. One of the available open source implementations can be chosen. The resources broker function is performed by an ALTO server [START_REF] Seedorf | Application-Layer Traffic Optimization (ALTO) Problem Statement[END_REF]. In addition, the Open Baton framework [START_REF] Baton | [END_REF] and the ONOS [START_REF] Onos | [END_REF]/Ryu [START_REF] Ryu | [END_REF] SDN controllers are the most suitable projects for the NESSMA framework's design. While ONOS/Ryu provides all the needed abstractions and features to develop the controller's blocks mentioned above, Open Baton is fully aligned with the NFV-MANO and provides the necessary Software Development Kits (SDKs) to interface the NSSM as a VIM with the NFVO.

Conclusion

In this chapter we focused on the design and the realization of the NS subnet management function responsible for the management of the NS subnets. The proposed framework architecture as well as its internal system components are designed based on a list of requirements derived from an analysis of the main NS standardization activities detailed in the previous chapter. Three main features are distinguished for the proposed framework: 1) Alignment with standardization activities, 2) the joint management of NS Subnets and their supported services, 3) integration with NFV-MANO.

Introduction

In this chapter we proposes the inter-slice bandwidth resources sharing, a novel mechanism for bandwidth resources optimization in slice-based infrastructures. The approach is based on the IETF COMS technology-independent information model [START_REF] Qiang | Technology Independent Information Model for Network Slicing[END_REF] which introduces four sharing levels to further optimize the network cost (in terms of bandwidth) of slice-based infrastructures, and thus increasing the operator revenue. We provide as well a proof of concept that implements and evaluates the mechanism in a SDN-based network. In practice, a network operator provisions a slice to be deployed according to the user request with a specified E2E bandwidth capacity. Note that a user may have several flow types (e.g., a video streaming and on-line gaming) circulating inside his reserved slice. Furthermore, many users may share the same slice. However, in particular NS conditions such as increase of users or peak times a slice may become congested so that the total bandwidth of the flows soliciting the slice at a specific point in time is greater than the slice bandwidth capacity. Surely, the capacity of a network is not usually set to the sum of its served flows since the latter are not simultaneously present within the network.

Therefore, our solution InterS, allows a congested slice to temporarily acquire all or a part of the free bandwidth resources of its neighbor slices and make use of them to serve its own traffic. To the best of our knowledge, InterS is the first solution demonstrating the inter-slice resources sharing concept based on the IETF COMS NS data model.

Besides operator profitability, we believe that this concept may help to reduce NS reconfigurations that may occur periodically in a slice-based infrastructure. The goal of NS reconfiguration is to augment NS resources or to simply guarantee better network utilization rate. This is referred to as the NS augmentation function in standardization bodies such as ETSI NGP [START_REF] Etsi Gr Ngp | Next Generation Protocols (NGP); E2E network slicing Reference Framework and Information Model[END_REF].

The augment operation is triggered by an operator/service provider to either increase or decrease the actual NS resources at runtime. In case of a NS scale up update, if the new required resources are not supported on the slice's actual route, the operations includes 1)the creation of a new path with the required resources, 2)rerouting the flows as well as migrating the VNFs to a new path and 3)releasing the resources in the older route.

This two-phase strategy is also referred to as make-before-break [START_REF] Gausseran | Be Scalable and Rescue My Slices During Reconfiguration[END_REF]. By reducing the frequency of such costly operations, InterS is providing more scalability, efficiency and profitability.

Indeed, isolation is one of the key expectations of network Slicing. However, the strength and level of isolation may vary depending on the contracted requirements between service providers and operators as well as NS usage scenarios [START_REF] Kotulski | On end-to-end approach for slice isolation in 5G networks. Fundamental challenges[END_REF]. Thus, in InterS, shared slices does not conserve the same level of isolation as exclusive ones since they are frequently allowing other slices' traffic on their free resources.

This chapter is organized as follows. Section 4.2 explains our proposed inter-slice bandwidth resource sharing approach. Section 4.3 presents the details of our proof of concept, called InterS, that includes the design of the solution as well as the experiments performed on the latter to evaluate the proposed concept.

The Inter-Slice Bandwidth Resource Sharing Approach

This section introduces the inter-slice bandwidth resource sharing approach and provides a concrete example of its operation.

Overview

The inter-slice bandwidth resources sharing concept demonstrated in this chapter is based on the resource reservation level attribute under the slice-level attributes entity of COMS (Figure 4.1). Four levels of resources reservation are defined for a NS:

• None: no specific resource reservation, for this level, a NS instance will share and compete for resources with other NS instances.

• Shared non preemptive: the free reserved resources could be used by other NS instances but they can not be retrieved if other NSs are still using them.

• Shared preemptive: the free reserved resources could be used by other slice instances, and will be retrieved if the NS needs them.

• Exclusive: the reserved resources can not be used by other NS instances, even if these resources are free.

COMS is a technology-independant information model for transport network slicing.

It is mainly meant for the management of NSs as well as NS subnets. As discussed in section 2.5.1, COMS is an essential brick of the ACTN architecture. The COMS NS data Our solution InterS particularly invokes the inter-slice bandwidth resource sharing mechanism in order to optimally deal with the NS congestion issue in slice-based infrastructures. Therefore, InterS allows a congested slice to temporary acquire all or a part of the free bandwidth resources of its non exclusive neighbor slices and make use of them to serve its own traffic. We define neighbor slices as a set of slices that share at least one physcial link of the physical infrastructure, ideally a slice path.

An Example of InterS Operation

The goal of this section is to explain the inter-slice bandwidth resource sharing mechanism by realizing the following experiment. Particularly, the shared non preemptive mode is used for this matter. The scenario of the experiment was chosen to reflect the different behaviors of InterS in a simple and clear manner. We note that the realized experiment serves only as an example of the proposed approach. The experiments of our proof of concept that we relyed on for the evaluation of the concept are detailed in section 4.3.2.

The experiment was performed on a network topology that consists of three Open-VSwitch in a linear topology (S1-S2-S3) and 16 hosts, eight source hosts (H1 to H8) connected to Switch 1 and and eight destination hosts (H9 to H16) connected to Switch 3. The maximum capacity of the path S1-S2-S3 is set to 150 Mb/s.

InterS was configured to support four QoS flow types A, B, C, D respectively characterized by a guaranteed data rate of 10, 20, 30, 40 Mb/s. Also, three NS instances (NSIs) were created in the network with the characteristics described in table 4.1. In addition eight flows of different types were generated from hosts H1 to H8 with the transmission data rates and the durations described in table 4.2. • At time t=5, the Flow 3 belonging to NSI 2 is sent to the network at a rate of 10 Mb/s for a period of 19 seconds. Since NSI 2's full capacity is free at this instant, Flow 3 is well served.

• At time t=10, Flow 4, another flow of type D belonging to NSI 1 is arriving to the network. NSI 1's available bandwidth is only 30Mb/s at the moment, hence NSI 1 select NSI 2 resources (40Mb/s) to accommodate this traffic. After this operation, NSI 2's capacity is fully used.

• At time t = 15, Flow 5 is admitted in NSI 1 occupying all its free remaining bandwidth.

• At time t=20, Flow 6 of type B is arriving at NSI 2, however, NSI 2's resources are actually accommodating two flows (Flows 3 and 4) with a total throughput of 50Mb/s which is equal to NSI 2's bandwidth capacity. Because NSI 3 is "exclusive", the only remaining option to check is NSI 1. Likewise, the latter is actually serving two flows (Flows 2 and 5) which are consuming its whole bandwidth. As a result,

Proof of Concept

This section presents a Proof of Concept of the inter-slice bandwidth resource sharing approach called InterS. It describes the design of our implementation as well as the experiments realized to evaluate the concept.

InterS's General Design

This section explains the general design of InterS that covers only the non preemptive sharing mode. An extended version of InterS and an augmentation with the preemptive sharing mode are described in sections 4.3.4 and 4.3.7. Our InterS solution is particularly demonstrating the above reservation levels for NS bandwidth resources. InterS is not implementing the None level since it is not compatible with our NS QoS model.

In fact, according to the overall vision on Network Slicing provided by different standards associations, a NS is all about the allocation of isolated resources with certain guarantees [START_REF] Chahbar | A Comprehensive Survey on the E2E 5G Network Slicing Model[END_REF]. Hence, prior instantiation, a NS has to be defined with a specific bandwidth capacity to be maintained during the whole NS lifecycle. Thus, A NS is capable of forwarding a specific network flow with its contracted rate guarantee from its source to its destination. Furthermore, we believe that the "None" level refers to best effort traffic that does not belong to any NS but uses the free resources of NSs in a specific path.

In our proof of concept, a NS is instantiated using a Rest API by defining the values of the following attributes: bandwidth, path, NS Identifier (Id), a list of allowed flow types and the bandwidth reservation level. Different flow types are also defined in the system with different rate guarentees. All the flows supported in the system are transmitted in the slice-based network at their guaranteed data rate a successful authentication, the flow is saved in the flow DB and the FAP proceed the flow to the admission system.

2. Admission: Its main function is to check if the arriving flow could be actually served in its proper NS at its defined guaranteed rate. If this is not the case, the admission system will repeat the last step for all the other non exclusives neighbor NSs. Resources of the eligible neighbor NS with the maximum available bandwidth are then temporarily provided to the congested NS to serve the flow. This is the part where the inter-slice bandwidth resource sharing happens.

Operation Description

Add used to add a flow in the database after a successful authentication.

Update

after a successful admission of a flow, its updated in the flow DB with a new attribute indicating the eventual usage of resources from neighbor NSs. This update allows also to differentiate between flows admitted in the network and the ones being processed or rejected.

Check

used by the FAP to check if the arriving flow is already existing in the Flow DB. This prevents the FAP from proceeding a currently admitted/dropped flow to the next process.

Delete

remove a flow from the database following its termination in the data plane.

Get retrieve some specific informations about the flow such as the quotas of resources acquired from neighbor NSs which leaded to the admission of the flow. This operation is used in the implementation option detailed in section 4.3.4.

Experiments

The experiments were performed on a network topology that consists of three Open- In order to run intensive experiments and evaluate the sharing approach of InterS, we have developed "FlowEvents", a traffic generator framework over Mininet [START_REF] Lantz | A network in a laptop: rapid prototyping for software-defined networks[END_REF] and OpenVSwitch [START_REF] Pfaff | The Design and Implementation of Open vSwitch[END_REF] automating the generation of random flows towards the network at that all the supported flow types previously defined are allowed in each of the 5 slices. the graphs presenting the results of the experiment are then generated from the produced datasets. The main softwares installed in each VM are: 1)The Ryu SDN Framework [START_REF] Ryu | [END_REF],

2)our solution InterS [START_REF] Chahbar | InterS: Towards Inter-Slice Bandwidth Resource Sharing[END_REF], 3)OpenVSwitch [START_REF] Pfaff | The Design and Implementation of Open vSwitch[END_REF], 4)Mininet [START_REF] Lantz | A network in a laptop: rapid prototyping for software-defined networks[END_REF] and 5)"FlowEvents". All the VMs are requested from the "Nancy" site of Grid5000, particularly from both the "Grimoire" and "Grisou" clusters. The resources capacities of those VMs are described in table 4.6.

T SBU R = 1 500 5 i=1 ( 100 15 15 j=1 n ij k=1 RF (k) ij * DF (k) ij BW i * D j ) (4.2)

Terms Meaning

n i j the number of admitted flows within slice i in experience j.

RF (k) ij

the achieved rate of the kth flow admitted within slice i in experience j.

DF (k) ij

the duration of the kth flow admitted within slice i in experience j.

BW i the bandwidth capacity of slice i.

D j the duration of experience j.

458 the total number of flow events in each experience. 500 the total bandwidth capacity of the 5 slices.

Implementation and Evaluation of the Shared Non Preemptive Resource Reservation Level

In this section, a first implementation of the shared non preemptive reservation level is evaluated. The implementation allows a congested NS to acquire free resources from at most one neighbor NS.

Algorithm

The algorithm of the admission system for the non preemptive sharing mode is generally described below (Algorithm 1).

The f reeBW () is a method of the Slice Class. When called by a NS instance it return the free resources of the instance at the moment of the call. The obtained results, shown in Table 4.8, are clearly indicating the increase in TSFAR and TSBUR from scenario 1 to scenario 3 for all the flow arrival rate values. Table 4.9

precises the values of improvement in percentage from scenario 1 to sceanrio 3 as well as from scenario 1 to scenario 2 per each event rate. As detailed by table 4.9, scenario 3 has clearly achieved the best amelioration in TSFAR and TSBUR and this for each flow events rate. Table 4.8 shows that the TSFAR keeps increasing from the left scenario to the right one as well as from the highest events rate configuration to the lowest. However, while TSFAR increases TSBUR keeps decreasing from the highest events rate setup to the lowest. The later is due to the fact that TSBUR is calculated on the basis of the experience duration D j . Figure 4.10 illustrates the impact of the events arrival rate configuration on the 15 experiences' durations in minutes. It is obvious that the experience duration gets bigger in low events rate configurations leading to lower TSBUR. Naturally, experience 5 with its 49 flow events has recorded a duration of roughly 20 minutes.

Lastly, we point out to an inaccuracy in the metering function of OpenVSwitch, that we call the meter error, encountered in all the experiences of the above experiments. To However, in the following sections and for a matter of accuracy in comparisons between results of different implementations, we will ignore the meter error in the calculus of the TSBUR (ideal TSBUR).

Aggregation of Resources From Multiple Neighbor Slices

Until now, InterS allowed any congested slice to acquire the free bandwidth resources of at most one neighbor slice. Thus a flow is rejected if there is no alternative slice capable of providing the required resources.

In this implementation, we observe that flows are rejected even though the total free bandwidth of all the neighbor slices are superior to the flows' guaranteed rates. This limitation has caused us to think about a new implementation option where a congested slice is able to aggregate free fragments of resources from different neighbor slices and acquire them to admit a flow that would be dropped on the previous implementation.

The new extension is used as a last resort when the required resources can not be wholly obtained from one neighbor slice only. This new behavior is integrated in InterS as an implementation option that can be activated or deactivated by the operator using Rest API. In the following of this section, we aim to discover the impact of the second implementation on both TSBUR and TSFAR and compare it to the first one in the exact same conditions.

Algorithm

The algorithm of the extended admission system for the non preemptive sharing mode is generally described below (Algorithm 2).

all k Slice k .f reeBW () is the total free resources of all the neighbor slices including Slice i . As detailled in alogrithm 2 from line 11, a set of resources fragments are acquired from different neighbor slices to scale up a congested slice (Slice i ) and therefore allowing it to admit and forward F low F . These resources are immediately released and returned back to their proprietary slices after F low F termination. For this end, the "Get Quotas" operation introduced in Figure 4.4 is used by the reservation system at the flow termination to obtain the resource contribution of each neighbor slice in the given congested slice.

Numerical Results

The obtained results, shown in Table 4.11, are clearly indicating the increase in TSFAR and TSBUR from scenario 1 to scenario 3 for all the flow arrival rate values. Table 4.12 precises the values of improvement in percentage from scenario 1 to sceanrio 3 as well as from scenario 1 to scenario 2 per each event rate. As detailed by table 4.12, sceanrio 3 has clearly achieved the best amelioration in TSFAR and TSBUR and this for each

Comparison of the Two Implementations of InterS

The aim of this section is compare the two implementations in terms of improvement in TSFAR and TSBUR achieved between extreme scenarios as well as from scenario 1 to scenario 2. We recall that table 4.9 and table 4.12 precise respectively the different values of amelioration measured in the afforementioned scenarios.

As concluded in sections 4.3.3 and 4.3.4, the two implementation of InterS (with the shared non preemptive mode) perform the best at moderate flow arrival rates such as 1/4 and 1/8.

Regarding the improvement in TSBUR, table 4.9 and table 4.12 are clearly indicating that implementation option 2 has slightly outperformed the first one in the amelioration between extreeme scenarios as well as between scenario 1 and scenario 2 and this for all the defined flow arrival rates.

Concerning the improvement in TSFAR between extreeme scenarios, Figure 4.15 illustrates the outperformance of implementation 1 over implementation 2 and this for all the tested flow arrival rates except 1/8. This is interpreted at flow events rate 1/8 by the admission of 3 additional flows in implementation 2. We also observe that the difference between the two implementations shown in Figure 4.15 for flow events superior or equal to 1/4 is not as relevent as the difference measured in the 1 and 1/2 flow events rate. Precisely, implementation 2 has lead to the loss of respectively 12 and 11 flows in flow events rates 1 and 1/2 in comparison to implementation 1. From the latter, it is obvious to conclude that the second implementation of InterS should not be adopted in the 1 and 1/2 network flow rate conditions.

Regarding the TSFAR amelioration between sceanrio 1 and scenario 2, Figure 4.16

shows the outperformance of implementaiton 2 over implementation 1 for all the tested flow arrival rates that are superior or equat to 1/4. The latter is interpreted by the admission of a total of 8 additional flows in all of 1/4, 1/18 and 1/16 configurations.

Similarly to the improvement measured between extreeme scenarios, implementation 1 is performing better than the second one at events rates 1 and 1/2. Precisely, implementation 2 has lead to the loss of respectively 6 and 5 flows in flow events rates 1 and 1/2 in comparison to implementation 1.

From the comparison of Figures 4.15 and 4.16, we conclude that implmentation 1 performs more better than implementation 2 at flow events rates 1 and 1/2. Thus, it is inappropriate to enable the second implementation at such network conditions.

Limitation of the Shared Non Preemptive Mode

The limitation of the shared non preemptive reservation level manifests in the innability of a slice to retrieve immediately its used resources by other slices when it needs them. We observe from the results presented in Figures 4.9 and 4.14 that the total number of accepted flows increase significantly for some slices and decrease for others when several flows are stopped during their transmission within the neighbor slices.

The preemptive component is responsible to stop the transmission of the well chosen flows and instruct the data plane configuration system to present these flows again to InterS as new arriving ones.

All the flows that are admitted in a specific slice and supported by resources acquired from a shared preemptive slice are susceptible to be stopped and re-admitted many times until their transmission is finished or they are admitted and supported by resources of their proper slices or rejeted.

Instead of dropping a flow, our implementation allows to present it continiously each time it is stopped by the preemptive process to the InterS's admission sytem as a new flow. This will surely increase the chance of the flow to be admitted definitely or complete its data transmission to the destination host. In our implementation when a flow is re-admitted, it resumes the transmission of data from the point it stopped at previously without any loss in data. In the shared non preemptive implementation, we say that a flow is:

• "admitted definitively" if it is fully supported by the resources of the slice to 1. The admission of a flow may follow up with one of the aforementioned decisions explained in the previous section: accept definitively, not definitively accept and reject.

2. There is two different perceptions of "free resources" depending on the resource reservation level of a slice. From a shared non preemptive slice's perspective, "free resources" are the ones that are not used by neither the proprietary slice nor any neighbor slice. For a shared preemptive slice, "free resources" include the resources that are not used by the proprietary slice and are used or not by a neighbor slice.

Therefore, the freeBW() method has different behaviors depending on the resource reservation level of the slice calling it.

3. The slice is scaled down not only after flow termination but also if an eventual supporting slice is retrieving its resources (line 7).

4. An aditional set of operations represented by the Preemptive() method are executed if the slice is of the shared preemptive type (line 11).

One of the main functions of the preemptive component is to select the appropriate flows of neighbor slices (supported by Slice i resources) to be stopped and sent for re-admission for the sake of the optimization of bandwidth resources. This is also a way Regarding the amelioration from scenario 1 to scenario 2, the maximum increase in TSBUR and TSFAR is achieved by the 1/4 events rate.

We conclude from the results illustrated in Figure 4.19 as well as table 4.15 that the shared preemptive implementation of InterS is also performing the best at moderate events arrival rates such as 1/4 and 1/8. • Type 0: flows are associated to an admission code equal to zero. It identifies the flows that got rejected the first time they were presented to the admission system.

• Type 1: flows are associated to an admission code equal to 1. It identifies the flows that got accepted the first time they were presented to the admission system.

• Type 2: flows are associated to an admission code equal to 2. It identifies the flows that were not admitted definitely (decision 3 in Figure 4.18) and they got the chance to complete the transmission of data before any interruption from a resource owner slice.

• Type 3: flows are associated to an admission code strictly superior than 2. It identifies the flows that were not admitted definitively and got stopped/re-admitted one or many time before they were definitively accepted or completed their transmission.

• Type 4: flows are associated to an admission code strictly inferior to 0. It identifies the flows that were not admitted definitively and got stopped/re-admitted one or many time before they were rejected.

Table 4.16 reveals the distribution of flows obtained in scenario 3 with a 1/4 events rate configuration at the end of the experiment (15 experiences). We observe that the shared non preemptive implementation has generally outperformed the shared preemptive one in the improvement of both TSFAR and TSBUR between extereme scenarios.

Conclusion

Network Slicing is becoming a mature technology in recent years due to the continuous efforts conducted by the standards organizations, academic units and operators. In this thesis, our main contributions covered the modelization of the network slicing technology as well as the proposition of the inter-slice resource sharing mechanism to deal with the resource optimization challenge in slice-based infrastructures.

In

Perspectives

The perspectives of our work are summarized below. We group the futur works in short, medium and long terms research directions.

Short Term Research Directions

The inter-slice resource sharing approach presented in this thesis is a novel and an outstanding research direction. The short term research directions are as follow:

• Neighbor slices' selection criteria: regarding the algorithm of the interslice bandwidth resource sharing, the selection criteria of neighbor slices can be extended to other policies other than the maximum amount of free resources. A relevant criteria could be a measure of slice activity. Together, the two criterias will ensure the availibilty of free resources in the present and the futur so that the neighbor slice will not be penalized by the resources sharing mechanism. An other criteria that can be considered is the duration of resources availability in a neighbor slice. This will require the prediction of flows durations in the network so that the neighbor slice is selected only if its free resources are available for a duration at least equal to the flow duration of the congested slice. The slice activity as well as the flow duration can be predicted using machine learning algorithms based on the history of the NS.

• Extension to other network resources: we have particularly demonstrated the benefit of the inter-slice resource sharing for bandwidth resources. However, it can be applied to other resources such as compute or storage.

Medium and Long Terms Research Directions

We aim to achieve the following long term objectives:

• Realization of the ACTN Framework: NS modelization is still an important challenge in the standardization community. In the absence of a clear consensus within IETF on the modelization of network slicing in the transport domains, our vision was explained and provided in section 2.5.1. The implementation and the evaluation of such a vision will be possible in the future, especially with the launching of the ACTN project within the opensource ONOS controller. We believe that if the project is extended by a NS engine and an implementation of the COMS and the VN information models, it can serve as a reference platform for the transport network slice experimentations. This is also an opportunity to define and experiment with a transport customer service model based on our recommendations detailed in section 2.5.2.

• 5G use case experiments: we aim to operate our proposed inter-slice resource sharing mechanism in a large environnement with different network topologies including different types of VNFs and experiment with a 5G use case such as "connected vehicules".

2. 1 4 1. 1 . 1 4 1. 1 . 2 1 . 3

 141141213 NS functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2 GSMA's NS templates . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.3 NS management roles and actors [2] . . . . . . . . . . . . . . . . . . . . 2.4 Standardised SST values . . . . . . . . . . . . . . . . . . . . . . . . . . 2.5 COMS NS augmenting entities . . . . . . . . . . . . . . . . . . . . . . . 2.6 3GPP and GSMA commun NS characteristics . . . . . . . . . . . . . . . 2.7 Summary on the similarities and the differences between SDOs'visions . 4.1 NS Instances (NSIs) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.2 Flows generated in the Network . . . . . . . . . . . . . . . . . . . . . . . 4.3 Flow DB operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.4 the NS sharing mode evaluated by section . . . . . . . . . . . . . . . . . 4.5 The number of experiences executed per flow arrival rate in each scenario 4.6 VMs resources capacities . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.7 Equations terms and meanings . . . . . . . . . . . . . . . . . . . . . . . 4.8 the TSFAR (/458) and TSBUR (/500) obtained from each scenario for different flow arrival rates. . . . . . . . . . . . . . . . . . . . . . . . . . . 4.9 Improvement values (%) in TSFAR and TSBUR per event rate from SC1 to SC3 and SC1 to SC2 . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.10 the ideal TSBUR (/500) obtained from each scenario for different flow arrival rates. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.11 the TSFAR (/458) and TSBUR (/500) obtained from each scenario for different flow arrival rates. . . . . . . . . . . . . . . . . . . . . . . . . . . 4.12 Improvement values (%) in TSFAR and TSBUR per event rate from SC1 to SC3 and SC1 to SC2 . . . . . . . . . . . . . . . . . . . . . . . . . . . xiv List of Tables 4.13 The total number of flows accepted by Slice 2 obtained in each scenario for flow arrival rates 1 and 1/4. . . . . . . . . . . . . . . . . . . . . . . . 4.14 the TSFAR (/458) and TSBUR (/500) obtained from each scenario for different flow arrival rates. . . . . . . . . . . . . . . . . . . . . . . . . . . 4.15 Improvement values (%) in TSFAR and TSBUR per event rate from SC1 to SC3 and SC1 to SC2 . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.16 Example of flows distribution . . . . . . . . . . . . . . . . . . . . . . . . 4.17 The number of accepted flows per slice for flow events rate 1. . . . . . . List of Figures 1.1 Thesis Challenges . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2 SDN architecture: Simplified view [4] . . . . . . . . . . . . . . . . . . . . 1.3 High-level NFV framework [6] . . . . . . . . . . . . . . . . . . . . . . . . 1.4 End-to-End Management and Orchestration reference architecture [10] . 1.5 Our contributions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.1 ETSI NGP NS Framework. Introduction of the NS managed objects, NS workflows and functions in the NS architecture. . . . . . . . . . . . . . . 2.2 Involving the GSMA GST/NEST in the instantiation phase of a NS. . . 2.3 3GPP NS Information Model . . . . . . . . . . . . . . . . . . . . . . . . 2.4 3GPP NS Management Functions . . . . . . . . . . . . . . . . . . . . . . 2.5 The 4 types of a Transport NS: Fronthaul, Midhaul, Transport and an other Network separating the core to client applications. . . . . . . . . . 2.6 The ACTN Architecture: CNC, MDSCs and PNCs. . . . . . . . . . . . 2.7 IETF COMS Information Model . . . . . . . . . . . . . . . . . . . . . . 2.8 The NS Subnet Stitching Mechanism . . . . . . . . . . . . . . . . . . . . 2.9 Enabling network slicing within the ACTN architecture . . . . . . . . . 2.10 Integration of VN, TE and COMS models . . . . . . . . . . . . . . . . . 2.11 Mapping of 3GPP NS functions to the Transport Network . . . . . . . . 2.12 Mapping of the ETSI NGP NS information model objects, the 3GPP NS data model, the GST/NEST and the ACTN Framework on the End-to-End Management and Orchestration reference architecture (MANO) . . 3.1 The position of the NSSMF in the E2E MANO architecture . . . . . . . 3.2 Revisited NFV-MANO Framework [81] . . . . . . . . . . . . . . . . . . . 3.3 The NESSMA architecture . . . . . . . . . . . . . . . . . . . . . . . . . 3.4 NSSM's System components . . . . . . . . . . . . . . . . . . . . . . . . . Introduction Chapter content 1.0.1 Problem Statement . . . . . . . . . . . . . . . . . . . . . . . . 1.0.2 Research Challenges . . . . . . . . . . . . . . . . . . . . . . . 1.1 Context . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Software-Defined Networking (SDN) [4] . . . . . . . . . . . . Network Function Virtualization (NFV) [6] . . . . . . . . . . 1.1.3 SDN/NFV [6] . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.1.4 Network Resources and Service Orchestration [7] . . . . . . . 1.2 Our Contributions . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2.1 An E2E 5G Network Slicing Model . . . . . . . . . . . . . . . 1.2.2 A NS Subnet Management Framework . . . . . . . . . . . . . 1.2.3 The Inter-Slice Bandwidth Resource Sharing Mechanism . . . Thesis outline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Figure 1 . 1 :

 11 Figure 1.1: Thesis Challenges

Figure 1 . 2 : 1 . 1 . 2 6 ]

 121126 Figure 1.2: SDN architecture: Simplified view[4]

Figure 1 . 3 :

 13 Figure 1.3: High-level NFV framework[START_REF]Architectural Framework, V1.2.1. Group specification GS NFV 002[END_REF]

Figure 1 . 4 :

 14 Figure 1.4: End-to-End Management and Orchestration reference architecture[START_REF]View on 5G Architecture version 1.0[END_REF]

  by a NS subnet management framework. Indeed, each component of the proposed framework relies on our vision on the end-to-end 5G network slicing model. Therefore, our contributions comes in a logical sequence to reach the objective of the thesis as depicted in Figure 1.5.

Figure 1 . 5 :

 15 Figure 1.5: Our contributions

Figure 2 . 1 :

 21 Figure 2.1: ETSI NGP NS Framework. Introduction of the NS managed objects, NS workflows and functions in the NS architecture.

Figure 2 . 2 :

 22 Figure 2.2: Involving the GSMA GST/NEST in the instantiation phase of a NS.

Figure 2 . 3 :

 23 Figure 2.3: 3GPP NS Information Model

Figure 2 . 4 .

 24 Figure 2.4. First the Communication Service Management Function (CSMF) receives the communication service related requirements from the CSC. Those requirements are converted to NS related requirements (Service profile) and then provided to the NS Management Function (NSMF). Indeed, the CSMF manages the Communication Services provided by the Network Operator. The NSMF creates and manages the NSIs based on the received NSs related requirements. Then, it derives the NS subnets related requirements (Slice Profile) and provides them to the NS Subnet Management Function (NSSMF) so that the NS subnet management is delegated to the NSSMF.

Figure 2 . 4 :

 24 Figure 2.4: 3GPP NS Management Functions

Figure 2 . 5 :

 25 Figure 2.5: The 4 types of a Transport NS: Fronthaul, Midhaul, Transport and an other Network separating the core to client applications.

  of the underlying TE networks to customers. TE networks or TE topologies mechanisms are key enablers of network slicing since they allow the dynamic provisioning of the E2E connectivity. The TE topology (or TE Network) model will be further discussed in this section. The ACTN architecture (Figure 2.6) includes three controllers: the Customer Network Controller (CNC), the Multi-Domain Service Coordinator (MDSC) and the Provisioning Network Controller (PNC). Three interfaces are then introduced by this three-tier architecture: CNC-MDSC interface (CMI), MDSC-PNC interface (MPI) and Southbound interface (SBI).

Figure 2 . 6 :

 26 Figure 2.6: The ACTN Architecture: CNC, MDSCs and PNCs.

  Figure 2.7 shows our vision of the IETF NS data model with the augmenting entities (dark color).

Figure 2 . 7 :

 27 Figure 2.7: IETF COMS Information Model

2. 4 . 2 . 6

 426 The NS Stitching Data Model[START_REF] Xavier De Foy | Interconnecting (or Stitching) Network Slice Subnets. Internet-Draft draft-defoy-coms-subnet-interconnection-03[END_REF] Furthermore, the COMS model is augmented to show up NS subnets and their interconnections within the E2E transport NSs. The new model will not only isolate the management of subnets but also will allow the description of the interconnection instances (implemented as gateways in the data plane) to the upper layers for management operations such as subnet sharing or substituting. The model introduces the mechanism of anchor node and anchor termination point in which all open-ended links within a subnet are linked to an anchor node at a anchor termination point (Figure 2.8).

Figure 2 . 8 :

 28 Figure 2.8: The NS Subnet Stitching Mechanism

Figure 2 .

 2 Figure 2.9 depicts our vision. The customer in our case is the 3GPP system orchestrator (the operator). Therefore the CNC hosts the aforementionned 3GPP NSMF. By analogy to the RAN and the CN, the CNC sends the TNS related requirement over the CMI. At the latter, a service customer model encompasses the technology-agnostic TNS profile and the 3GPP RAN and CN access points. At the time of writing this article, neither a TNS profile nor a clear NS customer service model are defined within the IETF.

Figure 2 . 9 :

 29 Figure 2.9: Enabling network slicing within the ACTN architecture

Figure 2 . 10 :

 210 Figure 2.10: Integration of VN, TE and COMS models

Figure 2 . 11 :

 211 Figure 2.11: Mapping of 3GPP NS functions to the Transport Network

Figure 2

 2 Figure 2.12.

Figure 2 . 12 :

 212 Figure 2.12: Mapping of the ETSI NGP NS information model objects, the 3GPP NS data model, the GST/NEST and the ACTN Framework on the End-to-End Management and Orchestration reference architecture (MANO)

i.

  Preparing the flat GST to automation and programmatic use by transforming it to a JSON template validated by a JSON schema. ii. Making the GST customer facing by separating the Customer Facing Service (CFS) attributes from Resource Facing Service (RFS) ones so that most customers (non-technicals) deal only with what/where/when questions. iii. Many of the GST attributes are ignored in the reviewed template on the pretext that their values can be derived from other populated parameters. After comparison of the two templates, we notice that the following GST attributes are missing: Downlink throughput per network slice, Energy efficiency, Isolation level, Location based message delivery, Maximum supported packet size, NB-IoT Support, Uplink throughput per UE.

Figure 3 . 1 : 1 . 2 .

 3112 Figure 3.1: The position of the NSSMF in the E2E MANO architecture

10 .

 10 Integration with NFV-MANO: While the NFV-MANO framework deals with orchestration of NFV Network services, Network Slicing requires a high-level service orchestration capable of managing NSs considered as customer-facing services. Therefore, a new NS abstraction layer need to be introduced in the NFVI allowing the integration of NSs'life cycles management in the NFV-MANO. Two possible opportunities of this integration are envisageable. The first consists of extending the NFVO's service orchestrator functional block with a NS management engine. The second consists of performing NS orchestration in an external entity and interfaces it with NFV-MANO. In this last context, efforts of the IETF NFV research group (NFVRG) [80] to integrate NSs in the NFV-MANO architecture result in a revisited ETSI NFV framework (Figure 3.2).

Figure 3 . 2 :

 32 Figure 3.2: Revisited NFV-MANO Framework[START_REF]Towards Integration of Slice Networking in NFV[END_REF]

Figure 3 . 3 :

 33 Figure 3.3: The NESSMA architecture

  For example, a tenant service would consist of connecting multiple VNFs running in different Data centers (DCs) connected across different transport domains. Following the ETSI NS architecture, the NSM constitutes the end-to-end NS view exploiting the abstractions of the underlying physical infrastructures exposed by different NSSMs. Next, the end-to-end NFV Network Service is separated from the NS, Segmented by the Umbrella NFVO and distributed to the underlying NFVOs for deployment (instantiation of VNFs/creation of the network service in each DC). The remaining NS is also Segmented to Subnets and delegated to the transport NSSM for deployment in each transport domain. Finally, each NFVO requests to the NSSM the installation of the required programmable flow rules through the SDN controller.

Figure 3 . 4 :

 34 Figure 3.4: NSSM's System components

  Section 4.3.3 and 4.3.4 evaluate respectively two different implementations of InterS with the shared non preemptive resource reservation level. Section 4.3.5 compares the two previous implementations. Section 4.3.6 highlights the limitation of the shared non preemptive mode of InterS. Finally, Section 4.3.7 and 4.3.8 cope with the latter limitation by implementing and evaluating the shared preemptive resource reservation level. Section 4.4 concludes the chapter.

Figure 4 . 1 :

 41 Figure 4.1: COMS'Slice-level attributes entity

Figure 4 . 2 :

 42 Figure 4.2: COMS data store

Figure 4 . 3 ,

 43 Figure 4.3, shows the result of the experiment. In particular, graph a), shows the transmission rate of the 8 generated flows during the whole experiment. Graphs, b), c) and d) illustrate respectively the flows that were served by NSI 1, NSI 2 and NSI 3 resources as well as their instantaneous throughput at the receiving hosts. In the

Table 4 . 1 :

 41 NS Instances (NSIs)

Flow 1 is belonging to NSI 3 .

 3 Knowing that the latter does not support the flow type D, Flow 3 is dropped. This explains the absence of the flow's associated trace in all of the b), c) and d) graphs. At the same instant, the Flow 2 belonging to NSI 1 is introduced in the network with a transmission rate of 45 Mb/s for the duration of 24 seconds. At this moment, NSI 1's available bandwidth is 70 Mb/s, thus the flow is rate-limited to 40 Mb/s and served in NSI 1. In our QoS model, we do not allow a flow to send more than its guaranteed rate, all the excess traffic is dropped.

Figure 4 . 3 :

 43 Figure 4.3: a) Flows data rates at sender hosts. b) Instantaneous throughput of flows (served in NSI 1) at receiving hosts. c) Instantaneous throughput of flows (served in NSI 2) at receiving hosts. d) Instantaneous throughput of flows (served in NSI 3) at receiving hosts.

Flow 6

 6 is dropped. This explains the absence of the flow's associated trace in the graphs b), c) and d).• At time t = 25, Flow 7 of type C is well admitted in NSI 3. At this moment also, transmission of Flows 2 and 3 has ended, thus releasing their used resources in respectively NSI 1 and NSI 2.• At time t =30, Flow 8 of type A arrives at NSI 3. No more resources can actually be allocated in this slice, therefore NSI 3 will try to acquire resources from an neighbor NSI with the maximum free bandwidth resources. Actually, NSI 2 and NSI 1 have respectively an unused bandwidth of 10 and 30 MB/s, thus both of them are candiates for resources sharing. Finally, NSI 1 bandwidth resources (10Mb/s) are acquired by NSI 3 to serve Flow 8.

3 . 4 . 5 . 3 . 6 .

 34536 Reservation: for each slice registred in the slice DB, the reservation system keeps track of the actual resources being reserved by the NS's proprietary flows, the actual resources acquired by neighbor NSs and the free resources. It is also responsible for the release of NS resources following the termination of a flow as well as its removal from the flow DB. In the case of flow admission, the entry corresponding to the flow already added by the authentication process in the flow DB is updated by the reservation system to keep track of the eventual acquired resources used to accomodate the flow. DP configuration: The admission of a specific flow is translated within the DP configuration system to a set of flow rules and meters configured in the data plane nodes all along the path of the selected NS. Following a failed admission or authentication, the flow is rejected and only the SAP is configured to the drop this flow. This is achieved by calling the Ryu Framework which in turn send the appropriate openflow messages to the nodes. Flow DB: an inventory of all the flows existing in the network at a specific point of time, either being served in a specific NS or dropped. The interaction of the above mentioned components with the flow DB is governed by a set of operations described in table 4.Slice DB: an inventory of all the NSs requested for instantiation to InterS using Rest API by the network operator. All the components of InterS are interacting with this database in read-mode only.

  VSwitch in a linear topology (S1-S2-S3) and 100 hosts, 50 source hosts (H1 to H50) connected to Switch 1 and and 50 destination hosts (H51 to H100) connected to Switch 3. The maximum capacity of the path S1-S2-S3 is set to 500 Mb/s (Figure 4.5).

Figure 4 . 5 :

 45 Figure 4.5: Network topology

  The execution of the experiment was simultaneously happening on a set of VMs allocated on the Grid 5000 public cloud (Figure4.6). One VM is allocated per scenario and flow arrival rate to run the 15 experiences. By this separation we simply aim to reduce the time of our lenthy experiment. A pyhton script is used to automatically gather the results obtained on the different VMs and output them to files as datasets. All

Figure 4 . 6 :

 46 Figure 4.6: Access to Grid5000[START_REF]Grid 5000 Cloud[END_REF]

Figure 4 . 8 :

 48 Figure 4.8: Per slice bandwidth usage rate in a 1/4 events rate setup.

Figure 4 . 9 :

 49 Figure 4.9: per Slice flow acceptance rate during the 15 experiences in a 1/4 events rate setup.

Figure 4 . 10 :

 410 Figure 4.10: Experience duration per events arrival rate

Figure 4 . 11 :

 411 Figure 4.11: The meter error observed in the OpenVSwitch metering Function

Figure 4 . 12 :

 412 Figure 4.12: Improvement percentage of TSBUR and TSFAR per events rate

Figure 4 . 13 :

 413 Figure 4.13: Per slice bandwidth usage rate in a 1/4 events rate setup.

Figure 4 .

 4 Figure 4.14: per Slice flow acceptance rate during the 15 experiences in a 1/4 events rate setup.

Figure 4 . 15 :

 415 Figure 4.15: Comparison of the TSFAR amelioration between implemenations from scenario 1 to scenario 3.

Figure 4 . 16 :

 416 Figure 4.16: Comparison of the TSFAR amelioration between implemenations from scenario 1 to scenario 2.

  This issue can be identified in the per slice flow acceptance rate figure either in the first implementation (Figure 4.9) or the second one (Figure 4.14). Scenario 1 is realizing the normal behaviour of Slices and thus providing a relevant information about the normal capacities of operational slices in terms of the flow acceptance rate.

Figure 4 .

 4 [START_REF] Zhang | An Overview of Network Slicing for 5G[END_REF] clarifies the details of the process of flow re-admission.

Figure 4 . 18 :

 418 Figure 4.18: Flowchart of the flow re-admission process.

  for the preemptive component to ensure the obtention of the highest possible network usage rate.The flows selection process is based on the following optimization formula: minimum number of flows that realize the equation 4.3. R i is the guarented data rate of flow F i existing in the network and respecting the constraint. RR designate the resources required to admit the new arriving flow (F low F ). RR is the substraction of the free resources of Slice i (to which F low F belongs to) that are not used by any neighbor slice from the flow's guarented data rate (FGR). The idea of the equation 4.3 is to stop the least number of flows with a minimum summation of their guarented data rates being at least equal to RR.

Figures 4. 20

 20 Figures 4.20and 4.21 illustrate respectively the bandwidth usage rate of each slice

  Figures 4.20and 4.21 illustrate respectively the bandwidth usage rate of each slice averaged on the 15 experiences and the per slice flow acceptance rate during the 15 experiences.

Figure 4 . 19 :

 419 Figure 4.19: Improvement percentage of TSBUR and TSFAR per events rate

Figure 4 . 20 :

 420 Figure 4.20: Per slice bandwidth usage rate in a 1/8 events rate setup.

Figure 4 . 21 :

 421 Figure 4.21: per Slice flow acceptance rate during the 15 experiences in a 1/4 events rate setup.

4. 3 . 8 Figure 4 .

 384 Figure 4.22 compares the improvement in TSBUR and TSFAR between the shared preemptive and the shared non preemptive implementations of InterS. Particularly, upper graphs of the figure concerns the amelioration from scenario 1 to scenario 3 and lower graphs relate to the improvement from scenario 1 to scenario 2.

Figure 4 . 22 :

 422 Figure 4.22: Compare InterS'two sharing modes

5 C h a p t e r General Conclusion and Perspectives Chapter content 5 . 1

 551 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.2 Perspectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.2.1 Short Term Research Directions . . . . . . . . . . . . . . . . 5.2.2 Medium and Long Terms Research Directions . . . . . . . . .

  our first contribution an E2E 5G network slicing model was provided based on an in-depth analysis of the modelization works published by the leading SDOs such ETSI, GSMA, 3GPP and IETF. We commenced by providing a general architecture of network slicing common to a large extent to the different SDOs. This part has served as a stepping-stone to set the primary foundation of network slicing before diving deep into domain-specific visions. Then we explained the two different visions of ordering a NS among SDOs. Next, the network slicing process in each of the RAN, the Core and the transport networks were exhaustively detailed. Last, we have addressed some open standardization issues as well as future research directions in this area.Our second contribution focuses on providing a list of requirements that should be satisfied by a NS subnet management framework. The design as well as the requirements of the framework called NESSMA are derived from the E2E network slicing model provided by the first contribution. NESSMA is designed to manage NS Subnets as well as their supported services' life cycles taking into account its integration with NFV-MANO.Our third contribution realizes a proof of concept of the inter-slice bandwidth resource sharing approach based on the COMS NS information model. Indeed, our implementation is based on the modelization works presented in previous contributions.Our PoC, so called InterS, allows the instantiation of NS with one of the following resource reservations levels: 1) Exclusive, 2) Shared non preemptive and 3) Shared preemptive. Our PoC includes two main implementations. The first one allows a congested NS to acquire free bandwidth resources from at most one neighbor NS. The second implementation, allows the congested NS to acquire and aggregate fragments of free resources from multiple neighbor NSs. Three main experiments were realized. The first evaluates the shared non preemptive mode within the first implementation. The second experiment evaluates the shared non preemptive mode within the second implementation. Finally, the third experiment evaluates the shared preemptive mode within the first implementation. The comparison of the two implementations has shown that they are slighly outperforming each other depending on different predefined network conditions. The results obtained from the realized experiments have shown that the shared non preemptive mode penalizes some slices in favor of others in the operation of the inter-slice bandwidth resource sharing. The usage of the shared preemptive resource reservation level has resolved the issue. Finally, the results of all the experiments have shown that the inter-slice bandwidth resource sharing mechanism presented by the evaluated resource reservation levels can significantly improve the flow acceptance and the bandwidth usage rates of the network. Therefore, it presents a real resource optimization opportunity for slice-based infrastructures.

An E2E 5G Network Slicing Model

	C h a p t e r	2
	Chapter content
	2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
	2.2 Network Slicing: A General Vision . . . . . . . . . . . . . . . . . . .
	2.3 Ordering a NS: Service Graph or NS Template ? . . . . . . . . . . .
	2.4 Network Slicing: A Domain-Specific Vision . . . . . . . . . . . . . .
	2.4.1 RAN and CN . . . . . . . . . . . . . . . . . . . . . . . . . . .
	2.4.2 Transport Network Slicing . . . . . . . . . . . . . . . . . . . .
	2.4.2.1 Definition . . . . . . . . . . . . . . . . . . . . . . . .
	2.4.2.2 ACTN Architecture . . . . . . . . . . . . . . . . . .
	2.4.2.3 TE Topology Model [44] . . . . . . . . . . . . . . .
	2.4.2.4 The Virtual Network (VN) Model [45] . . . . . . . .
	2.4.2.5 The COMS Data Model [46] . . . . . . . . . . . . .
	2.4.2.6 The NS Stitching Data Model [50] . . . . . . . . . .
	2.4.2.7 The TE Tunnel Data Model [51] . . . . . . . . . . .
	2.4.2.8 The Performance Telemetry Data Model (PTISA) [52]
	2.4.2.9 The ACTN Common Interfaces Information Model
	(ACTN C2IM) [53] . . . . . . . . . . . . . . . . . . .
	2.5 Our Vision on the E2E 5G Network Slicing Model . . . . . . . . . .
	2.5.1 Enable Network Slicing Within the ACTN Framework . . . .

Table 2 . 1 :

 21 NS functions

Table 2 .

 2

2: GSMA's NS templates

Table 2 .

 2

	Advanced cus-	Communication Ser-	Consumes a Communication Service. It
	tomer		vice Customer	has some capabilities limited by the CSP
				to manage the Communication Service via
				the CSMF.
	NS Provider	Network Operator	Provides a NS and Consumes NS Subnet(s).
	NS tenant	Communication Ser-	Consumes and manages a Communication
			vice Customer and	Service and also NS(s) via the NS Manage-
			Communication Ser-	ment Function (NSMF).
			vice Provider
	NS	Subnet	Network Operator	Provides a NS Subnet.
	Provider
	Communication	Communication Ser-	Provides Communication Service NS(s) and
	Network		vice Provider and	NS Subnet(s).
	Provider		Network Operator

3: NS management roles and actors [2] Actor Role Description Basic customer Communication Service Customer Consumes a Communication Service but does not use the Communication Service Management Function (CSMF).

Table 2 .

 2

			4: Standardised SST values
	SST	SST Value	Bref Description
	eMBB	1	Slice suitable for the handling of 5G enhanced Mobile
			Broadband.
	URLLC	2	Slice suitable for the handling of ultra-reliable low la-
			tency communications.
	mIoT	3	Slice suitable for the handling of massive IoT.

The identification of NSs in control plane is done using the Network Single-Slice Selection Assistance Information (S-NSSAIs). It is based on the SST and an optional complementary information, called Slice Differentiator (SD), that allows the definition of different NSs types around the same SST value.

Table 2 .

 2

		5: COMS NS augmenting entities
	NS Entities	NS characteristics
	Port-Config	packet rate, packet loss probability, packet loss threshold.
	Port-Stats	received packets, sent packets.
	Link-QoS	link bandwidth agreement, link throughput, link throughput
		threshold, link-latency agreement, link-latency, link-jitter agree-
		ment, link-jitter, link-jitter threshold, path restrictions: list of
		mandatory nodes, list of mandatory links, list of excluded nodes,
		list of excluded links.
	Compute-Unit	compute unit ID, number of Cores, ram, access mode, location,
		unit type.
	Storage-Unit	storage unit ID, size, access rate, access mode, read-write mode
		type, redundancy type, location.
	Service-	service instance ID, Pre-defined Function Block: Domain-agent
	Instance	name, southbound(sb) IP address, sb port, northbound (nb) IP
		address, nb port, Function Id, Function name, IP address, port,
		list of termination points.
	Slice-Level-	service time start, service time end, life-cycle status, reliability
	Attributes	level, resource reservation level, availability, availability-threshold,
		Access-control: match, action, priority, counter.

Table 2 . 6 :

 26 3GPP and GSMA commun NS characteristics TSCI) information model. This model supports the vision of the ETSI NGP and represents a NS service as a set of transport networks (subnets) including nodes and their interconnection links. The nodes may represent either the

	3GPP field	Value	Equivalent GSMA at-
			tribute
	Connection Density	Integer (UE/sq km)	Terminal Density
	E2E Latency	integer (ms)	slice quality of service pa-
			rameters
	UE Mobility Level	Enumeration (stationary,	Supported device velocity
		nomadic, restricted mobil-
		ity, fully mobility)
	Resources Sharing Level	Enumeration (shared, non	Simultaneous use of the
		shared)	network slice
	Reliability	Float	Reliability
	Communication Service

Table 2 . 7 :

 27 Summary on the similarities and the differences between SDOs'visions

	Main contribution			Generalized NS architecture	and its associated workflows.	Information/data model	for NS provisioning and	management on RAN and	Core network.	GST/NEST	The ACTN architecture and several	data models(cited in section 2.4.2).	Enable Network Slicing	within the ACTN architecture by	integrating together multiple	IETF data models.
	NS Service request Network domain	Service/	Slice VN Type (1,2) RAN Core Transport General	profile										VN type 1	+ TNS profile
		Service	graph
	Provision models [65]	SaaS-PaaS-IaaS-	like like like
	SDOs	modelling	aspects	ETSI NGP		3GPP		GSMA	IETF		Proposed	vision

Table 4 . 2 :

 42 Flows generated in the Network

	Flows	Transmission	End-points	Type	NS	Starting	Duration
		data	rate				time (s)	(s)
		Mb/s
	Flow1	40		H1-H9	D	NS3	0	4
	Flow2	45		H2-H10	D	NS1	0	24
	Flow3	10		H3-H11	A	NS2	5	19
	Flow4	40		H4-H12	D	NS1	10	30
	Flow5	30		H5-H13	C	NS1	15	25
	Flow6	20		H6-H14	B	NS2	20	20
	Flow7	30		H7-H15	C	NS3	25	15
	Flow8	10		H8-H16	A	NS3	30	10
	following the aforementioned graphs will be analyzed.
	• At time t=0, Flow 1 of type D is sent from source host H1 to destination host H9
	at the rate of 40 Mb/s for 4 seconds. Referring to table 4.1 (path and end-points),

Table 4 . 3 :

 43 Flow DB operations

Table 4 . 6 :

 46 VMs resources capacitiesThe goal of the experiments is to evaluate the impact of the InterS approach combined to the flow arrival rate on both the total slice flow acceptance (TSFAR) and the bandwidth usage (TSBUR) rates. Thus, the performance metrics considered for this study is the the TSFAR and TSBUR. TSFAR and TSBUR are respectively calculated using the equations 4.1 and 4.2 below. The terms of both equations are described in

	Cluster	CPU	Cores	Memory	Storage
	Grimoire	2 x Intel Xeon	8 cores/CPU	128 GiB	600 GB HDD
		E5-2630 v3			+ 4 x 600 GB
					HDD + 200
					GB SSD
	Grisou	2 x Intel Xeon	8 cores/CPU	128 GiB	1 x 600 GB
		E5-2630 v3			HDD + 1 x
					600 GB HDD

Table 4 . 7 :

 47 Equations terms and meanings

  Algorithm 1: Non preemptive sharing mode Input : The new arriving Flow, F low F Output : Accept or Reject F low F 1 i ← Get the NS identifiant to which F low F is belonging to 2 if Slice i .f reeBW () >= F low F 's guarenteed data rate (FGR) Scale up Slice i with Slice n resources for F low F (Scale down to normal after F low F termination)

	3	Pass
		// F low F Accepted, Go to line 10
	4 else
	5	n ← Get the neighbor Slice identifiant with the Maximum free bandwidth
		resources(If it exists)
	6	if Slice n .f reeBW () >= FGR
		// F low F Accepted
	8	else
	9	Reject F low F
	10 if F low F is not Rejected
	11	Reserve Slice i resources for F low F
	12	Configure data plane for F low F
	13	Forward F low F to Slice i
	4.3.3.2 Numercial Results

7

Table 4 .

 4

	8: the TSFAR (/458) and TSBUR (/500) obtained from each scenario for different flow arrival
					rates.
	rate:1	rate:1/2	rate:1/4	rate:1/8	rate:1/16
	TSBUR TSFAR TSBUR TSFAR TSBUR TSFAR TSBUR TSFAR TSBUR TSFAR
	SC1 242.82	289 222.031 301 194.869 335 169.407 393	125.02	437
	SC2 254.108 299 237.359 320 218.033 366 188.148 432 131.748 454
	SC3 261.344 306	245.6	331 228.764 385 198.008 446 132.765 458

Table 4 .

 4

	9: Improvement values (%) in TSFAR and TSBUR per event rate from SC1 to SC3 and SC1 to
					SC2
	rate:1	rate:1/2	rate:1/4	rate:1/8	rate:1/16
	TSBUR TSFAR TSBUR TSFAR TSBUR TSFAR TSBUR TSFAR TSBUR TSFAR
	SC1->SC3 7.63	5.88	10.62	9.97	17.39 14.93 16.88 13.49	6.2	4.81
	SC1->SC2 4.65	3.46	6.9	6.31	11.89	9.25	11.06	9.92	5.38	3.89

  This rate is approximately the same for the other experiences since the observed behavior is the same. Although this value

seems negligible for this experience, its impact may cause relevant loss in the achieved TSBUR as indicated by the ideal TSBUR values in table 4.10. TSBUR values in the current section (table 4.8) are calcultaed based on the achieved throupuut of flows.

Table 4 .

 4 10: the ideal TSBUR (/500) obtained from each scenario for different flow arrival rates.

		rate:1	rate:1/2	rate:1/4	rate:1/8	rate:1/16
	SC1	246.846	225.391	199.168	172.853	126.881
	SC2	258.117	240.075	220.898	191.355	133.081
	SC3	264.862	248.25	231.439	201.333	135.109

Algorithm 2 :

 2 Resource aggregation from multiple neighbor slices Input : The new arriving Flow, F low F Output : Accept or Reject F low F 1 i ← Get the NS identifiant to which F low F is belonging to 2 if Slice i .f reeBW () >= F low F 's guarenteed data rate (FGR) Slice i with RR from Slice k Scale up Slice i with all Slice k .f reeBW ()

	3	Pass
		// F low F Accepted, Go to line 20
	4 else
	5	n ← Get the neighbor Slice identifiant with the Maximum free bandwidth
		resources(If it exists)
	6	if Slice n .f reeBW () >= FGR
		// F low F Accepted
	14	break
	15	else
	16
	18	else
	19	Reject F low F

7 Scale up Slice i with Slice n resources for F low F (Scale down to normal after F low F termination) 8 else if 2d implementation is enabled and FGR <= all k Slice k .f reeBW () // F low F Accepted 9 RR ← F GR -Slice i .f reeBW () 10 Sort neighbor Slices descendingly based on free resource criteria (From highest to lowest) // Scale up Slice i with the required resources RR from neighbor Slices 11 foreach Slice k in neighbor Slices 12 if Slice k .f reeBW () >= RR 13 Scale up 17 RR ← RR -Slice k .f reeBW () 20 if F low F is not Rejected 21 Reserve Slice i resources for F low F 22 Configure data plane for F low F 23 Forward F low F to Slice i

Table 4 .

 4 16: Example of flows distribution

	Flow Types	Total Flows (/458)
	Type 0	55
	Type 1	331
	Type 2	33
	Type 3	17
	Type 4	22

Acknowledgments

I

. I greatly appreciate the support of Mr Abdulhalim Dandoush. I am grateful for his help and valuable support.

Availability

Float Availability UE Speed integer (Km/h) Supported device velocity Nevertheless, the GSMA GST template extends the 3GPP service/slice profile with standardized slice characteristics. As for IETF, it is not yet clear if the customer service model supports a service graph or a transport slice profile following the same modelling of 3GPP within the RAN and CN. In fact, authors in [START_REF] Rokui | 5G Transport Slice Connectivity Interface[END_REF] proposed an initial version of the NS customer service model at the CMI interface also called Transport Slice

Abbreviations

5G

Fifth Generation of Mobile Networks.

V2X

with a reserve of NS bandwidth availability. Figure 4.4 shows the initial design of InterS under the Ryu SDN framework [START_REF] Ryu | [END_REF]. • Flow departure event: is captured by the flow termination program (FTP) which trigger the reservation system and coordinates its interaction with the flow DB and the slice DB to respectively release NS bandwidth resources and delete flows from the flow DB.

Following the arrival of each new flow, the FAP get notified and launches the following InterS components:

1. Authentication: After the verification that the received notification is about the arrival of a new flow, the FAP launches the flow authentication process. The latter will verify that 1)the source host is belonging to an already established NS,

2) the flow type indicated in the flow is supported in the system and 3) the switch triggering the flow arrival notification is the Slice Access Point (SAP). Following different arrival rates.

We have defined 3 scenarios with 5 network slices that share the same S1-S2-S3

path. Each slice has 100 Mb/s initial bandwidth capacity out of the 500 mb/s available in the physical path. In scenario 1 all the slices are instantiated as exclusives. In scenario 2, only 2 slices are exclusives and the 3 remaining ones are shared. Lastly, scenario 3 defines all the slices as shared. Table 4.4 specify the sharing mode that will be implemented and evaluated in each of the following sections. In all the iterations of all the experiments, we generate a random number of flows uniformly in the interval [START_REF] Mckeown | OpenFlow: enabling innovation in campus networks[END_REF][START_REF] Xavier De Foy | Interconnecting (or Stitching) Network Slice Subnets. Internet-Draft draft-defoy-coms-subnet-interconnection-03[END_REF]. All the values of the parameters related to each flow are also generated randomly such as the source host, the destination, the slice identifier, the arrival time, the transmission duration, and the flow type. The Flow rate is a summation of the flow's guaranteed rate and a number picked randomly from the [1,[START_REF]View on 5G Architecture version 1.0[END_REF] interval. The later simulates a flow excess rate that will be dropped later by InterS.

For each experiment, we vary the flow duration between 40 and 180 seconds. We note

We are particularly interested by analyzing the improvement in TSBUR and TSFAR between the extreme scenarios 3 and 1 for each events rate. We observe from Figure 4.7 that the minimum augmentation in TSBUR and TSFAR is achieved by an events rate equal to 1/16. In this case TSBUR and TSFAR are respectively improved in scenario 3 comparing to scenario 1 by 6.2% and 4.8%. The maximum increase in TSBUR and TSFAR is achieved by an events rate equal to 1/4. In this case TSBUR and TSFAR are respectively improved by 17.4% and almost 15%. Likewise, we observe roughly this same pattern in the improvement from scenario 1 to scneario 2.

We conclude from the results illustrated in Figure 4.7 as well as table 4.9 that InterS performs the best at moderate flow arrival rates such as 1/4 and 1/8.

We think that this a logical conclusion since at high events rates the flows' interarrival times converge to 0. This means that they all arrive in approximately the same moment so that the total slices' bandwidth capacities are insufficient to serve them all. As a results a significant number of flows will be rejected in both the "Exclusives" and the "Shared" scenarios. Likewise, at a low events rate setup, flows' arrival are sufficiently separated in time so that a significant number of flows is accepted in both the "Exclusive" and the "Shared" scenarios.

We observe also, from table 4.8, that in the whole realized experiments, the flow acceptance rate has reached 100% only at scenario 3 with the 1/16 events rate setup. flow events rate. We are particularly interested by analyzing the improvement in TSBUR and TSFAR between the extreme scenarios 3 and 1 for each events rate. We observe from Figure 4.12 that the minimum augmentation in TSBUR and TSFAR is respectively achieved by the 1/16 and the 1 events rates. In this case TSBUR and TSFAR are respectively improved in scenario 3 comparing to scenario 1 by 6.41% and 1.73%. The maximum increase in TSBUR and TSFAR is achieved by an events rate equal to 1/4. In this case TSBUR and TSFAR are respectively improved by 18.6% and 14.63%.

Regarding the amelioration from scenario 1 to scenario 2, the maximum increase in TSBUR and TSFAR is respectively achieved by the 1/4 and 1/8 events rates.

We conclude from the results illustrated in Figure 4.12 as well as table 4.12 that this implementation of InterS performs the best at moderate events arrival rates such as 1/4 and 1/8. We observe also, from table 4.11, that in the whole realized experiments, the flow acceptance rate has reached 100% only at scenario 3 with the 1/16 events rate setup.

moving from scenario 1 to sceanrio 2 and 3. This is happening because the shared non preemptive reservation level does not allow a Slice to retrieve its resouces used by other slices until the later realases them. Therefore, this sharing mode is benefiting some slices on the expense of penalizing others. This limitation is even more important in high flow arrival rates as shown by table 4.13. In fact, Slice 2 is significantly penalized in scenario 2 as well as 3 for "rate:1" but slightly penalized in "rate:1/4" and only in sceanrio 2.

Implementation and Evaluation of the Shared Preemptive Mode

The goal of this section is to extend InterS with the implementation of the shared preemptive resource reservation level defined in the COMS information model. Instantiating a NS as shared preemptive means that its free resources can be used by neighbor NS instances but are retrieved immediately if the NS needs them. The new sharing mode is then integrated to InterS and evaluated.

InterS'Design Extension

In order to realize the shared preemptive feature, InterS is extended with a new component that manages the retrieval of resources and the re-admission of flows as shown in Figure 4.17. In contrary to the shared non preemptive mode, a shared preemptive Slice has the priority and the authority over its resources during the whole operation time. Thus, it can retrieve its resources from neighbor slices immediately after a flow arriving event if the available resources are not sufficient to support the flow. Because of the instantaneous resource retieval characteristic of the shared preemptive slice, one or which it is belonging to.

• "admitted but not definitively" if it is fully or partialy supported by resources of one or multiple neighbor slices. Thus, the resources can be retrieved any time during the flow transmission which causes the flow to be stopped and introduced again to the admission system.

• rejected if its proper slice does not possess the required resources and the latter are not available within neighbor slices to be acquired at the flow arrival time.

Algorithm

As observed from section 4.3. The new algorithm of the admission system has the same structure as the one of the first implementation of the shared non preemptive but with some key differences.

The output of the optimization algorithm is a list of flows associated to their guarented data rates F i /R i with i in [1,m]. If there is multiple flows with the the same guarented data rate, the lastly arrived flow will be selected by the algorithm to be stopped and sent for re-admission. In this way, we are privileging old flows over the recent ones. This is a part of the optimization algorithm since the old flows have existed in the network for a longer time and have generally more chance to complete the data transmission than the recent ones. We believe this will contribute to an increase of the flow acceptance rate.

Numerical Results

The obtained results, shown in We are particularly interested by analyzing the improvement in TSBUR and TSFAR between the extreme scenarios 3 and 1 for each events rate. We observe from Figure 4.19 that the minimum augmentation in TSBUR and TSFAR is respectively achieved by the 1 and the 1/16 events rates. In this case TSBUR and TSFAR are respectively improved in scenario 3 comparing to scenario 1 by 4.62% and 4.81%. The maximum increase in TSBUR and TSFAR is respectively achieved by the 1/8 and 1/4. In this case TSBUR and TSFAR are respectively improved by 16.8% and 13.73%.

Regarding the improvement achieved in scenario 2, the shared preemptive implementation has outperformed at the 1 and the 1/2 events rates for TSBUR and the 1, 1/4 and 1/16 for TSFAR.

Generally, we conclude that the the difference in performance between the implmentation of the two sharing modes is not so relevant. We recall that the different values of TSFAR and TSBUR improvement corresponding to each of these two implementations are detailled in tables 4.9 and 4.15.

In the shared preemptive implementation, the inter-slice bandwidth resource sharing approach does not come with the limitation found in the previous resource reservation level and discussed in section 4.3.6. In fact, no slice is penalized in favor to another and this for all the flow events rate of the experiment. This can be observed firstly in As concluded in section 4.3.6, the limitation is even more important in higher events rates. Table 4.17 demonstrates the abscene of the issue in the shared preemptive implementation by providing the per slice flow acceptance rate at the highest events rate of the experiment (rate 1). Finally, we conclude that the two sharing modes have achieved closer results in terms of performance, but the shared preemptive resource reservation level is more important and priviliged since its resolve the issue of slice penalization.

Conclusion

The Network Slicing paradigm promises operators to cope with the high variety of 5G services. The network optimization issues of slice-based infrastructures is still an interesting challenge. In this direction, this chapter proposed a novel approach we called inter-slice bandwidth resources sharing based on the COMS information model. We are