Zero-touch automation, in the form of some sort of over-arching service lifecycle management system, was the holy grail for operators just a few years ago. What changed that is the combination of a lack of insight into how to proceed, and the pressing need to reduce opex. The combination resulted in point-of-problem strategies that tapped off a lot of the easy automation fixes. The loss of these then reduced the accessible benefits of broader ZTA, and stalled practical initiatives. Now, we just might see some ZTA creep in from below.
5G deployment may be an example of another of those point-of-problem drivers of service automation, or rather a formalization of one. For some time now, we’ve been seeing operators shifting toward an open-device model, made up of a combination of open-source software and white-box hardware. This approach admits to the possibility that some open-source network software might be hosted in a resource pool, including even public clouds. That opens a question that’s been around since 2013; do hosted functions create more network complexity and cost than device networks?
Substituting one or more virtual functions for a physical device has admitted capex benefits, if you’re not paying through the nose for the functions and if your hosting capabilities are efficient. It also has admitted opex problems. A half-dozen operators told me that their experience with cloud-hosting of network functions was that the opex for that approach was running 30% higher, roughly, than for traditional appliances. That was enough to erode or even erase the capex benefits.
A super-ZTA model for top-down service lifecycle automation could have addressed this problem, if it had been developed. A generalized approach to operationalizing hosting of functions, adopted from the cloud’s exploding repertoire of tools, could also solve it. What could also solve it is a point-of-problem strategy aimed specifically at 5G. The question is whether that’s the right approach. Point-of-problem strategies have helped operators reduce opex already; adding one in 5G could do the same, but it could also build another specialized solution to what should be recognized as a generalized problem.
I’ve blogged many times (you can find them via the search tool on my blog page) on the topic of ZTA and the right way of approaching it. The problem with the “right” ZTA at the strategic level is that it takes time to develop a general strategy, and then deploying it might require changes to operations tools and practices. At the tactical level, the way network operators are organized and socialized tends to focus solutions to things that have budgets. 5G deployment has a budget, specific people responsible, P&L, and so forth. Broad-based ZTA has little specific budget support, according to operators.
The real question, though, may be whether specialized point-of-problem 5G automation could set an example for the rest of the network space, even provide some elements applicable beyond the 5G target. Properly done, 5G service automation might be able to rise up and support other missions, but this would require that the 5G strategy be based on generalizable principles and tools.
Nokia just announced what it calls “AVA 5G Cognitive Operations. 5GCO (I’m using this shorthand because it takes too long to type the real name!) is part of the overall Nokia AVA Telco Ecosystem, which means that it’s based on a broader strategy and not one-offed for 5G. The Ecosystem is a public-cloud (Azure, currently, with others possibly in the wings) AI framework that analyzes operations data to predict problems and guide solutions. All of this is based on Nokia’s AVA concept, so it’s best we look at AVA overall.
AVA stands for “Automation, Virtualized, and Analytics”, and the idea has been around since 2016. Since then, Nokia has introduced more and more AI and also a collaborative framework, additional information-gathering (including crowdsourcing), and “solutions” that apply all of this to specific problem sets. 5GCO is one such solution. The basic Nokia AVA approach is to use broad data collection, and AI/analytics to drive automated processes that alter network behavior. This reduces or eliminates the need for specific service modeling, goal-states, and other event-interpretation and steering processes, or so it’s hoped. By analyzing data broadly, Nokia AVA can determine whether anything is going wrong, and invoke steps to correct it…again, so it’s hoped.
One reason for this “hoped” qualifier is that this whole process could be better explained. Even operators who have adopted some of the Nokia AVA solutions aren’t able to articulate the basic platform concepts particularly well. It appears to them that the AVA platform is specialized into solutions by predefining some rules and policies that then guide the AI stuff. The approach appears to classify “events” into standard categories, which can then be associated with action policies that include kicking off automated processes.
There’s broad capability within AVA to define new events and classifications, so it’s possible to incorporate almost anything you can know about as an event to be analyzed. There’s also a collaborative framework to help tune solutions to fit specific combinations of network equipment, services, and available information. If this extensibility aspect of AVA is true (meaning that I’ve interpreted the material correctly), you could not only build 5G automation from it, but also build service automation for other services, both new and legacy.
There’s a lot of merit to this approach, I think. Networks already generate reams of direct event data and telemetry, and certainly an analysis of this information could be used either “symptomatically” to deal with conditions, or holistically to establish goal states, operating states, the current state (relative to the last two) and overall root causes and remedies. If you compare this to the IT world, the AI process would be creating the states (needed for descriptive DevOps) from retrospective analytics, and then using AI to interpret events and trigger state transformations, which is what descriptive DevOps tools are moving to do.
Compared to service modeling, the approach has the advantage of doing its own retrospective analysis to establish a “model” and define states (normal and otherwise), rather than requiring that the model be created explicitly. Service models and state/event tools are “anticipatory”, and of course the limit of any such process is the ability to anticipate. The AVA approach can at least minimize this by having analytics do the heavy lifting.
AI analysis of events is a kind of soft-state-event approach. You don’t have explicit events driving you to explicit next-state conditions and invoking corresponding processes, and as I said, that helps by eliminating the need to develop specific service models that, for each element, represent state/event/process relationships explicitly. It’s possible using the intent modeling techniques I’ve described in past blogs and my ExperiaSphere projects, to retrofit the models to an existing network, but it’s still a considerable amount of work.
All AI systems have a potential risk that’s directly proportional to just how much they really replace “real” or human intelligence. Anyone who, like me, has worked for decades with state/event systems knows that they have one significant benefit—you can look at the state/event model and where you are in it, and know what’s supposed to be happening. If it didn’t happen, or if something was improperly modeled in state/event terms, you can find the problem quickly and address it. If the whole state/event analysis is soft, known within the AI processes only, then it’s essential that the AI steps to make a decision, and the steps taken to implement it, be explicitly visible and auditable. Otherwise, your AI assistant turns into “Hal”.
The AVA approach to 5G is smart, in that it builds on a general strategy. The AVA approach, as a general strategy, is smart because it can be applied to existing networks and services with minimal effort and probably no retrofitting of technology elements. I just need to know how smart the AI is, and there’s not enough material available for me to say.
I’m sure Nokia would have been willing to give me a briefing on this, but as I’ve noted in the past, I can’t blog on information that’s presented to me specifically, and not reflected in public material that all can reference. So I’ll ask Nokia to give this blog a read and send along any specific links to website material that I could use to dig deeper into the process. If I get that, or if I get specific responses to the details of the solution from operators, I’ll revisit this.
https://www.sdxcentral.com/articles/news/nokia-blends-ai-cloud-for-5g-automation/2020/03/
https://telecoms.com/465252/nokia-launches-ava-cloud-service-delivery-platform/