 Hello, and welcome to Ericsson's virtual demo on non-real-time ran intelligent controller-based quality of experience modification. Let me start by sharing our vision for the Open RAN. We believe in an open and desegregated world where the networks offer more than open interfaces. The network must be robust and simple to deploy, orchestrate, and manage. It also needs to secure evolution and adaptability for future use cases when anything can be a device. Only a comprehensive orchestration solution with a non-real-time ran intelligent controller across radio, transport, and core domains can secure service quality assurance at the device level, anywhere and at any time. Ericsson is fully committed to creating a future-proof orchestration architecture. Our ambitions are to enable network service quality assurance at a greater granularity level than that of today at the device level, to ensure that the network monitors the service quality and adapts the quality of experience or QoE target to guarantee desired performance, and to address today's applications and public spaces that are adaptable for new use cases, devices, and private networks. Let me now describe the difference between today's management versus the future orchestration based on the non-real-time ran intelligent controller, which shall henceforth be called non-real-time RIC. As shown in the left side, using today's management paradigm, the service quality assurance is achieved at the slice level. The QoE can be changed based on a request from the consumer that starts at the operation and support system, or OSS, proceeds to the core network, and then to the radio access network or ran. Let me explain this a bit more. The consumer can request a QoE change to the operator OSS. The operator OSS triggers the ran to change the QoE via the core network, for example by changing the corresponding QCI, that's QOS Class Identifier, or the 5QI, that's 5G QOS Identifier. While this works fine, it does have the following limitations. First, the core network cannot perform per UE assurance and QoE optimization based on ran conditions. And second, the core network is not aware if a change in the QoE has given the expected effect to the service quality. Now, let's look at the right side that shows the non-real-time RIC based future orchestration. Here, the service quality assurance is achieved at the device level. The QoE targets are set by the core network. Based on these targets, QoE optimization is done autonomously by applications within the non-real-time RIC, also known as R-Apps, that aim to achieve service assurance. The non-real-time RIC can initiate QoE changes towards the ran for this purpose. The non-real-time RIC applications, or R-Apps, monitor UE service quality and decide when and how to perform a temporary QoE change in a fully automated manner. In addition, the non-real-time RIC continuously monitors the ran to ensure that the QoE modification results in the desired service quality for the UE. Let me list the key benefits of non-real-time RIC based orchestration. First, it provides a greater level of granularity where the non-real-time RIC acts on the need of the devices. Second, the non-real-time RIC is aware of the expected quality and results achieved. And finally, the operators are now able to use non-ran data and a wider ran scope, for example, outside a genode B to influence the QoE of the devices. Here, we illustrate the reference scenario for our demo. First, it is assumed that the network operator has deployed a network slice for mobile broadband and one high priority network slice for first responders. The two slices have different quality of experience targets as shown in the graph at the bottom. The first responder slice has a higher quality of experience target compared to the mobile broadband slice. This implies that the ran will prioritize first responders over mobile broadband users. Second, it is assumed that a large fire is ongoing and some first responders are on duty in the area. Each first responder is streaming a live video. The ran treats the first responders with high priority so that they observe better quality of experience compared to the mobile broadband users. Third, a special R app in the non-real-time RIC is designed to provide service assurance for first responders. The R app monitors the location of each responder and the quality of experience of its video. The R app is also aware of the fire location through enrichment information collected by the Service Management and Orchestration, or SMO. Finally, one of the first responders is closest to the fire location but it has worse quality of experience compared to the other first responders. The ran has no information on which first responder to prioritize because it is not aware of the location of the fire. As long as the quality of experience target is fulfilled, the ran does not take any corrective actions. Here, we describe how the non-real-time RIC can be used to improve service assurance in the described scenario. The R app decides to act for improving the quality of experience of the first responder in the best location. This is illustrated here as step one. To achieve the QoE improvement, the R app provides a new policy to the ran over the A1 interface indicating to the ran to increase the priority for the selected user. This is illustrated as step two. The ran, including near real-time RIC, OCUCP and ODU, modify the priority and update the scheduling policies. This is illustrated as step three. As a result, the quality of experience of the video from the first responder closest to the fire is increased. This is illustrated as step four. This demo focuses on step two, meaning that it aims to show how to create a new policy using the A1 interface. To demonstrate the concept, we will briefly show some work we have contributed to the O ran software community, or OSC. This includes an A1 controller function and an A1 policy management service. The A1 controller function terminates and mediates the A1 interface connection from the ran to the service management and orchestration layer. The A1 policy management service maintains a view of all A1 policies across the ran and allows us to view, create and manage these A1 policies in a simple and intuitive manner. A sample graphical control plane UI allows us to visualize and manipulate these policies. But of course, in many cases, more sophisticated automated processes running in a non-real-time RIC would manipulate policies in a much more dynamic and intelligent way. We show a brief demo of how you can manually view, modify and create, and delete A1 policies in the ran. We will first open the A1 policy control in the OSC non-RT RIC control panel from the SMO portal. Here we see some sample A1 policy types supported in the ran. The policy types shown depend on the capabilities of the underlying ran functions as exposed over the A1 interface. Each policy type can have many policy instances, each with different scopes or targeted towards different ran functions. Let us first consider the policy type for fine-grained tuning of QoS priorities to affect QoE for appropriate UEs. We can view an existing policy instance by clicking on it. For these QoS policies, each policy has a scope selector to target a specific QoS ID, or QCI, or a 5QI, and a specific identified UE. We also see a value for the QoS priority for this QoS UE pair. A JSON representation of the new policy object can be seen at the bottom. Also at the bottom, we can view the JSON schema used to both define the format for the A1 policy instance objects, which is also used to populate this interface, and to validate the policy's contents. At the very top, we can also see that this policy instance is addressed to the ran function GNB G1-2. We have just shown you how to view the A1 policy types and instances in the ran as shown here. At this stage, we can manually edit the policy instance to decrease the priority level for the particular UE QoS ID pairing. We submit the policy using the Submit button, which updates the policy in the ran node over the appropriate A1 interface connection. Here, we briefly show the audit logs from the A1 controller function, showing the A1 REST operation has been performed with the modified A1 policy, addressed to the appropriate ran function. We can also create a new policy instance by clicking on the Create Instance icon. We first set the scope filter for a specific UE ID and for QoS ID 4, then set the preferred priority level to 22 for that UE QoS class pair. We then select which ran function we would like to deploy this new policy instance to. Once the values are validated according to the policy type's model, the policy is ready for deployment using the Submit button. Note that the new policy instance now has a new, automatically assigned globally unique policy ID associated with it, as can be seen in the top title bar. You have just seen how to modify or create the A1 policy instances in the ran as shown here. As you might expect, policy instances can be manually deleted by clicking on the Delete Instance icon for a specific policy instance. In this case, we delete the policy deployed to node GNB G14. The green pop-up notification shows us that the delete operation completed and the policy instance is now removed from the list of policies in the Control Panel. We can again see from the logs that the delete operation was achieved using the appropriate REST delete operation over the A1 interface addressed to the appropriate ran function. Now, we've also shown how to delete the A1 policy instances in the ran as shown here. This completes our brief demo of how to manually manipulate A1 policies using the A1 interface via the non-real-time RIC A1 controller. Of course, to reiterate, many A1 policy management operations will likely be performed automatically and continuously by appropriate non-real-time RIC applications or services. Usually informed by changes in network and subscriber context or requirements, as would be the case for the scenario we introduced previously. This presentation has demonstrated how non-real-time RIC can make intent-driven and fine-grained updates to the ran to optimize for a specific emergency services scenario. Non-real-time RIC enhances radio resources management capabilities and addresses a new set of use cases for ran optimization and automation. Ericsson will continue to improve non-real-time RIC capabilities and drive the innovation via open-r app structure in the future.