Why Is It So Hard to Run a 5G Core on Kubernetes—And What Needs... Joel Studler & Ashan Senevirathne

This talk explores the deployment and operational challenges of 5G core networks within Kubernetes environments. The speakers, Ashan Seniviratna from Telstra and Joel Studler from Swisscom, discuss the anticipated growth of mobile data traffic and the increasing complexity of managing multifaceted 5G core deployments. They highlight the discrepancies between traditional telco operational mindsets and Kubernetes' cloud-native principles, particularly regarding configuration management and network reliability. Additionally, the presentation reflects on industry experiences, solutions to improve deployment processes, and a future vision where 6G can leverage cloud-native architectures by design. The importance of integrating network functions with Kubernetes tools, fostering a change in operational practices, and collaborating across the telco ecosystem is emphasized throughout.

Good afternoon, everyone. So, let's let's start our presentation. Hands up those who have a 5G connection on the on your mobile phones. Oh, that's good. Most Most of you have it. So, on your smartphone, you have a small 5G icon. And behind that icon, there's a large distributed system which runs our mobile mobile core. And increasingly, this this mobile core, it's it's running on Kubernetes. And we

are here to share some of the challenges we see running and life cycling that that mobile core. So, we are representing two different operators, similar challenges. And some of you are from the Telco, some of you are not from the Telco, but I think most of the learnings will applicable be to to most of you. So, before we jump to the the technical details, I want to

set the scene. Um So, the mobile mobile data traffic, it's predicted to grow three times in by by 2031. And that's not a not just a prediction. It's already in in the motion. Every network device that we bring in, every use case, every application that we run, it lands on the network. Um also, the complexity, it's predicted to increase uh because we we we do use multiple

technologies. There's there's 4G, there's 5G, 5G standalone, um edge use cases, network slicing, etc. So, all of these adds up the operational like the surface. So, every operator here has been asked to maintain these networks. So, that's the third [clears throat] item. So, so the ask is um maintain and operate this this complex network with the with the same amount of people we have. Um So, you've

got the traffic growing on one hand, the complexity complexity is increasing, but how do you maintain this this network with with with with with a very lean um like a team and an organization? And that that gap somehow needs to close. And um we want to fundamentally think and sort of challenge how we operate and life cycle this network. So, with that, my name is Ashan Seniviratna.

I'm a product owner at Telstra. And my name is Joel Studler. I'm a lead engineer at Swisscom. Uh very happy to be here. Nice that you made it to our talk. Uh before we share our insights on what went well and what should be improved with with 5G and and Telco and Kubernetes, we would love to hear your insights. This is a QR code that leads to

a retro board. I'm going to show it very quickly. We really would love your insights to to hear what you think about 5G core and Kubernetes. On on this left side, you see what went well with 5G core and Kubernetes. If you have some insights yourself, please add them here. Uh On the right side, you can what needs to be improved. And please add your honest opinion

on on what needs to be improved. Also, use the voting function. And of course, please adhere to the CNCF code of conduct that applies here as well. Please use that next 30 25 minutes to to share your insights so we can get that conversation going. So, who in this room has contributed to a 5G core deployment on Kubernetes? Please raise your hand. So, we have a few

Telco Telco heads right here. That's So, to some of you, this might be news. To some of you, this is not really new. So, what is a 5G core? All of these boxes are services in a 5G core deployment. On the top layer layer, we see a distributed control plane that is handling authentication, user data management, sessions, and all of that. And on the bottom, we have

the user plane function which is acting as a router or a high-speed packet forwarding engine. We have two boxes that are not part of the 5G core. One of them is the UE. That's basically your smartphone. And the other one is the radio access network. So, antennas and access network to the core. Two specifics that we we would like to point out. The first one is everything

in this system is highly standards driven, especially the dotted lines in between all these boxes. So, all these connections are depending on standards. We sometimes call them APIs because they're some of them are HTTP APIs. But we sometimes also call them interfaces because they have hard dependencies to the infrastructure. And that's something to keep in mind when we talk about Telco on Kubernetes. The second one is

that it's carrier grade reliability. So, we we're talking about a highly reliable system. So, the journey of 5G on Kubernetes, what has worked well so far? And we can only speak for Telstra and Swisscom. So, what we found is the 5G cores are running containerized. They're running on Kubernetes. So, that's really good. Great achievement. It's mostly GitOps driven. And we do have some CICD capabilities. We can

