Programmable edge-to-cloud virtualization fabric for the ...

Project co-funded by the European Commission under the Horizon 2020 Programme.

Programmable edge-to-cloud virtualization fabric for the 5G Media industry

D4.2 - 5G-MEDIA Catalogue Portal and Network Apps Work Package: WP4 - 5G-MEDIA Open Repository of Network Apps Lead partner: UPM

Author(s):

Javier Serrano, David Jiménez, Federico Álvarez [UPM], Francesco Iadanza [ENG], Francesca Moscatelli, Giacomo Bernini, Lonrenzo Neri [NXW], Morteza Kherikhah [UCL], Gordana Macher [IRT], Igor Fritzsch [BIT], Rocío Ortiz, Alberto Florez [TID], Panagiotis Athanasoulis, Stamatia Rizou [SILO], Petros Drakoulis, Panagiotis Dimou, Stamatis Samaras, Nikolaos Zioulis, Alexandros Doumanoglou, Dimitros Zarpalas [CERTH]

Delivery date (DoA): 30/11/2019 Actual delivery date: 29/11/2019 Dissemination level: Public Version number: 1.0 Status: Final Grant Agreement N°: 761699 Project Acronym: 5G-MEDIA Project Title: Programmable edge-to-cloud virtualization fabric for the 5G

Media industry Instrument: IA Call identifier: H2020-ICT-2016-2 Topic: ICT-08-2017, 5G PPP Convergent Technologies, Strand 2:

Flexible network applications Start date of the project: June 1st, 2017 Duration: 33 months

5G-MEDIA - Grant Agreement number: 761699

D4.2 – 5G-MEDIA Catalogue Portal and Network Apps

Page 2 / 95

Revision History Revision Date Who Description

0.1 April, 26th 2019

UPM Template creation, ToC and assignment

0.2 July, 12th 2019 NXW Catalogue final release initial description

0.2 July, 11th 2019 ENG AAA initial contributions

0.3 September, 4th 2019

BIT Functions descriptions


NXW Catalogue final release description


SILO Accounting Agent

0.4 October, 17th 2019

IRT Section 7.2 Addition

0.5 November, 21st 2019

NXW Interfaces implementation


ENG Billing sub-section


UPM Section 7.1 Addition.

0.6 November, 27th 2019

ENG Billing refinement


UPM Final document consolidation


UPM Finalized document for submission

Quality Control Role Date Who Approved/Comment

Internal review Nov, 22nd 2019 Fatih Ustok, Selçuk Keskin (NETAS)

Comments and suggestions for improvement

Internal review Nov, 25th 2019 Gordana Macher (IRT) Comments and suggestions for improvement



Page 3 / 95

Disclaimer This document may contain material that is copyright of certain 5G-MEDIA project beneficiaries, and may not be reproduced or copied without permission. The commercial use of any information contained in this document may require a license from the proprietor of that information. The 5G-MEDIA project is part of the European Community's Horizon 2020 Program for research and development and is as such funded by the European Commission. All information in this document is provided "as is", and no guarantee or warranty is given that the information is fit for any particular purpose. The user thereof uses the information at its sole risk and liability. For the avoidance of all doubts, the European Commission has no liability with respect to this document, which is merely representing the authors’ view.

The 5G-MEDIA Consortium is the following:

Participant number Participant organisation name Short

name Country

01 ENGINEERING – INGEGNERIA INFORMATICA SPA ENG Italy

02 IBM ISRAEL - SCIENCE AND TECHNOLOGY LTD IBM Israel

03 SINGULARLOGIC ANONYMI ETAIREIA PLIROFORIAKON SYSTIMATON KAI EFARMOGON PLIROFORIKIS SiLO Greece

04 HELLENIC TELECOMMUNICATIONS ORGANIZATION S.A. - OTE AE (ORGANISMOS TILEPIKOINONION TIS ELLADOS OTE AE) OTE Greece

05 CORPORACION DE RADIO Y TELEVISION ESPANOLA SA RTVE Spain

06 UNIVERSITY COLLEGE LONDON UCL United Kingdom

07 TELEFONICA INVESTIGACION Y DESARROLLO SA TID Spain

08 UNIVERSIDAD POLITECNICA DE MADRID UPM Spain

09 INSTITUT FUER RUNDFUNKTECHNIK GMBH IRT Germany

10 NEXTWORKS NXW Italy

11 ETHNIKO KENTRO EREVNAS KAI TECHNOLOGIKIS ANAPTYXIS CERTH Greece

12 NETAS TELEKOMUNIKASYON ANONIM SIRKETI NET Turkey

13 INTERINNOV SAS IINV France

14 BITTUBES GMBH BIT Germany

15 NATIONAL CENTER FOR SCIENTIFIC RESEARCH “DEMOKRITOS” NCSRD Greece



Page 4 / 95

Table of Contents

EXECUTIVE SUMMARY ................................................................................................................. 11

1. INTRODUCTION .................................................................................................................... 12 1.1. SCOPE OF THE DELIVERABLE ............................................................................................................................ 12

2. OVERALL 5G-MEDIA ARCHITECTURE .................................................................................... 13

3. INFORMATION MODEL SPECIFICATIONS .............................................................................. 17

4. 5G APPS AND SERVICES CATALOGUE.................................................................................... 17 4.1. FINAL RELEASE ............................................................................................................................................. 17 4.2. CATALOGUE PORTAL ...................................................................................................................................... 21

4.2.1. Design and interfaces .......................................................................................................................... 22 4.2.2. Left-side menu and available operations .............................................................................................. 23

5. SECURITY FRAMEWORK (AAA) ............................................................................................. 29 5.1. AUTHENTICATION AND AUTHORIZATION ............................................................................................................. 29 5.2. ACCOUNTING .............................................................................................................................................. 39

5.2.1. The role of Accounting Agent in the Accounting & Billing services......................................................... 48

6. INTERFACES IMPLEMENTATION ........................................................................................... 52 6.1. 5G APP AND SERVICE CATALOGUE NBI IMPLEMENTATION ...................................................................................... 52

6.1.1. NSD and VNF Package management interface ..................................................................................... 52 6.1.2. Catalogue-to-Catalogue interface ........................................................................................................ 52 6.1.3. Admin interface ................................................................................................................................... 53

6.2. 5G APP AND SERVICE CATALOGUE SBI IMPLEMENTATION ...................................................................................... 55 6.2.1. OSM R3/R4/R5/R6 MANO Plugin ......................................................................................................... 55 6.2.2. OpenStack VIM Plugin ......................................................................................................................... 55 6.2.3. Catalogue-to-Catalogue Plugin ............................................................................................................ 56

7. MEDIA AND NETWORK FUNCTIONS REPOSITORY ................................................................ 57 7.1. GENERIC NETWORK FUNCTIONS ....................................................................................................................... 57

7.1.1. Generic VNFs and PNFs descriptions .................................................................................................... 59 7.2. MEDIA NETWORK FUNCTIONS ......................................................................................................................... 64

7.2.1. Media VNFs and PNFs descriptions ...................................................................................................... 69

8. CONCLUSIONS ...................................................................................................................... 88

9. REFERENCES ......................................................................................................................... 89

ANNEX I – INTRA-OSM KAFKA BUS NOTIFICATION SAMPLES FOR THE LCM OPERATIONS .......... 90

ANNEX II – NSD AND VNF PACKAGE MANAGEMENT OPERATIONS.............................................. 93



Page 5 / 95

List of Figures

Figure 1 – Architecture of the 5G-MEDIA platform (Source D2.3 [2]) ................................... 14

Figure 2 – Private and Public catalogues functional design ................................................... 19

Figure 3 – Updated high-level software design..................................................................... 20

Figure 4 - 5G Apps and Services Catalogue Portal ................................................................. 21

Figure 5 - Left-side menu, Admin and User view .................................................................. 23

Figure 6 - NS Descriptors page ............................................................................................. 24

Figure 7 - NSD graph for UC3 vCDN ...................................................................................... 25

Figure 8 – VNF Packages page .............................................................................................. 25

Figure 9 – VNFD textual visualization ................................................................................... 26

Figure 10 - VNFD graph ........................................................................................................ 26

Figure 11 - Modal for updating VNF Package operational state ............................................ 26

Figure 12 - Projects page ...................................................................................................... 27

Figure 13 - Modal for adding a new project.......................................................................... 28

Figure 14 – Modal for adding a selected user to an available project ................................... 28

Figure 15 - Plugins page ....................................................................................................... 29

Figure 16 - Modals for enabling/disabling/deleting a selected MANO plugin ....................... 29

Figure 17 – High-level Catalogue user configuration ............................................................ 31

Figure 18 – KeyCloak client configuration for the Catalogue ................................................ 32

Figure 19 – User configuration on the AAA portal ................................................................ 32

Figure 20 – KeyCloak user configuration .............................................................................. 33

Figure 21 – OIDC configuration in the OSM's NBI and LIGHT-UI containers .......................... 33

Figure 22 – Authorization Code flow (credits wso2.com) ..................................................... 34

Figure 23 – Resource Owner Password Grant flow (credits wso2.com) ................................ 35

Figure 24 – JWT access token example................................................................................. 36

Figure 25 – KeyCloak login call and tokens returned ............................................................ 37

Figure 26 – KeyCloak refresh token call and tokens returned ............................................... 37

Figure 27 – Authentication Drivers on AAA portal ................................................................ 39

Figure 28 – Grafana reports for NS/VNF sessions ................................................................. 40

Figure 29 – Grafana reports for NS/VNS resource usage ...................................................... 41



Page 6 / 95

Figure 30 – Cost advisor sheet with "what-if" option ........................................................... 41

Figure 31 – Cost advisor "whatif" cost diagram per VM........................................................ 41

Figure 32 - Resource/Cost vs QoE and CNO .......................................................................... 43

Figure 33 - simplified billing data model for UC2 .................................................................. 47

Figure 34 - UC2 Quality Profile ............................................................................................. 47

Figure 35 - simplified resource cost model ........................................................................... 48

Figure 36 - NS sessions monitoring reports .......................................................................... 48

Figure 37 – Interactions among the components included in the events and metrics collection for accounting ................................................................................................. 49

Figure 38 – The API of accounting agent as it appears in the Swagger framework ................ 51

Figure 39 - Image Import API payload example, web-download case ................................... 55

Figure 40 - vLoadBalancer workflow in UC3 ......................................................................... 61

Figure 41 – vCompression general architecture ................................................................... 71

Figure 42 – Speech-to-text engine design ............................................................................ 76

Figure 43 – Nevion Virtuoso software-defined media node ................................................. 80

Figure 44 – Image/Face Recognition Engine: Design approach ............................................. 81

List of Tables

Table 1 - Catalogue's main features per release ................................................................... 20

Table 2 - 5G Apps and Services Catalogue external libraries ................................................. 22

Table 3 - NSD Management operations ................................................................................ 24

Table 4 – VNF Package Management operations ................................................................. 25

Table 5 – PNFD Management operations ............................................................................. 27

Table 6 – Users Management operations ............................................................................. 28

Table 7 - MANO Plugins Management operations ................................................................ 28

Table 8 – hard/soft resource allocation model and QoE ....................................................... 45

Table 9 - Catalogue-to-Catalogue interface .......................................................................... 53

Table 10 - MANO Plugins management interface ................................................................. 53

Table 11 - Catalogue-to-Catalogue management interface .................................................. 54

Table 12 - OS Glance images APIs for uploading ................................................................... 56

Table 13 – Generic Network Apps technical requirements ................................................... 57



Page 7 / 95

Table 14 - vLoadBalancer API ............................................................................................... 61

Table 15 – Basic video features ............................................................................................ 63

Table 16 – Most important distortion parameters (source AGH University VQ indicators) ... 64

Table 17 – Media-specific apps technical requirements ....................................................... 65

Table 18 – vCache REST APIs ................................................................................................ 70

Table 19 – vCompression API ............................................................................................... 72

Table 20 – Speech-to-text API .............................................................................................. 77

Table 21 – Image/Face recognition relevant configuration parameters ................................ 82

Table 22 -- Image/Face recognition API ................................................................................ 85

Table 23 – Image/Face Recognition custom configuration as body in POST-requests ........... 85



Page 8 / 95

Definitions and acronyms

5G-MEDIA 5G Virtual Network Functions for the Media Industry

5G-PPP 5G Infrastructure Public Private Partnership

AAA Authentication, Authorization and Accounting

ACC Accounting

API Application Programming Interface

APP Application software

ATS Apache Traffic Server

AWS Amazon Web Services

BIND Berkely Internet Name Domain

BSS Business Support System

C2C Catalogue-to-Catalogue

CDN Content Delivery Network

CNO Cognitive Network Optimization

CPU Central Processing Unit

CRUD Create, Read, Update and Delete

CSAR Cloud Service Archive

CSV Character-Separated Values

DevOps Development and Operations

DNS Domain Name System

DPI Deep Packet Inspection

ETSI European Telecommunications Standards Institute

FaaS Function as a Service

FPS Frames per Second

FQDN Fully Qualified Domain Name

GoP Group of Pictures

GPU Graphical Processing Unit

GUI Graphical User Interface

H2020 Horizon 2020

HAProxy High Availability Proxy

HTML HyperText Markup Language



Page 9 / 95

HTTP HyperText Transfer Protocol

IDS Intrusion Detection System

ISG Industry Specification Group

JAR Java Archive

JS JavaScript

JSON JavaScript Object Notation

JWT JSON Web Token

M2M Nachine-to-Machine

MAPE Monitor, Analysis, Policy, Execution

MANO Management and Organization

MEC Multi-access Edge Computing

ML Machine Learning

MOS Mean Opinion Score

NB Northbound

NBI NB Interface

NFV Network Function Virtualisation

NFVI Network Function Virtualization Infrastructure

NFVO Network Function Virtualization Orchestrator

NS Network Service

NSD Network Service Descriptor

OIDC Open ID Connect

OS OpenStack

OSM Open-source MANO

OSS Operation Support System

PNF Physical Network Function

PNFD PNF Descriptor

PoP Point of Presence

QoE Quality of Experience

QoS Quality of Service

RAM Random Access Memory

REST REpresentational State Transfer

RTMP Real-Time Messaging Protocol



Page 10 / 95

RTP Real-Time Transport Protocol

RTSP Real-Time Streaming Protocol

RTT Round-Trip Times

S2T Speech to Text

SB Southbound

SBI SB Interface

SDK Service Development Kit

SDN Software-Defined Networking

SDNC SDN Controller

SELFNET Framework for Self-Organized Network Management in Virtualized and Software Defined Networks

SI Spatial Index

SLA Service Level Agreements

SotA State of the Art

SVP Service Virtualisation Platform

TCP Transmission Control Protocol

TI Temporal Index

TOSCA Topology and Orchestration Specification for Cloud Applications

UDP User Datagram Protocol

UI User Interface

VCA VNF Configuration and Abstraction

VDU Virtual Deployment Unit

VIM Virtualized Infrastructure Manager

VL Virtual Link

VM Virtual Machine

VNF Virtual Network Function

VNFD Virtual Network Function Descriptor

VNFFG VNF Forwarding Graph

VNFM VNF Manager

WAN Wide Area Network

WIM WAN Infrastructure Manager



Page 11 / 95

Executive summary

The programmable edge-to-cloud fabric for dynamic hosting of 5G Virtual Network Functions for the Media Industry (5G-MEDIA1) project proposes a solution for the problem of how media applications and the underlying 5G networks should be coupled and interwork, in order to ensure the applications allocate the resources they need to deliver high quality of experience and so that the network is not overwhelmed by media traffic.

The 5G-MEDIA project will extend the ongoing 5G-PPP work on NFV and SDN key technologies for offering an advanced managed environment for network services and media-related applications that links their online lifecycle management with user experience and decisions in resources and infrastructures usage optimisation. In order to design and create the media services over the platform, developers and users could either use existing applications or design, create and upload new ones. A key feature of the 5G-MEDIA architecture is the catalogue where the descriptors of available applications and NSs are stored. This catalogue is present in the SDK as a private catalogue, allowing developers to design and validate applications, and in the core of the SVP as a public catalogue, storing all available applications and NSs descriptors for all platform users.

This document provides the design of the 5G-MEDIA public catalogue portal and the updates with respect to D4.1, as well as the details of the set of network applications development.

The first chapter introduces this deliverable, its purpose and its relationship with the rest of the deliverables of the project.

The second chapter presents the overall architecture of the 5G-MEDIA platform, introducing the main components.

The third chapter provides the specifications of the information models used by the catalogue.

The fourth chapter depicts the final release of the public catalogue and the specifications of the catalogue portal.

The fifth chapter is related to the security framework of the catalogue.

The sixth chapter contains the specifications of the interfaces used by the catalogue.

Finally, the seventh chapter defines the development status of an initial set of 5G-MEDIA network applications.

1 http://www.5gmedia.eu/



Page 12 / 95

1. Introduction

The goal of this deliverable is to provide the final release of the 5G-MEDIA Applications and Services Catalogue, its interfaces and the final set of network applications developments and the design and manual of the public catalogue portal. The public Catalogue is a key part of the SVP depicted in D3.4 [1]. It allows to store available applications and network services.

The main innovation carried out is the proposition of a generic catalogue, compatible with multiple 5G solutions, trying to leverage the progress made by the H20202 5G-PPP3 Phase 1 Project SELFNET4. This SELFNET core, together with the designs presented in this deliverable, allows the platform to work with different kind of VIMs and MANOs.

