 Good morning folks. We'll just get started at one minute after the hour. Hello everybody and welcome to today's LFN webinar. Today's topic is what's new in Onap Frankfurt. Our host today is Amar Kapadia. He's the co-founder of Arner Networks and an Onap community member. Before we get started, just a couple of housekeeping items. All of our attendees will be muted during the presentation. However, we do have a Q&A dialogue box, so if you have any questions throughout the duration, please feel free to type your question in the Q&A window. We have dedicated some time following the presentation to address Q&A, so feel free to ask anything you'd like during the presentation. Additionally, our slides will be available tomorrow following the webinar. All of our attendees on the Zoom webinar will get the slides via email tomorrow. Alright, without further ado, I'm going to pass it over to Amar to discuss Onap. Thanks, Jill. Hi everyone. So today is a very exciting day. The Frankfurt release of Onap just came out today, so I'm very excited to share with you what's new in the release. What we are going to cover today are some quick facts about the Frankfurt release. For those who are new to Onap, we do have a few slides where we cover what Onap is and some high-level architecture points on Onap. We'll go through the highlights of the release itself and then look at what's next. So in terms of quick facts, Onap is the most comprehensive and secure release, the Frankfurt release is the most comprehensive and secure release to date. And I will explain what that means. It's comprehensive in terms of its stability and security, etc., in terms of its functionality and in terms of its support for various standards. So that's the next bullet. There's support for 5G with network slicing, so this release has comprehensive support for 5G. There's deep collaboration and harmonization with third-party standards organizations and open-source bodies such as ORAN, GSMA, Etsy, TMF, etc., TM Forum. And we'll talk about all of that. And finally there's support for Edge and cloud-native deeper Kubernetes integration. So we'll cover all, don't worry about if you don't fully understand what these mean, we'll cover them in a lot more detail. This shows the evolution of Onap. And Onap, the Amsterdam release came out in November of 2017. And just to have some fun underneath each release, it shows what the key point of the release was in the language of that city. So Amsterdam was more of an I am here type statement. And Beijing was when Onap started introducing use case blueprints to show users how to use Onap and what it's useful for. Casablanca was when standards collaboration started in earnest. Dublin in July of 19 was when commercial activity really picked up. El Alto in October of 2019 was a non-functional release in mostly at stability and security. And Frankfurt that's out in today is all about 5G. One of the main points that I think Frankfurt brings to the table is the strong commercial activity. And if you go back and look, the commercial activity keeps increasing across releases. This is based on self-reporting. So end users or CSPs and vendors slash academic institutions self-report what they have done for each of these Onap releases. And based on that, you can see that CSPs seven have stated that they're either in pre-production or in production. Additional seven have said they're in pilot or POC and five have said they're contributing. And on the vendor side, there are 10 vendors who have said they have products based on Onap. So these could be pure play so they could be Onap based products based purely on the open source. Or they may take components of Onap and create proprietary products. So both types are included in this number. SI professional services, seven, interop testing. These are usually network function vendors who are doing interop testing with Onap or other third party products. And there are 12 of those. And then seven additional vendors or academic institutions said they were contributing to Onap. So as you see, this is a phenomenal amount of commercial activity. Next, I'm going to give a little bit of an overview for those who are new to Onap and who want to learn a little bit about Onap. For those who are familiar with Onap and are waiting to see the highlights of the release, I do apologize. We'll just spend a few minutes, I promise. And then we'll go to the highlights itself. Onap, I'm not going to read this. You guys can read it. But Onap essentially provides three things. It provides orchestration, life cycle management and control loop automation of network services and other workloads. And it's applicable for software, network, IT and cloud providers and developers. So it has a wide appeal in terms of who it can help and a wide range of services and workloads that it can manage. Which CSPs are involved with Onap? Again, based on the self-reporting, these are the CSPs that have reported they're involved with Onap for the Frankfurt release. So again, you see this is a massive list and we also looked at how many of these have Onap in production slash pre-production, pilot slash POC and those that are simply contributing and sort of watching before they commit more. So I think it's a pretty impressive list. I'm now going to talk about Onap in the context of the Etsy framework. A lot of people are familiar with the Etsy framework. Etsy was the first one to come out with the Etsy NFE architecture, the famous Etsy NFE architecture. So we've modified it a little bit and then shown Onap in that context. So on the left hand side, you see the data path, commodity hardware, server storage switches. On top of that is virtualization software. It can be containers, virtual machines, virtual storage, overlay networking, and data plane acceleration. And on top of that you have workloads. So these could be network functions, VNF, CNFs. You can also have PNFs, but of course PNFs will bypass the virtualization software. You can have analytics, you can have, which could be EIML, and you can have edge applications, arbitrary, you could have AR, VR, drone control, etc. So that's all running on the data path. It is managed by the right hand side. So first you have the virtualized infrastructure manager, the VIM, which is typically open stack for virtual machines and Kubernetes for containers. And then you have SDN controllers to manage the overlay networking. And those are shown as replicated. So if you have, you know, 1000 locations, you'll have 1000 clouds, each with their own SDN controller. Above that in the dark blue is what you see the scope of Onap. So Onap is a centralized application. And the functionality it has is a service orchestrator that does the global orchestration. Underneath that are controllers of different sorts, and we'll look at them in the next slide. And then a very important functionality that Onap introduced sort of, I would say, innovated on and was the one of the first to have that was monitoring and control loop automation. What that means is all of the telemetry, so metrics, events, logs, alarms flow into Onap. The data is collected, it's analyzed, and based on that analysis and event triggers a policy, and the policy then triggers either the service orchestrator or one of the controllers to take action. So now you have corrective actions based on fault management, performance management being conducted without human beings. So that's a huge value add that Onap added. Above that you have the OSSBSS layer, e-services are simply self-service portals for end users through which they can order services or make changes. And then big data services that could be batch analytics to go through the networking analytics data after the fact. So if you want to see what SLAs were violated in a particular month, you can go through big data services. So that's Onap in the scope of the Etsy framework. This is the detailed Onap block diagram. I'm not going to go through it, but I'm just going to make some high points. On the left hand side, you see the design framework. So Onap has a clean delineation between design time activities and runtime activities. And that's not to create silos, but really the goal is to have independence. So individuals that are doing design can do it without having any dependency on ops people, and ops people can manage their networks again without depending on designers. So that's, it's a clean split. And on the left hand side in the design, you can do onboarding, you can do service design workflow. You can have controller design studio which creates templates for configuration and lifecycle management, DCA design studio for onboarding microservices and creating closed loops, control loops. So it's a fairly rich set of activities. It's all unified in one design palette, and it's been made easy to use when possible. So the goal is to see if we can do activities without requiring developers. On the right hand side, you have the runtime in that you will see some of the main blocks are so the service orchestrator underneath that there are four controllers. There's multi vim slash cloud that talks to open stack Kubernetes, Microsoft Azure, Starling X, and other clouds. You have SDN controller that can be used to do configuration and lifecycle management of L one L two and L three devices. And it can also third party controllers, SDN controllers underneath application controller is meant for layer four through seven configuration and lifecycle management and VFC is a full blown NFVO that Etsy compliant. So for controllers, and then you see the data collection analytics and events the DCA block that collects all the telemetry that I just mentioned, it analyzes it feeds it to the policy block that's shown above, and the policy framework then triggers an actor, an actor could be service orchestrator or one of the controllers. You also have available active and available inventory that's for inventory services and on top you have GUI and external APIs that go to northbound interfaces. And on the southbound side you have third party controllers, the VIM, which is the cloud layer and a few shared services on the right. And then finally one project that I should draw your attention to is the own app operations manager, which is used to install configure and manage own app itself because own app is a micro services based cloud native application. So somebody has to manage its life cycle and that's the project. So that's a super quick overview of own app. I mean we could literally spend hours on each block, but for those that are new, hopefully this gives you a flavor. Own app has a set of use case blueprint is these are blueprints that have been created by the community to show what types of things own app can do. So own app obviously can solve literally any use case you can think of, but to show something concrete the community has created a set of blueprints and the blueprints that exist today are 5G. There are two that are there for residential connectivity virtual CP and a broadband service for optical networking. We have to cross domain cross layer VPN and multi domain optical networking service. So CC VPN is for layer two and layer three connectivity and M dawns multi domain optical networking services for layer zero and one. And then finally we have voice over LTE. So with that we are concluding the overview on own app and jumping into the release. So why do we call it the most comprehensive collaborative own app release today. Well, there were 27 sub projects in this release 34 organizations participated 438 developers. There were 13.5,000 commits a little bit over that. The feature security and defects issue addressed where over 4,400. So you can see that no individual company can match this type of velocity. This type of a scope. First we are going to talk about the new blueprints. The first blueprint that had substantial enhancement was the 5G blueprint with Frankfurt we can confidently say that on app supports end to end 5G. So the first thing it supports is end to end 5G orchestration. And for that there were over 100 points model related points that were incorporated into own app. So the models are aligned with Etsy and 3GPP. Next PNFs are also supported so PNFs, VNFs, CNFs are all supported and PNFs can now be upgraded the software can be upgraded without requiring an external element management system. End to end network slicing this was a key feature that we were all waiting for with baited breaths. And in the next slide I'll talk about what own app does for network slicing self organizing network support son support. This has actually been there since pre prior releases, but there were just enhancements on the Frankfurt release and in son you can do things like assigning sell IDs to ran sites that come up and optimization for automated neighbor relations. There are improvements in data collection. So on app has the ability to collect fault management and performance management so on performance management both real time and non real time so real time comes through high velocity collector high velocity VES collector and bulk data or non real time performance data comes through a file collector. So these were all enhancements done specifically for 5G. Configuration management is fairly robust. You can use a variety of mechanisms yang, net com, rest com, rest to configure. There was a lot of work done with the Oran software community in terms of harmonizing with their activities in terms of all one and even interfaces. There's all one support is fairly in fairly good shape. Of course it's not. There's few things that still need to be done but it's in fairly robust shape and even interface. The first support is there in Frankfurt with more to come. We talked about the PNF upgrade and to really facilitate the activities of this use case blueprint. A number of simulators have been created because as you can imagine you don't want to do development with Rian ran sites or real PNFs. So there's a PNF simulator. There's a ran simulator and these are open source as well. So other folks can use them for their activities. 5G network slicing. So first of all, what is network slicing for those that are new. You take a pipe and then you carve it up into sub pipes, each with a different SLA. So in this case it's showing 5 slices. The first slice is optimized for low latency applications such as virtual reality demand low latency because if you spin your head and the scene doesn't get refreshed in like 15 milliseconds or so people are going to get dizzy. The next slice is optimized for high bandwidth. So if you're doing 360 video, then again the bandwidth requirements are just tremendous. Optimized for low power that could be for an industrial sensor where you want the sensor to live for 10 years without a battery change. Slice 4 is optimized for high reliability and low latency. And this is typically again a lot of industrial applications. Drones might be flying around in a factory. They might be flying around for precision agriculture. So those types of applications. And then you have slice 5 shown here which is optimized for SLA for IP enterprise services. So that's the concept of network slicing. Now what does own app do. So on app can be used to manage an end to end slice, which includes ran core and transport. There's no point in just having one of the domains on a slice because you really need the slice to persist end to end. So on app can be used to do that. On app includes a communication service management function, which is customer facing, which can be used to order a slice. It includes a network slice management function that sits south of the CSMF. So CSMF is the top layer functionality. NSMF is the next which is used to manage the slice decompose it into specific domains. And then there are adapters to what are called NSS MF network slice subnet management functions, which then manage the slicing activity per domain. So these three things are there CSMF. There's a GUI for CSMF and a workflow. NSMF again, there's a GUI and a workflow and NSS MF that is an adapter to an external NSS MF work is done on the GUI side to be able to design these services distribute them modeling and slice instant selection. So a ton of work went into 5G network slicing. If this is a topic of interest for you. I strongly sort of encourage you to check it out. Another new blueprint that was created is M dons multi domain optical networking service. This complements the the previous cross domain cross layer VPN CC VPN blueprint and together they can be used to create a complete solution. So CC VPN was can be used for layer two and layer three and M dons is used for layer zero and layer one. So what does M dons do M dons you order the end to end optical network service through the BSS and you ordered it into one on app on app then peers that information to another on app instance that could be sitting in another service provider or a different business unit within the same service provider. So now you have both the own app instances coordinated having the same information and the own app instance in turn passes that information on to the domain controller that actually does the optical sort of management and automation and the interface to those domain controllers is through two standard APIs ONF TAPI transport API or open Rotom. So those are the two APIs that were shown. So what problem is the solving. So today if you are trying to construct an optical service that spans to CSP is there's a lot of manual work. That goes on in coordinating the interfaces between the two CSPs. So it takes time. It's expensive. You know the customer has to wait revenue gets delayed. All of that can be automated to just a few minutes with this use case blueprint. There's also changes to CC VPN. So there are enhancements where you can now for E line services. There's improved support. So combined. If you combine these two blueprints you can get full automation from layer zero to layer three. Okay now we are going to move to standards alignment. As we saw since the Casablanca release of own app. There's tremendous collaboration between own app and third party standards organizations and open source projects. In fact, I think it wouldn't be an exaggeration to see that many of these standards organizations view on app as the reference implementation for their standards. So Etsy. There's a ton of collaboration going on. Sol three was already supported with the Frankfurt release their support for Sol five, which is the interface to an NFVO and Sol two, which is an interface from a GVNF manager to a VNF. There's also support for Etsy for the Etsy catalog specification Etsy packet extraction and VNF packet subscription and notification. TM forum is another very important organization from an own app point of view. The northbound API's are harmonized with TM forum API's and There were changes made to the Frankfurt release to support network slicing so you can order a network slice through the TM forum API's. The VTP rest API. So it's both ways. So own app benefits from TM forum, but it's also the reverse where we're done and own app is flowing back to TM forum. So the VTP is a test automation project and VTP's rest API was contributed back to the TM forum test API. MEPH as you saw with the M don's blueprint also the same with the CC VPN blueprint MEPH continues to be quite important in terms of its APIs, LSO APIs. So you saw in the previous slide the MEPH legato API was used for Southbound interface to own app from BSS and the interlude APIs were used for appearing from own app to own app. 3GPP there's a collaboration going on on the 5G side. So all of the 5G network slicing activities you saw were aligned with 3GPP and fault management performance management collection. All of that is aligned with 3GPP. Oran Alliance. We talked about the O1 interface and the A1 interface that is aligned with the Oran software community. So strictly speaking, these activities are aligned with Oran software community as opposed to the Oran Alliance, the specification body. So for those that are new to Oran, Oran has multiple aspects to it. The first is specifications. The body creates the number of specifications. The second is software community that implements the functionality required by Oran. So the collaboration is with Oran SC. And O1 interface is for fault management, performance management and configuration management. And A1 interface is between a functionality called the non real-time RIC which resides in own app to the near real-time RIC which resides outside of own app. And it's an interface through which the non real-time RIC can push policies to the near real-time RIC. Next we go into the deployment readiness enhancements. So what are the things that are done in own app to make it more suitable for production deployments? The first is integration project improvements. There was a new team that took over the integration project and they have made substantial improvements. The first change that was done was patch submission gating. So what this means is any contributor in own app, when they submit a patch to be incorporated into the own app code base into the master, there is an automatic deployment of own app and it automatically runs tests to make sure that this patch is functioning correctly or it's not breaking the build in some sense. So that has been done and during the Frankfurt release, more than 4,000 automated own app deployments were spun up and spun down to do this patch submission gating and more than 70,000 test suites were run. So that's just an amazing amount of automated sort of testing that was done. And this directly impacts the velocity of own app because now you're no longer second guessing yourself, you know, did some so-and-so patch work or is the master broken or is it still functional? So it substantially improves the velocity of the project and the stability. So as a CSP, you can be confident that the code base is in a lot higher quality. There are other testing improvements as well, expanded testing, test framework improvements. So there was collaboration with opnfv. Opnfv has historically had a very robust and high quality set of testing test framework tools. So those were adopted into own app. So the test API, the test results database, test visualization were all taken from opnfv. There's also support for classifying what types of tests should we have, what tests should be run in response to what types of activities, what frequency. There are test KPIs that are being defined. There's a Python SDK for testing. So a ton of work on testing. And there was also requirement gap analysis done on what types of tests exist, what types of tests are required, and we already talked about the KPIs. So this is probably not the most exciting part of the Frankfurt release, but it is super important because if you're considering putting own app into production, which you should, then these are the types of things that matter. Security improvements, there's, it's been an area of rapid improvement. It's a lot of focus is going into security. So HTTP, there were many services, microservices that were exposing HTTP as a way to interact with them. So they're being converted to HTTPS. There's removal of hardcoded passwords. The Kubernetes pods are more strictly speaking, the containers are increasingly running with non root privileges, because as you can imagine, if they're running with root privileges, you can, if they're attacked, you can sort of do some bad things. Vulnerabilities have been reduced. There's upgrade of libraries and these upgrades directly improve security. Java library, Angular library, Open Daylight release have all been upgraded. CII is a way to sort of do security badging. There's greater support for CII. Integration with AF for automatic certificate generation. So once you switch to HTTPS, you also need certificates and certificate management in previous releases has been sort of all over the place. So with Frankfurt, it's being centralized into a project called AF, authentication and authorization framework. And with that, you can streamline how certificates are generated and how you can update them, etc. And there's a SAS service for code scanning called Sonar Cloud. And that's being used for on app as well. So numerous security improvements. Now we'll go into the functional updates. There are, this is split into two sections, design time updates and runtime updates. So in design time updates, the, there were numerous enhancements from a modeling and an AI point of view. So an AI now includes new or updated models for 5G service design 5G networks. We talked about the 100 plus items from a modeling point of view 5G network slicing CCV PN M dawns PNF enhancements and for managing external dependencies. There's also better visualization for looking at the schema. And design support through virus XMI UML. The next there is support for self service control loops. So why are these important? The reason these this feature is important is you can, you as a user can now control, create full control loops without waiting for an official on app release. So that's where the self service comes from. And how do we accomplish that? There's a new DCA microservices onboarding and design aspect in the in SDC. And that's to onboard DCA components like microservices compose flows and dynamically distribute these blue blue prints to the runtime engine. There's support for Tosca model. So the entire control loop can now be described in Tosca and that makes it easier more consistent and all the benefits you go get from modeling like you can have revision control, you can go back to an older one. You can essentially describe the entire control loop as code. Policy based reconfiguration of DCA microservices. And that's important if you want to make changes to microservice configuration in runtime. For example, if you want to change a threshold on the fly. So you can do those types of things. And a blueprint generator tool to simplify deployment artifact creation. And then on the configuration and life cycle management. There is a new component called CDS controller design studio. It's not new for Frankfurt. It was released a couple of releases back, but it's still relatively new. And this is used for templating so you can template your configuration and life cycle management actions. So you don't have to go one by one like configure this item or change make this life cycle management step. You can just package all of that in up in a blueprint. So there's design time support for that, which makes it easier to include sort of package list search package creation. It's easier to create and manage these controller blueprint archives via GUI. So those are some of the main changes on CDS on the runtime. So CDS is repeated here as well. So CDS, there were changes on the design time and runtime. So on the runtime CDS is now first class citizen. So it has integrations with SO clamp and policy projects. And CDS also has a number of new features like rolling upgrade of these blueprint of blueprint processor error catalog library integration certification of a BP process processor imperative for imperative flows and support for Python scripts. And last but not the least, there's increased support for cloud native for Kubernetes NFVI. So there's a Kubernetes plugin in the multi cloud project that now supports CNS and CNS. So CNS are cloud native network functions, CNS are cloud native applications. And this includes provider networks, multiple virtual networks per cluster that all span multiple Kubernetes clouds. And the Kubernetes plugin also now supports Starling X. So as you see, many major design time and runtime updates that are also changes per project. So I'm not going to go through all of them just I'm going to hit some high points. You can definitely there's a wiki page on wiki.onab.org that talks about key Frankfurt updates so you can read more about that there. You can also go through the release notes if you want to go through in detail what changes were made to each project. AF, certificate management protocol v2 integration, app C, which is the application controller. We talked about CDS. So now you can have resource resolution via CDS, CDS integration and support for 16 brand new lifecycle management commands. And we've listed three of them config scale in post evacuate start traffic. So there's, you know, 13 more. Clam. There are changes to support the self service control loops that we talked about. So it can now support fully model driven control loops and can support CDS as an actor. So you can include CDS in your control loop. DCA we talked about the mod platform. There are also new microservices that have been created event processors. PM performance management subscription handler data lake handler for analytics and root cause analysis. There's thresholding gen two TCA. And there's also experimental support to onboard acumos models acumos is the ML model modeling project. So you can onboard those models on to own app. D map is the messaging bus. It supports message router and data router MR and DR. So there are some updates on the MR side to protect update operations. D map is built around Kafka Kafka. So the underlying message buses Kafka. External API that are changes made to support slice ordering. MSB is sort of a service mesh precursor to some of the newer service meshes like Istio where you can register API's you can discover services, etc. So now you can register Frankfurt API's. OF is an optimization project and that's becoming increasingly important. It's used for slice or slice subnet selection for network slicing is being used for model driven route optimization for optical networking paths between two domains for CC VPN Policy number of updates. You can policy update notifications. There's health check streamlined health checking for policy administration point. You can now configure pre loading or pre deployment of policies. There are new API's to for example create more than one policies using just one call. And there's a new experimental monitoring GUI for a PDP policy deployment point. The portal has been enhanced. In terms of the GUI from angular from an angular point of view. And then there's all improved back in performance added reporting features. So Many new features from an Etsy compliance point of view. Sol3 has already been there. So there are some enhancements but Sol2 and Sol5 are new. There's also a PNF support software upgrade without an external management system EMS. We talked about that. There are brand new workflows for NSS NSMF and CSMF and there's a new adapter for an external NSS MF. Then there's also support for CC VPN E line with which we talked about and M dons. VFC the NFVO project now supports Etsy catalog specification and UUI which is a runtime GUI. It's an operational administration and management GUI can now support CSMF and NSMF UIs. There's a monitoring module to monitor 5G slices and there's also support for CC VPN E line over OTN inter domain links and M don support. All right. So that covers the release highlights. Now we are going to quickly look into what's new and then jump into Q&A. So what's next? Training for own app courses are now available through Linux Foundation training. So if you're interested in own app and don't know quite where to start, I would encourage you to check it out. There's a new exam coming up. It's the certified own app professional exam beta opens in July. And that's if you are a CSP and you have a team of engineers that you want to be certified, you know, at least they have solid baseline understanding of own app, then they can take this exam. The next release of own app Guilin comes out in second half of 2020. Guilin is a city in China. You can see the picture there. It's a very beautiful city. There's increased support for 5G in the areas of network slicing. So today in network slicing, you can do creation and activation and you can do deactivation and termination, but you can't really do the life cycle management of a network slice in between where you want to optimize, you want to modify, you want to change or adapt the network slice. So that will be there in Guilin. Much deeper ORAN integration in terms of more complete support for O1, more complete support for A1. Aspects of the non real-time RIC will be available. So this is all going on for Guilin. Increased Etsy support, for example, the Solve 7 standard and increased harmonization with 3GPP standards. There will also be deeper cloud native integration with Kubernetes. So these are all the things you can look forward for for own app Guilin. How do you, how can you get involved? You can read about the own app architecture release notes that I had mentioned. Documentation. You can read about use case blueprints. The 5G blueprint solution brief has been completely updated. There's an Mdawn solution brief that you can read about. There's some end user oriented documents that are available. The end user advisory group has done a piece on own app consumption perspective. So you can see that. Bell Canada has actually been using own apps since 2017 in production. And people almost think that's, that's a miracle, but they have been. And finally now you can find out how they did it. So there's a case study on Bell Canada and it in detail outlines what they had to do to be able to put own app in production and how to be able to successfully extract value from own app. And if all of this sounds interesting and you would like to join the community, you can join weekly project meetings. There's a link to that. Whatever project catches your fancy. You can, it's an open project. That's one of the benefits of open source. You can just join. There are two events coming up. There's an event coming up next week, the virtual elephant developer and testing forum. And that's a really good place to understand what's going on with own app understand some of the projects more deeply. It's a free event. So I would strongly encourage everyone to join registration is required. So please do register beforehand. And it's been designed in such a way that it's people from almost all time zones can take advantage of the event. And then there's open networking and Ed summit coming up in September. And that's a virtual event. And there's more tips on how to get involved by clicking on the on the link. So you will have these slides so you will be able to get access to all these links. So with that, I'd like to conclude. So on app is the Frankfurt release is the sixth release. It's most comprehensive secure and collaborative, as you hopefully saw, rich feature set including end to end 5G network slicing optical integration via M dons security and deployment readiness anchored in Frankfurt. It's a collaborative release with diverse contributions 27 sub projects 34 organization 400 plus developers new CI CD through the patch gating automation automated testing that we saw deployment is accelerating from commercial adoption. You saw the tremendous sort of jump in commercial activity around on app and the collaboration with 3GPP at CMF team forum, and we didn't really talk about the this last aspect. Too much collaboration with CNCF and Linux Foundation Edge. So you'll just have to take my word for it but there was there is a lot of ongoing work going on with the carino project with CNCF telecom user group the CNCF tug. And then we also talked about the open ran software community. So that concludes the presentation portion of this webinar and we can now cut over to the Q&A. Great. Thanks Amar. We do have a handful of questions here. So I'm just going to go down the list. The first one. How do you see on app co co existing with Mano and or Kubernetes. Can they coexist or will operators choose the orchestration model. So on app in my mind is a Mano plus plus it does everything that is required by a Mano and it has the additional functionality in terms of service assurance or control loop automation. Different people use different terms. It also has inventory services and it has a design palette. So these are three things that are over and above what say a classic Etsy Mano would require. So in that sense on app is a Mano. So you can use it for that functionality. You do not need to use on app along with some other Mano. With Kubernetes, it's completely complimentary on app does not try to replicate anything that's being done by Kubernetes. And you can think of on app. If you think of Kubernetes as resource orchestration, you can think of on app as application orchestration and management. So on app will manage containers phenomenally well within and a cloud. But if you let's say you have 10,000 clouds, some that are ed, some that are core, some that are public and you need to push all these services and applications to different clouds, manage their life cycle day zero configuration, networking configuration, security configuration, change management, migration, replication, control loop automation, then that's what you would use on app. So I see those completely complimentary. Great. Thank you. Next question. And the Frankfurt release DCAE MOD is introduced. Is it going to replace SDC DCAE DS? No, no, I believe they're complimentary. And I'm not exactly sure how they work together, but I believe they're complimentary. Great. Another question. Today for CNF deployments, we package the helm charts and heat package to satisfy SDC and SO. And Frankfurt, can we just onboard our SOL 004 package and create service and distribute it to runtime. So I believe the mechanism is still the same as Dublin and El Alto. So you sort of have to go through the same flow, the heat, heat with helm inside it. Great. Thank you. Who can be a user of on app like O-Ran, who could be others? So as we saw in the use case blueprint section, on app has wide appeal. So, and frankly, even that list is by no means comprehensive. So what we are seeing on app being used for residential connectivity for enterprise use case for SD van for transport use cases for and for mobility with 5G being the key one. And also for edge computing application orchestration. So the MEC orchestration function. So it really, it's not just for O-Ran SC. It is very useful. O-Ran requires a component called a service management and orchestrator SMO. So on app, of course, is a wonderful SMO from an O-Ran point of view. But that's not the only thing. It's all the other use cases that are described are things on app is being used for. In fact, it's also being used as an LSO by one of the operators. So wide range of use cases. And frankly, these are just a few. The use cases are limited only by people's imagination. Wonderful. Thank you. Where do you see on app going next with 5G and then even into 6G. Right. So 5G as we saw, I think the thing with an open source project, it's never done. There's always more to do. So you see that with Frankfurt, there's for the first time, there's comprehensive end to end support for 5G. So you can actually take on app Frankfurt and use it for in production 5G deployment. So you saw all the features for that, but there's always more to do. So you will see a lot more work on slicing. So that's something that's coming up in Guilin. O-Ran software community integration, you will see a lot more broader support for O-1. The first implementation of the non-real-time rig, there's several companies working on aspects of the non-real-time rig. So those are the types of things you will see, you will see much better support for cloud native in Guilin. So that's what you can sort of look forward to. Okay. A few more questions. Like O-1 and A-1 interface, are there any plans for generic interface where O-Ran type user can connect as a plug-in? Yes. So the beauty of O-NAP is it's a platform. So these interfaces, there's nothing special. There's no hard coding being done. So if there's something else that requires a different way to do configuration management or different way to push policies from O-NAP to the RAN, it's completely possible. So O-NAP has the concept of workflows in the service orchestrator that can be completely modified by the user. It has the concept of directed graphs in these controllers, which again can be modified by users. So it's a very configurable platform that you can adapt to your interfaces. Okay. Thanks. Can you confirm that Frankfurt supports five 5G slices? That diagram was just an example. To be completely honest, I have not heard what the upper limit is. I imagine it does, but let me take that as an action item. But that particular picture was just an example. Okay. What's the plan for SDNR? So SDNR continues. It's under the SDNC project. And in fact, if you see some of this new work like the A1 interface is in SDNR. So that is to the best of my knowledge, continuing just fine. And we'll keep adding new features to support things like better radio integration, A1 interface, etc. Okay. Great. Well, that takes us through all of the questions that have come in. So unless there are any other last minute questions, I think we can conclude today's webinar. Okay. No more questions. Well, thank you, Amar. And thank you everyone for joining us today. Congratulations to O-NAP for getting Frankfurt out the door. And have a good one, everyone.