Red Hat and Ericsson tackle conflict in multivendor autonomous networks
By Ray Le Maistre
Jul 9, 2026
To embed our video on your website copy and paste the code below:
<iframe src="https://www.youtube.com/embed/nyqjT_vyiqw?modestbranding=1&rel=0" width="970" height="546" frameborder="0" scrolling="auto" allowfullscreen></iframe>
Ray Le Maistre, TelecomTV (00:05):
We are at DTW Ignite 2026 in Copenhagen. I am here with executives from Red Hat and Ericsson to talk about how they are collaborating on a number of key industry initiatives. So I'm with Chris Thornton, Senior Principal Community Architect at Red Hat, and Jörg Niemöller, Expert in Analytics and Customer Experience from Ericsson. So welcome, gentlemen. Thanks so much for joining us here at TelecomTV. Now, the excitement here at DTW is around a lot of key industry topics, but the catalyst projects are always a big highlight of this show. Tell us about these projects in general and how you became involved in a project called Conflict Management in Intent-Based Networks Phase Two. Chris, tell us about that catalyst.
Chris Thornton, Red Hat (00:54):
Thanks, Ray. Yeah, we've been looking at customer requirements and the fact that you're going to have competing customer requirements using a finite set of network resources, and working with Ericsson, which we've been doing through a number of phases of this catalyst. This is a Phase Two catalyst. Last year we identified some areas for improvement, so we've come back this year to try and enhance those. But in fact, Jörg and I collaborated originally on, I suppose you might call it a Phase Zero catalyst three years ago. So we've had a long relationship in terms of evolving what we've been doing here. And in this catalyst, Red Hat are providing the O-Cloud layer compliant with the O-RAN Alliance, where we're having the hosting platform on top of which a number of different services can run.
Ray Le Maistre, TelecomTV (01:44):
And Jörg, from your perspective, what are the key takeaways from this catalyst?
Jörg Niemöller, Ericsson (01:49):
I mean, the catalyst is directly addressing the autonomy level four challenge or level four-plus challenge, which means we try to find network operation that doesn't involve humans anymore in the decision-making loop. Furthermore, in this particular project, we are looking into multiple layers of network operation, all the way from the business layers to the service layers, all the way down to the raw network operation. In this respect, we are also not talking about just TM Forum standards. In a realistic network scenario, we have RAN management based on O-RAN, based on the O-RAN SMO concept, and we're combining this with the upper layers of TM Forum to address this challenge.
Ray Le Maistre, TelecomTV (02:30):
So a lot to consider there, and you can see why this is important to address for many operators. And a lot of operators here are talking about autonomous networks and getting towards level four. And as the industry reaches that level of autonomy, you've described a hidden friction here where software agents and rApps are pursuing particular individual goals — like energy savings versus network optimisation — and this results in conflicts. Can you explain this black-box problem and why traditional reactive human intervention acts as a ceiling to what can be achieved with autonomy? Jörg, can you start with this?
Jörg Niemöller, Ericsson (03:13):
An autonomous network is operated by autonomous entities, and autonomous entities run on their distinct sets of objectives. For example, there is an rApp that wants to optimise the network for energy consumption. There's another rApp or a service orchestrator that wants to deliver service quality to customers following SLAs and so on. So these are distinct sets of objectives and you still have just a single set of resources — just one network — and they both try to act, but as the objectives are not aligned, they ultimately lead to conflicts. So for example, when you try to solve energy constraints, you would like to switch channels off, which is not good if you would like to provide good service quality. So if each of these individual entities act in isolation, they take completely different actions than if they were to coordinate into something that is from a business perspective optimal for the network.
Ray Le Maistre, TelecomTV (04:15):
And Chris, how can these issues be overcome? Because this is something I know that's been looked at for a few years already.
Chris Thornton, Red Hat (04:21):
Level four autonomy requires that the network itself is going to be configured, managed and optimised with little or preferably no human interaction. So we're looking at how these different constraints that we're working with can all be managed with that low-touch model.
Ray Le Maistre, TelecomTV (04:42):
Now, of course, another key consideration here at this event is business cases and new use cases, and the TelecomTV community is really invested in the evolution of reliable 5G and B2B enterprise solutions. Can you walk us through a particular scenario you've tested in Stockholm, where a robotics provider slice request created a direct resource conflict with an active network slice used by first responders? And again, that's an issue that's going to be critical for operators all over the world. Chris, tell us about this scenario.
Chris Thornton, Red Hat (05:24):
Absolutely. And this is what we've been showing on our catalyst. So we've taken a knowledge graph and we can feed all of the information about these different requirements into that. So an existing customer request that's sitting in there has a whole load of constraints around it, a level of service that it needs to manage. And when a new request comes in — in this case, the robotic AI slice request — we need to be able to identify if there are going to be any conflicts with that existing service for the first responder. That's a critical network. And if there is a conflict, we need to be able to either manage it or block that request for a human or another automated agent to come in and propose a counter-offer.
Jörg Niemöller, Ericsson (06:10):
What you're referring to is a situation where conflicts occur. This is a use case where we have different customers with different needs, which ultimately leads to these misaligned objectives — different intents, different requirements — and that leads to the conflict. And in this project, we show on multiple layers of the network, all the way from the business layer to the network operation, different techniques for handling these conflicts. For example, at the business layer, we're having a natural language conversation between the customer and the network, where the network derives from this conversation the requirements that the customer has. It then checks the feasibility of these requirements with the service layer. And if it is not feasible, the service layer will make counter-proposals as to what can actually be delivered right now, and this is then pushed back up to the business layer where it is openly discussed with the customer to find a compromise.
(07:01):
If we then go further down, the service layer is now facing potential conflicts with other entities that operate the network — like, for example, rApps that want to optimise the network. And here we are using a knowledge graph approach to identify potential conflicts, and then we're using intent in order to share objectives with the other entities. So we are basically sharing the misaligned objectives with each other so that, for example, the rApp then suddenly has additional requirements to consider in its decision-making. And then if we go further down into the RAN, the rApps have an agentic system of operation. So they are coordinated by a centralised intent management function, and we have an agentic system where rApps can make proposals, they collaboratively evaluate these proposals, and so on. So we have a collaboration scheme there. And in this collaboration scheme, we are also opening up through new APIs to third parties. So it's not all within one ecosystem of one vendor. And this is also a big contribution — new APIs through which multiple vendors' contributions, multiple vendor rApps, can participate in these decision-making loops. So different techniques for conflict avoidance, conflict handling, and conflict management on different layers.
Ray Le Maistre, TelecomTV (08:15):
Now, you've mentioned a key point there, because as communications networks evolve, they are increasingly becoming multi-vendor, and this catalyst project demonstrates cross-vendor conflict resolution using third-party components. How do open APIs and autonomous domain authorisations allow disparate multi-vendor applications to safely participate and negotiate in a single self-governing system?
Jörg Niemöller, Ericsson (08:45):
First of all, you have to protect the network. When conflicts occur, this is usually shown by different entities trying to take different actions towards the same features in the network, towards the same parameters. And this can lead to instabilities. So what this project is also proposing is a scheme in which we provide authorisation for taking actions to one entity and one entity only — so it's exclusive. This first of all protects the network from constant instabilities caused by entities overwriting each other's configurations, but it also pushes the entities towards collaboration. So they collaborate before an action is actually taken. They discuss with each other and collaborate in order to choose the action collaboratively that will ultimately lead to the best business outcome. And to do so, we are opening new APIs so that this collaboration can be done across vendor systems. For example, rApps from multiple vendors in the same SMO environment can now be coordinated in the same decision process before the entire domain as a whole acts towards the network.
Ray Le Maistre, TelecomTV (09:53):
And Chris, how can these multi-vendor environments best be managed?
Chris Thornton, Red Hat (09:56):
So what we've seen is the requirement for a cloud- and AI-native platform on top of which these applications are to run. And so we're seeing the requirements coming in from our customers and partners to have that common platform. And by pushing these standards, we're seeing that they're unlocking innovation by being able to plug and play new pieces of technology as they go through.
Ray Le Maistre, TelecomTV (10:21):
Now, obviously this catalyst — you mentioned this is like the third iteration — and this is something that can be seen here on the show floor. But also at these events, everybody is looking forward to what's going to come next, what the next few years are going bring. So as we look beyond this year's show, what are the next crucial steps that service providers must take to build the common cloud-native foundations that are required for level four autonomous intelligent networks? Chris.
Chris Thornton, Red Hat (10:53):
Yeah. So we're seeing how our customers are asking for that AI- and cloud-native platform on top of which they can place components that they can change as they evolve. We're seeing the requirements that they need to run on-premises, on a cloud, or where they make sense to perform. And importantly as well, we're seeing that at all levels — right the way from the O-Cloud layer at the bottom, on top of which a number of different CNFs and other network functions can actually run, right the way up to the automation platform that instruments everything as it goes through. And Red Hat provides that platform and allows those customers the choice to be able to come and pick and choose technologies as their networks evolve.
Ray Le Maistre, TelecomTV (11:42):
And Jörg, what are the key considerations for the network operators?
Jörg Niemöller, Ericsson (11:46):
There are a couple of very exciting technologies today. There are intent-driven autonomous networks with new architectures. There is agentic AI. So there's a lot of promise right now out there, but at the same time, telco-grade is not an empty phrase. It means we cannot really play games with the network that our customers are actually making money from. So what this means is that we have to address, for high-scale production use, critical questions like how to resolve conflict, how to make it secure and safe. And this catalyst project is answering some of these questions already and showing the way ahead in which direction it can go. At the same time, everything has to be autonomous, which means no human involved — just to come back to that challenge. It is highly demanding, but the technologies are underway. And at Ericsson, we embrace these technologies and we are evolving our portfolio to use them in order to make the autonomous network promises real — like delivery at scale, constant attention to the network, fast resolution of faults in the network. All these promises will become real, but in a way that we don't compromise the network. Telco-grade solutions will come for that.
Ray Le Maistre, TelecomTV (13:02):
Well, these are absolutely critical considerations for operators right now, and it's not really optional — and all the operators, I think, really know that and are looking for the results and the outcomes that you've been talking about here today. Chris, Jörg, thanks so much for talking to us about the catalyst, what you're doing together, and what needs to come next. Thanks very much for joining us.
Jörg Niemöller, Ericsson (13:26):
Thank you very much. Thanks for having us.
We are at DTW Ignite 2026 in Copenhagen. I am here with executives from Red Hat and Ericsson to talk about how they are collaborating on a number of key industry initiatives. So I'm with Chris Thornton, Senior Principal Community Architect at Red Hat, and Jörg Niemöller, Expert in Analytics and Customer Experience from Ericsson. So welcome, gentlemen. Thanks so much for joining us here at TelecomTV. Now, the excitement here at DTW is around a lot of key industry topics, but the catalyst projects are always a big highlight of this show. Tell us about these projects in general and how you became involved in a project called Conflict Management in Intent-Based Networks Phase Two. Chris, tell us about that catalyst.
Chris Thornton, Red Hat (00:54):
Thanks, Ray. Yeah, we've been looking at customer requirements and the fact that you're going to have competing customer requirements using a finite set of network resources, and working with Ericsson, which we've been doing through a number of phases of this catalyst. This is a Phase Two catalyst. Last year we identified some areas for improvement, so we've come back this year to try and enhance those. But in fact, Jörg and I collaborated originally on, I suppose you might call it a Phase Zero catalyst three years ago. So we've had a long relationship in terms of evolving what we've been doing here. And in this catalyst, Red Hat are providing the O-Cloud layer compliant with the O-RAN Alliance, where we're having the hosting platform on top of which a number of different services can run.
Ray Le Maistre, TelecomTV (01:44):
And Jörg, from your perspective, what are the key takeaways from this catalyst?
Jörg Niemöller, Ericsson (01:49):
I mean, the catalyst is directly addressing the autonomy level four challenge or level four-plus challenge, which means we try to find network operation that doesn't involve humans anymore in the decision-making loop. Furthermore, in this particular project, we are looking into multiple layers of network operation, all the way from the business layers to the service layers, all the way down to the raw network operation. In this respect, we are also not talking about just TM Forum standards. In a realistic network scenario, we have RAN management based on O-RAN, based on the O-RAN SMO concept, and we're combining this with the upper layers of TM Forum to address this challenge.
Ray Le Maistre, TelecomTV (02:30):
So a lot to consider there, and you can see why this is important to address for many operators. And a lot of operators here are talking about autonomous networks and getting towards level four. And as the industry reaches that level of autonomy, you've described a hidden friction here where software agents and rApps are pursuing particular individual goals — like energy savings versus network optimisation — and this results in conflicts. Can you explain this black-box problem and why traditional reactive human intervention acts as a ceiling to what can be achieved with autonomy? Jörg, can you start with this?
Jörg Niemöller, Ericsson (03:13):
An autonomous network is operated by autonomous entities, and autonomous entities run on their distinct sets of objectives. For example, there is an rApp that wants to optimise the network for energy consumption. There's another rApp or a service orchestrator that wants to deliver service quality to customers following SLAs and so on. So these are distinct sets of objectives and you still have just a single set of resources — just one network — and they both try to act, but as the objectives are not aligned, they ultimately lead to conflicts. So for example, when you try to solve energy constraints, you would like to switch channels off, which is not good if you would like to provide good service quality. So if each of these individual entities act in isolation, they take completely different actions than if they were to coordinate into something that is from a business perspective optimal for the network.
Ray Le Maistre, TelecomTV (04:15):
And Chris, how can these issues be overcome? Because this is something I know that's been looked at for a few years already.
Chris Thornton, Red Hat (04:21):
Level four autonomy requires that the network itself is going to be configured, managed and optimised with little or preferably no human interaction. So we're looking at how these different constraints that we're working with can all be managed with that low-touch model.
Ray Le Maistre, TelecomTV (04:42):
Now, of course, another key consideration here at this event is business cases and new use cases, and the TelecomTV community is really invested in the evolution of reliable 5G and B2B enterprise solutions. Can you walk us through a particular scenario you've tested in Stockholm, where a robotics provider slice request created a direct resource conflict with an active network slice used by first responders? And again, that's an issue that's going to be critical for operators all over the world. Chris, tell us about this scenario.
Chris Thornton, Red Hat (05:24):
Absolutely. And this is what we've been showing on our catalyst. So we've taken a knowledge graph and we can feed all of the information about these different requirements into that. So an existing customer request that's sitting in there has a whole load of constraints around it, a level of service that it needs to manage. And when a new request comes in — in this case, the robotic AI slice request — we need to be able to identify if there are going to be any conflicts with that existing service for the first responder. That's a critical network. And if there is a conflict, we need to be able to either manage it or block that request for a human or another automated agent to come in and propose a counter-offer.
Jörg Niemöller, Ericsson (06:10):
What you're referring to is a situation where conflicts occur. This is a use case where we have different customers with different needs, which ultimately leads to these misaligned objectives — different intents, different requirements — and that leads to the conflict. And in this project, we show on multiple layers of the network, all the way from the business layer to the network operation, different techniques for handling these conflicts. For example, at the business layer, we're having a natural language conversation between the customer and the network, where the network derives from this conversation the requirements that the customer has. It then checks the feasibility of these requirements with the service layer. And if it is not feasible, the service layer will make counter-proposals as to what can actually be delivered right now, and this is then pushed back up to the business layer where it is openly discussed with the customer to find a compromise.
(07:01):
If we then go further down, the service layer is now facing potential conflicts with other entities that operate the network — like, for example, rApps that want to optimise the network. And here we are using a knowledge graph approach to identify potential conflicts, and then we're using intent in order to share objectives with the other entities. So we are basically sharing the misaligned objectives with each other so that, for example, the rApp then suddenly has additional requirements to consider in its decision-making. And then if we go further down into the RAN, the rApps have an agentic system of operation. So they are coordinated by a centralised intent management function, and we have an agentic system where rApps can make proposals, they collaboratively evaluate these proposals, and so on. So we have a collaboration scheme there. And in this collaboration scheme, we are also opening up through new APIs to third parties. So it's not all within one ecosystem of one vendor. And this is also a big contribution — new APIs through which multiple vendors' contributions, multiple vendor rApps, can participate in these decision-making loops. So different techniques for conflict avoidance, conflict handling, and conflict management on different layers.
Ray Le Maistre, TelecomTV (08:15):
Now, you've mentioned a key point there, because as communications networks evolve, they are increasingly becoming multi-vendor, and this catalyst project demonstrates cross-vendor conflict resolution using third-party components. How do open APIs and autonomous domain authorisations allow disparate multi-vendor applications to safely participate and negotiate in a single self-governing system?
Jörg Niemöller, Ericsson (08:45):
First of all, you have to protect the network. When conflicts occur, this is usually shown by different entities trying to take different actions towards the same features in the network, towards the same parameters. And this can lead to instabilities. So what this project is also proposing is a scheme in which we provide authorisation for taking actions to one entity and one entity only — so it's exclusive. This first of all protects the network from constant instabilities caused by entities overwriting each other's configurations, but it also pushes the entities towards collaboration. So they collaborate before an action is actually taken. They discuss with each other and collaborate in order to choose the action collaboratively that will ultimately lead to the best business outcome. And to do so, we are opening new APIs so that this collaboration can be done across vendor systems. For example, rApps from multiple vendors in the same SMO environment can now be coordinated in the same decision process before the entire domain as a whole acts towards the network.
Ray Le Maistre, TelecomTV (09:53):
And Chris, how can these multi-vendor environments best be managed?
Chris Thornton, Red Hat (09:56):
So what we've seen is the requirement for a cloud- and AI-native platform on top of which these applications are to run. And so we're seeing the requirements coming in from our customers and partners to have that common platform. And by pushing these standards, we're seeing that they're unlocking innovation by being able to plug and play new pieces of technology as they go through.
Ray Le Maistre, TelecomTV (10:21):
Now, obviously this catalyst — you mentioned this is like the third iteration — and this is something that can be seen here on the show floor. But also at these events, everybody is looking forward to what's going to come next, what the next few years are going bring. So as we look beyond this year's show, what are the next crucial steps that service providers must take to build the common cloud-native foundations that are required for level four autonomous intelligent networks? Chris.
Chris Thornton, Red Hat (10:53):
Yeah. So we're seeing how our customers are asking for that AI- and cloud-native platform on top of which they can place components that they can change as they evolve. We're seeing the requirements that they need to run on-premises, on a cloud, or where they make sense to perform. And importantly as well, we're seeing that at all levels — right the way from the O-Cloud layer at the bottom, on top of which a number of different CNFs and other network functions can actually run, right the way up to the automation platform that instruments everything as it goes through. And Red Hat provides that platform and allows those customers the choice to be able to come and pick and choose technologies as their networks evolve.
Ray Le Maistre, TelecomTV (11:42):
And Jörg, what are the key considerations for the network operators?
Jörg Niemöller, Ericsson (11:46):
There are a couple of very exciting technologies today. There are intent-driven autonomous networks with new architectures. There is agentic AI. So there's a lot of promise right now out there, but at the same time, telco-grade is not an empty phrase. It means we cannot really play games with the network that our customers are actually making money from. So what this means is that we have to address, for high-scale production use, critical questions like how to resolve conflict, how to make it secure and safe. And this catalyst project is answering some of these questions already and showing the way ahead in which direction it can go. At the same time, everything has to be autonomous, which means no human involved — just to come back to that challenge. It is highly demanding, but the technologies are underway. And at Ericsson, we embrace these technologies and we are evolving our portfolio to use them in order to make the autonomous network promises real — like delivery at scale, constant attention to the network, fast resolution of faults in the network. All these promises will become real, but in a way that we don't compromise the network. Telco-grade solutions will come for that.
Ray Le Maistre, TelecomTV (13:02):
Well, these are absolutely critical considerations for operators right now, and it's not really optional — and all the operators, I think, really know that and are looking for the results and the outcomes that you've been talking about here today. Chris, Jörg, thanks so much for talking to us about the catalyst, what you're doing together, and what needs to come next. Thanks very much for joining us.
Jörg Niemöller, Ericsson (13:26):
Thank you very much. Thanks for having us.
Please note that video transcripts are provided for reference only – content may vary from the published video or contain inaccuracies.
As networks strive for Level 4 autonomy, software agents often clash over resources. Red Hat's Chris Thornton and Ericsson's Jörg Niemöller explain how a TM Forum Catalyst project called Conflict Management in Intent-Based Networks - Phase 2 used knowledge graphs, shared intent and open APIs to allow multivendor applications to safely negotiate these conflicts with an O-RAN Alliance-compliant cloud platform to enable network slicing for emergency services in Stockholm.
Featuring:
- Chris Thornton, Senior Principal Community Architect, Red Hat
- Jörg Niemöller, Expert of Analytics and Customer Experience, Ericsson
Recorded June 2026
Email Newsletters
Sign up to receive TelecomTV's top news and videos, plus exclusive subscriber-only content direct to your inbox.