This document presents also the mechanisms of Authentication, Authorization and Accounting (AAA) that are used as security framework for each kind of user, as well as the northbound (NB) and southbound (SB) interfaces of the catalogue.

Finally, the document presents the current status of the set of generic VNFs and media-specific VNFs and PNFs; providing a detailed description of its features and behaviour.

1.1. Scope of the Deliverable

This deliverable is focused on the three tasks of WP4 “5G-MEDIA Open Repository of Network Apps”: T4.1 “Catalogue Setup and Operation”, T4.2 “Generic Network Apps and Functions” and T4.3 “Media Network Apps and Tools”. T4.1 is in charge of the design of the catalogue and its interfaces while tasks T4.2 and T4.3 are in charge of the set of applications provided by the project. D4.2 “5G-MEDIA Catalogue Portal and Network Apps” contains the implementation of the catalogue, together with a portal design, which acts as a GUI, and a set of applications. Both the implementation of the catalogue and the applications are still undergoing refinements. Changes, induced by the testing of the Use Cases will be reported in the Deliverables D6.2 “5G MEDIA Immersive Media Pilot” [2], D6.3 “5G MEDIA Mobile Contribution, Remote and Smart Production Pilot” [3] and D6.4 “5G MEDIA High Demanding UHD over Open CDNs Pilot” [4].

2 https://ec.europa.eu/programmes/horizon2020/en 3 https://5g-ppp.eu/ 4 https://5g-ppp.eu/selfnet/



Page 13 / 95

2. Overall 5G-MEDIA Architecture

To keep the document self-contained, we present in this Section the current 5G-MEDIA architecture in the time of writing. The final version of the 5G-MEDIA architecture together with the final refinements of the technical components of the solution will be reported in the deliverable D2.4.

The 5G-MEDIA approach delivers an integrated programmable service platform for the development, design and operation of media applications in 5G networks. Figure 1 shows the high-level architecture of the 5G-MEDIA operations and configuration platform. The main building blocks comprising the 5G-MEDIA architecture are:

� An Application/SDK that enables access to media applications development tools, such as editor, validator, emulator, private catalogue, etc.

� An SVP that hosts the components related to the ETSI MANO framework5, the Applications and Services Catalogue, the Media Service MAPE and the corresponding Virtualized Infrastructure Manager (VIM) and WAN Infrastructure Manager (WIM) plugins enabling the integration to different NFVI platforms.

� Different NFVIs comprising the “Physical Layer” that provide computing resources by different operators and supporting different cloud technologies to host generic and media-specific VNFs depicted at the “Virtualized Resource Layer”.

The 5G-MEDIA SDK provides a set of open-source tools to support the rapid development of media applications using a DevOps approach. In particular, these tools allow the definition of media service forwarding graphs (also using already existing VNFs, stored in the 5G-MEDIA private VNFD/NSD Catalogue), to proof and package the various functions, as well as to emulate behaviours of the virtualized infrastructure, to accelerate application development and provide a testing environment to be utilized prior to service deployment in the runtime SVP. In addition, the 5G-MEDIA SDK tools enable the use of the innovative concept of the Function-as-a-Service (FaaS). Particularly, 5G-MEDIA pioneers in applying FaaS to VNF management, complementing traditional VM based VNFs with FaaS based media-specific functions, aiming at dramatically reducing development cycles and slashing operational costs to 5G-MEDIA users. In this perspective, developers do not have to care about the low-level details related to the virtual computing and storage infrastructure (e.g. virtual server profiling in terms of CPU, RAM, etc.), thus drastically contributing to reduce the service creation time cycle and maintenance effort. In this line, the service developers will be able to create the so-called FaaS VNFs, i.e., VNFs that are instantiated upon the detection of specific events or VNFs whose events trigger specific actions on other components. The combination of the FaaS approach with the VNF packaging and the enablement of inserting FaaS VNFs in a typical VNF Forwarding Graph (VNFFG) is one of the main innovation aspects of the proposed 5G-MEDIA approach.

5 http://www.etsi.org/technologies-clusters/technologies/nfv/open-source-mano



Page 14 / 95

The 5G-MEDIA SDK interacts with the 5G-MEDIA SVP, which hosts the components related to the ETSI MANO framework (NFV Orchestrator, VNF Manager(s), Infrastructure Manager(s), the public VNF/NS Catalogue and Repositories etc.), as well as unique components that are used to support 5G-MEDIA internal services and deliver its applications to the external stakeholders (e.g. the Media Service MAPE – Monitor, Analysis, Policy, Execution).

Figure 1 – Architecture of the 5G-MEDIA platform (Source D2.3 [2])



Page 15 / 95

A major innovation of the project is the development of the Media Service MAPE component, which is composed of the Monitoring system, the Cognitive Network Optimization (CNO) engine and the Policy Manager. The development of MAPE will be based, where applicable, to the design, utilization of tools and architectural diagram being part of the outcomes of CogNet 5G-PPP phase 1 project6, while achieving integration to the OSM components, including Monitoring plugin and Service Orchestrator. The monitoring services aims to monitor the performance/behaviour of the instantiated Network Services (NSs), the integrated NFVIs, the interconnecting networks and the applications themselves. The measured performance metrics are directly used by the CNO engine which comprises mechanisms that take advantage of Machine Learning (ML) techniques and optimization policies to trigger the dynamic instantiation and update of VNF Forwarding Graphs (VNFFGs) or scaling options according to the capabilities provided by the OSM (i.e. Scaling Groups construct in the NS descriptors) over the different NFVIs. Alternatively, after the proper execution of the policy classification procedure, 5G-MEDIA SVP will be also able to take advantage of the benefits provided by the VCA Engine (and in particular the Juju7 adapter provided by the OSM) to execute commands on the VNFs themselves, according to the specific Use Case scenario needs. As it becomes clear, the CNO is able to respond on dynamic changes of the environment (e.g., location change of end users, varying QoS demands) and in cooperation with the Policy Manager to make suggestions to the MANO NFVO and VNFMs how to manage/update VNFFGs, perform scaling options, execute commands via Juju charms or even start new components enforced by the FaaS VNFs in order to meet expected QoS/SLA requirements in the most effective way. Last but not least, the QoS/QoE monitoring modules are able to provide both NSs individual and aggregated monitoring views and graphical user interfaces for metrics specified by the developer per NS/VNF, which are part of the generic monitoring system of the SVP.

In the context of 5G-MEDIA approach, as depicted in Figure 1 at the “Virtualized Resource Layer”, each media service comprises a chain of media-specific and network-specific atomic services, all interconnected to deliver an expected output to the end user (media consumer). The resulting graph (i.e., a graph where nodes refer to computing tasks and edges refer to network communication links) is referred as Media Service Forwarding Graph. During the design, development and testing phases, the 5G-MEDIA platform provides appropriate programming tools to abstract the details of the underlying 5G infrastructure and allow developers to focus on the functionality of the services. Once the media service is deployed in the virtualized infrastructure, the 5G-MEDIA platform provides mechanisms to flexibly adapt service operations to dynamic conditions and react upon events (e.g. to transparently accommodate auto-scaling of resources, VNF re-placement, etc.).

Finally, in terms of the supporting physical infrastructure (Physical Layer), the proposed architecture considers that several cloud-based NFVIs will be connected to the SVP via the

6 http://www.cognet.5g-ppp.eu/ 7 https://jaas.ai/



Page 16 / 95

appropriate VIM and WIM components, enabling the use of computing and networking resources in the respective NFVI.



Page 17 / 95

3. Information model specifications

The specification of the descriptors for Network Services, Virtual Network Functions and Multi-access Edge Computing (MEC) applications in 5G-MEDIA has the twofold objective of aligning with the latest standards available in ETSI NFV and ETSI MEC ISGs, while integrating novel extensions and parameters to capture additional requirements of multimedia applications. This approach maximizes the compatibility and the interoperability of 5G-MEDIA architectural components with external NFV products, thus facilitating its acceptance and adoption in the NFV community. Where needed, extensions to the standard information and data models are proposed following the best practices commonly adopted in the languages and protocols used at the NFV MANO and MEC interfaces (e.g. TOSCA CSAR packages or HTTP messages for REST APIs) for augmenting information elements and primitives. The descriptors adopted in 5G-MEDIA for the definition of NSs and MEC applications as well as VNFs were reported in D4.1 [6].

4. 5G Apps and Services Catalogue

As reported in D4.1, the motivations behind the implementation of the 5G Apps and Services Catalogue reside in the intent of covering several limitations that currently are affecting State of the Art (SotA) NFV catalogues. The catalogue implementation unifies and standardizes data-models for NSDs, PNFDs and VNFDs (ETSI GS NFV SOL001 v2.5.1 [7]) as well as supports a standardized VNF Package format (ETSI GS NFV SOL004 v2.5.1 [8]). By doing so, the Catalogue implementation aims to hide the high fragmentation in a way that descriptors and packages are represented among the several existing catalogues in the MANO layer. At the same time, it offers a structured support for application specific configurations and monitoring parameters, while preserving standards compliance for NSD, PNFD and VNFD data models.

Moreover, the 5G Apps and Services Catalogue implements at its Northbound Interface (NBI) the ETSI GS NFV SOL005 v2.4.1 [9] specification, exposing common procedures for onboarding, query, update and delete descriptors and packages among different MANO instances. Indeed, the dedicated plugins are in charge of performing the proper translations towards the target MANO data model and handling the received requests by interfacing with the underlying MANO NBI.

In the following section, we present the final functional and software designs of the 5G Apps and Services Catalogue, paying particular attention to modifications, updates and enhancements introduced since D4.1 was released. Moreover, in section 4.2, detailed guidelines are given for the proper operation of NSDs, PNFDs and VNF Packages thorough the 5G Apps and Services Catalogue portal.

4.1. Final release

With respect to D4.1, the functional design of the 5G Apps and Services Catalogue remains unchanged except for the integration of a new module in order to support the inter-catalogues communication. Indeed, the Catalogue can be configured for acting as a private catalogue deployed in the DevOps environment. In this specific case new functionalities are activated in order to allow the SDK user/developer to retrieve descriptors and packages from the public Catalogue instance, residing in the production environment, according to granted permissions. The loading of existing descriptors from the public Catalogue to the private one brings, for



Page 18 / 95

instance, the possibility of reusing existing building blocks in composing new service that, once finalized, can be pushed to the public Catalogue as well as new developed applications and packages. Moreover, the new catalogue-to-catalogue module potentially enables the hierarchical communication between a parent Catalogue belonging to an inter-working layer and several child Catalogues from different administrative domains.

Figure 2 reports the updated high-level functional design of the 5G Apps and Services Catalogue, highlighting the 5G-MEDIA specific Use Case where a private instance which is deployed in the DevOps environment interact with the public Catalogue in the production domain.



Page 19 / 95

Figure 2 – Private and Public catalogues functional design

On the software side the new module is implemented as a new plugin type plus a set of NB REST APIs for triggering the push of NSDs, PNFDs and VNF Packages from the private Catalogue to the public one. The updated high-level software design is reported in Figure 3.



Page 20 / 95

Figure 3 – Updated high-level software design

The Catalogue APIs Handler now comprises the NSD and VNF Package management interfaces based on SOL005, the catalogue-to-catalogue API for pushing descriptors and packages from the private instance to the public one and the Admin API, which allows to dynamically configuring and instantiating new MANO plugin instances. A new plugin type, Catalogue-to-Catalogue (C2C), has been added and the corresponding implementation integrates a “C2C Client Lib” to communicate with the public Catalogue and to perform load and push operations of descriptors and packages.

Table 1 reports the main features per Catalogue’s release. Table 1 - Catalogue's main features per release

Catalogue Release Main Features

R1 • NBI – NSD Management (SOL005) • Core IFA-013 [10] API support (partial notifications) • OSM R3 Plugin – NSD support • NS TOSCA Descriptors (SOL001) • TOSCA Parser & Validator for NSD (SOL001) • Initial packages and descriptor versioning • “PluginsManager” for runtime plugins configuration • Dummy consumer on notifications

R2 • NBI – NSD Management refined (SOL005) • NBI – VNF Package Management (SOL005) • NS and VNF TOSCA Descriptors (SOL001) • TOSCA Parser & Validator for VNFD (SOL001) • CSAR option #1 (SOL004) • OSM R3 Plugin – VNF Package support • OSM R4 Plugin – NSD + VNF Package support • Initial integration with 5G-MEDIA SDK



Page 21 / 95

Catalogue Release Main Features

R3 • PNF TOSCA Descriptors (SOL001) • OSM R5 Plugin – NSD + VNF Package support • OSM R6 Plugin – NSD + VNF Package support • Catalogue-to-Catalogue Plugin • Integration with 5G-MEDIA SDK • Extensions to the 5G Catalogue Portal for:

o Export descriptors and packages to the public Catalogue o Dynamically instantiate new MANO Plugins o Enable/Disable/Delete MANO Plugins

• Integration with 5G-MEDIA AAA, including: o Project-based views o Policies for Service Provider

• OpenStack8 VIM Plugin (Ocata -> Queens)

4.2. Catalogue portal

In this section, we present the 5G Apps and Services Catalogue portal, giving guidelines for properly operating NSDs, PNFDs and VNF Packages through its Graphical User Interface (GUI) as showed in Figure 4.

Figure 4 - 5G Apps and Services Catalogue Portal

8 https://www.openstack.org/



Page 22 / 95

4.2.1. Design and interfaces

The 5G Apps and Services Catalogue portal is developed as a JavaScript web application where the pages’ layout and style are implemented by integrating the Gentelella9 template, which is based on the Bootstrap toolkit10. The portal web application runs on top of the Apache211 web server that is configured for enabling the usage of HTML templates to be included in the application’s web pages. In particular, different HTML templates have been implemented for realizing the common building blocks in the web pages’ structure, i.e. the top bar, the left-side menu and the footer.

The communication between the portal and the 5G Apps and Services Catalogue NBI, i.e. the SOL005 NBI of the spring-boot application detailed in D4.1, is realized by implementing a REST client through the jQuery Ajax library12, while the users’ authentication is handled at the 5G-MEDIA AAA as specified in Section 5. For communicating with the KeyCloak13 identity server, the portal makes use of the keycloak-js-bower14 library, which acts as an adapter and allows to retrieve Json Web Tokens15 (JWT) for authorizing all the requests towards the Catalogue application. Moreover, further libraries have been integrated to implement portal-specific functionalities, such as the graphical representation of descriptors (NSD, PNFD and VNFD), implemented through cytoscape.js16, and the parsing and dumping of TOSCA descriptors that is realized through js-yaml17.

Table 2 reports the list of external libraries used for the portal implementation. Table 2 - 5G Apps and Services Catalogue external libraries

Library Description Source Licence

Gentelella HTML/Bootstrap template

https://github.com/ColorlibHQ/gentelella MIT License

jQuery JavaScript library https://jquery.com/download/ MIT Licence

9 https://github.com/ColorlibHQ/gentelella 10 https://getbootstrap.com/ 11 https://httpd.apache.org/ 12 https://api.jquery.com/jquery.ajax/ 13 https://www.keycloak.org/ 14 https://github.com/keycloak/keycloak-js-bower 15 https://jwt.io/ 16 https://js.cytoscape.org/ 17 https://github.com/nodeca/js-yaml



Page 23 / 95

Library Description Source Licence

including Ajax

cytoscape.js JavaScript library for graphs

https://github.com/cytoscape/cytoscape.js MIT License

js-yaml JavaScript YAML parser and dumper

https://github.com/nodeca/js-yaml MIT License

keycloak-js-bower

JavaScript KeyCloak adapter

https://github.com/keycloak/keycloak-js-bower

Apache 2.0 Licence

4.2.2. Left-side menu and available operations

The user can operate the 5G Apps and Services Catalogue application by navigating the left-side menu, which is present in all the portal’s pages. In particular, the left-side menu offers different available areas for operations based on the user’s permission, i.e. specific operations related to plugins’ configurations and projects’ settings are only exposed to the “Admin” user, as showed in Figure 5.

Figure 5 - Left-side menu, Admin and User view

4.2.2.1. Common areas of operability

The areas of operability that are in common to regular and admin users are the ones related to the descriptors and packages management. In particular, the Catalogue portal works with project-



Page 24 / 95

based views: users can potentially belong to several projects, each of them containing different set of descriptors and packages, while a descriptor or a package can belong to just one project. In particular, a descriptor or a package is uniquely identified by its id and version. Once a project is selected through the proper menu in the top bar, the user has the visibility of only the descriptors and packages in such project and is able to onboard new descriptors/packages just to this specific project. In the following subsection, we describe available operations for each page/area.

NS Descriptors

The NS Descriptors page allows the user to show NSDs available for a selected user’s project and perform Create, Read, Update and Delete (CRUD) operations on top of such NSDs. In this page an “Onboard NSD” button is available for onboarding new descriptors and a table is reporting all the available NSDs for the selected project, see Figure 6. Each row in the table is showing high-level information of a specific descriptor and the current onboarding state with respect to the Catalogue (e.g. “LOCAL_ONBOARDED”) and with respect to the underlying NFVO’s catalogues.

Figure 6 - NS Descriptors page

