Theodore Giannakopoulos

Evaggelos Spyrou
email: espyrou@iit.demokritos.gr

Stavros J Perantonis

Recognition of urban sound events using deep context-aware feature extractors and handcrafted features

Keywords: Soundscape classification, Context-aware feature extractors, Convolutional Neural Networks

This paper proposes a method for recognizing audio events in urban environments that combines handcrafted audio features with a deep learning architectural scheme (Convolutional Neural Networks, CNNs), which has been trained to distinguish between different audio context classes. The core idea is to use the CNNs as a method to extract context-aware deep audio features that can offer supplementary feature representations to any soundscape analysis classification task. Towards this end, the CNN is trained on a database of audio samples which are annotated in terms of their respective "scene" (e.g. train, street, park), and then it is combined with handcrafted audio features in an early fusion approach, in order to recognize the audio event of an unknown audio recording. Detailed experimentation proves that the proposed contextaware deep learning scheme, when combined with the typical handcrafted features, leads to a significant performance boosting in terms of classification accuracy. The main contribution of this work is the demonstration that transferring audio contextual knowledge using CNNs as feature extractors can significantly improve the performance of the audio classifier, without need for CNN training (a rather demanding process that requires huge datasets and complex data augmentation procedures).

Introduction

Soundscape audio recordings capture the sonic environment of a particular time and location and it can be conceived as an "auditory landscape", either in an individual or common level. With the advances in audio signal processing and machine learning, it has become possible to automatically predict the content, the context [START_REF] Khunarsal | Very short time environmental sound classification based on spectrogram pattern matching[END_REF][START_REF] Ye | Urban sound event classification based on local and global features aggregation[END_REF][START_REF] Huzaifah | Comparison of time-frequency representations for environmental sound classification using convolutional neural networks[END_REF][START_REF] Thorogood | Soundscape audio signal classification and segmentation using listeners perception of background and foreground sound[END_REF] and even the quality [START_REF] Giannakopoulos | Automatic soundscape quality estimation using audio analysis[END_REF] of the soundscape recordings. Automatic recognition of soundscapes is rather important in many emerging applications, such as surveillance, urban soundscape monitoring and noise source identification.

An important problem in automatic soundscape classification is the diversity between different datasets and benchmarks, in terms of class taxonomy, dataset size and audio signal quality. In this work, we utilize the ability of deep neural networks to learn patterns in large datasets, capturing both spectral and temporal relations in audio signals. Towards this end, a deep learning network architecture is trained to distinguish between contextual classes (e.g., park, restaurant, library, metro station, etc). Then, this network is used as a supervised audio feature extractor in an urban classification task of urban audio events and in combination with handcrafted audio features. Extensive experimentation proves that this transfer of knowledge from an audio context domain, using deep neural networks, can boost the performance of the soundscape classification procedure, when handcrafted features are combined with the deep context-aware features.

The main contribution of this work is the experimental proof that audio contextual knowledge can be "transferred" through a CNN, which is trained in a scene-specific dataset, and that this scheme can be used to boost the performance of audio event classification based on typical handcrafted audio features. This has been experimentally demonstrated using two widely adopted benchmarks, even with a baseline classification approach and a standard early-fusion feature combination scheme.

General Scheme

As illustrated in the general conceptual diagram of Figure 1, we propose classifying unknown soundscape recordings using two distinct feature representation steps:

-Handcrafted audio Features (HaF) According to this widely-adopted approach, each signal is represented by a series of statistics computed over short-term audio features, either from the time or the frequency domain, such as signal energy, zero crossing rate and the spectral centroid. These features aim to represent the audio signal in a space that is discriminative with regards to the involved audio classes. This baseline audio representation methodology is described in more detail in Section 3. -Context-aware deep Features (CadF) A supervised convolutional neural network is trained to discriminate between different audio urban context classes (such as park, restaurant, etc), based on spectrograms of short-term segments. The output of the last fully connected layer of this network is used as feature extractor in the initial soundscape classification task. This methodology is described in detail in Section 4.

The two different audio feature representations are then combined in an earlyfusion scheme and classified using a standard Support Vector Machine classifier. The main idea behind this feature combination procedure is the fact that the Context-aware deep Features (CadF) are extracted based on a deep neural network that has been trained to distinguish between different context classes and can therefore introduce a diverse and complementary content representation to the Handcrafted audio Features (HaF). In various machine learning applications, it has been proven that combining diverse and complementary features (or individual classification decisions) in meta-classification schemes, leads to classification performance boosting [START_REF] Kuncheva | Measures of diversity in classifier ensembles and their relationship with the ensemble accuracy[END_REF]. This is also proven experimentally in this work, as described later in the experiments section.

Audio classification based on handcrafted audio features

As a baseline methodology of automatic characterization of audio segments, a short-term feature extraction workflow of widely-adopted handcrafted audio features has been adopted. Traditional audio classification, regression and segmentation utilizes handcrafted features in order to represent the corresponding audio signals in a feature space that is able to discriminate an unknown sample between the involved audio classes. This process of extracting features from the initial audio signal is therefore essential in all audio analysis methodologies.

In order to achieve audio feature extraction, each audio signal is first divided to either overlapping or non-overlapping short-term windows (frames). Widely accepted short-term window sizes are 20 to 100 ms. Additionally, a widely adopted methodology in audio analysis is the processing of the feature sequence on a "mid-term basis", according to which the audio signal is first divided into mid-term windows (segments), which can be either overlapping or non-overlapping. For each segment, the short-term processing process, described above, is carried out and the feature sequence from each mid-term segment, is used for computing feature statistics (e.g. the average value of the zero crossing rate). Therefore, each mid-term segment is represented by a set of statistics. Typical values of the mid-term segment size can be 1 to 10 seconds [START_REF] Giannakopoulos | Introduction to Audio Analysis: A MATLAB R Approach[END_REF], [START_REF] Hyoung-Gook | MPEG-7 Audio and Beyond: Audio Content Indexing and Retrieval[END_REF], [START_REF] Theodoridis | Pattern Recognition, Fourth Edition[END_REF].

Table 1 shows the adopted handcrafted audio features. In this work, two midterm statistics have been adopted, namely the average value and the standard deviation of the respective short-term features. This means that the final signal representation using these handcrafted feature statistics is a 34 × 2 = 68 feature vector. The pyAudioAnalysis library has been adopted for implementing these audio features [START_REF] Giannakopoulos | pyaudioanalysis: An open-source python library for audio signal analysis[END_REF]. Each unknown audio file is therefore represented using the aforementioned procedure and it is classified using a Support Vector Machine classifier with an RBF kernel. More details on the classification scheme of the handcrafted audio features are given in the experiments section. pyAudioAnalysis has been widely used in several audio classification tasks in the bibliography (e.g., [START_REF] Subramaniam | Bimodal first impressions recognition using temporally ordered deep audio and stochastic visual features[END_REF][START_REF] Mesaros | Dcase 2017 challenge setup: Tasks, datasets and baseline system[END_REF]) and it implements most basic audio features. In addition, in this paper it has been chosen for its Pythonic implementation that makes it easier to combine with the deep learning -related experiments implemented in Keras and Tensorflow.

4 Context-aware deep learning

Convolutional neural networks

