only experience can provide enough of a knowledge base for successful correlations. As an example, it is worth formulating the problem in concrete terms, as follows: QoE KPIs. An end-to-end measurement campaign for streaming with 100 service access requests during the busy hour of a weekday gives the result of a service accessibility of 97 %. QoS KPIs. During the same measurement period, the OSS registers for the aggregated streaming traffic a service accessibility of 99.6 %, out of a total of 5873 service requests. What kind of conclusions can be extracted from those KPIs? Is access to the streaming service perform- ing well or badly? Can the fault be associated with a given fact, geographical location, type of terminal or even type of content accessed within the given service? Answers to these questions can only be given as a result of the correlation of QoS KPIs and QoE KPIs, which will be greatly influenced by local factors and may not easily be generalised. Certainly, as time goes by and operators accumulate experience, these questions will be at least partially solved. In this context, it is worth noting that by measuring QoE KPIs and evaluating them, the problem of improving the QoE, which is the ultimate goal, will not be solved. It is relatively easy in this complex environment to confuse the process with the goal and with the risk of finishing the process short of achieving the goal. Giving a pointer towards a generic cause of bad performance is part of the process (e.g. 97 % of service accessibility is not acceptable as the cause might be in the congested packet core network node). Fully identifying the cause and enabling the solution is certainly closer to achieving the goal (e.g. while the value of 97 % of service accessibility was registered in a given radio access area, the overall aggregated value of 99.6 % of service accessibility strongly suggests that this is closely related to the geographical area where the tests were performed, further investigation showing that the RNC under consideration p