 Hi everyone, this is Lin Meng from China Mobile. Thank you very much for joining this session. In this session, I will mainly talk about the requirements of network slice management, our open source practice in LFN or NAP community, and the roadmap of network slice intelligence. 3GPP has defined what is a network slice. A network slice is a logical network that provides specific network capabilities and network characteristics. This is also one of the key features of 5G. The essence of network slicing is to be able to effectively cater to a diverse set of use case categories and customers in an optimal manner. 3GPP also defined slice management functions at three different levels. CSMF is responsible for translating the communication service related requirements to the network slice related requirements. It is also responsible to communicate with the network slice management function, the NSMF. NSMF is responsible for the management and orchestration of NSI. It derives the network slice subnet related requirements from the network slice related requirements. It also communicates with the NSSMS and CSMF. NSSMS is responsible for management and orchestration of NSSI. It is domain specific. So we have cleared up the key requirements of the network slice management here. Firstly, the demand of a slice is customized. It undertakes the QoF and QoE of different customers and the vertical industries, including the connected home, autonomous vehicles, smart cities, remote healthcare, and so on. Each of these categories have a different set of performance requirements like the latency, the throughput, reliability, and availability. They also have different set of characteristics like the mobility and resource sharing level. So talking about the resource sharing level, the resources at the NSSI and NSI level could be shared in an optimal manner and shape the network dynamically to meet the demands of various services. The resource of slices should be shared and the slice is logically isolated. The different cans of network services should be designed, configured, implemented, and managed in an automated manner. It should be virtualized and cloud deployment. The slice orchestration functionality is actually enabled for the network automation and should play an important role in the quick service rollout. The network slice management should also be easy to use. It should also be definable and extensible. So the most convinced way is to align with the standard, both in modeling aspects or the interfaces. For the real deployment, the operators have different preferences. For example, they may choose a third-party NSSIMF or an independent developed NSSIMF. So the solution we provided should be loosely coupled building blocks that could provide the flexibility for various deployment scenarios. The network intelligence should also be taken into consideration from business level to operation level to the network elements. Our final goal is to realize the autonomous network in which we could provide the intent-based service management and self-excapabilities such as self-optimization and self-hailing. The open network automation platform actually satisfies all the above demands. So considering all of these aspects, China Mobile, together with lots of active members in ONAB community such as Vipro and Huawei, initiate this very complex use case, the E2E network slicing use case in ONAB. And in total, we have 15 active companies around the whole world participating in this use case. And nine companies among them have made code contribution in the past releases. The overall objectives of this use case are firstly to implement the ONAB-based slice management functions defined by 3GPP, the three-layer management functionalities. And we also want to demonstrate the E2E slice design instantiation and operation including RAM, core, and transport slice subnet. Thirdly, we also want to provide the flexibility, the flexible architecture choices to operators for deployment scenario if they could choose an ONAB-based XMF or to choose a third-party XMF. This page depicts the specific standards name we have referenced and implemented in this use case. So back to this page. As you can see that the interaction between say SMS and the OSS and BSS system is aligned with TMS standard. The interaction between say SMS and N-SMS as well as the interaction between an SMS and RAM and SSMF as well as the core and SSMF is aligned with 3GPP standard. For transport interaction, the connection between the N-SMS and the transport and SSMF is aligned with IETF TSAI model and the whole closed-loop framework is actually aligned with ETSI DSM framework. Also from the south bond of RAM and SSMF, the interaction between RAM and SSMF with RAM domain is also aligned with O-RAM community. I will skip this page. For the current status of E2E network slicing use case, if we look from the architecture point of view, in Frankfurt release which started almost two years ago, we have implemented the say SMS and N-SMS within O-NAP also connect to an external core and SSMF. And then in its second release which is queuing release based on Frankfurt deliveries, we have provided the O-NAP-based RAM and SSMF O-NAP-based transport and SSMF and O-NAP-based core and SSMF. We also provided the choice to connect to an external RAM and SSMF. So you can see that after these two releases, we have provided the basic structure of the three-layer O-NAP-based slice management functions. And starting from this year which is the Honolulu release and Beyond releases, our focus is on the enhancement of the existing functions and the extension of the closed loop scenarios. If we look from the NSI Lifecycle Management point of view, in Frankfurt and Guilin release, our scope focused on the preparation, commissioning and decommissioning system. The focus area for Honolulu release and Beyond release is the operations stage which we mainly focus on the closed loop scenarios. This page describes the closed loop structure as O-NAP. And you can see that the word in bracketed, the name of the O-NAP modules playing the respective roles of a closed loop. We leverage the song framework within O-NAP to provide a general closed loop framework. The closed loop framework within O-NAP is composed of building blocks such as data collection and analysis, optimization, coordination and decision and then the action. Actually, as you may all know that the closed loop framework could be used to realize the intelligent, to realize many intelligent slicing scenarios such as the slice KPI monitoring, the KPI guarantee and the SLA guarantee. And I will also talk more later in this presentation. For the current status of closed loop functionalities, what we have done are the basic life cycle management of a slice including the design, creation, activation, deactivation and termination. We also have provided the basic process of the NST selection and NSI and NSSI selection, which actually are used in many stages of NSI life cycle. For example, during the creation phase and for modification, we both could use the NSI or NSSI selection. And it is started in Frankfurt release and from Guilin release we have focused support more complex scenario in the NSI and NSSI selection by introducing more parameters. The PM and FM data collection is also what we have done, which is a basic process to support the further KPI calculation and the slice analysis. And then in Guilin release, we have started the structure building of the slice analysis microservice and the KPI calculation microservice as well as the network capability report. And these two microservice actually we have finished the basic structure in DCAE module and the enhancement will be continued in the following releases. So as we talk about that in the requirement page, that our final goal is to provide an autonomous network and we believe that the intent-based network is in such pattern. So we also explore the end-to-end and Iran core transport subnet slicing based on intent which could provide capabilities such as self-instantiation, dynamic adoption, self-prediction, root cause identification and self-hailing and so on. And if we map to the NSI lifecycle management, the intent-based network slice instantiation and lifecycle management should be provided. For example, in commissioning phase, the instantiation or reuse of appropriate slice could be based on self-learning and the closed-loop automation should have the advanced capabilities such as machine learning-based prediction, root cause identification and self-adaptation. If we look into the standards definition such as 3DPP and TMS, the intent is the formal specification of all the expectations including the requirements, goals and constraints. It expresses the expectations that need to be fulfilled without paying attention to how to realize them. The ONAP community also has started the exploration of intent-based network framework since last year and there has been lots of discussion in the community about how to position the IBM framework. And one of the ideal solutions could be defining a general intent process system within ONAP. The user intent from the North Bund will be converted to the general intent and go into the intent-process system. The intent-processing system will then realize the functionalities described in the left box by interacting with the existing ONAP modules and then to convert the general intent to other system intent and also interact with other systems and intent systems. In the end of this presentation, we also provide a network-slice intelligence roadmap and of course some of them may go in parallel. Actually, we have started the first step, the second step and the final step in parallel which is researched and hold by other teams. And for runtime monitoring, as I have said, we actually have explored the KPI monitoring functions to evaluate the KPI fulfillment in real-time predict and analysis using the AI method. For a close-loop update, we actually now could support some simple scenario in randomness to adjust or update the resource configuration of the slice subnet in a close-loop way. And the third step in our blueprint is to... Actually, it is in the commissioning states to determine the initial resource assignment and configuration for a new slice by intelligent analysis. Based on SLA requirement, I believe this functionality could be fulfilled after our KPI communication computation microservice and the slice analysis microservice supporting more fundamental functionalities. And the SLA guarantee is actually our goal of the slice management. No matter whether we introduce an intent-driven solution, our goal for the slice is actually to guarantee the slice SLA to guarantee the slice SLA fulfillment of the tenants and then to dynamically adjust the service capabilities of the network slices by using the optimal resources. And for the intent-driven solution, which is also our final goal of the network slice intelligence, as I have said, this has been explored in parallel. And I believe that this is not only good for network slicing, it could also be used in many other scenarios to use the intent to describe the expectation of a slice service to express the expectation of the customer and ignore the technical details. So that's all for today's session. And thank you very much for listening. Thank you very much for your time. Bye.