 Good morning. Good afternoon. Good evening, everyone. This is Lingli from China Mobile. Wherever you are, I hope you are well and stay well. Thank you for attending this online presentation. For the next few minutes, I would like to share with you the mobile vision and practice to enable autonomous networks with open source platform, including ONEP. And the content is mainly focused on two parts. For the first part, I would like to tell you that what we believe autonomous networks would be, why open source platforms would help in enabling them, and how. Starting from what? During the last year, there has been a lot of efforts from various skills, industry online services, and major companies to call for promotions of autonomous networks. As you can see from this page, a series of white papers, what items have been published or under development, just specified what autonomous networks are and how to classify the corresponding autonomy levels. Among them, a white paper of autonomous networks published by 10 foreign in May 2019 represents the typical industry consensus, as we believe, which will be leveraged in our further analysis here to provide you the basic background. To summarize, the 10 foreign white paper includes four parts. In addition to a series of autonomous levels and a collection of use cases, it also provides a hierarchical architecture and a methodology. It is proposed to prioritize the use cases for deployment from business drivers, technology maturity and coverage scale consideration. To better explain why open source has a role in enabling autonomous networks, we have to take a closer look at its content to understand the remaining open issues behind it. The first perspective we take is from the autonomous levels. As you can see from this diagram, the goal for network autonomy is defined in two dimensions. Scenario specific functional requirements is the vertical axis and scenario coverage is the horizontal axis. It is hence straightforward to envision a two stage upgrade approach from level zero to level five, in which the first stage is focused on improving the functional requirements in selected scenarios, while the second stage is targeted to scale promotion and deployment to cover all scenarios. But is that all? We see there are two remaining open issues. First, from the coverage perspective, how to make the least from the next scenarios in state one. If all the solutions, all the implementations or interfaces are developed in a back to back fashion to a common architecture to address all scenarios in state two. And that brings us to our second question. So, from the functional perspective, is it possible to introduce common components in the earlier stage and scale their deployment later, which would avoid fragmentation of first flight and ensure convergence to ease scale adoption later. And the second perspective is from the hierarchical architecture. Well, it is recommended to evolve resource management in the bottom into autonomous domains as the basis for network and business automation on the top. In other words, autonomous domains assume more close trust relationship and further dedication from network operators or service providers to device vendors, which might not be applicable to network operators who run their own network operation for efficiency for multi vendor business. Or just due to local regulation reasons. Meanwhile, the one way linear dependency from network and business layers to autonomous domains in the bottom also raises risks for uncertainty and complexity. To summarize our analysis, in addition to the open issues identified regarding to network autonomous levels and hierarchical architecture for prioritization methodology, which is directly applied to each use case. It is also difficult to retrieve convergence or identify common interest among network operators or service providers. Who are different in types of businesses are running. And who are also different in the geographical areas. They're operating and there are different types of use cases priorities, because they're serving different types of customers. And last but not least, without a generalized approach, it is not clear how to enable use cases, new use cases, I mean, in a sustainable and future proof manner. Now it is time for us to review what we think on how open source would help in solving these issues. In a nutshell, we believe that open source would be of help in. Firstly, setting up a common functional architecture and identifying a group of common ID building blocks in the earliest stage. And secondly, refining the hierarchical architecture or layering architecture and helping the industry converge to cross layer interfaces from various domains, various operators and certainly providing a future proof. Way forward in automating a devop loop and providing the basic tooling for open autonomous network application, certification, testing, deployment. First of all, for guys who are already familiar with owner functional requirement in these use cases so far, it is not surprising to figure out that through the unified abstraction, the uniformed way of data collection, control and management. The common functional requirement architecture and standard interfaces can be formed among various autonomous network use cases from different domains or scenarios. The diagram. And the left shows a preliminary analysis bias for the functional blocks of different autonomous levels in the first stage of the path. And the table on the right shows the mapping between this functional blocks and relevant SDOs who are currently working on their specifications, as well as open source communities working on their implementation. Due to the existence of the vision general functional architecture. And it opens with community reference implementation. It is recommended that in the early stage of network autonomy. All operators should join their heads in properly involved and designing a general functional platform architecture standardizes external interaction interfaces and internal functional modularity. And further refer to other open source communities for sharing the advanced latest technology, which would be more helpful for us to moving forward to the realization of large scale promotion of functional modules or current capabilities. And also ensure interoperable with cross layer and cross vendor scenarios. And ultimately helping us in achieving the long term cross industrial convergence goal. Our second observation is that at present, the industry actually do have two typical autonomy level target positioning ideas for network elements. The recommendations from the TM forum white paper indicates that the upper layer autonomy is completely dependent on the bottom layer autonomous domains. Which means the interfaces and business logic and corresponding coordination mechanisms within the existing upper layer must be adapted accordingly after the bottom layer changes. Which is under the assumption that the network operator fully trust and delegate their operational responsibilities of autonomous network elements to its vendors who are writing the software. And assumption of trust and linear dependency makes the development cycle. A quite long and the adoption at all. For the other side standard organizations and open source communities such as Iran assumes. Autonomous level two for the network elements layer and the other layer would be responsible for further implement higher autonomy and coordination as required. Despite the fact that in this case, the operation and maintenance maximum layer can build common function while enhancing the existing data and control interfaces of the network elements. Thus, with the potential of shortening the cycle retrieving the final goal. The fact is the standard and related projects maturity is rather low. As the traditional device manufacturers are not actively involved in this option and the targeted scenarios are currently rather limited to rural deployment and not addressing massive scale deployment. A potentially third option that might be provided by onette with these existing use cases is that network element layer provides additional analysis of applications and device specific knowledge. Well, the life cycle management of these analysis applications and the integration of knowledge of different vendors could be implemented by the operating support system providing a common infrastructure. Which could help the potential to pull together the expertise from both sides and provide a few future proof way. The new application use cases. So the network operators kicking off their price or attributing network autonomy. It is therefore recommended to taking into consideration from factors like the actual deployment requirements of the company. Clearly identify their preferred way of collaboration with their partners. Whether they choose autonomous devices white boxes devices or collaborative devices. It is important to specify the goal of layered collaboration interfaces in different stages along the way in different, you know, choices. It will be extremely helpful for them to make decisions and make and keep the pace of moving forward to open industrial collaboration platform like LFN by promoting the standard organization and opens your community to formulate and verify related interfaces, processes, and join hands for accelerate innovation, verify the implementation and training the talent as needed. The third expectation is that the difficulty of introducing DevOps for different autonomous elements or applications vary if we take different options as mentioned above. For autonomous device option, horizontal evaluation for a single network element vendor is currently challenging due to the lack of cross organizational continuous integration and continuous deployment tool train or corresponding management processes. And horizontal evaluation for multiple vendors targeting at a specific scenario is also facing the challenge due to the lack of poorly specified and well recognized benchmarking standards for collaborative devices. It is yet needed to consider the complexity of multi vendor coordination between network element vendors and the platform vendor who might have independent release cadence and need to conduct pairing testing, which means the synchronization iterative triggering of multiple components from different vendors, for example, applications, knowledge, and devices. And for wide box devices option, which is the most challenging one because the network element vendor and application vendor would form a multiple to multiple relation in this case when coordinating and conducting pairing testing. And it is hence recommended to accelerate the development of both use case specific, magic definitions and benchmarking standards as well as building a general DevOps automating tooling and cross organizational management process. To quick summarize, to address the above mentioned remaining open issues for network autonomy, we are envisioning a three stage part for network operators to achieve the ultimate goal of poor network autonomy, which is to do functional enhancement for specific high priority cases at the beginning, ditch end to end cases later, and to revive industrial convergence for the best in the end, during which the real key differentiator to ensure the success in the last stage is to build and verify a common architecture across different autonomy levels, standardize cross layer interfaces, and drive SDO alignment in the earlier stages. In particular, to leverage existing open industrial platforms to explore, converge and verify cross layer interfaces, which would be later used in both evaluate majority from open source communities and majority from related standards. Last but not least, to drive magic and benchmarking standard development for known use cases and build general DevOps tooling and processes for our new use cases to come in the future. With the previous vision in mind, China Mobile has been working on relevant aspects in Linux Foundation networking. In particular, we believe that the following three subgroups are of particular interest in our proposed way forward. EU AG to do requirement mining for strategy convergence from network operators. ONEP or other technical projects to build a reference implementation for common functional architecture, and OVP to provide DevOps tooling, benchmarking and certification procedure for network autonomy solutions. For the first part, a network operator survey is being composed inside EU AG to solicit network automation and autonomy status requirements and strategy with the hope to reach a converged version and service input to corresponding technical groups. For the second part, the objective is to build an open source reference set for the common architecture, which would serve two voted purposes. First, to provide a common context and guide telecom communication professional standards organization to unify the problem description and requirements definition of different application scenarios, hence promoting inter-industrial convergence. Second, to reduce the field knowledge barrier for other IT industry experts or open source communities to participate in this innovation and migration parts for network autonomy, hence promoting cross-industrial convergence. In order to do that, we need first analyze the general architecture requirements corresponding to autonomous network classification standards and their open source community mapping. Next, typical cross-domain application scenarios and guide the open source community to complete the reference implementation prototype verification of the general architecture. Third, promote telecommunication standard organizations to unify their core data collection analysis service, close to policies, and turn model definition based on a common architecture. And we believe with the complementary open source networks as well as open source AI platform, ONEP would provide the basis for constructing such open source reference set for autonomous network. And since these earlier releases, ONEP has been building and enhancing its use cases for self-organization network, the autonomous network cases for radio access network domain. And with the development of 3GPP specification, we're also working with TIB Open Core Network Projector, which has planned to use ONEP as its illustrator for later releases to further extend its go with core network autonomous network cases like UPL collection with extensions to ONEP. Full standardization after the S5 work item on data collection integration, we have been lately working on policy management use cases, standard analysis and comparison with the purpose of understanding their specific requirements, if any, with the common closed-loop architecture provided by ONEP. And there is the demo of this common architecture with ONEP and other complementary components which is being showed online during this event. For the OVP part, the objective is to support the construction of the inter-organizational DevOps standard system and the development of open source tools for software-based networks and network autonomy applications. The good news is that we have already a very good basis from the existing VNF Autonomic automated testing framework and a well-established and practice certification process from the LFN community. But the bad news is that we're still lacking a clearly specified and well-established way to do cross-organizational CI, CT, CD. And still remaining the most challenging part is the benchmarking for network autonomy applications devalued social solutions because there's none open data or standard metric or benchmarking definition. Well, we believe the benchmarking part requires more SDO efforts with field knowledge from city experts. We started already in building a preliminary demo of CI, CT, CD with ONEP, which is being showed during this event too. To conclude, let me first do a quick recap. We talked about industrial phenomenon of network autonomy, analyze these remaining issues, and discuss how open source platforms can help in solving these issues, followed by a brief introduction to some of our ongoing work in relevant through. And I would like to conclude this presentation with a call for action. As a famous Chinese saying goes, one person works fast while a group of people work much further. We from China Mobile are firm believers in industrial collaboration, and it is always our dearest hope to go further with all of our fellow members and contributors in this community along the parts from network automation to network autonomy. And you know how to reach us. Thank you for your attention.