As with most machine learning application domains, audio analysis has significantly benefited by the recent advances that deep learning has offered. Most of the research efforts towards this direction have focused on employing audio features in deep learning schemes for speech recognition [START_REF] Hinton | Deep neural networks for acoustic modeling in speech recognition: The shared views of four research groups[END_REF][START_REF] Dahl | Context-dependent pre-trained deep neural networks for large-vocabulary speech recognition[END_REF], generic audio analysis [START_REF] Lee | Unsupervised feature learning for audio classification using convolutional deep belief networks[END_REF] and music classification [START_REF] Scardapane | Music classification using extreme learning machines[END_REF]. Also, inspired by the outstanding results of convolutional neural networks (CNNs) in image classification [START_REF] Krizhevsky | Imagenet classification with deep convolutional neural networks[END_REF], a few research efforts have also focused on particular audio analysis tasks by representing the audio signal as a 2-D time-frequency representation, mainly for musical signal analysis applications [START_REF] Schlüter | Musical onset detection with convolutional neural networks[END_REF]24,[START_REF] Grill | Music boundary detection using neural networks on spectrograms and self-similarity lag matrices[END_REF][START_REF] Choi | Explaining deep convolutional neural networks on music classification[END_REF][START_REF] Zhang | A deep representation for invariance and music classification[END_REF] and speech emotion recognition [START_REF] Huang | Speech emotion recognition using cnn[END_REF]. In general, such deep-architectures and especially deep CNNs are well known for their ability to autonomously learn highly-invariant feature representations, extracted from complex images.

CNNs have been widely adopted as deep architectures. They are actually a subcategory of traditional neural-networks (ANNs). However, in CNNs, (convolutional) neurons in one or more layers are applied to a small "region" of the layer input, emulating the response of an individual neuron to visual stimuli. These layers are called convolutional and are usually deployed in the beginning of the architectural scheme. CNNs in general use one or more convolutional layers, usually followed by a subsampling step and at the end by one or more fully connected layers, similar to the ones used in traditional multilayer neural networks. CNNs have been proven to achieve the training of computationally large model with very robust feature representations especially in difficult multi-class image classification tasks.

Context-aware deep audio feature extractors

Signal representation In this work, we propose using CNNs as estimators of contextual audio classes. Towards this end, instead of using handcrafted audio features, the audio signal is first represented by its spectrogram: in particular, a Short-Term FFT (applied on the hanning-windowed version of each raw audio signal) is used to estimate the audio signal's spectrum, using a short-term win-dow of 20 ms with 50% overlap (i.e. the short-term window's size is 10 ms). It has to be noted, that before the spectrogram calculation, the signal is resampled to 16KHz and stereo signals are converted to single-channel. In addition, after the spectrogram calculation, only the first 100 frequency bins are kept. Since each short-term window is 20 ms long, this actually means that only frequencies up to 5000 Hz are kept, i.e. 62.5% of the total spectral distribution. The spectrogram process calculation is performed for each 200 ms mid-term segment. Therefore, for each individual audio segment the respective time-frequency spectrogram representation corresponds to an image of 19 × 100 resolution. Figure 2 illustrates the adopted process that leads to the signal representation used by the convolutional neural network. Each individual 19 × 100 spectrogram representation (corresponding to a 200 mseconds segment) is fed as input to the context-aware CNN described in the next section. 3, the convolutional neural network that is trained to recognize audio context classes has first a convolutional layer that takes the initial spectrogram image (19x100) and uses 64 convolutional nodes (3x3 each). This is also followed by a batch normalization and a RELU activation stage [START_REF] Schmidhuber | Deep learning in neural networks: An overview[END_REF]. Then a similar 2nd convolutional layer is used with the same number of nodes, followed by a maxpooling and a dropout step. Maxpooling is actually a sub-sampling layer that changes the resolution of its input, in order to facilitate the discovery of more abstract features and avoid overfitting. In this architecture, maxpooling size is set equal to 1x2, in order to only subsample the representation dimensions that correspond to the frequency domain. Dropout layers are used in an additional effort to avoid overfitting [START_REF] Srivastava | Dropout: a simple way to prevent neural networks from overfitting[END_REF]. According to the dropout technique, at each training stage, individual nodes are "dropped out" of the net with a particular probability. Incoming and outgoing edges to a dropped-out node are also removed. Dropout is set equal to 0.2 in our system.

The group of these two convolutional layers and the maxpooling layer is then repeated at a second group of layers. Finally, a fully connected (dense) layer that maps the (flat) representation is generated by the last pooling layer to a highdimensional (512) flat representation. The final output of the network is the prediction of the adopted audio scene classes as described in the sequel. The adopted CNN architectural scheme has resulted after a parameter optimization procedure where the number of convolutional layers, the number of convolutional neurons at each layer and the size of the dense layer have been used as parameters, where performance measures from the TUT dataset have been used (not the final evaluation datasets).

CNN training procedure In this work, it is our goal to extract audio contextaware knowledge through the utilization of a CNN that has been trained to distinguish between acoustic scene classes. Towards this end, the aforementioned network has been trained using the TUT Acoustic scene classification dataset [START_REF] Mesaros | Tut database for acoustic scene classification and sound event detection[END_REF]. This is a widely adopted benchmark of almost 5000 audio segments of 10 seconds each. The segments have been annotated to 15 scene classes that describe the recording context such as: bus, car, city center, home, metro station, residential area, train etc.. The adopted CNN scheme has been trained on several non-overlapping 200-mseconds spectrograms of the aforementioned audio segments of the TUT dataset. In total, around 200 thousand spectrograms have been used to train the CNN. The resulting CNN is used as a feature extractor, i.e. the last output layer is omitted in the overall system.

Both the network and the training procedure has been implemented using the Tensorflow [START_REF] Abadi | Tensorflow: Large-scale machine learning on heterogeneous distributed systems[END_REF] and Keras (keras.io) frameworks. The training procedure has been carried out in a Linux workstation equipped with a Tesla K40c GPU, which achieved a 15x speed boosting, compared to the CPU-based training procedure.

Using CNN as a feature extractor As soon as the CNN is trained as described above, the input values of its last dense layer (i.e. the 512 values of the respective fully connected layer) are adopted as deep features for each 0.2 seconds audio segment. These 512 feature sequences are then used to produce long-term averages. Note, that this corresponds to the statistic calculation substage of the handcrafted feature extraction described in Section 3. However, in the case of the CNN-based feature extractor, only means of the short-term features are extracted, due to the fact that the CNN training phase has also taken into consideration the temporal evolution of the audio signal (through one of the two dimensions of the spectrogram), so there is no obvious need for further using standard deviation or some other statistic, apart from the mean value.

Therefore, during the audio event recognition phase, each audio recording is represented by 512 averages of the respective 512 short-term sequences of the deep context-aware features. Finally, these 512 features are merged with the 68 2. Classification accuracy for all audio feature methods: baseline, handcrafted audio features, context-aware deep features and combination. The performance boosting offered by the combination classification method has been found to be statistically significant (p < 0.05) handcrafted audio feature statistics, leading to a early fusion feature vector of 580 dimensions in total, for each audio recording.

Experimental evaluation

Sound Event Datasets

The TUT dataset described in Section 4.2 has been used to train the adopted CNN scheme to distinguish between audio scenes that characterize the "context" of the audio signal. In order to evaluate the performance of the final classification approach, two audio event datasets have been utilized:

-The Urban Soundcape Dataset 8K (U-8K) [START_REF] Salamon | A dataset and taxonomy for urban sound research[END_REF], contains 8732 labeled sound excerpts (all less or equal to 4s of length) of urban sounds from 10 audio event classes: air conditioner, car horn, children playing, dog bark, drilling, engine idling, gun shot, jackhammer, siren, and street music. The average classification accuracy obtained is 68% for the baseline audio classification method.

-The ESC-50 dataset [START_REF] Piczak | Esc: Dataset for environmental sound classification[END_REF] has also been used in various audio classification papers as a benchmark. This is a public labeled dataset of 2000 environmental recordings with 50 audio event classes, 40 sound files per class, 5 seconds per file. The number of classes is much higher in this dataset, therefore the classification accuracy of the reported baseline method is around 44%.

Experimental Results

