5G network slice manager

(1)

Universidade de Aveiro Departamento de Eletrónica,Telecomunicações e Informática 2019

Henrique Almeida

Andrade de Castro

Cruz

Gestor de Slices de Rede 5G

5G Network Slice Manager

(2)

(3)

Universidade de Aveiro Departamento de Eletrónica,Telecomunicações e Informática 2019

Henrique Almeida

Andrade de Castro

Cruz

Gestor de Slices de Rede 5G

5G Network Slice Manager

Dissertação apresentada à Universidade de Aveiro para cumprimento dos requisitos necessários à obtenção do grau de Mestre em Engenharia de Com-putadores e Telemática, realizada sob a orientação científica do Doutor Rui Luís Andrade Aguiar, Professor Catedrático do Departamento de Eletrónica, Telecomunicações e Informática da Universidade de Aveiro, e do Doutor Daniel Nunes Corujo, Professor Investigador Doutorado do Departamento de Eletrónica, Telecomunicações e Informática da Universidade de Aveiro.

(4)

(5)

o júri / the jury

presidente / president Professor Doutor Atílio Manuel da Silva Gameiro Professor Associado da Universidade de Aveiro

vogais / examiners committee Professor Doutor Bruno Miguel de Oliveira Sousa

Professor Auxiliar Convidado do Departamento de Engenharia Informática da Faculdade de Ciên-cias e Tecnologia da Universidade de Coimbra

Doutor Daniel Nunes Corujo

Investigador Doutorado do Departamento de Eletrónica, Telecomunicações e Informática da Uni-versidade de Aveiro

(6)

(7)

agradecimentos /

acknowledgements Agradeço a orientação aos Professores Rui Aguiar e Daniel Corujo, ao grupodo ATNoG-IT Aveiro, assim como à minha família e amigos. Esta dissertação foi realizada com o apoio do Instituto de Telecomunicações.

(8)

(9)

Palavras Chave 5G, NFV, Slices de Rede, OSM, Aplicação Web, Sistema de Gestão

Resumo A Quinta Geração de Redes Móveis (5G) apresenta-se como a mais

revoluci-onária geração de redes móveis até agora. Impulsionada por novos desafios que tecnologias emergentes e casos de uso promovem, o 5G será essen-cial para potenciar novos serviços e lidar com a exigência dos requisitos que daí advêm. Para atingir estas metas definidas para o 5G, novas tecnologias destacam-se como as Redes Definidas por Software (SDN), a Virtualização de Funções de Rede (NFV) e as Slices de rede. Estas últimas serão essen-ciais para garantir Qualidades de Serviço e Experiência a serviços verticais que necessitam de garantias de segurança e isolamento dos seus dados en-quanto beneficiam de redes virtuais dedicadas cujos elementos físicos são partilhados para outras Slices ou Funções de Rede. Desta forma, os Opera-dores de Rede conseguem fornecer novos e melhorados serviços enquanto garantem menores custos operacionais e capitais. No entanto, tecnologias como o Slicing de Redes encontram-se permaturas e um sistema prático para a sua gestão entre o cliente e o fornecedor será essencial para alcançar efici-entemente os objetivos da mesma. Esta dissertação apresenta uma prova de conceito de um gestor de Slices de Rede 5G através de uma plataforma web desenvolvida para o efeito.

(10)

(11)

Keywords 5G, NFV, Network Slicing, OSM, Web Application, Management System

Abstract The Fifth Generation of Mobile Networks (5G) is presented as the most

evo-lutionary generation of mobile networks to date. As new and upcoming tech-nologies and use cases promote new challenges, 5G will have to meet these demands. In order to do this, new technologies are being introduced, such as Software Defined Networks (SDN), Network Function Virtualization (NFV) and Network Slicing. Network Slices will be essential to guarantee customized Quality of Service and Experience to vertical industries and use cases while they benefit from dedicated virtual networks whose physical elements are shared by other Slices or Network Functions. Consequently, Network Op-erators will provide new and improved services while guaranteeing lesser op-erational and capital costs. However, technologies such as Network Slicing are still in a premature state and a practical management system is essential to effectively reach its goals. This thesis presents a proof of concept of a 5G Network Slice Manager through a web platform specifically developed for this purpose.

(12)

(13)

4 Evaluation 45 4.1 Testing Methods . . . 45 4.2 Results . . . 46 4.2.1 Listing actions . . . 46 4.2.2 Adding/Sharing actions . . . 47 4.2.3 Deleting actions . . . 48 5 Conclusion 49 5.1 Conclusion . . . 49 5.2 Future Work . . . 50 References 51 Appendix-A: OSM NBI 55 URL and Methods Summary of OSM Release FIVE NBI . . . 55

Appendix-B: Testing Script 57

(15)

List of Figures

2.1 5G Diversity of service, use case and requirements . . . 4

2.2 NFV reference architectural framework . . . 7

2.3 NFV architecture evolution. . . 8

2.4 Network Slicing Architecture Functional Layers - NGMN . . . 9

2.5 Network Slicing Architecture Functional Layers - 5GPPP . . . 11

2.6 Network Slice Management functional architecture . . . 13

2.7 Network Slice Management Function . . . 14

2.8 Network slice creation process . . . 16

2.9 Overall 5GTANGO Architecture . . . 17

2.10 5GTANGO Slice Manager Architecture . . . 18

2.11 Broad mapping of OSM components to NFV functional blocks . . . 19

2.12 Relation between Network Slices and vanilla ETSI NFV Network Services . . . 20

2.13 Open Baton Release 2 Architecture . . . 22

2.14 ONAP Platform Architecture (Casablanca Release) . . . 23

3.1 System Architecture Diagram . . . 28

3.2 System Functional Architecture Diagram . . . 29

3.3 Database Architecture Diagram . . . 30

3.4 Login Page . . . 31

3.5 Admin Landing Page view - All system Network Slices . . . 32

3.6 Adding a Slice . . . 32

3.7 Admin Catalogues view - All system VNFDs . . . 33

3.8 Admin Catalogues view - All system NSDs . . . 33

3.9 Adding NSD . . . 34

3.10 Admin view - All system OSM Accounts . . . 35

3.11 Adding OSM Account - All required Information . . . 35

3.12 Admin view- All Users List . . . 36

3.13 Admin view - Adding User . . . 36

(16)

3.15 Slice Owner Information - Newly created Slice . . . 38

3.16 Slice Owner Information - VNFDs and NSDs added to Slice . . . 38

3.17 Slice Deployment - Replication of OSM Error example . . . 39

3.18 Slice Owner view - Deployed Slice Info . . . 40

3.19 Deployed Slice view - Composing Network Services Information . . . 40

3.20 Slice Owner view - Member Management . . . 41

3.21 OSM Graphical User Interface - VNF Packages List . . . 42

3.22 OSM Graphical User Interface - NS Packages List . . . 42

3.23 OSM Graphical User Interface - NS Instances List . . . 43

(17)

List of Tables

4.1 Median Request Time - Listing actions . . . 46