Available operations for each properly onboarded NSD are reported in Table 3. Table 3 - NSD Management operations

Operation Icon Description

GET NSD

Through this operation the user is able to get the NSD and visualize the NSD text in a dedicated modal

VIEW GRAPH

Through this operation the user is able to visualize the NSD in graphical way, where VNFs and Virtual Links (VLs) are represented as node of different types, interconnected between each other, see Figure 7

UPDATE NSD

Through this operation the user is able to ENBLE or DISABLE the NSD, according to SOL005 specification

DELETE NSD

Through this operation the user is able to delete the NSD if DISABLED and NOT_IN_USE, according to SOL005 specification



Page 25 / 95

Figure 7 - NSD graph for UC3 vCDN

VNF Packages

Like in the case of NSDs, the VNF Packages page is dedicated to the visualization and management of VNF Packages in a specific project, allowing the user to perform CRUD operations. Also, in this page the onboarding operation can be actuated through a dedicated button: “Onboard VNF”, see Figure 8. A table is reporting all the available VNF Packages and, for each row, high-level information of a specific descriptor is showed (e.g. onboarding state, operational state, etc.).

Figure 8 – VNF Packages page

Available operations for each properly onboarded VNF Package are reported in Table 4. Table 4 – VNF Package Management operations


GET VNFD

Through this operation the user is able to get the VNFD inside a VNF Package and visualize the VNFD text in a dedicated modal, see Figure 9

VIEW GRAPH

Through this operation the user is able to visualize the VNFD in graphical way, where Virtual Deployment Units (VDUs) and Connection Points (CPs) are represented as node of different types, interconnected between each other, see Figure 10



Page 26 / 95


UPDATE VNF PACKAGE

Through this operation the user is able to ENBLE or DISABLE the VNF Package, according to SOL005 specification, see Figure 11

DELETE VNF PACKAGE

Through this operation the user is able to delete the VNF Package if DISABLED and NOT_IN_USE, according to SOL005 specification

Figure 9 – VNFD textual visualization

Figure 10 - VNFD graph

Figure 11 - Modal for updating VNF Package operational state



Page 27 / 95

MEC APP Packages

MEC APP Packages are currently not supported.

PNF Descriptors

The PNF Descriptors page contains a table that is showing all the PNFDs available in a specific project. Like in the case of NSDs and VNF Packages, users are able to perform CRUD operations on top of such PNFDs. The onboarding operation can be performed through the dedicated “Onboard PNFD” button. Each row in the table is showing high-level information of a specific descriptor such as the current onboarding state (e.g. local onboarding state plus MANOs’ onboarding state).

Available operations for each properly onboarded PNFD are reported in Table 5 – PNFD Management operations


GET PNFD

Through this operation the user is able to get the PNFD and visualize the PNFD text in a dedicated modal

DELETE PNFD

Through this operationreducing the user is able to delete the PNFD if NOT_IN_USE, according to SOL005 specification

SDN APP Packages

SDN App Packages are currently not supported.

4.2.2.2. Admin area

Projects

The Projects pages allow the “Admin” user to visualise which are the currently configured projects and to create new ones by using the 5G-MEDIA AAA APIs. The page contains a table which shows the projects’ ids, descriptions and related users; moreover a button for adding new projects is available at the bottom of the table.

Figure 12 - Projects page



Page 28 / 95

Figure 13 - Modal for adding a new project

Users

Similar to the Projects page, the Users one contains a table showing all the users handled at the 5G-MEDIA AAA identity server. In particular, the table shows the users’ ids, first name, last name and the default project the user is associated to. For each user, operation is available for binding the selected user to a project (see Table 6). At the bottom of the table the “New User” button can be used for creating new users via 5G-MEDIA AAA.

Table 6 – Users Management operations


ADD USER TO PROJECT

Through this operation the Admin is able to add the selected user to one of the already existing projects, see Figure 14

Figure 14 – Modal for adding a selected user to an available project

Plugins

The Plugins page allows the Admin user to show high-level information for each of the currently running MANO Plugins and Catalogue-to-Catalogue plugins (in case the Catalogue is configured as a private instance). In particular, for each MANO plugin, the Admin can visualise the id, the type (e.g. OSMR5, OSMR4 etc.) and the IP address of the instance. Moreover, an operation is available for enabling, disabling and deleting MANO Plugin instances, ad reported in Table 7. Two different buttons are available at the bottom of the respective tables for adding new “MANO” or “C2C” plugins (see Figure 15).

Table 7 - MANO Plugins Management operations


OPERATE MANO

Through this operation, the Admin is able to enable, disable or delete a MANO Plugin instance, see Figure 16



Page 29 / 95


PLUGIN

Figure 15 - Plugins page

Figure 16 - Modals for enabling/disabling/deleting a selected MANO plugin

5. Security Framework (AAA)

5.1. Authentication and Authorization

Compared to the release described in the deliverable D4.1 “5G-MEDIA Catalogue APIs and Network Apps” released in M15, the main achievement produced in this second period of activities about Authentication and Authorization has been the integration of Open ID Connect18 (OIDC) protocol in the MANO framework used in the project (OSM19 r4 and r5, with plans to upgrade to the latest official release before the end of the project) and within the Catalogue.

18 Open ID Connect: https://openid.net/connect/ 19 OSM: https://osm.etsi.org/



Page 30 / 95

The main advantage of the introduction of Open ID Connect protocol is the adoption of a well-known authentication and authorisation protocol that simplifies the management of different MANO framework from the perspective of the 5G-MEDIA Catalogue without the hassle of handling different user repositories and providing a complete abstraction over the security configuration to the Catalogue.

In 5G-MEDIA project, the KeyCloak has been selected as the Identity Server because it is open-source and it has robust support by the community. Of course, any other OIDC compliant Identity Server can be used (such as Google Identity Platform20), so this should grant sustainability and possibly benefit from additional features for a seamless sign-in experience.

Another advantage of centralising the token management is also the ability to revoke an “access” token even before its expiration and of course tracking the actual login activities from the KeyCloak portal. This is done without having the Catalogue need to know and manage different credentials, but just those necessary to access the Identity Server. In fact, each client configured on KeyCloak has its own private credentials that again can be changed and reconfigured over time, improving the whole security management of 5G-MEDIA services.

As a result, the whole security configuration is managed by the AAA portal and involves both authentication and authorisation. The administrator can configure users and permissions on the systems involved using a unique web portal (AAA) that provides a plugin-based architecture to facilitate future extensions.

The minimal set of systems managed by the AAA portal are: multiple OSM instances, the Catalogue, KeyCloak as Open ID Connect Identity Server.

An administrator can login on the AAA portal, manage the creation of new Catalogue users, assign them to specific resources and configure their authorisations. The user profile contains additional information for the Catalogue authorisation, such as the Catalogue “project”, used to enable multitenancy. Such information are used on the Catalogue to allow fine-grained authorisation and grant access, for example, to a private VNF catalogue that is visible only to Catalogue users belonging to the same “project”.

The Figure 17 shows a high-level picture of the configuration done by the administrator to grant access to an example user “mediauser1” over two different OSM instances, one OpenStack and the Catalogue with different local users and permissions.

20 Google Identity Platform: https://developers.google.com/identity/



Page 31 / 95

Figure 17 – High-level Catalogue user configuration

The configuration is stored on the AAA portal and is partially replicated on the involved systems as follows:

A) on the AAA portal, admin-like credentials for KeyCloak are used to allow its configuration using the management API;

B) on KeyCloak, one client is configured for each system involved, with private credentials and a unique identifier that are stored on the related client along with the Identity Provider endpoint URL;

C) on KeyCloak, users and impersonating roles are created and configured whenever any change is detected on the AAA portal, such as the creation of the example user “mediauser1”;

D) on the OSM, private credentials and KeyCloak endpoint URL are stored on the NBI and GUI containers; local users and projects are created along with those stored in the AAA portal to enable both OpenID Connect and plain username/password on the OSM;

E) on OpenStack, local user and projects are created using the management API using admin-like credentials previously stored on the AAA portal; in case OpenStack is configured to support OpenID Connect,

F) on the Catalogue, private credentials and KeyCloak endpoint URL are stored to enable OpenID Connect profiles; users are requested to be stored locally, as the user, the role and the projects he belongs to are communicated as custom tags within the access token and rely on the intrinsic token validation provided by the Open ID Connect protocol.

For some of the point above, further details are provided to give a better idea of the AAA configuration flow.

For point A), KeyCloak starts with pre-configured clients, one for each resource, with credentials, local roles, and the attribute mappers used to map relevant user profile info to attributes in the access token. The example reported in the Figure 18 shows the configuration for the 5G-MEDIA Catalogue, identified by “catalognxw”, with the specific roles (ROLE_SERVICE_DEVELOPER, ROLE_SERVICE_COMPOSER, etc.), the attribute mappers to report in the “access token” both the information about the role and the projects the user has been assigned.



Page 32 / 95

Figure 18 – KeyCloak client configuration for the Catalogue

For point B), the Figure 19 shows an example configuration done on the AAA portal, where the “mediauser1” Catalogue user with ID 8 is configured with a specific role (“ROLE_ADMIN”), then associated with different resources (2 OSM and 1 OpenStack instances).

Figure 19 – User configuration on the AAA portal



Page 33 / 95

For point C), the Figure 20 shows the configuration in KeyCloak for the user that impersonate a local user and role for each client.

Figure 20 – KeyCloak user configuration

For point D), the Figure 21 shows the configuration in the OSM’s NBI and LIGHT-UI containers with the references to the KeyCloak endpoint, the client ID and secret.

Figure 21 – OIDC configuration in the OSM's NBI and LIGHT-UI containers

OpenID Connect protocol comes with different “flows”, that define the interactions required from the Identity Server perspective to verify the identity of end-users and grant the authorisations.



Page 34 / 95

In 5G-Media, two flows have been integrated: Authorization Code Flow and Resource Owner Password Grant, the first to support web-based applications accessed throw browsers (GUI), the latter to support access via REST calls (M2M).

The Figure 22 shows the basic “Authorization Code Flow” used in 5G-MEDIA for GUI apps using the browser.

Figure 22 – Authorization Code flow (credits wso2.com)

The Figure 23 shows the basic “Resource Owner Password Grant Flow” used in 5G-MEDIA for M2M communication.



Page 35 / 95

Figure 23 – Resource Owner Password Grant flow (credits wso2.com)

Both rely on authentication “access” tokens in JWT format21, signed by the Identity Provider in order to be validated by the Client before being processed, that are configured to expire after 60 seconds. An example is reported in the Figure 24, with highlight on the relevant information used by the Catalogue to retrieve the logged in user and the projects he belongs to.

21 JSON JWT format: https://jwt.io/introduction/



Page 36 / 95

Figure 24 – JWT access token example

For GUI based access, web sessions are used to force a new logon on the Identity Server after the “access” token expiration due to inactivity; the same “access token” for GUI access is not visible to users but stored in session to allow access to the backend services and passed over as an HTTP attribute. For M2M based access, special “refresh” tokens are provided to the clients to allow the request of new “access” tokens when the latter are expired. Below are reported the calls to obtain an “access” token and to renew it using a “refresh” token. Of course “refresh” token does expire too, but with longer time (30 minutes); in this case, a new login on KeyCloak is required to start the process over.

The Figure 25 shows the login call to KeyCloak that returns both the “access” and “refresh” tokens in JSON format. The “client_id” value depends on the actual configured resource.



Page 37 / 95

Figure 25 – KeyCloak login call and tokens returned

Similarly, the Figure 26 shows to call to KeyCloak using a “refresh” token that produces the same type of result as above.

Figure 26 – KeyCloak refresh token call and tokens returned

The AAA portal can be easily extended with plugins to support other authentication methods than OpenID Connect in order to manage infrastructures that do not integrate such protocol and are provided “as-is” to 5G-MEDIA. An example might be OpenStack, easily configurable to support OpenID Connect through specific configuration over its internal identity server (see “setup OpenID



Page 38 / 95

Connect”22 on KeyStone) but that could be provided without such configuration with “bearer” authentication tokens.

The setup of plugins in AAA requires the creation of a library as a JAR file to be added to the classpath that contains an implementation of the interface eu.fivegmedia.aaa.service.driver.IDriverUser with the methods reported below:

• public void setApplicationProperties(..); //receive the environment variables • public String authenticateAndGetToken(..); //authentication and get the resource token • public void createUser(..); //create a new user • public void deleteUser(..); //delete a user

Please refer to the “fivegmedia3a” project on the official source repository (currently https://production.eng.it/gitlab/5G-MEDIA/fivegmedia3a) for the actual parameters and implementation (such as DriverOSMr4, DriverOSMr5, DriverOSMr5Keycloak).

Once the JAR library is available, it can be configured from the AAA portal as shown in the Figure 27 below. If the “Auth Driver” does not have the fully qualified class name, it is assumed it starts with “eu.fivegmedia.aaa.service.driver.”.

22 OpenID Connect configuration on KeyStone for OpenStack, https://docs.openstack.org/keystone/pike/advanced-topics/federation/openidc.html



Page 39 / 95

Figure 27 – Authentication Drivers on AAA portal

5.2. Accounting

Accounting services

Since the release of the deliverable D4.1, the Accounting services have been improved to advise the developers about the FaaS VS non-FaaS VNF usage according to their cost in terms of resource usage through a component named “cost-advisor”.

To demonstrate the usage of the cost advisor in an example scenario, we assume that the cloud resource costs will eventually level down among different cloud providers, so the cost advisor takes as reference the official IBM resources costs for plain VMs23 and for FaaS24 and computes the costs based on both FaaS and non-FaaS option for the same VNF.

In the end the cost advisor recommends the end-user, based on its resource history data, whether to use one deployment over the other based on the amount of time the VNF is running, the CPU utilization it consumed during its run, the amount of memory it was using, and the other metrics provided from the monitoring and stored by the accounting services.

23 https://www.ibm.com/cloud/pricing 24 https://cloud.ibm.com/openwhisk/learn/pricing



Page 40 / 95

Such data is visible through the AAA portal that points to dedicated Grafana reports that show the NS/VNS sessions (see Figure 28), the resource usage per period of interest (see Figure 29) and the cost analysis sheet with the costs reported, for each VNF session, for the “what-if” option to have it FaaS or non-FaaS (see Figure 30).

The API provided to the cost advisor component are reported below, with time format either unixtime millis or parametric (*time methods), with different return type (respectively String CSV, plain CSV, zipped CSV).

• http://IP:PORT/export_string/TOKEN/USER

• http://IP:PORT/export_string_time/TOKEN/USER

• http://IP:PORT/export_string_time_filter/TOKEN/USER/TIME_FROM/TIME_TO

• http://IP:PORT/export_unzipped/TOKEN/USER

• http://IP:PORT/export_unzipped_time/TOKEN/USER

• http://IP:PORT/export_unzipped_time_filter/TOKEN/USER/TIME_FROM/TIME_TO

• http://IP:PORT/export/TOKEN/USER

• http://IP:PORT/export_time/TOKEN/USER

• http://IP:PORT/export_time_filter/TOKEN/USER/TIME_FROM/TIME_TO

Figure 28 – Grafana reports for NS/VNF sessions



Page 41 / 95

Figure 29 – Grafana reports for NS/VNS resource usage

Figure 30 – Cost advisor sheet with "what-if" option

As a result, the cost advisor produces a report that highlights the best choice for a given NS/VNF (see Figure 31).

Figure 31 – Cost advisor "whatif" cost diagram per VM



Page 42 / 95

Billing services

Basic billing services have been introduced to support the CNO optimisation and measure the benefits in terms of resource cost, that helps to define a more effective charging model for the 5G-MEDIA verticals.

Today, with the increasing competition among different providers, end users are in the privileged position to be able to choose what they perceive to be the “best” among all the services they are offered in terms of what they actually experience.

Their choice is based not only on the objective properties of the service, such as the maximum bandwidth, the video resolution and so on, but also on subjective metrics that are strictly related to the service they consume such as a video that plays “smoothly”, without any interruption, and no loss of quality of any kind. This is the so called Quality of Experience (QoE).

From the service provider perspective, ensuring a good QoE means that they not only have to monitor the resource allocation and consumption, but also have an estimation of the QoE they are going to provide for each of their users.

This has an impact on all the phases that data has to pass through, for example with video streaming, where the QoE can be affected on each of such phases.

In the context of 5G-MEDIA, with a distributed cloud to edge environment, such phases translate to a set of VNFs dynamically deployed along the path to the final user, with the CNO working to optimise resources allocation and provide the best possible QoE, and also to the external link between the edge and the end user.

The QoE estimation is the focus to have any sort of optimisation at the service platform virtualisation level. In literature [11], the effort to define QoE ended up with a model where part [12] of the metrics can still be considered objective although heavily dependant on the position on the network where they are measured. Such objective metrics are basically related to 1) network, 2) content, 3) device conditions, and are addressed in 5G-MEDIA by network probe, application level monitoring and media-specific probes deployed on the final users’ devices.

In 5G-MEDIA, similarly to the “what-if” analysis for FaaS, the billing services take into account the different resource costs and CNO optimisations, using the QoE as a measure of their effectiveness. The high level picture that introduces this concept is shown in the Figure 32.



Page 43 / 95

Figure 32 - Resource/Cost vs QoE and CNO