Table 2 presents the classification results for all three methods on both datasets: baseline (BL, as described in the corresponding dataset descriptions, i.e., [START_REF] Salamon | A dataset and taxonomy for urban sound research[END_REF] and [START_REF] Piczak | Esc: Dataset for environmental sound classification[END_REF]), Handcrafted audio features (HaF), context-aware deep features (CadF) and combination (HaF + CadF). Note that the HaF results correspond to a tuning procedure in terms of short-term window size and step. The best performance has been reported for a 40 msec frame of 50% overlap (i.e. 20 msec step) and a non-overlapping 2-second segment size. The C parameter of the SVM classifier has been selected in the context of a cross-validation pipeline from the range 0.01 to 50. The selected C value was 10 for both tasks and the respective training errors were 65% and 82% which does not indicate a significant overfitting state. Also, it has to be noted that melgrams have also been evaluated as an alternative signal representation method and they did not lead to performance improvement (they were on average 1% less accurate for both methods).

It can be seen that the HaF method slightly outperforms the CadF feature extraction approach, however the two feature methodologies combined lead to a relative performance boosting of 11% and 5% for the ESC50 and the U-8K datasets respectively. This performance boosting, despite the fact that the CadF method alone hardly outperforms the baseline approach, is a rather important finding. Note that all classification results presented here are for the best Support Vector Machine classifier, with a RBF kernel, where the C parameter has been tuned in a cross-validation procedure. Other widely used classifiers such as random forests and extra trees have been also evaluated but achieved lower classification rates, when used both in the individual feature representation feature methods and in their combinations.

The goal of this paper is to demonstrate the ability of the "context-aware" CNNs to provide an alternative feature representation that boosts the performance of handcrafted audio features. The aforementioned results prove that, even with a baseline classification and fusion approach the combination of the two feature representation methodologies lead to significant performance boosting. Despite the fact that a simple workflow has been used in the classification stage, the overall method achieves comparable results for the U-8K dataset (74% in [START_REF] Piczak | Environmental sound classification with convolutional neural networks[END_REF] and 75% in [START_REF] Huzaifah | Comparison of time-frequency representations for environmental sound classification using convolutional neural networks[END_REF]), even if such methods adopt complex deep learning classification schemes that usually require laborious data augmentation procedures and respective parameter tuning [START_REF] Salamon | Deep convolutional neural networks and data augmentation for environmental sound classification[END_REF].

Conclusions

In this paper we have demonstrated the utilization of Convolutional Neural Networks that have been trained to distinguish between acoustic scene (context) classes, in a framework for classifying urban audio events. Towards this end, handcrafted audio features as well as features extracted from the proposed CNN are combined in an early fusion approach and classified using a baseline classifier.

Extensive experimentation has proven that this combination leads to a relative performance boosting of up to 11%, despite the fact that the performance of the CNN-generated features alone is hardly baseline-equivalent. This is due to the fact that the CNN introduces highly diverse representation, which is not modelled in the handcrafted features.

The contribution of this work is focused in the fact that it experimentally proves that the transfer of contextual knowledge using a CNN trained in a scenespecific dataset can lead to significant performance boosting when combined with typical handcrafted (manually designed) audio features. However, this performance boosting has been demonstrated using a very simple classification scheme (i.e. SVMs performed on simple long-term feature statistics). Our ongoing and future work aims to combine this contextual knowledge in the context of a deep learning framework that will replace the simple feature merging (early fusion) and the (meta)classification technique adopted in this paper.

Fig. 1 .

 1 Fig. 1. Conceptual diagram of the proposed method. Two separate steps are adopted during in the analysis pipeline: hand-crafted-audio features are computed on the raw signal, as well as a supervised CNN trained to distinguish between different context classes is used as a feature extractor.

Fig. 2 .

 2 Fig. 2. Signal representation adopted in the deep learning scheme: each 19 × 100 spectrogram representation (corresponding to a 200 mseconds segment) is fed as input to the context-aware CNN model

Fig. 3 .

 3 Fig. 3. Adopted CNN architecture. In general, two groups of two convolutional layers are used. Each convolutional layer has 64 nodes, while after each group a maxpooling procedure is applied. The final dense layer has 512 nodes

Table 1 .

 1 Chroma Vector A 12-element representation of the spectral energy using a semitone spacing 34 Chroma Deviation Standard deviation of the 12 chroma coefficients Handcrafted short-term audio features. In total, 34 audio features extracted from the time, spectral and cepstral domains are computed per short-term frame. This leads to a series of 34-dimensional feature vectors for each audio segment. At a second stage segment-level statistics (mean and standard deviation) are computed for the whole audio segment, leading to a 68-dimensional representation.

	Index	Name	Description
	1 Zero Crossing Rate Rate of sign-changes of the signal during the duration of a particular frame
	2	Energy	(normalized) sum of squares of the signal values
	3 Entropy of Energy Entropy of sub-frames' normalized energies
	4	Spectral Centroid Center of gravity of the spectrum
	5	Spectral Spread Second central moment of the spectrum
	6	Spectral Entropy Entropy of the normalized spectral energies for a set of sub-frames
	7	Spectral Flux	Squared diffs between the normalized magnitudes of the spectra of the two successive frames
	8	Spectral Rolloff Frequency below which 90% of the magnitude distribution of the spectrum is concentrated
	9-21	MFCCs	Mel Frequency Cepstral Coefficients
	22-33

Acknowledgment

We acknowledge support of this work by the project SYNTELESIS "Innovative Technologies and Applications based on the Internet of Things (IoT) and the Cloud Computing" (MIS 5002521) which is implemented under the "Action for the Strategic Development on the Research and Technological Sector", funded by the Operational Programme "Competitiveness, Entrepreneurship and Innovation" (NSRF 2014-2020) and co-financed by Greece and the European Union (European Regional Development Fund).


Ioanna Mesogiti
email: imesogiti@cosmote.gr

Eleni Theodoropoulou

George Lyberopoulos

Fotini Setaki

Aurora Ramos

Panagiotis Gouvas

Anastasios Zafeiropoulos

Roberto Bruschi

A Framework to Support the Role of Telecommunication Service Providers in evolving 5G Business Models

Keywords: 5G Business Roles, Verticals, Value Proposition, Telecommunication Service Provider

5G networks will constitute a complete transformation in the ICT domain by enabling the deployment of vertical services within the network infrastructures, based on extensive use of network softwarization and programmability. This shift will trigger and facilitate the transformation of existing stakeholders' roles, as well as the interactions between multiple stakeholders from the traditionally separated markets. The 5G-PPP project MATILDA aims at delivering a holistic 5G end-to-end services operational framework, including 5G-ready applications lifecycle management from development to deployment over 5G network infrastructures. This paper aims at providing a refined and extended vision of the 5G business roles and their interactions and based on these at defining business applicability of the MATILDA project, with special focus on the project's value proposition addressing the Telecommunication Service Providers.

Introduction

5G networks will go beyond performance enhancements of the existing telecommunication services, to a complete transformation of the ICT domain towards enabling the deployment of various vertical services (industry 4.0, automotive, multimedia, smart cities, eHealth, etc.) over the 5G infrastructures [START_REF]5G-PPP Program, European Commission, "5G empowering vertical industries[END_REF]. This shift will be based on extensive use of network softwarization and programmability to provide an integrated logical infrastructure over multiple disaggregated physical resources (in practice telecommunication networks and compute facilities), making use of convergent technologies for both mobile and fixed access ( [START_REF]Next Generation Mobile Netoworks (NGMN) Alliance[END_REF], [START_REF]5G-PPP View on 5G Architecture[END_REF]). These technology advancements will trigger and facilitate the emergence of new business models involving a transformation of existing stakeholders' roles, as well as the interactions between multiple stakeholders from the traditionally separated markets.

To this end, a number of projects (EU, national funded, equipment vendor supported, etc.) are focusing on the technical realization of the aforementioned concepts, with MATILDA 5G-PPP project [START_REF] Matilda H | 5G-PPP Project[END_REF] aiming at designing and implementing a novel holistic 5G end-to-end services operational framework tackling the overall lifecycle of design, development and orchestration of 5G-ready applications from multiple vertical sectors, and 5G network services over programmable infrastructure, including intelligent mechanisms to increase automation in most of those processes. However, it is not always clearly defined how the various 5G-related projects and solutions can support the interaction between the stakeholders, and whom they address. This paper aims at defining the business applicability of the MATILDA project with respect to the related business roles (and involved stakeholders) and their interactions, with special focus on the value proposition that is addressing the Telecommunication Service Provider.