4.2 Median Request Time - Adding actions . . . 47

4.3 Median Request Time - Sharing actions . . . 47

(18)

(19)

Glossary

3GPP 3rd Generation Partnership Project 4G Fourth Generation of Mobile Networks 5G Fifth Generation of Mobile Networks

5GPPP 5G Infrastructure Public Private

Partnership

AAA Authentication, Authorization and Accounting

API Application Programming Interfaces BBF Broadband Forum

BSS Business Support Systems

CAPEX Capital Expenditure

CDN Content Delivery Network eMBB Extreme Mobile Broadband EM Element Manager

EMS Element Management System ETSI European Telecommunications

Standards Institute

FCAPS Fault, Configuration, Accounting,

Performance, Security

GSMA Groupe Spéciale Mobile Association HNF Hybrid Network Functions

IETF Internet Engineering Task Force IoT Internet of Things

ISG Industry Specification Group

ITU-T International Telecommunication Unit

-Telecommunication Standardization Sector

KPI Key Performance Indicators MANO Management and Orchestration MEF Metro Ethernet Forum

mMTC Massive Machine Type Communications NaaS Network as a Service

NBI North-Bound Interface NF Network Functions

NFV MANO NFV Management and Orchestration NFV Network Function Virtualization

NFVI Network Function Virtualization Infrastructure

NFVI-PoP Network Function Virtualization Infrastructure (NFVI) Point of Presence NFVO Network Function Virtualization

Orchestrator

NGMN Next Generation Mobile Networks Alliance

NM Network Manager

NMS Network Management System NS Network Services

NSMF Network Slice Management Functions

NSSMF Network Slice Subnet Management

Functions

NSD Network Service Descriptors NSI Network Slice Instance

ONAP Open Network Automation Platform ONF Open Networking Foundation OPEX Operational Expenditure OSM Open Source MANO OSS Operations Support System PDU Physical Data Units PNF Physical Network Functions PoC Proof of Concept

QoE Quality of Experience QoS Quality of Service RAN Radio Access Network

REST Representational State Transfer SDC Service Design and Creation SDK Software Development Kit SDN Software Defined Networking SDO Standard Developing Organizations

SDM-C Software-Defined Mobile network

Control

SDM-X Software-Defined Mobile network

Coordinator

SFA Sales-Force Automation SLA Service Level Agreements SPA Single-Page Application

(20)

UI User Interface

URLLC Ultra-Reliable and Low Latency

Communications V&V Verification & Validation VIM Virtual Infrastructure Manager VM Virtual Machine

VNF Virtual Network Functions

VNFD Virtual Network Function Descriptors

VCA VNF Configuration Agent

VNF-FG Virtual Network Functions Forwarding

Graphs

VNFM Virtual Network Function Manager

WAN Wide Area Network

WIM Wide Area Network (WAN) Infrastructure Manager

(21)

1 | Introduction

1.1 Motivation

Nowadays we face a technology-driven world where new and evolved technologies aim to build and transform the way we live and interact as members of a connected society. As a result, it is expected that the amount of information exchanged over the networks will have an unprecedented volume as well as a demand for greater throughput, lower latency, ultra-high reliability, high connectivity density and higher mobility range, thus requiring new network technologies that allow one to tackle these new demands.

In light of this,5G is seen as the solution, one that will include optimization and efficiency as core values of its architecture. This new generation of mobile networks will operate in a heterogeneous environment in what concerns technologies, businesses and services, which will require new approaches that are lacking in the Fourth Generation of Mobile Networks (4G) and all its enhancements[1]. 5G will then bring to the table new network enablers such as SDN and NFV which in synergy provide performance, flexibility and efficiency in the approach to different scenarios, one of which will be Network Slicing: a fundamental 5G pilar that allows new services, businesses and vertical industries to be integrated in a network that tailors its resources to their technological and business needs[2]. In order to facilitate the operation of these slices across different domains there is the need of a platform that can ensure the management of these slices, their Virtual Network Functions (VNF) and Network Services (NS), its users and the multiple orchestrators available to them.

This thesis addresses these 5G-enabling technologies, focusing on network slicing and its management.

1.2 Objectives

This thesis aims to provide a proof of concept of a Network Slice management platform to be used by an operator. The implementation will consist of a web application that reflects a thought out management logic of slices, Virtual Network Function Descriptors (VNFD), Network Service Descriptors (NSD) and users.

Furthermore, the platform will allow the onboarding, instatiation and termination of VNFs and NSs by communicating with the NBI of OSM - Open Source NFV Management and Orchestration - a software stack aligned with European Telecommunications Standards

(22)

Institute (ETSI) NFV. The application should also serve as an aggregator, enabling a single point of control to operate different OSMs.

It should be noted that in the development of this platform OSM’s Release Four was used. However, given that OSM’s Release Five provides Network Slicing capabilities which are relevant to this thesis objectives, an overview of the latest release will be provided in Chapter 2.

1.3 Document Structure

The following document will present different chapters that will cover at first, in Chapter 2, an overview over the state of art regarding 5G and its enabling technologies as well as an insight into available projects and softwares. Chapter 3 will introduce the implemented system considering the Network Slice Manager produced for this thesis and present the web application developed. In chapter 4 is presented the application performance results. Finally, chapter 5 concludes this document and gives a perspective on future work that can be performed.

(23)

2 | State of the Art

This chapter introduces the state of the art concerning 5G, its enabling technologies, projects and softwares that are making possible this telecom evolution. After introducing 5G, it is presented an overview of NFV, its architecture and components, as well as an extensive rundown on Network Slicing: what it can achieve and what is required in order to meet its goals, the steps being made to reach a standardized architecture, the management and orchestration of Network Slices and a brief introduction on a relevant 5G Infrastructure Public Private Partnership (5GPPP) project. Furthermore, it is presented an outline on several Management and Orchestration softwares.

2.1 Fifth Generation of Mobile Networks - 5G

5G presents itself as the most evolutionary generation of mobile networks to date. As businesses and services adapt to recent and upcoming technologies, mobile networks must keep up with the consequent demands and prepare for an increasingly connected world. Therefore, 5G will have to meet standards that go beyond latency and speed: higher flexibility and efficiency overall, through the introduction of new technologies in the access, mobile edge, transport and core networks, as well as the support of new business models and user equipments. The 3rd Generation Partnership Project (3GPP) summarizes 5G’s requirements as the following[3]:

• Support for multiple access technologies; • Scalable and customizable network;

• Advanced Key Performance Indicators (KPI) (e.g., availability, latency, reliability, user experienced data rates, area traffic capacity);

• Flexibility and programmability (e.g., network slicing, diverse mobility management, NFV);

• Resource efficiency (both user plane and control plane);

• Seamless mobility in densely populated and heterogeneous environment;

• Support for real time and non-real time multimedia services and applications with advanced Quality of Experience (QoE)

With these requirements, 5G aims to provide three major services: Extreme Mobile Broad-band (eMBB), the natural evolution of 4G, supporting higher data rate stable connections with moderate reliability; Ultra-Reliable and Low Latency Communications (URLLC), for maximum reliability, low latency transmissions of small payloads, a service whose objective

