 Hello, I'm Magnus Burgard from Ericsson. I will talk about closed control loop. The introduction of 5G mobile networks calls for drastically increased automation in the management of networks and services. The expectations on high service flexibility in combination with the ability to serve new categories of customers require a dynamic infrastructure and continuous re-disposition. And here's where the closed loops come in. Closed loops are key enablers for automation that have been successfully used in many industries for long and more recently for computing and networking applications. Examples of use cases are to minimize energy consumption or to maximize service output. What is then a closed loop? It is a control mechanism that uses feedback signals to monitor and regulate itself with the objective of achieving a specific goal. And what is then closed loop automation? It's the combination of automated processes with a closed feedback loop. In management systems, the process that chains management services, data, analytics, policy, orchestration, etc. Autonomous systems that constantly monitor and assess the network and take corrective actions when the goals are not met. So ultimately, it is about reducing human intervention but still allow interactions with operators for goals, definition and monitoring performance. A closed loop automation can self-monitor, self-evaluate, self-heal and fulfill all specific requirements. And typically, there will be many closed loops in an automation system. Consequently, the interest for closed control loops has increased and is now in focus in several SDOs. The 3G-PPSI-5 enhanced closed loop SLS assurance. The SCC-SM recently published closed loop automation part 1 enablers and as well as in open source projects like OWNUP. A promising prospect is to add an intent-based interface to the closed control loop in order to serve new types of applications. I will come back to that. Here is a functional view as depicted in SCC-SM 9-1, shows the different stages in a closed loop and let me go through that. The data collected by the collection stage from the managed entity is aggregated and sent to the analysis stage, which is responsible for deriving the right insights about the current status of the environment under control. The analysis stage considers the current and historical data combined with the knowledge and it tries to assess if the goals of the closed loop are met. If the goals are not met, it makes a diagnosis on the reasons. The insights from the analysis stage are fed to the decision stage, which is responsible for finding the solution that makes the control loop meet its goals and create plans for the necessary actions that need to be taken. The generated plans are technology agnostic, usually in forms of workflows. Therefore, they are sent to the execution stage to be translated into actions according to the context and the technology employed in the managed entity. The outcome from the execution is absurd after new data is collected and the gap between the current and expected states is evaluated again. The knowledge in the closed loop has the main purpose of storing and retrieving data, including context and experiences, that can be shared between the different stages, as well as between different closed loops. Knowledge can also be used as a means of feedback singling between the closed loop stages. In the SZZM 9-1 specification, there is also information about closed loop coordination. It's a set of capability that allows multiple closed loops running within the SZM framework, in this case, to be coordinated in runtime. The main objective is to improve the performance and the fulfillment of the closed loop goals. Focus on conflict detection and mitigation, pre-action and post-action coordination, a delegation and escalation of goals, like in the hierarchical closed loop case here on the right, or information sharing between multiple closed loops. And the example here is the peer closed loops. The closed loop life cycle management is worked on in Onup. A closed loop is designed here in this area and the definition in Tosca is sent to the runtime environment and executed by the closed loop participants here at the bottom. Examples of these closed loop participants are database, Kubernetes ecosystem, policy framework controllers, and service orchestration. Since control loop is a key concept for automation assurance use cases, it is a priority for Onup as an automation platform. POCS have been progressed in Onup, released G and H in this area, and the closed loop life cycle management redesign has reached a relevant, viable set of features. And it is ready to be moved in release I to mainstream as part of the policy framework. The release I release is coming later this fall. The solution supports deployment and orchestration of automation and control loop use cases across CNFs, VNFs, and PNFs in a model driven way, and thereby simplifies the network management. It will enable operators and service providers to manage the life cycle of a network service. And now I will continue to talk about the concept of intent in combination with closed loop. Let me start to describe some of the general properties of intent. An intent goal is declarative, leaving its implementation open. It's an expression of utility. It's requiring a satisfactory outcome rather than a specific outcome. It is infrastructure agnostic and portable, not device nor infrastructure specific. Handles user expectation, contracts and changing requirements, but decoupled from variations in the underlying infrastructure. It makes intent portable across vendors and implementations, etc. It's composable and additive. Multiple intents may be given to the autonomous system independently, and the system is expected to consider them together. It's complete and exhaustive, describing all expectations comprehensively. And if a requirement or concern is not described by intent, it is not recognized as required or relevant. It's persistent. It stays valid until it's actively removed by its owner. It is a knowledge object with actively managed life cycle. Here is a picture from 3GPP on intent that contain two closed loops. One on the top between the intent owner, the management service consumer, and the intent handler, the management service producer, to handle the intent setting, negotiation and reporting, and one underlying control loop like I have described before. But the intent-driven management make use of a closed loop to continuously monitor whether an intent is fulfilled. There is also a lot of intent-related closed loop work in TM Forum, and also in Etsy CSM. Here is a figure from TM Forum showing the use of multiple closed loops for intent-driven management. And that concludes my presentation. Thank you very much for your attention.