The paper is organized as follows: To start with the various business roles in the value chain of the 5G ecosystem are identified. In the next section, the MATILDA solution is briefly presented, to be followed by the description of the MATILDA framework including capabilities and functionalities to the benefit of the basic stakeholders along with the interactions among them. Based on this framework, the following section provides an analysis on the value proposition of MATILDA for the Telecommunication Service Provider that is the main customer targeted by MATILDA solution, while conclusions are drawn at the end.

Business Roles in the 5G Ecosystem

In general, the business roles that usually appear in the value chain of the future 5G business ecosystem have been drafted in a number of industry white papers ([7]- [START_REF]Next Generation Mobile Netoworks (NGMN) Alliance[END_REF]), which however mainly adhere to existing business roles and stakeholders. Leveraging these initial definitions, MATILDA focuses on the refinement and extension on these business roles [START_REF]Market Analysis, Business Plan, Sustainability Model & Innovation Management[END_REF], which can be generalized for any 5G business ecosystem, irrespectively of the adoption of the MATILDA technical solution. These business roles definitions are described in this section.

At first, a principal role in the 5G ecosystem is that of the Telecommunication Service Provider (TSP)-(undertaken by Mobile and/or Fixed-network infrastructure providers), operating a programmable (5G) network infrastructure spanning from the radio and/or fixed access to the edge, transport and core network. The network infrastructure can be either owned by the TSP or network resources can be leased (partly or completely) as a Network Service (NaaS) from an Infrastructure Provider.

The latter reveals another significant role, that of the Infrastructure Providers (IPs), putting infrastructure resources (network resources, storage space, compute resources) in place for the 5G-ready applications deployment. Depending on the nature of the required infrastructure resources and the assets of the stakeholders, this role can be split to further roles, performed by one or more stakeholders; namely:

 Network Infrastructure Providers (NPs) operating telecommunication infrastructures and offering network resources and services to end-users, verticals and/or (other) TSPs;  Cloud Infrastructure Providers (CPs), operating centralized or distributed (in more than one location) cloud/edge deployments and offering compute and storage resources in a programmable way. The Equipment Vendors' role traditionally providing hardware equipment, now is moving to providing software telecom equipment (i.e. VNFs), thus practically implementing programmable network layer functions and delivering these components/ functions to the stakeholders in charge of their operation.

At this point, we can distinguish the Operation/Business Support System (OSS/BSS) providers' role which consists in designing and developing 5G OSS/BSS systems, towards supporting the multiple, new interactions among the various stakeholders (e.g. TSPs and the Service Providers). Although OSS/BSS providers' role can be undertaken by traditional equipment vendors, there is plenty of room for new businesses to undertake this role.

System integrators undertake the role of supporting the design and development of end-to-end orchestration platforms, at network and application level.

The role of software developers is key in the 5G ecosystem, and includes:  VNF developers, designing and developing Virtual Network Functions.  Cloud application developers, designing and developing cloud-applications (e.g. micro services-based applications based on cloud-native principles)  (Vertical) application developers, designing and developing any type of application combining cloud and network concepts (e.g. Mobile Edge Computing-oriented functionalities). (Vertical) Application/Service Providers (AP/SP) provide applications/ services to end users and aim at enhancing their portfolio and optimising service provisioning.

Finally, Service Consumers/ End Users are the individuals or corporate users to consume the 5G applications/ services while being static and/or on the move. Vertical industries fall into this category.

The described 5G value chain composed of the aforementioned large number of business roles is depicted in Fig. 1, where the stakeholders primarily addressed by MATILDA are marked in purple. In a real 5G business environment (especially one adopting the MATILDA concepts) a stakeholder may undertake more than one role, or a stakeholder's role may be assigned to more than one stakeholder depending on the nature of the 5G application/service and the resources that it requires. For instance:

 The NPs may also undertake the role of the CPs depending on their infrastructure assets, or in some cases even the role of the AP/SP  The Application Developers' and AP/SP's roles could be played by the same stakeholder  The SP role can be undertaken by a vertical or by a software house providing, while  Many stakeholders can be considered as Service Consumers, depending on the nature of the applications, e.g. customers of the verticals or the verticals themselves can be Service Consumers, and so on.

MATILDA Framework and Users

MATILDA Solution

The vision of MATILDA [START_REF] Matilda | Deliverable D1.1 "MATILDA Framework and Reference Architecture[END_REF] is to design and implement a novel holistic 5G end-to-end services operational framework tackling the overall lifecycle of design, development and orchestration of 5G-ready applications and 5G network services over programmable infrastructure. For this purpose MATILDA devises a unified programmability model and a set of control abstractions serving as interface between the 5G applications/ services and the 5G infrastructure layers, while incorporating intelligent and unified orchestration mechanisms for the automated placement of the 5G-ready applications and the creation and maintenance of the required network slices. A non-exhaustive list of MATILDA solution capabilities include:

 Enforcement of deployment and runtime policies through a set of mechanisms establishing deployment plans based on high-level objectives and runtime adaptation of the application components and/or network functions;  Deployment on multi-site/ multi-domain infrastructures;  Extraction of network and application-oriented analytics;  Management of network services defined in the form of VNF graphs through a multi-site NFV Orchestrator (NFVO). A detailed description of the MATILDA architecture and technical innovations are provided in [START_REF] Matilda | Deliverable D1.1 "MATILDA Framework and Reference Architecture[END_REF], [START_REF] Gouvas | Design, Development and Orchestration of 5G-Ready Applications over Sliced Programmable Infrastructure[END_REF] and [START_REF] Gouvas | Separation of concerns among application and network services orchestration in a 5G ecosystem[END_REF]. Businesswise, the MATILDA framework consists in the following three major layers: (a) the 5G-Ready Application Layer, (b) the 5G-Ready Application Orchestration Layer and (c) the Network Slice Management Layer (Fig. 2).

MATILDA Framework Users and Interactions

The interactions that can be realized between the MATILDA stakeholders and the MATILDA framework layers are defined as follows [START_REF]Market Analysis, Business Plan, Sustainability Model & Innovation Management[END_REF]:

(a) The MATILDA 5G-ready Applications Layer is primarily oriented to software developers, to support the design and development of 5G-ready applications, that are distributed-by-nature, consisting of cloud native components relying on a service mesh as a means of network abstraction. This layer also enables the definition of the critical configuration parameters for application components' initial deployment and runtime, their chainable interfaces among them (for the creation of a service graph), quantitative metrics with regard to the required QoS, in terms of compute and network performance functionalities, soft or hard constraints that have to be fulfilled, and so on. The latter is based on the conceptualization of a metamodel (application graph metamodel), to declare information and requirements.

(b) The 5G-Ready Applications' Orchestration Layer is oriented to (vertical) AP/SPs, to support the life-cycle management (deployment and runtime management) of the 5G-ready applications across the available multi-site programmable infrastructure, using a set of optimisation schemes and intelligent algorithms to provide the needed resources. Through their interaction with this MATILDA layer, AP/SPs are also able to specify policies and configuration options on a per application deployment (instance) basis; in other words to formulate the slice intent for the creation of the appropriate application-aware network slice that has to be provided by the TSP. Considering the business landscape, the role of the (vertical) AP/SP can be undertaken by the TSP.

(c) The Network and Computing Slice Management Layer is oriented to TSPs, to support the 5G application-aware network slice instantiation and management during the overall lifecycle of the application, after having got the application deployment request by the 5G-Ready Application Orchestrator. It includes functionalities such as: compute and network slice instantiation and management, network services and mechanisms activation and orchestration, as well as monitoring streams management and runtime policies enforcement. This layer includes an OSS/BSS system, a NFVO and a resources manager to handle the network and compute resources deployment.

