Service assurance is a key enabler for effective automation: It is only possible to control what is being actively monitored. To activate something on the network, it is necessary to know that
something needs to be done – whether because of a fault, mistake, or a breach of a service level or some other defined threshold.
This philosophy is in line with the ETSI’s Zero-touch Service Management (ETSI-ZSM) architecture which identifies the need for a close collaboration between assurance and orchestration to achieve end-to-end service automation. This is the way to manage thousands of concurrent slices in a 5G SA network (see Figure 2).
Service assurance starts with the definition of data collection points. Based on observed real-time data, analytics works out whether everything is operating correctly or whether there are traffic trends that could cause damage or a potential breach. The policy manager decides what actions need to be taken based, for example, on the relevant customer’s contracted service status.
Currently, service assurance tends to be used as an operational tool aiding troubleshooting and monitoring. With strong support from the operators who see the benefits for operations and cost control, ZSM standards promise to make service assurance an integral and integrated part of the OSS landscape. It is an important stepping-stone towards the future automation of 5G networks.
This is still work in progress. ZSM has not yet specified some key interfaces and processes. This means that service assurance solutions currently need to be integrated separately with each orchestration vendor (see Figure 3 on next page).
To be compliant with ZSM, a service assurance partner needs to integrate with the top layer of the Management and Orchestration (MANO), which includes a policy manager, NFV Orchestrator (NFVO), and the knowledge base. The NFVO can talk to the virtual network functions manager for each virtualized function vendor deployed. Service assurance can suggest an action, but it is the policy manager that makes the decision.
Action could be as complex as changing network function from one vendor to another in real-time. For example, in an industrial private network use case, the NFVO could switch from a high-capacity network function used during busy hours to a lower cost, smaller scale function for off-peak hours, reducing OpEx for the operator. By collecting data across all network elements and monitoring latency between data centers, Anritsu is also investigating the feasibility of enabling operators to move functions to the least cost data center on disaggregated networks offering multiple flavors of edge.