# A Quality of Experience Management Framework for Mobile Users

Authors: María Jesús Algar; Isaac Martín de Diego; Alberto Fernández-Isabel; Miguel Ángel Monjas; Felipe Ortega; Javier M. Moguerza; Hektor Jacynycz
Journal: Wireless Communications and Mobile Computing
 (2019)

---

## Abstract

Voice transmission is no longer the main usage of mobile phones. Data transmissions, in particular Internet access, are very common actions that we might perform with these devices. However, the spectacular growth of the mobile data demand in5G mobile communication systems leads to a reduction of the resources assigned to each device. Therefore, to avoid situations in which the Quality of Experience (QoE) would be negatively affected, an automated system for degradation detection of video streaming is proposed. This approach is namedQoE Management for Mobile Users (QoEMU).QoEMU is composed of several modules to perform a real-time analysis of the network traffic, select a mitigation action according to the information of the traffic and to some predefined policies, and apply these actions. In order to perform such tasks, the best Key Performance Indicators (KPIs) for a given set of video traces are selected. AQoE Model is trained to define a global QoE for the set of traces. When an alert regarding degradation in the quality appears, a proper mitigation plan is activated to mitigate this situation. The performance ofQoEMU has been evaluated over a degradation situation experiments with different video users.


---

## Body

## 1. Introduction

During the last decade mobile networks have witnessed a continuous growth in traffic, due to the increasing number of connected devices. This growth has accelerated with the takeoff of the Internet of Things (IoT), with an estimation of 30 billion connected devices by 2020 [1].Telephone cells have limited resources in terms of simultaneous voice connections and data bandwidth. Such resources are shared among all devices connected to the same cell. When this limit is reached, the cell cannot provide service to all connected devices leading to a congestion situation. The result is a reduction of the bandwidth assigned to each device and the impossibility for new devices to attach to the cell and, in some cases, the device may even become unable to access any data service.In any environment, it is common to find cells with severe congestion problems while their neighbor cells are underutilized. Mobility Load Balancing (MLB) [2] is a widely used technique to balance the network load. The overload of some cells is transferred to other less congested ones to achieve a more efficient load distribution in the mobile network. This technique is used in Global System for Mobile communications (GSM) [3], Universal Mobile Telecommunications System (UMTS) [4], and Long Term Evolution (LTE) [5]. However, the use of MLB in LTE presents important limitations (see, e.g., [6]).Mobile networks have evolved to support very high-speed data transmission, since the new generation of mobile users not only demands telecommunication services but especially data-communication services. Cisco’s Visual Networking Index (VNI) Global Mobile Data Traffic Forecast predicts that mobile data traffic will grow at an annual rate of47% from 2016 to 2021, reaching 49.0 Exabytes per month by 2021. Video traffic, which currently accounts for 60 per cent of the total mobile traffic, is predicted to reach 78 per cent by 2021 [7].Network operators design their network capacity according to traffic estimations for resource provisioning. However, with the arrival of5G mobile communications [8], it is expected that these networks will support a variety of applications that will increase the demand of bandwidth significantly [9]. When the connectivity is lower than a tolerable threshold, the network traffic will pause or slow down. This degradation could greatly impact the user perceived quality, also known as the Quality of Experience (QoE) [10]. In this work, the following definition of QoE from the EU Qualinet community (COST Action IC1003: “European Network on Quality of Experience in Multimedia Systems and Services) encompasses the discussed aspects and defines it as the degree of delight or annoyance of the user of an application or service. It results from the fulfillment of his or her expectations with respect to the utility and/or enjoyment of the application or service in the light of the users personality and current state. In the context of communication services, QoS is influenced by service, content, device, application, and context of use” [11].The Online Network Traffic Characterization (ONTIC) project proposes to design, develop, and evaluate a novel architecture and a set of data mining techniques to characterize network traffic data streams, identifying traffic pattern evolution and proactively detecting anomalies in real time [12]. ONTIC has defined several use cases to address the network transformation. One of them is theAdaptive QoE Control, which implements an analytics-enhanced control loop to react to QoE degradation situations in video services and apply corrective measures [13].The aim of this work is to consolidate an automated framework to prevent degradation situations in mobile networks. This framework will be namedQuality of Experience Management for Mobile Users (QoEMU). We focus on video streaming domains where modeling distortions is a very complex issue [14]. The main goal ofQoEMU is to detect problematic scenarios and react applying different actions to mitigate adverse effects, ensuring a minimum overall degradation of the QoE. It is known that the QoE depends on the end user’s device [15]. In this work, mobile phones were considered.This paper is organized as follows. Section2 presents the proposed framework in the context domain. Section 3 describes in detail the proposed framework, introducing all components and their functionality. Results from two empirical experiments to test the approach are shown in Section 4. Finally, Section 5 summarizes the conclusions of this work.


## 2. Background