see the CNCF tools that that we talk about on this conference. We can use them to help us with the integration plumbing. So, that's really great. One interesting development is that network engineers start to operate workloads on Kubernetes. So, that's really great to see. And it also leads to the last point that Telco and cloud native world start to integrate more and more. One one proof is

the Telco presence on in in this very cloud native conference. So, in addition to asking you what went well and what should be enhanced going forward, we asked around in the industry. And we have three voices today here. And we really like to thank everyone that's that provided their insights already up front. The first one that we're going to hear is from Jessica Østergaard from Ericsson. We've

come a really long way as an industry in Telco to adopt cloud native technologies and their implementation architectures. But where I would love to see us make even stronger progress is how we work with these technologies to fully adopt a more cloud native operating model so that we as vendors and our customers, the CSPs, can fully harvest the benefits of these technologies without excessive cost. So, yeah.

So, so what Jessica's mentioned was um we did deploy these applications on Yet, there's a lot of operational improvements that we can leverage from So, let's see what we have deployed now. So, so the so so on the left, you see a cloud native model. So, services talking to services platform handles the discovery, scaling, routing, etc. The reality is we containerized these applications. We put it in

a appliance level like a network application into a box, labeled it as Kubernetes. We containerized it, when we start operating the these applications, we realize that we we don't use the full leverage of the this Kubernetes like the features, etc. So, why why this is happening? Mainly, as as Joel mentioned, we also have this Telco mindset overlapping or or coming together with the with the Kubernetes world.

And they they sense themselves have a very different mindset of like thinking how how things are interacting and and all. So, when it comes to Telco, they think topology first. So, you need to know every node, every interface, every link. I think it also resonates with all the other Telco colleagues here. So, you configure each instance individually. And then you need to protect those instances because the

services on top of those instances rely rely on staying them alive. So, Kubernetes on the other hand, thinks very differently. So, it's very service-centric. You you declare what you need. So, for an example, if you want to run three pods, you declare your intent. Platform takes takes care of it, deploys where it runs. If a pod fails, then the then Kubernetes itself self-heals and then replaces these

instances. So, these two mindsets that we are seeing, it's not naturally compatible. And then when you force them to meet together, there's always these mismatches occur. And these mismatches, we we've seen that it happens in networking, um life cycle, and also on the reliability aspect. So, let's look into the networking first where we see these mismatches occur. Um So, on the left side, I think everyone knows,

Kubernetes as a platform, it provides um platform handling handles the discovery, the routing, the scalability, handling like even it's supposed like declarative like the Instead, we built a static IPs, introduced virtual NICs, manual IP management, interface-centric configuration. I also this all the all the network configurations are tightly coupled to the infrastructure underneath. So, we didn't extend the Kubernetes networking specifically. Rather, we bypassed it. if you if

you if you also look at what what we introduced, the result is completely familiar to a Telco network engineer. The reason being they can it's very familiar for them all these point-to-point connections, static addressing, and also these interface names that that they like recognize on a day-to-day. So, it looks like completely broken to a platform engineer looking at from the outside world. So, we built virtual cables

and then integrated into the Kubernetes instead of using all these platform services. The second one is the slide that I really like because it shows you like clearly how we handle the configuration. Uh the life cycle aspect. On the left side, this is what we wanted from Kubernetes. So, we introduce a custom resource. So, in this case it's a network function. The intent is to keep it

connected, scale automatically. Um Looks good. Five lines of config. The platform reconciles. Done. On the other hand, we introduce this proprietary protocol or it came with the uh the legacy way of working, uh which is this netconf. Mostly, they they've got like more than 2,000 parameters, very imperative and fragile approach. And on top of that, we also put this uh imperative logic into Git and then called

it GitOps. Um and we shoved 2,000 parameters in in there and then filed this uh and also said like Um act- it's not like very declarative in in the end, as you can see. So, we configured boxes um and uh instead of using this declarative configuration approach. The third is quite important, the reliability aspect. So, as everyone pods fails, Kubernetes detects, um new pods pods are scheduled,

traffic rerouted, service continues. And that that whole thing happens in seconds. Today, instance fails. There's a external HA logic that we trigger. Uh an operator is paged. Takes 5 minutes. There's a manual validation happens, takes another 15 minutes, and then the recovery uh confirmed, question mark, takes some time. So, this whole process takes minutes, hours, or even some phone calls. So, every manual touch point that we