It becomes obvious that although the business roles in the value chain benefiting from MATILDA are many, three of them only will be directly interacting with the MATILDA technical layers, namely the 5G-Ready application developers, the (Vertical) AP/SPs and the TSPs.

In the end, the technical benefits that the MATILDA framework users can anticipate are: flexibility for application/ VNF developers in the design, development and distribution of 5G-ready applications and VNFs by easy-to-access tools, capability for the vertical SPs of putting policy-based configurable networkagnostic slice requests, capability of full lifecycle management for applicationaware network slices over multi-site programmable infrastructure for the TSPs.

MATILDA Value Proposition Analysis for Telecommunication Service Providers

The main customer segment targeted by MATILDA is the TSP that by acquiring, operating and maintaining the MATILDA solution will be able to improve its business offerings towards vertical customers and software developers. The value proposition of MATILDA to TSPs "bridging the existing gap in end-to-end orchestration solutions and delivering an easy and flexible environment for integration of vertical applications into a 5G ecosystem" has been analysed on the basis of the Value Proposition Canvas [START_REF]Value Proposition canvas template[END_REF] (Fig. 3); the latter identifying how the "pains" of a specific Customer can be relieved and how the "gains" expected by the solution can create revenues and added value for the Customer. Considering the Customer Profile, that is the TSPs profile, the "jobs" of the TSPs with regard to the provisioning of 5G-ready applications, include the following processes:  Receiving customers' requests for advanced telecom services to support 5Gready applications and manage the lifecycle of the microservices' graph they consist of.  Analysing/Resolving customers' requests (service graphs along with other data) in terms of identifying infrastructure resources' availability for the provisioning of these services and suitable network functions.  Allocation of infrastructure resources in a dynamic/flexible/efficient way, so as to optimise their utilisation and fulfil the requested QoS.  Acquiring infrastructure resources (either own or obtained as a Service from 3rd party Infrastructure Providers) and network functions and providing them to the requested 5G-ready applications (customers). In 5G this process corresponds to efficient slicing of infrastructure resources.  Continuous monitoring of infrastructure, resources and QoS, and adjusting to runtime policies adherent to each 5G-ready application(s) deployment, following a continuous match-resolve-act approach.  SLAs' Maintenance.

Existing application deployment frameworks cannot sufficiently support the deployment of 5G-ready applications, because application deployment procedures are detached from underlying network systems and resources. In particular, TSPs have to face a number of challenges, which constitute their main "pains" in the 5Gready application deployment procedure, the most critical ones being the following:

 Currently, the provision of network resources cannot be modified at runtime because it is performed in a monolithic way, that is on a per-connection and per-technology (fixed or mobile) basis with fixed QoS attributes.  Network services (NSs) are fixed and at a certain level pre-defined on a pernetwork technology basis.  Currently, no automated infrastructure optimisation framework exists with regard to applications/ application components' placement; especially in multi-network/ multi-domain/ multi-Point of Presence (PoP) infrastructure deployments.  Multi-network/ multi-domain/ multi-PoP infrastructure deployments are not easily abstracted at application/ service layer, and resource provisioning is handled on a per customer case.  For advanced infrastructure services, direct communication between the customer and the TSP personnel is required. These "pains" result in significant human and infrastructure resources and cost overheads as well as lack of deployments' flexibility. To relieve part of these "pains" for the TSPs in the deployment of the 5G applications, MATILDA builds a value proposition around an advanced holistic framework [START_REF] Matilda | Deliverable D1.1 "MATILDA Framework and Reference Architecture[END_REF] consisting of the following products and services:

 The Network and Computing Slice Management Layer (especially the OSS/BSS, the Slice Manager and the NFVO parts).  The Telco Northbound API, facilitating the translation of slice intent requests to application-aware slice creation and management.  Modules of the 5G-ready Application Orchestration Layer, including Execution Manager, Policy Engine and Optimisation Engine components. More specifically, the MATILDA products and services are considered as "pain relievers" in the following ways:

 The MATILDA Northbound API, Vertical Application Orchestrator (VAO), OSS/BSS and NFVO support simplicity, homogeneity, flexibility by providing: (a) a single point/interface for receiving requests from various customers for various 5G-ready and common applications, (b) the means to interpret the advanced resource requirements of the 5G-ready applications' in the service graph in a homogeneous and automatic way without requiring direct communication between the customer and the TSP, as well as (c) the functionality to set up and manage the 5G-ready application deployment and operation over an application-aware network slice (that can abstract technologies/domains/PoPs), thus going beyond the existing monolithic way of services/resources provisioning.

 The MATILDA VAO and Mobile Edge Orchestrator (MEO) include functionalities that offer optimised infrastructure resource allocation in multinetwork/ multi-domain/ multi-PoP infrastructure deployments.  The Execution Manager, the Policy Engine and Optimisation Engine modules of the 5G-ready Application Orchestration layer, along with the solution monitoring mechanisms, provide the required continuous monitoring functionality of infrastructure, resources and QoS, and enable the adjustment of resources to runtime policies adherent to each 5G-ready application(s) deployment, following a continuous match-resolve-act approach. They consist of components that are supporting vertical applications and services management, however in continuous interaction with the telco network management mechanisms. At the same time, the following capabilities of the MATILDA products and services comprise "gain creators" for the TSPs:

 Capability of setting up and managing 5G-ready application deployments and operation over an application-aware network slice; necessary for the fast expansion of the TSP's service portfolio in various vertical markets;  Effective utilisation of network resources and optimisation of resource allocation and application components' placement also leading to cost savings. As a result, the "gains" for the TSPs from the MATILDA framework in 5G services deployment are the following:

 Fast and cost efficient expansion of their service portfolio in various vertical industries for the generation of new revenue streams.  Optimisation of 5G network resources provisioning leveraging the latest technological advancements in telecommunications and computing domains, well before or aligned with the competition.  Cost-efficient utilisation of infrastructure resources (either own ones and/or obtained as a Service), while maintaining high QoS for advanced services.

Discussion

This paper deals with the refinement and extension of the commonly identified business roles in the 5G ecosystem, to be driven by the foreseen transformation in the ICT domain in the forthcoming 5G era. It also discusses the roles/stakeholders interactions on the basis of the business framework to be supported by the 5G-PPP project MATILDA solution. The role of the Telecommunication Service Provider (TSP) in the 5G ecosystem is analysed with respect to the "pains" that are foreseen in the process of delivering 5G services, especially in terms of integrating vertical applications within the 5G (in general programmable) infrastructure, and the "gains" that are expected by these activities. The ways in which these "pains" can be relieved and the expected "gains" can be achieved is analysed in the context of MATILDA's value proposition to TSPs which consists in bridging the existing gap in end-to-end orchestration solutions and delivering an easy and flexible environment for integration of vertical applications into a 5G ecosystem.

Fig. 1 .

 1 Fig. 1. 5G Ecosystem and Stakeholders addressed by MATILDA

Fig. 2 .

 2 Fig. 2. 5G Ecosystem and Stakeholders addressed by MATILDA

Fig. 3 .

 3 Fig. 3. Overview of MATILDA Value Proposition to TSPs

Acknowledgements. The research leading to these results has received funding from the European Union's Framework Programme Horizon 2020 under grant agreements (1) No. 761898 and project name "MATILDA: A Holistic Innovative Framework for the Design, Development and Orchestration of 5G-Ready Applications and Network Services over Sliced Programmable Infrastructure".


Alexandros Kostopoulos

Chochliouros

Evangelos Sfakianakis

Daniele Munaretto

Claus Keuker

A Cloud-based Architecture for Video Services in Crowd Events

Keywords: Cloud-enabled Small Cell (CESC), Mobile Edge Computing (MEC), Network Functions Virtualization (NFV), Radio Resource Management (RRM)

In this paper, we discuss a use case focused on crowd events in the context of the original 5G ESSENCE project [1], emphasizing on the provision of video services to the involved end-users. In particular, we investigate the core architectural components, as well as the cloud testbed for the deployment of our use case.

