While it’s quite obvious for Quality of Experience (QoE) management to include the collection and aggregation of end-users’ session records, there have been quite some occasions where teams have learned that there’s more data sources and insights required to measure and optimize QoE.
As such, the goal for today’s blog is to introduce some of the other aspects that need to be covered to assure the platform can support all aggregations as required, mask all impact as associated with planned activities and safeguard the ability to immediately act on findings. All of these are essential to measure and optimize QoE for the end user with minimal capital and human resources.
First of all, it’s essential for the QoE platform to cover your entire services portfolio. Consumers buy a bundle of services and rate their experience to the bundle, not to the individual service. This is also one of the key reasons why a single service data collector will never do the job for you.
Next, there’s the need for the platform to support not only CPE data sources, but also your entire delivery ecosystem, such as headends, core IP networks, CDNs and access networks. The ecosystem is under constant evolution as a result of continuous technology migrations, architecture changes or service group reduction. The QoE management system is required to account for this of course. Any change in the network configuration impacts end user’s QoE (e.g. remapping of users into updated service groups).
There are also bigger network evolutions, consider e.g. an IPTV platform designed to support an “on-net” delivery to set-top boxes that is extended to also support “off-net” media delivery to mobile phones and tablets. Without doubt, consumers rate their QoE regardless of what device they use, where they are, and at what time. Consequently, a QoE platform must support collection and aggregation of QoE data from the entire eco-system; from service acquisition or origination, to fixed/mobile distribution networks and fixed/mobile CPE.
For the “on-net” service delivery scenario, it is critical that the topology as used for data aggregation truly reflects the actual. That implies that it’s impossible to proceed on a single ingest of network topology data. At the very least, it requires regular updates out of the database holding all information on the topology of the network as built. But it’s even better to interface also with your planned network maintenance application, so you can mask alarms and suspend QoE data processing in the regions and of customers whom you know will be impacted by the network maintenance.
When you fail to do so, you risk drowning in alarms that have no value as they go back to events that you have scheduled yourself. But equally so, QoE stats will be inevitably corrupted, and negatively impact your chances to conclude and act on the platform’s actual status.
For “off-net” and “service delivery to mobile devices” scenarios, it is essential to capture KPI’s from the different network providers, understand their network type and topology, but also get information about the end-user’s device type, player or operating system version. Not having a data lake with this variety of data sources has a negative impact on the visibility of service availability, performance and consumer’ QoE. Adding to that, without this data, operators are challenged to find root-causes of service degradations and outages. Without doubt, this will in its turn negatively affect your ability to define the actions required to improve QoE where needed.
All of these reasons above illustrate the value of a platform like DataMiner, which can interface with all probes and QoE collectors, topology and subscriber databases, and OSS platforms. Using DataMiner, operators get 360° insights in the entire operations, network performance and consumer experience. As a result, DataMiner is the platform operators use to continuously optimize QoE while maximizing the utilization of the network inventory. DataMiner gives you the ROI you expect!
*“On-net”: “On-net” delivery refers to delivery of service across access infrastructure that is owned/managed by the operator. It’s not necessary for this infrastructure to be entirely integrated, the topology shall be known to the QoE platform.
*“Off-net”: “Off-net” delivery refers to delivery of service outside of the operator’s owned/managed access infrastructure. Examples here could be: while roaming on a partner mobile network or using a community 3rd WI-FI network. That’s an essential difference compared to the “on-net” scenario when the topology is unknown.
Thanks Dominique – nice article!