The two main goals of CNO are improve the QoE metric and reduce resource consumption or, from another perspective, to reduce the resource consumption while keeping the same QoE, with any variation between these two extremes.

To mitigate the dependency on the endpoint conditions that impact the QoE measurement, the assumption taken into the project is to use probes on the edge to measure the expected QoE that should be received on the final endpoint, in case there’s no loses on the external link, map this value on the actual resource usage and have an objective measure of the resources needed to achieve it. At the same time, probes on the endpoint help to adjust the resources allocation and detect, for example, congestions in the last mile that could vanish any additional effort and push the CNO to prioritise other services.

So, based on the expected QoE metric, we explore some interesting goals that fall into the generic category of resource monitoring, the consumption optimisation and the charging, such as:

1. measure the additional resource costs that one service provider might want to bear in order to provide a better service and gather more customers, using a better QoE as target, and measure the costs/benefits ratio;

2. dimension the penalty that one service provider could propose as part of its offer when the QoE goes below a minimal threshold, and that is proportional to additional resources necessary to bring the QoE back to the acceptable value; the penalty value could also take into consideration the actual numbers of users active and so on;

3. measure the cost saving in terms of resource costs when using the CNO and determine its value as a paid option.

A simplified resource cost model in 5G-MEDIA is used to provide some numbers along with the resources consumed in order to give a concrete idea of the results. Such model comprehends the



Page 44 / 95

CPU cycles, memory size, disk space, GPU, the inbound/outbound traffic, with data model and prices aligned with the major cloud players offers such as IBM (“multitenant”25 and “FaaS”26) and Amazon Web Services (AWS) (see compute27 and network )28; the traffic considered is only the one among Points-of-Presence (PoPs) not belonging to the same cloud provider, as in AWS. Such model includes also the regions to support geographical position as an additional input to the CNO optimisations to evaluate the trade-offs between cost and closeness to the venue.

With the above assumptions, we get an approximate relation among 1) some metrics measured on the cloud, 2) the expected QoE values and 3) the resources used, that in the end allows to measure the CNO optimisations in terms of resource costs. And, of course, the billing reports demonstrate the optimal and fair resource allocation of the CNO across multiple users according to their priority.

In the first sample scenario without CNO, given a certain load with different priorities (say, some “premium” and some “standard” users), reports show that the actual resource (bandwidth) consumption. To try to guarantee some QoE, the resources are most likely hard reserved, probably wasted and have a cost. We can have an approximation of the expected QoE and the costs measuring consumption up to the edge.

With the same load, we activate the CNO and see that the bandwidth is optimally used and expected QoE raises. Same cost as without CNO, but with better expected QoE.

With CNO active, we can also reduce the resource consumption to get the same QoE as without CNO: lower cost compared to without CNO, but with the same QoE. As a consequence, with this approximate relation between expected QoE and resource costs, it is possible to get an estimation for the above points 1), 2) and 3). We now explore two resource allocation schemas used by the CNO, called “soft” and “hard”. “soft” resource allocation

The CNO tries to allocate resources to each service/user according to an expected QoE, but without any reservation involving underlying system and network devices. This means the CNO is going to optimize the resources available without the possibility to actively request any extension.

CNO is aware of network condition, active services/sessions and their requirements/constraints, therefore it should be able to split the available resources across all of them with objectives of

25 https://cloud.ibm.com/gen1/infrastructure/provision/vs 26 https://cloud.ibm.com/functions/learn/pricing 27 https://d1.awsstatic.com/whitepapers/aws_pricing_overview.pdf 28 https://aws.amazon.com/ec2/pricing/on-demand/



Page 45 / 95

providing the minimum quality of experience (QoE) of each user/service while maximizing the total number of users sharing the same resources.

CNO may allocate more resources than the minimum QoE of a service/user is required when there are spare resources. An upper limit to this allocation may be followed by CNO according to a policy devised by the service provider or requested by users. With reports available about the additional resource costs, the service provider is facilitated to define such policies.

CNO tries to allocate bandwidth within the specific range of this profile according to underlying network conditions. If CNO finds itself in a difficult position to maintain the minimum QoE of its users due to lack of network resources, to reduce resources of each user, according to their priorities, in a way that the QoE of users are not exceedingly damaged and the stream continuity is preserved (without any artefact). For example, it could simply privilege premium over standard users or do the opposite depending on the total income generated by each user category, and so on. The definition of such a policy is facilitated by historical reports.

CNO may also consider a particular policy for distributing spare network bandwidth across its users based on their priorities and measure the cost for such an effort. By spare, we mean a condition in which CNO have already satisfied the minimum QoE of all users/services, and yet there are available resources to be distributed across them. For example, CNO could simply allocate more resources to premium users. With reports available about the actual users and profiles, the service provides is facilitated to take the best decision.

“hard” resource allocation

This is very similar to the “soft” scheme”, but here the CNO reserves resources by the help of system/network devices. This approach has a greater impact on costs, is appealing for services with strict QoE requirements and it is less likely that the service provider fails to deliver the minimum QoE of a service. But yet penalty policy can still be considered in case the network fails to do so.

Another variant of this scheme could be thought of as a model in which there is a resource reservation for the maximum QoE of a service/user. In this case, we would not need CNO, and thus we do not consider such scenarios.

Both resource allocation models are summarized in Table 8. Table 8 – hard/soft resource allocation model and QoE

Minimum required QoE Maximum required QoE

“soft” resource allocation

not guaranteed

(best effort to satisfy min QoE)

not guaranteed

(when spare resources available)

“hard” resource allocation

guaranteed

not guaranteed



Page 46 / 95

Based on the actual resource usage and QoE provided, it should be then easier to define the billing scheme to adopt; as an example, here are reported two very different ones, variable” and “fixed”.

In “variable” billing, users will pay for a service according to the minimum QoE of that service and if the service provider did manage to provide more QoE than the minimum (up to a certain limit that can be defined by the service provider or user) then users will be charged accordingly. On the other hand, if the service provider fails to satisfy the minimum QoE of service then affected users should be refunded according to refund policy. In this way providing higher QoE to users or accommodating a greater number of users results in higher revenue and the CNO will help to achieve this goal.

With “fixed” billing, one can assume users will pay a certain price for each service depending on the requested quality. This way billing might be completely decoupled from the resource consumption and CNO splits available resources across users with objective of meeting their minimum requirements and providing a higher QoE (more than their minimum) whenever possible and with a cost/ratio to be evaluated. Yet, resource consumption reports can help to shape how much to charge users.

To get a better sense of this scheme, we explored the CNO behavior for UC2, where the remote production services are shaped within different production profiles that represents the different expected entropy (also known as Spatial Index (SI) and Temporal Index (TI), further explained in section 7.1.1.5) of the video content streamed (e.g. sports vs interviews), with different metrics (bitrate and compression level) that are related to the allocated resources (bandwidth). These production profiles model is preliminar and will be evaluated, validated and, if necessary, adjusted on D6.3.

Without CNO available, resources can’t be fully used and in turn, we do not maximize the QoE of existing users neither we can accommodate more users than it could. This condition typically occurs when we do a hard reservation to deliver the maximum QoE of a session.

With CNO, we expect to provide higher compression level (bitrate/QoE) to each user according to its profile, if there is spare capacity, and ensure continuity of sessions by actively adjusting the compression level (mean bitrate) of sessions in order to prevent packet losses.

The simplified data model used to support billing in the UC2 is shown in the Figure 33. Along with the AccNsSession class already provided by the accounting, the model has been now updated to include 1) the quality profiles (QualityProfile), 2) the association with the NS instance (AccNsSessionQualityProfile), 3) the video metrics (AccNsSessionMetrics), 4) the network resources to measure inbound/outbound traffic (AccNsSessionNetwork), 5) the simplified resource cost (ResourceCost).



Page 47 / 95

Figure 33 - simplified billing data model for UC2

Some initial reports are shown below. The Figure 34 shows the UC2 Quality Profiles and the min/max values for metrics (bitrate, compression level, entropy) and QoE; more advanced model could have overlapping metrics and QoE values ranges as well as additional metrics.

Figure 34 - UC2 Quality Profile



Page 48 / 95

The Figure 35 shows the simplified resource cost model used in 5G-MEDIA, with different profiles and billing periods that are per month (for plain VNFs) and per second (for FaaS VNFs).

Figure 35 - simplified resource cost model

The Figure 36 shows the different metrics and expected/measured QoE values for the UC2 services.

Figure 36 - NS sessions monitoring reports

5.2.1. The role of Accounting Agent in the Accounting & Billing services

The Accounting agent, that initially described in D4.1, is a mechanism developed for purposes of accounting the operational states and relations of the NS instances, VNFs and VDUs of an OSM tenant while receiving metrics concerning the running VDUs. The aforementioned actions are conducted for billing purposes. The leading role of the accounting agent is to record the relations of a tenant with an NS instance and its underlying VDUs, collecting selected consumptions and publishing them to the billing services.

In the 1st release of the Accounting agent, the consumption of deployed (through the OSM release 3) OpenStack/DevStack VMs was tracking. In the latest release, the agent has been updated to be compatible with the OSM releases 4/5 and in parallel has been extended to take into



Page 49 / 95

consideration the consumption of resources in the Kubernetes/FaaS VIM. This agent can be decomposed into the OSM Notification Handler, the NBI API Client, the Accounting agent database & API, the Accounting Service Client and the NFVI Metrics Collector. These components have been integrated, successfully tested and validated with OpenStack VIM and Kubernetes/FaaS VIM. Given that the latest version of the agent is independent of the NFVI/VIM, the resources consumption of further VIMs can be easily performed; the necessary information is retrieved by invoking the NBI OSM API and by processing a set of events/messages in the intra-OSM Kafka bus29.

The Accounting agent has been developed in Python and is deployed as a docker container. For the Accounting agent Database & API, Django30 and Django REST Framework31 have been employed, while PostgreSQL has been selected as the database and the application is served through Apache server and the WSGI module. The online documentation of the REST API the agent exposes is available through the Swagger32 framework. The Accounting Service Client and NBI API Client are implemented as simple HTTP clients. Moreover, the NFVI Metrics Collector consumes messages from the intra-OSM Kafka bus as a Kafka Consumer (ns topic) and Celery33 has been employed for purposes of periodically aggregating and forwarding the collected metrics to the Accounting/Billing service.

Figure 37 – Interactions among the components included in the events and metrics collection for accounting

29 https://kafka.apache.org/ 30 https://www.djangoproject.com/ 31 https://www.django-rest-framework.org/ 32 https://swagger.io/ 33 http://www.celeryproject.org/



Page 50 / 95

To begin with, the OSM Notification Handler subscribes to the intra-OSM Kafka bus and receives a notification concerning the instantiation of a new NS. Leveraging the NBI API Client, the OSM Notification Handler fetches necessary NS, VNF and VDU information from the OSM NBI API. The acquired essential information regarding the relations between NS, VNFs and VDUs is recorded to the Accounting agent Database. Through the Accounting Service client, new NS, VNF and VDU sessions are initiated on the Accounting service. After the sessions have been initiated and recorded, the NFVI Metrics Collector component is then responsible for the collection and periodic aggregation of the selected measurements, depending on the type of deployed VNFs (FaaS or non-FaaS). When a collection cycle is completed the aggregated metrics are published to the Billing services.

OSM Notification Handler

The OSM Notification Handler is a component that connects to the intra-OSM Kafka Bus, which is utilized for the communication of the various OSM components and receives the notifications (messages) that are published to this Kafka bus. The general idea behind this component is that it receives notifications about events that occur concerning a network service’s instantiation, termination or scaling. The OSM Notification Handler processes each of the notifications about an event accordingly.

It should be noted that, in the previous versions of the Accounting agent, when OSM release 3 was utilized, the almost equivalent component was the Virtualized Infrastructure Manager (VIM) Notification Handler. The main drawback of the OSM Notification Handler was that in order to support different types of VIMs (e.g. OpenStack, OpenNebula34), separate sub-modules should have been developed. Moreover, in case the notifications regarding the instantiation and termination of network services were not existent or accessible for a type of VIM, then this VIM type would not be supported.

The major alteration in the OSM’s architecture, with the introduction of the centralized intra-OSM Kafka Bus, was considered a major improvement, allowing for the Accounting agent to keep track of the instantiations, terminations, scaling events etc. of the network services in a more unified, VIM-agnostic approach.

Accounting agent API & database

The API of agent is considered the second component of the Accounting agent. The implemented API includes endpoints responsible for fetching NS instances by the tenant, VDUs by NS instance or tenant etc. The recording of all state transitions of NS instances and VDUs by the OSM Notifications Handler makes the Accounting agent capable of providing an API including endpoints able to retrieve information referring to a specific time range about the overall hours of a VDU being active, paused, suspended and shut down, or the overall hours of an NS instance being up or down depending on the state of its underlying VDUs etc. The aforementioned operations

34 https://opennebula.org/



Page 51 / 95

concerning NS instances or VDU accounting are available per tenant. An overview of the available endpoints of the Accounting agent API is presented in Figure 38.

NBI API Client

The OSM NBI API client is another HTTP client developed for purposes of interfacing with the Northbound Interface (NBI) API offered by OSM. This client is an essential component of the accounting agent as it interfaces with OSM and retrieves information about tenants, data centres, NS instances, VNFs and their relations. The NBI API client plays a significant role as the relations between NS instances, VNFs, VDUs and tenants must be constructed, leveraging on the notifications received and handled by the OSM Notification Handler component.

Figure 38 – The API of accounting agent as it appears in the Swagger framework



Page 52 / 95

NFVI Metrics Collector

The NFVI Metrics Collector component is responsible for collecting metrics from the Monitoring infrastructure, part of the MAPE, regarding the running VDUs. The NFVI Metrics Collector is a subscriber in the topic ns.instances.trans of the 5G-MEDIA Kafka bus where the collected metrics are pushed after the adaptation process, whether these metrics are received from the applications or infrastructures. Periodically, the NFVI Metrics Collector aggregates the collected metrics per VDU and, leveraging on the Accounting Service Client, forwards them to the Accounting service.

The current version of the NFVI Metrics Collector and the Accounting agent overall supports the collection of metrics from both FaaS and (regular) non-FaaS VNFs. In the case of non-FaaS VNFs the metrics that are collected include the CPU utilization, the memory (RAM) utilization and the disk usage. On the other hand, for FaaS VNFs, only memory utilization is collected and forwarded to the Accounting and Billing services.

Accounting Service Client

The Accounting Service Client is an HTTP client developed for purposes of interfacing with the API offered by the Accounting service. The client serves as a wrapper for making requests to the Accounting service, opening and closing NS, VNF and VDU sessions, while also forwarding selected metrics for each VDU. Samples are presented in Annex I – Intra-OSM Kafka bus notification samples for the LCM Operations

6. Interfaces implementation

6.1. 5G App and Service Catalogue NBI implementation

6.1.1. NSD and VNF Package management interface

As reported in D4.1 (section 6.2), the 5G Apps and Services Catalogue NBI is based on ETSI NFV SOL005 v2.4.1. In particular, the Catalogue implements the NSD and VNF Package management interfaces, details about all the available operations can be found in the above-mentioned deliverable as well as the specification of the interface for the MEC AppD management, which is intended to be implemented as a future feature. For convenience, NSD and VNF Package management operations are reported also in Annex II – NSD and VNF Package Management Operations.

6.1.2. Catalogue-to-Catalogue interface

In order to allow users to commit new developed applications/functions and services from the DevOps environment to the production one, a new RESTful NBI has been defined for exporting VNF Packages, PNFDs and NSDs. Details of the available operations are reported in Table 9.



Page 53 / 95

Table 9 - Catalogue-to-Catalogue interface

Operation HTTP Method URI Description

Export VNF Package POST /catalogue/cat2catOperation/exportNsd/{ns

dInfoId}

This resource allows to POST an NSD with a specified “nsdInfoId”, which is stored in the private Catalogue, to the public related instance

Export PNFD POST /catalogue/cat2catOperation/exportPnfd/{pnfdInfoId}

This resource allows to POST a PNFD with a specified “pnfdInfoId”, which is stored in the private Catalogue, to the public related instance

Export NSD POST /catalogue/cat2catOperation/exportVnfPkg/{vnfPkgInfoId}

This resource allows to POST a VNF Package with a specified “vnfPkgInfoId”, which is stored in the private Catalogue, to the public related instance

Each of the methods specified in the previous table triggers the send-off notification over the private Catalogue’s internal communication bus, this notification is then processed by the Catalogue-to-Catalogue Plugin that will retrieve the specified descriptor from the local storage and will perform the onboarding operation at the public Catalogue NBI. Then, the public Catalogue, after receiving a request for onboarding a descriptor or a package, according to SOL005 specification, will proceed to local onboard it. Finally, at the public Catalogue, a notification is sent to trigger the active MANO plugins for translating and onboarding the descriptor/package into the underlying MANOs’ inner catalogues.

6.1.3. Admin interface

The 5G Apps and Services Catalogue provides a RESTful Admin NBI, which is intended to be accessible only to Admin users for performing management operations related to plugins.

The Admin user can create new plugin instances at runtime, both MANO plugins and Catalogue-to-Catalogue plugins, as well as get information about all running instances or a specific one and enable/disable and delete them. Available operations are listed in Table 10 and Table 11.

Table 10 - MANO Plugins management interface


Create MANO Plugin POST /catalogue/manoManagement/manos

