The necessity to monitor Network Services in the 5G ecosystem

In the next years, 5G infrastructure will become a ubiquitous, flexible and programmable network that will be in the core of every social, business and cultural process, enabling both economic growth and social prosperity. However, the 5G vision poses significant technical challenges that must be fulfilled, including the concept of agile programmability and supporting the introduction of management mechanisms for the efficient instantiation of innovative services across heterogeneous network components, virtualized infrastructures and geographically dispersed cloud environments.

One of the important issues to be addressed in this new era of 5G service management is related to network and service monitoring, demanding for collecting data, extracting information and automatically drive corrective actions related to the performance and usage of the resources involved in the lifecycle management of 5G services. However, the already available monitoring tools do not achieve the requirements stemming from the services envisioned in the 5G landscape, since they are in most of the cases:
• intrusive and heavy-handed for short-lived, lightweight network function instances,
• not able to follow the fast pace of management changes enforced by continuous dynamic scheduling, provisioning and auto-scaling,
• not covering the requirements of all the involved emerging technologies, including deployments in both hypervisor-based and containerized manner (from kubernetes to unikernels), as well as monitoring data collection from different cloud environments.
In the next sections, we provide insight on the monitoring concepts and implementation strategies that have been followed by the most active MANO open source communities.

Methodologies and technologies used by open source MANOs

Open Source MANO (OSM)

OSM introduced the monitoring module, in an experimental mode in release three. One of the guiding principles for the OSM Monitoring Module (MON) is that it is required to interface with and leverage existing or new monitoring systems and not to replicate or compete with those systems. In the current release (five), Monitoring Module became part of the OSM ecosystem and contains the definition of alarms and metrics that OSM can process implemented by a tool plugin which is responsible for translating alarms and metrics from the innate format of the NFVI monitoring tool into the format that OSM interprets. The collected metrics and events are published in Apache Kafka bus in order to be consumed from Service Orchestrator or from external tools (such as Prometheus, Grafana). OSM monitoring provides the ability to correlate telemetry related to the VMs and VNFs to the relevant Network Services, while its development roadmap includes the automated process of task execution based on monitoring events (for example scaling out/in action from OSM SO).

Open Platform for NFV (OPNFV)

Considering that OPNFV facilitates the development and the evolution of NFV components consisting the NFVI, the focus moved on monitor, analyze and evaluate the performance of the NFVI in order to deliver a service assurance framework aligned to requirements of a carrier-grade telecom operator. Several projects within OPNFV approach the above aspect from different perspectives. Some of them are a) Yardstick which executes performance tests based on ETSI reference test suites in order to verify the infrastructure compliance when running VNF applications; b) Barometer that captures statistics and events from the components that provide networking functionality to the VNFs and also platform’s status, in order to detect faults, violations or performance degradation; c) VSPERF that provides an automated test framework and comprehensive test suite based on industry standards for measuring data-plane performance which includes switching technologies with physical and virtual network interfaces; d) Bottlenecks that aims at detecting performance system limitations by testing and verifying the OPNFV infrastructure in a staging environment before committing it to a production environment. Thus telecom operators can choose from many monitoring and benchmarking projects the one which is suits better to their requirements.


Open Network Automation Platform (ONAP)

ONAP ecosystem introduced the Data Collection, Analytics and Events (DCAE) sub-system which gathers performance, usage and configuration data about the VNFs and their underlying infrastructure. In case that anomalies or significant events are detected the results trigger appropriate actions to other ONAP components such as Policy, Scaling etc. The collection layer provides various data collectors for both physical and virtual elements and supports both real-time streaming and batch collection. The data collection process is based on Virtual-function Event Streaming (VES) data model which describes a vendor-agnostic common vocabulary of event which is used to drive an automated data analytics within the ONAP DCAE. In this respect, ONAP monitoring approach is that it can be considered as part of a close loop control process which manages the life cycle of the deployed VNFs.


SONATA was the first MANO framework to embrace and integrate a complete monitoring solution based on Prometheus monitoring tool, well before it becomes a Graduated Project of Cloud Native Computing Foundation (CNCF). Furthermore, since SONATA include a monitoring framework from its first version, the consortium realized in an early stage that the monitoring framework must extend in the following ways: a) to facilitate monitoring information from NS/VNF application level b) to correlate and provide all monitoring information coming from VMs with the corresponding NS/VNF and c) to provide a runtime reconfiguration mechanism for monitoring rules in other to support other components like SLA, Policy and Function Service Management (FSM) but also NS/VNF developers. In the current version of SONATA (powered by 5GTango) the monitoring framework provides data for hosts, VMs, containers, networking infrastructure (SDN controllers) and also provides to mechanisms in order to collect application specific metrics from NS/VNFs based on SNMP or the PushGateway provided from Prometheus.

We use cookies to facilitate navigation and improve your experience across our website. By clicking "Accept", you will be storing these cookies.