have in the in the in in today's world, it introduces a scaling limit, and we cannot move faster with when when when when every recovery needs a phone call for an example. So, with that uh I want to introduce a second industry voice, which is the which is Morgan Richomme, who's also in the audience today. Um he's from Orange. He's a product owner. So, let's listen. >>

Use standard coming from the industry. Listen more people from computer science. And uh stop [snorts] maybe writing over engineering standard uh you know that to to to achieve this kind of goals. So, let's see if we managed to keeping it simple in Telco. Um I would like to show you a very specific example um on the about the UPF. So, remember the UPF is this box on

the bottom, which is basically the router. I will zoom in a bit to show you what we're talking about. So, on the very left, you have your smartphone, the UE, the user equipment, which connects wirelessly to the antenna, which then allows you to connect to the UPF, the user plane function that allows you to connecting to some other networks. Normally, it's the the internet. So, deploying that

on Kubernetes is as easy as just putting it on Kubernetes, right? So, we get all the features like networking, IP address management, we get the declarative configuration, we get GitOps, and all of that. We get the container orchestration and auto scaling features. So, done. The problem we ran into, we found out that the Linux kernel wasn't that good in terms of networking, in terms of efficiency back

in the day when we started with 5G core. So, we decided to put network interface cards directly into pods. So, we touched them directly to the pod, which made sense because we need the throughput. So, we solved the issue of bottlenecks, but what we actually did is, like Ashan already said, we bypassed the Kubernetes networking completely. So, we don't leverage the networking of Kubernetes, we don't leverage

the IP address management. So, we have to manually manage IP addresses. But, it's not so bad. We can still use the rest. Only that we decided to use node pinning. So, we decided to have one node per UPF instance to have in order to have deterministic traffic paths and so on. So, what we did is we had we intentionally decided to have one node per UPF instance,

which basically meant we get rid of the container orchestration, because if you have only one to choose, it's not really orchestration anymore. Um so, we don't have auto scaling and container orchestration anymore in the example of UPF. And last but not least, we configured these boxes using netconf. That's a standard we use in Telco. So, we also got rid of the rest. >> [clears throat] [applause] >>

Great achievement, yeah. >> [laughter] >> So, yeah, I'm sorry, Morgan. We didn't do well in terms of keep it simple. We I guess we over engineered a little. So, let's see what what we can do in the future. If we look at that 5G core picture again, it really looks like microservices, but it actually behaves like infrastructure. And that's a very important um statement because we need

to get away from from that reality. Or put in put differently, it's like trying to take a turboprop plane and turning it into a turbojet. You can imagine it's a lot of work. So, let's have a look at 5G core and what works what what what we actually need to improve. On the UPF side, we already talked about getting rid of the configuration um uh netconf specifically,

and we really need to discuss the runtime. So, we need to if we want to keep Kubernetes, we need to do a lot better. On the middle layer, there's also some improvement needed, specifically on the configuration side as well, but also on the networking. There it's less dramatic because we don't need these high throughput instances. It's It's It's only APIs and like control plane traffic and no

actual data plane traffic. And on the upper upper layer, we're mostly fine. We still need to get rid of netconf, but um it's okay-ish for for the rest part. To summarize, for all network functions, we should really start leveraging all these Kubernetes ecos- Kubernetes tools and the entire Kubernetes ecosystem that is there. We should use the IPAM features, we should use load balancing and services. Uh specifically

leverage DNS. Tolerate not. The- These are the things we need. We should use auto scaling and scheduling. We should improve our networking. For an instance, use DRA. Um and we should use declarative configuration instead of netconf. On the user plane functions specifically, we think there will be specialized node. We we will need that And we should really discuss the use of Kubernetes runtime. If we stick with

Kubernetes for the UPF, we should do Let's have a look at the retro board quickly and see what's going on. There's a lot already. That's very nice. Please keep on adding stuff and voting. It's really nice that you're so active. And we're jumping back to the presentation for a bit. So, the next voice we'd like to introduce is from Riccardo Gasparetto from Vodafone, an architect in Vodafone.