This resource allows to create a new MANO Plugin instance, the payload of the request consists in a JSON object representing the MANO entity



Page 54 / 95


Query All MANO Plugins

GET /catalogue/manoManagement/manos

This resource allows to GET information about all MANO Plugins stored in the Catalogue’s DB

Query MANO Plugin GET /catalogue/manoManagement/manos/{manoId}

This resource allows to GET information about a specific MANO Plugin, identified via “manoId”

Update MANO Plugin PATCH /catalogue/manoManagement/manos/{manoId}

This resource allows to change the operational state of a MANO Plugin identified via “manoId”. The payload of the request consists in a JSON object representing the MANO entity and containing the updated “pluginOperationalState” (e.g ENABLED, DISABLED or DELETING)

Table 11 - Catalogue-to-Catalogue management interface


Create Catalogue-to-Catalogue Plugin

POST /catalogue/cat2catManagement/5gcatalogues

This resource allows to create a new Catalogue-to-Catalogue Plugin instance, the payload of the request consists in a JSON object representing the Catalogue entity

Query All Catalogue-to-Catalogue Plugins

GET /catalogue/cat2catManagement/5gcatalogues This resource allows to GET information about all Catalogue-to-Catalogue Plugins stored in the Catalogue’s DB

Query Catalogue-to-Catalogue Plugin

GET /catalogue/cat2catManagement/5gcatalogues /{catalogueId}

This resource allows to GET information about a specific Catalogue-to-Catalogue Plugin, identified via “catalogueId”

Update Catalogue-to-Catalogue Plugin

PATCH /catalogue/cat2catManagement/5gcatalogues /{catalogueId}

This resource allows to change the operational state of a Catalogue-to-Catalogue Plugin identified via “catalogueId”. The payload of the request consists in a JSON object representing the Catalogue entity and containing the updated “pluginOperationalState” (e.g ENABLED, DISABLED or DELETING)



Page 55 / 95

6.2. 5G App and Service Catalogue SBI implementation

6.2.1. OSM R3/R4/R5/R6 MANO Plugin

The 5G Apps and Services Catalogue is capable of supporting the management of NFV descriptors and packages towards OpenSource MANO, from release three till release six.

D4.1, in particular, section 6.4.3, can be taken as a reference for the MANO Plugin software design specification. At that time, the Catalogue was supporting just OSM R3 and the south-bound driver was relying on the J-OSMClient library35 as client implementation of OSM NBI. In order to support OSM further releases, from R4 till R6, a new client library has been developed and integrated within the Catalogue spring-boot application as a Maven dependency. The new library, called “OSMr4PlusClient”, implements the client-side of the OSM NBI for descriptors and packages management, which, starting from OSM R4, has been progressively aligned with ETSI NFV SOL005 by the OSM Community. Differences between the different OSM versions are handled at the PluginsManager Service depending on the plugin type, i.e. OSMR3, OSMR4, OSMR5 and OSMR6.

The available operations at the OSMr4PlusClient are listed on D5.2 [13].

6.2.2. OpenStack VIM Plugin

The first version of the OpenStack (OS) VIM Plugin that is integrated within the Catalogue has been tested for image onboarding on OpenStack releases starting from Ocata36 (15th release) till Queens37 (17th release). With reference to D4.1 (Section 6.4.3.1.), the web-download method has been selected as the first approach for the plugin implementation, where the “uri” field (see Figure 39) that contains the image location on the web storage is retrieved for each VNF from its own VNFD. Indeed, with reference to ETSI NFV SOL001, the image location can be specified in “tosca.nodes.nfv.Vdu.Compute -> sw_image_data” or “tosca.nodes.nfv.Vdu.VirtualBlockStorage -> sw_image_data”.

Figure 39 - Image Import API payload example, web-download case

35 https://github.com/girtel/J-OSMClient 36 https://www.openstack.org/software/ocata/ 37 https://www.openstack.org/software/queens/



Page 56 / 95

For interacting with the OS Glance38 images repository, the OS Plugin makes use of the OpenStack4j39 Java library v2. In particular, the OS Glance images APIs implemented in OpenStack4j and used for the image uploading and deleting are reported in Table 12 - OS Glance images APIs for uploadingTable 12.

Table 12 - OS Glance images APIs for uploading


Create image40 POST /v2/images This resource allows to create a

record for an image

Import an image POST /v2/images/{image_id}/import

This resource allows to import an image with reference to an already existing “image_id”. The payload of the request specifies the import method, e.g. web-download

Delete image DELETE /v2/images/{image_id} This resource allows to delete an image record including the binary image data

6.2.3. Catalogue-to-Catalogue Plugin

The C2C Plugin, as specified in Section 4.1, is activated when the Catalogue is configured as a private instance. The C2C south-bound driver is configured for interacting with a Catalogue public instance and has a dual role. First of all, it’s responsible for loading available public descriptors and packages, depending on the user authorization profile and projects visibility, and to store them locally, this way the user can reuse already existing services and applications for creating new customized services. Secondly, the C2C driver handles the users’ requests for exporting new descriptors and packages to the public Catalogue.

For such purposes, the C2C driver integrates a library which is a client implementation of the Catalogue NSD and VNF Package Management interfaces based on ETSI NFV SOL005. Details about available implemented APIs are reported in Annex I as per the NSD and VNF Package Management NBI.

38 https://docs.openstack.org/glance/latest/ 39 http://www.openstack4j.com/learn/image-v2 40 https://docs.openstack.org/api-ref/image/v2/index.html?expanded=stage-binary-image-data-detail,create-image-detail#image-create



Page 57 / 95

7. Media and Network functions repository

This section provides the final repository of applications that will be stored in the 5G App and Service Catalogue. The Generic Network Functions are those that are not strictly media related, and they will be used for composing and deploying media services on top of the 5G-MEDIA SVP. The Media Network Functions are specific media packages that facilitate media applications within the 5G-MEDIA framework.

All these applications could be implemented and then deployed as VNF on an NFVI, in order to bring flexibility in terms of deployment, upgradability and functionality and allows for more dynamic media applications and scenarios. Other option is that the applications are developed as PNFs, which can be either hardware solutions providing specific functionality (i.e. broadcaster’s transmission equipment like en-/decoders and gateways) or they can be functions that are virtual but not dynamically provisioned as the VNFs mentioned before, but already running in the network.

7.1. Generic Network Functions

The following table reports the initial set of Generic Network Functions along with their description and requirements in terms of VDUs.

Table 13 – Generic Network Apps technical requirements

VNF/APP DETAILS

vFirewall NF name: NETW_APP_001_FW Short description of functionalities: Security Front/Back End VNFs to protect users and service providers data VNF component name: NETW_APP_001_FW_01

• Memory: 1 GB • CPU: 1 vCPU • Storage: 1 GB • Image: vFirewall-v01.qcow2

Connectivity specifications: • VLs: mgmt_net, ext_net, data_net

Provider: NXW Status: READY



Page 58 / 95

VNF/APP DETAILS

vIDS/DPI VNF name: NETW_APP_002_IDS_DPI Short description of functionalities: Security Front/Back End VNFs to protect users and service providers data VNF component name: NETW_APP_002_IDS_DPI_01

• Memory: 8 GB • CPU: 4 vCPUs • Storage: 20 GB • Image: vIDS-v01.qcow2



BIND PNF name: NETW_APP_003_DNS Short description of functionalities: It offers standard DNS services for IPv4 based networks. PNF component name: NETW_APP_003_DNS_01

• Memory: 1 GB • CPU: 1 vCPU • Storage: 3 GB • Image: vDNS-v01.qcow2

Connectivity specifications: • VLs: mgmt_net, int_net, ext_net

Provider: NXW, TID Status: Deployed in all the network. In Onlife network, if the client has IPv6 it allows translation from IPv4 to IPv6

vProbe VNF name: NETW_APP_004_QOE Short description of functionalities: It analyse the multimedia content passing through it providing a measure of QoE. VNF component name: NETW_APP_004_QOE_01

• Memory: 8 GB • CPU: 2 vCPU • Storage: 10 GB • Image: qoe_probe_1.0.6.qcow2, qoe_probe_1.0.6 (Docker)

Connectivity specifications: • VLs: mgmt._net, int_net, ext_net

Provider: UPM Status: READY



Page 59 / 95

7.1.1. Generic VNFs and PNFs descriptions

7.1.1.1. vFirewall

The vFirewall network function is based on VyOS41, an open-source GNU/Linux-based operating system extended with network routing and firewall software suitable for being deployed in VNFs in the form of Virtual Machines (VMs). This network function was explained on details in D4.1.

7.1.1.2. vIDS/DPI

The vIDS/DPI network function is based on the SELFNET virtual Intrusion Detection System (vIDS) VNF, which analyses network traffic in real-time and reports alerts when packets content matches a specific detection rule (called signature). This VNF has been developed in the SELFNET 5G-PPP Phase 1 EU project42 as part of the Self-Protection Use Case activities and it is explained in D4.1.

7.1.1.3. vDNS

The vDNS network function is based on the BIND943 software, an open-source DNS software which implements the DNS protocol on GNU/Linux-based operating system, and it is explained in D4.1.

7.1.1.4. vLoadBalancer

The vLoadBalancer enhances the vDNS network function described in D4.1 (7.2.2.3) introducing new load balancing functionalities through the integration of the HAProxy44 software.

As described in D4.1, the DNS functionality remains based on the BIND9 software, where in Ubuntu 16.04 Linux distributions the main configuration elements of the service are available at

• /etc/bind for general service and application configuration parameters contained in the configuration files:

o named.conf o named.conf.default-zones o named.conf.local o named.conf.options

• /var/lib/bind in which the specific zones files are available o ZONE-X-NAME.zone, for forward translations from URL to IP o ZONE-X-NAME.rev.zone, for reverse translations from IP to URL

41 https://vyos.io/ 42 https://5g-ppp.eu/selfnet/ 43 https://www.isc.org/downloads/bind/ 44 http://www.haproxy.org/



Page 60 / 95

In the vLoadBalancer PNF, the BIND DNS functionality is combined with the HAProxy (high availability proxy) software. HAProxy can be configured for several purposes:

• as TCP Proxy, can accept a TCP connection from a listening socket, connect to a server and attach these sockets together allowing traffic to flow in both directions

