 Good morning, everyone. For those who just joined Cube India, welcome. I hope you guys enjoy as much as we are doing so far. And for those who have been with us since 8 AM in the morning, please, guys, hang in there. Lunchtime is almost there. I would like to start the presentation by asking you guys a simple question. How many of you have worked with eBPF and its usage on 5G applications? OK, I see a couple of hands. It's a bit tough, right? I know. Let's make it more simple then. How many of you know about this famous character, Ant-Man, from The Avengers? All right, guys. I know, I know. So it would be crazy to say that Ant-Man is to the quantum realm, as the eBPF is to the inner core of a Linux kernel for a 5G. Sounds crazy? Today, Prakash and myself, Marco, we talk about this in that topic, paradigm shift in 5G deployment. It's a problem for eBPF, for open source, 5G cores, performance, and security. I will start with just listing the content. We start with the introduction of ourselves, followed by a problem statement and hypothesis. Then we will discuss about the state of art, followed by the pre-designed environment we prepared for the presentation. Last, we will work on the verification of results and some takeaways. OK, let's move on. Prakash? Yeah, thanks, Marco. Hi, guys. So my name is Prakash. This is a brief introduction of mine. So I'm from Andhra. And my tech journey began when I did my bachelor's in computer science, followed by post graduation from UT Austin. Right now, currently, I work as a cloud architect in Accenture, Japan. And there, I tried to develop and deploy cloud solutions. And my hobby is doing snowboarding and having fun, so looking forward to having a great session with you all. Over to you, Marco. Amazing. Prakash, smart guy, I'll pray that, guys. Smart guy. About me, my name is Marco Gonzalez. I'm from Lima, Peru, South America. I've been working in telecom for over 14 years now, a long time. And now I work as a 5G inclusion architect at Ericsson, Japan. In my free time as an AWS Community Builder, I talk about AWS, 5G, and this mix of both. You can check out my blog, the link. And also, sports, a lot of soccer. Okay, guys, that's enough for introduction. Let's jump into the good stuff. Before that, short disclaimer, this presentation contains some information that belongs to our personal opinion and insights. That being said, we did not want to reflect any position or views for our companies. Please, guys, take a look at the following diagram over here. We tried to summarize in five items all the current challenges 5G is facing right now. The first one, challenges in performance and security. Every system we have right now are facing these evolving threats of security and demands grow speed and reliability. Since 5G entered the picture, it has been the same. Second one is the demand and complex, sorry, dynamic and complex 5G demands. 5G is by no means guys aesthetic. It changed over the time. It changed since 2018 and we will keep changing. And for that, we require a robust, yet flexible solution to manage them. Third one is a very common scenario, improve user experience under the most difficult environments, let's say, overload scenarios. That's what customer wants, quality, always. Fourth one is the current dependency we have, the high dependency on current modules and proprietary hardware for 5G solutions. It's a big one, guys, and we'll talk about this today. Last but not least, the cloud solution, multi-cloud and hybrid solution we have so far, yet they have so many approaches that fall short when we want to deploy 5G solutions. Based on these five items, we prepare the following statement. If 5G core can coexist with EVPF, then can performance and security be improved? By the end of the discussion, we will know the answer about these questions. Let's start with some sort of art about EVPF. And for that, let's focus on this diagram. It shows a conventional container networking solution. You can see the pot which the application can be anything, can be 5G, for instance, sockets, IP tables, then routing, and the internet interface. This pot connects to the node or the host node using this virtual internet, and then we see again a duplicate view, right? We see again in the host nodes, IP tables, routing, and, of course, more overhead. It helps us to solve the most common solutions right there. Create stacks, isolate pots, and make communication between them. But, in fact, they add a big overhead, and we will talk about this. I will zoom in and try to mention the three most well-known overheads we have so far. The first one is the context switch overheads. It happens when the packages go through the internet in the pot all the way to the internet in the host node. The second one is perhaps the most impactful one is the IP tables overheads. When the packages go traverse from the pot to the node, we see all these overheads. And last, we have the contract or connection tracking overheads. This is how IP tables identify what to do next with the packets in the summary of the stream. So then we ask ourselves, what is EBPF doing then? How is EBPF solving this? In simple words, EBPF is removing all these IP tables overheads. EBPF uses customized packet filtering, processing, and programmable network data path on each Kubernetes node, and this allows us to minimize first the context switching, then it reduce completely the IP tables overhead. And that make us have the full latency and CPU overhead reduced. Let's see some example about this following slide. A key difference between IP tables and EBPF is latency. In this example we took from reference, there are 100,000 sequential requests being sent to a Kubernetes service. And this is not just any kind of request. They are TCP connect requests and response, which means the whole cycle. And we can see by far how EBPF outlasts IP tables. And as we increase the number of services, we see this difference way bigger. Another difference that we can highlight is how EBPF solved this IP table rule, this mess we have right now operating this. For those who have been into the operation work, handle these kind of lines of work, or these lines of IP tables can be really messy. So how EBPF solved this? Well, simply just remove them. No more IP tables set up. And this is key guys, because as we increase services in our solution, it becomes a crucial part of how to maintain this service. Which lead us to the next slide, 5G Core. We mentioned before that our goal is to co-exist EBPF and 5G Core. And we must understand three key points first. Telco APIs, guys, 5G Core is for developers. It will be like this and will continue to be like this. Enable 5G for developers and API exposure in 5G network. Why we mentioned this? Because the goal, the ultimate goal in our view is monetize 5G and cloud app solutions. So I have to say, but it's the truth. I'm not going to into the 5G topology because we can take a whole new session about this. I just want to highlight this small component here. Network exposure function. It is right now standardized by 3GPP as the edge how to talk with different applications worldwide. And then we ask how we can improve this. What happens when our element needs to handle 1,000, hundreds of services in a single infrastructure? Let's talk about our demo next. Finally, we believe in open source. Our demo, our demonstration is focused extremely on open source projects. In this presentation, we have used U-Around Sim and Open 5DS. For mainly two reasons, guys. First, the versions are really stable. We have deployed it, implemented in AWS environments. And second, guys, there's a huge community behind this. And community means help, support, and efficiency. All right, Prakash. Thank you, Marco. So now let's get into the project design and environment. If we go back to the beginning, the problem statement which Marco mentioned. So if 5G core can be deployed along with the EPPF, then can it optimize the performance? So that was the main question. So let's answer that through this project design which we executed. So for this, we deployed the 5G core in two different scenarios. In the first scenario, we tried to deploy U-Around Sim as one open to virtual machine and the 5G score in another open to virtual machine. And we established networking between both of those VMs. And after that, we attached an ad gateway for one way connectivity outside and we attached internet gateway so that whenever the UV sends a request, then it goes through open 5G score and it accesses the internet through the internet gateway. So this is the first scenario and let's check the second scenario. And here, the main thing to notice is we utilize the traditional IP table setup here. And in the second scenario, we deployed the 5G core as a Kubernetes port and keeping the U-Around Sim as a virtual machine itself. So our main focus here is to identify the metrics and the performance of the 5G core itself. So that's the reason we kept the U-Around Sim as a virtual machine separately. And here as well, we established a networking between both the U-Around Sim open to VM and the 5G score. And this is an ad gateway for one way connectivity. And here as well, there's IGW attached so whenever the UV tries to access the internet, so the flow will be from the U-Around Sim to the 5G score and again to the internet gateway. So these are the two setups which we executed. And now let's look at the components inside the 5G score. Before that, one more thing to point out here is in the first setup, as I mentioned, so we use the traditional IP Linux tables and here we use the Cilium operator which is EBPF enabled. So now let's look into the open 5G score part which we deploy and see what are the components of that. So without going into too much detail, these are the 5G core components. We have these are the 5G core components present in the report. If you see here, we have AMF, SMF, UPF, NRF, et cetera. So and this raises the question, what are we trying to achieve through this setup? So there are different scenarios in 5G, there's roaming, et cetera. So we are trying to achieve three different scenarios. The first one is the UE initial registration. So the UE registers to the existing 5G core following the security authentication and radio connectivity. So this is the first scenario we are implementing and the second scenario is PDU session establishment. So the UE, the user equipment requests both the RAN and core resource to start exchanging data traffic. So that is the second one. And let's check the third one. And here we are trying to provision the operations. So we try to register a new UE and an existing one in the 5G core database. So through this setup and through these scenarios, we are trying to see how can the performance be improved only if these scenarios are considered. Now let's jump into the verification and see the results of that. Yeah, so after we deployed the setup to simulate the traffic, so we need for those three specific scenarios. We do two bascripts. So the first basket, it generates the UE traffic and when I say generate the UE traffic, it means creating the UE users. So it all depends on the IP address availability of the subnet itself. So through those two bascripts, in one, we are trying to create the user equipment. We are trying to increase the user equipment. And in other script, we are trying to create the UE RAN sim links. So through that way, we are generating the traffic here. So after simulating this traffic to jot down the metrics, we focused on the following KPIs. So these are the following KPIs which we followed. First one is NFEI KPIs and second one is the 5G KPIs. So the first one, we are trying to check the CPU utilization for those three specific scenarios. And next one is a memory utilization. The third one is a network throughput. And the fourth one is a network latency. And when it comes to 5G KPIs, we considered the initial user registration failure. So it mainly focused on the AMF component of the 5G core. And the next one is the service-request-failure ratio. So it focuses on the AMF and the SMF connectivity. So those kind of specific scenarios. And the third one, if you see the number of subscribers, that is mainly for the SMF. So for the phase one, we tried to focus on the NFEI KPIs and this performance, how this performance can be improved. So if you can see here, these are the results of the performance after simulating the user traffic. If you notice here, the CPU utilization, the average CPU utilization, when we executed those specific scenarios, the average utilization when the AVPF is enabled is 0.24%. And the average utilization, when we use the traditional IP tables, you can see it's 0.47%. So one more thing to point out and note down is that for the dimensioning part, we just use one VCP and two gigs of RAM for the 5G core part and the Ubuntu VM as well. So these kind of percentage calculations has been done based on those dimensioning. So here you can notice that if you see here, the average utilization of 0.24% and 0.47%. So there's around 48% improvement when we use ABPF part. So it reduces the potential bottlenecks and reduces the memory of a CPU overhead. And you can see the next one as well. In the memory utilization, there's 18.9% and 29%. And here as well, we can notice that a significant reduction of memory overhead which is going on. And if you check the network latency part, so if you see here, the 2.2 milliseconds and the next one is 2.8 milliseconds. So whenever the ABPF is enabled, so we notice that 2.2 milliseconds and it's 2.8. So if you see, the improvement is around 20%. So that is not a small thing to note down. And this can cause significant improvements in the future, things which you are going to do in the 5G core when implemented with the ABPF. So through these results and from these verification results, you can see that there's significant improvements. With this, we go back to our main problem statement. So OT Marko. Thank you, Prakash. OK, guys. At the beginning of the presentation, we asked a question. Can ABPF coexist with 5G core? And not only that, but improve latency and CPU and security? The answer, guys, is yes. And we showed these great numbers. We just did a demo with over 100 UE connecting. We can escalate to more. Of course, it requires hardware. It requires research for more colleagues. A few takeaways. Guys, in this presentation, we talk about three core use cases. As Prakash mentioned, there are many use cases for 5G, guys. It's not only one or just 10. The purpose of this presentation is to show that ABPF can support, can be an ally to 5G, can improve many features, not only performance, security, observability, monitoring, and even dashboard visibility was improved using ABPF extended solution, open source solutions. And only that, we proved that we can implement it along with open source 5G solutions. So we help the open source community. Our goal today is to encourage any of you who is into 5G or just want to try ABPF and 5G to please use it as a reference and keep researching and investigating. Guys, I hope you enjoyed today's Q-Day, as well as all for all for our site. Thank you so much.