# QoE Modeling on Split Features with Distributed Deep Learning
### QoE Machine Learning Challenges  
Towards achieving a superior QoE model, a comprehensive user study that covers all possible contexts is required in principle, where the collected datasets are eventually shared publicly to advance reproducible research. Machine learning models might be appealing especially when the corresponding feature set is large and complex with very large datasets [5]. On the other hand, there are data privacy aspects that need to be preserved, hence data may not be copied/transferred, processed, or modeled in a centralized computation node in a _Fully Centralized_ way. Even so, continuous shuffling and transfers of large size sets of raw data is costly and energy-consuming. The overall ML challenges related to QoE modeling are itemized as follows:  
* _Model transfer might be inadequate_: QoE data in the source domain (the domain that trains and sends out the pre-trained model), where the model is developed, and QoE data in the target domain (the domain that receives and uses the pre-trained model received from the source domain), where the model is to be deployed for real operations, need to have a similar data distribution as they need to represent the same underlying conditions and features. The authors of [6] show that when a model is trained with features that are only specific to the source domain, _negative transfer_ (reducing the model performance) can occur, since the specific features at the source domain do not represent the target domain well enough. In addition, model transfer might leak information from the source domain to the target domain since there is no intermediate aggregation process before the target domain receives the model.
* _Privacy-sensitive dataset_: Specific local features in the source domain are potentially sensitive; detailed user profiles, among others, cannot be shared easily [7] without explicit consent. In addition, it may happen that one research group is interested in a QoE model particularly for video contents with high spatio-temporal complexity, e.g., within the scope of developing action games, while another research group is interested in assessing QoE for a different type of video content. At the same time, there might still be a common subset of non-sensitive indicative metrics, i.e., ML_features_, representing the underlying _QoE factors_ in multiple domains or decentralized entities.
* _Distributed user observations with different features_: Model training can be inherently split into multiple partitions in cases when datasets are collected at multiple physically separated computation nodes. A typical example is when operators collect network datasets, while applications collect User Equipment (UE)-specific datasets on the application layers and user interfaces of applications. Another example is that some QoE research entity collects a user dataset with observations that are different from those obtained by other research entities. For example, operators that serve different customer segments, with different preferences and expectations might have different user profiles. These two datasets can be trained on separate models, which are trained only on local features, but collaboratively to improve local model accuracies further with minimally exchanged information in between.