 Hi all, welcome to the session on one app for XNF-based 5G service orchestration. Myself Sesh Kumar Modiganti from Huawei Technologies India Private Limited and me along with my friends from Orange will be demonstrating today the orchestration of free 5G C or the free fifth generation mobile core network orchestration using one app. Let's get into the demo before we start with the session. I wanted to give a brief on how the journey so far had been with respect to one app. One app initially as we know has been incubated in the month in the year 2017 as Amsterdam release. Within it actually was a combination of two open source projects, open e-comp as well as open no. And the combination gave us a good platform which actually had a design time, the runtime and the closed loop interactions of the VNF, the virtual network functions. Then came the third release, the Kaseblanka release, which was very vital for us. We also had the orchestration of PNF capability introduced in one app. Along with this, the major milestone or breakthrough was the introduction of the ETSI standard alignment within one app. Initially, we did the Sol3 alignment as external VNFMs could be also orchestrated along with the services which are there in one app. This was a major breakthrough for us to actually have better standard alignments within one app. Then came the Dublin release wherein we actually improved on all these aspects, the PNF, VNFs along with that we also introduced the CNF orchestration. Though at this point of time, we were mainly focusing on the POC level of CNF orchestration wherein we were embedding the Helm chart into the ONAP heat repository and we were actually onboarding the same onto STC and for them further we were distributing it to further of ONAP. The CNF constituted of the container network functions semantics, which was actually understood by the KATIS plugin introduced into ONAP and hence we were able to do the PNF, VNF and the CNF as a POC still, but by Dublin timeframe. This was a world further, El Alto release was mostly a maintenance release wherein we actually took a lot of technical data and cleared it off, but then crimped the Frankfurt release wherein we introduced the slicing. When we're talking about slicing, we are talking about the E2E slicing here that we were mainly focusing on the core, the transport and the RAM slicing. Though in Frankfurt, we were mainly focusing on the core part of the slicing using a virtual network functions as part of service. This is a world further into Guilin and Honolulu wherein we actually had a full-fledged understanding of Helm charts right now ONAP can onboard Helm charts. We have introduced a new type in the resources, which is a Helm type. This brought in the status of a first-class relationship for the Helm chart itself instead of a POC level which we started from Dublin. Having said that, now the slicing also uses the core, the CN part of it using the CNFs and the transport and the RAM part of it using the VNF mode of it. So this is a quick overview of how we have evolved with respect to the XNF wherein it constitutes of the PNF, the VNF and CNFs and how the different key requirements and the standard alignments have actually happened within ONAP. Now, coming back to the scenarios which ONAP actually can take in, as I was talking about two major things. One is the ETSI alignment, the other is the native Helm-based orchestration. Both of them are getting done using the current flows. What we want to demonstrate in the current demo is actually the native flow wherein we have the free 5G core Helm charts being demonstrated using our native flows and we actually have all the three kinds of resources there. With that, we will be demonstrating the end-to-end orchestration of a 5G core application. Having said that, I want to hand over the flow to my friend, Ukash from Orange, over to you, Ukash. Okay, thank you, Sessha. Now, I would like to focus on the description of different software components and the scenario of the demonstration. Firstly, let's say something about the two words 5GS project which is aiming for the simplification of the free 5G core deployment. First of all, like I said, this is an open-source project which leverages Kubernetes and Helm and is focused on the deployment and testing of the containerized 5G service on top of Kubernetes. So, we need to recall that the Kubernetes, of course, is a platform for management of the containerized workloads. Wifang is an application which aims for the simplification of the management and installation of the complex application assigned to Kubernetes. So, in this solution, we leverage open-source software components. The first one is the free 5G core solution which implements the PGPP RIS 15 specification of the 5G core. And it can be decomposed into different elements of the 5G core starting from the UPF, which is the implementation of the 5G core user plane. And AMF, SMF and other components which implement the control plane functionality of the 5G core. The second open-source component is the URNC solution which is an implementation of the user recruitment and GNOTB for the 5G standard. Both contribute to the Towards 5GS project. Both implementations and Towards GS software packages can be found in the GitHub or in the URNC software repository. So, if we focus more on the details of the Towards 5GS platform, here we can see different software blocks. The green ones are those of the free 5G core while the blue ones are belonging to the URNC. Moreover, in the dotted lines, we'll see the Helm charts. So, first of all, to create this solution, we have created Docker images for the free 5G core and we have placed them in our organization for the future download. Later on, we have created a set of Helm packages which you can find in the Towards 5GS repository. And these Helm packages are able to be installed with the standard Helm client or any other implementation of the Helm client like, for instance, the one we can find on the on-app platform. Further, we have tested the installation of the free 5G core and URNC on a specific configuration of the environment starting firstly with the Kubernetes version 121 and Helm client version 3.4.2. However, on-app implements version 3.5 of the Helm specification and such one was also tested. For the Kubernetes platform itself also, there is a requirement to use a specific version of the kernel. For the working nodes, this is required for the deployment of the UPF component of the free 5G core. So, as we can also see, all the software components are split into free Helm packages 2 for the free 5G core and 1 for the URNC component. In terms of the further configuration of the platform, we have tested the solution of the Flannel and Calico containerized work interfaces. And the solution also requires the Maltes component to be installed in the Kubernetes, which is required to associate many interfaces with the selected pods created on the free 5G core. Last but not least, we require also the MongoDB, which is used for the storage of configuration and state of the components. So, all together, like it was mentioned, we can find the software components or in the GitHub repository dedicated for the project or in the Docker Hub organization where the Docker images are stored. And in the Bitnami MongoDB implementation can be found for the database as well. Now, let's focus more on the demonstrated scenario itself. And in the further slides, I would like to present more information on what is the purpose of the demonstration and how it looks at demonstration scenarios and how we will utilize towards 5G software components along with the on-app platform in order to orchestrate XNF-based 5G service. So, the orchestration of the 5G service, of course, will be performed by on-app and here we will leverage the capabilities of the joint orchestration of the CNFs with the PNFs. And mostly thanks to the latest advances in the implementation of the CNF support in on-app and the progressing support for the PNF reconfiguration as well. So, in the entire process, we focus on the lifecycle management of the 5G service. However, we don't focus on the orchestration of the networking and we don't do the 5G slicing management. So, mainly the software components, lifecycle management and the configuration of them. We also have an assumption that our infrastructure, of course, will let us to have the PNFs, the PNFs and the CNFs, where the PNFs are typically placed on the OpenStack and the CNFs on the Kubernetes. In our example, in fact, the Kubernetes itself would be created on top of the OpenStack and we will not do this demo orchestration of the PNFs. So, let's say we have an assumption that this infrastructure is ready and running. So, the main purpose of the demo is to create a service and to have possibility for the end-to-end connectivity test. One remark more is that we don't, of course, utilize the real PNFs. So, we use the URNSim software component. So, in fact, we utilize the orchestration capabilities of ONAP to create a URNSim application. And this would be used and will be represented as a PNF in one service which will have the PNF and the 5G core CNF. So, the entire process of the orchestration starts from the unboring phase where a network administrator is passing the software packages for our network functions, including the hand charts for our P5G core solution. Then network administrator triggers the deployment process of the CNF, providing necessary input parameters. And with this inputs also we can steer on more and influence how the deployment process will look. However, the deployment process of the CNF cannot be completed until the PNF is registered. So, like you have already heard, we will create in the meantime the PNF service and the registration event will be sent to ONAP. This will, of course, pass the necessary identifiers of the PNF and will let the completion of the 5G core setup. So, once this is done, ONAP will perform, first of all, the check of the health check of the CNF and PNF, and afterwards will perform the synchronization of the configuration between the CNF and the PNF. Thanks to that, both network functions will have the same configuration, so it will allow us for the creation of the network connectivity. Of course, the last one would not be possible until we don't create the user profile in the control plane. So, we will utilize the capability of ONAP for the creation of the customized workflows for the registration and the creation of the subscription. And this is completed. At the end, we performed the connectivity test where we showed all the setup and orchestration was completed properly and the end-to-end connectivity from the user equipment to the internet is possible. So, in the further part of the demonstration, we will show in eight different steps the recording of the demonstration, and it will be more or less composed like it was shown in the previous slide. I think it's worth to mention also that the entire process is automated and for that purpose we utilized the ONAP SDK, which is a Python library which covers the rest of the APIs exposed by the ONAP platform. So, this was used to create all the automation environment, automation logic, which in fact also is inspired by the work done in the VFIROS CNF use case, which officially demonstrates the capabilities for the CNF orchestration in ONAP. Hello, my name is Michał and I would like to thank my colleagues Łukasz Abderawów, Elements SESU very much for their very good cooperation. The result of our work is a shorter demo, which I will have a pleasure to present, the orchestration of Free 5G Core using Open Network Automation platform. The first step mentioned by Łukasz is service onboarding. It is triggered by running the onboard script. During this procedure, all necessary packages and files describing the service are uploaded to ONAP. The service package is prepared in advance and contains two types of network function models. The first one is a descriptor of the PNF radio access network. The other one defies the CNF core part and consists of Helm chart and post configuration operation specification. The PNF package is uploaded and validated first, then the core part package is processed by ONAP. The last step of onboarding process is service distribution. The scriptors and required files are being passed to specific ONAP components during this operation. Once it is finished, service is ready for deployment. In software design and creation application, we can look through onboarded resources. The components of 5G service are presented here. Resources related to Run Simulator can be found here also. In details of core service, there is a composition tab that presents service graphical visualization, PNF and CNF. The deployment of our use case begins with free 5G core instantiation, which is started in the right top window by running instantiate script. The goal of this process is the creation of the CNF instance defined by the Helm package. But it is not the pure Helm chart, but the package that includes complex models describing the process of parametrization and post instantiation configuration. ONAP is a very powerful tool for such operations. The platform allows parametrizing Helm packages with input parameters defined by ONAP. Thanks to a wide range of parameter resolution methods, they can be resolved as input or read from an external system or service. CNF Helm package with a set of custom parameters is instantiated by ONAP in selected Kubernetes cluster and dedicated namespace. The free 5G core use case is a single Helm chart with multiple parameters resolved from the input. Details of Kubernetes cluster prepared for demo purpose needs to be registered inside ONAP. Its identification data are also passed as one of the instantiation parameters. Progress of the instantiation process is shown in the logs. You can observe actually running building block and the number of steps that remain until the end of deployment. Core instantiation would not be started before PNF association with the service. This is the result of the PNF registration process. In our case PNF is simulated by your RunSim Helm application treated by ONAP like PNF. Its instantiation is run in the right bottom window and takes about 30 seconds. During post instantiation operation for RunCNF, a registration request is sent to the orchestrator. This procedure passes required identification parameters of PNF to ONAP and as a result enables communication with PNF from ONAP perspective. Registration of the PNF is required for the continuation of core CNF instantiation. It takes about 3 minutes and 20 seconds until all pods are up and running. The status of the pods is monitored during post instantiation status check. At this stage, core and run parts are instantiated and run is properly registered as physical network function. All pods are in the running state but the reconfiguration of the radio access network is not completed yet. Connectivity test that verifies end-to-end connection is implemented as a Kubernetes job and run by ONAP as a health check operation. During the job execution, interfaces attached to the user equipment simulator and the execution of the ping command are verified. Missing U.S. Symptom 0 interface is the reason for test failure. The connection from the U.E. towards the Internet through free 5G core cannot be established. Further reconfiguration of the run components is needed to deliver a working service. After CNF instantiation and PNF registration, ONAP can run data reconfiguration operations. One of them is checking by ONAP status of the created pods in the Kubernetes cluster. If all of them are up and running, following procedures could be run. In order to complete service deployment, ONAP can execute specific scripts called REST APIs or perform any other operation defined in the onboarding model for specific CNF. We utilize this functionality to perform registration and reconfiguration operations. The first use of this mechanism is to register user equipment and to make its subscription in free 5G core. The second use is the reconfiguration of the PNF. Based on the reconfiguration template, parameters like MNC and MCC resolved from core CNF can be modified in the run part. As a result of the reconfiguration procedure, Gnode Bpod is recreated with updated parameters. The creation of new pod and termination of the old one have been already done at the beginning of the video. The successful subscription is visible in the dashboard of the free 5G core network. The result of Gnode B reconfiguration could be observed in the real-time status tab, where UI status is connected now. The connectivity test drop is still running and creating new test pods. After successful recreation of the Gnode Bpod, it is expected that test will pass. It is confirmed with the test pod that the status is completed. In the right bottom window, you can see the logs from the completed pod. This time, the US in Tanu Zero interface is attached to the user equipment, and pink Google works well. None of the packets sent to the internet through the free 5G core was lost. And-to-end connectivity towards the internet through free 5G core is established. The connectivity test drop cleans up all test pods after 100 seconds since test completion. It's good to have also a mechanism that removes other resources from the Kubernetes cluster. We are doing that with the dedicated script, which is started in the right bottom window for the run part. In the Kubernetes console, you can observe the termination of the UE and the Gnode Bpods. In the free 5G core dashboard, you can observe that the status of considered UE has been changed from connected to idle. I really appreciate your attention during this meeting. I hope this presentation and demo were interesting and satisfying to you. If anyone has any question, please feel free to ask them now in the chat. Session and Wukash will do their best to answer all of them. Thank you very much.