SQM strikes back in the NFV Empire
Hello Operators. Dare I break it to you that it’s time to re-engage and ramp up all those SQM (Service Quality Management) programs again? Yes.
SQM systems have had a chequered history. The big marketing promises didn’t fulfill the ROI requirements.
However, in the old days (yesterday, today and probably for much of tomorrow), SQM had very much hit a wall by trying to model services on top physical telco networks. Real-time topology management had always been too cumbersome to offer a clear value.
Around 2008-2010, “CEM” systems based on probe data began to dominate SQM systems. Customer (XDR event) driven service assurance was discovered to be much more efficient and useful compared to SQM.
Today SQM systems have mostly remained dormant. The new SOC solutions are based on combined probing, fault management and performance information while service modelling and monitoring operate modestly. Only the core elements and services are being monitored by just a few KPIs. And for legacy networks this is fine, and I would say, usually enough.
Enter NFV. The biggest revolution in telco since the discovery of GSM. Fifteen to twenty years ago SQM engineers tried to figure out the complex workings of telco services through reverse engineering and everything seemed quite clear …until the resource allocation of services changed and became a dynamic process. Suddenly, the service chain became big black box.
NFV has huge implications for the service chain. DevOps in NFV join forces for the first time in order to accurately define service changes. Bingo! This is very good news for SQM developers who suddenly have a transparent documented service chain for the actual customer-facing services. So why, all of a sudden, do we now need Next Generation SQM instead of a ”CEM” solution?
There are lots of reasons why SQM is required in NFV. Services use one or several VNFs on top of virtual data centers – one ‘broken’ VNF will break the service.
For example, a “CEM” solution will discover that a customer has problems with Service A and service A happens to be running in NFV environment. The questions are: Do you know which VNF instances are providing the service? Do you know which VNF process needs to be fixed? Do you know in which data center VNF is running? Do you know the status of the VNF? Do you know how to heal VNF?
NFV will transform operations, but at the same time it sets new criteria for the OSS.OSS has to be near real time and it must be completely aware of the full service chain. While NFV service modelling must include service testing and monitoring rules.
SQM needs to incorporate a full service model AND it needs to receive information when a service has been orchestrated AND understand how VNF monitoring data will start to flow in. This complexity requires that SQM, DevOps and orchestration solutions are fully integrated.
It has been said that many Operators are blindly driving their networks. In NFV this will truly be the case if Next Generation SQM is not fully integrated with an NFV Orchestrator. SQM has struck back.