 Okay, thank you everyone for joining us. Welcome to today's CNCF live webinar, Cata and Arm, a Secure Alternative in the 5G space. I'm Libby Schultz and I'll be moderating today's webinar. I'm going to read our code of conduct and then hand it over to Kyle Freit, Principal Solutions Engineer at Arm. A few housekeeping items before we get started. During the webinar, you are not able to speak as an attendee, but there is a chat box on the right hand side of your screen. Please feel free to drop your questions there and we'll get to as many as we can at the end. This is an official webinar of the CNCF and as such a subject to the CNCF code of conduct. Please do not add anything to the chat or questions that would be in violation of that code of conduct and basically please be respectful of all of your fellow participants and presenters. Please also note that the recording and slides will be posted later today to the CNCF online programs page at community.cncf.io under online programs. They're also available via your registration link and the recording will be available on our online programs YouTube playlist. With that, I will hand it over to Kyle to kick off today's presentation. Hello, everybody. Again, my name is Kyle Freit, Principal Solutions Engineer here at Arm. So I started my life here at Arm actually as a DevOps engineer working on major infrastructure systems here. So, you know, all the major hyper scalers, so AWS, Azure, GCP, I recently moved to another team where we focus 100% on these hyper scalers. So think of it mostly as like taking on projects that are x86 based, trying to focus them back on to Arm or maybe providing adjustments or, you know, performance based changes to them so that way we can perform and excel on all the hyper scalers. As of recent, I've been mostly focused on 5G and networking within the Arm technology. So let's talk a little bit about the agenda today. So we're going to talk a little bit about 5G itself. Unfortunately, 5G is full of acronyms. It's, I think they kind of do it on purpose to make it harder to understand in my opinion. So we're going to have to go through a lot of acronyms to understand kind of what the importance of the RIC is, which is the main topic of this here along with CATA. I'll talk a little bit about ORAN, which is one of many different groups that are trying to do this here. And is everyone able to see my slides, by the way? Is it moving? Just got a notification saying that it's not moving. They are not moving right now. Oh, okay. Um, okay. Let me try to get that screen then. Sorry about that. No problem. So sorry about that. Okay. So let's try this one more time. So let's go over the agenda once more. So 5G and technologies and all that aspect here. So we're going to have to go over a lot of acronyms, unfortunately. There's a lot of systems that are all integrated in this entire RAN, this entire whole package of this. And then we're going to talk a little bit about ARM and its aspects within 5G. We'll talk about the RIC, which is one of the platforms that I moved from x86 over to ARM. We'll talk a little bit more about that performance requirements associated with it. And then from there, we're going to talk about how the importance of the RIC is within the RAN itself and the security implications of that. And then we're going to talk about deploying the RIC and how that's currently done and how we expect to do that. And then we're also going to talk about a little bit more about the orchestration lifecycle, how it deals with dealing with upgrades and aspects of that. I'll finish up with the conclusion remarks and then we'll have some time for the Q&A. So, acronyms. Unfortunately, this page is just full of them. This is just kind of a prerequisite for this. I'm going to go over some of the major ones here. Here on the slide, so that way people can actually want to go through some diagrams. We have the RIC, so that is the RAN Intelligent Controller. Think of this thing as the brain that takes in decisions from other aspects of the system, modifies them on the fly. And then we also have different components that are also like the non-real-time RIC, which takes in configuration things. They make changes, but they're not necessarily in real-time. They're not fast. They're kind of slow. Maybe it's configuration where we're adding a radio or something like that along those lines. And then we have the CU, the DU, and the RU. So, the RU is basically the radio unit. That's the thing that you see on the poles and you're driving by on the freeway or whatever. That's basically what connects to your UI with your user device, user equipment. And then from there, the RU is connected to this DU, which is basically digitizing what is coming off of the radio unit. And then you have this centralized unit, which is something that can control many, many DUs. Now, an RU can be considered something like a GNB or a GnodeB or Enoby. So, I reference 4G here as the Enoby because really, we've already spent a ton of money in 4G to get this up and running. A lot of countries and servers, sorry, operators are still using 4G. So, this infrastructure is going to last for a long time. It's not going to go away instantly as soon as 5G becomes a mainstream aspect of this. There's also that confusing thing as well here. So, Gnobies, which are 5G nodes, are also called new radio or G standing for next generation. So, again, these acronyms are just relatively hard to understand. So, that's why I wanted to provide this to you. And then some of the interfacing between each other. So, like the A1 interfaces, which basically communicates between the non-real-time RIC and the real-time RIC. Then we have E1s and E2 interfaces, which communicate between aspects. And then the almighty X2, which is the interface between these different nodebies, these Enoby and Gnobies. So, we'll move on here. So, I want to talk a little bit more about the history of the entire service. So, we started now as 1G. That was basically voice. You're talking about those bricks that people used to walk around with. And then we moved into 2G, which was also known as kind of like GSM. So, that's a basically improved voice, maybe a little bit of texting. And then we have 3G, which are integrated voice. That kind of had a little bit of an internet access to it as well. But we're talking about two megabits per second, relatively slow speeds. And then we have 4G LTE, which is kind of like the main standard right now, which is up to about 100 megabits per second. And then we get to 5G. 5G is, I think the record right now that I saw from Nokia was 4.7 gigabits per second. So, we're talking just a ton of throughput compared to previous generation here. Now, with 2G and 3G specifically, people were using controllers. It was very fixed setups. A lot of orchestration and management was just done basically one time. A lot of people using multiple different systems. With 4G, the idea was, hey, if we use these interfaces between each other using these X2, we can purchase multiple different types of RUs, different types of systems, and they could all communicate with each other. So this X2 is kind of like an open interface. Well, what really happened was a lot of these vendors actually took their X2 interfaces and kind of modified it. So they said, oh, R is, you know, X, Y, and Z. The other one does, you know, X, Y, and I don't know, B or something like that. So really what it did is it caused a lot of this vendor lock-in because then they couldn't really communicate with each other. Now, with ORAN, so the ORAN Alliance, they kind of thought about this. They said, okay, we're going the vendor lock-in route here. We need to try to open this up so that we, you know, if we want to use a better radio unit or we want to use different equipment for different aspects, maybe I want to, you know, customize this in some way and not just be forced to use, I don't know, Erics and Nokia, whatever it might be and only use that for the entire system. This allowed one to be more open so all of them could communicate with each other. You could reduce costs. You know, you could enable different equipment in different areas based off utilization. Maybe it's, you know, a farm-pound area where there's a lot less utilization instead of being in, you know, downtown New York City. Now, you're not, you know, you're not buying such a large, expensive machine for every little aspect of this. You can kind of cut and paste them together. And, you know, all these different people also are part of the ORAN Alliance. You're going to see some big names here as well. So, you know, we're talking Verizon, AT&T, T-Mobile for the United States, at least. And then, you know, we're talking about China Mobile, SoftBank. Those are big aspects outside the United States that also kind of want to be part of this new openness infrastructure. So, let's talk about ARM here. So, where does ARM fit? So, previous, you know, most previous generations, 2G, 3G, you know, 4G, even 5G in this aspect, a lot of this is x86 based. So, we're talking Intel systems or proprietary products, these kind of systems that are running major applications that are, you know, behemoth, monolithic. So, the idea was with 5G, we really want to get into that aspect. We want to be able to provide, especially with 5G being more of containerized in DNFs, you know, we want to be in all the different aspects of 5G to provide our performance and our optimization here. Now, a lot of times, I don't know, depending on, I guess, where you're located, in the United States, 5G just really didn't seem like that. It was kind of like a hype, you know, it's people kind of thought about it. They're like, oh, it's a little bit better than 4G, you know, you had 5G coming out on AT&T and you saw it on your cell phone and you got started seeing cell phones that had 5G, but it was just kind of like, I don't know where I'm going to use it or what it's going to happen. Well, really, in general, it actually has launched and it has been really taking over the systems here. So, this is a report for June of 2021. 22,000 5G sites already with under 160 operators. So, we're already, you know, a few months behind on this report here. And then we also have billions of devices that are already 5G. And as you can see from the map, you know, we have the United States, we already have launched 5G networks. I can talk a little bit more about that as well. And, you know, we have other companies or other countries as well that are deploying them or heavily investing in them or doing these soft launches. I think originally when I first read about 5G, I think it was like Korea that was really pushing this here. Now, with ARM, you know, we want to be in the core systems. We want to be part of the 5G core, the LTE core even. We want to be part of the RAN, we want to be part of those distribution units, those centralized units that are connected to those ENOBs, GNOBs. And then we're already on the RICBs, that's what I was working on here. And the high L1s and those small cells, L1, 2 and 3s. Now, when we mentioned 5G and LTE, we're talking about also connecting these existing 4G systems to have a GNOB, which is basically or EN GNOB, which is basically a specialized connector that runs 5G on a 4G system. So think of these as two separate systems that are running these RUs, these radio units here. So you get a phone that has 4G, it also has 5G, and then from there the phone can communicate with both bands. So they're basically doing 4G and 5G. Now, most of the systems may not have the 5G back in, especially since it's still kind of in the development phase right now. But at this point, your phone is able to utilize both 4G and 5G. It may route those things from the 5G GNOB to the ENOB via like an interface. But either way, you're able to get that kind of faster throughput. Now, most connectors and most systems were connected to the major internet. There's also different applications and things like that that are outside of that. Think of that maybe as like an app store or a web server, those kind of things. So part of the ARM enablement here is you've got to think of it in kind of three different aspects. So first, you know, we have the system. We have the developer system that's utilized to be able to do these 5G, these aspects of it. Then you also have to write the software that enables these kind of things like acceleration. And then you need to also find the systems, you know, the people that will create the architecture or use this and deploy it further. So it's kind of like the three-step process with ARM. You know, to find something that is utilized and takes on all these things is a very complex and hard problem. It's not something that you can just basically take off the shelf and just get everything up and running. A lot of times this has to be customized or optimized for these kind of aspects. Now, with ARM, we really wanted to target these with a software and a hardware vendor. So as I mentioned before in the previous slide, you know, we wanted to be in the core network, the RIC, the RAN itself, the L1 and the small cells. And you can see that we have it targeted with a software and a hardware company, in most cases, are coupled together. So that way we're able to take on that entire lifecycle of the previous slide, you know, providing the silicon for it, developing that, getting the software going to it, and then integrating it and using it. So we are part of almost all these different aspects here on with an ARM. Now, I wanted to highlight also a couple other aspects. So, you know, we are working on system-ready. System-ready is to basically make a system universally the same across all these different platforms. So there's not customized software. There's not customized hardware that you have to deal with. Everything basically runs exactly the same. It's like everything runs as like a server. So we have like the Cassini project, the DPDK, all these different aspects we are all working on in order to kind of push forward into the 5G solution. So I mentioned before about the RICs. So the RIC is the new real-time RIC is the one that I worked on and that I ported over from x86 to ARM. And there's a couple different components. There's four functional components of this RIC. So we have the orchestration layer. That's that non-real-time RIC. We're talking about configuration management. Maybe you're adding a new radio, maybe a new DU, CU, whatever it might be. And those are basically doing non-real-time slower actions. And then we have the real-time RIC itself, which is a component that's between those. Or sorry, underneath this here, which communicates with a non-real-time RIC. Takes this data in, maybe a configuration, maybe data from the overall system, does something with it. And then we have the CU stacks and the DUs after that. Now, the deployment within 5G itself, we're using a lot of VNFs, these virtualized systems. We're using containers. The idea is to distribute this across it. It's no longer some giant system that you use that has one piece of large monolithic software that runs this and is dependent on this huge system that is customized. We're trying to open it and we're trying to make it so that way we can scale appropriately. Especially when I mentioned the speeds of these things. 4G, LT, 100 megabits, 5G. We're going to 4.7 gigabits per second. That's a crazy amount of flow and performance that people are asking for. And as our lives become more and more digitalized, things cost much more. Your videos are no longer just a few megabytes. We're talking gigabytes. We're talking DVDs, HD quality that's going across these things here. We have multiple different services that are running. Throughput is a really big deal for this. Let's talk about the RIC here. Real-time RIC we talked about before, non-real-time RIC. To put a number on it to figure out how often these things are changing or how quickly they need to be. This is the overall architecture of the system here. We have the non-real-time RIC here that's along with the service management orchestration that's sitting here. It interfaces directly via that A1 to the near real-time RIC. And this itself also has access to all these different other systems. So it's taking in this data. Maybe it's chugging on this and doing some machine learning aspects of this. And I'll talk a little bit of this a little further. And then it's modifying the behavior of all these other systems. So with the RIC, this is a new aspect of 5G versus 4G. This is a system that helps modify and optimize it. With 4G, it was just kind of like if the system didn't work very well or there was a lot of people utilizing it and it was slow, that's just kind of the way it worked. There was no real way for you to make these modifications. A good example is like everyone goes into a stadium or something like that and you have thousands of the people in the stadium. You're going to start getting slower service. And unfortunately, that's not a real common situation. You're going to have them all the time. So everyone's going to deal with this kind of service degradation. Whereas with this RIC, we could say, oh, hey, I see a ton of people joining in. They're all going to the stadium here. Why do we start directing people to different RUs and being able to help support this so that way we can get more people on the network and they can get their quality of service? So I mentioned X-Apps. So X-Apps are these like third-party services that are developed either by like maybe it's say an operator, maybe O-RAN itself. O-RAN has quite a few applications that are able to be used right now. You can modify them, you can make them yourself. And again, they're taking this data in from different components of the RAN itself and ingesting that and doing something with it. In some cases, maybe you're not using any X-Apps at all and all it is doing is just management aspect of it. That's perfectly fine. But the real kind of exciting part of this is taking that data in, controlling, can change things instantaneously. I mean, we're talking between 10 milliseconds into a second. Over and over again, we're taking things and changing them all the time. So quality of service is kind of a renowned, sorry, not a renowned, but a common theme of 5G. So we'll talk a little bit more about this performance. So this kind of breaks it down a little bit in a better picture. So these are different aspects within this RIC and I'm kind of highlighting these different X-Apps. So these are kind of a few of the major X-Apps that are being pushed by O-RAN. Obviously, again, they're third party. So you can make them yourself. You can develop them yourself, whatever you want to do. And we're talking about slicing. A good example of slicing is, let's say, I have maybe a medical service, a bunch of different ambulances or something like that that are on a network slice of 5G. I have a bunch of cars, maybe smart cars that are doing this. And we're doing different optimizations for every one of those different things here on this slicing app here. Radio connection optimization, maybe an example of a phone that has 5G and 4G. You can basically auto-connect and say, hey, this person's UE, this user's equipment should go and connect to both 4G and 5G for optimization. Like maybe this tower is closer to here or this radio is closer to here. So maybe you should connect to this one instead. So these are very, very fast interactions with each other. And that's what the real-time RIC is doing. It's doing these modifications and decisions very, very quickly. And that's kind of the big highlight of this. Now, what comes in an X-App? So an X-App can leverage lots of different things. This graphic here is really good to kind of explain what aspects these things can do. We can develop it and go C++, Python. So it kind of opens it up to a lot of different people to be able to do this. You're taking in interface data. You're talking about the A1s, the E2s. You're taking in data from all that system. You can do something with it. A good example of this is that machine learning that I mentioned before. So maybe you're taking the data and you can kind of see the throughput of all these different people. You start seeing it slow down. Maybe you want to steer them to different locations or different RUs. You can tell devices, hey, we have more people joining our 5G, so let's reject them from using 5G and only push them to 4G if they are dual systems. Lots of different aspects of that. But again, really this comes down to low balancing quality of service, connectivity management, handover control. These are all things that this is really important on the aspect of this. So let's talk about some security concerns. I mean, I've mentioned all these cool things about the RIC and what it can do. And we talked about how it's taking these decisions and they're splitting instantaneous decisions on the system and modifying them, changing the DU, the CU, the RU and telling it to do all these different things. So that's kind of a big deal. That's something that has quite a bit of implications with this. So I'm sure a lot of people are thinking already, yeah, okay, there's already these problems. We get it. There's no big deal here. But I want to kind of highlight some of these things here that are concerns of this aspect here. So we have X-Apps. So the idea is that this is controlling the EnoBeats, the GenoBeats, the CUs, the DUs. So a lot of times these applications are probably not vetted at all. I mean, an operator will probably do a good aspect of trying to vet them themselves. Maybe they're having somebody write these applications for them. But in most cases, people are not probably explicitly writing exploits into them. But maybe they're using older methods or maybe they're using other packages that maybe have some exploitations on them. So you have things that maybe necessarily are not dangerous by definition, but are in a case when an appropriate situation comes up. The other thing, too, is X-Apps are not just a single thing you run. This RIC can run many, many applications at the same time. So let's say, for example, you're running the slicing application X-App and maybe the steering one. But from there, you have a third-party X-App that also interacts with other components of that. And maybe those services are interacting with each other in a maybe not a great way. Perhaps maybe it's resource-bound or there's having some issues with network trafficking or routing aspects of this. And then you can also have multiple of these RICs running the same application. So think of multiple different systems all running these RICs that are all controlling different DUs and CUs. And perhaps maybe those different ones are interacting with each other or those applications don't necessarily able to communicate or when they do communicate, there's other problems. I think another big aspect of this is the process starvation aspect. We only have so much limited resources on this here. So maybe if one X-App that is doing the steering or the machine learning requires heavy load, perhaps the other ones will starve out or not be able to communicate properly and then you'll get this quality of service. Now, the majority of this entire system is all orchestrated via Kubernetes. So our security policies rely a lot on the security policies aspect. So let's think about how we can take these kind of this cool technology and then bring it down and try to make it more secure. So really thinking about that Cata, since we know Kubernetes is along with Docker, let's think about Cata here. So Cata is a good natural fit to kind of secure the RIC and maybe the other components within this here. So let's talk about deploying the RIC. So Cata containers, I'm not sure if everyone has seen them or heard of them before, but we'll kind of go over them basically here. So Cata, OCI compliant run times, basically lightweight virtual machines. So we're talking something that's seamless. I can take a Docker container, modify it so that now it's running Cata. It's open sourced. Many, many groups all use this here. Multiple architectures. So that way, you know, if there's one system that's ARM, one system that's Xe6 or they're all ARM, whatever it is, they're all going to be able to work there. Then you have multiple hypervisors on this here. So QEMU, we have Firecracker. That's a very popular one that's even more restricted down. Now the community that is using Cata is growing. Obviously it's very large, but the key takeaway here that I wanted to talk about was these, you have some intersections here. So, you know, he had China and no mobile, China telecom. Those are other people that are using the Oran Alliance. So, you know, we're, or China Unicom. So, you know, we're already using both the technologies. It makes sense to just kind of slap them together here to kind of secure that. That's just kind of one of the takeaways I wanted to bring up here. So we've discussed Docker containers before in the past. I'm sure you've used them. I'm sure everyone has talked about them, but, you know, Docker containers are typically reused resource. You know, they're all shared. So this is a good illustration of a traditional container running Docker containers. You know, we do limitations based on C groups. Maybe you're using SEL Linux. Maybe, sorry, SEL aspects of this. Maybe you're using, I don't know, some reconfiguration, read-only amounts. You're trying to do things to help optimize this, not running as root user, those kind of things. But, you know, you're seeing that these three different processes are using multiple aspects of the CPU. They're using memory. They're using the network and storage. And since they're all shared, it's a great way for them to also share other things that are maybe more malicious. And, you know, in my experience in infrastructure and in other, you know, talks with other people, to mitigate this, people were basically running VMs and then running Docker containers inside those VMs. But then we're talking about large systems that require much more, you know, resources that are able to run on this just to run your Docker containers. The other aspect, too, was isolation. So we want to isolate them by using different systems completely. I mean, I guess that works. But at this point, you're also going to be using, it's going to cost more money. It's going to be harder for maintenance. It's going to be harder for orchestration of this. Maybe you want to do upgrades. Bigger problems come along with this. So then we move on to Cata here. So Cata containers are basically isolated themselves on the system using virtualization. So think of it as a major VM, but miniaturized. So we're talking about specialized, miniaturized, reduced-sized kernels for each one of these here, hardware is virtualized for every one of them. There is no intersection between each other here. So for the case of Kubernetes, VM isolation is provided at the pod level. Each pod is booted and it's a lightweight VM. It's a unique kernel instance. So the kernel itself can be modified, even reduced further for kind of an attack surface aspect of this. And now each pod is now running its own VM. It no longer has access to the host kernel. It cannot take something from that, which is basically the main concern of Docker containers itself. And then you get the full security of being that VM. Now, the typical scenario is you have much Docker containers. One of them gets maybe an exploit against it or some issue. Then they spread across all of them or you're doing memory poisoning or some aspect of that. Whereas here, we're all isolated individually of each other. So let's talk about orchestration. So I haven't gone too depth of here, but this is the RIC. So I wanted to break it down into many, many different components of the RIC itself. So as we look at it, this entire thing is the RIC here. So we have the X app and the configuration manager. So that's the thing that's basically taking these X apps and deploying them onto the system. They're deployed onto the X app namespace. And in this illustration, we have many, many different X apps that are all doing different things, but they're all within that same namespace. And then we have the A1 moderator, which is taking the A1 interface that we talked about before with the non real-time RIC. Those different aspects here, by having them just as single Docker containers, yeah, there is some inherent security that you're able to get with Kubernetes, but just think of the implications of this app manager. So if the app manager was to be modified or exploited, perhaps maybe versions of these applications would be then deployed that maybe don't necessarily look malicious, but maybe do something more malicious. Maybe a good example of this is traffic steering. I always, every couple of milliseconds tell them to move to a different system or different RU. So then the entire system doesn't work very well. The customers are having quality service problems or perhaps maybe the machine learning has a new model that is being deployed on there that causes some other aspect of the system to no longer work. A good aspect to, or sorry, a good idea also is the MRRMR, which is the RIC messaging service, which basically goes across and talks to all these different systems. So if you were to induce latency into that, then the entire system that brings up the RIC no longer works correctly or very slow. So I wanted to show a little bit more about like a Kubernetes kind of typical aspect of this. So we try to mitigate these by putting them on different nodes, maybe perhaps you're running them on VMs, and on the one on the left, we're talking about standard containers. Standard containers, we have four different systems, maybe a master along with all these additional other systems here. And to separate them is how we do this isolation. So your cost is four different machines, whereas let's say, for example, we use the Cata containers. And I want to also illustrate in this that not everything has to be running in Cata. You can run whatever run time you want. So if you want to run without Cata, and it's an example on the far right, they're not using Cata at all. So maybe this is just some other application that you have no concerns with or maybe it's test environment, I have no idea. But within this here, each one of them is running on the single node. So I have one node that's maybe the master and I have a second node that contains all these different services that are all separated by that virtualization within Cata. So this is just an example of the RIC. And I wanted to talk a little bit more about the different aspects of the namespacing on there. So we have the RIC apps. So each one of those apps is all isolated by itself, no more interaction with each other. And then we're talking about the RIC PLC, which is basically the initial setup of the system. And then the infrastructure that runs the RIC itself, those are all containerized in this Cata environment. So how hard is Cata to orchestrate and what's its lifecycle like? So I'm sure a lot of everyone's like, okay, Kubernetes is kind of hard to already use or maybe you're relatively new with it. It's already kind of, it's a little bit mind boggling a little bit at this point. So I understand the kind of hesitance of that. I know you gain a lot, but how hard is it to use and manage? Well, to basically get Cata running, there's only a few different steps that have to be done. You've got to install or compile version two of Cata. You got to modify your container D. You got to modify the runtime classes for Cata and then just modify your plugins. From there, it's basically plug and play. You from there are then now using Cata on there and you can change it for different hypervisors. So let's say for example, you want to run some as firecracker, some as the QME. So you have lots of different options and it's just a relatively modification of a bunch of YAML files and that's it. So the Cata agent is running on the guest system that's basically supervising and managing these containers. So it is a separate system compared to like Kube control aspects. You're going to want to look at to see which containers are running Cata, upgrading, modifying those. So there's a little bit of upkeep that it's a little different, but not by far many, many steps or anything like that. And then we can also use the lib container to manage the lifecycle of this container as well. So the idea is that you can reuse aspects of this and then be able to deploy a brand new pod, a brand new container, whatever you want to do with that here. And then it's also responsible for the entire lifecycle. So Kubelet is still taking care of the entire system. It's not like you have an entire separate item that does this. So I want to talk a little bit about conclusions. So we talked a lot about 5G, a lot of the aspects of it, the really cool things that are on there. So 5G is quickly taking hold and ARM is already going to be part of this. So as we mentioned, ARM has many, many different aspects of the 5G system. We're working with hardware and software companies to deploy these systems here. I've already, you know, completed the porting process of the real-time RIC. So we already have some major decision-making inside of this here. Also talking about that real-time RIC, there's a lot of security concerns. We've already gone over them many, many times. But, you know, we want to be able to talk about this. And most of these are easily remedied through Cata. I'm not saying Cata is the one-all be-all that is not the case here. But the idea is that it's a very simple decision that can be made to help modify this and make it more secure than it inherently is currently. And then the complexity of solving this has a combination of different tools that are already readily available right now. And then it also is supported by ARM. So one, you're going to get the security aspects of the ORAN SC, the RIC itself. By utilizing Cata and then utilizing ARM, you're able to get the optimization and the throughput that you're looking for at a cheaper cost and lower power. So I wanted to also mention, too, that I'll be attending along with a couple of my other colleagues, Kubcon. Hope to see you guys there. We'll also be on the virtual and physically there as well. And then we also have ARM Dev Summit, which is coming up as well. Hopefully you can also join that and learn a little bit more about ARM itself and how to integrate your systems with them. And then I also wanted to include some of the blogs that we have talking about 5G and the Cassini project. And that's it. Thank you very much for your time. I hope this was educational and was helpful. If you have any questions, please put them in the chat and I'll do my best to talk to you about those. Now, if you have specific questions about ARM and about maybe it's Roadmap or some questions like that, I can definitely direct those to go to market strategy people where they can reach out to you to provide more detail to you. Thank you. If anyone has questions, let's drop them in that chat box so we can get some answers. Looks like there might be a few in here, Kyle. Did you address these as we were going through? Yeah, I'm kind of going through some of your problems. Yeah, so I just I'll directly reply to these people here on this. Okay, so what's the problems with containers? Original, not Kata. So basically the idea is that the containers are using Kubernetes with Docker. So Docker is utilizing shared resources across this. For example, if one of the system or one of the Docker containers is utilizing a piece of memory, perhaps another service that's running on the Docker container or on the system itself can cause either let's say memory poisoning, you're putting something in there that the Docker container can read or maybe you're modifying another container where you're doing breakouts from that. Kata itself is able to mitigate that by using the VM. I'm not saying the VM is 100% the right answer. I'm just saying that's much easier by virtualizing the entire system and its resources than to just directly, you know, share it across. So why ARM is only porting from x86? I remember similar efforts being done by EPC. Why not natively build the RIC on ARM architecture to build more efficient solutions trying to understand what maybe the limitations here on ARM. So the idea was that previously on some of these telecom systems, they were mostly built on specialized architectures or specialized systems, major throughput systems here. x86 is just kind of like the typical partner that was done on here. So most of these systems were already developed on x86 in mind. ARM itself is pushing towards getting this completed and moving forward on there. So the porting process is just something that we did this, you know, to bring it over to here. But in the future, I don't see a reason why ARM would not be developing these applications or these architectures itself to help optimize them. But that's just to answer why the RIC itself was ported. I can take this question as well and bring it to our go-to-market strategy people to give them more of an understanding of what you're looking for. So if security concerns, why not use Firecracker as you mentioned more as restrictive instead of Cata? So Cata is the VM, is the same as the VM itself. Firecracker or QME, those are the hypervisors. So you could use Firecracker. It is more restrictive. That's perfectly fine. A lot of people do use it. It's just much more restrictive. I guess it kind of depends on what, you know, it's different flavors, whatever you choose to pick. How can we manage the Cata containers, the open-stack Kubernetes? So Cata containers are typically managed through the Cata agent, but the entire system is still orchestrated through Kubernetes. So there's not necessarily like one option or all options. I don't know if it works with open-stack. I'm not completely sure on that. I have not used it in that aspect, but you should be able to be able to utilize, deploy, check the status of those containers, you know, resource allocations, those kind of things through the Cata agent. If we're going VM for isolation, why not use Kupvert? I'm not sure Kupvert. I don't know how to answer that one. I'll have to get back to you on that one. I'm not really sure. I have not utilized that before. Any performance impact detected on Cata and RunC? Yeah, so there is some inherent performance impact. You know, always if you're adding extra layers, there's always going to be something that's going to slow it down. So I am not saying that by switching from direct Cata containers on Kubernetes that you will see the exact same performance. That is not the case. I mean, you still see the same exact impact done on the previous mitigation for Docker containers when you ran them as a VM and then ran the Docker containers in there. One, there's the orchestration aspect of that, but performance is, you know, you have an entire system that has to deal with all the virtualization of a much larger system, all these kernel, this much larger kernel with a lot of different impact on that, whereas Cata has a centralized slim diversion of this kernel. So it may not have all of the different aspects as a full-fledged system, but you're still going to get some impact. That is 100% going to happen. If you're not sharing the bare metal resources or some version of that and you're virtualizing it, then yeah, there's going to be extra stuff. There's going to be extra layers. That's unfortunate, but that's just the way it is. Any other questions from anybody else? I mean, I can dive deeper into some of the 5G if that's more interesting to people, but I really would like to go over. Let's see if anybody weighs in on for us. Okay. There we go. Okay, so porting the legacy VNS. Okay. Yeah, so that's kind of the big overlying thing with 5G is before with 4G, 3G, or even previous technologies, I mean, you're talking about proprietary systems that are running major applications that do everything. These are not configurable outside of the initial setup and run of this, whereas now we're pushing more towards the container, the VNS to be able to run these systems independently, scale them appropriately, upgrade them very quickly. That's kind of like the overarching theme of 5G is to be able to do this much quicker, much faster instead of buying hundreds of thousands of dollars of equipment for each one of them, and that's how you upgrade is by buying another one. Now you can scale those resources appropriately. Some 5G setups have special network requirements. Do these apps adapt to this use case? So the X apps itself can be developed by the operators. They can be developed by third parties. So I don't see a reason why any of these applications could not be developed in a special requirements for those operators. The idea is to utilize and leverage these X apps to make things much faster, to be able to utilize and modify, change the system almost instantaneously. So I don't see a reason why not. I guess the only aspect that I can say is that the O-RAN, the X app itself, are relatively new-ish. These systems are being deployed as we speak. People are utilizing them now. So there's always going to be some bugs that have to be worked out for these kind of systems, but I don't see a reason why this would not be a direct replacement of previous systems. The whole idea of the O-RAN Alliance is to provide a system that is now more open to reduce the vendor lock-in. So that way you can use multiple different types of systems, multiple different items together to adapt for the appropriate situation. So again, I don't know the specific answer to your question, Francisco, but I would think so. Yes, that they could do that. Okay, anyone else? Again, if you have other questions, too, that maybe I'm not clear on, maybe that's strategy-wise where ARM fits in this. I don't know what they're planning to go further on within 5G. I can always reach out to our go-to-market people to provide you better details and have them reach out to you as well. Sounds good. Well, if there aren't any other questions, we can wrap things up. Okay. Sounds great. Thank you very much for your time, everybody. I appreciate it. Everybody, thank you so much for joining us. Thank you, Kyle, for a great presentation. Just a reminder, this recording will be online later today, and if you have any questions, please feel free to reach out to us at online programs at CNCF.io. And thanks, everyone, for joining. Thank you, Kyle. Yeah, thank you. Have a great day.