As mentioned, one of the main problems of mobile networks is congestion situations, since they can even cause users disconnections. To address this issue, a possible solution could be readjust one of assigned resources. For instance, a scheduling based on a search scheme is presented in [16]. This approach finds the suitable number of combinations of antennas and user equipment.Due to the network evolution from4G to 5G it is also essential to facilitate the management of scenarios of growing network complexity [17]. Recent studies have focused on network dimension. In [18] a prediction method based on cluster analysis is proposed, whose main goal is to obtain general information about the multidimensional situation of LTE traffic to assign resources more efficiently. The network can be analyzed using only time-dependent data, applying k-means, and Support Vector Machine (SVM) methods [19]. In addition, useful information about network future behavior can be given to plan optimal access.Other researches have centered their attention in the relation between spatial and temporal information [20, 21]. They usually apply Machine Learning (ML) techniques to combine this temporal and spatial information to improve prediction accuracy in any cellular network, even in noisy or challenging cases.Regarding the QoE, a framework to model the mobile Internet network QoE using Big Data is proposed in [22]. Up to now, parameters such as bandwidth, loss, and delay were sufficient to evaluate Quality of Service (QoS) [23]. However, these metrics are not sufficient to describe a good quality level for real-time multimedia applications, as it is necessary to capture subjective aspects such as user satisfaction [24]. Many researches develop QoE metrics using explicit functions, which take into account parameters from the encoder or the network [25, 26]. In [27] a framework called Post Streaming Quality Analysis (PSQA) is developed to improve the QoE of dynamic adaptive streaming over HTTP video streaming over mobile networks. PSQA uses ML to generate the best adaptation logic parameters from past throughput traces training. In [28] a QoE model for HTTP adaptive streaming is developed. Parts of this model have become standardized in ITU-T P.1203.3.In the case of Ericsson, it has introduced a highly automated and programmable architecture, the COMPA architectural model [29]. This approach consists of an evolution of classic autonomic networks. It uses control loops to obtain data from a variety of sources (for instance, network traffic in real-time situations), making automatic corrective decisions such as modifying the assigned bandwidth (depending on the analysis of these data) and executing them. The COMPA principles have been incorporated to current 5G standardization efforts such as the Open Network Automation Platform (ONAP) [30]. Figure 1 shows the COMPA model, including three different functions:(i)
A(Analytics) takes care of turning data into information and insights that serve as a basis for decision making and triggering actions.(ii)
P(Policy) is a function that governs the behavior of a telecommunication system based on the insights from A, asking the COM function to implement the desired behavior.(iii)
COM is a function that enforces the decisions made by the Policy function, including three components:C(Control): in charge of negotiating, establishing, maintaining, and terminating data/user plan connections.O(Orchestration): in charge of the organization of the loop, its deployment and automation, coordination, and communication between components and services.M(Management): it coordinates the efforts to accomplish goals and objectives using available resources efficiently and effectively.Figure 1
COMPA architectural model.


## 3. The QoEMU Framework

The main goal ofQoEMU is to detect situations suitable of deteriorating the QoE in mobile networks and apply different mitigation actions to alleviate the QoE degradation situation. Different types of mitigation actions can be adopted, for example: bandwidth regulation; access technology steering (i.e., from 4G to 3G), or different services (such as video service, web navigation, etc.) can be blocked [31]. An important point to highlight is the impossibility of simply providing more bandwidth to users. The overall available bandwidth in a cell is limited and therefore only redistribution is feasible.Different options could be considered at this point (see, e.g., [32]). In this case, QoE degradation alleviation must deal with enhancing the average QoE, even if some of the users do not receive a better service. The proposed framework, presented in Figure 2, uses the COMPA architecture introduced in Section 2 and follows, whenever possible, the Kappa architecture paradigm, using a message broker as main communication means between the architecture modules [33].Figure 2
QoEMU framework.First, aVideo Processor module, which is a streaming video server based onVLC that provides video to users. Video traffic goes through theVirtual Proxy (the COM module). This module redirects traffic to theVLC Video Server component. It also collects network traces from the users traffic and is able to regulate the available bandwidth for users to play the video, based on the mitigation plans provided by thePolicy Manager module. TheMessage Broker module, which is based on Apache Kafka [34], is used to communicate the traces from theVirtual Proxy to theDegradation Detection module. This component is based on Apache Spark Streaming [35] and works as a time-based sliding window operator [36] that continuously receives batches of information (network traces in this case). Thus, theDegradation Detection module accumulates the traces during the window duration (several batches). Then, it processes the accumulated traces to obtain the Key Performance Indicators (KPIs) [37] and QoE metrics based on theQoE Model (i.e., the ML model previously trained to organize the traces which is used byQoEMU to detect degradation situations). ThePolicy Manager module is in charge of receiving the insights from theDegradation Detector module to decide the mitigation plans that must be executed, according to a set of predefined policies. Such mitigation plans are communicated to theVirtual Proxy module to solve the detected degradation situations.In Section3.1 the architecture of theQoEMU framework is presented in detail. Then, the architecture built to generate theQoE Model is addressed in Section 3.2.


### 3.1. QoEMU Framework Architecture

