 Hello, my name is John Keaney from Ericsson Software Technology. I will talk briefly about supporting non-real-time apps for service management and orchestration in an open-ran telecommunications environment. But first, let me talk a little about ORAN. The ORAN Alliance is a new telecoms industry initiative set up about three years ago to define an open, disaggregated interoperable RAN, or Radio Access Network. It was formed as a merger of the X-RAN and C-RAN initiatives from before that. The Alliance was initially set up by and continues to be steered by network operators. Now, together with equipment vendors and other interested parties, the ORAN Alliance defines new standards for a more open and competitive RAN supplier ecosystem. Ericsson joined the ORAN Alliance as a contributor in December 2018, making significant contributions. This includes co-chair positions in two of the working groups and numerous representatives in most of the other working groups too. The ORAN software community, or OSC, is a joint collaboration between the ORAN Alliance and the Linux Foundation, driving open source implementation of the ORAN concepts and functions. In addition to developing new code itself, it is expected to align with other related open source projects to support the ORAN Alliance architecture and specs. So, this is an overview of the ORAN architecture. The ORAN architecture is quite similar to and is pretty well aligned with the 3GPP RAN architecture. But it also includes some new functions and interfaces, including two new RAN intelligent controller logical functions, or RICS. One in the RAN and one in the OEM or service management and orchestration layer. A new E2 interface is also introduced to support more open, disaggregated RAN functions. A new A1 interface is also included to enable more flexible, fine-grained and dynamic optimization and assurance capabilities for the RAN. There's also a focus on being able to execute the ORAN functions on white box or cloud platforms represented as an O cloud. To help with execution platform management, including some aspects of function lifecycle management, a new O2 interface is also introduced. So let's talk a little about the SMO and non-real-time RIC. From an ORAN point of view, the SMO or service management and orchestration framework is responsible for RAN domain management. SMO capabilities include supporting F-CAPs functions for the RAN with the O1 interface, cloud infrastructure management with the O2 interface. The SMO framework also includes the non-real-time RIC. The non-real-time RIC comprises the non-RT RIC framework and the non-RT RIC applications or RAPs. These non-RT RIC applications or RAPs are independently deployable, modular, multi-vendor applications hosted in the non-real-time RIC. RAPs access the non-RT RIC and SMO services they need via the new ORAN interface. RAPs can then leverage the functionality exposed by the non-RT RIC over ORAN to provide added value services for RAN operation. For example, intelligent configuration, orchestration, optimization or assurance functions. At a minimum, ORANs should be able to gather data about the RAN and instigate changes in the RAN functions and infrastructure via the A1, O1 and O2 interfaces. The non-RT RIC platform must also coordinate RAPs, for example, support their lifecycle management and orchestration. It must also manage which functions and data is made available over R1 from the non-RT RIC and SMO and from other RAPs. So the non-RT RIC framework is responsible for exposing all required functionality over the R1 interface to the RAPs, whether from the non-RT RIC, the SMO framework or from other RAPs. As mentioned, the R1 interface will be an open, standardized, extensible interface for RAPs to access data and functionality in the SMO, non-RT RIC platform and from other RAPs. The RAPs working together with the capabilities of the SMO and non-RT RIC can then enable continuous non-real-time control and optimization of RAN elements, their resources and infrastructure, while also providing guidance and enrichment data to features in the RAN, all in time scales ranging from just seconds to much longer timeframes. We envisage that our RAPs may come from multiple vendors and can run on different SMOs, so a well-defined, open, standardized R1 interface is vital. We see that an open, standardized, multi-vendor R1 interface will lead to healthy innovation and computation, both above the R1 interface leading to an RAP ecosystem and below the R1 interface in the SMO platform and services. The R1 interface is also defined to be extensible to foster even further innovation. Given the importance of RAPs, R1, and the non-RT RIC, Ericsson has adapted a leadership role, not just in defining and standardizing these in the RAN Alliance, but also driving open source contributions for these in OSC and ONAP. As an example, I will briefly show some of the non-RT RIC platform functions we have contributed in OSC and ONAP towards supporting RAPs and the R1 interface. As mentioned, the non-RT RIC terminates the A1 interface, so services to manipulate A1 policies in the RAN and to support passing A1 enrichment information to RAN functions over the A1 interface are shown. The A1 policy functions are contributed to ONAP, while the A1 enrichment information functions can be found in OSC. A service exposure function in OSC will form the basis of an R1 service exposure gateway to manage RAPs accessing the non-RT RIC and SMO services and other RAPs. Many services already available in ONAP can be exposed to RAPs as a starting point while standardized R1 services are being defined and standardized in the RAN Alliance. We are currently extending the A1 enrichment information coordinator to act as a generic information coordination function for RAPs to access data from the SMO, including information about RAN state, again as an initial starting point while an R1 data coordination function is being defined. We have also demonstrated an early RAP catalog and a visual control panel and various simulators and test stubs. These are available in OSC. Our RAPs themselves are likely to manifest in different forms. Some may be microservice based. So we again provide an initial version of a Kubernetes Helm chart manager. We also envisage that apps may be formed as an aggregation of functions, configurations, subscriptions, orchestration directives, policies and models, which will require careful coordination with services provided in the SMO and non-RT RIC platforms. Some of these will likely be standardized as core R1 services and some may be R1 extensions. Such diversity of apps and their respective requirements will require careful consideration around RAP modeling, packaging, orchestration and lifecycle management and of course access control. What I have shown here is just a small snapshot of our commitment to own up an OSC. Own up functions are a possible starting point for some of the services and capabilities needed in an SMO and non-RT RIC platform. In own up we contribute in areas such as the policy framework and control loops, the configuration and persistency service, CC SDK, DMAP and DCAE in service orchestration and SDC and of course integration. We have taken on numerous leadership positions in own up and OSC towards making our open source vision a reality. So let's wrap up. So today I have talked about ORAN and their goal to support non real time apps for service management and orchestration in an open run environment. Together with the service management and orchestration functions, non real time RIC applications or RAPs will enhance open run management assurance and optimization capabilities. Supporting openness, standardization and multivenderness in a harmonized and consistent way will drive innovation in both apps and platforms. Therefore Ericsson is committed to both standardization and open source contributions to support this vision. We will continue to improve SMO, non real time RIC and RAP capabilities in own up and OSC driving forward innovation via open interfaces. Thank you.