 Hi folks, we'll get started in just a minute, we'll allow a little bit more time for people to join. Okay, hello everyone, welcome to our, the latest LF networking webinar. Today we're going to be speaking with Deutsche telecom, they're going to be talking about how Deutsche telecom deploys on app in oran town. Before we do introductions just a couple of housekeeping items attendees will be muted throughout the presentation. However, if you have a question. There is a little Q&A dialogue box to the right on the bottom of your screen. Feel free to type a question in that box at any time. We will reserve some time after the presentation to answer some questions live. We will also be typing responses in real time as well. A recording of this webinar and the slides will be available in the coming days so if you've registered for the event, then you will get an email shortly afterwards directing you to the content where it's accessible. All right, without further ado, let's click to the next slide and I'll introduce our panelists and we can get started. So, all from Deutsche telecom, we've got Andreas Geisler, Mark Fiedler and Sebastian Zeschlein. They're going to be speaking to us today about own app in oran town. I will go ahead and hand it over to Sebastian. So hello everyone. Very warm welcome also from from my side here from Germany from Deutsche telecom. Thank you for your interest and your participation in our webinar. And as Jill said today we'd like to introduce a bit our journey, how we use own up in DT and what we do with it in the context of access disaggregation and how we build a service management and orchestration solution in the oran context. But before we start, I'd like to mention two things to you. So fantastic news, the latest release of own up has been launched today on up Istanbul. So, really great success to the community and I'd like to thank also everybody who has contributed to that once again. And Andreas will also then talk a bit later on how we plan to use Istanbul as well. And the second the second thing I'd like to mention is that after the webinar we will have a DT user story page available on the Linux Foundation networking site, where you can find more text documents about our user story, and also a longer version of our case study, which will be soon on its way. And with that, I'd like to come to my first slide here. I'd like to give you a bit of context where this project. DT own up or team up as we call it is embedded so it's embedded in a program, which is larger called network differentiation so how does that Deutsche telecom plan to build the networks of the future and you can see on the right hand side that we have colleagues dealing with this aggregation of networks in order to drive flexibility and scalability, and also to give a new push to the ecosystem. We have colleagues working on the cloudification of things on software defined networks and of course, also, we'd like to leverage open APIs in the future a lot. But this group you are. We are belonging to has done. We think one of the key obligations and that would be to master all these future or all these complexity coming and resulting from these things like this aggregation and cloudification you see, as you can imagine. Integrating a black box solution coming from one vendor is pretty easy task as compared to a disaggregated network where you would have several network functions to to integrate and also, of course, I'd like to mention the speed of change which is quite different. As we compare our networks from the past with the networks of the future. And so, you can read it. Our belief is mastering the network automation is really key in order to enable the benefits coming from this network differentiate differentiation from the software defined cloudified disaggregated networks. We asked when we started this journey into into open source we we also asked the question what would be the best production model for a network automation system and you can believe me, we have we have tried out everything you can you can see in the cloud. We have done an in house development. We, of course, are talking to the vendors, the good old RF IR Q story, we are looking into partnerships with hyperscalers we think of model driven software and and one option of course is the open source. And of course, all of these have in common that in case in any case we want to be able to shape the services we provide to our customers ourselves because we think that's a strategic asset of a future operator of a really software defined telco. And, and therefore I'm glad to have Mark and Andreas today with me will guide us and give us a bit more information on how we leverage open source in the context of all run. So the open radio access network. Over to you Mark. Thank you Sebastian. Welcome also from my side. My name is Mark feet lies introduced in the beginning. And I'm the one who is providing some insights today about our let's say challenges in the radio access network area to provide a bit and an outlook for the for the for the next slides also then provide giving you some insights about what we are doing in this famous Oran town and how the SMO the service management and orchestration framework will hopefully help us to push in that area of of Iran, but first things first. Basically, we as Deutsche telecom see a couple of challenges in the existing radio access network. And I hope I guess it's not just for Deutsche telecom it's about the whole ecosystem and for the operator that we see that we need to improve and to need to challenge our entire ecosystem in the way that we want to improve. Let's say the number of vendors where we can integrate and choose from the market. I think that is a general challenge we are facing in the industry. Besides the ecosystem topic radio access network in entirely as a really costly technology, which compared to the flexibility and innovation power we have today, potentially has not the right amount of flexibility in that area. Furthermore, we see as well with the modernization of the network. There's a lot of cumbersome challenges in that area by modernize those technology and having done a really costly run swap at the end, which is something we need to improve entirely. And last but not least, as I said in the beginning, compared to the flexibility and the innovation power we need to improve dramatically. Please go to the next slide to improve or basically to start challenging this whole thing. We started a program in DT which is called the access disaggregation. And this really compared and jointly an activity we're doing in the Iran area. What we want to introduce here as well today is that we have three sweet spots where we want to focus in this entire disaggregation story where we see one of the or mainly the biggest challenges in that area. The first one is to disaggregate the functions in that area of to pick and choose a specific solutions. In this example here to introduce and integrate radio units from different vendors compared to what we had in the past on the BBU area. That's the first thing. The second thing is the general aspect to decoupling software and hardware functions. You know in the past we had this famous black box solutions where we had introduced an entire technology stack from a vendor starting from the hardware up to the software and also to the management system on top. And last but not least and that's exactly the topic for today that we want to introduce an independent management framework where we see as such a telecom as well one of the biggest challenges to push this and having the flexibility and freedom to integrate different network functions from different vendors and having independent management framework available. Exactly. And from an integration point of view and that is, I guess, one of the interesting stories and that is what we give some insights here today is how what is required to leverage the benefits from that access disaggregation story and what we see is here that the operating model needs to change. And as well for my integration responsibility. With the integration of this software stacks. We see also a shift of the responsibility that we had in the past to quickly on the vendor side, which is then going more in the direction of the operator side. That's nothing what we can do overnight and something we need to prepare ourselves carefully. With the layering of technologies and that's exactly the beautiness of this. Let's say this aggregation story coming from the independent cloud technology and platform technology we want to use. Deploying cloud native and physical network functions on it, and want to manage them independently that's exactly the approach where we want to open the ecosystem, introduce new vendors in that market to having the flexibility to have a new operating model approach available. Exactly that was the motivation to say okay we want to prove exactly those technologies and those architecture. And that is why Deutsche Telecom has selected a city in Germany to prove the technology start deploying those technology and see how this technology provides those benefits we have seen or this expected benefits we have seen on the slide before. And starting leveraging this operating model and start learning from what is implemented and to push further the ecosystem, work with the ecosystem, but also with the open source communities to get new features and get the robustness and stability of what we have today in the network. So then it's again my turn I guess. So what was important, what were the strategic guidelines we were laying out when we were starting to design our DT service management and orchestration solution. So, very important is open standards. So the O-RUN and 3GPP, they define of course the standards which we in the end need to implement and need to work with. For sure we are also present in those organizations and pushing forward the standards which we in the end in practice then also implement. Open interface and models that's of course the second cornerstone we've been laying out. So the data models and interfaces in order to manage the upcoming complexity should be of course in the end also what we want to have. And yeah, of course, a state of the art technology. So it's also about when we manage the future network we want to have a future proof architecture for the network and service management functions, which we in our case, found by using components from the open network automation platform as Andreas will also show a bit later. And you can read the goal which we which we want to achieve in the end. So we want to be independent and yet want to have that integrative approach. When we think of managing the network of the future be it cloudified, but of course also be it disaggregated as in the case of O-RUN. Thank you. Now coming back a bit more to what is behind the SMO concept and why we have decided to use ONAP for this approach to develop a solution for the SMO. I'm not sure how many of you are deeply involved in the discussions about the pros and cons, the benefits and how to implement such SMO concept as it written here in the headline to this technology stack of radio access networks. It's a really complex topic and we know that this management functions were typically placed on the vendor side and that is something which were delivered entirely with the technology stack and that was basically well proven and integrated. But exactly as I introduced at the beginning we as an operator want to pick and choose mainly which vendor, which technology solutions we want to layer, we want to stick to an entire network to be independent. And for that as I said we also want to need to have an independent management framework which allows us also to modernize our OSS landscape tremendously. Because simply we saw that the technology is costly and mostly also the OSS tools are basically not the ones which are built on a green field approach, let's say like that. So that means there's a couple of improvement items visible. But coming back to the SMO concept, the service management and orchestration platform is aimed to cover the entire life cycle of the cloud native functions in the sense of access this aggregation we want to cover the mainly the CUNDU functionality so central unit distributed units and as well the PNF functions around the radio units, which will be integrated and connected to the controllers and the architecture. So even starting point we as Deutsche Telekom has mainly focused in the beginning of this famous F caps functionality so fault config accounting performance and security capabilities to prove the operational on the one hand stability, but also from a functional point of view, if we, or is Deutsche Telekom able to manage with this SMO MVP, the technology stack in the old round town so that was mainly the target we had. And then we focused basically on this F cap functionalities, but I want to introduce a bit more and more detail from a functional point of view what we basically did or what what our ambition level is. And for sure we need to implement and integrate a specific service design for this 4G and 5G services we want to roll out for customers. With that, we want to have an entire automated day zero and day one configuration, also known as the instantiation process of this physical and virtual devices or cloud native devices, and then providing an initial configuration for those to be able to operate and integrate those network functions in production state to be able to, to understand the heels and the, the heels status let's say in this way, we focused as well on the integration and calculation of performance counters. We use mainly this through GPP term to calculate the performance counter here in this way, but also using the best format to be able to receive all this metrics in an independent manner and integrated independent state between the network functions and the management framework. Automation is a clear target we have for sure. And one of the first integration is also that we do work that we work on specific automation cases for radio access network to provide quality enhancement and stability from an SMO point of view it's not just the blurry and simple. Let's say the zero day one configuration of those it's also the life cycle and the optimization of the life cycle of those network functions slide. I want to kindly hand over to Andreas. Yeah, welcome also from my side. We have another view on the Oran SMO architecture. So we have already, we have some, of course, defined interfaces between the SMO function and the network and the components itself. So you see where there is the 01 and 02 interface and as well the open front hole interface towards the radio units. We're trying to focus as already Mark said on specific, let's say functions here not covering all of them at the moment. But what we want to what I want to point out here that we also try to cover different deployment scenarios, for example, so between radio and aggregation sites so do you deployments on different sites and are and see you deployments. So that is also what we try to achieve and try to show here. We will, as Mark already said, instantiate the service or the cloud native functions via the Kubernetes interfaces women interfaces through the 02 interface and configure them via the 02 and open front hole interface from the SMO site. And on the other hand, receive the data from the elements, then via the also one best interface or less in a controller interface. Can you go to the next slide. Next slide is showing basically the architecture of the team up platform. The team up platform is targeted, or the target for that is to be a platform which can be used not only for this use case, but it should be also be a platform used for other future use cases. So the first use case as we see it here is of course then the orange case. So then we have to do some adaptions according. The SMO here as you see and with the blue squares you see this is these are the components we take from the own up community for the from the own up platform. And currently, we are using the Honolulu release and what Sebastian already mentioned today, or let's say at the end of the week, we have now the new release, so the Istanbul release out and we are now also planning in the next weeks or coming weeks then also to upgrade then this platform to the next release to be on the on the latest versions. We try to be, let's say use the components as they are in and try to let's say feedback as a let's say from the concept point we are trying to involve be involved in the this open source community of course and we are already. We are giving them any, let's say fixes and enhancements try to give them back to the community that's our, our basic focus here. And so the additional components will have to be developed for that are here marked with the magenta color so as Mark already mentioned so we will have an old portal for that. So we will have enhanced in, let's say managed as also fault and performance management functionality which is your name DCI E plus for example where we have a long term storage for events for alarms and the visualization as well we integrate and as well to the portal. So on the one side, we are using the SDN C and CDS components for the configuration so using the old to kind of old to one interface sorry, or one interface towards the net elements for the configuration updates. We are using the SO and multi cloud adapter. Towards the VIM, so the Kubernetes interfaces for the instantiation and the life cycle management of the cloud native functions and receiving basically alarms. By the desk collector and as an addition we also try to do maybe a Kafka to Kafka integration. If it's useful for the best integration here. There's a little slight differences as well in the deployment of the own up components and Tina components we doing a little bit of a different approach using also open source tools like the Argo. We, we are using of course our own repositories from the Deutsche Telecom and to deploy the software in our clouds infrastructure. So basically, this is how we use it and of course it will be also evolve over the time so you see we will, we have currently something like a config management so we receive data from the DT the Deutsche Telecom run planning. Components we have to, let's say use this data when setting up the the run elements and configuring them. Currently we are using an own kind of self made config management what we're, let's say check for example to use the new CPS component of all of own up. And most likely there will be other components to be added in the future, like all F or other ones, which could be useful for the functionality of the SMO. Yeah, so this is basically our overview of what we wanted to show you here. And yeah, the next slide would be then the sum up slide from Sebastian. Thanks Andreas and yeah, the SMO part is really our first example. Maybe Andreas is very modest before we started our journey with the disaggregated run piece we were also in the laboratory, we were running several tests with other technologies reaching from the core functionality to the transport network, etc. So we were trying different contexts already, as it should be like when you're talking of a platform so the SMO piece is really then the one we got the most serious with taking it into into pilot production. And yeah, to sum it up a bit. So this is already our last slide and I see we are great in time because we are planning half an hour presentation and then lots of time for questions for you so please feel free to enter them already in the chat to sum it up a bit. As you can see, the owner platform can be used in several different network domains and contexts. So, as I said, we have trialed it out in several with several network technology and were successful in all the proof of concepts and lab deployments with with it. Then you definitely see how the platform has matured over the releases. Of course, you can you can argue left and right. It needs to be hardened still but we are really happy to see how the platform has evolved how it got more features over the releases what has been added. And really great success as I mentioned before, for the for the open source community for the own community. And last but not least, we all need to earn money and open source definitely from our perspective is also means to lower the implementation efforts. As I was mentioning before, if everyone would do it on their own and do some some in house deployment, then definitely that would be not the optimal price point you were hitting. And therefore, the goal is clear to to get on some community based approach here in order also to to lower the the total cost of ownership of such a solution. What we've learned. So, as I mentioned before, in that in those for these future networks and you can hear it probably from everybody around the globe in the industry mastering the automation is really key, because this is actually where you create the network experience for your customers. And as I said, the complexity is definitely rising with cloud native virtualized with software defined and disaggregated networks. And the point where you have to bring it together, no matter which solution you're in the end rely on is the automation. And definitely for DT I can say we want to differentiate from the competition by having that automation layer under our control. Then of course, not sure from which business you come from but still for DT it's relevant. We need to combine the network skills with the it skills in order to manage software defined networks reads pretty easy. Almost a no brainer, but we were really successful in bringing people from both departments together in order to build a proper network automation you need to have the tools skills, but you also need to have the process skills and the network technology skills. It's really a rare that we would find somebody who has skills and is an expert in radio access network technology and at the same time knows everything about software and it and has both skills so bring them all together put them in one team and we've been really successful in that. And then, if you are ramping up such innovative technology. Then, you know, you will hit several problems challenges and you're definitely in a world where not everything is clear. And how do you tackle that challenge best. And we would recommend go into agile development mode. If you want to to really leverage open source technology and build innovative solution so we are leveraging in our case the safe framework in case you know it skate agile framework. And we would really recommend because of the nature of a the radio access network is not mature and be the management solution also is not, you know, something which is on the market for like a decade or something. So, if you want to develop, then go agile. And of course, we are not doing it alone. So, it reads like partnerships are very, very helpful and DT is definitely not doing it alone but with the help of partners. And our wish list we are at least close coming closer to Christmas or time of wishes. Of course we would always wish wish for a richer richer ecosystem, and we were putting more and more developers and contribute also to the community. So really, really glad to see that. And, but of course, if if more people would contribute and jump on that open source train. It becomes more efficient for everybody so that's the belief we have means also you know ecosystem means also we wish for you know companies startups who are making use of open source in order to help the bigger companies to come to better solutions. Plug and play integration of network functions into the platform. Still, I mean, in my career looking back to what we did when the automation was still called OSS. In other words, you know everything of take every kind of technology behaves a bit different and it's really always a pain to integrate between vendors between technology. So, a bit more plug and play integration really would be helpful in order to lower again in the end the cost and also to lower the time to market. So we have to put it down here. Truly cloud native network functions is really something we would wish for because then again the integration and also the management of these network functions becomes a lot easier and the team really did take some network functions already to the lab and tried to manage them and in the end, we were still seeing okay there is there's also on the network function side. Still a journey and network functions still need to evolve in order to become really really cloud native. I think we were pointing on that one. Really important is that you define in a software defined network, a relevant part of the customer experience with that automation layer and this is really strategic. Where you want to have that under under your control. One way or the other, you can do it of course also with the help of partners and vendors and commercial solutions, but this is really what we believe where in the future. The differentiation is being made, and that would be just a plea for the importance of the automation layer in general. With that, I'd like to close the presentation I really hope you have enjoyed it and thanks again for your interest, but I would now be open for for for questions. And we would use the rest of the hour for your questions back to you Jill. Great, thank you everyone. Yes, we do have have a handful of questions here in the window so we'll just start working through those. Somebody is asking about integration space related to slide seven towards the beginning of the presentation. Slide seven was showing DT needs to do more integration compared to what was required previously, what DevOps environments is DT planning to leverage here is DT able to execute that whole integration by itself. That's, I really like this. This question. Thanks for that. Basically, yeah, sure. It's, it's a huge journey and a challenge. I think we have a clear target to become a software defined telco and to reach that I think we, we need to prepare our organization for such a big move entirely. That's not just in the area of access disaggregation or providing an independent management framework. And that's exactly about the mindset of what DevOps mean and how this change from from an responsibility point of view exactly and that is about the question. I would say we as Deutsche Telecom, we are working exactly on this journey on this challenge to be able to cover those efforts of our own but as Sebastian introduced and shown also for sure having an ecosystem with partners to cover that. Great, thank you. Next question, the own app based SMO platform does not show the non RT, Rick, or a one interface to near RT, Rick, could you please comment. Also good question, potentially I would take that. As you know, we are also active in the in the orange alliance. And we are evaluating a lot of that. But one of the key targets we had in in or on town or basically in the development of such an SMO framework was to work on this F caps functionalities which were not on this real time aspects and I fully agree that one of the biggest challenges and also improvement parts in Iran is to introduce this, this Rick story independent if it's this non real time Rick or new real time Rick. We are currently working in the labs on introducing specific things on that that is not publicly, and it's also not currently introduced in old town. But that's up to the discussions we had in the communities entirely. Okay. Thank you for that moving along. Rania is asking, what is the total footprint of the deployed orchestrator in terms of the CPU and storage. Well, I think we are still. We are still, let's say, verifying when it comes then into let's say the use cases, what will be, let's say our complete footprint here I can say that we have, as we already answered part of the question so we are using virtual machines at the moment for the deployment on an open stack and then having their cluster setup at the moment we are using, for example, 12, the sort of the Kubernetes cluster will have will will be based on on on 12 worker nodes at the moment it will be quite, quite big especially because of course we do have. Let's say also long term storages inside so elastic search and so on so of our own components. Currently, I think I cannot see tell you exactly so what is the what is the, let's say, a number of CPUs and memory which we are using and especially than the, let's say the data or the volumes which we which we need to do. I think we will sum this up at some point and I think make this maybe or will will will provide this maybe later so at least from a, let's say, theoretical or let's say practical one when we when we come or see then the, the working version basically with getting more and more data so that's something which we are still investigating on. Great. Moving along Carlos is asking is suggesting he says if I can summarize what you're doing your forking own app to create a self made implementation of an SMO will you be contributing that back to the community, build it into a different product or keeping it internal. Currently, we are, we are not really forking own up, so we are using own up, basically with the same kind, for example, health charts which also the official own up release is providing so m is providing. Of course, we are trying to be more and more engaged in the community I mean we have already a couple of people which are contributing to the community. We have as ptls as developers and and also including partners of us which we are paying for that they are contributing to a new features additional features and we our target is that our teams will get more and more involved in the community and we are streaming then the work which we have done back to the community definitely so this is one of our targets in using open source software that we give back of course then let's say self made implementations back also to the community. Go ahead, Mark. I just wanted to add because I like this question in the way that I would really like also to to underline here. It's definitely not to just fork the code and build a product out of it. It's really to also enlarge the community help the community to grow in that area and to show how own up can be used as an open source approach to implement several use cases and SMO is one of the use cases. On up can can implement or be able to implement so definitely we want to encourage more in the community as Andrea said and it's one of the beautiness of the owner community to have the freedom to implement such solutions. Yeah and and I wanted also to add thanks Mark for for jumping. We are doing it also for our own benefit so not only for the benefit of the community but upstream first really helps later to keep your solution clean integration wise because if you would keep a fork alive. Then we know it gets expensive in the end and really you put and waste a lot of effort that's why why we follow really a strict upstream first policy. Yeah, great thank you for that clarification there. Next question what what was the effort to develop and set up the SMO and what was the effort to develop and set up the use case. That was a good question. Yeah in general I think it's an outcome of a long journey that was mainly what Andreas introduced between the lines. So we are I think since Amsterdam in the community. So, and honestly we were also one of the operators which were passive over some time and and assessed the benefits also need to push a lot of things in the company that was what Sebastian has shown at the beginning. And we did a lot in the back, we did a lot with the development people a lot with our partners and then pushing the ecosystem to come to the stage to be able to run this MVP in a pre production site and there's a more as a as a good starting point to also having a growing area of features and functions and and for sure we are not at the end right so we are in the beginning. There is also a good challenge to work closely with with our partners and vendors to implement such an SMO so I cannot tell you the concrete numbers of the development and the setup of this SMO. But the efforts were the long strategy cycle and the journey, getting the right people getting the right structure to work on such technology stack which is something which needs to prepared and rolled out over time. Great thank you. The next question. How do you validate the integrated solution is it a proprietary lab or shared open source use case based testing infrastructure. And potentially I will take that as well. I saw also a generic question in the beginning about, can you participate in or on town. Good question and basically or on town is mainly and that is what how we call it as the telecom is is a city, as I said in the beginning is a city in Germany where we rolled out an overlay network. Based on your own technology. So that's something we want to run in or we run in production and provide the service to the customer. So that's nothing which is open in in sense of other, let's say partners other vendors or someone who's interested to join. But a good message for that is that that we have worked along the, the one lines to, yeah, open and or having the ability to have an open lab. And that is exactly potentially you have seen this this message. And this information which was shared for some weeks that we jointly have opened this why 14 y lab. So I 14 y lab. You can Google for that. It's a lab in Berlin, which is exactly for this purpose. And where we with other partners. And consortium have have worked on such a lab to verify exactly those solutions to have an open openness in the industry to collaborate on those technology. Yes, and and own up is of course a part of that open lab. I 14 y lab. Great. Next question from Eric. How many X and F EGC you do you do you deploy with TNAP for this orant town project. Yeah, mainly, Eric, good question. Thanks for that. The solution or basically what we deployed is the 4G and 5G service. And this is along the amount of sites we deploy in the city so currently we are deploying several sites and along the sites and depending on the deployment concept what Andreas has shown. So we are running CUDU and our use. I would not stick that specifically to one side to say okay we are for example deploying 15 sites and then having the amount of network functions running. It's also dependent on which deployment mode is selected for the specific site. So, and how the scaling of this network function is implemented so that's a specific part of the solution we have there. It's exactly about the deployment of in radio units or specific radio units and CUDU deployments. Thanks for that. Moving along. Could you please comment on how where an application network management analysis is on board it and hosted in the TNAP architecture. I think if you go for a kind of, let's say, control loop implementation, something like that. I think we will have at the moment two ways of doing that. I mean, on one hand, we will have we will try to or focus on trying to use the existing control loop functions and analytics functions of the DCIE component and but on the other hand, as we have also this kind of long term storage and spark components inside so runtime and also long term analytics can be done on the on our DCIE plus system but this would be then the second option where we could add some analytics on to let's say have further analysis and and and let's say yeah application analysis or network analysis on that. And we actually did have a have a follow up question about TNAP folks are wondering what version of own app that was based on at at the moment as I said it we are based on Honolulu maintenance release version so this is then the latest which was, let's say, announced one week before so and now, as I said so we will have a look at how to plan how to and when to update and to the next release so the Istanbul release because we are also, we will also require maybe some functions which are existing from in the from the Istanbul release and based on that of course we will have to check when we do the do the upgrade basically to the Istanbul release. Great. Thank you. Moving along do you have a lot of customizations custom workflows and so we sorry we are our focus is to use Marco workflows. So we do not want to have specific workflows currently for that. So we are trying to focus completely on Marco workflows and the usage of CDS actually. That means everything is should be embedded in the in the model itself. So we have to do the CBA packages deployed with the models for the different components, and this, and we are trying to use then the Marco workflow I think we might have some small additions in the in the Marco workflow but generally we don't use specific workflows. This next question is a little bit long. You mentioned that recently you've managed to perform on app upgrade to the latest upstream version. As of now vanilla on app does not support at its core seamless upgrades did you manage to develop your own workflow tools to upgrade on app or just by upgrading you mean playing reinstall from scratch plus data migration from previous installs. Yeah, so that's a good question so we have we are not in the situation at the moment that we needed to let's say have real data migrations I know that we have problems current or you know enough there are still problems or challenges on that on that in the perspective. We will focus on that so currently at let's say we have we can do the, of course we were trying to do a base a new installation, but we also trying as I said to use algo CD for upgrading the services and the pots and so on. Which works quite quite nicely but of course it does not mean that we have we did that this supports then data migrations and something like that. And I think that's something we'll have to focus on in the in the coming sprints and we will also then support or try to support whenever we can also the community to let's say give our let's say implementations forever or whatever let's say data migration exporting importing stuff that we will try to give back to that to the community or let's say discuss here and the om team without about that and support the om team on that but it's right. We have not at the moment we are not in the situation that we have let's say an installation which has a big amount of data which has to be then really migrated from one release to the other. That's that's right at the moment. Great questions. As SML becomes mission critical how do you deal with SLAs OLA's for open source based solutions. Good question. Absolutely right. I like that as well. Yeah basically with that we are back to the DevOps concept so we we call it for the moment or let's call it for the moment DevOps concepts for sure behind that is a support structure which is required to run such an SML platform as a mission critical component absolutely right. So I would would phrase the answer in a way that we are working on exactly on an approach to the structure the L1 L2 and L3 support. We have existing partners in the industry which provide exactly, for example, level three support for specific own up components which is also a beauty thing and we are encourage others to help and push in that sense, because that is simply also like the journey of access this aggregation, enhance the ecosystem enhance the entire industry a bit or motivate the industry to provide such services for specific things to having the ability to to select specific vendors, specific support structures but the aim is to cover mostly the L1 and L2 support in DT and if required having for specific mission critical components in own up level three support externally but that depends on the component as I said. Okay we are just about at time. Jill, I think your audio might have cut out. Seems to be. Okay as Jill was mentioning we are running out of time here. So I think we should bring things to a close want to thank all of our panelists here for this great presentation. The L1 register for the webinar will be sent the materials via email by tomorrow. And for all the questions that we didn't get to today we will wrap them up and get them to our panelists and get them answered for you. So thanks again for your attendance and stay tuned for more great LFN webinars. Thank you all.