(24)

is to empower new use cases that rely on critical communications; finally, Massive Machine Type Communications (mMTC) aims to serve Internet of Things (IoT) platforms that deal with non-critical sporadic connections of small data payloads[4].

Figure 2.1: 5G Diversity of service, use case and requirements [5]

To be able to provide these services, softwarization technologies, like NFV, SDN and Net-work Slicing, are key in meeting the requirements of programmability, flexibility, adaptability and capability. They are also an important feature to reduce Operational Expenditure (OPEX) and Capital Expenditure (CAPEX) as well as energy consumption while delivering an improved QoE[6].

2.2 Network Function Virtualization (NFV)

As user and industry requirements change rapidly, a mobile network has to be flexible and cost-efficient in adapting to these changes. NFV decouples Network Functions (NF) from physical devices, enabling 5G to be an agile tool that fulfills the need to ease the operational and managerial aspects of networks by leveraging virtualization technologies. Therefore, network equipments can be consolidated onto datacenters, distributed network nodes and at end user premises which host services decomposed into a set of VNFs that are reusable[7]. This will allow Network Operators to create new approaches for operations, service assurance, security and to emerge with new network topologies. Complementing SDN without being mutually exclusive, the virtualization of Network Functions provides various benefits, highlighted by ETSI[8]:

• Reduced equipment costs and reduced power consumption through consolidating equip-ment and exploiting the economies of scale of the IT industry;

(25)

• Increased speed of Time to Market by minimising the typical network operator cycle of innovation. Economies of scale required to cover investments in hardware-based functionalities are no longer applicable for software-based development, making feasible other modes of feature evolution. Network Functions Virtualisation should enable network operators to significantly reduce the maturation cycle;

• Availability of network appliance multi-version and multi-tenancy, which allows use of a single platform for different applications, users and tenants. This allows network operators to share resources across services and across different customer bases; • Targeted service introduction based on geography or customer sets is possible. Services

can be rapidly scaled up/down as required;

• Enables a wide variety of eco-systems and encourages openness. It opens the virtual appliance market to pure software entrants, small players and academia, encouraging more innovation to bring new services and new revenue streams quickly at much lower risk;

• Optimizing network configuration and/or topology in near real time based on the actual traffic/mobility patterns and service demand. For example, optimisation of the location and assignment of resources to network functions automatically and in near real time could provide protection against failures without engineering full 1+1 resiliency; NFV is applicable to both the data and control plane of mobile and fixed networks (e.g. Authentication, Authorization and Accounting (AAA) servers, Content Delivery Network (CDN)s, Firewalls, QoE measurement, routers, etc.) and is enabled by recent technologies such as Cloud Computing and Industry Standard High Volume Servers.

Since NFV is such a crucial technology for 5G, a consensus among the industry is imperative hence the ETSI’s NFV Industry Specification Group (ISG) creation that was tasked to produce a set of high level reference documents.

2.2.1 NFV Requirements

To comply with the 5G vision, NFV addresses multiple criteria, specially in a inter-operability, multi-vendor, multi-provider perspective.

First off, Performance of the VNFs, measured by indicators such as throughput and latency, while maintaing their Portability between different but standard datacenters even though the underlying programmable hardware platforms limit the maximum achievable performance.

Secondly, Manageability of the whole NFVI that provides flexibility and efficiency in operating VNFs (NFVI, VNF and NFV MANO are defined in the following section). This means that the NFVI resource utilization should improve, specially considering the Elasticity that Cloud Computing can provide. Moreover, NFV brings new challenges when managing Quality of Service (QoS).

Thirdly, Reliability and Stability while providing most services given that NFV operates in error-prone hardware platforms.

(26)

Finally, new Security concerns arise with NFV when operating VNFs, mainly when using third-party resources or due to integration complexity[9].

2.2.2 NFV Architecture

An important step in defining the underlying NFV framework was NFV ISG’s Architectural Framework document that set and industry-wide standard for the NFV ecosystem, enabling NFV to distinguish itself from the traditional network service provisioning in three key differences[10]:

• Decoupling software from hardware: As the network element is no longer a collec-tion of integrated hardware and software entities, the evolucollec-tion of both is independent of each other. This enables the software to progress separately from the hardware, and vice versa;

• Flexible network function deployment:The detachment of software from hardware helps reassign and share the infrastructure resources, thus together, hardware and software, can perform different functions at various times. Assuming that the pool of hardware or physical resources is already in place and installed at some NFVI Point of Presence (NFVI-PoP)s, the actual network function software instantiation can become more automated. Such automation leverages the different cloud and network technologies currently available. Also, this helps network operators deploy new network services faster over the same physical platform;

• Dynamic operation: The decoupling of the functionality of the network function into instantiable software components provides greater flexibility to scale the actual VNF performance in a more dynamic way and with finer granularity, for instance, according to the actual traffic for which the network operator needs to provision capacity. For this framework, three main working domains were identified: the VNF, a software implementation of a network function that runs over the NFVI, where the physical resources needed to support the virtualization execution are gathered and the NFV MANO responsible for the orchestration and lifecycle management of all resources and VNFs. Figure 2.2 depicts the functional blocks and reference points in the NFV Framework, explained above.

(27)

Figure 2.2: NFV reference architectural framework [10]

2.2.2.1 NFV Management and Orchestration (NFV MANO)

One of the main focus of this thesis will be the Management and Orchestration of the NFV framework. According to ETSI’s architecture, as depicted in Figure 2.2, NFV MANO is composed by three functional interconnected blocks[11]:

• NFV Orchestrator, responsible for onboarding VNF packages, Virtual Network Func-tions Forwarding Graphs (VNF-FG) and NS. It is also tasked with managing the NSs’ lifecycle and policies, global resources as well as validation and authorization of NFVI resource requests;

• Virtual Network Function Manager (VNFM), which manages VNFs’ instances lifecycle in addition to coordinating and adapting roles for configuration and event reporting between NFVI and the Element Management System (EMS) and/or Network Management System (NMS). In addition, ETSI’s NFV Architecture Framework allows for it to have multiple VNFMs;

• Virtual Infrastructure Manager (VIM), assigned to control and manage the NFVI compute, storage and network resources, within one operator’s infrastructure sub-domain. Furthermore, it collects and forwards performance measures and events;

As far as NFV MANOs go, an overview over Open Source Management and Orchestration (MANO) softwares, such as OSM1_{, OpenBaton}2 _{and ONAP}3 _{will be provided in section 2.4.}

