Guy Daniels, TelecomTV (00:13):
Right. Welcome back everyone. Welcome back to our online streaming audience as well. We are streaming this event live for both days. So our next session is AI for core network automation. It's our third session of the day, so I'm going to ask our speaker, Bejoy to come and join me on the stage. So please welcome, be joined to the stage. He's going to take up the lectern.

Bejoy Pankajakshan, Mavenir (00:42):
Hi. Good morning everybody. So my presentation is title, navigating the Journey to the AI Native TechCo Future. I know the section was labeled as automation in the core. I'll cover that for the most part and I'll also touch on other areas as well, including monetization, the use of AI in monetizing the agenda. First time I'm going to cover our view of the industry inflection point and how we view AI applied to different areas of the network, be it for monetization or the drive towards autonomous networks. And then I'll dive into mapping vision as well as the three buckets in which we see our products evolve, which is generally the industry vision as well. How does the operator make money using ai? How do you make the operationally more efficient by using ai? And then of course having a path to a future six G AI core as well.

(01:31):
So first part, you'll see a lot of elements here on this slide. The intent here is the view that we are at an inflection point with more use of AI in telco and in every other sector we used to have for our portfolio, we've had use of AI in security and other domains, but it's the first time that we actually seeing more use of AI in trying to automate the network for achieving level three, level four down the road. So the way to look at the slide is there's some elements in the left which are dealing with how the monetization features will evolve. On the right side you have elements on how the wall operational efficiency aspects will evolve. And then of course there are a few other elements around energy efficiency and network convergence in general, as the progression happens in three gpp. The intent is not to say that we are here on each step of these elements on the right hand side, but it's to say that it's a journey that will happen in the next three to four years.

(02:27):
Starting with let's say API exposure, I'll cover this in more detail later in the presentation, where today it's CAMARA based APIs. How does it evolve in the future when you have more agents that are interacting from the enterprise side? Same thing for experience, whether today it's very user-centric, you're selling connectivity as an operator. How does that connectivity evolve to various selling intelligence? And GSMA actually has an initiative right now where you're looking at the ROI of intelligence, not just under specific projects, but also looking at the intrinsic benefits of ai. How does the organizational transformation happen? What benefit does it bring to the operator and to businesses? So considering all of that and looking at how does the network evolve from it just being a connectivity pipe to being a value chain where it understands reasons and creates opportunities for the operators to monetize their network using AI, as well as how do you run the network more efficiently with less number of people effectively and be more operationally efficient?

(03:28):
So coming to the Mavenir pillars in our vision, there's three main pillars. The first one is AI for monetization, which is all around what kind of services could evolve in the core. Primarily it's on the core when it comes to monetization, unless you consider the AI and ran efforts that AI ran alliance has with multipurpose compute where you run not just ran workloads but other workloads also on the same GPO. So that's one example of AI for monetization in the ran side, but otherwise most of the use cases here around the consumer enterprise to the core. And the core includes everything from packet processing to IMS, to the billing side and customer experience side as well. The second piece is AI for operational efficiency. This is a drive to move towards autonomous level four five in the future. Where today, based on the surveys and reports that we see operators are generally between level two and three.

(04:24):
They may have achieved level four in specific domains like for example, just in the transport domain of fiber rollout. But to realize the end-to-end vision of a level three, level four, what is required and finally how does that set it up for a future AI core? So I'll give an example of how we view the core evolving to support six G AI services. Now looking at purely from today's world, how could you consider using the core to monetize and applying ai? So there are several cases in the core for in-call use cases as well as post-call. And these are enterprises. There are startups as well that are doing agents that run on top of the operator network and give you the same sort of capabilities. But the pitch here is for operators to actually not just become a dumb pipe as the AI evolution happens, but also to participate in that and make money out of it.

(05:16):
So there are many use cases here, be it in call, a post-call sentiment analysis, fraud detection post-call, things like summarization of the call giving transcription. So all these use cases again, as I said, could be realized as an OTT solution. But what if it could do it on-prem? I think the AWS outage that we all experienced yesterday is a good example of why there are risks with running these solutions in the public cloud. And the operator networks is always set up for high reliability finance kind of solutions. But here the objective is not just from a reliability perspective, but you also have cost. And when you look at tokens and how an AI would be implemented with these models running in the public cloud, be it entropic and others, the objective is not to go compete against building those LLMs out there tailored for these voice services, but to come up with versions of these models that will run for specific use cases.