In accordance with the COMPA model, theQoEMU architecture consists of three main modules: theDegradation Detector, thePolicy Manager, and theVirtual Proxy.Degradation Detector. This module supports to the A function in the COMPA model. It is in charge of the real-time analysis of video traffic data from users connected to the network. Regarding the architecture of theDegradation Detector module, it consists of four components: theKPI Selector, theQoE Analyzer, theAlert Notifier, and theQoE Model. This latter is trained using a specific architecture that includes theQoE Model Generator System module. This architecture is explained in detail in Section 3.2 and its scheme is shown in Figure 4.First, theKPI Selector extracts the KPIs from the collected network traces. Next, theQoE Analyzer uses a nonsupervised ML algorithm to split up the dataset in heterogeneous groups. The main idea is to collect traffic data with similar QoE in the same cluster and compute an average QoE. TheDegradation Detector module is able to analyze the QoE of a set of traces collected during a time window in real time and detect a degradation situation. When the average QoE of the traces in a time window is under a threshold (δdeg), a degradation situation is considered to occur. Then, theDegradation Detector module sends an alert to thePolicy Manager module. The alert includes the average QoE and the location where the degradation has been detected. When an alert about a degradation situation is sent to thePolicy Manager, a session is created in such module. Since it is possible to detect multiple degradation situations in different locations, they will be treated by thePolicy Manager in different sessions. While a degradation situation in a given location persists, theDegradation Detector module keeps on periodically sending information about the evolution of the average QoE. However, it is stateless and therefore not aware of the sessions kept by thePolicy Manager.Policy Manager. This module supports the P function in COMPA. It consists of two components: thePolicy Engine and theDegradation Sessions Database. The first one makes decisions based on the alerts received from theDegradation Detector and decides which mitigation actions have to be enforced by the COM function. TheDegradation Sessions Database maintains information of the active degradation sessions (mobile devices IPs). A search is performed on the database when an alert from theDegradation Detector is received. If a degradation session is located at the same location, it means that the degradation continues and has already been alerted (has an associated session). According to its policies, thePolicy Engine may decide to update the mitigation plans being enforced.During the conversation between theDegradation Detector and thePolicy Manager modules, two different situations can be distinguished:(i)
If the average QoE is greater than or equal to a threshold (≥δdeg), it could mean two different things. If there is a degradation session in the same location, this means that the degradation situation has just finished. On the other hand, if the locations are different the QoE is directly considered as satisfactory.(ii)
If the average QoE is strictly lower than a threshold (<δdeg) and a degradation session exists in the same location, the degradation continues and thePolicy Manager module has been alerted. In contrast, a new degradation situation has been detected and an alert is sent to thePolicy Manager module. At this point, this module generates a session identifier and stores information about the date, the time, the degradation location, and the average QoE. When a session begins, a specific mitigation plan is selected for that session.The message exchange between theDegradation Detector and thePolicy Manager is based on a Representational State Transfer (REST) interface [38]. ThePolicy Manager only provides REST interfaces and, therefore, cannot be directly plugged to theMessage Broker component. As theDegradation Detector plays the role of a message producer according to a Kappa architecture, an adapter (thePolicy Manager Adapter) is required. It plays a message consumer role when receiving alerts from theDegradation Detector while, at the same time, implements a REST client interface towards thePolicy Engine component.Figure3 presents an example of the messages between theDegradation Detector module (A), and thePolicy Manager module (P), when a degradation situation is detected. For the sake of simplicity, it is represented as an end-to-end REST exchange.Figure 3
Sequence diagram for a degradation situation.Figure 4
QoE Model Generator System.Virtual Proxy. This module supports the COM function in COMPA. It is aware of what type of user each IP address belongs to, so that it can apply different policies. It implements two main tasks. The first one handles the traffic towards theVLC Video Server, captures traffic information (network traces), and forwards it to theDegradation Detector. The second executes the mitigation actions invoked by thePolicy Manager to alleviate the degradation.Regarding the architecture of this module, it consists of three software components:HAProxy,TC (Traffic Control), andTstat [39]. Once thePolicy Manager has decided which mitigation actions have to be enforced, they are communicated to theVirtual Proxy for being applied. TheHAProxy provides HTTP and TCP proxy capabilities. It allows, among other things, a high availability and load balancing [40]. It is in charge of rerouting the incoming HTTP traffic to the Video Server to enable the capture of network traces.Tstat is an automated tool for passive monitoring [41]. It provides traffic monitoring up to Gigabits per second using off-the-shelf hardware and offers a passive sniffer functionality of traffic. Additionally, it is capable of analyzing these traces to provide multiple KPIs, concerning connections, at both the network and transport level [37].TheTC configures the Linux kernel packet scheduler which acts as a bandwidth regulator. It allows controlling the way packets are handled in network interfaces. The main feature, as per theVirtual Proxy which is involved, is the rate of handled packets. Thus, it is possible to characterize traffic and create rules to assign a bandwidth for each type of service or range of IPs [42]. A bandwidth limitation functionality will be used when needed for video users connected to theVirtual Proxy.When thePolicy Manager decides which mitigation actions have to be enforced and creates a degradation session, theVirtual Proxy module is informed to implement the mitigation plan. Message exchange between them is based on REST as well. The mitigation plan activation orders sent to theVirtual Proxy should include information about the start and end of the plan, the mitigation actions to perform for each type of user and the location in which the plan is going to be applied.After applying a mitigation plan, theDegradation Detector module keeps on receiving network trace information and an average QoE is continuously computed. The evolution of this indicator is received by thePolicy Manager, which evaluates whether the degradation situation continues. If that is the case, it informs theVirtual Proxy module to carry on the mitigation plan. However, if thePolicy Manager module detects that the degradation has finished, it informs theVirtual Proxy module to cancel the plan and discards the degradation session record in its database.


### 3.2. QoE Model Generator System

As mentioned before, theDegradation Detection module of theQoEMU framework (see Figure 2) uses theQoE Model. It implements a ML model able to discriminate between network traces and compute an average QoE. This component has been built using the architecture presented in Figure 4.A controlled experiment with several users is performed to generate theQoE Model. It uses an alternative architecture that comprises three modules: theVirtual Proxy, theVideo Local Server, and theQoE Model Generator System. Notice that this architecture is not used by theQoEMU framework since it is only in charge of generating theQoE Model.Firstly, several network traces from traffic generated when videos are watched in devices are collected. User’s traffic goes through theVirtual Proxy module, whereTstat monitors the traffic to obtain traces. Secondly, theTraffic Control (TC) is used to generate random disturbances for each user. The objective pursued is to cause different congestion situations to obtain information about the degradation situations produced. As a result, the user has to label the QoE of the service, that is, they will be asked about their quality of experience. In theLabel Provider component, each user evaluates three possible QoE levels:Good,Medium, andBad. Then, this information is combined with the traffic traces generated by the user.For the experiment, a total of328,708 video traces were obtained using the method presented above. Notice thatTstat generates 114 different variables. Thus, before using theCluster Generator component to group the traces, it is necessary to filter the data and select those variables with relevant information. TheKPI Selector component is used for this purpose.Following the state-of-the-art for QoE [43, 44], the ensuing variables are selected according to the domain knowledge:(i)
PCK.ALL (s_pkts_all according toTstat): total number of packets sent by the video server during the connection.(ii)
PCK.RES (s_pkts_retx): number of packets retransmitted from the server.(iii)
PCK.UNK (s_pkts_unk): number of packets not in sequence or duplicated.(iv)
RTT (s_rtt_avg): round-trip time. This is the time needed for a package to be sent plus the time needed for an acknowledgment of the package to be received.(v)
BYTES (s_bytes_all): total number of bytes sent.(vi)
DURATION (durat): timestamp of the connection.From these variables, the following KPIs are defined (see Table1):(i)
Ratio of Missing Packets (RMP): percentage of missing, and forwarded, packets during connection.(ii)
Ratio of Unknown Packets (RUP): percentage of packets not in sequence or duplicated which are not classified as specific events.(iii)
LATENCY: the average RTT.(iv)
BANDWIDTH: the data transmission rate, number of bytes per second that have been transmitted during the connection.Table 1
KPIs obtained in the data analysis.
Variable Expression RMP PCK.RES/PCK.ALL RUP PCK.UNK/PCK.ALL LATENCY RTT BANDWIDTH BYTES/DURATIONThe purpose of these KPIs was as follows. RMP is necessary to being able to detect possible problems experienced by users. It is strongly related to QoE. RUP allows to detect possible packets that arrive later or disordered to the destination. As expected, it is related to situations of degradation where the packets are buffered and then suddenly liberated. LATENCY is the difference between a stimulus and the response to it. In this case, it consists of the average time a packet needs to go from the initial point to the destination. It allows to detect possible delays that affect the QoE. Finally, BANDWIDTH provides information about the performance of the connection. If it is significantly reduced, it could negatively influence the QoE.A dataset of more than300,000 traces, four KPIs and the corresponding QoE label from the users, are obtained. The summary of the collected KPIs is presented in Table 2.Table 2
Summary (mean and standard Deviation) of the KPIs obtained in the data analysis.
Variable Mean Sd RMP 0.18 0.14 RUP 0.12 0.10 LATENCY 3 5 BANDWIDTH 109 83Despite the subjective response of the users (an opinion about the QoE), an unsupervised learning method has been selected. In theCluster Generator component, ak-means clustering algorithm [45] was trained to group the traces based on theEuclidean distance from the KPIs (normalized between 0 and 1). If the obtained clusters are informative, there will be a relationship between the QoE from the user and the labels in each cluster. The classical Elbow method is used to choose the optimal number of clusters in the model [46]. According to this technique, 4 clusters have been selected.Cluster 0 is defined by high values ofRMP and RUP variables. Cluster 1 is defined by high values of RMP and low values of BANDWIDTH. Cluster 2 is defined by low values of RMP, RUP, LATENCY, and BANDWIDTH. Cluster 3 is defined by high values of BANDWIDTH, and low values for the other variables. Thus, clusters 2 and 3 should be associated with high values of QoE, and clusters 0 and 1 should be associated with low values of QoE. At this point, the unsupervised cluster technique is completed with the labels from the users. In clusters 2 and 3, the labelGood is predominant. However, in clusters number 0 and 1 there is a mix between labelsMedium andBad.Following the labels assigned by the users, a global QoE for each of the generated clusters is calculated. In order to produce such a value, a score is assigned to each label following the eleven-grade numeric quality scale proposed by [47].Good is scored as 0.9, andBad is scored as 0.3. TheMedium could be scored as the mean value in the range [0.3,0.9], that is, 0.6. However, in order to bring on early detection of QoE degradation situations,Medium is scored as 0.5 (closer toBad score than toGood score).The users on charge of labeling were illustrated with the meaning of the label before watching the videos.Table3 presents the QoE for each cluster as the weighted average of the labels distribution in the cluster. For instance, the distribution of Good, Medium, and Bad traces in cluster 0 is 0.02%, 71.17%, and 28.80%, respectively. Thus, the global QoE for cluster 0 is calculated as (1)0.90∗0.0002+0.50∗0.7117+0.30∗0.2880=0.44.Table 3
Label distribution and QoE for each cluster in the model.
Cluster Good Medium Bad QoE 0 0.02 71.17 28.80 0.44 1 0.65 46.31 53.03 0.40 2 89.99 6.72 3.28 0.85 3 99.70 0.00 0.28 0.90The global QoE of clusters in Table3 will be used to define the model that will perform the QoE estimation of new video traces. That is, once the training phase has finished, this model is able to achieve the QoE of any video service.


