# Crowdsourcing Based Performance Analysis of Mobile User Heterogeneous Services
## 5 Use Cases
### Use Case 3: Impact of Radio Parameters on the Video Metrics and User QoE  
As already discussed in Section 2, we are interested in studying the impact of the radio parameters on fixed HD video quality streaming over the 4G mobile network. In particular, we would like to evaluate the impact of the three radio signal references (RSRP, RSRQ and RSSNR) on both the user MOS and the video KQI (i.e., bitrate and launch time). In other words, can we, based on these three physical parameters (RSRP, RSRQ and RSSNR), predict the video streaming performance (MOS and KQI)? To give a good answer to this question, we aim at training several machine learning models that take as input features these three parameters and gives as output the targeted video metrics (MOS, the bitrate, and the launch time). It is straightforward to train and predict the bitrate and the launch time with ML regressors as we have everything in our dataset. However, we do not measure directly in our campaign the user's MOS, so we need to build this feature in the dataset for every video session before to build and train any regressor. To that end, we calculate the MOS based on key models from literature. In fact, two approaches do exist in the state of the art to compute the MOS value. The first (\(MOS_{quality}\)) is based on the bitrate video values like in [21; 22], and the second (\(MOS_{buffer}\)) is based on the buffer information like in [23; 24]. We will denote by (\(user\_mos\)) the user's MOS score that is the minimum calculated MOS value from both approaches for each video session (we have 746 completed video sessions). We consider here the worst case of perceived quality between the buffer-based MOS and bitrate-based one. In the remainder of this part, we explain the implementation of the various steps of our prediction evaluation using the dataset [30]. Thus, to begin, let \(BR\), \(T_{init}\), \(T_{rebuf}\), and \(f_{rebuf}\) denote the bitrate video, initial buffering time, rebuffering duration, and rebuffering frequency, respectively. Based on the study [22], we achieve the video MOS from bitrate video as follows (1):  
\[MOS_{quality}=f_{literature}(BR,\,Resolution) \tag{1}\]  
The idea is to achieve the MOS score continuously for HD video resolution over the interval 0 and 9 Mbps as shown in Table 10. In fact, the MOS is considered excellent (with 5 value) when the bitrate is larger than 9 Mbps. \begin{table}
\begin{tabular}{l l l l l} \hline \hline
**Bitrate (kbits/s)** & **110 to 500** & **500 to 1050** & **1050 to 2250** & **2250 to 9000** \\ \hline MOS & 1 to 2 & 2 to 3 & 3 to 4 & 4 to 5 \\ \hline \hline \end{tabular}
\end{table} 
Table 10: HD video MOS versus Bitrate. Concerning the second approach, we implement the provided relationship between QoE and buffer information as in [24]. The used formula is given below in Equation (2):  
\[MOS_{buffer}=4.23-0.0672*L_{ti}-0.742 Lfr*L_{fr}-0.106*L_{tr} \tag{2}\]  
where \(L_{ti}\), \(L_{fr}\), and \(L_{tr}\) are the respective levels of \(T_{init}\), \(T_{rebuf}\) and \(f_{rebuf}\) as defined in [23; 24], where the authors use 1, 2, and 3 to encode the \"low\", \"medium\", and \"high\" levels, respectively. Therefore, we achieve the overall user's MOS score by using the below equation that implements \(Minimum\ (min)\) function as mentioned above:  
\[user\_mos=min(MOS_{buffer},MOS_{quality}) \tag{3}\]  
Once the MOS scores are calculated, our dataset is ready for the training and the prediction phases using four ML regressors. We aim at predicting, on one hand, the calculated MOS scores, and, on the other hand, the video KQI (bitrate and launching time). We consider here Random forest (RF), Decision tree (DT), K-nearest neighbors (KNN), and Gradient Tree Boosting (GTB), and we test many hyper-parameters configurations described in Table 11). During the hyper parameter tuning step, the results are validated using a 5-fold cross-validation method using Python \"scikit-learn\" package, where the data are divided into 80% for training and 20% for testing.