Introduction

The 5G ESSENCE project [START_REF] Essence | 5G-PPP Project[END_REF] addresses the paradigms of Edge Cloud computing and Small Cell as-a-Service (SCaaS) by fuelling the drivers and removing the barriers in the Small Cell (SC) market, forecasted to grow at an impressive pace up to 2020 and beyond, and to play a "key role" in the 5G ecosystem. 5G ESSENCE provides a highly flexible and scalable platform, able to support new business models and revenue streams by creating a neutral host market and reducing operational costs, by providing new opportunities for ownership, deployment, operation and amortization.

The 5G ESSENCE accommodates a range of use cases, in terms of reduced latency, increased network resilience, and less service creation time. One of its major innovations is the provision of E2E network and cloud infrastructure slices over the same physical infrastructure, so that to fulfil vertical-specific requirements as well as mobile broadband services. In this paper, we investigate the core architectural components, as well as the cloud testbed for the deployment of our use case.

Use Case Description

Broadcasters are looking for new ways to cover events, to offer exciting point-ofview perspectives to viewers on one hand, and to reduce production and delivery costs on the other. At the same time, network operators "target" to increase the usage of their networks, while stadium owners have a strong interest in making the visitors' experience as pleasant as possible and look for ways to increase side-revenues apart from ticket sales. The reception of live content from cameras located in the playing field, replays and additional contextual information on mobile devices, becomes a strong use case for all the above actors. The main challenges even with 4G networks are the delay in the delivery of such content in the range of milliseconds rather than seconds and the considerable strain imposed on the backhaul network. By deploying a 5G ESSENCE-based network these challenges can be efficiently "addressed".

The 5G ESSENCE delivers benefits to media producers and mobile operators as it enables them to offer a highly interactive fan experience and optimizes operations by deploying "key functionalities" at the edge, i.e., evolved Multimedia Broadcast Multicast Services (eMBMS) or local network services like real-time analytics together with multitenancy support by small cells. By leveraging the benefits of SC virtualization and radio resource abstraction, as well as by optimizing network embedded cloud, it becomes possible to ease the coverage and capacity pressure on the multimedia infrastructure and also to increase security, since content will remain locally. Furthermore, additional benefits for the operators and the venue owners arise such as: (i) lower latency, due to shortening the data transmission path, and; (ii) maintained backhaul capacity, due to playing out the live feeds and replays locally that puts no additional strain on the backhaul network and upstream core network components. Fig. 1 depicts the use case "5G edge network acceleration at stadium".

Fig. 1. 5G edge network acceleration at stadium

The scenario provides the logic for distributing the live video feeds received from the local production room to local spectators in a highly efficient manner. Different scale facilities can be used for the validation of the deployment topology. First, a small-scale facility as the municipal open swimming pool with a capacity of 500 spectators; secondly a medium-scale facility like the municipal indoor stadium (which is used for basketball, volleyball and handball games) with a capacity of 2,000 spectators, and; thirdly a large-scale facility as the municipal football stadium "Stavros Mavrothalasitis" which is located at the centre of Egaleo town in Athens and it is an open stadium with capacity of about 8,000 spectators.

Considering a proper selection from the aforementioned facilities, the selected facility will be covered with a cluster of eMBMS enabled CESCs (Cloud Enabled SCs) and, together with the Main DC (Data Centre), can be connected to the core networks of multiple telecom operators. The video content from cameras will be sent for processing locally at the Edge (similar to the proposed use case by ETSI MEC [START_REF]White papers from the 5G Infrastructure Association[END_REF]- [START_REF][END_REF]). Then the video streams will be broadcasted locally using the 3GPP eMBMS functionality. Spectators will be able to dynamically select among different offered broadcast streams. In this and in similar "big event" scenarios, massive data traffic will not affect -nor overload-the backhaul connection as it will be produced, processed and consumed just locally (i.e. a case of a 5G MEC scenario, aligned to the 5G 3GPP specifications [START_REF]Network Functions Virtualization (NFV); Management and Orchestration[END_REF]- [START_REF]Telecommunication management; Principles and high level requirements (Rel. 15)[END_REF]).

Architectural Components

The stadium use case shows a typical MEC configuration that keeps traffic as close as possible to the users to allow them to consume digital media with high quality and low latency. It shows that integrating network functionalities at the edge allows to fully benefit from advanced applications and services, including also broadcast or multicast-based technologies. Within the 5G ESSENCE infrastructure, the stadium use case will leverage the main DC to realize its services running as VNFs (Virtual Network Functions). The actual distribution of the service across the data centres depends on the actual load required by the system. The Edge Video Orchestrator -Master Orchestrator (EVO-MO) service, eMBMS and EPC (Evolved Packet Core) functionalities actually run as VNFs in the DCs. In case where a cluster of CESCs is to be used to enable larger deployments, the aforementioned architecture can be further extended. The Edge Video Orchestrator (EVO), eMBMS and EPC core services can be deployed on each CESC's light DC, while the EVO instances being managed by an EVO-MO located on a central location. In order to achieve multi-tenancy, the EVO, eMBMS and EPC core services could be instantiated multiple times, depending on whether the services needed are also "multi-tenancy capable". The eMBMS functionality will be triggered by the EVO-MO communicating to a Broadcast Multicast Service Centre (BMSC), which is running locally in the stadium premises. If a camera's stream is to be transmitted via eMBMS (controlled by a management application), then the EVO-MO will request the BMSC to set up an eMBMS channel. Once this is set up, the BMSC acts as a proxy for the data and forwards it to respective eMBMS channels.

All devices use unicast transmissions for connecting to the EVO network service, which subsequently manages data transmission. Camera/Encoders use unicast transmission to transmit video and audio to the EVO service. Clients use eMBMS multicast reception to receive video and audio transmissions. The EVO services can deliver data to the 5G ESSENCE telemetry and analytics systems that can feed, for example the NFV Orchestrator (NFVO). Typical values that can be sent (other than platform related values such as CPU (Central Processing Unit), occupancy, network traffic, etc.) are application specific information used for orchestration like the number of connected users. More information regarding the 5G ESSENCE architecture is provided in [START_REF] Chochliouros | Using Small Cells from enhancing 5G Networks[END_REF] and [START_REF] Kostopoulos | Small Cells-as-a-Service in 5G Networks[END_REF].

The solution platform can be deployed in another different context, as it can be event-specific (stadium, concert, etc.), venue-specific (mall, museum, university, airport, etc.) or area-specific (neighborhood, city and region). In the following sections, the main components of the solution architecture are presented.

Hotspot LTE eMBMS

The EPC and eMBMS VNFs build the so-called hotspot LTE (Long Term Evolution) eMBMS. In practice, the two VNFs, EPC and eMBMS, are the "core" network components allowing the provision of LTE unicast communications and broadcast communications in the stadium. The two VNFs are also a MEC solution to offload traffic in a certain edge area without affecting the national backbone, as the local traffic stays local.

With the advent of the LTE technology, eMBMS has become an "attractive" solution for network operators who desire to increase bandwidth capacity and improve service quality, while maintaining low-cost investments for upgrading the network architecture. The eMBMS is an optimized broadcast/multicast service, which leverages on a point-to-multipoint link to transmit control/data information from the base station (eNB) to a group of users. One of the key hurdles of eMBMS deployment for business/mission critical applications is that an eMBMS "island" must be integrated within the existing service provider and/or private national mobile network. Our solution solves this problem by providing partial functions of the EPC integrated with the broadcast functions to: (i) eliminate dependencies on a national/centralized mobile core network while being able to interface with it via existing interfaces; (ii) rapid low latency signalling; (iii) optionally eliminate failures due to backhaul scarcity, latency and failures, and; (iv) flexibly deploy virtualized functions at the network edge.

