While we have discussed how to avoid service disruption in general, there will be times when issues arise. When they do, it's essential to ensure that they are resolved as quickly as possible, so that any resulting disruption is minimized. “Mean-time-to-repair” (MTTR) is thus a key metric and reducing this is a key strategic imperative. To do so, an optimized service assurance platform and processes are essential. In the last of this series of articles, we explore how this can be achieved and the necessary requirements that should be in place.
To reduce MTTR to a minimum, a service assurance platform should provide:
Real-time awareness: 24/7 service monitoring, detecting problems as they arise. It should be possible to assign priorities, so that when an issue matches criteria that define it as critical, it is reported within only a few seconds. Monitoring should be multi-layer, with test cases covering the full range of services and the performance of the most important elements involved. Reporting interfaces should be easily accessible and also usable by non-experts to enable operations teams to rapidly understand problems in an immature environment.
Root cause analysis and support for problem resolution: enabling the triage and diagnosis of issues, ideally by utilizing data from across the service infrastructure, covering RAN, EPC and IMS domains, and allowing the isolation of issues that relate to devices, network elements or the service itself. Sufficient detail should be available to engineers, so that they can resolve issues and, where possible (e.g., provisioning issues), permit the automatic resolution of issues.
Insight from outside the network: an active monitoring solution utilizes terminal devices (real and virtual) to provide end-to-end monitoring of service QoE (awareness), together with diagnosis of issues, including root cause analysis obtained from passive signaling solutions, enabling appropriate action to be taken.
Insight from Inside the network: an optimized service assurance platform will be able to perform multi-layer monitoring of the service and the IMS core. In the context of virtualized network functions, the solution will ensure that each domain and element is performing as expected. Regression testing of virtual element instances ensures resources are correctly set up. 24/7 monitoring detects malfunctions and performance issues and provides historical trend data, enabling the organization to understand the relationship between element performance and QoE, and to predict issues before they occur. Monitoring is performed both in the same location (physical location) as the virtual function to ensure that, for example, the vIMS is performing as expected, as well as remotely to the virtual function to ensure it is reachable from other areas.
The net result is a complete view of service performance, proactive prevention and much faster resolution of issues, combined with the ability to continuously improve the experience for customers.
To learn more about network impact due to virtualization or VoLTE implementation, why not get in touch with our team?
While we have discussed how to avoid service disruption in general, there will be times when issues arise. When they do, it's essential to ensure that they are resolved as quickly as possible, so that any resulting disruption is minimized. “Mean-time-to-repair” (MTTR) is thus a key metric and reducing this is a key strategic imperative. To do so, an optimized service assurance platform and processes are essential. In the last of this series of articles, we explore how this can be achieved and the necessary requirements that should be in place.
To reduce MTTR to a minimum, a service assurance platform should provide:
Real-time awareness: 24/7 service monitoring, detecting problems as they arise. It should be possible to assign priorities, so that when an issue matches criteria that define it as critical, it is reported within only a few seconds. Monitoring should be multi-layer, with test cases covering the full range of services and the performance of the most important elements involved. Reporting interfaces should be easily accessible and also usable by non-experts to enable operations teams to rapidly understand problems in an immature environment.
Root cause analysis and support for problem resolution: enabling the triage and diagnosis of issues, ideally by utilizing data from across the service infrastructure, covering RAN, EPC and IMS domains, and allowing the isolation of issues that relate to devices, network elements or the service itself. Sufficient detail should be available to engineers, so that they can resolve issues and, where possible (e.g., provisioning issues), permit the automatic resolution of issues.
Insight from outside the network: an active monitoring solution utilizes terminal devices (real and virtual) to provide end-to-end monitoring of service QoE (awareness), together with diagnosis of issues, including root cause analysis obtained from passive signaling solutions, enabling appropriate action to be taken.
Insight from Inside the network: an optimized service assurance platform will be able to perform multi-layer monitoring of the service and the IMS core. In the context of virtualized network functions, the solution will ensure that each domain and element is performing as expected. Regression testing of virtual element instances ensures resources are correctly set up. 24/7 monitoring detects malfunctions and performance issues and provides historical trend data, enabling the organization to understand the relationship between element performance and QoE, and to predict issues before they occur. Monitoring is performed both in the same location (physical location) as the virtual function to ensure that, for example, the vIMS is performing as expected, as well as remotely to the virtual function to ensure it is reachable from other areas.
The net result is a complete view of service performance, proactive prevention and much faster resolution of issues, combined with the ability to continuously improve the experience for customers.
To learn more about network impact due to virtualization or VoLTE implementation, why not get in touch with our team?