And let's see if he agrees with our assessment. Hi, I am Riccardo from Vodafone. So, for many operators running 5G is painful because it's often just legacy lift and shift. We deal with thousands of manual config parameters and zero abstraction. Also, upgrades are too risky to ever match the Kubernetes cadence. For 6G, we need two things. First, drop netconf in favor of Kubernetes operators to enable true

GitOps. Second, fully automated testing to eliminate the manual bottleneck and finally deploy at speed. Thank you. All right. So, so what what what do we do next? Um we've shown you the problem. Uh Yuel went through a very detailed example of the UPF. You've also shown every Kubernetes feature gets bypassed one by one. So, the question is um what do we actually do about it? And we

want to be very honest here. There's no silver bullet, uh but we see uh a clear direction uh where we want to head towards. Uh we're also in a transition era. So, so these are different technologies that we introduced over time. Uh you've got the 2G, 3G, 4G, 5G, and in the future, the 6G. More more on the um and also we sit between 5G and 6G

now. So, we introduced 5G few years back. We've done the the the the most of the applications are running in production, etc. So, more from the platform side, there's physical network functions, virtual network functions, VMs running on OpenStack for an example. Um containerized network functions or the CNFs. And also um cloud-native network functions, which are gradually um starting to be introduced. And the reality today is um

we have a mix of uh technologies, uh which has legacy interfaces um existed. And as I mentioned, most of these applications are running on Kubernetes um and uh on on these platforms. So, the bottom line is we we cannot wait for 6G to fix everything. Um and the question is how we operate today and how we make it um while we push them in the right direction

for the tomorrow. Um so so now what what's Swisscom and Telstra been been doing in this space? So, we started introducing GitOps. So, the Git is the source of truth. Every life cycle aspect that's in in code, no manual steps. So, while that configuration sits in Git, we also introduce abstraction to this configuration. So, we we leverage Kubernetes resource model. [clears throat] Using Kubernetes operated operators, we

extend the Kube API. So, any external activities that we do outside to the Kubernetes like IP handling, config management like this netconf aspects, we started bringing them into the in-band Kubernetes. So, so in the essence, we we we started using Kubernetes as the control surface of all the all the network elements. And one example to showcase that what we've done in Swisscom is the Swisscom automation platform

for for Telco. Um it's using GitOps and KRM as Arslan pointed out. It's using STC for cloud-native netconf. Um we use NetBox operator for um integrating IPAM into Kubernetes. We have a network as a service operator. We use Kubernetes for plumbing as well. KRM-based configuration assembly, so to say. We have Headlamp for user experience and user interface. And last but not least, we use we use Flux

CD as the deployment tool for everything. Uh please please check it out on the architecture the reference architecture website of CNCF. Uh it has been published roughly a week ago. >> [snorts] >> So, as Telco, um So, so we we've shown that operators are proving the GitOps and the KRM approach um as a start. Uh and most of the use cases are running in production. Um the

vendors they they they must follow cloud providing cloud-native APIs gradually, just not not just the appliance wrappers. And more from the standard side um and to be fair, like 3GPP or ETSI these standards, they are moving in the right direction. Uh a little bit slow, but um uh more more more more more from the standard side, they need to embrace uh mandating some of these implementation patterns

not just on the on the concept end. While that's happening on the on the platform end, um a lot of the um asks from Telcos in the past uh providing these high-performing networks, we we see that a lot of the AI workloads uh uh they they've got similar requirements. So, it has become a plat- platform level concern now. And also the Telcos been asking for distributed observability,

and we are seeing that the OpenTelemetry becoming the standard for distributed um systems including the network functions, the Kubernetes, and so on. So, so we are seeing like this gap is closing, uh but not that fast enough. So, and that brings us to what we do with the as we mentioned in all the previous slides, um the 5G we introduced containerized applications on the That was step

one. Um uh and we we we started introducing these containerized applications. Um and we realized the the the benefits of the cloud-natives uh after some time. Um so so which which which has paid us paid us some some price ever since. And 6G is the opportunity to uh not to repeat that same mistake. So, so in 6G, um 6G must uh provide cloud-native by design, uh declarative

by default, and resilient by architecture. Not just as an as an afterthought or retrofit uh from the start. So, we we ran 5G on Kubernetes. So, that was that was good. And we are also trying to introduce this plumbing using cloud-native tooling, uh bringing some of this netconf aspect into into KRM. That still we are we are introducing a workaround on that. So, when it comes to

