 Welcome everyone, this is the Open Networking and Edge Summit session on network management challenges in the new world of Open RAN. I'm David Kinsey from AT&T. I am Ting Lu from Ericsson. Today in this presentation, we'll give you an overview of the new network management framework as defined in the ORAN Alliance. In this presentation, Ting and I will present the network management architecture definition in ORAN. We'll talk about the challenges of deploying the new network management framework from an operator's perspective. And I will talk about the challenges in building a new network management system from an OSS vendor's perspective. We'll begin with the description of the network management architecture definition in ORAN. ORAN Alliance was created in 2018 by AT&T, China Mobile, Deutsche Telekom, NTT DoCoMo, and Orange. Since then, ORAN Alliance has become a worldwide community of mobile network operators, vendors, research and academic institutions operating in the radio access or RAM industry. ORAN Alliance's mission is to reshape the RAM industry towards more intelligent, open, virtualized, and fully interoperable mobile networks. The new ORAN standards will enable a more competitive and vibrant RAM supplier ecosystem with faster innovation to improve user experience. ORAN-based mobile networks will at the same time improve the efficiency of RAM deployments as well as operations by the mobile operators. Today's topic will focus on the network management functions for RAM. It is called the Service Management and Orchestration Framework, or SMO, in ORAN. We'll talk about this new architecture, explain the new standard interfaces to the RAM network, and the challenges the operators and RAM vendors will face in the new world of open RAM. Another benefit of the SMO is its external interfaces to utilize non-RAM data to further improve and optimize the RAM network. Now let's look at what's new in the ORAN management architecture. We start with the traditional physical RAM. There are many management functions such as EMS, DSON, CSON, service delivery, service assurance, design, and inventory functions. If we classify them based on the execution time required, some are near real-time control functions with millisecond execution time, and others will be non-real-time management functions that take seconds or even minutes to execute. The near real-time systems are normally provided by the network vendors, and the non-real-time management systems are usually provided by OSS vendors or network vendors. With ORAN evolution, the physical RAM elements are disaggregated into ORU, ODU, and OCU, as virtualized functions with open interfaces between them. A near real-time radio-intelligent controller, near real-time rig, is created as the runtime environment to host the near real-time control applications called X-Apps. Similarly, in the higher-layer management plane, it is SMO. In keeping with the disaggregated ORAN concept, the traditional OSS functions are decomposed into SMO platform and modular software applications called R-Apps for the actual management, such as F-Caps and CSON, usually takes a bit longer than the control functions. Where a new set of application management functions are introduced, as well as the non-real-time radio-intelligent controller, non-real-time rig, sitting inside of the SMO as the runtime execution environment for the R-Apps. So now you can see there are two key differences between the O and the new world of ORAN. First is separation of the management platform, SMO and rig, versus the applications, X-Apps and R-Apps. Second is separation of near real-time control applications, the X-Apps, versus the non-real-time management applications, the R-Apps. And ORAN is the entity to define the standard open interfaces between all the elements in this architecture. Here we want to talk about the standard and open source organizations that are influencing the new RAM management architecture. First is ORAN Alliance. However, ORAN Alliance's focus is mainly in the RAM. It views the network management from a bottom-up angle, essentially to create open interfaces for the network management systems to connect to, including R1 interface in the non-real-time rig to support R-Apps, the O1-A1 interfaces for RAM, F-Caps and O2 for cloud orchestration and management. The actual service management and orchestration functions are largely left for other network management open source communities to address, such as ONAP and OSM. Here using ONAP as an example, it takes the management top-down view for end-to-end customer and user experience, operations functions and processes, service delivery orchestration, service assurance and analytics, and the common data messaging and integration infrastructure as platform services. So far we have had a lot of cross-pollination between ORAN and ONAP. In recent releases, ORAN software community, OSC and ONAP are collaborating in open source software development as deployable SMO modules. Now we're going to examine the new network management challenges from an operator's perspective. The SMO architecture in ORAN has three dominant aspects. These are the non-RT RIC, which allows extensibility with the concept of onboarded R-Apps. The primary RAM management interface is through the O1 interface and the cloud management through the O2 interface. The open radio unit or ORU has its own F-Caps interface, which the SMO connects to when managing ORUs in a hybrid mode. This interface is called the front-haul in-plane. The front-haul in-plane interface is expected to be included in the next release of ORAN architecture description, which should be publicly available in February 2022. To achieve portability, the R-Apps adhere to a standard R1 interface. Additionally, the non-RT RIC provides the logical termination of the A1 interface, which is used to provide policies to the near real-time RIC and send it enrichment or non-RAN data when needed. Many of the working groups use different terms for similar SMO roles or functionality. These are not intended to be interpreted as architectural components but functional roles that the SMO exhibits. Since the SMO internal interfaces beyond the R1 are not yet specified by ORAN, most messages between the roles are depicted as comments rather than messages in interaction diagrams. Working Group 1 has taken the action to coordinate across all the work groups to identify and define the common roles, which over time all work groups should adopt. This is expected to be publicly available in February 2022. AT&T's vision of the SMO is basically a three-layered architecture focusing on network integration, extensibility through applications, and a third common platform layer to integrate the application layer and the network layer. The network integration layer provides integration to both the network and the cloud, providing a single point of control for conflict remediation to a device and providing the scale required for telemetry collection. This allows the application layer to be agnostic to the network access mechanisms. Since the SMO is the collector for both 01 and 02 data, the SMO has the responsibility to correlate the telemetry in order to determine if errant behavior in an application may have been caused by activity within the cloud or vice versa. In the SMO architecture, there is no EMS as a component or external system. It is expected that the EMS applications are to be refactored over time into cloud-native microservices and deployed in the SMO application layer. All applications are dependent on and shared data with other applications. Therefore, all applications need ubiquitous access to data. In the SMO integration layer, an open interface for common data management should exist. This removes data ownership from the application layer, forcing it to adopt a data-centric approach to data management. The applications over time are expected to become more intelligent by leveraging AIML tools and techniques. The SMO integration layer should natively support the training, testing, and monitoring aspects of AIML-enabled applications. Some of the services provided by the SMO and the services provided by applications are expected to be exposed to external OSS and BSS systems. This should be a simple task where the exposed open API is registered within the SMO, which then allows external OSS BSS, other management functions such as slice management and or external APIs to be made available outside the corporate environment. AT&T has identified several key challenges it has experienced in prior EMS and NMS implementations. These have been translated into successful attributes of a commercial SMO enlisted at the bottom of the slide. Although AT&T's initial focus will be on the RAN, through the introduction of the SMO as O-RAN elements are introduced to the network, we do believe that it should actually support both the network core and transport functions as well. The SMO must be able to support Brownfield and Greenfield appointments. Therefore, the SMO must be able to register and discover existing clouds, CNFs, and PNFs. Discovery of existing CNFs is a particularly hard problem since metadata onboarded or retained in the SMO as part of onboarding and lifecycle management are not stored in the cloud. Some EMS functions might not conform to the restrictions of the R1 interface, but should still easily integrate into the SMO, presumably through an open API. How to address that interface gap is an ongoing discussion within AT&T. Other challenges identified on the slide are numbered on the left. Those numbers are then placed on the architecture diagram to the right where the challenge is met with the strategy. For example, item three closed platforms are solved with an extensible architecture leveraging the R1 standard API for easy integration and extensibility of the SMO capability. This final slide provides additional detail on the attributes of a commercial SMO mentioned on the previous slide. AT&T reviews SMO candidates against these objectives and its evaluation. Some of these are more internal to AT&T, such as the reduction of technical debt. Others are to minimize acquisition costs such as leveraging open source where possible. Since the only sure thing of technology is that it will change, the hardest to develop is future readiness. To combat this, AT&T is looking to focus more on the services provided by a tool rather than the tool itself. Now let's look at the many challenges in building an SMO from an OSS vendor's perspective. To provide an SMO as a product, a vendor must have a strategy to support multiple targets on all fronts, including applications, RAN networks, cloud infrastructures, and operators environments. We can summarize all the key challenges in one slide. Then we will go into a bit more details in the subsequent slides. So first, let's look at on the left. Support multi vendor applications. This is to allow any third party provided Rapps onboarded to SMO and the SMO deploys them to run in non real-time rig, which is enabled by a standard set of runtime APIs. Support multi vendor RAN network. Any vendors O-RAN compliant network functions can be onboarded to SMO and managed by the Rapps through the standard interfaces. Moving to the right, it is the multi cloud deployment where the RAN network functions, the Xapps, Rapps, and SMO platform itself are all to be deployed into the cloud native environment. Depending on the operators, it can be private or any of the hyperscalers public cloud. On the top is that SMO must be able to integrate into multiple operators environment where every operator would have their own unique operations processes and systems. For SMO system vendor, this could be most challenging because SMO as a product must be built with componentization in mind with open interfaces to fit into any operator's OSS framework. So in the next section of concerns, here we are going to talk about the SMO platform versus applications and how cloud native technology is enabling the CI CD process. If we start with the application development. For a vendor, the existing large monolithic OSS such as traditional EMS for F caps management and song system for automation are decomposed into cloud native microservices. Step two, the RAN vendors applications, as well as third party developed applications may be published and verified via a marketplace where non real-time rig management APIs are exposed for developers to build O-RAN non real-time rig compatible Rapps. Step three, SMO cloud native orchestrator deploys both ran network functions and Rapps Xapps to manage the network functions. Step four, SMO cloud native orchestrator continuously deploy software updates to both ran network functions and the management applications. The O-RAN Alliance objective is for RAN vendors to come together and agree on a set of standard interfaces. So the new cloud native RAN can be managed under a single SMO platform. However, now all operators have green field RAN deployment. For most of the operators, they will need solution to support Brownfield with legacy RAN currently under the management of vendors EMS. So from a vendor's perspective, to provide a single pane of glass user experience is important for the customers. The vendor can provide this seamless experience with adaptation to the legacy RAN, including the capabilities for auto discovery and F-CAPs management through vendors EMS. The deployment model of SMO may dictate what SMO functionalities to be included and where they are deployed. An operator with smaller footprint may only need one SMO instance, while a larger operator may need a distributed hierarchical model where a central node and multiple local nodes subtending to the higher layer management are deployed. For the distributed hierarchical model on the right side of the diagram, each SMO node at different level may be responsible for certain functions, but not all of the functions. Here was a three tier example. The central node, which can be SMO or existing OSS is responsible for application onboarding and end-to-end service management. The regional SMO is responsible for application distribution and regional analytics, whereas the local SMO nodes provide non-real-time rig to run RAPs, AIML training and fine-tuning with local data feed, and to provide faster and granular control loops closest to the network. Lastly, I'd like to talk about the flexibility for SMO componentize the deployment and integration. The operator most likely have their own BSS OSS in place today. With a new implementation like SMO, it needs to be flexible to fit into operators existing OSS BSS framework. Here is an example that integration with operator systems to reduce the overlapping functionalities. So from an SMO provider's perspective, the challenges is not only to offer flexible product packaging for deployment, but also perhaps as a system integrator to offer a customized integration service. This concludes the video recording of the presentation. We now go live with the Q&A session.