 So, yes, as mentioned, I'm pleased to be here and share with you some of our learnings that we have taken from our Oran journey, Oran solution development. I would like to give you a broad overview about this journey and also context. And then also focus a little bit on what role some of the open source communities play in our development and in particular to give you some updates, how we use OnUp and why it is important for us that this kind of community effort is really taking place and is successful. So, let me start a little bit broader and here to go into the kind of key drivers for us why we go into softwareization, into disaggregation and lately also the role of some of the solutions coming out of the open source communities, but really let me start where we come from. So Deutsche Telekom, we are a brownfield operator that is having really large install base of radio access networks in other markets. We have also a complex spectrum holding involving large footprint of different spectrum components. We are driven by performance, network quality and efficiency. If you look at that from this perspective, our solutions that we deploy need to support not only 4G and 5G, but also 2G for example. And in order to get a solution, what we see today is really a handful of vendors who can support that. So that's what we mean here by ecosystem challenge because the solutions that are deployed are tightly integrated monolithic solutions that are supporting all these capabilities. Also what is important to consider for radio is that it is largely distributed by topology basically. It involves a lot of aspects like regulation, getting access to the sites. It is requiring fiber to the sites. So what it goes to is that the deployment and cost related to it is substantial. And obviously it's the largest cost block in the mobile network TCO. And it also has low flexibility because of all these constraints. The other thing is that when you think about modernization of these deployments, it's really long lasting and costly exercise because of all the points I have already mentioned. And last but not least, when we look at this from an innovation perspective and primarily driven by the fact that these solutions are tightly integrated hardware software solutions. This is limiting innovation, innovation speed that we see. For example, in today's solution, so you need to go through the design of the algorithm and related baseband chip and that takes a lot of time. And that's what we mean by limited innovation flexibility. So this is what is driving us to look at different approaches, how we can design and build radio access networks. And now what we did on DTE side is because if you look at ORAN, this is a really broad term. In fact, DTE also co-founded ORAN Alliance, which is the initiative that is defining interface specification, it is defining architecture, and it is also also driving open source development of the run solution components. But in that large environment, if you will, for our initial steps, we have focused on three important components. So the first one is an adoption of the open front home that is allowing you to deploy multi-vendor radio access network from the perspective that radio unit comes from one vendor and the baseband or most of the RAN protocol processing is coming from the other vendor. So that's what we mean by RUBBU decoupling. So that's one key component that we are focusing on in that adoption. The second one is hardware software decoupling and bringing cloudification benefits into the RAN. So this is critical for our ecosystem at first as well, because if you look at new RAN vendors, they will not develop their own bare-metal solutions. So they are focusing on using Cots hardware. The second aspect of hardware software decoupling can be that also addressing the innovation challenge that I mentioned, because the coupling hardware and software development cycle is definitely allowing to use the different approaches in both domains and gain a foster innovation speed. And thirdly, maybe not in the initial steps to be the focus, but also cloudification in that space allows the resources sharing with potentially other use cases or other applications, especially on the edge of the network. So these are the key components that we focus on in the RAN desegregation. And now here a little bit what are kind of key learning components, if you will, that we have on our RAN journey. So the first one I want to mention is that we have started the so-called RAN town, which is an effort where we deployed really truly multi-vendor RAN based solution. It is currently in the friendly user prior phase, it's a limited deployment and it also adopted, and for the first time in Europe, massive MIMO capability was integrated, it also involves, and I will come back to this point in the next stages, it involves SMO approach and automation. So the DT has been investing into development of independent management framework as mentioned, so that's a component that we are focusing on. As a third point, in order to foster sustainable ecosystem and also help the new come as into that field, so that they can contribute into the solution, we have started an activity in Berlin called I-14 while up, so it's an effort where we are deploying a kind of reference or RAN based architecture that will allow component or subsystem solution providers to come in, integrate and do interoperability tests and with that also kind of help with the productization of the solution. The other thing that is very important is that also for us, in order to go on the journey, new skills need to be developed in terms of competencies and also capacities, and that is also related to another point that I listed here, it's a new operating model. So moving away from tightly integrated solutions into the disaggregated, of course, introduces a lot of complexity, but also it requires service providers like ourselves to take more responsibility. And in that context, we are really looking at into which tasks in this whole kind of value chain from designing requirements, bringing some components, integrating and finally deploying and operating which tasks, for example, in the system integration space, we should be taking and which are then the task for other players that are better positioned on the market to drive. And last but not least, the other key focus area for us at the moment is also vendor selection, so who will be the vendor for large scale, future large scale deployment. So moving now a little bit more in detail into this point of independent management framework, as mentioned, that one is for us a critical component because in that area, we believe that it is enabling the supplier flexibility because we are gaining a control point here that would allow easier replacement or evolution of the subcomponents. And of course, what is often highlighted and that's what we see also in our efforts is that disaggregation brings complexity and that complexity to really manage cloud native deployment, having a CNF based run functions requires a lot of automation for keeping efficiency. So in that space, SMO with its capabilities is playing a major role in the target picture and it then also requires integration into existing IT landscapes and also it will require a lot of transformation efforts if you will to be able to take the benefit out of this approach. What I mean by that is that if you look at today's operating models, it is really often using the sequential waterfall processes that is involving a lot of large upfront design and then you have organizations focused with expertise on the sequential steps like design, procurement, implementation, integration, etc. While now going into the DevOps software-driven network deployment, the design and operation requires a cross-functional approach which is optimized by by flow and this is one of the important aspects related to adoption of open and disaggregated solutions. In the last step here, what I wanted to share with the community here is that our approach for the SMO development and the SMO platform we call by the way TNAP like shown here. So that is based on on app and why did we choose that is that because it's an open architecture, it's a platform approach and basically important components are already pre-integrated and we do not need to care about individual sourcing and related complexities but at the same time it also enables a customization and for us it's also an effort where we are looking at feasibility of the approach to to use large open source code base so if we use like 99 percent of open source code so how we could take how we could take run use case into this and into this domain so that's what we have been focusing on and then clearly for us was also to look at if we can approve that we can manage the complexity associated with that especially in the in the in the operations use case what we did is in our development effort is treated to focusing on the zero day one use cases so especially the net design and runtime capabilities so how we can perform a site installation how we can create association of radio units to appropriate du and then how the configuration tasks can be can be realized with that solution and future focus in that in that area will be to to develop more day two day two related use cases so close to automation some of the non real time capabilities to enable to enable innovation and it is and as it is it is community the community efforts we are also planning to to contribute some of the development and we are driving and especially we are looking at the parcel a component which is the component that is interactive that is basically allowing users to interact with the automation capabilities etc so that's that's an area where we would also like to encourage the community to and to back up this effort and and and use it and also enhance it and then also also contribute contribute back so that's also our our encouragement here to that that we all to better strengthen the community engagement in this in this effort because that would also drive a future success so that's that's what i am prepared for today thank you so much for having me here and we think the great event thank you very much better i think your your insights into or and and obviously the integration with everything is is really good if you can stop sharing then you could probably go back into the definitely there you go okay so so so i think the the great thing here is i see that you're already sort of picking up the pieces and like like last year i remember uh or you know in couple of years you know both alex and and uh rosh and and and your team from you know cq teams from dojo telecom were thinking of of going out and and deploying and i think it's amazing to see just in one year you made so much progress across all your networks so congratulations and really appreciate your support there um and again i think uh there are no further questions so i'm just going to say thank you very much for the insights appreciate your help thank you so much again it was great to meet you here okay thank you