6G, 6G should be designed from from the start as I mentioned. So, three three lessons quickly in our journey. Uh Kubernetes is not failing Telco. Uh it's important to say that out loud. The platform is capable and maturing. Uh the challenge is how we've been using it uh to today. The second, containerized doesn't mean uh cloud-native. We've seen this slide by slide today. Um you take an

appliance, you put it in a container, deploy it on Kubernetes, but still bypasses every feature. Uh it doesn't bring any benefits. So, the last one is the architecture mindset determines the success. So, we need to think services over instances, uh intent over configuration, and architecture over control. So, lastly, running Telco workloads on Kubernetes And what we are seeing is the real transformation happens when we uh start

operating like Kubernetes. Um and the hard part is still ahead of us. So, as a industry, the vendors, the operators, the standard bodies, the cloud-native community, we should drive this uh change and then go in this direction. So, the good news is the industry is already moving. Um and you can be part of it. So, there are a few projects going on in the cloud-native Telco industry

that I would would like to point out. Um there is Nephio. Uh you might have heard of it already or use it. Um there is Sylva. So, there's no silver bullets, but there's a silver lining or >> that's the slogan, I guess. Um and CNTF a conference or like a forum that that allows vendors and operators to come together and it's acting like a collaboration hub. Um

behind this link tree, there are more initiatives. And please join them to keep uh the cloud-native Telco moving. there is a slide with additional resources. I won't lose any words on that one, but I would really like to go back to this retro board and see what you added. So, there's a lot of stuff that's really I saw >> oops. it's a tie. But it's also good,

yeah. Right starting point for containerization on the core. Um we also need to value the positive. DRA for networking, that's a promising one uh going forward in the next years. I think the first one is quite nice. K8s current network abstraction is great for microservices, but not net- network heavy stuff. Yeah. So, that's something we need to look into. Yeah. And please continue using this retro board.

It's going to stay there. Uh you can you can use it. Use it in your um in your events. I know Friday there's Sylva dev day. Uh we can we can use the content from And uh please use it. Discuss it in your companies. And Approach us if you have any further follow-up questions. And with that, we thank you very much for being here and for participating.

should we have some time for questions? We still have some time for questions. So, if anyone has a question or in addition to the retro board as Hi. I'm not coming from a Telco background. But you mentioned that one of the bottlenecks you have is the kernel in terms of throughput for the Uh how you dealing with that thing in order to replace that that is a

bottleneck and prevents you from scaling those devices? And what sorry? I didn't >> bottleneck that you have and you now have physical appliance network card there. Yeah. How do you plan on replacing that in the future? So, I mean currently we use SR-IOV and DPDK and as mentioned, we basically mount the kind of we use we consume the interface card network interface card directly from the from

within the pod. And um I think DRA can help us a lot with going forward in that in that sense. So, um but we Yeah. We built it with the legacy tooling we had. Um yeah. Yeah. Thank you. Dorian, Deutsche Telekom. As you well know, we have a bit less issues. example, no netconf. So, this problem solved. Yes. Like I think the elephant in the room is

that Telcos always believe they can do As one example, instead of relying on Kubernetes services, we have seen that the vendors will bring their own software load balancer because there is no way that Kubernetes can do that, And I think we have this issue because they will only provide one architecture. They will not do one architecture for Kubernetes, then one for on VMs, then one for on

bare metal, whatever. So, we're not even aligned in do we really want to use this Kubernetes? And I think with 6G, this could be the point where we say no, we are sure that this is the path. And then if everyone does it, maybe we can just use the Kubernetes services, you know? Yeah. Fully agree. Yeah. Hi. Svetlana, Deutsche Telekom Cloud Services. And first, let me thank

you very much. Huge thanks for this Because um I would say we really feel the pain and there's a lots of people in this uh group, I would say. Mhm. So, you brought us hope. You brought a ray of hope into our houses. So, thank you for that. Um the question would be I'm sorry if I missed it in the presentation, if you contribute or plan to

contribute to 3GPP HSI standards. Um yeah. So, I mean I can speak for Swisscom. We figured it's it's really hard to directly influence the standards as a small telco that we are. uh currently currently there's there's not a lot of activity going on there and we hope we can influence them through uh collaborations with the vendors or collaboration through um other not not so hard standard bodies