• as HTTP Reverse-Proxy ("gateway“), receives HTTP requests and passes them to servers using different connections

• as Content-Based Switch, it can consider any element from the request to decide what server to pass the request or connection to

• as Server Load Balancer, it can load balance TCP connections and HTTP requests

• as Traffic Regulator, it can apply traffic policies (protect the servers against overloading, adjust traffic priorities based on the contents, and even pass such information to lower layers)

HAProxy configuration file is located, on Linux 16.04 distributions, at /etc/haproxy/haproxy.cfg.

Once HAProxy is started, three different parallel procedures are activated:

- processing of incoming connections o accept incoming connections through its "frontend", which references one or

multiple listening addresses; o apply the frontend-specific processing rules to these connections (according to

haproxy.cfg file); o pass these incoming connections to a "backend", which contains the list of servers

and the load balancing strategy for this server farm; o apply the backend-specific processing rules to these connections; o decide which server to forward the connection to according to the load balancing

strategy; o apply the backend-specific processing rules to the response data; o apply the frontend-specific processing rules to the response data;

- periodical checking of servers' status; - exchanging of information with other HAProxy nodes if available.

In 5G-MEDIA, the vLoadBalancer is deployed as a PNF, which is pre-instantiated in the NFVI infrastructure and can be reached by users on the external virtual network with respect to service (e.g. the vCDN service). At the same time the vLoadBalancer is connected to the service on the same external virtual network and it’s able to redirect users’ request among VNFs registered in its servers’ farm.



Page 61 / 95

Figure 40 - vLoadBalancer workflow in UC3

To allow a dynamic configuration and update of the records in the DNS as well as updating the HAProxy configuration file and restarting the load balancing service, a RESTful interface is exposed by the PNF. The current available API is described in Table 14.

Table 14 - vLoadBalancer API

HTTP Method &

REST Endpoint

Request body Description

POST

/dns

{

"hostname": <host.domain>,

"ip": <IP address>>

}

This POST operation is used to:

- apply a add a new A record to the zone file for a given DOMAIN;

- make modifications to haproxy.cfg file in order to add a new host to the load balancing list;

The request body include attributes as follows:

• hostname: the FQDN of the host to be mapped

• ip: the IP address to map to the URL

DELETE

/dns

{

"hostname": <host.domain>

}

This DELETE operation is used to:

- remove a previously set FQDN for a host;

- remove a previously added host to load balancing list (modifying the haproxy.cfg file).

The request body include attributes as follows:

• hostname: the FQDN of the host to be removed



Page 62 / 95

API usage examples

# curl -X POST -H 'Content-Type: application/json' -H 'X-Api-Key: secret' -d '{‘’hostname’’: ‘’cdn-uhd.cache#.5gmedia.lab’’, ‘’ip’’: ‘’<new edge cache ip address>’’}’ http://localhost:9999/dns

# curl -X DELETE -H 'Content-Type: application/json' -H 'X-Api-Key: secret' -d '{‘’hostname’’: ‘’cdn-uhd.cache#.5gmedia.lab’’}' http://localhost:9999/dns.

7.1.1.5. vProbe

The vProbe network function aims to obtain measure the QoE based on the media content that the platform is providing to the final user. This python-based function uses different open-source tools and libraries for its running process: Keras45, sklearn46 and FFmpeg47.

Since there are two different types of media content on the platform, the composition of this function at the current time is different depending on whether the content is 3D media or regular video.

3D Media content

The approach followed, in this case, is depicted in [14] where a QoE MOS metric is obtained from some parameters obtained from the 3D stream: Geometry resolution, Texture resolution, Network protocol and RTT. This approach is implemented at this moment by collecting the previous parameters and sending them to the CNO where the QoE MOS metric is calculated following the model proposed on [14].

Video content

This function approach collects basic information of the video sequence that is directly provided by FFmpeg without the need of any additional computation. This model is capable of predicting the measurement of MOS in real-time. The model receives as input a set of descriptors that are gathered during the data acquisition of the video sequence. Then, the data is normalized and projected in a sub-space where the points are better separated in terms of MOS variable. Finally, a regressor is employed in order to obtain the expected value of the MOS as well as its corresponding confidence interval.

The set of features that are obtained directly from FFmpeg are depicted in Table 15:

45 https://keras.io/ 46 https://scikit-learn.org/stable/ 47 https://www.ffmpeg.org/



Page 63 / 95

Table 15 – Basic video features

Feature name Description Example Variable type

codec Codec name H264 string

scan_type Scan type progressive string

bitrate Bit rate in kbps 6110 int

frame_rate Frames per second 50 int

width Width of the image 1920 int

height Height of the image 1080 int

duration Duration of the video sequence in seconds

6 int

For real-time MOS calculation, apart from this very basic features, the model takes into account the spatial entropy metric SI and the temporal entropy metric TI. These metrics are calculated following the open-source SITI48 algorithm recommended by the Video Quality Expert Group (VQEG)49. This algorithm calculates the SI and TI metrics the ITU-T P.910 [15] standard.

Finally, the probe calculates the blurriness of the image by calculating the variance of the Laplacian method proposed by Pech-Pacheco et al. in their 2000 ICPR paper [16].

For training the regression model, different databases have been used. The main idea is to have different resolutions, codecs, bitrates, frame rates and scan types. The used databases are depicted in . With the set of different databases, the regression model has been trained and validated for MOS calculation.

Database Provider

IRCCyN IVC 1080i50 Institut de Recherche en Communications et Cybernétique de Nantes

MCL-V51 University of Southern California - USC Media Comm Lab

ITS4S52 Institute for Telecommunication Science

48 https://github.com/Telecommunication-Telemedia-Assessment/SITI 49 https://vqeg.github.io/software-tools/quality%20analysis/siti/ 50 http://ivc.univ-nantes.fr/en/databases/1080i_Videos/ 51 http://mcl.usc.edu/mcl-v-database/ 52 https://www.its.bldrdoc.gov/resources/video-quality-research/data.aspx



Page 64 / 95

Database Provider

TUM_1080p25 TUM_1080p5053

Fakultät für Elektrotechnik und Informationstechnik

Technische Universität München

VQEG_HDTV54 Video Quality Experts Group (VQEG)

KoNViD_1k55 The Konstanz Natural Video Database

This MOS based QoE metric doesn’t detect quality loses and it’s only calculated based on features of the image and the compression rate. In order to take into account loses of quality, the probe obtains a set of no reference metrics to evaluate the level of distortion provided by the AGH University56. The indicators are provided with thresholds are depicted in Table 16:

Table 16 – Most important distortion parameters (source AGH University VQ indicators)

Indicator Range of results

Monotonicity relative to distortion Thresholds for no distortion

Blockiness 0-3570 Greater value à less visible distortion 0.9-1.01

Block loss 0-200 Greater value à more visible distortion 0-5

Interlacing 0-1 Greater value à greater distortion 0

Flickering 0-8 Greater value à more visible distortion 0.125

Since these parameters are not considered on any database, the MOS is corrected (decreased) when the values are out of the thresholds. Consequently, a final QoE pseudo-MOS metric is sent to the CNO as QoE metric for the given media content. This model should be validated in the future.

7.2. Media Network Functions

The following table reports the updated list of the refinements, updates, and newly implemented Media Network Functions along with their description and requirements in terms of VDUs.

53 https://www.ei.tum.de/ldv/forschung/videolabor/data-sets-downloads/ 54 https://www.its.bldrdoc.gov/vqeg/downloads.aspx 55 http://database.mmsp-kn.de/konvid-1k-database.html 56 http://vq.kt.agh.edu.pl/metrics.html



Page 65 / 95

Table 17 – Media-specific apps technical requirements

VNF/APP DETAILS

vCache VNF name: MEDIA_APP_01_CACHE Short description of functionalities: Cache server where the user is connected to, can be deployed according to a hierarchy of mid/edge caches orchestrated/managed by the vCDN. In order to serve the media content near to the end user, reducing latency and offering a better QoS/QoE. VNF component name: MEDIA GEN_APP_001_CACHE_01

• Memory: 8 GB • CPU: 4 vCPUs • Storage: 40 GB • Image: vCache.qcow2



vCompression Engine

VNF name: GEN_FUN_02_COMPRESSION Short description of functionalities: Virtual media function for compression/decompression and encoding/decoding of audio-visual media content. VNF component name: GEN_FUN_02_COMPRESSION_02

• Memory: 8 GB • CPU: 8 vCPUs • Storage: 75A GB • Image: vCompresssion.qcow2 / vcompression (Docker)


Provider: IRT Status: WORK IN PROGRESS / Final state Feb/2020

Media Process Engine

VNF name: MEDIA_APP_03_MPE Short description of functionalities: A media functions that performs the switching and mixing of audio/video signals. It serves as a virtual broadcast video/vision switcher. VNF component name: MEDIA_APP_03_MPE_02

• Memory: 8 GB • CPU: 8 vCPUs • Storage: 10 GB • Image: MPEv1.qcow2


Provider: UPM Status: WORK IN PROGRESS / Final state Feb/2020



Page 66 / 95

VNF/APP DETAILS

Speech-to-Text Engine

VNF name: MEDIA_FUN_04_SPEECH Short description of functionalities: A media function that allows for the recognition and analysis of the audio/video material’s audio signal which will be decoded into text. VNF component name: MEDIA_FUN_004_SPEECH_02

• Memory: 8 GB • CPU: 8 vCPUs • Storage: 2 GB • Image: vspeech.img (qcow2) / vspeech (Docker)


Provider: BIT Status: WORK IN PROGRESS / READY / Final state Feb/2020

Demonstrator VNF name: MEDIA_FUN_05_Demonstrator Short description of functionalities: A media function that receives an A/V stream and displays that stream with minimal latency in a browser-based user interface. In addition, it can interact with the Speech-to-Text Engine in such a way as to provide a subtitle overlay to the A/V output stream. VNF component name: MEDIA_FUN_005_Demonstrator_01

• Memory: 2 GB • CPU: 2 vCPUs • Storage: 2 GB • Image: vplay.img (qcow2)


Provider: BIT Status: READY

vTranscoder3D VNF name: MEDIA_APP_06_TRANSCODER3D Short description of functionalities: Performs on-the-fly transcoding of a 3D media stream comprising of time-varying geometry and texture information. Both types of content (2D & 3D) are simultaneously re-encoded. VNF component name: Media_APP_006_TRANSCODER3D_02

• Memory: 4 GB • CPU: 1 vCPU • Storage: 8 GB • Image: vTranscoder3D-cpu


Provider: CERTH Status: READY



Page 67 / 95

VNF/APP DETAILS

vTranscoder3D-GPU VNF name: MEDIA_APP_06_TRANSCODER3D Short description of functionalities: Performs on-the-fly transcoding of a 3D media stream comprising of time-varying geometry and texture information. Both types of content (2D & 3D) are simultaneously re-encoded. This version utilizes GPU Hardware to accelerate the processing of the 3D media stream and achieve higher output frame-rates or transcoding more qualities at once. VNF component name: Media_APP_006_TRANSCODER3D_02

• Memory: 4 GB • CPU: 1 vCPU • GPU: 1 x Nvidia 1080Ti (actual hw) (for gpu image) • Storage: 8 GB • Image: vTranscoder3D-cpu, vTranscoder3D-gpu



5G-MEDIA Gateway PNF name: MEDIA _PNF_01_GATEWAY Short description of functionalities: Convert the incoming SDI Signals to IP or vice versa Provider: IRT (Vendor Solution) Status: READY (Procurement of ST 2110 equipment in progress)

UHD Streaming Server

PNF name: MEDIA_PNF_02_UHDSS Short description of functionalities: Transmits VoD from media libraries according to user profiling and preferences. Can be eventually replicated and serves as the root for vCache/vTranscoder hierarchies VNF component name: MEDIA_APP_02_UHDSS_01

• Memory: 8 GB • CPU: 4 vCPUs • Storage: 40 GB • Image: OriginServer.qcow2



vBuffer VNF Name: MEDIA_APP_07_BUFFER Short description of functionalities: Sliding window buffer to be used in order to buffer the live 3D streams and facilitate the replay functionality in UC1. VNF component name: MEDIA_APP_07_BUFFER_01

• Memory: 8 GB • CPU: 1 vCPU • Storage: 16 GB • Image: To be developed

Connectivity specifications: • VLs: mgmt._net, ext_net, data_net

Provider: CERTH Status: WORK IN PROGRESS / Final state Feb/2020



Page 68 / 95

VNF/APP DETAILS

Image/Face Recognition

VNF Name: MEDIA_APP_08_IMRECOGNITION Short description of functionalities: Detection of objects within the A/V material with a context-aware text-based output VNF component name: MEDIA_APP_08_IMRECOGNITION_01

• Memory: 8 GB • CPU: 8 vCPUs • Storage: 2 GB • Image: vDetection.img (qcow2) / vdetection (Docker)


Provider: BIT Status: WORK IN PROGRESS / Final state Feb/2020

vReplay VNF Name: MEDIA_APP_09_REPLAY Short description of functionalities: Temporal aggregation of recent 3D media frames and game state information into a 3D replay clip VNF component name: MEDIA_APP_09_REPLAY_01

• Memory: 8GB • CPU: 1vCPU • Storage: 16GB • Image: to be developed


Provider: CERTH Status: WORK IN PROGRESS / Final state Feb/2020

vBroker VNF name: GEN_FUN_11_BROKER Short description of functionalities: Application-level multicasting to support a reasonable amount of spectator clients to the transcoded 3D streams VNF component name: GEN_FUN_11_BROKER_01

• Memory: 8GB • CPU: 1vCPU • Storage: 40GB • Image: to be developed





Page 69 / 95

VNF/APP DETAILS

vUnpacker VNF name: MEDIA_APP_12_UNPACKER Short description of functionalities: software function that acts as decoder for SMPTE ST 2110 standard video over IP. VNF component name: MEDIA_APP_12_UNPACKER_01

• Memory: 8GB • CPU: 12 vCPU • Storage: 10GB • Image: unpacker.qcow2


Provider: UPM Status: READY

7.2.1. Media VNFs and PNFs descriptions

7.2.1.1.vCache

The vCache VNF is responsible to bring the media content closer to the 5G-MEDIA user by caching frequently-accessed information at the edge of the network, then improving the response time. The vCache application is based on the Apache Traffic Server57 (ATS). ATS is a high-performance web proxy cache that improves network efficiency and performance. It may be configured to run as forward and reverse proxy. The Apache Traffic Server software is released under Apache 2.0 license58, after the donation made by Yahoo! to the Apache Foundation. The first implementation of this function is depicted in D4.1.

vCache, a VNF that deploys a cache server to which the user is connected to, according to a hierarchy of mid/edge caches orchestrated/managed by the vCDN, in order to serve the media content near to the end-user, reducing latency and offering a better QoS/QoE. This VNF is based on the open-source project Apache Traffic Server59. In this interim period, it was further updated in order to enhance the application-level monitoring for collecting new media-related metrics. Therefore, the following activities were performed:

● Updating edge and mid vCaches VNF Packages and VNFDs. ● Enhancing application-level monitoring for collecting new media-related metrics.

57 Apache Traffic Server: http://trafficserver.apache.org/ 58 Apache license 2.0: http://www.apache.org/licenses/LICENSE-2.0 59 https://trafficserver.apache.org/



Page 70 / 95

Table 18 – vCache REST APIs

HTTP Method &

REST Endpoint

Request body Description

GET/ Lists all the available APIs.

PATCH /vnfconfig/v1/cache_configuration

{“from”: “172.16.0.2”, “to”: “172.16.0.253”}

Modifies the configuration of the

vCache inspector plugin, setting up the IP range for accessing the cache

content.

PATCH /vnfconfig/v1/cache_origin_configuration

{“ip”: “10.0.8.39”, “port”: 32400}

Modifies the configuration of the cache related to the

origin server setting up its IP address and port. This configuration is not applicable to hierarchical vCache levels or the first

level of the vCache.

PATCH /vnfconfig/v1/cache_edge_origin_configuration

{“ip”: “10.0.4.250”, “port”: 8080}

Modifies the configuration of the

caches from the second level in the hierarchy, i.e. configures the vCaches with parent vCache IP

address and port.

7.2.1.2.vCompression Engine

The vCompression Engine is a media-specific function that compresses/decompresses and encodes/decodes incoming audio and video streams with low latency. It is based on open-source encoding techniques and uses the latest video standards such as SMPTE 2110 and H.264/H.265. It is intended for use before and after WAN transfer and is capable of dynamically adjusting encoding properties during runtime. Properties such as bitrate can be set on-the-fly via the RESTful API or performance metrics such as the actual, average bitrate, quality, CPU or RAM usage can be monitored. The vCompression Engine is completely implemented as software and will replace traditional hardware en-/decoders in the future due to their flexibility and agility especially with regard to remote productions.

Since the release of "D4.1 - 5G-MEDIA Catalog APIs and Network Apps", the vCompression Engine has undergone significant changes due to particular requirements in the context of UC2 and UC3, which are presented below.



Page 71 / 95

Design

The vCompression Engine has one input and several outputs. Figure X schematically shows only two outputs. Thereby, the input signal, which is given by an audio or video stream, is compressed with the help of the de-/encoder and finally distributed to the outputs via a muxer. Thus the same signal is present at each of the outputs, which is transmitted to the corresponding endpoints. The parameters of the de-/encoder can be set either via a RESTful API or via the connection to the 5G-MEDIA MAPE bus system. In addition, the vCompression Engine provides the option to have information about the status of the VNF sent via Webhooks or to transmit performance metrics to the 5G-MEDIA SVP via the bus interface.

Figure 41 – vCompression general architecture

Configuration

In order to start the vCompression Engine, it needs at least the URL of the input stream and an endpoint at which the compressed stream is to be transmitted. Supported input streams are UDP, TCP, RTP, RTMP and RTSP. Optional parameters concern the service itself such as the port where the service API should be reachable, the communication interfaces at which incoming data should have listened or data pushed or test cases for evaluation purposes. The following list shows all relevant parameters:

● API related config ○ API_PORT - Port where the API listens for incoming requests [default: 3000]

● Notifier related config ○ ENABLE_NOTIFIER - en-/disable Webhooks [default: false] ○ NOTIFIER_ENDPOINT - URL of the Webhooks endpoint [default:]

● FFmpeg related config ○ FFMPEG_INPUT - URL of the incoming stream (UDP, TCP, RTP, RTMP, RTSP)

[default:] ○ FFMPEG_OUTPUTS - URLs where to send the encoded stream [default:]

● Test related config



Page 72 / 95

○ ENABLE_TEST - en/disable test scenario, how vCompression behaves when changing the bitrate [default: false]

○ TEST_FILE - file to store the test metrics [default: log.csv] ○ TEST_INTERVAL - interval where bitrate remains constant [default: 30000] ○ TEST_BITRATES - bitrates to test [default: [5000, 500, 15000, 14000, 50000, 3000,

1000, 12000, 10000, 8000, 20000, 1000, 40000, 30000, 12000, 500, 3000]] ● Kafka related config

○ ENABLE_KAFKA - en-/disable Kafka [default: false] ○ ENABLE_KAFKA_CONSUMER - en-/disable Kafka consumer [default: true] ○ ENABLE_KAFKA_PRODUCER - en-/disable Kafka producer [default: true] ○ KAFKA_KEY - Kafka key [default: vce] ○ KAFKA_ATTRIBUTE - Kafka attribute [default: vdu_uuid] ○ KAFKA_HOST - IP of the Kafka host [default:] ○ KAFKA_PORT - port of the Kafka host [default: 9092] ○ KAFKA_CONSUMER_TOPIC - consumer topic [default: ns.instances.conf] ○ KAFKA_PRODUCER_TOPIC - producer topic [default: app.vce.metrics]

The vCompression Engine can be either configured via RESTful API or during instantiation via environmental variable injection. That means to configure the function by defining a specific file named .env or by using build-in commands which are provided by the packaging technology (i.e. –e in case of Docker).

Interfaces

The RESTful API, Webhooks and Bus interfaces are provided to configure, monitor and access the results of the vCompression Engine. While the Webhooks and RESTful API are based on the Hypertext Transfer Protocol (HTTP), Apache Kafka bus uses the TCP network protocol to establish a bidirectional real-time data transmission between the media-specific function and parts of 5G-MEDIA SVP such as CNO/MAPE. As another option, the Webhooks can be used as a real-time push interface. Once the URL of a remote host or service is configured, status information will be transferred remotely.

Table 19 – vCompression API

# HTTP method

URI Description

1 GET / Gets the status of the process and all metrics that relate to it

2 POST /bitrate/:b Changes the bitrate of the encoder



Page 73 / 95

# HTTP method

URI Description

3 POST /gop/:g Change the GOP size of the encoder

4 POST /resolution/r: change the resolution of the encoder

This is an example of an HTTP GET “/” request:

{

"status": true,

"stats": {

"id": {

"name": "Id",

"value": [

"02:42:ac:11:00:02",

""

]

},

"utc_time": {

"name": "UTC Time [ms]",

"value": 1567685938463

},

"pid": {

"name": "PID",

"value": 26

},

"pid_cpu": {

"name": "CPU Usage [%]",

"value": 39.7

},

"pid_ram": {



Page 74 / 95

"name": "RAM Usage [byte]",

"value": 57511936

},

"gop_size": {

"name": "GoP Size",

"value": 25

},

"num_fps": {

"name": "Fps",

"value": 35

},

"num_frame": {

"name": "Frame",

"value": 333

},

"enc_quality": {

"name": "Quality [0-69]",

"value": 15

},

"enc_dbl_time": {

"name": "Encoding Time [s]",

"value": 11.1

},

"enc_str_time": {

"name": "Encoding Time [h:m:s:ms]",

"value": "13"

},

"max_bitrate": {

"name": "Maximum Bitrate [kbps]",

"value": 3000

},

"avg_bitrate": {



Page 75 / 95

"name": "Average Bitrate [kbps]",

"value": 3075.1

},

"act_bitrate": {

"name": "Actual Bitrate [kbps]",

"value": 3128.4

},

"enc_speed": {

"name": "Encoding Speed [x]",

"value": 1.16

}

}

}

Packaging

The vCompression Engine is packaged to the following formats:

• Docker: Build script included • Virtual Machine Image: Start/Stop scripts included

Further Information

For further information, please see the documentation of the vCompression Engine in the README.md file on https://production.eng.it/gitlab/5G-MEDIA/vcompression

The vTranscoder media application designed in D2.2 [17] and mentioned in D4.1 is contained on this function.

7.2.1.3.Media Process Engine

The Media Process Engine is a media-specific function, which acts as a video signal switcher, based on the open-source tools Voctomix60 and GStreamer61. Concretely, the MPE VNF is composed by voctocore, the processing part of the Voctomix solution. This processing core has a python-based

60 https://github.com/voc/voctomix 61 https://gstreamer.freedesktop.org/



Page 76 / 95

code that allows to switch between different input streamings, and to compose a new video streaming, by composing the input together with a background.

Since the release of "D4.1 - 5G-MEDIA Catalogue APIs and Network Apps" the support of 3 video sources has been added.

7.2.1.4.Speech-to-Text Engine

The Speech-to-Text Engine is a media-specific function based on deep learning technologies that recognizes speech within any audio and video material and converts it into a human-readable text format in real-time. Supported input signals are raw and encoded audio and video streams based on the UDP, TCP, RTP, RTMP or RTSP protocol. The text derived from the input stream is either written directly into the output stream i.e. as subtitles or provided separately as metadata via appropriate (real-time) interfaces (HTTP Restful API, WebSocket, Webhooks).

Figure 42 – Speech-to-text engine design

Since the release of "D4.1 - 5G-MEDIA Catalog APIs and Network Apps", the following major changes have been made to the Speech-To-Text Engine:

● Integration of Mozilla DeepSpeech as an open-source implementation based on Baidu's Deep Speech research paper.

● Support of both Google Speech API and Mozilla DeepSpeech. Moving from Google Speech API to Mozilla DeepSpeech as the default inference task.

● Changing between the two S2T implementations (Google Speech API, Mozilla DeepSpeech) on the fly.

● Improved synchronization of video and subtitles. ● Extend by an additional output format/interface.

o Metadata as JSON via WebSocket and API (client-side rendering). o Video with build-in subtitle (server-side rendering).

● Extended for simulation purposes e.g. within the scope of 5G-MEDIA SDK (dummy profiler). ● Implementation of application-level monitoring to exchange data between 5G-MEDIA SVP

and VNF e.g. to retrieve the status of all application-related processes, performance and media-specific metrics.



Page 77 / 95

● Decoupling of FFmpeg's low-level tasks from the actual inference task by using WebSockets. This allows the actual S2T process to be executed as a true function within serverless infrastructures.

● Further developments regarding real-time speech recognition and low latency; real-time capabilities of Mozilla’s DeepSpeech, in progress.

Interfaces

The REST-API, WebSocket and Webhooks interfaces are provided to configure, monitor and access the results of the Speech-to-Text inference. While the Webhooks and REST-API are based on the Hypertext Transfer Protocol (HTTP), WebSocket uses the TCP network protocol to establish bidirectional real-time data transmission between the Speech-to-Text Engine and other enhanced media services. As another option the Webhooks can be used as a real-time push interface. Once the URL of a remote host or service is configured on the Speech-to-Text Engine, the results as well as the monitoring data will be transferred remotely.

Table 20 – Speech-to-text API

# HTTP method

URI Description

1 GET /api Finds all data

2 GET /api/transcription Finds transcription

3 POST /api/transcription/start Starts transcription

4 POST /api/transcription/stop Stops transcription

5 GET /api/transcription/state Finds state of transcription

6 GET /api/words Finds words

7 GET /api/statistics Finds statistics

8 GET /api/configuration Finds configuration

9 POST /api/configuration Updates configuration



Page 78 / 95

7.2.1.5.Demonstrator

The Demonstrator is a self-contained media VNF function that receives an A/V stream regardless of the transport protocol (UDP, TCP, RTP, etc.) and displays that stream with minimal latency in a browser-based user interface. In addition, it can interact with the Speech-to-Text Engine in such a way as to provide a subtitle overlay to the A/V output stream. In this context, all data is passed from the origin Speech-to-Text function to the Demonstrator via WebSocket. Conversely, the Demonstrator relays all requests to the origin Speech-to-Text function essentially via HTTP based RESTful API. This function is explained in D4.1 and since it was a helping function it is no longer used by the platform.

7.2.1.6.vTranscoder 3D/vTranscoder 3D-GPU

The requirements in terms of networking for 3D media streaming applications are challenging as the bandwidth that is required for a single 3D media stream is typically very high (~15-25 Mbps). In addition, the latency requirements are varying according to each application, but nonetheless, most of the envisaged applications are expected to also require interaction – in order to capitalize on the 3D nature of the media – therefore being further restricted by low latency requirements.

Full live tele-immersive 3D media transcoding is a novel concept that has not been explored in either academic literature or actual business. The main reason for this is mainly that the technology behind real-time 3D acquisition has also recently emerged, but following the overall mixed reality related developments, is expected to start reaching the consumer base in the following years. While adaptive streaming solutions for stereoscopic 3D video, multi-view content and on demand 3D content have been explored, there are little developments for the real-time, full 3D setting, which is a lot more complex.

vTranscoder3D is the 5G-MEDIA’s approach to face the live 3D media stream transcoding problem. Most of the challenges and design choices behind vTranscoder 3D have already been discussed in “

D4.1 - 5G-MEDIA Catalogue APIs and Network Apps”. Since the release of "D4.1 - 5G-MEDIA Catalogue APIs and Network Apps" the following updates were made:

● vTranscoder3D, the VNF that re-encodes incoming 3D media traffic in an online manner and which was developed from scratch within the 5G-Media project, was further updated in order to support the changing and maturing developments of UC1. Therefore, the following activities were performed:

○ Added support for VNF repositioning (i.e. migration) between heterogeneous computing nodes (i.e. cpu to gpu and gpu to cpu) for the vTranscoder3D.

○ Updated the vTranscoder3D VNF to output multiple qualities to the UC1 broker. ○ Conducted a study to assess the feasibility of CNN-based video encoding solutions

and published its results. (http://www.5gmedia.eu/outcomes/publication/ - Comparing CNNs and JPEG for Real-Time Multi-view Streaming in Tele-Immersive Scenarios)



Page 79 / 95

○ Definition of the relevant live metrics that will be reported by the vTranscoder3D functions as well as the integration of this functionality to the VNF.

○ Integrated support for day0, day1, etc. configuration of the vTranscoder3D VNF from the FaaS configuration service.

○ Conducted a thorough analysis of end-to-end 3D media streaming with various codecs (image and video for the textures and 3D for the geometry) and in various networking conditions to facilitate the optimization and refined design of the vTranscoder3D VNF and published an article with the results. (http://www.5gmedia.eu/outcomes/publication/ - Benchmarking Open-Source Static 3D Mesh Codecs for Immersive Media Interactive Live Streaming)

○ Various performance optimizations ○ Developed HW (GPU) accelerated video encoding support for the vTranscoder3D

VNF.

7.2.1.7.5G-MEDIA Gateway

The purpose of the 5G-MEDIA Gateway PNF is to convert incoming SDI signals from cameras or video servers to IP to make use of them inside the network or vice versa converting those signals back to SDI. Gateways are typically hardware appliances so IRT will make use of vendor solutions here as well.

Since the release of "D4.1 - 5G-MEDIA Catalogue APIs and Network Apps" the following updates were made:

Nevion Virtuoso

The Nevion Virtuoso IP production Platform is a software defined media node platform designed to meet the challenges of an IP-based live broadcast production environment. The platform runs virtualized media functions dependent of the user’s needs. The functions reach from encoding/decoding and transport protection to monitoring, and signal processing.

In our specific scenario the platform is used to packetize incoming SDI signals without any encoding and transmit them with the uncompressed bitrate of about 1,5 gbps per signal stream to the vCompression Engine where the compression/encoding for the WAN transfer is carried out (Section 7.2.1.2).

Its key features are:

• Software-based approach with license options ensures easy and future-proof upgrade path • Multi-format video and audio compression • Adaptation of SDI, ASI and audio signals • Fully standards-compliant IP media transport • Advanced audio/video processing • Content protection and encryption • High availability device and network redundancy • Simple integration in any IT/IP network infrastructure • Powerful monitoring and alarm handling



Page 80 / 95

• Virtuoso OS provides easy-to-use user interface for monitoring & control

Figure 43 – Nevion Virtuoso software-defined media node

7.2.1.8.UHD Streaming Server

The UHD Streaming Server PNF, also called Origin Server is the server where all media contents are stored. The application is based on the media server Plex62. It was presented in D4.1.

7.2.1.9.vBuffer

The vBuffer VNF is developed in order to facilitate the realization of the Replay functionality in UC1. In particular, the players’ 3D Streams are buffered in-memory in a sliding window buffer (i.e. a buffer that keeps data from the last X seconds of a game session). This is accomplished by vBuffer subscribing as a consumer to the game session’s 3D streams in vBroker. Upon a game highlight, i.e. a player score or a player hit game event, the Game Server triggers a command to vBuffer requesting it to flush the buffer in a temporary persistent topic in vBroker. Subsequently, the vBuffer’s flushed data is consumed by vReplay VNF to produce a complete 3D replay clip of the game highlight.

7.2.1.10.Image/Face Recognition

The Image/Face Recognition Engine is a media-specific function that recognizes Images/Faces within video material which is streamed via RTP, RTMP or RTSP protocol. As a result, this service provides computer vision specific metadata derived from the recognized Images/Faces. This metadata is either made available via websockets, rendered into the image and stored locally - these images can be combined to a video and stored locally - or transferred to FFmpeg as an image and made available as a video stream or pushed as messages into a given datastream. In the following the basic design and its parts will be represented.

62 Media Server Plex: http://www.plex.tv



Page 81 / 95

Figure 44 – Image/Face Recognition Engine: Design approach

Design

The Image/Face Recognition function is built up into 5 different main (grouped) parts, which are chained together and where each fulfils a particular task (see Figure 44). These are:

● Input: Describes the input source, which can be an RTP, RTMP or RTSP stream. Both UDP and TCP sockets are supported by its service. This service has 3 inputs and 2 outputs. Input 1 describes the input source in the sense of the original source. The original material is made available in images via output 2 for further processing. Input 2 is input 1 as loop, which is combined with input 3 (results of image-processing) for output 2 as base stream.

o Images from Output 1 (pipe2image) are passed on to Processing -> Metadata. o Video from Output 2 is passed on to Output.

● Processing -> Metadata: Each image is processed in the sense of object recognition (Image/Face). The resulting metadata is passed on for further processing.

o The metadata is made available via a websocket connection. o The metadata is passed on to Processing -> Create image. o The metadata is passed on to Processing -> Create video.

● Processing -> Create image/video: The image and metadata can be combined to a new image; based on the metadata rectangles and further information are rendered onto the image. This new image can be saved locally, combined to a new video and saved locally or passed on for further processing. The image passed to can be the original image (frame) or a transparent image with the dimensions of the original image.



Page 82 / 95

● Intermediate -> Switch: This service passes image material from two sources to two outputs. the two outputs are a temporary image in a repeating loop and the received image. at the two outputs one leads to the INPUT and the other to an output, which immediately rejects the image. This step is necessary because the processing services require time for processing, but input 3 of Input for output 2 is aborted if no input signal is present

● Output: To access the result of the Image processing (Image/Face Recognition) this service combines both input sources (original video with audio and the images as video) via overlay to keep the audio stream.

Configuration

To configure the function it needs at least the URLs of the input and output streams. Supported streams are RTP, RTMP and RTSP. Optional parameters concerns the service itself such as the video/image resolution, whether the metadata will be served via WebSocket or processed into images/video, the color of the metadata rendering, the selection of the algorithm and thresholds for image/face recognition. The following table shows all relevant parameters:

Table 21 – Image/Face recognition relevant configuration parameters

Parameter name Parameter description

APP_PORT port of vDetection

LOG_LEVEL_ENUM list of available log-levels

LOG_LEVEL log-level

SWAGGER_DOC_USE flag whether Swagger Doc is available via http://localhost:3145/doc/swagger

SWAGGER_UI_USE flag whether Swagger UI is available via http://localhost:3145

INPUT_SYNC_USE flag whether input synchronization is used (default: true)

INPUT_SYNC_ENUM_TYPES list of input synchronization types INPUT_SYNC_TYPE input synchronization type INPUT_SYNC_PROT input synchronization protocol INPUT_SYNC_HOST input synchronization host INPUT_SYNC_PORT input synchronization port INPUT_SYNC_BASE input synchronization base INPUT_SYNC_NAME input synchronization channel

name INPUT_SETTINGS_LOG_LEVEL_ENUM list of input log-levels INPUT_SETTINGS_LOG_LEVEL input log-level (default: quiet) INPUT_SETTINGS_FPS input frames per second *fps*

(default: 25) INPUT_SETTINGS_SCALE_USE flag whether scale resolution of



Page 83 / 95


input (default: false) INPUT_SETTINGS_SCALE_WIDTH scale width of input (default: -1) INPUT_SETTINGS_SCALE_HEIGHT scale height of input (default:

1080) INPUT_STREAM_SOURCE_PROT input source protocol INPUT_STREAM_SOURCE_HOST input source host INPUT_STREAM_SOURCE_PORT input source port INPUT_STREAM_SOURCE_BASE input source base INPUT_PIPE_SOURCE_PORT input source pipe port (default: 0) PROCESSING_SETTINGS_ENUM_TYPES list of processing types PROCESSING_SETTINGS_TYPE processing type (default: face-

recognition) PROCESSING_SETTINGS_ENUM_FPS list of processing fps PROCESSING_SETTINGS_FPS processing fps (default: 15) PROCESSING_DETECTION_CASCADE_CLASSIFIER_ENUM_TYPES list of processing detection

cascade classifier types PROCESSING_DETECTION_CASCADE_CLASSIFIER_TYPE processing detection cascade

classifier (default: HAAR_FRONTALFACE_ALT2)

PROCESSING_DETECTION_CONFIDENCE_MIN processing detection minimal confidence in percentage (default: 10, best and max: 100%)

PROCESSING_RECOGNITION_ASSETS_PATH path to folder with training set of images (default: assets/image)

PROCESSING_RECOGNITION_ASSETS_FILE_ENUM_TYPES list of file-extensions PROCESSING_RECOGNITION_ASSETS_FILE_TYPE file-extension to lookup (default:

jpg) PROCESSING_RECOGNITION_DISTANCE_MAX processing recognition maximal

distance (default: 200, best and min: 0)

PROCESSING_DRAWING_LINE_COLOR_R color code R of lines PROCESSING_DRAWING_LINE_COLOR_G color code G of lines PROCESSING_DRAWING_LINE_COLOR_B color code B of lines PROCESSING_DRAWING_LINE_THICKNESS thickness of lines PROCESSING_DRAWING_TEXT_COLOR_R color code R of text PROCESSING_DRAWING_TEXT_COLOR_G color code G of text PROCESSING_DRAWING_TEXT_COLOR_B color code B of text PROCESSING_DRAWING_TEXT_BACKGROUND_ALPHA alphacode of grey-background of

textbox OUTPUT_SYNC_USE flag whether output

synchronization is used (default: true)

OUTPUT_SYNC_ENUM_TYPES list of output synchronization



Page 84 / 95


types OUTPUT_SYNC_TYPE output synchronization type OUTPUT_SYNC_PROT output synchronization protocol OUTPUT_SYNC_HOST output synchronization host OUTPUT_SYNC_PORT output synchronization port OUTPUT_SYNC_BASE output synchronization base OUTPUT_SYNC_NAME output synchronization channel

name OUTPUT_SETTINGS_LOG_LEVEL_ENUM list of output log-levels OUTPUT_SETTINGS_LOG_LEVEL input log-level (default: quiet) OUTPUT_SETTINGS_IMAGE_ENUM_TYPES list of output image types OUTPUT_SETTINGS_IMAGE_TYPE output image type *frames*

(default: png), png will cause overlay and jpg will stack detection with original stream below

OUTPUT_SETTINGS_IMAGE_RESOLUTION_WIDTH output image resolution width (default: 1280)

OUTPUT_SETTINGS_IMAGE_RESOLUTION_HEIGHT output image resolution height (default: 720)

OUTPUT_SETTINGS_VIDEO_ENUM_TYPES list of output video types OUTPUT_SETTINGS_VIDEO_TYPE 4 character code of video type

(default: mp4v) OUTPUT_SETTINGS_VIDEO_RESOLUTION_WIDTH output video resolution width

(default: 1280) OUTPUT_SETTINGS_VIDEO_RESOLUTION_HEIGHT output video resolution height

(default: 720) OUTPUT_LOCAL_IMAGE_USE flag whether processing images

will be saved locally (default: false) OUTPUT_LOCAL_IMAGE_PATH path to save images OUTPUT_LOCAL_IMAGE_FILENAME file-name OUTPUT_LOCAL_IMAGE_FILEEXTENSION file-extension OUTPUT_LOCAL_VIDEO_USE flag whether processing images

will be saved locally as video (default: false)

OUTPUT_LOCAL_VIDEO_PATH path to save video OUTPUT_LOCAL_VIDEO_FILENAME file-name OUTPUT_LOCAL_VIDEO_FILEEXTENSION file-extension OUTPUT_SERVE_USE flag whether output video will be

served (default: true) OUTPUT_SERVE_FRMT FFmpeg format for flag `-f` OUTPUT_SERVE_PROT output serve protocol OUTPUT_SERVE_HOST output serve host OUTPUT_SERVE_PORT output serve port OUTPUT_SERVE_BASE output serve base



Page 85 / 95

The Image/Face Recognition function can be either configured via HTTP-REST-API or during instantiation via environmental variable injection. That means to configure the function by defining a specific file named .env or by using build-in commands, which are provided by the packaging technology (i.e. –e in case of Docker). Another option is to access the function via the user interface, which facilitates the configuration via REST-API. The Image/Face Recognition Engine can be reconfigured at runtime.

Interfaces

The REST-API, WebSocket and Webhooks interfaces are provided to configure, monitor and access the results of the Speech-to-Text inference. While the Webhooks and REST-API are based on the Hypertext Transfer Protocol (HTTP), WebSocket uses the TCP network protocol to establish bidirectional real-time data transmission between the Speech-to-Text Engine and other enhanced media services. As another option the Webhooks can be used as a real-time push interface. Once the URL of a remote host or service is configured on the Speech-to-Text Engine, the results as well as the monitoring data will be transferred remotely.

Table 22 -- Image/Face recognition API

# HTTP method

URI Description

1 POST /rest/detections/start Starts the image/face recognition with the given source

2 POST /rest/detections/stop Stops the image/face recognition

3 PUT /rest/detections/config Set configuration of image/face recognitions/detections at runtime

4 GET /rest/detections/info Get current configuration of image/face recognitions/detections

With the POST-requests’ configuration can be send as JSON object to override the default configuration, actually the following custom variables are supported:

Table 23 – Image/Face Recognition custom configuration as body in POST-requests

{

"config": {

"input": {

"source": {

"url": "rtmp://192.168.0.1:1935/live/stream"

}



Page 86 / 95

},

"processing": {

"settings": {

"fps": 10

}

},

"output": {

"settings": {

"image": {

"type": "png",

"width": 1280,

"height": 720

},

"video": {

"type": "mp4v",

"width": 1280,

"height": 720

}

},

"serve": {

"frmt": "rtp_mpegts",

"url": "rtp://192.168.0.1:5001/detection/demo"

}

}

}

}

For Development and testing purposes the Image/Face Recognition Engine can be started via Node or Docker with Swagger, an API-Documentation UI. Please disable Swagger and the Swagger-UI if not needed.

Packaging

The Image/Face Recognition Engine is packaged to the following formats:

• Docker: Build script included • Node: pm2 (processmanager) script included

Further Information

For further Information, please see the documentation of the Image/Face Recognition Engine in the README.md file on https://production.eng.it/gitlab/5G-MEDIA/vdetection



Page 87 / 95

7.2.1.11.vReplay

The vReplay VNF is responsible for zipping and packaging a 3D replay clip to be later be offered for on demand spectating. vReplay’s instantiation is triggered in a FaaS manner whenever the Game Server detects a game highlight in the running game session. When instantiated, the vReplay connects to vBroker to consume the buffered 3D streams of the player representations (flushed by vBuffer) as well as the game state stream, which is flushed to vBroker by the Game Server itself. The task of vReplay is to synchronize the 3D Stream with the Game State based on internal frame timestamps embedded inside the two kinds of streams. When synchronization is finished, vReplay packages the information to a suitable format for fast playback and stores the final 3D replay clip in a persistent topic of vBroker. Upon task completion, a notification is sent to the Game Server via vBroker and subsequently the spectators of the game are notified that the new replay clip is ready to watch on demand.

7.2.1.12.vBrocker

vBroker is a VNF packaging a Kafka broker as a serverless OpenWhisk (OW) action that is deployed on a per session basis and act as the 3D stream traffic broker for all spectators of a particular 3D media session. vBroker also acts as as an intermediate to establish communications between different components of UC1 (vBuffer, vReplay, Game Server). Finally, vBroker also acts as a repository of 3D replay clips which can be consumed on demand by the spectators of a game session.

7.2.1.13.vUnpacker

The vUnpacker is a VNF that enables the support of UDP protocol and the IP SMPTE standard ST2110. This VNF is based on a modification of the open-source tool FFmpeg provided by Canadian Broadcasting Corporation63 allowing the decoding of RTP 2110 video over IP, creating a regular TCP workflow in the output for the rest of VNFs.

63 https://github.com/cbcrc/FFmpeg



Page 88 / 95

8. Conclusions

In this deliverable, the final release of Public Catalogue is provided, providing as well the specifications and manual of the Catalogue Portal.

It has been also presented the interfaces needed to communicate to and from the catalogue towards other components of the platform. Another important topic presented is the policies of Authentication, Authorization and Accounting, which represent a security framework based on the role of each user. Additionally, the implementation of the billing system is depicted.

Also, it is mentioned as the main innovation, the ability of the catalogue to work with different solutions, basing the design on an ETSI compliant way, and proposing it as a general solution, compatible with multiple MANOs and VIMs.

Finally, the final set of generic network applications and media-specific applications are presented, providing a detailed description of its features and behaviours.



Page 89 / 95

9. References

[1] Deliverable D3.4, “5G-MEDIA Operations and Configuration Platform”, 5G-MEDIA Consortium, November 2019.

[2] (Draft) Deliverable D6.2, “5G-MEDIA Immersive Media Pilot”, 5G-MEDIA Consortium, February 2020. [3] (Draft) Deliverable D6.3, “5G-MEDIA Mobile Contribution, Remote and Smart Production Pilot”, 5G-

MEDIA Consortium, February 2020. [4] (Draft) Deliverable D6.4, “5G-MEDIA High Demanding UHD over Open CDNs Pilot”, 5G-MEDIA

Consortium, February 2020. [5] Deliverable D2.3, “5G-MEDIA Platform Architecture”, 5G-MEDIA Consortium, August 2018. [6] Deliverable D4.1, “5G-MEDIA Catalogue APIs and Network Apps”, 5G-MEDIA Consortium, August

2018. [7] ETSI GS NFV-SOL 001 v2.5.1, “Protocols and Data Models; NFV descriptors based on TOSCA

specification”, ETSI NFV ISG, December 2018. [8] ETSI GS NFV-SOL 004 v2.5.1, “Protocols and Data Models; VNF Package specification”, ETSI NFV ISG,

September 2018. [9] ETSI GS NFV-SOL 005 v2.4.1, “Protocols and Data Models; RESTful protocols specification for the Os-

Ma-nfvo Reference Point”, ETSI NFV ISG, February 2018. [10] ETSI GS NFV-IFA 013 v2.1.1, “Management and Orchestration; Os-Ma-Nfvo reference point –

Interface and Information Model Specification”, ETSI NFV ISG, October 2016. [11] ETSI TS 182 028, v3.5.1, “Telecommunications and Internet converged Services and Protocols for

Advanced Networking (TISPAN); NGN integrated IPTV subsystem Architecture”, ETSI TISPAN 02, February 2011.

[12] Economics and technologies for inter-carrier services, EU FP7 Project ETICS [13] Deliverable D5.2, “API Development by using Serverless Computing Framework”, 5G-MEDIA

Consortium, November 2019. [14] A. Doumanoglou et al., “Quality of Experience for 3D Immersive Media Streaming,” IEEE Trans.

Broadcast., vol. 64, issue 2, pp. 379-391, Jun. 2018. [15] ITU-T P.910, “Subjective video quality assessment methods for multimedia applications”, ITU

Telecommunication Standardization Sector, April 2008. [16] Pech-Pacheco et al. “Diatom autofocusing in brightfield microscopy: A comparative study”,

Proceedings 15th International Conference on Pattern Recognition. ICPR-2000, September 2000. [17] Deliverable D2.2, “5G-MEDIA Requirements and Use Case Refinement”, 5G-MEDIA Consortium, April

2018.



Page 90 / 95

Annex I – Intra-OSM Kafka bus notification samples for the LCM Operations

LCM Operation Type Sample Message

instantiate (start)

_admin: created: 1545062732.5816464 modified: 1545062732.5816464 _id: 08f4b767-ccdb-49fa-bf3f-468fbef93ffe id: 08f4b767-ccdb-49fa-bf3f-468fbef93ffe isAutomaticInvocation: false isCancelPending: false lcmOperationType: instantiate links: nsInstance: /osm/nslcm/v1/ns_instances/2c80ff71-1781-42c2-a438-9f6c2826be26 self: /osm/nslcm/v1/ns_lcm_op_occs/08f4b767-ccdb-49fa-bf3f-468fbef93ffe nsInstanceId: 2c80ff71-1781-42c2-a438-9f6c2826be26 operationParams: _id: 08f4b767-ccdb-49fa-bf3f-468fbef93ffe nsDescription: Test nsInstanceId: 2c80ff71-1781-42c2-a438-9f6c2826be26 nsName: kostas_test_0001 nsdId: d5c99561-ec46-4480-8377-b5b218b8b1e5 nsr_id: 2c80ff71-1781-42c2-a438-9f6c2826be26 vimAccountId: 41dab0c0-35f4-4c40-b1cd-13e4a79dab48 operationState: PROCESSING startTime: 1545062732.581603 statusEnteredTime: 1545062732.581603

instantiate (end)

nslcmop_id: 08f4b767-ccdb-49fa-bf3f-468fbef93ffe nsr_id: 2c80ff71-1781-42c2-a438-9f6c2826be26 operationState: COMPLETED

terminate (start)

_admin: created: 1545062761.5119748 modified: 1545062761.5119748 _id: 37c76074-c7cb-4966-aff7-edfc4cee6782 id: 37c76074-c7cb-4966-aff7-edfc4cee6782 isAutomaticInvocation: false isCancelPending: false, lcmOperationType: terminate links: nsInstance: /osm/nslcm/v1/ns_instances/2c80ff71-1781-42c2-a438-9f6c2826be26 self: /osm/nslcm/v1/ns_lcm_op_occs/37c76074-c7cb-4966-aff7-edfc4cee6782 nsInstanceId: 2c80ff71-1781-42c2-a438-9f6c2826be26, operationParams: _id: 37c76074-c7cb-4966-aff7-edfc4cee6782 autoremove: true nsInstanceId: 2c80ff71-1781-42c2-a438-9f6c2826be26 operationState: PROCESSING startTime: 1545062761.5119283 statusEnteredTime: 1545062761.5119283

terminate (end)

nslcmop_id: 37c76074-c7cb-4966-aff7-edfc4cee6782 nsr_id: 2c80ff71-1781-42c2-a438-9f6c2826be26 operationState: COMPLETED



Page 91 / 95

LCM Operation Type Sample Message

scale (scale out start)

{ "_id": "f375c679-42a8-46e2-9730-a6531c38e2ef", "operationState": "PROCESSING", "id": "f375c679-42a8-46e2-9730-a6531c38e2ef", "operationParams": { "scaleVnfData": { "scaleVnfType": "SCALE_OUT", "scaleByStepData": { "scaling-group-descriptor": "scale_by_one", "member-vnf-index": "2" } }, "scaleType": "SCALE_VNF", "nsInstanceId": "efd548ab-4d1a-44da-b530-1a45f0f56074", "lcmOperationType": "scale" }, "lcmOperationType": "scale", "links": { "nsInstance": "/osm/nslcm/v1/ns_instances/efd548ab-4d1a-44da-b530-1a45f0f56074", "self": "/osm/nslcm/v1/ns_lcm_op_occs/f375c679-42a8-46e2-9730-a6531c38e2ef" }, "isAutomaticInvocation": "False", "statusEnteredTime": 1556175459.4643524, "nsInstanceId": "efd548ab-4d1a-44da-b530-1a45f0f56074", "isCancelPending": "False", "startTime": 1556175459.4643524, "_admin": { "projects_write": [ "admin" ], "created": 1556175459.4645183, "projects_read": [ "admin" ], "modified": 1556175459.4645183 } }

scale (scale out end)

{ "operationState": "COMPLETED", "nslcmop_id": "f375c679-42a8-46e2-9730-a6531c38e2ef", "nsr_id": "efd548ab-4d1a-44da-b530-1a45f0f56074" }

scale (scale in start)

{ "_id": "062601b3-4108-4918-b3ac-ff73e9185bcc", "operationState": "PROCESSING", "id": "062601b3-4108-4918-b3ac-ff73e9185bcc", "operationParams": { "scaleVnfData": { "scaleVnfType": "SCALE_IN", "scaleByStepData": { "scaling-group-descriptor": "scale_by_one", "member-vnf-index": "2" } },



Page 92 / 95

LCM Operation Type Sample Message "scaleType": "SCALE_VNF", "nsInstanceId": "efd548ab-4d1a-44da-b530-1a45f0f56074", "lcmOperationType": "scale" }, "lcmOperationType": "scale", "links": { "nsInstance": "/osm/nslcm/v1/ns_instances/efd548ab-4d1a-44da-b530-1a45f0f56074", "self": "/osm/nslcm/v1/ns_lcm_op_occs/062601b3-4108-4918-b3ac-ff73e9185bcc" }, "isAutomaticInvocation": "False", "statusEnteredTime": 1556175170.0867147, "nsInstanceId": "efd548ab-4d1a-44da-b530-1a45f0f56074", "isCancelPending": "False", "startTime": 1556175170.0867147, "_admin": { "projects_write": [ "admin" ], "created": 1556175170.0868711, "projects_read": [ "admin" ], "modified": 1556175170.0868711 } }

scale (scale in end)

{ "operationState": "COMPLETED", "nslcmop_id": "062601b3-4108-4918-b3ac-ff73e9185bcc", "nsr_id": "efd548ab-4d1a-44da-b530-1a45f0f56074" }



Page 93 / 95

Annex II – NSD and VNF Package Management Operations

NSD Management Operations


Create NSD resource

POST /nsd/v1/ns_descriptors Cf. ETSI NFV SOL005 v2.4.1 Sec. 5.4 for resource description

Query NSDs GET /nsd/v1/ns_descriptors Cf. ETSI NFV SOL005 v2.4.1 Sec. 5.4 for resource description

Query NSD GET /nsd/v1/ns_descriptors/{nsdInfoId} Cf. ETSI NFV SOL005 v2.4.1 Sec. 5.4 for resource description

Delete NSD DELETE /nsd/v1/ns_descriptors/{nsdInfoId} Cf. ETSI NFV SOL005 v2.4.1 Sec. 5.4 for resource description

Modify NSD PATCH /nsd/v1/ns_descriptors/{nsdInfoId} Cf. ETSI NFV SOL005 v2.4.1 Sec. 5.4 for resource description

Fetch NSD content

GET /nsd/v1/ns_descriptors/{nsdInfoId}/nsd_content Cf. ETSI NFV SOL005 v2.4.1 Sec. 5.4 for resource description

Upload NSD content

PUT /nsd/v1/ns_descriptors/{nsdInfoId}/nsd_content Cf. ETSI NFV SOL005 v2.4.1 Sec. 5.4 for resource description

Create PNFD resource

POST /nsd/v1/pnf_descriptors Cf. ETSI NFV SOL005 v2.4.1 Sec. 5.4 for resource description

Query PNFDs GET /nsd/v1/pnf_descriptors Cf. ETSI NFV SOL005 v2.4.1 Sec. 5.4 for resource description

Query PNFD GET /nsd/v1/pnf_descriptors/{pnfdInfoId} Cf. ETSI NFV SOL005 v2.4.1 Sec. 5.4 for resource description

Delete PNFD DELETE /nsd/v1/pnf_descriptors/{pnfdInfoId} Cf. ETSI NFV SOL005 v2.4.1 Sec. 5.4 for resource description

Modify PNFD PATCH /nsd/v1/pnf_descriptors/{pnfdInfoId} Cf. ETSI NFV SOL005 v2.4.1 Sec. 5.4 for resource description

Fetch PNFD content

GET /nsd/v1/pnf_descriptors/{pnfdInfoId}/pnfd_content Cf. ETSI NFV SOL005 v2.4.1 Sec. 5.4 for resource description

Upload PNFD PUT /nsd/v1/pnf_descriptors/{pnfdInfoId}/pnfd_content Cf. ETSI NFV SOL005



Page 94 / 95


content v2.4.1 Sec. 5.4 for resource description

Subscribe POST /nsd/v1/subscriptions Cf. ETSI NFV SOL005 v2.4.1 Sec. 5.4 for resource description

Query subscriptions

GET /nsd/v1/subscriptions Cf. ETSI NFV SOL005 v2.4.1 Sec. 5.4 for resource description

Query individual subscriptions

GET /nsd/v1/subscriptions/{subscriptionId} Cf. ETSI NFV SOL005 v2.4.1 Sec. 5.4 for resource description

Delete individual subscription

DELETE /nsd/v1/subscriptions/{subscriptionId} Cf. ETSI NFV SOL005 v2.4.1 Sec. 5.4 for resource description

VNF Package Management Operations

Operation HTTP Method

URI Description

Create VNF Package resource

POST /vnfpkgm/v1/vnf_packages Cf. ETSI NFV SOL005 v2.4.1 Sec. 9.4 for resource description

Query VNF Packages

GET /vnfpkgm/v1/vnf_packages Cf. ETSI NFV SOL005 v2.4.1 Sec. 9.4 for resource description

Query VNF Package

GET /vnfpkgm/v1/vnf_packages/{vnfPkgId} Cf. ETSI NFV SOL005 v2.4.1 Sec. 9.4 for resource description

Delete VNF Package

DELETE /vnfpkgm/v1/v vnf_packages/{vnfPkgId} Cf. ETSI NFV SOL005 v2.4.1 Sec. 9.4 for resource description

Update VNF Package

PATCH /vnfpkgm/v1/vnf_packages/{vnfPkgId} Cf. ETSI NFV SOL005 v2.4.1 Sec. 9.4 for resource description



Page 95 / 95

Operation HTTP Method

URI Description

Query VNFD GET /vnfpkgm/v1/vnf_packages/{vnfPkgId}/vnfd Cf. ETSI NFV SOL005 v2.4.1 Sec. 9.4 for resource description

Fetch VNF Package content

GET /vnfpkgm/v1/vnf_packages/{vnfPkgId}/package_content Cf. ETSI NFV SOL005 v2.4.1 Sec. 9.4 for resource description

Upload VNF Package content

PUT /vnfpkgm/v1/vnf_packages/{vnfPkgId}/package_content Cf. ETSI NFV SOL005 v2.4.1 Sec. 9.4 for resource description

Upload VNF Package from URI

POST /vnfpkgm/v1/vnf_packages/{vnfPkgId}/package_content/upload_from_uri

Cf. ETSI NFV SOL005 v2.4.1 Sec. 9.4 for resource description

Fetch VNF Package artifact

GET /vnfpkgm/v1/vnf_packages/{vnfPkgId}/artifacts/{artifactPath}


Subscribe POST /vnfpkgm/v1/subscriptions Cf. ETSI NFV SOL005 v2.4.1 Sec. 9.4 for resource description

Query subscriptions

GET /vnfpkgm/v1/subscriptions Cf. ETSI NFV SOL005 v2.4.1 Sec. 9.4 for resource description

Query individual subscription

GET /vnfpkgm/v1/{subscriptionId}


Delete individual subscription

DELETE /vnfpkgm/v1/{subscriptionId} Cf. ETSI NFV SOL005 v2.4.1 Sec. 9.4 for resource description

Programmable edge-to-cloud virtualization fabric for the ...

Documents