rApps & xApps: Unlocking Open RAN’s Potential
In the first instalment in our series of interviews with rAPP and xAPP developers, we spoke with Marcin Dryjański, CEO of Rimedo Labs, a spin-off from the Institute of Radiocommunications at Poland’s Poznan University of Technology. Rimedo Labs specializes in providing high-quality consulting, implementation, and R&D services for Open RAN, 5G, and 6G. Currently, Rimedo Labs focuses on delivering customized xApps and rApps for O-RAN’s RAN Intelligent Controllers.
In the rapidly evolving landscape of Open RAN networks, rApps and xApps are emerging as key enablers for optimizing network performance, improving energy efficiency, addressing critical security challenges, and much more. These applications, designed to run on RAN Intelligent Controllers (RICs), offer network operators the ability to implement granular, real-time adjustments and innovations to unlock the full potential of Open RAN.
From Traffic Steering and QoS management to energy-saving solutions like RF channel reconfiguration, xApps and rApps are not just tools – they’re transformative agents that help operators navigate the complexities of 5G Open RAN. In doing so they can also help operators create compelling new value propositions all while enhancing user experiences and reducing operational costs.
However, their development and deployment are not without challenges, including the need to continuously improve the standardised interfaces that make all this work possible, interoperability across platforms, and access to real-world network data for validation and AI/ML training. We started by asking Marcin about the work he’s led at Rimedo to date in developing these kinds of solutions.
ODIN: What xApps/rApps have you developed and can you name some of the technology partners you’ve been working with?
Marcin Dryjański: Among the xApps we’ve developed are the Traffic Steering xApp, QoS-based Resource Allocator xApp, Beam Mobility Management xApp, Jamming Detection xApp, and Signaling Storm Detection xApp. On the rApp side, we focus on energy efficiency and traffic management, with solutions like the Energy Saving rApp: Cell On/Off Switching, Energy Saving rApp: RF Channel Reconfiguration, and Traffic Management rApp.
In this field, namely integration, testing and development, we’ve been working with the Open Networking Foundation’s Aether (now part of the Linux Foundation), Juniper Networks, VMware by Broadcom, Keysight Technologies, Accelleran, Viavi Solutions, AWS and Tietoevry.
ODIN: Which xApps/rApps do you think offer the most exciting potential for Open RAN?
Marcin Dryjański: While TS-xApp can offer improvement of QoS in networks, e.g., better utilization of radio resources, or user-to-cell association based on their QoS profile, the most exciting potential in our opinion is in the xApps that aims for Massive MIMO optimization that is now being introduced into the mobile networks, e.g., dynamic selection of beams (Beam Mobility Management xApp), or RF Channel Reconfiguration to scale antenna array according to current network conditions like the number of users, their throughput demands etc.
RAN security is another exciting area, where accessing the RAN data and measurements can be used for both detection and mitigation of security threats at the radio level, e.g., signaling storms can be blocked at the stage of RAN to protect core network resources.
ODIN: How do you rate the maturity of RIC as a technology and platform for innovation? What still needs to be improved? Are the APIs good enough?
Marcin Dryjański: The RIC platforms are quite mature and allow for a variety of control and report actions. The bigger problem is that commercial platforms are slightly behind the specification process, which is of course reasonable, but limits the opportunity to test some of the ideas. On the other hand implementation of some features in the RAN is critical for the whole Open RAN concept.
Another challenge we face as developers is the fact that different RIC platforms all have different feature sets (e.g. Conflict mitigation, interface support, RIC databases, ASN.1 decoders) along with the different APIs/SDKs/Programming languages used.
The dream of xApp/rApp developers would be to have a standardized interface between RIC and xApp, so the process of integration would be fully platform-independent. At this stage, the different RICs have different maturity levels and use different approaches to SDK/API.
ODIN: How would you rate O-RAN specifications for E2, O1, R1, and A1 in terms of their usability for building xApps and rApps? What would you improve or change?
Marcin Dryjański: E2 – is well specified, the issue is rather on the RAN side (i.e. the E2 Nodes) to implement features from technical specifications (e.g., not all E2 Nodes support all the service models or parameters within a service model)
O1 – is in general, in a good shape being the base interface for app development.
R1 – is a very good concept with an idea of standardized API. However, at this moment it is not fully specified, e.g., Configuration Management and Fault Management are specified, while other important aspects of performance management and network information are not yet fully specified. But the direction of development is promising.
A1 – is specified pretty well. However, the major drawback we encountered in some of our activities, or projects is that it is helping one direction: from Non-RT RIC to Near-RT RIC. Some applications, like hierarchical traffic steering or energy saving, would require more detailed information sent from xApp to rApp. On the other hand, some general-purpose containers would be beneficial to create more customized policies. Moreover, the A1-ML is not yet specified.
ODIN: Do you have access to live network data for your AI/ML training?
Marcin Dryjański: We do have access to some network data, but it is strictly limited by commercial agreements or NDAs for certain projects. We think that there is a need for creating open repositories of test data that could be used by xApp-rApp vendors to compare their algorithms at the early stage of their development.
ODIN: How portable are your apps to different RIC platforms?
Marcin Dryjański: The algorithms themselves support exchange between platforms. Unfortunately, the different RIC platforms utilize different APIs and are written using various architectures and programming languages. Thus, to port an xApp from one RIC to another requires somewhat development effort. The approach we take here is that the app’s heart is the core of the algorithm while depending on the platform on which it should be ported, we develop its surroundings to support the interfaces and SDK/API.
This approach, also helps us to “move” the algorithm to the RIC it is needed. I.e. we are not binding the algorithm to the “RIC level”. An example here may be an energy-saving feature for cell on-off switching, which could be packed as an xApp (for faster adaptability) utilizing E2 interface with CCC service model, or as an rApp (for wider scope) utilizing the O1 interface.
ODIN: How do you resolve conflicts between RIC apps?
Marcin Dryjański: To date, all our integrations with commercial platforms were supporting use cases where xApps/rApps were not conflicting (e.g., ES-rApp with TS-xApp, or TM-rApp with TS-xApp). However, conflict mitigation is one of the research topics we are actively working on both “in-house” and with our customers.
ODIN: Do you need to test and validate your apps in different labs?
Marcin Dryjański: Yes, this is what we are aiming at. It is beneficial to us to test our solutions under real RAN, or RIC testers based on the real-world data from Network Operators, as it was done, e.g., during the NTIA RIC forum activity. The main reason is to verify the apps within the environments with O-RAN-compliant interfaces and harden the solutions. Secondly, on a less technical side, the open T&I labs allow us to expose our solutions and prove their workings to the wider community.
ODIN: What are some of the most interesting developments in the xApp/rApp space we should look out for over the next year or so?
Marcin Dryjański: In our opinion, the most interesting development would be aimed at the Massive MIMO technology, as it offers additional degrees of freedom by adding a space dimension to radio resource management. From this perspective, there is a big potential for developing dedicated solutions by xApp/rApp vendors. The second area we would envision is network security. Accessing the per UE/cell KPIs so xApp/rApps can detect and mitigate security threats such as jamming, or signalling storms at the early stage of the RAN. The visibility along with the ML framework plays a crucial role here.
ODIN: Do we need both near-RT and non-RT RICs, what unique value has been exposed over E2 to make near-RT RIC a must-have, and what use cases need near-RT RIC?
Marcin Dryjański: Some use cases require gathering information at low latency, e.g., security applications (sample being signalling storm detection, or jamming detection) or beam-level management. On the other hand, traffic steering from the Non-RT RIC perspective is limited, only to setting cell-level parameters. In the Near-RT RIC, the flexibility is much bigger, e.g., one can decide on an individual UE handover, set policy per group of UEs, QoS flow, and network slice in a timely fashion.
Moreover, the E2 interface allows capturing metrics per individual UEs, e.g. measurement reports, utilized PRBs. Finally, the frequent reporting period enables fast reaction for the changing network conditions, e.g., for cell on/off switching over the O1 interface it might take even a few minutes for an rApp to get a notification about the cell load, on the other hand, Near-RT RIC can observe cell load in the scale of tens of ms, and react relatively fast, e.g., turn on cell immediately after overload is observed (even if the process of cell activation still takes some time in order of seconds or minutes.)
Next week we’ll be speaking with the Singapore University of Technology & Design about their exciting work on rApps
