 Thank you. Thank you. Really, really great to be here. And of course, fantastic to be following Andrew and his presentation. So I'm going to talk about 5G and why cloud native is essential for 5G. We saw in the video earlier that 5G is happening now. We're actually from Ericsson. We have 17 commercial contracts for 5G. We're rolling out 5G as we speak now, NSA. Q3 this year, we're also deploying 5G standalone. So definitely happening now. And we also heard this presentation a little bit earlier here. 5G, it's use case driven. It will start in the enhanced mobile broadband. So we will, 5G brings the possibility of lower the cost of delivering one bit to a 10th. So 10 times cheaper to deliver data over 5G compared to 4G. So that's why it's really, really important. We hear about the data volumes going up. So it needs to be cheaper to deliver the mobile broadband and the increased capacity in that. And 5G is there to support that. But on top of that, and I think that's why I'm also going to talk about cloud native and why that's important. On top of the enhanced mobile broadband, we see two types of use cases, use groups of use cases. Massive machine type of communication. So utilizing a lot of different sensors, supporting smart metering, smart agriculture, logistics, et cetera. But also critical MTC. And I think that's even more interesting maybe, where we see that 5G will support ultra-reliable, low latency communication, very complex abbreviation there. But still, it will see how these use cases come together around industry control applications, as well as autonomous driving, traffic control, remote training, even remote surgery. I think maybe we're not going to build 5G for remote surgery. But still, I think we did a very great demo at the Mobile World Congress together with China Mobile around remote surgery. And I think we will see use cases there as well. And this is, I think, also a great opportunity that we see in the industry now to really build on top of 5G. 5G is not just another G. It's actually enhancing and enabling new applications on top of the mobile broadband. If we've seen that the business development on top of 4G has been primarily over the top, I think we see that coming together in 5G with edge, with exposure, with the right speed, and the low latency, we will be able to build completely new use cases on top of 5G. And that's going to be a very interesting evolution over the coming years. But I'm not here really to talk about 5G. I'm here to talk about why 5G needs cloud native. And I think it's coming back to all of these use cases. Coming back to why we need the possibility to really, really quickly roll out, to shorten the time to market for our functionality. So to really be able to quickly deploy new functionality, to quickly upgrade functionality. It's also important that we can scale the software that we deploy. So cloud native will help us there as well. We need to be able to scale down, to deploy on edges. We need to scale up to manage the increased capacity. And to do that, very simply, very fast. And also there, we see cloud native and containers and microservices really coming in to help. Efficient operations. We will see a larger set of use cases, a larger complexity actually in the network. And the only way we can manage that is through automation. Also here, we see cloud native with the simplicity that that brings really helps us in deploying that. And then, of course, finally, performance and capacity. It's really with the speed that is needed, with the capacity that is needed, we cannot lose anything. We need to have the lowest possible overhead. And we will get that with cloud native and containers. So 5G is super important. And cloud native is really, really essential for network applications. And in Ericsson, we have realized that. So we have gone all in on cloud native. All our 5G network applications, network functions, are cloud native from start. And we do that across the complete portfolio. So not only the 5G network functions, but also into OSS, into BSS, into communication services. And we see this as a big transformation of how we develop code and how we develop our applications. So we created a number of design principles that we are applying to all our development. Of course, cloud native, you can only do that by running in containers. And of course, you need to be built on microservices architecture, otherwise you will not be able to realize the benefits with cloud native. On top of that, we put another five critical design principles in place. Agnosticity, we will need to run our network applications on any Kubernetes infrastructure. We cannot build telco unique. We cannot build special functions or require special functions. We know that our cloud native applications will be deployed in multiple different ways across both edge central telco clouds and even public clouds. So definitely, agnosticity is super important. Decomposed software, we need to be able to decompose. We need to decompose our softwares into microservices. To have stable interfaces, independent lifecycle management is also depending on the decomposition of the software. Application resiliency, we have a long tradition in telco to build 1 plus 1 to rely a lot on hardware resiliency, et cetera. That's not going to work in a cloud native world. We need to both strengthen how we build the applications around resiliency, also push down into the cloud infrastructure and really to rely on the cloud native principles that handle the resiliency. We talk about herding cattles instead of herding cats. Then state optimized design. Stateless design comes with cloud native. We need to separate state and business code. But we also need to handle the states different. Not all states are equal. Some are just updated maybe once a month. Others are updated every microsecond. So some of the states needs to be kept very close to business logic, while other states can be separated and handled in a longer way from the code. And then finally, orchestration and automation. I think we see also here a super important part to manage the complexity that we see coming in with the 5G applications and all those different use cases. So to really utilize and build out the orchestration to manage cloud native applications as well as the infrastructure. So these design principles we put in place and we drive them across our complete development. Then I'm now almost echoing Andrea here. So we see that if cloud native is really the essential for 5G, open source is really the enabler to get us there. And Ericsson is a strong proponent of open source. We are strongly engaged in a lot of different communities. So LF networking, of course, own up. To extend own up to manage open source, to manage cloud native, to manage Kubernetes, to be able to manage cloud native applications. That's a very important next step. We also see LF Edge and the Crino, of course, to we extend 5G into the edges. We extend the network applications into the edge to really manage and handle the low latency that is required. Or the specific enterprise use cases, et cetera. So of course, a Crino and LF Edge is an important part of creating an open ecosystem around that edge infrastructure. Cloud native computing foundation, of course, and Kubernetes and all the tool sets around Kubernetes. That's really, really important for us. Then we talked about automation orchestration. And we know that we cannot get there. We're not going to get the efficiency, the reduced OPEX, the lower manpower needed to run these systems without AI and automation. And then we see deep learning combined with own up. And the orchestration parts are very, very important. Also, Airships plays a role here from a lifecycle management. And we are aiming to see how we can get the lifecycle management of Airship and lifecycle management of CNCF coming together in a good way. So open source is definitely really, really important. And I can just echo Andrea to say that we are here because we believe in open source. We are engaging, of course, we believe in open source. And the momentum that creates the flexibility and the energy that creates into the software development and into our products. Now I talked a lot about the cloud native applications and the importance to look at that. But that's not enough. It's not enough to do these design principles and develop our applications to be cloud native, to be based on microservices, to run in containers. It's not enough. You need to take a holistic view and look at the complete infrastructure, the complete package. So of course, we need to run on any infrastructure, on bare metal, on edge, in central clouds, public clouds, to be able to run on any infrastructure. We need a CNCF-based platform. We need to develop our applications to be cloud native. And we need an orchestration and automation tool suite that can handle a container as a service infrastructure and cloud native network functions. So when you as an operator, or when you as an organization that are going to deploy cloud native applications, it's not enough that you say that, OK, I buy a cloud native application. You actually need to look at your complete infrastructure, at your complete stack, and say, do I have all the supports in all the different stages and all the different layers of this stack to be able to really support the efficiency, the flexibility, the upgrade speeds, et cetera? Otherwise, you will not succeed. You will not get the benefits out of cloud native if you don't take a look at your complete stack and take a look at exactly how you don't do it. But even that is not enough. We also need to look at the complete way of working and operations. We see that if you want to upgrade, if you build in the flexibility to do an upgrade of an individual microservices in a few seconds, then, of course, you cannot have an upgrade schedule of once a year. You lose the complete meaning of that flexibility of that time to market. So if you don't really look into how you can have a complete continuous integration, continuous deployment, delivery, staging, all the way between your vendor and yourself as an operator, and even close that loop back so you can bring data back from your installations to your vendor for to enable the vendor to really learn what's going on outside in the deployments in the real operations. If you don't do that, if you don't upgrade your process to support a more frequent upgrade, then you will lose the benefits of Cloud Native. We see that Ericsson sees that when we engage with operators and do, so we have examples where we basically deploy production software into production systems every third week. And we see the benefits. We're reducing the upgrade times from a number of many, several days into maybe half a day. And we also see that we can create a DevOps schedule between us and our customers so that we have a closed loop, not only on the data we bring back, but also on functionality. And we can engage on a completely different level. So I think this is a call to say that you cannot only look at your stack. You also need to look at your way of working and your operations. And you need to rethink, basically, your organization, your operations, your processes, your way of working to really get the benefits out of Cloud Native. Right, so lots of slides, a lot of words. So is there anything real behind? And yes, there is. As I said, Ericsson is going full in on developing our 5G nodes, Cloud Native. I also said that we are rolling it out this year. And that means that it's ready, it's in our labs, it's in our customer labs, in our customer networks. I'm there, so I'm happy to invite one of my experts, Thomas Zeros, who's an expert in Cloud Native architecture and Cloud Native implementations. And he's going to show you a demo here of how we do in-service upgrade of our MME node in container orchestrated environment. Thank you, Anders. So just before you thought you were going to see a demonstration, you're going to see some slides first. Let me introduce you to our humble dual-mode 5G Cloud Core. Actually, this should have been called the dual-mode 5G Cloud Native Core, because everything that you see on the screen is Cloud Native fully to full extent. And as you see, these are the network functions that make up the dual-mode 5G Cloud Core. It's dual-mode because it does 4G and 5G. And as you see, the light green boxes are the network functions defined for evolved packet core, doing the 4G functionality. And the dark blue boxes do the 5G core network functions specified by 3GPP. So what we are going to show you today is how we take MME, which stands for Mobility Management Entity, within this dual-mode core, which is fully Cloud Native, runs on Kubernetes, and take the business logic part of this network function and upgrade it fully using Kubernetes facilities. So this MME, yes. So this MME instance that you're going to see here, basically, we only upgrade the business logic. And it runs on three microservices, three instances of the same pod. It roughly takes up around 0.15 vCPUs. So it's very lightweight. And it will handle around 7,500 simultaneously attached users. So I think in itself, it's a great example of how small can you scale with Cloud Native, but at the same time, how powerful can you be. Then this application is orchestrated fully by Kubernetes. And we're going to ask Kubernetes to do the upgrade for us and then watch the results and, of course, check the KPIs if everything is going right. So I'd like to ask my kind friends to roll the demonstration. And I'm going to talk you through it. On the video, on the right-hand side, you basically see the standard Kubernetes dashboard. And on the left-hand side, you see our little user interface that shows the traffic that is being handled by the MME. And as you see, there are three instances of the same pod with the version one of the software already running on the system. So we start the upgrade by actually associating these pods with a new image. We change the image. And once that is done and we refresh the dashboard, we see that the version has changed to version two. None of the software currently running is using this image. For it to be run, we need to ask Kubernetes to upgrade the pods, which are basically done by restarting them one by one. And since the business logic is fully stateless, that we can do without any end user impact. So as you see, we initiated the upgrade for the first pod. Actually, it's going to be CP2 control plane 2, pod that is going to be upgraded. And you will see on the user interface, when it turns green, it will already be running the new software. There you go. Now, this is typically the point where we stop for a second, check the KPIs, verify that the software is running as it intended to. And once we have done all the manual steps or once all the automated tests have been run, which is more likely the case, then we can ask Kubernetes to proceed for the rest of the pods and restart them sequentially. Actually, since this is a fully stateless business logic, we could just restart everything at the same time. But that would mean that would be some traffic outage, which we don't want. But obviously, if we have more than three pod instances, let's say if we have 50, then we could do the upgrade in greater steps if we wanted. So the last phase of the upgrade is when we ask the system to actually replace all the pods and restart them with the new software that has been associated with this pod. And once that is completed, the whole system, the whole MMA business logic is now will be upgraded to the new software level and will continue handling traffic forever. So that basically concludes our demonstration. As you see, the pods are running and the uptime is increasing as we go along. I'd like to get back to one issue first that I think Andes mentioned before. And it's the three things that we need to have to get the two cloud native benefits. It's the way of working, it's the application, and it's the cloud infrastructure. And there is one area which sort of spans across all of these. And an area where we see that we need to address the current state of things and we need to call your help in doing that. And that is networking. As of today, the networking mechanism, protocols, solutions that we use in telco networks are typically ones which we started using when we had monolithic nodes running on dedicated hardware. And since then, we have created cloud, we have evolved the cloud, we have created cloud native applications, but we are still using the same protocols, the same mechanisms, and the same solutions. So in many cases, we use layer 2 connectivity for things which we're using standard Kubernetes networking in layer 3. So this is a little bit for a call for action for vendors and operators and everyone who is working with open source, because we see open source as the best tool to push through this change, to look through these networking use cases and see which kind of traffic, which sort of old protocols do we need to evolve? Do we need to get rid of? How do we move traffic towards layer 3 plus kind of environments and solutions in the cloud? And of course, there will be things which will need extreme packet throughput and which might need layer 2 connectivity. There we need to see how we improve the ecosystem and how we work together with, for example, hardware acceleration technologies like SmartNICS and make the cloud better so it can better execute our mobile broadband, our IoT use cases, and everything that 5G has to bring. So with that, I ask Anders to conclude our keynote speech. Thank you very much, Thomas, great demo. So basically, my time is running out. So I'm going to summarize this. 5G is happening now. It's not something next year. It's not something in two years. It's happening now. Cloud native is essential to deliver 5G. And finally, open source is super important tool to enable cloud native implementation. Let's work together to iron out the last problems that we see. I think the call for action that Thomas had around networking is something that we work with, something that we help the community work with. And I also would like to get help back from the community to really sort this out. Come with us, visit us in our booth. We'll have a lot more use cases, a lot more demos around cloud native, around our own app-based OSS, et cetera. So please come and visit us. Thank you very much.