Orange CTO Laurent Leboucher on why intent-driven automation is ‘absolutely essential’
Orange CTO Laurent Leboucher on why intent-driven automation is ‘absolutely essential’
This is the second in a three-part interview with Laurent Leboucher, Group CTO and Senior Vice President of Orange Innovation Networks. Here we discuss why intent-based automation is so important as Orange transforms its network to be cloud native and software defined.
In autonomous networks, systems are governed according to specified objectives or expectations known as “intents”. Intents comprise the requirements, goals and constraints in a simplified way that’s abstracted from the technical inner workings of the network. Put more simply, intents are the “what” not the “how” – meaning, you can tell the system what it should do without having to tell it how to do it.
Part one of our interview focused on Orange’s goal to reach Level 4 Autonomous Network for some processes by 2025. Part three will look at the potential for generative AI and the need for cooperation among standards bodies and open-source groups. Our conversation has been edited for clarity.
DB: Are you putting intent-based automation into practice today?
LL: We are doing it, definitely – in different places, in different countries, and for different parts of the network, for instance for the transport (IP and WDM) network. For some projects, we are doing it to the extreme. For instance, the Pikeo project is our flagship innovation bet on network automation – it’s a 100% cloud-native 5G standalone operator at a small scale. And in that project, we try to go to the limit and we learn the hard way.
We have people moving to this project and using it as a kind of internal school and then contributing the practices and also reusing the tools in different real-life projects across countries. It’s working pretty well.
DB: What are some of the best lessons you’ve learned so far?
The need to think about security from the beginning and really put it at the core of all operations processes. And not reinventing the wheel whenever we think about the technical platform and all the tooling framework. Instead, we need to organize an automated pipeline for delivery, the lifecycle of network functions from continuous integration (CI) to continuous delivery (CD).
The other important lesson is that automation cannot be done without data. It’s obvious but important. Consider a data scientist on one side, trying to bring some very innovative machine learning, a new algorithm, and on the other side you have operations. If you’re using a traditional client-server model, where operations waits for the solution to be built, that will never work.
If you want to make it happen, you need to have operations and data experts in the same project, and it needs to be driven by use cases which are under the control of business operations and network operations. This is absolutely fundamental, and this is something that we are trying to do. It’s not always easy, because we need to have people who are ready also to take some risks on the operational side.
DB: TM Forum has explained how to do intent-based management from a technical perspective. But what is the business case for intent-based automation?
LL: The Forum has done a lot to explain in depth what it is to be intent driven, and I don’t know of any other organization that’s tried to explain it in a way which is understandable and spent enough time to do it the right way. So, I’m pretty sure that there is a gold mine [of information] in the Forum. The Forum was very advanced – perhaps a bit too advanced – when they started to work on it, but now it has become critical.
Coming back to the business case and why it’s so important, when we speak about automation, there are basically two ways to do it. It helps to use a metaphor. If I have a robot and I want to automate how the robot can go from room A to room B in my apartment, the very traditional way – a very simple way – is to do basic scripting, which means I would measure the distances between room A and room B and then program the robot to navigate the apartment, and it would work. The problem is, if I try to move the robots to another place – to the neighbor’s apartment, for example – I will need to redo the scripting.
When you have an intent-driven network, you’re able to adapt to different situations and configurations that may happen and which need to be abstracted to some extent. Intent is this mechanism to abstract and to be able to keep what is essential: the intent of going from room A to room B.
Being able to do that in network operation is absolutely essential as there must be awareness of any environment change. If stay at the edge of basic scripting, we will never be able to scale and never be able to reach the level of repeatability – industrial repeatability.
DB: Is 5G network slicing a good example of the need for intent?
LL: Slicing is one example of use cases where, when you establish a slice for a particular customer, say, for fixed wireless access, you need to take into account whether the radio network is congested or not. To address that and to cope with different situations, you need intent. This is why we want to introduce an orchestration solution when we move to dynamic slicing. For the very first deployments of slices in the network, we can do it without full automation. But if we want to be repeatable – if we want to do it at scale and we have to deal with different requirements from customers for their own mobile private networks or IoT deployments – then it has to be intent driven.
One way to do that is to introduce a multi-domain orchestration solution. It’s not just orchestration; it includes also the dynamic inventory. Having a real-time view of the resources is essential.
We also need to be able to introduce a rules mechanism to allow the next level of automation. And it’s not just for provisioning. Very often we think of provisioning as the most important use case, but … the most important is in production, when you have to keep the service level agreement (SLA) under control. Intent-driven orchestration is needed for that, for instance by automatically scaling in or out according the current situation.
DB: How far are we from intent-based management at scale? How long will it take us to get there?
LL: I think we will go step by step. We will not be able to replace everything and implement a complete intent-driven architecture at scale, end-to-end. But we will be able to do it step by step on a limited scope at first, focusing on all areas requiring repetitive scripting (IP backhaul, RAN, tariffing…). Multi-domain orchestration for slices could be one example. Maybe also in some areas, we can implement upgrades of software, of network functions during the life of the network, without disturbing our customers, in a way which is intent driven and uses the good practices that we can leverage from Kubernetes.
Kubernetes is not just a technology; it’s also a way to manage resources – and not only compute resources, but also storage resources, and later on network resources. The Nephio Project specifically addresses how we can use the Kubernetes management style intent-based with network resources, and I think this is really the right way to move forward.
We are leveraging what’s working well in the IT industry and trying to reuse it in the telco industry …because the IT industry is far bigger, so we can leverage its momentum and use it in the context of network workloads.