There are a variety of ongoing trends in telecoms, such as inter-access handover, edge computing, and the sheer proliferation of sites, which make automation increasingly important. 6GWorld spoke to Ian Hood, Red Hat’s Chief Technologist for its Global Service Provider Business, to get an insight into where we really are with network automation today and the nature of the necessary evolution over time.
We began by discussing how network automation fits within a wider context, that of business and enterprise automation and the use of AI more broadly. More specifically, “what some analysts are calling hyperautomation, to automate all processes across all of their business; and in telco that’s network, IT, back office, business processes – all those things.”
This turn of conversation isn’t surprising – Red Hat last year started talking about the “enterprise neurosystem”, a similar web of automation and AI. “What we found is that AI – just like many other things – is being developed in pockets and silos both within individual businesses and across multiple industries,” Hood explained.
“So the neurosystem concept was really more of a community approach, so that we can use AI as a technology across every business. Applying AI across the business in a uniform way so that we can actually integrate across them and build large-scale federation of AIs – of course making sure that the data itself doesn’t become public, but the models, approaches and those kinds of tools are being shared easily across multiple businesses.”
In itself this is an interesting direction, but doesn’t give many specifics about network automation. However, there are parallels with telecoms networks, in Hood’s view.
“What we’re seeing is that the industry for automating networks is more like software automation of the configuration of a network, rather than automation in developing the application itself,” he observed.
“Applications themselves come from many different players, then are being consumed rather than developed by an operator, but they need to reconfigure them on the fly. So they would need to go to an approach using what we call GitOps technologies – repositories, automation, tooling – to basically turn it into push-button deployment, reconfiguration and change. AI then becomes an essential part of that.”
In other words, there is progress, but – as with other industries – it is only progress in specific siloed areas as yet. Configuration of the network is essential for more efficient delivery of services over a specific network, no doubt. However, network optimisation is not the same as service optimisation or being able to deliver services to customers across multiple networks.
Automation and Orchestration
The attraction of a “neurosystem” approach to network automation seems fairly clear. With a commonality of models, tools and approaches across vendors and users, there is a real incentive for both vendors and operators to develop new capabilities rapidly. This, it seems, is exactly what some operators have been talking with Red Hat about.
“We were discussing automation in the context of the Open RAN architecture for inter-access networking and the ongoing evolution of AI in the networking 3GPP world. We said that we would want to take how we actually use AI for network slicing, RAN scheduling, network automation – all those kinds of use cases – and apply that same commonality across that collection,” Hood explained.
Of course it doesn’t stop there.
“I’ve done the RAN network automation portion, and I need to go automate the deployment of MEC edge solutions on top of that. I apply AI for that capability, and potentially offer AI-as-a-service to an enterprise customer as an option,” Hood suggested. “They use the same set of tooling in that type of use case.”
All of this implies a level of service orchestration way beyond anything currently known, which Hood acknowledges.
“We’re starting to see that the service orchestration tools will need to become much more API-driven, whoever’s making them, to fit into that software-driven approach that we’ve been building in the open-source community.”
This isn’t just theory, either.
“We’re starting to see that work being driven by our customers who are getting to the point where they want to do push-button stuff using APIs, and they don’t really want to use Graphic User Interface-driven service orchestrators, or CLI [Command Line Interface]-driven versions of them. They are not very well automated, not very secure, and don’t cover the breadth of technologies and services they want to deploy. So they’re finding that they need to modernise how they’re doing orchestration and figure out how to get the telemetry automated to the back office.”
The Current State of Automation
Automating the configuration of network switches, routers and more is an established process now in parts of the network. “They all use this technology called Ansible automation. It’s a process automation tool, but one of the processes is how to configure network devices, whether they’re physical, virtual, or containerised,” Hood summarised.
“Then we use an AI engine to provide recommendations on what to do. And again, Ansible is one of the automation tools to automate these processes.”
However, this stage of development does not yet extend to the RAN systems, and even less so Multi-Access Edge Computing.
“It’s still early in the days of making those technologies open. How they communicate between vendors, just at the physical level and what that standard looks like – what are the performance capabilities, how many radios can you actually handle at one time on one computer – all that good stuff has to be worked through,” Hood explained.
There is a question as to how far to rework these kinds of legacy applications and systems, however.
“The question is, do we make them cloud-native or do we just pull the data off the top of them, apply AI to them and get information over-the-top: data acceleration, AI information on that edge application. Should I waste my time rebuilding the application that’s been around for 20 years? It really comes down to the legacy of the application in terms of its ability to be software-defined and cloud-native, and whether it’s cost-effective to convert it to the cloud or whether we just go after the data that’s flowing across this application and apply AI to that data to improve the product and services that are being offered.”
Where Does Automation Go in 6G?
Perhaps unsurprisingly, Red Hat has a very particular take on this. “As we move up to 6G, now we get into an AI fabric, like this enterprise neurosystem that we talked about,” Hood explained.
The key elements in enabling an “AI fabric” like this to work are an abstraction from the underlying network and seamless interconnection of applications between public and private clouds, edge, and other locations. Hood describes this as an “application cloud”.
“It’s exactly what WhatsApp has done, letting a Google phone and an iPhone use WhatsApp at a higher layer to communicate our messages back and forth. Take that concept, apply that to any business application messaging system that they want to use for business applications and have those messages be passed at that higher layer between those files,” Hood proposed. “6G will help enable that level of separation from the network so that I can actually run an over-the-top web application play and do it securely.”
This would solve a long-standing challenge in telecoms to get applications interconnecting with the network. “It’s never really become a well-integrated connection. It’s always been a ‘ships in the night’ approach,” Hood noted.
Unlike some proposals, according to Hood this appears to be something with an active backing from end users.
“A lot of our larger customers in some of the verticals are looking at this as a way to solve that complexity of operations, of securing all of those connections that they currently have between all their different locations or different customers. It brings security up to the application layer and simplifies their operations overall.”