(06:13):
In this case, that use cases could be translation, it could be transcription, but everything related to how voice would be handled more efficiently in the network using optimized models. And also when you're talking about real time services like in call translation, the way the media and signaling is handled also has a big impact on the user experience. If you have to happen the signaling in media all the way to the public cloud, bring it back on-prem, that impacts the user experience because the real time interaction that's happening. So the solutions that we are in discussions with our customers is around how do you optimize this within in-network S lms, how do you get better control over how these services launch that becomes more reliable and secure as well. The next piece is the evolution for how we see CAMARA services or API exposure evolve. So on the far left is today's implementation where you have the enterprises with their own applications that connect to the operator open gateway with via an open gateway, API CAMARA, API.

(07:14):
And today there's around 60 plus APIs that are standardized, that's stable, that's in the stable stage right now and there's many more that's going to happen, right? But at the same time, if you look at the figure right next to it, it's showing the evolution that will happen when the enterprise side evolves to having agents and CAMARA has already started working in some of it. So as you could see at the bottom there now nine of the stable APIs have been converted to support MCP based exposure as well. So here the idea is that the interaction evolves from being a CAMARA API based interaction to tool discovery using MCP protocols. The next phase of it is the intent base where today if you have to do, let's say a fraud detection use case, which is security is one of the most popular use cases in CAMARA today, how would that API query that the enterprise is hard coding with multiple APIs for a single use case.

(08:07):
It gets converted into purely an intent where the enterprise just says, I want and slice or I want to check the fraud capability of the solution with certain liability in the case of slice or with certain guarantee. In the case of security, it's just an intent definition and you have something on the network side that interprets that intent and does the execution southbound. So here that's the third scenario and we are actually showing a demo of this at a booth and how the intent orchestration works with CAMARA. The fourth piece is where it gets interesting where you now adopt the protocols of a two, a agent to agent communication. Agent communication protocols on the far end where the enterprise evolved to an agent and the agent through its LLM query either discovers the path using MCP tools. So that's one of the options that you see on the right is the MCP tool-based discovery and the interaction using MCP.

(09:01):
The second option is where the interaction is happening, where the agents can directly talk to each other. So there's agents that are providing services in the operator network core as well, and that's the second path you see. And then of course the third one is where the standard, the current APIs are used. So we see this evolution path will be a journey in itself, but the operator networks have to evolve to be able to support this journey. The next piece is as intent driven networks evolve, and the previous slide I just talked about how intent would apply for the service exposure use case, which is just the second bucket in there, the network exposure. But at the same time, there are other avenues of the operator domain where intent is going to play a key role, especially as you move towards six G. And that's in network operations where today's interactions are very specific to a specific operation.

(09:55):
It evolves to being an intent where the intent can be described by the operations engineer or could be described by a customer of the operator and then the service lifecycle as well, whether it be self feeling, self-learning, orchestrating the network for service, a domain orchestration, all of that is defined and executed using intent. And finally, the bold BSS experience where the enterprise today for customer care engagements, where it is very light interaction that the enterprises have with customers, which is very touch point heavy, evolve to being purely an intent-based interaction that the enterprise also have. And the work that's happening in this domain is primarily with TMF as defined in API 9 21 for at least negotiating what the intent should be. But once the intent is received, once it's negotiated and agreed, the execution of that intent is going to be vendor dependent and use case dependent.

(10:49):
So you would have examples where the context is added to the intelligence query via MCP servers so that a query that happens is given more relevant response. As an example, if the intent comes in and says, I want to establish a slice with certain SLA, that's what the enterprise is asking, that intent could be negotiated, but as part of the process, you're looking into the network inventory to see can the service be fulfilled with the resources that are available with the network at that time? And that interaction is retrieved using an MCP server that's exposing the capability. So there's all these pieces come together when you look at an intern driven network of the future. The next piece as we look at how AI driven service assurance itself would evolve in an L three, L four L five network. One of the big problems that you have today in the network domain is any OSS solution that's sitting on the top.

(11:45):
It's primarily operating on the FM and PM data, which is fault alarms performance data, which is the counters and KPI or the key performance indicators. That's the level of knowledge that's known to the OSS systems. Of course, if you pick any OSS vendor, they will be working with the individual network provider vendors to kind of interpret what these network function counters and KPIs and alarms mean and that knowledge is what the OSS vendors use to determine when thresholds are breached. When should the alerting happen? The auto root cause analysis of that world process happens today in an automated way. I shouldn't say that there's no use of AI today. There is threshold based ai, pure AI, ML based mechanism be used in the OSS systems. What the OSS systems lack is a visibility that happens further into the application itself, the trace information, the log information, which has got very valuable pieces of stats, which will help in debugging the network and make it more proactive.