like Sylva or the CNTF. Yes. I don't know, maybe for you. >> Yeah, yes. Sim- similar. So, Telstra has some influence towards the the specs. But what we're seeing is the 6G part is still heavily on the RAN side. Uh but that that's why we want to push the direction on the on the core core aspect, like everything going on the Um and um yeah, so influence

it towards like the the the 6G side, like when when the those discussions happen. Yeah, for sure. Okay, great. So, then good luck with that because we all want it to come true. Yeah. >> Thank you. >> Uh thank you for your presentation. First of all, um my name is Giorgio Cassini. Um I work in a small telco as And my question would be directed in towards

this, meaning that uh as you outlined, uh there are several telcos, especially the little ones which which have haven't fully transitioned to a real 5G core network. Yeah. And um regarding that, do you think uh most of the elements you outlined related to the containerization of the uh core network services and not making them cloud-native directly, do you think this is um this is caused by a

gap in terms of knowledge and um the gap between telco teams and DevOps DevOps-oriented teams, platforms teams. Um I'm noticing um in in telcos like mine which are um in need not not big organizations, but where there's a still a huge gap between uh you know, still net- network teams, pure core uh telecom teams and and the knowledge uh related to cloud-native, Kubernetes technology, stuff like that.

Yeah, so so ob- obviously there's this this the skill gap. Um so, that's why as as you all mentioned, when we started introducing the the this the 5G core, for example, on Kubernetes, everyone was trying to figure out like what Kubernetes is. For the telco, it was new. Uh and not just the operator side, I think also as as an industry as a whole, we realized the

benefits and the and the and even the maturity of the platforms happened after introducing 5G. So, everyone's in a journey and obviously there's a there's a long learning that that you need to do. Uh And even it's it's interesting because I think it's it's a it's a really an industry-wide problem. And the the moment when I realized was when we worked with a hyperscaler and I realized

they're also hiring telco engineers in order to do their work. So, I had to educate them on cloud platforms and that was a really interesting experience. And I think the the telco industry is still, yeah, like like Dorian said earlier, um we we know we we as telco, we think we know better, right? And maybe we need to really start learning from from cloud-native, from IT and

and really build up that knowledge and we I think we need to be faster than we have been in the past, yeah. Thank you. And if I can, that leads me to a second small question. Um uh related to this, um did did you find any uh hard points in terms of walls between in the in the business side of things that you notice already some big

improvements when actually migrating the the uh network on uh the rendering it cloud-native in terms of latency, did did you already notice some some differences that can be uh out showed off, you know, to the business side of the company? In terms of in terms of latency for provisioning and automation or [snorts] for for like traffic? Yeah, I mean naturally network latency. Ah, network latency. In that

regard, I don't have any insights. No. No, do you have any? I mean it it has improved for certain bit, especially moving to bare metal. Um so Yeah, so we we had the OpenStack layer in between and now we are transitioning to bare metal. Yeah, and and also it also has a certain level of like the scalability. Okay. So, as you mentioned, it's more going 6G. Uh

Mhm. Yeah. But but we I don't think anyone has figured out like the spec for the 6G core or even like a 6G like the core side. Uh still still applies here. Thank you. Thank you very much. Thank you. All right. So, my my name is Deng Hui. I work for Huawei and uh uh I think this slide is very encouraging and I see the persistent effort

uh trying to solve the uh motivations. I think this is very good. Uh my my my comments would be you are talking about 6G here. I think there are two directions discussing today regarding the 3G uh evolution uh whatever. So, there could be uh like a continue like a 5G core uh similar solution. The other one could be more like a uh people are proposing like a

AI-native style, right? So, so my my my recommendation for you to consider is uh are we still solving yesterday's yesterday's problem or you looking forward? I mean, because when I listen to the keynote of this morning, I see the CNCF even also looking at the AI-native agentic AI, this kind of new technologies. Mhm. But we if we still looking back about yesterday's questions, Mhm. uh would that

be because the this is the really uh I mean, we we I think the CNCF is evolving. I think telco also need to consider. We also need to evolve in together. Otherwise, we have to thank >> I I think, yeah, I agree. We need to look look forward. I think the the the things we're pointing out, uh if we don't solve them, we're not going to do

