 Good morning, good afternoon, good evening ladies and gentlemen. Welcome to our panel session on App for Enterprise Business. I'm Catherine Lefebvre, I'm the ONAP TST chair, working as an EVP at AT&T, and today our speaker will be Amar Kappadia, co-founder of ARNA Networks, Javier Singh Seti, software engineer at ARNA Networks, and Bin Young-Jean, our ONAP architecture subcommittee vice chair, but also principal engineer at Ericsson. Let me tell you first why ONAP becomes a true enabler for innovation in support of future industry use case. Over the last four years, the ONAP committee has been collaborating with the industry through cross-open source committee engagement and cross-influences with standard design organizations. We have developed impactful features and functions, like 5G footprint, network slicing, and ORAN integration. We continuously add more cognitive and modular capabilities, secure and robust integration. We are also implementing ONAP best practice and global requirements in our source code to offer scalable, reliable, and secure production readiness deployment. All of this makes ONAP a true enabler for innovation. While ONAP has primarily been used by network service providers to support their network automation transformation and run virtualization journey, the ONAP community also recognized the value of ONAP in enterprise vertical markets. A new task force ONAP for enterprise business has been created accordingly early this year. So, Amar, can you please give us more insight about our ONAP for enterprise roadmap? Yes. Thank you, Catherine. As Catherine mentioned, this working group's goal is to show some concrete set of activities that can demonstrate value for enterprises. One of the first use cases we are working on is around private 5G. The market estimates for private 5G are extremely promising. You've probably heard the numbers, Nokia has estimated it'll be an $800 billion market by 2030, ABI research, STL have even predicted larger numbers. Along with edge computing, private 5G is expected to revolutionize industries such as industry 4.0, precision agriculture, hospitals, smart cities, V2X, construction, and more. So, as you see, we have a rich roadmap for the enterprise working group. Broadly speaking, it's in two aspects. One aspect is collaboration with the 5G super blueprint, which we will talk about in the next slide. And where this working group is the ONAP subject matter expert and all the ONAP related work architecture is being driven by this enterprise working group. The second is to integrate with a very novel network slicing approach from the University of Southern California called Sabres, which is highly secure as well. So now with that background, some high points on the roadmap. So what have we accomplished so far? We kicked off the task force in the first half. We did the architecture work to define how magma can be integrated with ONAP and you will see a lot more details about that in subsequent slides. And we have completed the integration of ONAP with Anukit. Anukit, as you will see in a subsequent slide, is the NFVI layer, its standardization of the NFVI layer, and we have completed the integration with the Kubernetes version of Anukit. And we have also integrated magma with Anukit. What are we working on this half in the second half? We are starting to implement the architecture work we did in the first half, meaning implementing the integration of the magma controller and access gateway with ONAP. And you will see a lot more details as we go along. We are now working on architecting some of the data collection KPIs and metrics, which we will implement subsequently. For this half, we are going to exercise the magma 5G core, which we will talk about more as well, with a UE and GNode B emulator. And finally, we are starting the design work to integrate with sabers. Next half, we are going to implement many of the things we are architecting in this half. So data collection and implementing the KPIs will be done next half, doing some control loop work, implementing initial sabers integration, and with core slicing with ONAP. And we will replace the GNode B and UE emulator with an actual RAM. So it will be a commercial RAM that we will use. Subsequently, later next year is going to be all around making what we have done more sophisticated. So the orchestration will be more sophisticated in terms of going to a fully cloud-native environment. We will be handling multiple access gateway CNFs, optimization for network slicing, more complicated LCM operations. And then later in 2023, we will be all around machine learning where we will look at AIML patterns. We will integrate with a function called NWDAF, Network Data Analytics function, which is all around machine learning. Can go to the next one. So this one talks about our collaboration with the 5G Super Blueprint. The 5G Super Blueprint is a place where we can integrate numerous Linux foundation projects that are all extremely relevant to 5G and edge computing. So before this initiative, there was no single place to integrate all these projects. And the 5G Super Blueprint is such a place. And as I mentioned, the ONAP Enterprise Working Group is a subject matter expert. And all of the ONAP design work and a lot of the implementation is coming, is driven by this Enterprise Working Group. So as you see, the scope of the blueprint is quite ambitious. It goes from the user edge to the service provider edge to the cloud slash core. It has edge computing components. It has 5G components. For today, we are not going to talk about the edge computing portions. We are only going to talk about the 5G and the core cloud components. So the notable parts are ONAP. So ONAP will be providing orchestration and lifecycle management. Historically, this role has been called the MANO, Management and Orchestration. More recently, there is a new term called SMO, Service Management and Orchestration. We are approaching this from a cloud native point of view. So we are using Kubernetes and using that to orchestrate both containers and virtual machines. 5G network slicing, we talked about, support for ORAN SC as the SMO. Initially, it will be a commercial ORAN. But over time, we will support ORAN SC, which stands for software community, ORAN software community. Patrol loop automation analytics and more. So that's the role of ONAP. We will be integrating with MAGMA. You will see more about MAGMA in a subsequent slide. It's a 5G core. It's an open source 5G core, LTE and 5G core, I should say, in the Linux foundation. ORAN SC, which is the implementation of the ORAN software components. And last but not the least, Anukit, which as I mentioned already is the NFVI layer. And for purposes of this blueprint, we are using the Kubernetes version of Anukit. There are two OpenStack and Kubernetes. So that's the whole scope. And with that, I'm going to hand it off to the next speaker, Prabhjod. Yeah. Thank you, Amar. So coming to ONAP compliance with Anukit, with respect to platform development process, ONAP is already leveraging conformance, functional validation, and performance frameworks from Anukit. As part of this initiative, we are essentially looking forward to use the infrastructure management aspects, leveraging Kubernetes reference infrastructure based on reference architecture and implementation projects in Anukit. Essentially, covering Kubernetes conformance aspects, most for most of the use cases, enabling faster, robust onboarding into production environments. And in a process, of course, saving on engineering cycles and reducing cost. So ONAP is already a fully containerized platform deployed using Kubernetes. And as part of this, we are rolling out ONAP itself and some of the other managed services like Magma Controller on a kubref environment, where kubref is a project under Anukit that delivers the Kubernetes-based reference implementation according to the reference architecture RA2 specification, allowing us to achieve conformance as per RA2 project of Anukit. So ONAP as well as Magma Controller deployment on kubref is already validated, making ONAP compliant with Anukit standardized Kubernetes infrastructure. Additionally, in future, we may also look forward to leveraging some of the conformance and performance framework from Anukit, which will allow us to enrich information with respect to interoperability aspects as well as the capacity or capability of the various solutions that will be delivered as part of this task force. Next slide, please. So another important piece of the solution with respect to 5G is Magma. So for those who are not familiar with Magma, it is an open source packet core originally open source by Facebook in 2019 and has recently become a part of Linux Foundation. As represented in the diagram on the right side, Magma essentially has three major components, access gateway, providing packet core functionality equivalent of AMF, SMF, UPF in 5G terminology. However, Magma itself is a converged core and that's why access gateway also extends support for LTE and carrier Wi-Fi. The second component is federated gateway, which is responsible for interfacing with the mobile network operator core. Other important component is orchestrator and NMS. Even though it is referred to as orchestrator, it mostly provides more of a controller or EMS functionality. So we are going to be referring to it as a Magma controller, which is mainly responsible for managing and configuring access gateways and federated gateways along with collecting various telemetry data from these connected devices. What's unique about Magma as opposed to other open source packet core projects is that it's already in production and additionally the project is backed by many contributors along with Facebook making Magma as the packet core of choice. And from architectural perspective, Magma core is hyper scalable, distributed where you can take access gateways, keep replicating it and scaling it out. It is highly available with many of its component being already containerized and cloud native except for access gateway containerization for which is currently in progress. It is vendor and transport agnostic and performs local breakout for internet traffic. It is also capable of interfacing with the MNO core with the federated gateway and along with providing capability to perform configuration and life cycle management remotely. All in all, it gives a converged packet core suitable for our use case. So with this, I'll hand over to the next speaker. Hi, thank you. Now we talk about the ONEP Magma integration scope. We defined two major integration scope here, initial scope and future scope. For the initial scope, ONEP is supporting orchestration of Magma controller and gateway, including access gateway. This function scope covers onboarding Magma CNF and VNF packages, defining services, and orchestrating the services through ONEP orchestration flow by leveraging ONEP runtime components and cloud infrastructure. Secondly, ONEP support Magma controller and access gateway configuration through the ONEP configuration flow. For instance, access gateway needs to be registered to the Magma controller to be ready to work with the controller and ONEP. Another one is ONEP supports Magma controller and access gateway life cycle management through the ONEP CNF resource life cycle management flows, for example, updating access gateway component. As the last initial scope, Magma network slicing will be supported. ONEP is a 5G network slicing orchestration platform conforming to 3GPP. Once Magma support network slicing later this year, ONEP and Magma can be integrated for the network slicing management. For the future scope, ONEP plans to support Magma controller access gateway control loops. For instance, ONEP collects network data through Magma and it can automate additional control loop, life cycle management orchestration actions. Also, with the collected Magma network data, ONEP can support analytics after that Magma plans to go further for identifying AI machine learning patterns on Magma controller data for smarter management. Next slide please. This is about ONEP Magma integration realization. The diagram defeats how ONEP and Magma realize the integration. ONEP has several sub components for design, orchestration, policy, assignment, configuration, FM, PM, and Covenant interactions. Magma consists of three major components as addressed before, controller access gateway and Federation gateway. Among them, controller and access gateway will be integrated into ONEP and tested first. The controller provides external interface for external systems. The access gateway implements CNF, BNF, PNF as IP edge handling. Federation gateways interacting with the MNO core network through 3GPP interfaces. ONEP manages Magma controller and access gateway onboarding and service design through the ONEP SDC component. Once Magma packages are onboarded to SDC, SDC designs Magma services based on the onboarded Magma models and distribute the Magma service package across the ONEP component. As shown in the diagram, there are two main interfaces between ONEP and Magma, controller, NOSPAN interface CM, LCM, and controller, NOSPAN interface FM, PM. ONEP service orchestrator and associated components work together to orchestrate the Magma network service into Covenant through the first Magma controller NOSPAN interface CM, LCM. Using the REST APIs, ONEP will register access gateway with the Magma controller and ONEP handles life cycle management on access gateway. Another interface point between ONEP and Magma for FM, PM is Magma controller NOSPAN interface FM, PM through the VES agent. ONEP DCAE component will collect FM, PM, and other telemetry data through VES agents. This is the summary of the ONEP Magma integration. Now back to you Catherine. So thank you so much Amar Payot and Bjong for sharing the first accomplishment made by the ONEP for Enterprise Task Force and also to give more insight about what we tried to accomplish in the coming months. So I also want to see the opportunity to welcome participation from new contributors that want to expand the applicability of ONEP. So if you're interested to join the ONEP for Enterprise Task Force, we are meeting on a big weekly basis every Wednesday. If you want additional information, you can go to the ONEP weekly and also type the Task Force ONEP for Enterprise business. And finally, we have also a mailing list if you want to reach any of us and additional ONEP community members. So now let's open the floor to any live questions from the audience.