(12:46):
Because if you have to move from L two L three to an L four L five network, you cannot rely on a proactive form of service assurance. It has to be very, I'm sorry, it has to be very proactive, cannot be a reactive method like the way it happens today. So what we're showing here is on the left is today's implementation. Many operators have achieved this level of service assurance where you have data that's put into a centralized data repository, a data lake. Different forms of ML models are being used for prediction, anomaly detection, correlation pattern recognition, some use of LLM as well, especially in root cause analysis and summarizing the output from past failures. And then you get a unified view, which the network ops folks could use. But evolving to the future, we see where the applications are playing a more active role.

(13:34):
This has to do with the proactive nature of how the service assurance should evolve, fix and identify the problem at the source of the problem itself. So infrastructure knowledge, which means you have to have topology awareness application, which has got AI agents implemented, integrated or natively within the application itself, which is then feeding information into a central knowledge base. This is one of the key evolution parts that we are expecting to happen. You see in the middle part there is the wall knowledge graph. This is where all vendor information operator information, which is all the past history that operators have that gets populated into knowledge graph which standard LLMs could retrieve to get context. So the idea here is not to go fine tune the LLMs out there to create specific LLMs for telco because that's going to be super expensive. But you build a knowledge base which can be used to add more context to the prompts that are given to any reasoning LLM out there.

(14:30):
So go pick Anthropic or go pick Llama any model that you have instead of fine tuning it for specific telco use cases. You could of course modify it to have a small language model. But the key here is how do you enhance the zero thought, the chain of thought process that the model has to retrieve more context when a prompt query is made. And that's that knowledge graph implementation that will happen in the network. And what that allows you to do ultimately is a view at the top which is very differentiated. So for example, if an ops engineer asks a question, the output is being generated real time through the LLM, that's depending into the knowledge graph, which means that that output and the view that it provides to one user, a consumer of that OSS service is going to be very different from if an executive launched in and looked at how is the network overall performing today, the way it's done is you would have UIs that are built, dashboards that have created previous ahead of time and then you display it versus in this case it's more real time because it's all being built real time and that's the view that we see in the future where you have to realize L five networks.

(15:38):
So how does this evolve too from a monetization perspective for the six G AI voice taking voice as an example. So this is showing the use case where native services are being implemented on ai. So translation service is one fraud detection where you could be looking at the voice signature and based on that you figure out if it's a deep fake call that's coming in instead of the real user. There's other use cases, well that's possible in the future like XR services, but the flow here is whether it's the internal OSS/BSS systems or it's an external enterprise that's generating a query using intent that is obtained or consumed at the intent orchestrator, it analyzes the intent, negotiates breaks it down, sends it to the internal execution agents that are being built and those execution agents then calls the corresponding network side functions via MCP. But as you saw in the CAMARA use case, it could also be an agent to agent communication that happens at that stage. So this is the view that we have in the future, how the core would evolve and how we could use the core effectively for monetization as a not bound setup of the customers of these operators evolve to be supporting agents and other new services. I think that was the last slide. We have a few minutes for Q and A.

Guy Daniels, TelecomTV (17:03):
Yeah,

Bejoy Pankajakshan, Mavenir (17:03):
Thanks very much.

Guy Daniels, TelecomTV (17:04):
Thank you very much. Come and sit down with me. Round of applause for Bejoy. Bejoy Pankajakshan is EVP, Chief Technology and Strategy officer of Mavenir. Of course I should have said that at the beginning. I apologize. Lots of digest there. Fascinating. I'm sure we've got questions from the floor. Tony, how are your eyes? You're back. Any hands? You can see I'm a bit struggling here with the lights. Any questions? There must be loads of questions coming up from, oh, do you want me to start off?

Tony Poulos, TelecomTV (17:33):
What I might do is have a random

Guy Daniels, TelecomTV (17:35):
People pick someone at random. I'll tell you what, why don't you do that? I'm going to start off. Have you. Alright then. Francis...

Francis Haysom, Appledore Research (17:42):
Bejoy, great presentation. You mentioned the API evolution earlier. Obviously at the moment, if you look at the CAMARA interfaces at the moment, they tend to be what I would term is telco exposing what it aura its network already is capable of doing, whether that's a sim swap or something like that. IE we're offering to the outside world what you can do as you move to intent based engagement, it becomes much more a customer driven process rather than what the telco does. Have you been at all looking at how we enable the operator to be able trust that type of interaction? Because at the moment we kind of put a barrier in the way this is what the network does and it does. This becomes a much more collaborative thing with intent. Have you looked at what needs to happen within the operator to make that intent based interaction work?