The eMBMS solution can be fully integrated with an existing service provider mobile core network. Moreover, depending on the customer's needs, the eMBMS can be deployed centralized or distributed to the edge of the network. The latter represents an important step towards making eMBMS efficient in terms of resource usage and delivery delay, while avoiding impacts on the national core network. The eMBMS can also interoperate with an external EPC. The SGi interface of the network operator (MNO)'s P-GW (Packet Data Network Gateway) is used to deliver a media (provided by the MNO) as IP multicast through the BMSC and MBMS-GW.

Edge Video Orchestrator and Distributor

According to [START_REF]Edge Video Orchestration EVO -Product description[END_REF], the EVO solution typically consists of the following components: Master Orchestrator (MO), Distributor, encoder and corresponding applications. Additionally, in case of LTE broadcast distribution, the eMBMS component is necessary. The core part of EVO is represented by the MO. The MO is provided as a virtual machine image using CentOS Linux as a base system. The main purpose of MO is to: (i) receive the encoded video streams from one or more connected encoders; (ii) forward the streams to one or more distributors (for unicast distribution); (iii) forward the streams to the eMBMS component (for broadcast distribution), and; (iv) encrypt video streams.

In each practical deployment there is always one MO and one or more Distributors. The encoders are always connected to the MO only. For unicast distribution and multicast, the system does not require any extra hardware components. Configuration of the multicast operation can be done by the EVO interface. Once the parameters are configured the EVO can be used to "tell" specific cameras attached to it to deliver their data to the according multicast channel.

Opposite to that, for LTE multicast, an additional eMBMS component provides HTTPS control interface and dynamic UDP (User Datagram Protocol) ports for video and audio data. The HTTPS control interface provides an API (Application Programming Interface) for managing broadcast sessions. This includes creating and starting broadcast sessions, querying the currently active sessions, and stopping a session. Each created session is identified by the Temporary Mobile Group Identifier (TMGI) and it contains one or more streams (e.g. HD (High Definition) / SD (Standard Definition) streams and audio stream). The number and type of the required streams is specified by the MO when the session is created and cannot be changed afterwards. The process is as follows: 1. MO creates a session and specifies the number and type of channels/streams to allocate.

2. The eMBMS component creates the session and returns a pair of UDP ports for each allocated channel and the TMGI of the created session.

3. The MO starts the session on the eMBMS component and starts pushing the associated video and audio streams to the eMBMS component.

The eMBMS component broadcasts them to the UEs (User Equipments).

To connect to the session and open the stream on the UE side, the following information is needed: (i) TMGI of the session, (ii) Multicast address which is used to broadcast the data within the session, (iii) UDP ports used for video and audio data, and; (iv) Key for decrypting the data.

The application retrieves this information from the MO and Distributor upon startup, using a dedicated unicast connection. This ensures that only authenticated users can receive and decrypt the broadcasted streams. After that, the application uses the Qualcomm Broadcast SDK (Software Development Kit) [START_REF]LTE Broadcast SDK[END_REF] to enable the session using the TMGI and receives the UDP data afterwards, which it can then decode and display.

When using a multicast delivery means, either eMBMS or Wi-Fi, the packet loss probability increases due to the missing MAC HARQ mechanisms. In order to mitigate this problem, it is possible to add redundancy to the user plane meaning that the same data is repeated in a special way in the user plane. If some data is lost, the original data might still be able to be recovered from the received subset. The mechanism is similar as the well-known FEC (Forward Error Correction) mechanisms employed by 3GPP on the radio link. The benefit of additional redundancy in the data path must be traded against higher data volume on the link. Therefore, it is possible to configure the amount of data plane redundancy provided by the system. Further, the system needs a distributor component in case the EVO service should be offered in multiple locations or if one MO instance cannot handle all the load and the installation must be scaled up to multiple physical machines. Basically, the distributor is the same component as the MO, just with a different configuration.

To be completely functional, the system also needs encoders. They receive the captured video and audio data using HDMI (High-Definition Multimedia Interface) or HD-SDI (High-Definition -Serial Digital Interface) and convert them to one or several IP streams. Thus, MO manages these provided streams. The advantage of such approach is that any professional or consumer camera that provides the necessary signal can be used. The encoders are specially designed and manufactured. Its software is based on OpenWrt and extended in such a way that it can directly connect to the MO via the web API.

Radio Access and Small Cells

The deployment architecture of the stadium use case also includes the small cells that provide the radio interface to support the video transmission to the UE. The small cells will form a zone-based architecture comprised of multiple low power access points coordinated by a localized zone controller, thus enabling the operators to offer high user experience while offloading unwanted data traffic from their macro and core networks. With the deployment of LTE SC technologies, mobile operators (and/or virtual mobile operators) are enabled to service a large number of mobile users, as well as provide users with the bandwidth they need to utilize mobile devices to enhance their productivity. Additionally, since poor 3G coverage remains an issue, mobile operators are enabled to deploy dedicated indoor coverage for voice and data in public indoor and enterprise locations.

Using SCs provides seamless mobility and enhanced user experience in enterprise and public locations by improving the coverage/capacity of the network. Moreover, these SCs provide LTE and Wi-Fi offloading capabilities. The multi-support of both LTE/3G and Wi-Fi access, integrated within a single compact form factor allows for reduced number of boxes and shared services (i.e., power, backhaul, etc.).

User Equipment

