 All right, good afternoon, everyone. Now we are going to start our session. The session is titled, Implementing Private 5G Networks for Enterprises with Kubernetes. I'll introduce myself and then hand it over to Christian. I'm Amar Kapadia. I'm part of a startup called Arna Networks. I'm Chris Jagirbna with Mirantis. I've been with Mirantis for the last 10 years, which is pretty long in IT terms. So I come from the cloud platform side, and as we are strong in Kubernetes now, I'm also taking over Kubernetes duties. I'm the manager of the architecture team, but do more architecture than management at the moment. All right, so let's get started. So first of all, what is private 5G? So whenever I say 5G, people start thinking about the phone. You start thinking about, when can I get my Netflix movie? How can I download it faster? So private 5G is not that. Private 5G is a non-public network used only by one organization for its own purpose. So in that sense, it's a captive network. And as I'll show in the next slide, private 5G is especially suited for sensitive traffic. And actually, just one more point on the preview. So it is expected that private 5G will accelerate digital transformation hand-in-hand with edge computing. And what it will do is it's going to be, as I'll show in the next slide, the ideal network to connect edge computing applications to end devices. And you see some of the segments, you know, 20% to 30% productivity in the factories and industry 4.0, tremendous water savings in agriculture, health care, 305 billion saved through these technologies. So now why is that? So we can go to the next slide. So private 5G has a number of technical attributes that makes it especially well-suited for these types of sensitive applications. And honestly, I would say it's the first wireless technology that is a legitimate replacement for wired ethernet. And by the way, private 5G does use the same underlying technologies as public 5G. So you get economies of scale and you get all the innovation from the public 5G networks that can be used for private 5G. Just some of the key points on private 5G, there's actually more. Of course, it's faster data rates. I'm going left, ultra-reliable low latency. That's another key feature of 5G. So you get end-to-end latency of five milliseconds or below 99.5 lines of reliability. As I'll show in the next slide, it's all software-driven, so you can deploy 5G in minutes. Energy efficient, there's technologies like beamforming. So you get energy efficiency, 10% of current usage, support for IoT million devices per kilometer square, 100x increase. It's more secure. There's a concept called network slicing. So you can put multiple workloads on the same private 5G network. So these and many more are the reasons why private 5G is going to be so effective. Now, what is the connection with Kubernetes? You're thinking this is a network. Why are we at a KubeCon event? Well, there's a good reason. If you look at the before picture, that's how networks used to be built. So if you look at the predecessor to 5G, which is 4G or LTE, you would have boxes. And these boxes would be fixed function appliances. You would cable them up, and now you have your network. And then you would have a management layer on top. That's not how current networks are going to be built. The current networks are going to be built on Kubernetes clusters that are sitting on commodity server switches and storage. And the entire network is containerized. So other than the radio, which is a physical piece of equipment, your radio area network, it's all containerized network functions. 5G core, again, containerized network functions. Edge computing applications, they are containerized applications. And what you have on top is a service management and orchestration layer that manages these network functions and applications across hundreds or thousands of clusters. So that is how private 5G networks will be put together. And now I'm going to hand it off to Christian to talk about some of the challenges and then get into Kubernetes in a lot more detail. Okay. And I can flip. So why is it difficult? First of all, networking is always difficult. I think that most of you would agree with us. But in this case specifically, we have a number of additional components that need to be considered. We have authentication in this network. If you were to build this, everything like this could be built from open source components that are available. The downside to this is that it is going to be rather, let's say, a daunting task to do. We have the 5G application itself and we have always in network context, we have very stringent requirements in terms of reliability, security, uptime, time to repair, all these SLA adherence and all these have to be considered in a build like this. But let's start on the very other side. How can you as a new private 5G engineer try this on your own and figure out whether it works for your environment? So what we are going to show you today, including a short demo, is built on a very small Kubernetes cluster for the 5G application orchestrator, which is in its simplest form, a single node that is doing everything. The rough requirements are 16 virtual CPUs, 32 gigabytes of RAM, 80 gigabytes SSD. It could be on a cloud somewhere in the cloud. It could be on a hardware device, but meeting those minimum requirements is certainly going to make your experience better. What you also will need is that 5G radio that I'm described earlier. This is just a piece of equipment that has either net on one side and 5G radio antennas on the other. And we will need, if we build multiple edge clusters for this, we will need multiple radios, but you can try it out with a single one if you really want to test it that way. The servers are industry standard. The core needs to be x86, but the edge clusters can be on ARM technology. So storage and networking, also there's a storage component to this, of course it will be necessary to save persistent data for the environment. Networking for the 5G network functions that is also managed by the AMCOP platform. And if your network functions may need data plan acceleration for test purposes, this is not necessary. The software side, you could put it all together manually or I personally do not have a lot of patience and I definitely do not have a lot of time. So using a component that is already available that I can download, that I can deploy on my Kubernetes clusters will make my experience, my personal experience a lot better for this. And I'm also not in the business of creating 5G networking, so it is in my best interest to use something that is already available. The orchestrator that Amal mentioned at the beginning is also running on Kubernetes and the way to deploy it is very simple. I really liked it when I saw the deployment in that this is only three components that are deployed one after the other in the right sequence and built the whole application out of the box. You know how complicated network orchestration can be to deploy, so this is actually, this was a very good experience. This also, this product is open source, so it is possible for you to, it will adhere to your open source requirements for your environment. Now let's step it up a little bit. If we were to deploy this on more than just that node, you would have to consider a whole bunch of other things. This is, let's say an example that I put together. You have multiple sites, you have a data center where you are running your core, you have a factory, you have multiple factories, you have office buildings, you may have 5G orchestrate, 5G edges in, for instance, public places. So this is, if you try to do this, all this, you have to have some sort of orchestration behind it. I put MCC, container cloud in there because this is what I would use if I was to try this out because I know it well and it will do well as a orchestrator for a number of Kubernetes clusters. You could use a different underlay, but this is what I would consider if I was to build this. The other thing on top of all that is MCOP, this is the actual 5G orchestrator, that will then take the Kubernetes clusters that I have built from my container orchestrator and will orchestrate the 5G network components on there. And each of those, you have to imagine because I didn't want to make it too complicated, you have to imagine each of those 5G Kubernetes applications again has a connection to this radio for the local environment. Is it possible to run more than one radio of a single edge or can you only run one radio? You can do multiple, so you can have different ratios. If you had like for instance a factory building and you want to have antennas across the whole building, you can have multiple antennas that are running all of one Kubernetes cluster. So yeah, some of the questions that I asked my customer for enterprise grade deployments and they of course apply here too. The one, the most important one in my opinion is life cycle management. If you do not solve that properly, this is going to be an unending headache because you have, especially with Kubernetes which still moves very fast, you have constant updates coming along and if you cannot do this in an automated, reasonably automated fashion, you will have a lot of work on your hands. Additional components. One component is a single sign on if you have many Kubernetes clusters and you have antennas running those, you will not want to have to local login on each of those Kubernetes clusters. Imagine you have 200 Kubernetes clusters and you have to locally manage every one of them. So this is a sort of a picture of what an enterprise environment would look like. And yeah, the key point. Why is my microphone sounding so different when I'm standing here? Anyway, one of the key points is suitability for the required and desired use cases. Yes, you can build all kinds of things but the end result of what you are going to be measured on is going to be how well it does for your business. So if you are building, let's say, a 5G network, I could build a beautiful one from scratch but I would have blown all my financial and reliability goals. But so basically make sure that it fits your business well. So from my experience and I've done this for a lot of customers, we have always have three options of building an environment. We can build the desktop's way which typically is the worst outcome. But if you scale out, it is good when you do only a couple of clusters. If the larger the environment becomes the more difficult it becomes to manage. You could do a plant in-house design which typically has the problem of having a very long lead time until you can actually deploy it. And this is also going to be a business problem. And then you can have the commercial solution. A lot of people do not like to hear commercial but in reality if you buy a commercial solution, you are sharing your development costs and development times with other people who are also buying the solution. Okay, so when you're looking for this 5G solution the first thing is I would talk to my stakeholders and put together the requirements from all stakeholders and figure out how and how I want to do this. If you're going to go this way, the MCOP way, this is going to be a very quick start for your organization and I think that this is going to be something that you should seriously consider. If you do not do this, and I think some people, some companies, people who are in here have the critical mass to build a solution by themselves, make sure that you have an answer for all those enterprise items because this is what you're in the end are going to be measured on this. In a couple of years nobody is going to remember how much less it cost initially but they are going to crucify you if you are down four to three days in a row and you will not be able to build this, especially in a network environment. Okay, so we talked about the Kubernetes layer and a lot of actually what Christian said applies to other layers in general but we talked about the Kubernetes layer. Then if you remember from my picture you have network functions, you have the RAN and the core and then you have service orchestration on top. So what is orchestration of Private 5G? So we can talk about it by functionality and by type. By functionality it is orchestration and day zero configurations. Orchestration and day zero configuration is just initial, initial deployment of all these network functions and setting them up. But then like Christian said, day zero is just the beginning, right? The real challenge is day one, day two configuration and life cycle management. So that's another thing the orchestrator has to do. Then you get into collecting analytics from your network functions, the Kubernetes layer and potentially even the hardware platform underneath and then what do you do with those analytics? There can be logs, metrics, events, alarms. So what do you do with that? There are two things you can do with that. One is open loop automation which means you display it on, visualize it on some dashboards and if there's a problem you open tickets and then you have human beings looking at those dashboards and tickets and doing something about it. The other technique is called closed loop automation where you have a machine deciding what to do, a machine learning model or a big data analytics application microservice. It looks at the collected data and through a policy engine drives an orchestration or a life cycle management action automatically. So that's what an orchestrator means. Even though we call it an orchestrator it's actually a lot more. The second thing is by type. So even though today's talk is private 5G you could be doing public 5G, public 5G architectures are actually quite similar and that's a good thing because in private 5G we want to leverage all that innovation in economies of scale. Private 5G, RAN, Core, we talked about but there's other things you could be managing as well. Like the transport, UE stands for user equipment. So it could be, normally we think about the phone but in a private 5G setting it could be a HoloLens, it could be a drone, it could be a robot, it could be IoT. You might have to configure a gateway, private 5G gateway that goes from Bluetooth to 5G or something like that, SDVAN. Edge computing applications have to be managed. So AR applications, retail applications, machine learning, whatever the application is edge computing. The infrastructure underneath, so it could be hyperscaler, it could be AWS local zones or Google distributor cloud edge or Azure stack edge or it could be private. And then there's a concept called network slicing where you split up a network into multiple for different workloads. So that's the role of an orchestrator. What are the new requirements? So orchestrators have been around forever but why is it different for private 5G? First of all, cloud native. So fortunately, everything is moving to cloud native. You have cloud native network function, cloud native applications. Occasionally we have some virtualized network functions, VNFs, but Kubernetes can handle them through technology such as Cube Word. So not a problem. Diversity, you have network services, infrastructure, edge computing applications, you have to manage all of this. And I would say the biggest item is the scale. You could have tens of thousands of sites, dozens of vendors and it's super dynamic. The edge and it's super dynamic. 5G, private 5G is going to be super dynamic. You're going to be updating, replicating, migrating, spinning up, spinning down all the time. So that's what creates new challenges. Role of open source. Mirantis and Arna, we are both huge proponents of open source. And I'm not going to go through this. I think if you're here, you're familiar with it. But maybe just the first point, open source is increasingly the reference implementation for open standards. And so you'll find that open source is often at the bleeding edge of implementing standards. Of course, reduces vendor lock-in. You can influence open source projects. Open source projects are more secure. You've heard of this before. So these are not some, these are projects you may not have heard about or you may not be familiar with, but these are actually all Linux foundation projects that pertain to service orchestration. There is MCoEdge multi-cluster orchestration and Linux foundation networking. That's for deploying cloud-native network functions or cloud-native applications across lots of clusters. Nephew is a brand new project. There's a talk tomorrow by John Bellarmic from Google. If you are interested, please check it out. That's to orchestrate and manage heterogeneous cloud and edge infrastructure, network services and applications as well. One app is more of a traditional Telco management and orchestration platform. CNC, if you know. And then Oran Software Community works on OpenRAN. It's taking the radio area network and opening it up. And Arna Networks, we take some of these projects and create the orchestrator that you will see in the demo. Then I think it is time for the demo actually. So, yeah, so maybe while you're bringing it up, I'll quickly describe the demo. So, today I'm going to show you the process of onboarding feedback. Okay, so maybe, yeah, let me just give quick context before we play it. I think we have time, right? Yeah, we do. So, normally, spinning up a private network would take you months. You would have to order the boxes and then once they come in, a specialized personnel would have to hook them up, configure them. It's literally months. What we are going to show you is going to be in minutes, we are going to spin up one component of the private 5G network. We are not going to spin up the entire network, but we are going to spin up an important piece called the 5G core using an open source 5G core. This demo can easily be extended. We could orchestrate the RAN as well. And so, within five minutes, you would have the entire private 5G network up and running. So, today you'll just see a piece of it. Publication using RAN networks in the T-Coaster orchestration platform. You can't hear? You can't hear. Is it hooked up to the speakers? This is, oh, this maybe. Okay. Let's see whether this will work. So, first of all, let's download it. USB, maybe. Yeah. Okay, then let's try that. I'm going to wait real quick to see whether we can get the... The process of onboarding the 3.5GC application using RAN networks multi-cluster orchestration platform and then orchestrating the 3.5GC under Miranti's Kubernetes engine. So, first of all, let's explore the environment a bit. Let me show you. So, this is in key cluster provisioned with the help of MCC, Miranti's container cloud. It consists of five nodes, three masters and two workers. Each machine has eight vCPUs and 16GB RAM. Operating system is Ubuntu version 20.04. Also, you can see the QBled version here. And also, for now, there's no workload in default namespace, as you can see. So, now let's jump into M-COP dashboard. I've already onboarded this in key cluster. Let me show you quickly. So, we can skip this process and proceed with the deployment of 3.5GC. So, first of all, we need to add tenant. Let's put the name 3.5GC, click Add, then expand the tenant. Then we need to add a logical cloud. Click on Create logical cloud. Let's put the name 3.5GC, for example. And also, we need to select our cluster here. Click Create. Then we need to add service. Click on Add service. Let's put the name 3.5GC as well. Add application, 3.5GC also. Click Add, expand. And here, we need to add our tar files for the health chart of 3.5GC. We can just drag and drop. And also, we need to add the configure write file here. So, after that, we need to click Submit. So, we created service. And let's then create the service instance. Click on Create service instance. Let's put the name 3.5GC as well. Service 3.5GC, select logical cloud. This one that we created previously. Service version should be V1. And also, we need to put version V1 here too. Click Next, expand it. And here in Select clusters, we need to select specific cluster type and select our cluster. And click Submit. So, then we need to instantiate service by clicking at this cloud with arrow button. Click OK. Service instantiated. And so, we can see the deployment process here. But let's jump back into terminal and see how deployment is going. So, as you can see, the pod is starting right now. So, let's wait a bit. Also, we can do this. Yeah, so for now, everything is up and running. The application is healthy. So, that's pretty much it. Thank you. I have to thank my colleague, Roman Kuzmin, for creating the demo. He was very quick about it. And I think he did a great job to visualize this. So, to reiterate from simplicity here is a key factor, being able to spin this up in a very short amount of time. On commodity hardware, the only thing that you really need in addition to your commodity hardware are those radios. It's a major advantage, both in terms of manpower and in terms of time until your 5G network can be operational. Of course, we all know that this is not going to be quite as simple as it sounds. It is going to take some time to procure the radios. But it is going to be on average a lot faster than buying those proprietary appliances and wiring them up. And then building the environment on that. And especially when the time comes around to do something new, let's say 5GC, a free 5GC is replaced by some other new component that is better. If you have a new appliance, you have to go back and you have to pay another 50,000 bucks for that appliance. In relationship to this, we are basically the same orchestrator will be updated to allow you to deploy this new component and replace the existing component. So just from the standpoint of being able to follow technology quickly and to build something that is both stable and flexible, this is, I think, this is a very good choice. Thank you. All right, thanks. Thanks, Christian.