 Hello, my name is Doref Cicci. I'm the project technical lead of the O1SC near real-time week sub-project. And I will present first, or the first part of this lessons run session, focusing on the near real-time week platform. After this, Mati Hiltonin, who is the project technical lead of the O1SC XSAP project will take over. And he will talk about the open source XSAPs and related use cases. Let's take a quick look at the agenda. So here, the first part that I will be talking about, I will be talking about learnings from simulation and trials, and using the near real-time week platform. I give one example of such a learning and how it led to a design change that we are implementing. And then I will find advice with an overview of changes in our implementation that we do in order to support E2AP version 1.1 and then the upcoming E2AP version 2.0. Mati will talk about the XSAP project and the XSAP community. He presents what we did in the DVDs in terms of use cases and what we are doing in the second half of this year and scope of the E-release. He presents two example XSAPs, the unlimited detection XSAP and the bouncer XSAP. And then he will present his thoughts on the XSAP API. And finally, his view on near real-time week trials. Okay. So in this first slide, I talk a bit about simulations. I think there are two types of simulations or three types of simulations. One is simulating protocol in our case with the near real-time week. It's the E2 protocol that is the focus of the near real-time week. So this is typically covered with protocol, compliance test tools. Then we have simulation where we need a load testing. We cover this with a bouncer XSAP. And then we have network simulation. And this slide is about network simulation that we did on our site. We're using a simulation tool that we also use in our projects. In this case, put here a link to a YouTube video where you can take a look at how the simulator is used in a project called Planner, where we do radio link failure prediction and then based on this, we optimize beam patterns. We use the same simulator and the simulator generally works so that you feed it network deployment, for instance, and over related thresholds like A3 and A4, you feed a city data and the radio propagation model into it. Based on this, it can calculate the coverage map. I put an example here on the upper right-hand side just to see to visualize this a bit. You feed you equal configuration and then also a mobility model of this release. And then that's a bit of a specialty with this simulator. It allows you, makes it programmable. We are a general purpose co-simulator interface, simple TCP-JSON interface. And we use that to extend the simulator to provide functionality that we then need when XSAPs modify the behavior of the run. The output of the simulator is generated data, which we can use for machine learning training and inference. It also gives updated UE position. It gives channel condition indicators like RSR, PN, SINR. It provides calculated KPIs about the cell and UE group KPIs. And one of the things of this is important is accelerated execution. So that you don't have to wait for the results as you have live trials. On the left-hand side here in the upper side, I put a picture. How we deploy this. Interesting is that we didn't actually interface the simulator via E2. And we were able to do this because in the XSAP that we implement, we have an E2 mediator layer. That on the south side speaks E2. But then on the north side to the so-called use case XSAPs that implement things like traffic steering, we have different interface, one based on rest here for controlling. And then a simple time series interface, in this case influx for transferring, for instance, counter information in metrics to the XSAPs. The interface is then used instead of E2. We basically placed this kind of adapter here that then talks to the simulator and that's whatever the XSAP wants the simulator to do. And it also provides the information back to the near real-time week in terms of metrics so that the XSAPs can actually calculate and apply machine learning models. So far we did this only with Horistics but we do have already now the availability to generate machine learning data and then we'll apply the machine learning models on this simulator data. And a couple of other XSAPs in addition to the traffic steering that I mentioned that we have in the pipeline for testing here. The other way how to learn is obviously by trialing. And I put here a quick summary of trial that we did related to traffic steering. Traffic steering is defined by the O-Runa lines as the so-called use case number five. It improves spectrum efficiency, capacity of network, it balances cell load, basic traffic steering mechanisms. What we did in these trials is that we implemented two use case XSAPs or groups of XSAPs that work together. One we call Advanced Traffic Steering, ATS and another one we call Area Optimizer. What we then did, and that's the whole idea of the year that you can quickly experiment with new XSAPs with new machine learning models. We did short trials about four to five weeks and certainly there is room for optimization where we do deployment, data collection and then XSAP execution. And the first sub-trial we focus on data collection and the second sub-trial you see here already the Advanced Traffic Steering. XSAP was using AI ML models and for this we had to connect, to collect data into a separate ML training and data lake and then do the training there and forward the models back into the near real time rig. On the AO side, similar things were done but in addition, there's connected mode load balancing and in sub-trial two, we focused on heuristics. So sub-trial three is then doing connected mode load balancing for the ATS and then on the AO side, we add a ML functionality. Another peculiarity is that for the trial we split the available number of G-Node Bs into two groups and then one of those groups was allocated to AO and the other one to ATS. Obviously the other option is to split by time so that one week you run the AO and then the other week you run the other XSAP and then compare the results. Anyway, what did we learn from these simulations and trials? This is summarized in this rather boring slide. So over on the C side, on the open source public side, what we learned is we need to implement a command line interface for troubleshooting. There's a multitude of interfaces available but they become unusable because of their sheer number. So a wrapper is needed. We are implementing this in the current release during the second half of this year. It for instance helps with finding the reason why the port was ever created and ever created. We also need interfaces for using existing sources of information. So for instance, we have an interface that allows feeding the list of E2 nodes and then also some configuration for those E2 nodes we are arrest directly into the E2 manager. This is instead of receiving this information over E2 connections. One interesting and I have an extra slide for that in terms of robustness, we also figured out that an optimization that we originally thought we can do from the beginning doesn't really work well. So we will change the subscription deletion in case of E2 disconnect when the SDP connection disappears and appears again. We also notice when data is delayed too much. This is about as bad as the data stream broken. So the least we can do for this case is waiting alarm if he notices and then a couple of fixes in the Rick message routing library that we found we need to do. Debugging capabilities again is one thing that we need to do as well. We also, I think, showed that the E2AP concept and procedures as well as the idea of XSAP works in practice. That's a feedback to the Oran Alliance. And I think if you look at Nokia learnings, we figured out that trials are and simulations both of them we can quickly try new algorithms, new AI ML models, but also heuristic based models. When we train AI ML data, we need to do the training typically at operator side and we need well-defined interface for this. I think we also showed that the near with like near with number of vendors, operators and also for practice can improve from performance. What we figured out is I mentioned this earlier. Stability and robustness improvements are important. I think an obvious improvement is handling microservices. We starts independently something that I think is obvious to many, but we still have some way to go there. And certainly we got further ideas on how to improve the traffic steering algorithm. I already mentioned that we changed something related to subscription handling in case of E2 disconnect. And this is actually interesting in the red part here where we have a normal disconnect of an E2 node. We normally will now notify this to the subscription manager. You see here notifications and to the XSAPs. And when we do so, we expect the subscription manager to automatically delete the subscriptions of that E2 node and also for the XSAP to adapt. And then when the XSAP is notified that the E2 node has connected again, then it has to re-issue subscriptions previously. We did it so that these subscriptions didn't have to be re-issued and that clearly led to problems in case of re-starts and other problem situations. We also think that we need some kind of timer solution described here in the green part but I'm not going there to explain this further in this presentation. So if we move on, this is my last slide and then I can hand over to Matti. This presents what we are doing in terms of implementation in the E-release to adapt to E2 AP version 1.1. That's an existing release of the E2 protocol. And then what is coming in E2 AP version 2.0 that we then have to eventually adapt to in the F-release in the next year or after the F-release. I think an important improvement in the ORAN Alliance is actually the definition of a new license, the standard collaboration copyright license which allows us in open source projects to use. Code-like parts of specifications like ASN1 or young definitions and compile them and use them directly in the open source projects. And this is important when we now upgrade to E2 AP version 1.1. Yes, it actually is a precondition for the release. What else do we change? We adapt to E2 AP version 1.1's E2 node configuration update change. This is a way how E2 nodes, the GNode B, informs about configuration information that it has about the run to the near real-time rig. We also implement support for object IDs. This is needed on the near real-time rig tool for XSubs to identify the E2 service model that the particular run function, the functionality that the E2 node supports provides. Then what we have for the next release is E2 AP transport network layer. We now need to see there's need for E2 scalability and high availability. This was still one of the three features that were defined in E2 AP version 1.1 compared to 1.0. 2.0, the upcoming 2.0 provides new procedure that works together with the existing makes subscription delete procedure. That's the subscription delete required procedure with the E2 node, for instance, overloaded against then initiate this procedure. E2 AP version 2.0 also improves description of what to do with weak control acknowledgement and weak control failures. Sorry. And we haven't implemented this on near real-time rig side. So getting this clarification early makes this possible to implement. Then there are a couple of backwards incompatible changes. One is adding a transaction ID into all global procedures, all of them marked with an asterisk here on the right-hand side. And then two backwards incompatible changes related to E2 node component configuration IE's. They now reuse existing setup request response and configuration update messages defined by 3GVP. They reuse those by reference. And then finally, one change is the mandatory inclusion of E2 node component configuration as well as run functionless into the E2 setup request. Previously, this was optional. And it being mandatory means we have to add at least one entry in this E2 setup request for those two lists. With that, I end my part of the presentation and I'm still available in the chat for, and now it's Magistern to talk about the RIG-XAP project. Thank you, Thorolff. I'll be talking about the RIG-XAP project and its latest status. So the mission of the RIG-XAP project is to implement open-source XAPs for the OSC RIG platform. The RIG project was started at the same time as the RIG-XAP project. So we've been going hand in hand. And of course, since we started implementing XAPs before any of the standards were finalized or the RIG APIs or the architecture, it has meant that the XAPs have needed to change. But this fact that we've been working together, I think has helped both the RIG and the XAPs evolve. So for example, when we implemented a number of XAPs and we kind of see what the pain points are, what common functionality is required in all the XAPs, we can move some of that functionality as a part of the RIG platform as part of the SDK. And the fact that we have been implementing a lot of different XAPs by different parties and using different service models has ensured that the RIG platform itself stays E2SM agnostic. Some of the XAPs that we have implemented in the RIG-XAP project would be classified as demo XAPs. These are Hello World XAPs in C++ Go and Python that demonstrate how all the different features provided by the RIG platform can be utilized by the XAPs. For example, how the XAP makes an E2 subscription or how the XAP reads the E2 information from the RNIP. The other set of XAPs are the use case XAPs where we are actually implementing traffic steering and anomaly detection use cases using combination of XAPs from different companies. And I'll be talking about these use cases in a little bit. But more recently, we are starting to explore more advanced ideas like, for example, using geo-location, network slicing, and the new E2SM RC. And while these XAPs in the open source are generally fairly simple, the best ideas could evolve into commercial versions in the future. We have been building the community around the RIG gap slowly released by release. In the first AMBA release, we had two contributing companies, AT&T and Samsung, and we had four XAPs. But over the releases, we have been adding contributors, HCL joined in the C release. And in the D release, we had China Mobile and a academic collaborator from Brazil joining. And in the E release, we are hoping Mavenir will join and implement an XAP for the RIG gap project. In addition to the XAP contributors, Viavi has been working closely with us since they are providing a simulator that supports the traffic steering and anomaly detection use cases. We requested some statements from the community to state how they view the RIG gap project and XAP project in general. Samsung is highlighting the AI ML aspect and highlighting that RIG will achieve proactive closed loop automation and optimization. HCL is also highlighting AI ML, but they also pointing out that this technology will enable new use cases to the point possible before. And finally, our academic collaborator is finding this a very good opportunity to work with real world problems and collaborate with leading businesses in 5G technology. So I would recommend this definitely for academic folks who are interested in this area. So let me talk about the D release use case. We were implementing a UE level handover control use case with data collection, machine learning, and prediction. In this use case, we use the KPI Mon XAP that uses KPM service model to collect data from the E2 simulator from Viavi. KPI Mon populates the information in time series database that is then consumed by the XAPs. The AD XAP anomaly detection detects UE level anomalies in throughput or signal strength and notifies the traffic steering XAP which then requests a prediction for what would be the throughput of the UE if it was handed over to a neighboring cell. And based on this prediction, traffic steering XAP will request the simulator for a handover. Unfortunately, in the D release, we were only able to integrate the AD QP and TS XAP and the influx database. So the integration with the KPI Mon and E2 simulator will be done in release E. So in release E, in addition to the integration, we are adding a couple of new XAPs and more information. The load prediction XAP that was officially part of release D will be now fully featured with the machine learning trend model and will populate predictions for cell load in the influx DB. And the MAPnir RC XAP will implement subset of the E2 SM RC that allows the request for UE handover to be communicated to the simulator. And it will also collect some additional information UE level measurements that are not available through the KPM service model. And finally, we are exploring the use of geolocation information. We are populating that in the influx DB directly from the simulator, but in the future, this could be implemented by an XAP that uses the measurements from the RAN and estimates the UE location. So the idea is that we are looking at how anomaly detection through prediction and traffic steering could be smarter with the geolocation information. So just to take a look at some of these machine learning XAPs, we basically have the ADQP and LP in the release that are machine learning based. These XAPs have a number of components. Some of them are data processing that are fixed components, but then there's a machine learning model that is trained offline and that can be updated in the XAP that is basically used to make the prediction or detection. In the current version, the training happens offline first and then we deploy the XAP, but in the future, when all the OSC and O-RAN technology and standards evolve, we can update the model on the fly. And the technique that we currently use in the ADXSAP is isolation for us, but the different XAPs use different machine learning models. Let me then talk about the Bouncer XAP. It's a little different and Thorov mentioned it. It started as part of the RIC platform work as a way to benchmark the RIC platform, but it is really an XAP and recently it was moved into the RICAP project. The Bouncer XAP acts like a regular XAP in the sense that it starts up, it reads the RNIP for the available E2 nodes and then it issues subscriptions using our own service model, Hello World Service model to the E2 nodes that are connected to the RIC. And then after the E2 nodes start reporting measurements and events, the Bouncer XAP issues a control message. So there's a control loop where a report message triggers a control message. And the simulator can measure the time between the report message and the matching control message and as a result can measure the control loop latency in the RIC. So with this Bouncer XAP together with the E2 simulator, we can profile many aspects of the RIC platform. For example, how many E2 nodes can connect to one RIC instance? How many E2 subscriptions can be supported? Of course, what is the control loop latency? What is the RIC throughput? And in general, this will help us identify what the performance bottlenecks are. For example, do we need to add more memory or CPU for the E2T for example, or are some protocols causing the bottleneck or are some libraries taking too long? So this will definitely be helpful in making the RIC even more scalable. And of course, the target is that this profiling tool, both the Bouncer XAP and the E2 simulator could be used to profile any RIC implementation. So of course, in order to be able to profile different implementations, we have to be able to port the Bouncer XAP to the different RICs. And I think Oran, Alliance and OSC in part have been very successful in creating this new market segment of RIC platforms. A number of companies in open source projects are working on implementing RIC platforms. And now from the XAP writer's point of view, the problem becomes, well, which RIC platform should I write my XAPs for? To alleviate this problem, Oran working group three is working on standardizing RIC API. And this would, if the RIC platform implements the standard API and the XAP uses the standard API, then the XAP would be portable from one RIC to another. The alternatives being explored are the SDK based approach and network API based approach. The SDK based approach would be similar to like Android SDK or iOS SDK, where the SDK provides a set of methods that the XAP can use. And there may be multiple implementations for the SDK, but from the XAP point of view, the methods are always the same. And in order to move a XAP from one RIC platform to another, all you need to do is link the XAP with the write SDK library. The network API based approach standardizes the protocol and encoding of the messages exchanged between the RIC platform and the XAP. For example, the standard might say that you use REST and JSON payload or SCTB and ASM1 payload to communicate certain messages like E2 or A1 between the XAP and the RIC platform. The considerations for the different alternatives and of course these alternatives can be, both of these could be standardized. The SDK approach allows different RIC implementations to use different protocols underneath. And also that would allow them to differentiate. For example, if one RIC platform comes up with the faster way of communicating, the XAPs could still be portable. And if the SDK approach also supports future proofing in the sense that the implementation can be updated without modifying the XAPs. The other aspect is simplicity for the programmers. Every RIC will likely provide some type of SDK. And of course the different SDKs may be simpler or harder than others. But they will likely be an SDK regardless. And if we do not standardize it, then there will be different look and feel on different RIC platforms. But finally, the language support in the OSC RIC we support C++, Python and Go. But do we need more? And of course, if the standard is defined on the SDK level, we need to define it for all the supported languages. And finally, Thoreau mentioned the trials. So we have been doing some trials with RIC and XAPs in AT&T's networks. The trials started from initially do no harm trials where we connected the RIC to production genoed bees and enoed bees in a listen only mode and used the measurements and data collected to provide analytics and fine-grained KPIs. But we have gotten to the point of actually controlling the enoed bees and genoed bees. The use cases are implemented as combinations of XAPs from AT&T and Nokia. So this abstract picture kind of shows different companies, XAPs interacting through messaging and through the database in FluxDB. So the idea is really to combine and put together XAPs from multiple companies. In this case, AT&T and Nokia to create these use cases. We are using pre-E2 interfaces where E2 is not available, but we are using a lot of times in XAP, for example, this XAP-E here, maybe using a pre-E2 interface, but it's providing a high-level interface for the high-level XAPs. And later on, this XAP-E implementation could be using E2 without these high-level XAPs needing to be modified. Openness of the technology is crucial for the success of the RIC. So it has to support third-party XAPs. And in this case, AT&T is essentially acting as a third party. And related to openness, the fact that you can run an XAP on a platform is not sufficient. It's also important that the information that is populated in the platform and the interfaces provided by XAPs to other XAPs are public or at least shared information with the other parties who are implementing XAPs. So in this case, the AT&T XAPs utilize the same interfaces as the Nokia XAPs. The goals of these trials are to evaluate the RIC technology and identify areas for improvement, like Thorov already mentioned. And it's also a starting point to evaluating the business cases. For example, how much benefit can we achieve by doing traffic steering in the RIC? And of course, gaining operational familiarity and comfort. It's putting the RIC into the RAN is a big step for the operators. And actually our operators have been very supportive of this effort. So that concludes my presentation. Thank you for your attention. And if you want to participate on this RIC and RICAP project, there's a link in this presentation, there's information there on how to reach out and how to help. Thank you very much.