To enable the eMBMS reception in the end devices (UEs), special requirements have to be fulfilled. First, the modem part of the UE hardware and firmware must be eMBMS enabled, meaning the eMBMS technology must be implemented in physical and MAC/L3 layers of the modem chip. To make this functionality usable by an application running under the control of the UE's operating system (iOS, Android), this eMBMS functionality should be controlled from the UE's application processor (typically different from the modem). Thus, a so-called eMBMS middleware must be present on the phone to form the interface between the application receiving video and audio data and the low-level functions on the modem. Currently, there are a limited set of middleware SW products allowing this, but are not yet recognized and spread in the market. Hence, special UEs have to be used for this use case. A further challenge for the UEs, in order to use low latency video transmission, is that chunkbased transport cannot be used. The edge video orchestration service uses the RTP (Real-Time Transport Protocol_ and eMBMS functions such as service announcements are not used. The EVO product uses own control channels to convey the information. Correspondingly, the eMBMS middleware of the UE must allow it to only use a subset of the standardised eMBMS functionality. As described in [START_REF]Edge Video Orchestration EVO -Product description[END_REF], the corresponding client application is available for Android and iOS systems. The client application shows the available cameras. One of the options that can be chosen is eMBMS. If on, then the client will display the video received via eMBMS. Only eMBMS enabled camera feeds can be shown via eMBMS. Users can adjust the number of viewable streams. The client enables up to 9 streams to be shown simultaneously.

Main Data Center

The 5G ESSENCE platform has been designed to take advantage of MEC concepts to improve user experience, bandwidth efficiency and help mobile operators lighten the service delivery process. The two-tier virtualised execution environment makes a distinction between a very light computational environment, directly attached to the Small Cells (Light DC)typically used to support the virtualisation of the SC and the execution of "light" service VNFsand the Main DC, where the most computationally demanding VNFs can run and where implementing all the processes can take advantage of a centralised view of the underlying infrastructure.

Depending on the deployed scenario, the border between Light DC and Main DC can be more or less evident with the possibility, in specific circumstances, to collapse it in a unique physical layer. For small or medium size deployments, the Light DC makes room for the Main DC as the only tier of the Edge DC. The choice of edge architecture is mainly based on the size of covered area and on the number of SCs. In a small deployment scenario, the hardware of the Main DC can vary from one to a few nodes (servers), clustered together through a typical Ethernet infrastructure. In this use case we have no constraints related to physical dimensions or power consumption, so there are many possibilities in the choice of computing resources. If transcoding applications would be needed, the platform could be equipped with one or more GPUs (Graphics Processing Units). This kind of resources could be also useful for applications requiring Machine Learning (ML) algorithms.

Apart from that, this use case does not provide demanding applications in terms of computing resources. On top of the HW Infrastructure there is the virtualization layer that will make use of a standard KVM Hypervisor. This layer will make available the Virtual Machines for hosting the required VNFs (vEPC, eMBMS, EVO-MO).

Cloud Testbed

The cloud testbed that will be used for the duration of the 5G ESSENCE, to enable this use case, consists of three different site deployments: (i) The campus of NCSR "Demokritos" (NCSRD), in north-east Athens, is a 150-acre area, combining indoor and outdoor environments, covered by five software-driven 5G wireless nodes and supported by an optical backbone. (ii) The OTE building (OTE Academy), to the north of the city, is a multi-functional complex, combining various indoor and outdoor usage scenarios, and; (iii) The Egaleo Stadium, in west Athens, is going to be an actual "field" testbed, supporting a wide variety of real-life scenarios, ranging from massive MTC (Machine-Type Communications) to flash crowd events. The interconnected sites are located approximately 10-15 kilometres apart and their interconnection is based on microwave links. All three sites use a common base infrastructure, but each one has different features.

NCSR "Demokritos" (NCSRD) Campus

The experimental setup at the campus of NCSR "Demokritos" comprises of five main parts: the core network, the backhaul network, the access network, mobile terminals connecting to the access network and distributed cloud deployments with computing, storage and networking resources. Topology and infrastructure are discussed as follows: Topology: The related infrastructure consists of a macro-cell located at a high mast, covering a wider area, within the campus and three SCs serving focused coverage areas. Both the macro-cell and SCs are purely software-defined, in the sense that: (i) they are driven by fully reconfigurable and open SDR equipment, and; (ii) they also feature edge computing equipment ("light Data Centres") for hosting virtual appliances. All radio access points are connected to a core facility (currently based on LTE EPC) through dedicated fibre links.

Infrastructure: The radio infrastructure for the front-end is as follows:  For the macro cell: SDR (Software-defined Radio) platform running a full software-based eNodeB implementation, driving a 5W HPA (High-Power Amplifier) and a sector antenna (outdoor, installed on a 70m-high mast).  For the small cells: SDR platform running a full software-based eNodeB implementation, with indoor low-power antennas. The testbed also features micro-servers integrated in each macro-/small cell, according to the CESC concept, which has been adopted in 5G SESAME project [START_REF] Sesame H | 5G-PPP Project[END_REF] and the 5G ESSENCE project [START_REF] Essence | 5G-PPP Project[END_REF] for mobile edge services. These micro-servers create a distributed Network Function Virtualisation Infrastructure (NFVI) based on OpenStack (supporting VMs or Containers) and OpenDaylight. In this manner, CESCs are both edge computing-capable and multitenant, enabling a small cell infrastructure to be shared among multiple tenants. Edge services deployed in the CESCs include several VNFs (vDPI, Security Appliance, Network Monitoring) as well as of virtualized appliances (Transcoder, Video analysis for object recognition).

The core functions (EPC) are also located on site. EPCs from different vendors have been tested. The eNodeBs (SCs and Macro Cell) are connected to the EPC over different types of backhaul links (fibre, RF, copper). UEs of various types have been tested (mobile phones by various vendors, laptops equipped with appropriate dongles, software-defined UEs based on SDN platforms). All types of UEs have embedded USIMs, appropriate for authentication to the EPC.

The testbed also hosts a core Cloud/SDN experimental platform for the experimentation needs of the 5G ESSENCE project. The cloud infrastructure is based on the OpenStack Cloud Operating System, comprising of 18 compute nodes (180 CPU cores, 1.5TB RAM) and storage system supporting SAS (Serial Attached SCSI) and iSCSI (Internet Small Computer System Interface). NCSRD's testbed also features SDN-enabled network devices that support OpenFlow protocol (i.e., HP 3500yl-24G, Dell PowerConnect 5524), as well as legacy devices including firewalling and routing equipment (i.e., a Cisco 2921 Integrated Router, a Cisco ASA 5510 Firewall). Finally, the NCSRD site connects to the Internet via the national NREN (GRNET), using a dedicated hardware firewall whose rules are fully customizable. VPN access is possible, via SSL (Secure Socket Layer) and IPSec (IP Security) connections. (c) A (common) backend infrastructure (including storage, monitoring/data visualization, command exchange, etc.). (iv) A broadband connection over GRNET 6 , serving as backhaul link.

Egaleo Stadium

The Egaleo municipal stadium "Stavros Mavrothalassitis" is a football ground located in Egaleo, in the west of Athens. The stadium was built in 1966 and totally renovated in 2006 (Fig. 4). The stadium belongs to the Municipality of Egaleo (MoE) and its capacity is 8.217 (seated) spectators. The stadium is used by the football team of Egaleo (Egaleo FC). In addition to the football matches, the stadium is used for various events, such as music concerts. In general, the Egaleo municipal stadium is a modern stadium and has all the appropriate facilities and infrastructures. The infrastructure at the Egaleo municipal stadium (Fig. 4 -left) aims at showcasing the value of 5G in big sports and/or cultural events. The access part of the infrastructure is based on three low-power cells, covering the entire stadium (Fig. 4 -right), integrated with local virtualization-capable IT resources, thus forming CESCs as described in the previous section. The capability of the CESCs to be multi-tenant and

Discussion

5G ESSENCE delivers benefits to media producers and mobile operators as it enables them offering a highly interactive fan experience and optimizes operations by deploying key functionalities at the edge (i.e., eMBMS or local network services like real-time analytics together with multitenancy support by small cells). In this paper, we investigated the core architectural components of the aforementioned use case, as well as the cloud testbed for the respective deployment.

A large-scale facility as the municipal football stadium "Stavros Mavrothalasitis" will be used for the validation of the respective 5G ESSENCE use case. The coverage in this facility will be provided by a cluster of multitenant, eMBMS-enabled SC and a main DC connected to the core networks of multiple telecom operators. The Edge DC will be processing video content from cameras deployed on-site, which will be broadcast locally without affecting the backhaul. Our future work will be focused on validation and testing in order to evaluate the proposed 5G ESSENCE architecture.

Fig. 2 .

 2 Fig. 2. (left) High (70m) Mast within the Campus of NCSRD, Hosting the Macro-Cell Base Station; (right) Cloud/SDN Infrastructure in NCSRD

Fig. 3 .

 3 Fig. 3. Topology of the testbed in OTE premises The OTE's testbed includes the following equipment: (i) An OpenStack-based cloud infrastructure (>220 CPU cores, >30 TB HDD, >340 GB RAM), consisting of 1 gateway, 5 controllers, 4 x86 + 2 ARM-

1 https:

 1 //www.cisco.com/en/US/docs/security/pix/pix30/user/guide/pixugcfg.html 2 https://en.wikipedia.org/wiki/Z-Wave 3 https://www.microtronics.com/en/products/BLE-Gateway.html 4 LoRaWAN (Long Range Wide Area Network) is a media access control (MAC) protocol for wide area networks. It is designed to allow low-powered devices to communicate with Internet-connected applications over long-range wireless connections. It can be mapped to the second and third layer of the OSI model. For further details also see: https://www.thethingsnetwork.org/docs/lorawan/ to host edge services enable a new business model, under which the CESC infrastructure is owned by the stadium operator (rather than by MNOs), who, in turn, leases slices to MNOs, MVNOs and enterprise users. The stadium is connected to the main site of the testbed (NCSR "Demokritos"), where the core functions are expected to reside, with a backhaul point-to-point microwave link. A VPN (Virtual Private Network) over the Internet also exists, yet only as a fall-back solution.

Fig. 4 .

 4 Fig. 4. (left) Egaleo Municipal Stadium; (right) Placement and coverage of radio cells

https://en.wikipedia.org/wiki/Narrowband_IoT

For more details see: https://grnet.gr/

Acknowledgements. The paper has been based on the context of the 5G-PPP phase 2 "5G ESSENCE" ("Embedded Network Services for 5G Experiences") Project (GA No.761592), funded by the European Commission.