Bejoy Pankajakshan, Mavenir (18:43):
So the intent, intent-based interaction does not mean that whatever the customer is asking is going to be supported. The first phase of the intent interaction is a negotiation. So say for your point that today you're selling network services exposed using API and that's what you could sell in the future as well. That is the case. It is you could only sell what you could support in the network. The key here is hopefully by the time that you evolve to supporting the intent based ask from the customers, your network has also evolved to a level three, level four where the requirements for a level four, level five is that new service creation can happen in a matter of minutes, which is today not possible. So if for example, the enterprise where to negotiate for an intent for a service capability that you have not set up, the idea here is that you're able to set it up in a matter of minutes and that would then enable you to then turn around and sell that and satisfy that intent. That's what will happen. Now when it comes to the security aspect of it, of course all of this will have proper guardrails and making sure that as part of the negotiation you're not going outside the bounds of what is required. So the way the intent orchestration engine will execute on this is with proper guardrails in place because the first part of it is the top layer. That would be the dashboard and what would actually evolve to supporting these services. Stop by a booth. We'll show you some of these capabilities as we see today.

Guy Daniels, TelecomTV (20:04):
Great. Thanks very much for that. Whilst we're waiting to see if there's any more questions from the audience, we have a question from our online audience, and I think this one's quite relevant here. The question is, and we're going to be covering this to an extent tomorrow when we look at the panel on future challenges. So the question is how do you adapt to MCP and A2A when we have no idea if MCP will be a long-term solution. There's constant change. How do you and telco's plan for this change today?

Bejoy Pankajakshan, Mavenir (20:32):
Yeah, so when initially the MCP effort came about, Anthropic and Enterprise were adopting it, there was work that was done in the telco sector itself. There was actually a paper written on what are the telco specific adaptations of MCP that needs to happen. Since then, we at least our thinking has evolved to where we are saying it does not need to be an MCP/T, which is the way this paper was advocating the use of MCP in telco, but it's going to be more of an intent driven solution. That's why we talk about MCP as the underlying way in which one of the ways in which you could utilize the network exposure, but it all has to do with who is the consumer of it. So one way is if that capability is being discovered using an MCP tool, then it becomes more interactive.

(21:17):
You could evolve and develop this much faster. But we are not saying that the only way of consuming the network services is going to be why MCP. If you see one of the slides we showed it is MCP, it's A2A or it's standard APIs as well. It's all going to depend upon which parts of the network have MCP based services exposed. Definitely we're not expecting the entire network overnight to be converted and exposed using MCP. It's a huge cost to it. And first of all, the MCP servers have to be developed. It's either going to come from the vendor or it's going to come from a neutral third party who knows enough to kind of abstract and create the tools for each domain. So you'll see vendors pop up who are building MCP tools for certain domains as well. You'll expect to see some of those players pop up. And the question is valid. I mean nobody knew about MCPA year ago. A2A is just being adopted in Linux Foundation. You'll see this evolve over time as well. And this is a journey, right? So if it takes two years from now and there's an evolved version of it, then we will adopt that.

Guy Daniels, TelecomTV (22:16):
Great, thanks. As you say, yes, it's a journey. Do you see any more hands coming up here, Tony, any more questions? We've got time for probably one more question. If anyone's got a burning question, I know you all want to rush out and have a look at the booth and have a demo. But any questions if yes, there's one in the middle there Tony. Thanks very much.

Audience Member (22:33):
Thanks for the presentation. So my question here, looking to the evolution with more centralized data management evolving from data lake to data fabric or data mesh. My question here, can we get AI to help us solve the data problem and assuming that will be good enough to understand the data and run interference at the network function level or where we need in order to optimize the processing?

Bejoy Pankajakshan, Mavenir (23:04):
Yeah, actually I forgot to mention that in the slide, the evolution path that we see for the data lake itself is where this technology coming out there for zero copy. Where today most of the enterprise implementation is where you copy the data that's put into the data lake multiple times. So we are seeing like IBM, snowflake and others talk about zero copy where the data, once it's towed, instead of copying it multiple times, which adds to overhead on the DB side, it is retrieved and used by the application, which is an AI agent in this case much more efficiently. So that's one part of the evolution that we see happen on the data fabric itself. The other key part is what data gets written into the databases. So Microsoft has this project called Janus, where effectively today, if you think about the data storage for service assurance, a lot of it is trace data logs and debug data, which if you have to run continuously in operate a network that's going to kill the footprint.

(24:00):
I mean you'll have to spend hundreds of millions is storing all this data. So how could you intelligently when a problem happens, create the enough information to be able to go debug it? And this is done using techniques like Janus, which is effectively an EBPF based implementation where when a problem happens, there's quotes hooks that are implemented within the application itself that it knows to generate additional information which can be used by these AI agents to go execute on and solve the problem. So there are different ways in which you could look to solve the same problem.

Guy Daniels, TelecomTV (24:34):
Great. Thanks very much Bejoy. Thank you very much. We are end of the session, so round of applause for Bejoy. Thank you very much.