any good with AI-native networks. They're not going to work. We need to do the cleanup, the proper cleanup and make make our systems stable, reach a high quality standard, which we don't have today. We don't have it. And then we can talk about the the future the future steps. >> And and maybe to add to the that, right? I think the the network it it will run

Yeah, so whatever comes next. And the the foundation needs to be done properly before we we add any additional like the the the features, etc. like what whatever happens next. Because if not, the life cycle part will cost cost a lot. Yeah. Like these are purely like we're we're purely like bypassing the Kubernetes like the the the features, yeah. And I think there are synergies between AI

and and telco over cloud. You pointed that out very very briefly, but the RI, for instance, that's something that has gained traction because of AI as well. So, there are synergies also so we can leverage that. >> I I think there's another uh I understand step-by-step solution, but I I do see uh there's a one possibility is the AI might solve some your problem. I mean, you

don't necessarily And we need to explore we need to explore that. Yeah, that that's my claim. For example, I saw the Barcelona demo. They are using agentic AI. Work I think Docomo has made that demonstration. Yeah. So, this is more like a we have to look forward. I'm going to Of course, yeah. Thank you. Hi, I'm Nunzio. I'm an SRI. Uh I'm not coming from the from

a telco So, uh if my question doesn't make sense, let me know. So, uh first question that that I have is uh if you keep state and uh if you keep it in Kubernetes or outside. And the second one if is can you run this multi-region? So, can you repeat the first one? >> Yeah, first question if you have any states to maintain the 5G core, like

in terms of data, like registration I would imagine for user and if you keep them in a DB in Kubernetes like in a person's volume >> or outside like on a separate >> we do keep that in Kubernetes in a in a database. Uh the next one is on a So, you keep them on a on a on a database, okay. Any any challenge with that? Like

keeping them like if you keep on a person's volume in Kubernetes? I mean, we haven't seen any challenges on the maybe maybe when it comes to the scaling aspect. And also when we start distributing them, like say for an example, you said are you asking about this geo- geographically Yeah, the second question was related if you run this multi-region and if can this can run active-active or

it's kind of active-passive where you to manually fail over to the second region. So, there there are different flavors of that because different applications behave differently. but what we are seeing is there are have challenges when you start sinking this dual rate pulse, etc. And also some are tied to like n plus two, you can't have like more than like n plus two. Uh yeah, that's all.

The I think that the state of the databases let's I would call them maybe long-term storage data. It's not like the what that it's the slow data storage, I would say. There is the fast data storage when you open a session for instance. >> Yeah. This session needs to be persisted at least in some way right? Um and this this session management that's the more complex part

and that's where we have to have more challenges where failover is not that easy and then you have things like if you if you reboot a node, uh you would kill the session on the user device which could kill the the phone call. For data it's not that dramatic, right? Unless you're in a video call or something. Um but um these the the the state is more

on the network state um that that is challenging, I guess. Okay, so the moment you run in one single region, if I understand. No, it would run multi-region. >> Multi-region. Yeah. All right, thank you. Yeah, thank you. Thank you. Um so I'm here to ask you from NTT Docomo. Um so the the your requirement is a much beneficial for the industry to pushing the the cloud native

journey to the much advanced for the future networking. Uh so my question is of course you uh work with the your partner vendors. Um did you find any changes of the design philosophy changes um design principle changes for the your recent done or your requirement for the future implementation? Should I go? Yeah. So I I think I think we we are all in a journey. Like so

as I mentioned like even with our like the main vendors, etc. So we trying to figure the journey. So they they this because of some of the standards being implemented prior to the like the maturity of the platform so being introduced to the Kubernetes, it's taking a bit more the legacy approach. So there's one side on the standards, the vendors and the operators. More from the operator

side. Obviously there's this mindset change on um I'll give you an example. We want to bring more abstraction to the So a lot of the engineers are used to seeing IP addresses in the config, the interfaces, link to link, like those sort of information in the And if you want to abstract them, that information doesn't sit on Git. So so your your source of truth kind of

like goes into the source of intent and that knowledge is distributed on all the fit for purpose tools. yes, it's a mindset change, but it's a journey. So we all figuring out on on that, yeah. But I think one one concrete example is also Flux. We haven't um we we've played with Flux three, four, five years ago. Um but it was very experimental and now we're moving

more towards direction where it's actually an official way to deploy. Um but um yeah, that was a long a lengthy process, I would say. Yeah. Okay, thank you.