1_{https://osm.etsi.org/} 2

https://openbaton.github.io/ 3_{https://www.onap.org/}

(28)

2.2.2.2 SDN enabled NFV Architecture

SDN is presented as another key technology to enable virtualization of the network infrastruc-ture providing foundations to isolate, abstract and share network resources. Complementing NFV, SDN can bring much added value by separating the control and data planes of a network, where the behaviour of network equipments, virtualized or otherwise, is controlled by a logi-cally centralized controller which is aware of the whole network, providing high level network programmability and allowing abstractions in the form of a detailed high-level schematic, thus improving flexibility and simplifying the dynamic deployment and operation of resources and consequently overlapping with some of the previously mentioned NFV requirements[12].

There are three architectural designs when it comes to the interaction, or not, of SDN and NFV: SDN agnostic, aware or enabled NFV architectures as one can see from Figure 2.3[13].

Figure 2.3: NFV architecture evolution [13]

While the first ETSI NFV Architecture did not mention SDN, many efforts were made in developing SDN controllers that could be incorporated in the aforementioned architecture. In [14], ETSI provides an overview on how SDN has been incorporated in the current ETSI NFV architecture framework. Either as SDN applications, resources or controllers, SDN can be positioned across most NFV components excluding the orchestrator and the VNF manager. In what regards SDN Controllers, a number of open source software implementations are available such as Floodlight4_{, OpenDaylight}5_{, ONOS}6_{, Ryu}7_{, among others.}

2.3 Network Slicing

As 5G use cases developed and their requirements grew increasingly diverse and extreme, Network Slicing was introduced as a solution by creating logical network slices across multiple domains and technologies to create tenant or service specific networks. Slices should realize an end-to-end vision across all the network, from the mobile edge to the network core. By leveraging NFV and SDN, network operators can build fully decoupled end-to-end logical

4_{http://www.projectfloodlight.org/} 5

https://www.opendaylight.org/ 6_{https://onosproject.org/}

(29)

networks on top of a common physical infrastructure in order to provide different QoS guarantees to different verticals.

Multiple definitions and concepts have emerged for Network Slicing. The Next Generation Mobile Networks Alliance (NGMN) defines a Network Slice as a "set of run-time network functions, and resources to run these network functions, forming a complete instantiated logical network to meet certain network characteristics required by the Service Instance(s)"[15]. This entails the existence of three layers (Figure 2.4):

• Service Instance Layer: represents the services as Services Instances which are supported. These can be provided by network operators or third parties;

• Network Slice Instance Layer: where the Network Slices are instantiated to provide network characteristics required by the Service Instance. Network Slices may also be shared across multiple Service Instances provided by the network operator and may be composed by zero or more Sub-Network Instances that can also be shared by Network Slice Instances. Both former and latter instances accrue from Blueprints that give a complete description of the structure, configuration and the plans/work flows for how to instantiate them;

• Resource Layer: a set of physical/logical resources, network infrastructure and/or network functions that provide dedicated and/or shared resources for Sub-Network and Network Slice Instances to run on.

Figure 2.4: Network Slicing Architecture Functional Layers - NGMN [15]

This entails that a Network Slice Instance is a run-time construct, and should be construed as being derived from a design time or configuration time "template" or a "blueprint". A Network Operator uses a Network Slice Blueprint to create a Network Slice Instance that provides the network characteristics which are required by a Service Instance. A Network Slice Instance may also be shared across multiple Service Instances provided by the network operator. A Network Slice Blueprint is a complete description of the structure, configuration

(30)

and the work flow for how to instantiate and control the Network Slice Instance during its life cycle, and refers to required physical and logical resources and/or to the Sub-Network Blueprint(s)[15].

Supported by NGMN’s Network Slicing concept, 5GPPP defines a slice as a "composition of adequately configured network functions, network applications and the underlying cloud infrastructure (physical, virtual or even emulated resources, Radio Access Network (RAN) resources, etc.), that are bundled together to meet the requirements of a specific use case, e.g., bandwidth, latency, processing, and resiliency, coupled with a business purpose"[16]. Furthermore, this definition with an established correspondence to ETSI NFV Architecture entails the existence of different layers, as Figure 2.5 shows:

• The Service layer comprises Business Support Systems (BSS) and business-level Policy and Decision functions as well as applications and services operated by the tenant. This includes the end-to-end orchestration system;

• The Management and Orchestration (MANO) layer includes ETSI’s NFV MANO functions, i.e., the VIM, the VNFM and the Network Function Virtualization Orchestra-tor (NFVO). An Inter-slice Broker handles cross-slice resource allocation and interacts with the Service Management function. Further, the MANO layer accommodates domain-specific application management functions. These functions would also implement ETSI NFV MANO interfaces to the VNFM and the NFVO. The Service Management is an intermediary function between the service layer and the Inter-slice Broker. It transforms consumer-facing service descriptions into resource-facing service descriptions and vice versa;

• The Control Layer accommodates the two main controllers, a Software-Defined Mobile network Coordinator (SDM-X) and a Software-Defined Mobile network Control (SDM-C), as well as other control applications. Following the SDN principles, SDM-X and SDM-C translate decisions of the control applications into commands to VNFs and Physical Network Functions (PNF). SDM-X and SDM-C as well as other control applications can be executed as VNFs or PNFs themselves;

• The Multi-Domain Network Operating System Facilities which includes different adaptors and network abstractions above the networks and clouds heterogeneous fabrics. It is responsible for the allocation of (virtual) network resources and maintains network state ensuring network reliability in a multi domain environment;

• The Data Layer comprises the VNFs and PNFs needed to carry and process the user data traffic.

(31)

Figure 2.5: Network Slicing Architecture Functional Layers - 5GPPP [16]

In order for Network Slicing to be supported, the management plane allocates a group of network resources, connects the physical and virtual networks and service functions as appropriate and instantiates all the network and service functions assigned to the slice. Furthermore, the control plane takes over the slice operations, governing all resources, functions and services, enabling their elasticity by configuring them to meet the service’s demands.

5GPPP highlights the following aspects as must-have capabilities of a Network Slice[16]: • Guarantees for isolation in each of the Data / Control / Management / Service planes.

Having enablers for safe, secure and efficient multi-tenancy in slices;

• Methods to enable diverse service requirements for a Network Slice, including guarantees for the end-to-end QoS of a service within a slice;

• Recursion, namely methods for a Network Slice segmentation allowing a slicing hierarchy with parent–child relationships;

• Methods and policies to manage the trade-offs between flexibility and efficiency in slicing;

• Resources and network functions Optimisation, namely methods for automatic selection of network resources and functions;

• Monitoring the status and behaviour of a Network Slice in a single and/or muti-domain environment; monitoring of a Network Slice interconnection;

• Capability exposure for a Network Slice with APIs for slice specification and interaction; • Programmability and control of Network Slices.

Given the above, Network Slicing can provide logical networks with better performance than one-size-fits-all networks, scale up or down as service requirements and number of users change, isolate the network resources of one service from the others enhancing reliability and

(32)

security, and can be customized according to service requirements which can optimize the allocation and use of physical network resources[17].

Other considerations, definitions and concepts were made by different Standard Developing Organizations (SDO), namely Internet Engineering Task Force (IETF)8_{, Broadband Forum} (BBF)9_{, Open Networking Foundation (ONF)}10_{, International Telecommunication Unit} -Telecommunication Standardization Sector (ITU-T)11_{, Metro Ethernet Forum (MEF)}12 _and Groupe Spéciale Mobile Association (GSMA)13 _{among others[18].}

2.3.1 Network Slicing Management and Orchestration

A Network Slicing MANO is a system responsible for all management and orchestration of Network Slices and the underlying resources and communications necessary to enable this innovative technology. In [19] a definition for Network Slice Management Functions (NSMF) appears, composing a slice-dedicated function with slice-specific view on any Fault, Configuration, Accounting, Performance, Security (FCAPS) data and management procedures. It has full visibility and control of the end-to-end slice and its performance. It resides above the Network Slice Subnet Management Functions (NSSMF) and monitors slice specific FCAPS to maintain and expose the overall Service Level Agreements (SLA) of the end-to-end slices to the tenant. The NSSMF manages Network Slice Subnets composed of Network Functions and other Network Slice Subnets. For management of virtualization aspects it interacts with NFV MANO. Figure 2.6 demonstrates the functional architecture of network slicing management with special focus in how the NSMF and NSSMF interact and position themselves within the network components.

8 https://www.ietf.org/ 9 https://www.broadband-forum.org/5g 10_{https://www.opennetworking.org/} 11 https://www.itu.int/en/ITU-T/Pages/default.aspx 12_{https://www.mef.net/} 13 https://www.gsma.com/

(33)

Figure 2.6: Network Slice Management functional architecture [19]

The above referenced document also states that a Network Slice Manager should provide different levels of control according to the relationship between "Slice Provider" - "Slice Consumer". These levels of control can be[19]:

• Monitoring only. The Slice Provider offers only means to monitor the slice KPIs as agreed in the contract. Network slice configuration is chosen from a catalogue of readymade slice templates. Accesses via dashboard-like web service and/or north bound interfaces provided by the Slice Provider;

• Limited control to Slice Consumer to perform design and composition of

network slice. Slice Consumer can change configuration of deployed network functions

and /or onboard own certified network functions into Slice Provider’s repository using interfaces provided by the Slice Provider;

• Extended Control. In this case the Slice Consumer deploys and operates the network slice using its own MANO stack and NMS. The Slice consumer has tight control over its own network functions and services while has limited control over Mobile Network Operator network functions.

In consequence of these different levels of control, the NSMF needs to support different abstractions of resources and to offer access to different management entities. Figure 2.7 the

(34)

positioning of the NSMF in a management function, aggregating data and providing a top level control of the whole slicing operation.

Figure 2.7: Network Slice Management Function (Network Slice segment term corresponds roughly to Network Slice subnetwork term used by 3GPP/NGMN) [19]

2.3.2 Network Slicing Business Perspective

As mentioned throughout this document, 5G enables businesses to keep up with their customer demands in a constant innovative field where new applications and service propositions appear faster than ever which entails a need for businesses to adapt as fast. Network Slicing is set as the technology that will meet these goals, creating separate use-case-specific logical networks over a shared physical infrastructure powered by new technologies such as NFV and SDN. A Network Slice will appear as a logical network serving a defined business purpose with particular characteristics, and comprises all the required network resources configured and connected together. It is important that Network Slicing lowers time to market, time to customer and operational costs for operators and businesses, while tailoring service characteristics, so templates or blueprints can shorten the process of creation of the Network Slices while preventing errors from human interaction, increasing efficiency and lowering OPEX. Ericsson provides an in depth process that defines the necessary steps to bring a Network Slice into commercial service, as seen in Figure 2.8[20]:

• Step 1 - Requirements: This step determines the necessary input parameters for creating and configuring a network slice. The more flexibility that is built into the requirements gathering, and template definitions, the more streamlined the process becomes. A key function of this step is to check if a template already exists for the type of network slice being created. If so, the following three steps (design, verification and

(35)

onboarding) can be skipped by proceeding straight to the ordering step (step 5). Thus, the following three steps are only necessary when customer requirements differ from what can be achieved using pre-defined templates. The aim is to have a catalogue of services and network slice templates which allow the ‘skipping’ to happen as often as possible, achieving savings through replication and automation;

• Step 2 - Design: The fact that the new service is going to be created within a dedicated network slice simplifies the design task because there are fewer dependencies and consequences to consider. There is no risk that the new service can impact any other service sharing the same resources. The modularity and programmability associated with network slicing streamline the design process. Design components can be selected from a menu, and the inherent programmability ensures their immediate usability; • Step 3 - Verification: The reduction in the number of service cross-dependencies

reduces the number of verification cases, by virtue of the isolation of the network slice. Fewer verification cases means fewer regression tests, and the whole task of verification is simplified and requires less time. Interestingly, network slicing can be used to facilitate testing. Network slice ‘sandboxes’ can be created, even in a live network, where new features and capabilities can be tested independently while minimizing risks to live traffic and services;

• Step 4 - Onboarding: This step refers to the uploading into the production system, and validation, of templates and other artefacts such as Virtual Machine (VM) images for example, needed by the orchestration system in the next step. Once again, the isolated nature of network slices reduces the risk of interfering with other services, and increases implementation speed. The BSS Catalogue is updated to include the new network slice templates, so that the offer modelled can be completed and an order created;

• Step 5 - Order activation: As the customer order is processed, resources are checked to make sure that the order is deliverable, and increased automation in the Sales-Force Automation (SFA) tools and BSS Catalogue reduces switch-on times and cost. Isolation between the network slices can minimize risk, as the activated changes cannot impact other existing resources. Due to lowered risks, and efficiency gains, operations departments will be more willing to accept order activations in an automated manner, avoiding manual steps and approvals delays;

• Step 6 - Service Assurance: Service assurance can be simplified and optimized, as each network slice can have its own performance targets assigned, in accordance with established SLA. Maintenance operations can be performed with reduced risks to other services, due to the network slice isolation. Upgrades can be performed in an increasingly risk-reduced manner, and a more ‘DevOps-like’ environment can be considered, especially in a network slice that is expected to require frequent updates, due to rapidly changing service requirements.

(36)

Figure 2.8: Network slice creation process[20]

This new type of Network as a Service (NaaS) business model grants customers the possibility to take control over their own network, creating and accommodating their network slices to meet service demands. Network Slices may offer in-slice management functions that supply or maintain the end user service or even provide full operational responsibility to the customer.

2.3.3 Network Slicing Research

In what regards Network Slicing Research and the objectives of this thesis, 5GTANGO implements a similar management system with focus on Network Slicing in its latest release. 5GTANGO(5G Development and Validation Platform for Global Industry-Specific Network Services and Apps)14 _{is a 5GPPP project that puts forth the flexible programmability of 5G} networks focusing on reducing network services’ time-to-market by shortening the service development cycle; reducing entry barriers for third party developers by supporting the creation and composition of VNFs and NSs; enabling new business opportunities with the customisation and adaptation of the network to vertical applications’ requirements; and accelerate NFV uptake in industry via and extended DevOps model and the validation at scale of Network Service capabilities of the 5GTANGO platform in vertical show cases[21].

5GTANGO builds upon the SONATA15 _{project to extend and improve the MANO} plat-form/Service Platform. SONATA developed an NFV framework that provides a programming

14

(37)

model and development toolchain for virtualized services, fully integrated with a DevOps-enabled service platform and orchestration system. It has two major building blocks: SONATA Software Development Kit (SDK) and SONATA Service Platform which are the base for 5GTANGO’s SDK and Service Platform, respectively. However, 5GTANGO also introduces a Verification & Validation (V&V) block that provides a testing environment for the SDK developed functions[22].

Figure 2.9: Overall 5GTango Architecture[22]

5GTANGO’s SDK provides a collection of tools empowering the service developer to rapidly build, validate and test NFV services. It enables a typical developer workflow supporting the creation of an isolated workspace and project environment, the generation and validation of descriptors, the packaging and onboarding, as well as the testing and emulation in a local development environment.

The V&V Platform is a mechanism of ensuring that the uploaded services can be tested on the appropriate target Service Platform to ensure that the service is considered fit for purpose.

The Service Platform provides the service and orchestration features, like slice management, policy and SLA management, user access management and infrastructure adapter[23].

2.3.3.1 5GTANGO Service Platform - Slice Manager

A key component of the 5GTANGO Service Platform is the Slice Manager that tackles the challenge of mappping Slice Instances to the physical and logical resources that are allocated to them. It supports flexible mechanisms for orchestrating and lifecylce managmenet of end-to-end Network Slices also taking into account verticals application requirements and SLA policies. Furthermore, 5GTANGO network slicing provides extended and novel isolation and customizable features, end-to-end telemetry and monitoring and end-to-end orchestration.

This Network Slice Manager is a Service Platform functional block that interacts with Operations Support System (OSS) and is responsible for interacting with the Service Platform

(38)

MANO framework to control network slicing.

Figure 2.10: 5GTANGO Slice Manager Architecture[24]

In Figure 2.10 one can identify two main components: the Slice Lifecycle Manager, which is responsible for assigning services and applications to network slices and for managing the lifecycle of these slices; and the Slice2NS Mapper that is responsible for mapping network slices to NFV Network Services.

The former instantiates a network slice by using a Network Slice Template previously onboarded, and assigns it to the customer, while also triggering the instantiation of underlying Network Services with the appropriate flavor and performance.

The latter maintains an association between the onboarded template and the underlying NSDs. The Network Slice Template includes a list of NSDs that need to be instantiated to comprise the Network Slice Instance, considering the applicable deployment flavor and performance requirements while also dealing with the combination of the Network Services. It is also responsible for maintaining the mapping between the slice and comprising Network Services for any lifecycle operation that needs to be performed[24].

2.4 NFV MANO Softwares

This section will provide an overview of different ETSI NFV aligned software stacks that ensure Management and Orchestration of a NFV implementation. It is also provided network slicing capabilities for each software.

2.4.1 Open Source MANO (OSM)

OSM is an orchestration and management system that provides support to a broad range of ETSI aligned NFVIs, VIMs, VNFs, NSs and Network Slices. It is used to manage life-cycle, configuration and in-life aspects of hosted functions. In the current Release Five (January 2019), OSM aims to minimize NFV integration efforts, enabled by[25]:

(39)

• Providing a NBI which enables the full operation of the system and Network Services and Slices by client systems;

• Extending the concept of Network Service, in order for a NS be able to span across different domains in an undistinguishable manner along with on demand transport connections among different sites;

• Managing the lifecycle of Network Slices, assuming the role of Slice Manager to an extent, extending it also to support an integrated operation.

Architecture wise, OSM splits its functionality into submodules, namely a Resource Orchestration component to handle cloud and physical resources, a VNF Configuration Agent (VCA) component to handle the interaction with VNFs/applications and a Monitoring Component in charge of monitoring procedures, on top of which sits a layer of Service Orchestration in charge of providing end-to-end coherency. OSM also implements a generic VNFM.

While looking south OSM consumes Application Programming Interfaces (API) from VIMs, SDN Controllers and VNFs, it also offers a northbound API for onboarding, control of lifecycles and in-life operations of NSs and VNFs. This NBI allows the implementation of the OSM Client but does not depend on it[26].

Figure 2.11: Broad mapping of OSM components to NFV functional blocks[26]

Through OSM’s NBI, two types of NaaS service objects are offered: Network Services and Network Slice Instances.

2.4.1.1 OSM as provider of Network Services

A Network Service is the minimal building block in OSM which bundles in one single service object a set of interconnected network functions (VNFs, PNFs and Hybrid Network Functions (HNF)) that can span across different underlying virtual or physical technologies, locations and geographical areas. These Network Services are provisioned through a method based on API invocations to OSM’s NBI and descriptors following OSM’s Information Model.

(40)

Therefore, Network Functions can be pre-modelled by different providers without affecting the provisioning of the Network Service itself.

Initially, a Network Service is modelled in a Network Service Package, that includes the complete blueprint of the NS behaviour with a full description of the NS topology, the lifecycle operations enabled and the NS primitives available. After the model is ready it can be onboarded into the system so that they can be used as templates for NS creation later on. The NBI offers API calls to support CRUD (Create, Read, Update, Delete) operations over the corresponding NS and NF Packages. While onboarding, OSM checks to validate in-model and cross-model consistency. Succeeding the onboarding, NS instantiation is performed. OSM takes as input a NS Package and a set of optional parameters. During this, OSM interacts with different service platforms (VIM and WAN Infrastructure Manager (WIM)) and the Network Functions to create the composite service object of the NS Instance. Once the NS has been successfully created, the NS Instance is subject to lifecycle operations, such as pausing/resuming, scaling, monitoring requests, software upgraded; and actions derived from NS primitives, i.e. actions relevant to the specific functionality of the service. OSM also allows other operations, namely to work with metrics and alarms to monitor the NS Instance. Finally, by calling the delete method of the API, a NS Instance can be finalized and its resources released[25].

2.4.1.2 OSM as provider of Network Slices

Network Slices are perceived by OSM as a set of various interconnected Network Services that are treated as a single entity forming a complete logical network to meet certain network characteristics[27].

Figure 2.12: Relation between Network Slices and vanilla ETSI NFV Network Services [25] From Figure 2.12 we can establish that a Network Slice is composed of one or more Network Subnets and that these are shares of a Network Service Instance.

(41)

Much like Network Services, Network Slices’ global lifecycle is comprised of four phases. Firstly, the preparation of the Network Slice Template where the necessary network envi-ronment is defined to support the lifecycle of the Network Slice Instance (NSI). Secondly, the instantiation of the Network Slice through the configuration of all resources to a state where the NSI is ready to be activated. Thirdly, in the Run-time phase the NSI is capable of handling traffic to support communication services. This phase also includes lifecycle and monitoring operations. Finally, a Decommissioning phase that releases dedicated resources and reconfigures the shared ones.

OSM supports two methods of management of Network Slices’ Lifecycle: Full End-To-End Management (Slice Manager and NFVO) and Standalone Management (only NFVO that interacts with a Standalone Slice Manager).

Focusing on the latter, the Standalone Slice Manager would require to ensure additional steps, specifically the onboarding of the different NSD that compose the Network Slice Template as well as ensuring the instantiation of the Network Services that comprise the Network Slice.

2.4.2 Open Baton

Open Baton is an open-source NFVO following ETSI NFV MANO specification aiming to foster the integration between VNF providers and Cloud Infrastructure providers. Open Baton connects with Openstack16_{, as a main provider of VIM functionalities for orchestrating} virtual resources, especially virtual machines and virtual networks. Open Baton provides three approaches when using the VNFM: a generic VNFM based on Advanced Message Queuing Protocol, an available SDK to implement a custom VNFM and a VNFM module via a Representational State Transfer (REST) interface. The VNFM connects with Open Baton’s included NFVO and generic EMS to complete the NFV framework[28].

Open Baton uses the ETSI NFV data model for definition of the NS and VNF Descriptors, allows interoperability and is easily extensible due to its message bus architecture that provides mechanisms to incorporate new functionalities and to be integrated in existing platforms.

(42)

Figure 2.13: Open Baton Release 2 Architecture [29]

Unlike OSM, Open Baton does not support Network Slices as defined above. Open Baton has a component named Network Slicing Engine (the NSE block in Figure 2.13) that only ensures QoS configurations that are defined in VNF and NS Descriptors[30].

2.4.3 Open Network Automation Platform (ONAP)

ONAP is a modular orchestration solution that supports YANG and TOSCA17 _{models. Its} architecture consists of two major frameworks each with several components: Design-time environment and Runtime Environment[31].

The first, divided in 2 sub-systems (Service Design and Creation (SDC) and Policy), represents the development environment with tools to define/describe and onboard resources, services and products as well as their management and control functions using a set of specifications and policies for controlling behaviour and process execution. SDC provides tools, techniques and repositories to define/simulate and certify system assets. ONAP provides a VNF SDK and VNF Validation Program to ensure a healthy VNF ecosystem when preparing the onboarding of VNF packages. The second, namely the Policy Creation component enforces rules, conditions, constraints and requirements by rapidly modifying rules thus allowing simpler management of complex mechanisms via abstraction.

The Runtime Environment allows for the distribution of policy enforcement and templates among the various ONAP modules such as the Service Orchestrator, Controllers, Data Collection, Analytics and Events, Active and Available Inventory, and a Security Framework. ONAP also provides an external NBI API that allows third-party frameworks to interact with relevant ONAP components.

The ONAP Operations Manager should also be highlighted, as a component that provides

17_{TOSCA vs.} _{Netconf a Comparison:} https://www.sdxcentral.com/nfv/definitions/tosca-vs-netconf-comparison/

(43)

the ability to manage cloud-native installation and deployments to Kubernets18_-managed cloud environments[32].

Figure 2.14: ONAP Platform Architecture (Casablanca Release) [32]

2.5 Summary

This chapter presented an overview over 5G and some of its enabling technologies, such as NFV, SDN and Network Slicing. It was also given examples of software stacks that provide Management and Orchestration to NFV Implementations and their inner workings and approaches.

The following chapter presents a produced practical scenario of a Slice Manager platform and some of its use cases.

18

(44)

(45)

3 | System Implementation

In this chapter an extensive view of the planning and implementation of a Network Slice Manager will be presented. The first section explains the a priori system requirements to build the managing logic of Network Slices and the underlying needs to produce it. Secondly, an overview of the technologies used and the architecture implemented is given. Finally, the developed application that provides a Proof of Concept (PoC) of a standalone network slice manager is presented.

3.1 System Requirements

First and foremost it was chosen to develop a Network Slice Manager that gave extended control, as defined in section 2.3.1, to its users while the "Slice Provider", as owner of the system, has full access and privileges to its contents. In the process of gathering the system’s requirements came the choosing of a NFVO that would allow third party applications to communicate with its components. Given some familiarity, availability, ease and documentation provided it was chosen ETSI’s Open Source MANO (OSM). Later in this section an overview of OSM’s NBI will be presented, that will allow this system to take actions within the orchestrator. In this case, OSM has the means to implement the role of NFVO and Network Manager (NM)/Element Manager (EM). Moreover, it was necessary to define what a practical implementation of a Network Slice would look like from a third party perspective, in what relates to the communication with the NFVO. At the time of development it was unknown how OSM would in fact implement capabilities to manage and instantiate a Network Slice and how that would translate into its NBI methods. Therefore this application was built around an abstraction of what a Network Slice should be, with its underlying Network Services and composing VNFs, which means that this system should manage this abstraction and leave the practical implementation for future work. As stated in 2.3.1, a Network Slice Manager should also have a specific view on slice FCAPS data and management procedures.

Given that this would be a system that should be accessible from anywhere it was chosen to produce it as a web application, which would allow to easily implement functions that interact with OSM’s NBI and show the results of these interactions in a web interface supported by a web service. The application should also allow communication with different OSMs, with each user being able to provide OSM user account information to establish connection and share it with other users.

(46)

It was also noted that the application should be a closed system, controlled by a super user that can ensure each user’s privileges and access. All the above information would be stored in a database specifically built to ensure storage of system information.

Certain usual web applications requirements were overlooked, such as loading times and user interface optimization concerns, to benefit the timeline in which the application was built.

The system requirements can be briefly compiled in the following:

• Management and storage of VNFD user catalogue, a user can upload and keep in its catalogue different VNFDs that are compliant with OSM’s Information Model ; • Management and storage of NSD user catalogue, a user can upload and keep in its

catalogue different NSDs that are compliant with OSM’s Information Model;

• Creation, editing and management of Network Slices. System users can create an abstract Network Slice that can be edited to include NSDs, and corresponding VNFDs, from the user catalogue or uploaded. The Network Slice owner should be able to manage other user’s access to it;

• Instantiation of "Network Slices" (which translates into Network Services and corre-sponding VNFs in the OSM). Given that these Network Slices are abstract and only exist in a management logic view, its instantiation leads to the onboarding and order to instantiate the composing network services;

• User management, a super user logic should be in place to control every aspect of the application, specially the creation and deletion of users since it is a closed system. The super user can grant privileges for users to access VNFDs, NSDs and Slices uploaded or created in the system;

• OSM account information management. The application should also work as an aggre-gator of Orchestrators where, given account details and configuration, Network Slices can be instantiated;

• Manage FCAPS procedures;

• A monitoring stack that allows users to scan and examine Slice behaviour and resource usage;

• Security of all communications and stored passwords. Security must always be a priority when dealing with potentially sensitive data.

3.1.1 OSM North-Bound Interface (NBI)

OSM North Bound Interface is a REST-full service following ETSI SOL005[33] standard. It admits both YAML/JSON formats.

By default it serves https (auto-signed certificate) on port 9999. Bearer authentication (with token) is used. Basic authentication or no authentication is also possible by changing the NBI configuration file on OSM installation. For developing purposes it admits web browser navigation using a basic http format.

This API provides Administrative Content Details where users, authorization tokens, projects and VIM accounts can be managed. It also provides Physical Data Units (PDU),

(47)

Virtual Network Function Descriptors (VNFD) and Network Service Descriptors (NSD) details as well as methods for Network Service Lifecycle Management. As of Release FIVE, which was launched prior to this implementation, it also provides management methods of Network Slice Templates and Network Slice Instances. In Appendix-A is provided a summary of the progress of the NBI implementation.

3.2 System Architecture

This section provides a view over the system’s architecture, illustrated in Figure 3.1 and its enabling technologies.

To develop the web User Interface (UI) it was used CoreUI1_{, a bootstrap admin template,} available in different frameworks, one of which - ReactJS2 _{- was used in this application.} ReactJS is a Javascript library that allows developers to build encapsulated components that manage their own state, and then compose them to make complex User Interfaces. In fact, CoreUI’s pre-built layout and components facilitated the development of the ReactJS Single-Page Application (SPA) that will be presented further down. It was also used React-Redux3_, a predictable state container for ReactJS applications.

The web app is served by a CherryPy4_{, a minimalist Python}5 _{Web Framework, that} implements two services: one enables the UI and information storage on the database and another that interacts with OSM NBI. The Database was created using MySQL6 _{and the} interactions between service and database ensured by SQLAlchemy7_{, a Python SQL Toolkit} and Object Relational Mapper that enables SQL databases.

1_{https://coreui.io/} 2 https://reactjs.org/ 3 https://github.com/reduxjs/react-redux 4 https://cherrypy.org 5 https://www.python.org/ 6_{https://www.mysql.com/} 7 https://www.sqlalchemy.org/

(48)

Figure 3.1: System Architecture Diagram

Some simple security considerations were taken into account to ensure data privacy in client-server requests and responses. For a full in production platform other security measures must be implemented and will be mentioned further in this document. The communications between UI and the CherryPy web service that provides methods for the UI actions are protected with Basic Authentication provided in the HTTP Request Headers to ensure access security to server resources. As for OSM’s NBI, communications use a Bearer Authentication with tokens as mentioned in the previous section. User passwords are hashed with SHA-256 algorithm plus salt. Figure 3.2 presents the architecture diagram that illustrates the functional blocks of the developed system.

(49)

Figure 3.2: System Functional Architecture Diagram

3.2.1 Database Architecture

A big part of a management system is reflected in the database architecture that stores the application information. Figure 3.3 shows the corresponding diagram that illustrates the MySQL database architecture implemented. From it, one can infer different layers that comprise various aspects of this application:

• User Management Layer: comprised of tables that store information about users and their ownership/membership of VNFDs, NSDs, Slices and OSM accounts;

• Slice Management Layer: gathers information on created Slices and their constitution (VNFDs, NSDs) as well as Network Services Instances when the slice is deployed; • OSM Management Layer: consists of OSM account information, onboarded VNFDs

(50)

Figure 3.3: Database Architecture Diagram

3.3 Network Slice Manager

The implementation of the Network Slice Manager began by developing a closed system, envisioned for Network Operators and Network Slice Clients, with a web interface that was built around the database architecture produced.

In fact, numerous changes were made both to the interface and supporting backend actions as the database architecture evolved throughout development. First was developed a simple application that could control most of OSM NBI relevant methods, with special focus on the onboarding and instantiation of Network Services and corresponding VNFs. Built on top, the Network Slice management provided new challenges because of its abstraction, which is explained above in this document, as well as the OSM account information management. From there was added the user management featuring a super user logic that would allow the system owner to control all aspects of the application, from user access and privileges to user catalogues and Slices.

Finally, a Proof of Concept was achieved, where an admin created user can:

• Upload/Delete OSM Information model compliant NSDs and VNFDs to its catalogue and share them with other users;

(51)

• Edit Slices (adding Network Services and VNFs to be instantiated that are owned by or shared to the user) and manage other users’ access to the Slice enabling a collaborative work mode with authorized personnel;

• Deploy Slices (instantiate underlying Network Services) to an existing or added OSM account and get information on NS Instances as well as terminating said Slices. Since the OSM release used does not support Network Slicing, the Slice deployment only reflects on the instantiation in OSM of the Slice comprising Network Services;

• Aggregate various OSM accounts where user Slices can be deployed and share these accounts with other users; Delete owned OSM accounts;

While the super user has privileges to do all the above, it is also capable of managing system users and all user stored information.

3.3.1 Login and Landing Page

On database instantiation is created an "admin" user which has all privileges and access to the platform. From there this user can create other users and use all system functions.

Figure 3.4: Login Page

The Login Page is an implemented page from CoreUI’s template. The Login action sets off a communication with the only public backend method to authorize a user. After this, user credentials are stored in the web application state in order to authorize future requests while using the system.

(52)

Figure 3.5: Admin Landing Page view - All system Network Slices

The initial Admin Landing Page presents all the created system Network Slices. Figure 3.5 shows the web interface layout with a Sidebar for platform navigation, a user configuration menu on top right and the container in the middle that will present the various pages of the application. From the Sidebar we can infer that these pages are the Slices page, Catalogues (NSD and VNFD), OSM Accounts and User Management. The latter is only available to the

super user.

For regular users it is used the same Layout. However, the system information shown is specific to user access and privileges and the User Management tab is inaccessible.

(53)

To create a Slice, a "plus" icon button enables a form where the user ir required to provide name and description of the slice.

3.3.2 VNFD and NSD Catalogues

The VNFD and NSD catalogues provide a table where users can manage their packages. Owned packages can be shared with other users. The super user can manage all user owned catalogues as can be seen on Figures 3.7 and 3.8.

Figure 3.7: Admin Catalogues view - All system VNFDs

Figure 3.8: Admin Catalogues view - All system NSDs

Each table entry presents information on creation date, name, description, name of the uploaded configuration file as well as the owner of the package. Three actions are provided to

(54)

the owner and the super user: more info on the table entry that enables a modal with VNF or NS configuration, a sharing and a delete option. To non-owners, i.e. users to whom a package was shared, the delete option is suppressed.

Figure 3.9: Adding NSD

Similar to the Slice table, adding a package enables a form that asks for name and description of the descriptor as well as the package file to be uploaded to the server that holds its contents for future onboarding to the orchestrator. It is expected that the user uploads an OSM Information Model compliant package to avoid errors when onboarding and instantiating the VNFs and NSs. However on Slice Deployment these packages are verified by the orchestrator and possible errors are propagated to the user, all this due to the system not having implemented capabilities to test said compliance and the actual onboarding of the packages is only requested on said deployment.

3.3.3 OSM Accounts

In this page, a user can manage different OSM accounts. It is assumed that these orchestrators are configured prior to being used, with focus on VIM accounts that must be added and ready to be used. Since the NBI does not support VIM specific actions, it is also expected that flavors and images for the different VNFs are present. The same OSM account can interact with different VIMs, therefore it is asked to be introduced which of those to use, especially because in order to deploy Slices, the NBI requires to identify which.