#### 3.2.1. QoE Calculation

The cluster model is a list with the centroids of the four clusters and their global QoE. In order to calculate a prediction for a new trace, the nearest centroid is calculated based on theEuclidean distance between the KPIs of the new trace and the centroids.LetV be a set of T video traces: {ti}i=1T. First, the corresponding cluster (C(ti)) for each trace ti in V is calculated using the KPIs in the trace looking for the nearest cluster centroid. For example, let one consider trace number 1. If the nearest centroid to the KPIs corresponding to trace number 1 is the centroid in cluster 0, then C(t1)=0. Next, the QoE for trace ti (QoE(C(ti)) is calculated as the QoE of the associated cluster using values in Table 3. Thus, the QoE assigned to trace number 1 will be QoE(C(t1))=QoE(0)=0.44. Finally, it is possible to calculate the QoE for the complete set of video traces V as the average of the QoE of all the traces in the set:(2)QoEV=1T∑i=1TQoECti.


## 3.1. QoEMU Framework Architecture

In accordance with the COMPA model, theQoEMU architecture consists of three main modules: theDegradation Detector, thePolicy Manager, and theVirtual Proxy.Degradation Detector. This module supports to the A function in the COMPA model. It is in charge of the real-time analysis of video traffic data from users connected to the network. Regarding the architecture of theDegradation Detector module, it consists of four components: theKPI Selector, theQoE Analyzer, theAlert Notifier, and theQoE Model. This latter is trained using a specific architecture that includes theQoE Model Generator System module. This architecture is explained in detail in Section 3.2 and its scheme is shown in Figure 4.First, theKPI Selector extracts the KPIs from the collected network traces. Next, theQoE Analyzer uses a nonsupervised ML algorithm to split up the dataset in heterogeneous groups. The main idea is to collect traffic data with similar QoE in the same cluster and compute an average QoE. TheDegradation Detector module is able to analyze the QoE of a set of traces collected during a time window in real time and detect a degradation situation. When the average QoE of the traces in a time window is under a threshold (δdeg), a degradation situation is considered to occur. Then, theDegradation Detector module sends an alert to thePolicy Manager module. The alert includes the average QoE and the location where the degradation has been detected. When an alert about a degradation situation is sent to thePolicy Manager, a session is created in such module. Since it is possible to detect multiple degradation situations in different locations, they will be treated by thePolicy Manager in different sessions. While a degradation situation in a given location persists, theDegradation Detector module keeps on periodically sending information about the evolution of the average QoE. However, it is stateless and therefore not aware of the sessions kept by thePolicy Manager.Policy Manager. This module supports the P function in COMPA. It consists of two components: thePolicy Engine and theDegradation Sessions Database. The first one makes decisions based on the alerts received from theDegradation Detector and decides which mitigation actions have to be enforced by the COM function. TheDegradation Sessions Database maintains information of the active degradation sessions (mobile devices IPs). A search is performed on the database when an alert from theDegradation Detector is received. If a degradation session is located at the same location, it means that the degradation continues and has already been alerted (has an associated session). According to its policies, thePolicy Engine may decide to update the mitigation plans being enforced.During the conversation between theDegradation Detector and thePolicy Manager modules, two different situations can be distinguished:(i)
If the average QoE is greater than or equal to a threshold (≥δdeg), it could mean two different things. If there is a degradation session in the same location, this means that the degradation situation has just finished. On the other hand, if the locations are different the QoE is directly considered as satisfactory.(ii)
If the average QoE is strictly lower than a threshold (<δdeg) and a degradation session exists in the same location, the degradation continues and thePolicy Manager module has been alerted. In contrast, a new degradation situation has been detected and an alert is sent to thePolicy Manager module. At this point, this module generates a session identifier and stores information about the date, the time, the degradation location, and the average QoE. When a session begins, a specific mitigation plan is selected for that session.The message exchange between theDegradation Detector and thePolicy Manager is based on a Representational State Transfer (REST) interface [38]. ThePolicy Manager only provides REST interfaces and, therefore, cannot be directly plugged to theMessage Broker component. As theDegradation Detector plays the role of a message producer according to a Kappa architecture, an adapter (thePolicy Manager Adapter) is required. It plays a message consumer role when receiving alerts from theDegradation Detector while, at the same time, implements a REST client interface towards thePolicy Engine component.Figure3 presents an example of the messages between theDegradation Detector module (A), and thePolicy Manager module (P), when a degradation situation is detected. For the sake of simplicity, it is represented as an end-to-end REST exchange.Figure 3
Sequence diagram for a degradation situation.Figure 4
QoE Model Generator System.Virtual Proxy. This module supports the COM function in COMPA. It is aware of what type of user each IP address belongs to, so that it can apply different policies. It implements two main tasks. The first one handles the traffic towards theVLC Video Server, captures traffic information (network traces), and forwards it to theDegradation Detector. The second executes the mitigation actions invoked by thePolicy Manager to alleviate the degradation.Regarding the architecture of this module, it consists of three software components:HAProxy,TC (Traffic Control), andTstat [39]. Once thePolicy Manager has decided which mitigation actions have to be enforced, they are communicated to theVirtual Proxy for being applied. TheHAProxy provides HTTP and TCP proxy capabilities. It allows, among other things, a high availability and load balancing [40]. It is in charge of rerouting the incoming HTTP traffic to the Video Server to enable the capture of network traces.Tstat is an automated tool for passive monitoring [41]. It provides traffic monitoring up to Gigabits per second using off-the-shelf hardware and offers a passive sniffer functionality of traffic. Additionally, it is capable of analyzing these traces to provide multiple KPIs, concerning connections, at both the network and transport level [37].TheTC configures the Linux kernel packet scheduler which acts as a bandwidth regulator. It allows controlling the way packets are handled in network interfaces. The main feature, as per theVirtual Proxy which is involved, is the rate of handled packets. Thus, it is possible to characterize traffic and create rules to assign a bandwidth for each type of service or range of IPs [42]. A bandwidth limitation functionality will be used when needed for video users connected to theVirtual Proxy.When thePolicy Manager decides which mitigation actions have to be enforced and creates a degradation session, theVirtual Proxy module is informed to implement the mitigation plan. Message exchange between them is based on REST as well. The mitigation plan activation orders sent to theVirtual Proxy should include information about the start and end of the plan, the mitigation actions to perform for each type of user and the location in which the plan is going to be applied.After applying a mitigation plan, theDegradation Detector module keeps on receiving network trace information and an average QoE is continuously computed. The evolution of this indicator is received by thePolicy Manager, which evaluates whether the degradation situation continues. If that is the case, it informs theVirtual Proxy module to carry on the mitigation plan. However, if thePolicy Manager module detects that the degradation has finished, it informs theVirtual Proxy module to cancel the plan and discards the degradation session record in its database.


## 3.2. QoE Model Generator System

As mentioned before, theDegradation Detection module of theQoEMU framework (see Figure 2) uses theQoE Model. It implements a ML model able to discriminate between network traces and compute an average QoE. This component has been built using the architecture presented in Figure 4.A controlled experiment with several users is performed to generate theQoE Model. It uses an alternative architecture that comprises three modules: theVirtual Proxy, theVideo Local Server, and theQoE Model Generator System. Notice that this architecture is not used by theQoEMU framework since it is only in charge of generating theQoE Model.Firstly, several network traces from traffic generated when videos are watched in devices are collected. User’s traffic goes through theVirtual Proxy module, whereTstat monitors the traffic to obtain traces. Secondly, theTraffic Control (TC) is used to generate random disturbances for each user. The objective pursued is to cause different congestion situations to obtain information about the degradation situations produced. As a result, the user has to label the QoE of the service, that is, they will be asked about their quality of experience. In theLabel Provider component, each user evaluates three possible QoE levels:Good,Medium, andBad. Then, this information is combined with the traffic traces generated by the user.For the experiment, a total of328,708 video traces were obtained using the method presented above. Notice thatTstat generates 114 different variables. Thus, before using theCluster Generator component to group the traces, it is necessary to filter the data and select those variables with relevant information. TheKPI Selector component is used for this purpose.Following the state-of-the-art for QoE [43, 44], the ensuing variables are selected according to the domain knowledge:(i)
PCK.ALL (s_pkts_all according toTstat): total number of packets sent by the video server during the connection.(ii)
PCK.RES (s_pkts_retx): number of packets retransmitted from the server.(iii)
PCK.UNK (s_pkts_unk): number of packets not in sequence or duplicated.(iv)
RTT (s_rtt_avg): round-trip time. This is the time needed for a package to be sent plus the time needed for an acknowledgment of the package to be received.(v)
BYTES (s_bytes_all): total number of bytes sent.(vi)
DURATION (durat): timestamp of the connection.From these variables, the following KPIs are defined (see Table1):(i)
Ratio of Missing Packets (RMP): percentage of missing, and forwarded, packets during connection.(ii)
Ratio of Unknown Packets (RUP): percentage of packets not in sequence or duplicated which are not classified as specific events.(iii)
LATENCY: the average RTT.(iv)
BANDWIDTH: the data transmission rate, number of bytes per second that have been transmitted during the connection.Table 1
KPIs obtained in the data analysis.
Variable Expression RMP PCK.RES/PCK.ALL RUP PCK.UNK/PCK.ALL LATENCY RTT BANDWIDTH BYTES/DURATIONThe purpose of these KPIs was as follows. RMP is necessary to being able to detect possible problems experienced by users. It is strongly related to QoE. RUP allows to detect possible packets that arrive later or disordered to the destination. As expected, it is related to situations of degradation where the packets are buffered and then suddenly liberated. LATENCY is the difference between a stimulus and the response to it. In this case, it consists of the average time a packet needs to go from the initial point to the destination. It allows to detect possible delays that affect the QoE. Finally, BANDWIDTH provides information about the performance of the connection. If it is significantly reduced, it could negatively influence the QoE.A dataset of more than300,000 traces, four KPIs and the corresponding QoE label from the users, are obtained. The summary of the collected KPIs is presented in Table 2.Table 2
Summary (mean and standard Deviation) of the KPIs obtained in the data analysis.
Variable Mean Sd RMP 0.18 0.14 RUP 0.12 0.10 LATENCY 3 5 BANDWIDTH 109 83Despite the subjective response of the users (an opinion about the QoE), an unsupervised learning method has been selected. In theCluster Generator component, ak-means clustering algorithm [45] was trained to group the traces based on theEuclidean distance from the KPIs (normalized between 0 and 1). If the obtained clusters are informative, there will be a relationship between the QoE from the user and the labels in each cluster. The classical Elbow method is used to choose the optimal number of clusters in the model [46]. According to this technique, 4 clusters have been selected.Cluster 0 is defined by high values ofRMP and RUP variables. Cluster 1 is defined by high values of RMP and low values of BANDWIDTH. Cluster 2 is defined by low values of RMP, RUP, LATENCY, and BANDWIDTH. Cluster 3 is defined by high values of BANDWIDTH, and low values for the other variables. Thus, clusters 2 and 3 should be associated with high values of QoE, and clusters 0 and 1 should be associated with low values of QoE. At this point, the unsupervised cluster technique is completed with the labels from the users. In clusters 2 and 3, the labelGood is predominant. However, in clusters number 0 and 1 there is a mix between labelsMedium andBad.Following the labels assigned by the users, a global QoE for each of the generated clusters is calculated. In order to produce such a value, a score is assigned to each label following the eleven-grade numeric quality scale proposed by [47].Good is scored as 0.9, andBad is scored as 0.3. TheMedium could be scored as the mean value in the range [0.3,0.9], that is, 0.6. However, in order to bring on early detection of QoE degradation situations,Medium is scored as 0.5 (closer toBad score than toGood score).The users on charge of labeling were illustrated with the meaning of the label before watching the videos.Table3 presents the QoE for each cluster as the weighted average of the labels distribution in the cluster. For instance, the distribution of Good, Medium, and Bad traces in cluster 0 is 0.02%, 71.17%, and 28.80%, respectively. Thus, the global QoE for cluster 0 is calculated as (1)0.90∗0.0002+0.50∗0.7117+0.30∗0.2880=0.44.Table 3
Label distribution and QoE for each cluster in the model.
Cluster Good Medium Bad QoE 0 0.02 71.17 28.80 0.44 1 0.65 46.31 53.03 0.40 2 89.99 6.72 3.28 0.85 3 99.70 0.00 0.28 0.90The global QoE of clusters in Table3 will be used to define the model that will perform the QoE estimation of new video traces. That is, once the training phase has finished, this model is able to achieve the QoE of any video service.


### 3.2.1. QoE Calculation

The cluster model is a list with the centroids of the four clusters and their global QoE. In order to calculate a prediction for a new trace, the nearest centroid is calculated based on theEuclidean distance between the KPIs of the new trace and the centroids.LetV be a set of T video traces: {ti}i=1T. First, the corresponding cluster (C(ti)) for each trace ti in V is calculated using the KPIs in the trace looking for the nearest cluster centroid. For example, let one consider trace number 1. If the nearest centroid to the KPIs corresponding to trace number 1 is the centroid in cluster 0, then C(t1)=0. Next, the QoE for trace ti (QoE(C(ti)) is calculated as the QoE of the associated cluster using values in Table 3. Thus, the QoE assigned to trace number 1 will be QoE(C(t1))=QoE(0)=0.44. Finally, it is possible to calculate the QoE for the complete set of video traces V as the average of the QoE of all the traces in the set:(2)QoEV=1T∑i=1TQoECti.


## 3.2.1. QoE Calculation

The cluster model is a list with the centroids of the four clusters and their global QoE. In order to calculate a prediction for a new trace, the nearest centroid is calculated based on theEuclidean distance between the KPIs of the new trace and the centroids.LetV be a set of T video traces: {ti}i=1T. First, the corresponding cluster (C(ti)) for each trace ti in V is calculated using the KPIs in the trace looking for the nearest cluster centroid. For example, let one consider trace number 1. If the nearest centroid to the KPIs corresponding to trace number 1 is the centroid in cluster 0, then C(t1)=0. Next, the QoE for trace ti (QoE(C(ti)) is calculated as the QoE of the associated cluster using values in Table 3. Thus, the QoE assigned to trace number 1 will be QoE(C(t1))=QoE(0)=0.44. Finally, it is possible to calculate the QoE for the complete set of video traces V as the average of the QoE of all the traces in the set:(2)QoEV=1T∑i=1TQoECti.


## 4. Case Study

This section details the evaluation of the proposal to illustrate its viability. It consists of two experiments. The first one, presented in Section4.1, addresses the detection of QoE degradation situations using theQoE Model for different sets of traces. The second experiment, detailed in Section 4.2, presents the complete process achieved by theQoEMU framework in order to detect a QoE degradation situation and illustrate how the system reacts activating a proposed mitigation plan to solve the situation. In both cases the degradation threshold δdeg has been fixed at 0.5.


### 4.1. QoE Model Evaluation

In this experiment theQoE Model is evaluated to illustrate its capabilities to calculate the QoE value and detect possible degradation situations. For this purpose, two sets of 10,000 traces from theDellEMC dataset [48] have been selected. Notice that this new dataset has made possible to calculate the needed KPIs to feed theQoE Model.For the first set, any of the traces is assigned to the nearest centroid using theEuclidean distance. The traces were mainly distributed between the clusters 1 and 3. The distribution of traces in the clusters is: 0.13, 0.45, 0.07 and 0.35, respectively (see Table 4). Thus, the resulting QoE value was 0.13∗0.44+0.45∗0.4+0.07∗0.85+0.35∗0.90=0.61. This implies that no degradation situation was detected by theQoE Model. Then, it could be said that the selected traces present a normal behavior and no mitigation plan is needed at this point.Table 4
Distribution of the two sets of traces from theDellEMC in the clusters provided by the QoE Model.
Cluster Set 1 Set 2 0 0.13 0.14 1 0.45 0.53 2 0.07 0.09 3 0.35 0.24For the second set, the traces were distributed similarly to the previous one (i.e., clusters 1 and 3 receives most traces). The distribution was:0.14, 0.53, 0.09 and 0.24 respectively for each one of the clusters. Thus, the resulting QoE value was 0.14∗0.44+0.53∗0.4+0.09∗0.85+0.24∗0.90=0.57 (see Table 4). This implies that no degradation situation was detected by theQoE Model. Nevertheless, the obtained values could be a starting point for a possible degradation situation as it is close to the predefined threshold. However, the most common situation could be a temporary random problem related to the bandwidth.Thus, theQoE Model has been tested using a different dataset of that used to train it. It was able to evaluate the QoE value detecting normal behavior and possible degradation situations in traces.


### 4.2. Complete Framework Evaluation

In order to evaluate the performance of the completeQoEMU framework, a mobile experiment has been carried out in a laboratory, in which three users watching a video in their devices, connected to different servers through a switch, are monitored. The scheme of the scenario is presented in Figure 5.Figure 5
Excerpt of the scenario scheme in the experiment.The profiles of the users are defined based on the priority they have on resource sharing in degradation situations. The category of each user is different:Gold, who is a premier user whose connection should be as good as possible most of the time;Silver, who is an user with a medium quality type of connection; andBronze, who is an user with the worst type of connection that could be penalized to improve the global performance. Each user is connected to an IP address and receives the video streaming as shown in Figure 6.Figure 6
Users connected to an IP direction.In this particular case, the mitigation plan designed consists of a limitation of the user bandwidth:Gold is granted 3Mbps,Silver is granted 1Mbps andBronze only receives 64Kbps. With this mitigation action, theGold user will watch the video normally; theSilver user will experience some difficulties, although, in general, the video can be properly watched; and theBronze user will have frequent problems to visualize the video.TheQoE Analyzer component in theDegradation Detector module (see Figure 2) estimates the QoE using a time-based sliding window operator. The window duration is 30 seconds and the slide duration is 10 seconds (see Section 3). That is, the QoE calculation (as explained in Section 3.2.1) is achieved in 10-second batches of traces and the window considers the last 30 seconds of traces (i.e., the current batch together with the two previous batches). An alert will be generated when the QoE value of the traces are under the previously fixed degradation threshold (i.e., δdeg=0.5).When users begin to reproduce the video, the traffic traces are sent to theDegradation Detector module to analyze them and obtain the corresponding KPIs, which represent the global QoE of each set of traces generated by users. In the beginning, visualization is perfect and each user enjoys watching the video. This situation is represented in Figure 7, and at first 50 seconds in Figure 10.Figure 7
The three users watching the video with similar quality.After45 seconds, an artificial congestion in the traffic is generated. Thus, a limit in the bandwidth is applied to all the users. This action generates several problems and, consequently, users start to have troubles in their visualizations. The QoE decreases, as shown in Figures 8 and 10.Figure 8
Users suffering a degradation.Next, this action implies a reduction in the QoE given by theDegradation Detector module under the fixed threshold (δdeg). This happens 60 seconds after the start of the video.When this information arrives at theDegradation Detector module, it detects a degradation situation and generates an alert. The alert is received by thePolicy Manager module which, according to the policies it has configured, chooses a mitigation plan to alleviate the undesired situation. The plan comprises bandwidth regulation actions, which are sent to theVirtual Proxy module, responsible for applying it.When the degradation situation has finished, the mitigation action is deactivated and the three users watch the video without issues, as shown in Figure9. This happens 110 seconds after the start of the video (see Figure 10).Figure 9
The mitigation plan has ended and all the bandwidth of the users will be restored.Figure 10
QoE for the traces in the experiment. Green line indicates the start of the artificially generated congestion. Red line indicates the QoE threshold.Thus, a complete experiment usingQoEMU framework has been developed applying specific mitigation actions to solve a congestion traffic issue.Notice that the global performance of the system relies on two main configuration parameters: the thresholdδdeg for the QoE and the mitigation policy action. In this case, the threshold was fixed to 0.5. However, if a higher value was selected (for instance 0.75), the artificial degradation would be detected earlier. This implies increasing the risk of false alarms (false detection of degradation situations). Since the bandwidth regulation action mainly affectsBronze users, they will have a lot of problems to visualize the video, that could be avoided with a proper system configuration. Regarding the mitigation plan, it depends on the network capabilities. Thus, if it would be possible to grant a high bandwidth for each user profile (equals to the applied one for theGold users), it is clear that the system will be restored earlier. However, this plan depends mainly on the business domain model.


## 4.1. QoE Model Evaluation

In this experiment theQoE Model is evaluated to illustrate its capabilities to calculate the QoE value and detect possible degradation situations. For this purpose, two sets of 10,000 traces from theDellEMC dataset [48] have been selected. Notice that this new dataset has made possible to calculate the needed KPIs to feed theQoE Model.For the first set, any of the traces is assigned to the nearest centroid using theEuclidean distance. The traces were mainly distributed between the clusters 1 and 3. The distribution of traces in the clusters is: 0.13, 0.45, 0.07 and 0.35, respectively (see Table 4). Thus, the resulting QoE value was 0.13∗0.44+0.45∗0.4+0.07∗0.85+0.35∗0.90=0.61. This implies that no degradation situation was detected by theQoE Model. Then, it could be said that the selected traces present a normal behavior and no mitigation plan is needed at this point.Table 4
Distribution of the two sets of traces from theDellEMC in the clusters provided by the QoE Model.
Cluster Set 1 Set 2 0 0.13 0.14 1 0.45 0.53 2 0.07 0.09 3 0.35 0.24For the second set, the traces were distributed similarly to the previous one (i.e., clusters 1 and 3 receives most traces). The distribution was:0.14, 0.53, 0.09 and 0.24 respectively for each one of the clusters. Thus, the resulting QoE value was 0.14∗0.44+0.53∗0.4+0.09∗0.85+0.24∗0.90=0.57 (see Table 4). This implies that no degradation situation was detected by theQoE Model. Nevertheless, the obtained values could be a starting point for a possible degradation situation as it is close to the predefined threshold. However, the most common situation could be a temporary random problem related to the bandwidth.Thus, theQoE Model has been tested using a different dataset of that used to train it. It was able to evaluate the QoE value detecting normal behavior and possible degradation situations in traces.


## 4.2. Complete Framework Evaluation

In order to evaluate the performance of the completeQoEMU framework, a mobile experiment has been carried out in a laboratory, in which three users watching a video in their devices, connected to different servers through a switch, are monitored. The scheme of the scenario is presented in Figure 5.Figure 5
Excerpt of the scenario scheme in the experiment.The profiles of the users are defined based on the priority they have on resource sharing in degradation situations. The category of each user is different:Gold, who is a premier user whose connection should be as good as possible most of the time;Silver, who is an user with a medium quality type of connection; andBronze, who is an user with the worst type of connection that could be penalized to improve the global performance. Each user is connected to an IP address and receives the video streaming as shown in Figure 6.Figure 6
Users connected to an IP direction.In this particular case, the mitigation plan designed consists of a limitation of the user bandwidth:Gold is granted 3Mbps,Silver is granted 1Mbps andBronze only receives 64Kbps. With this mitigation action, theGold user will watch the video normally; theSilver user will experience some difficulties, although, in general, the video can be properly watched; and theBronze user will have frequent problems to visualize the video.TheQoE Analyzer component in theDegradation Detector module (see Figure 2) estimates the QoE using a time-based sliding window operator. The window duration is 30 seconds and the slide duration is 10 seconds (see Section 3). That is, the QoE calculation (as explained in Section 3.2.1) is achieved in 10-second batches of traces and the window considers the last 30 seconds of traces (i.e., the current batch together with the two previous batches). An alert will be generated when the QoE value of the traces are under the previously fixed degradation threshold (i.e., δdeg=0.5).When users begin to reproduce the video, the traffic traces are sent to theDegradation Detector module to analyze them and obtain the corresponding KPIs, which represent the global QoE of each set of traces generated by users. In the beginning, visualization is perfect and each user enjoys watching the video. This situation is represented in Figure 7, and at first 50 seconds in Figure 10.Figure 7
The three users watching the video with similar quality.After45 seconds, an artificial congestion in the traffic is generated. Thus, a limit in the bandwidth is applied to all the users. This action generates several problems and, consequently, users start to have troubles in their visualizations. The QoE decreases, as shown in Figures 8 and 10.Figure 8
Users suffering a degradation.Next, this action implies a reduction in the QoE given by theDegradation Detector module under the fixed threshold (δdeg). This happens 60 seconds after the start of the video.When this information arrives at theDegradation Detector module, it detects a degradation situation and generates an alert. The alert is received by thePolicy Manager module which, according to the policies it has configured, chooses a mitigation plan to alleviate the undesired situation. The plan comprises bandwidth regulation actions, which are sent to theVirtual Proxy module, responsible for applying it.When the degradation situation has finished, the mitigation action is deactivated and the three users watch the video without issues, as shown in Figure9. This happens 110 seconds after the start of the video (see Figure 10).Figure 9
The mitigation plan has ended and all the bandwidth of the users will be restored.Figure 10
QoE for the traces in the experiment. Green line indicates the start of the artificially generated congestion. Red line indicates the QoE threshold.Thus, a complete experiment usingQoEMU framework has been developed applying specific mitigation actions to solve a congestion traffic issue.Notice that the global performance of the system relies on two main configuration parameters: the thresholdδdeg for the QoE and the mitigation policy action. In this case, the threshold was fixed to 0.5. However, if a higher value was selected (for instance 0.75), the artificial degradation would be detected earlier. This implies increasing the risk of false alarms (false detection of degradation situations). Since the bandwidth regulation action mainly affectsBronze users, they will have a lot of problems to visualize the video, that could be avoided with a proper system configuration. Regarding the mitigation plan, it depends on the network capabilities. Thus, if it would be possible to grant a high bandwidth for each user profile (equals to the applied one for theGold users), it is clear that the system will be restored earlier. However, this plan depends mainly on the business domain model.


## 5. Conclusions

One of the main problems of mobile networks are QoE degradation situations. In this paper, theQoEMU framework has been presented and tested.QoEMU is an automated system for the analysis of network traffic, the detection of degradation in the Quality of Experience of user, and the generation and application of mitigation actions to alleviate adverse effects. All these tasks are achieved using an architecture based on the COMPA model.The architecture ofQoEMU implies three main modules. TheDegradation Detector module, that corresponds to theAnalytics module in COMPA, generates alerts based on theQoE Model previously generated. ThePolicy Manager module corresponds to thePolicies module in the COMPA architecture. TheVirtual Proxy module corresponds to theControl, Orchestration and Management function in the COMPA model. It executes the mitigation actions to solve the detected degradation.In order to train theQoE Model, a specific architecture has been used. An experiment with more than 300,000 labeled traces was performed. Using ML techniques, theQoE Model has been able to predict the QoE of a set of traces.TheQoEMU framework has been tested with several video users in laboratory experiments. A degradation in the QoE has been generated based on an artificial congestion in the traffic. TheQoEMU framework was able to detect the generated degradation and manage it through an adequate mitigation action. Thus, a mitigation plan was designed based on the different profiles. Once the degradation situation was corrected, the plan was deactivated.As future work, the presentedQoE Model could be upgraded by including the opinions of a higher number of experts. In such a case, a method to integrate several opinions into a unique ground truth should be considered [49, 50]. In order to implement theQoEMU framework in production, different test batteries are mandatory (e.g., stress testing) and a cooperation between the Over-The-Top (OTTS) and Internet Service Providers (ISPs) is needed [51]. Furthermore, a graphical real-time statistics tool will be implemented. For this purpose, a server will be deployed to predict, in real time, the value of the QoE and communications between different components. It could be also interesting to measure the predictive capabilities of the system. In addition, more specific distances among KPIs, different to theEuclidean distance, could be considered for the calculation of the QoE.



---

*Source: 2352941-2019-01-01.xml*