Why managing conflict between rApps is vital for RAN automation at scale

Ongoing increases in mobile network size, sophistication and heterogeneity mean that Intelligent RAN Automation is becoming essential for today’s Communications Service Providers (CSPs). Recognizing this necessity, the O-RAN Alliance introduces the concept of “rApps” as a novel solution to deliver RAN automation capabilities.

rApps are software applications that act on so-called “higher-level” control loops, with a response time of seconds and above. Intelligent automation using rApps has the potential to revolutionize the world of network management and orchestration, augmenting or replacing existing manual processes to improve network performance and reduce costs. rApps automate at scale on a network level, leveraging rich data and AI/ML to automate a wide variety of use cases. Automated network healing and outage compensation, performance anomaly detection, network optimization, energy saving and configuration validation are among the many use cases that can be automated using rApps.

The O-RAN Alliance has defined the service management and orchestration (SMO) framework as a key function within the O-RAN architecture. The SMO offers capabilities to orchestrate the deployment of network functions into the open cloud infrastructure and perform fault, configuration, performance and security management for them, while the non-real-time RAN Intelligent Controller (non-RT RIC), a sub-function of the SMO, offers capabilities to enable the implementation of intelligent RAN automation and optimization use cases. The SMO and Non-RT RIC together provide a multi-vendor platform that enables enhanced RAN management and automation via rApps, as shown in Figure 1 below.

Figure 1: Overview of rApps deployed on the O-RAN Alliance SMO/Non-RT RIC

You can learn more about rApps in previous blogs at rApps – your best bet for innovation in 5G networks and How the O-RAN Alliance R1 interface empowers a global RAN automation community.

How do conflicts arise between rApps?

Let’s say that a CSP has deployed an SMO and now wants to deploy some rApps that will bring valuable automation into their network. Meanwhile, both in-house and third-party developers have been busy creating new and innovative rApps to solve those annoying or complicated tasks once and for all. With all this diverse innovation across a global rApp developer community, it’s easy to see how some of those rApps, when deployed on the same SMO/Non-RT RIC, could start to work at cross-purposes.

Let’s take a simple example to show how this could happen. Suppose one rApp developer discovers a way to improve cell coverage by making AI/ML-based adjustments to power levels or antenna tilts across the network to minimize those grey spots. However, little do they know that in parallel another rApp developer has built an rApp that optimizes cell capacity in dense urban areas during peak times by changing the same power and tilt parameters! This is a typical example of how rApps with different goals can conflict with one another. We summarize the trade-offs in our example in Figure 2 below. There are other similar examples, such as an rApp that focuses on energy savings conflicting with an rApp that wants to maximize coverage or capacity.

Figure 2: Examples of differing rApp goals that require trade-offs and conflict management.

So, can our CSP use these new rApps? Or if they do, will they just degrade the network performance without the CSP knowing why? Will we end up with a “ping-pong” effect where one rApp keeps up-tilting the antenna while another keeps down-tilting the same antenna?

The above simple examples are just the tip of the iceberg. In a highly automated network, fueled by a vibrant rApp developer eco-system and the automation capabilities of the SMO, rApp conflicts will become more frequent. Read on to find out more about how we can address this.

How can we manage conflicts between rApps?

As the ‘host’ of the automation rApps, it’s natural for the SMO/Non-RT RIC to take the lead in rApp conflict management. In Figure 3 below we show an overview of how the SMO/Non-RT RIC framework can support a range of conflict management functionality, from relatively basic to highly intelligent.

Figure 3: A growing scale of rApp conflict management functionality in the Non-RT RIC/SMO framework

As Figure 3 shows, there’s a sliding scale in terms of Non-RT RIC/SMO support for rApp conflict management. We have divided this into three high-level categories, starting with the relatively basic enablers, evolving towards more advanced policy-based conflict management, and ultimately managing conflicts as part of a broader “intent-based” network management approach. There are of course multiple steps within each of these three categories. We discuss them in some more detail below.

Conflict Management Basics

We need a solid foundation upon which we can build our conflict management support. We need to provide in-depth visibility (‘audit trail’) of the behavior of rApps – in other words, close monitoring of what rApps did, when they did it, and towards what part of the network. We can then use this information to help identify when there are conflicts, such as two rApps changing the same parameter within a short time-frame. By using ‘access control’ features of the security infrastructure administrators can also restrict parts of the network which can be modified by a given rApp; this helps to prevent accidental conflicts.

When rApps are deployed, they need to be working towards the right parts of the network, avoiding accidental or unintended overlaps. A comprehensive but simplified view of the network topology, coupled with rApp scoping controls, can allow rApps to quickly find what they need, while allowing operations staff to ensure they are correctly scoped and stay out of each other’s way as much as possible.

When rApps are onboarded to the SMO/Non-RT RIC framework, the rApp software package can declare the rApp data & API dependencies – the network data that the rApp reads and writes, the key performance indicators that it works on, and so on. Not only does this mean that the rApp gets exactly the data it needs, as efficiently as possible, but also that the SMO/Non-RT RIC can alert the administrator if two rApps are going to consume the same KPIs or modify the same configuration parameters, a potential conflict scenario!

Policy-based rApp conflict management

Now that we understand the basics, we can start to discuss how to evolve towards more advanced rApp conflict management. We first describe policy-based conflict detection and avoidance, and then explore more sophisticated arbitration and prioritization capability between rApps.

Conflict Management needs to be clever, because there are a broad range of conditions and scenarios that need to be considered. We believe that a policy-based solution is an ideal candidate to meet these needs.

Policies give us a flexible and configurable way to control how rApps conflicts are managed by the SMO/Non-RT RIC framework. They allow conflict management criteria and logic to be configured dynamically at run-time, without the need to change any of the SMO/Non-RT RIC or rApp software. This means that CSPs can easily change the conflict management policies in response to changes in rApp priorities, the deployment of new rApps, or the identification of new conflicts that need to be managed.

To enable this flexibility, the SMO/Non-RT RIC can provide a “policy mechanism” that executes the conflict management decision-making “policies” at the appropriate times. For example, when an rApp requests an update to the network configuration the platform may execute a policy to check if there are any conflicts and how they should be handled. We illustrate this approach in Figure 4 below, using our simple example of Coverage and Capacity rApps from earlier in the blog. The ‘Capacity’ rApp wants to optimize cell capacity by down-tilting an antenna, but in parallel the ‘Coverage’ rApp wants to maximize cell coverage by up-tilting the same antenna. Without conflict management support, we risk finding ourselves in a “ping-pong” situation where the two rApps keep up-tilting and down-tilting the antenna.

Figure 4: Policy-based solution for rApp conflict management

1. rApp administrator configures conflict management policies

2. Cell Capacity rApp requests antenna down-tilt) via Network Configuration Manager (NCM)

3. NCM requests conflict evaluation from policy engine. Result is ok, so NCM updates network

4. Cell Coverage rApp request antenna up-tilt via NCM

5. NCMP requests conflict evaluation. result is not ok. NCM rejects the change

So what would these conflict management policies look like? Let’s consider an example, again using our ‘Coverage’ and ‘Capacity’ example. A very simple policy may specify that:
-“When an rApp changes the antenna tilt, don’t allow any other rApp to change the tilt within a configurable time period.”

The above policy is very straight-forward, but what if the Coverage rApp got there first and now we don’t have enough capacity in the cell during a busy hour? An improvement is to specify that:
-“When an rApp changes the antenna tilt, only allow higher priority rApps to also change the tilt within a configurable time period after the original change.”

This allows the service provider to give the Capacity rApp a higher priority, so it can over-ride the changes made by the lower priority Coverage rApp. There are lots of further enhancements that could be added to the policy; for example, the policy logic could vary at different times of the day (office/weekend hours), for different parts of the network (urban/rural), for different traffic patterns, for sporting/cultural events versus ‘normal’ times, and so on.

With the policy approach we can have even more intelligence in how we arbitrate and co-ordinate between rApps. In our earlier example, we accepted the proposed network updates from the Capacity rApp, but rejected the changes proposed by the Coverage rApp. That “Accept/Reject” approach will be fine in some cases, but in others we will need to be more subtle. For example, our policy may specify that:
-“When any rApp requests a change to the antenna tilt, allow the change but ensure that Capacity rApps are treated with higher priority than Coverage rApps.”

The platform could then ensure that the change coming from the Capacity rApp is applied to the network as a high priority update, while the Coverage rApp change must wait at the back of the CM change queue. The platform could also arbitrate between the two rApps by controlling how ’aggressive’ they can be in up-tilting or down-tilting the antenna, based on the policy contents (this assumes that the rApps expose the ability for their behavior to be tuned in this manner). In our example, the higher priority Capacity rApp would be allowed to be more aggressive than the lower priority Coverage rApp, ensuring that the cell is tuned to provide good capacity while also providing acceptable coverage.

The above examples highlight the importance of the SMO providing CSPs with full visibility of the behavior of both the rApps and of the conflict management mechanism that the SMO provides. This includes the ability to view what actions the rApps requested and the outcome of the policy-based decision on how to handle those actions. For example, the SMO might record that “At 10:03 rApp “Cell Coverage” was prevented from updating cell 123 as rApp “Cell Capacity” updated that cell at 09:54”.

Finally, a further benefit of a policy-based approach is that we can use it to inject other decision logic into our rApp control flows, for scenarios other than conflict handling. For example, a policy could specify that rApps are prevented from updating the network during maintenance windows, or it could provide specialized logic to guide the platform on how to prioritize incoming CM changes.

AI/ML-based conflict detection and intent-based network management

As we’ve seen, a policy-based approach gives us powerful support for managing rApp conflicts. However, it requires a human user to figure out how rApps may conflict and to define a policy to instruct the system on how to manage those situations. But what happens if the human user isn’t aware of all the various ways that rApps can affect each other and the network? To solve this problem, we can use machine learning to discover relationships between the changes that multiple rApps make to the network and their impacts on network performance. We can highlight these relationships to the system administrator, who can then use those insights to identify any misbehaving or conflicting rApps and update their conflict management policy accordingly. This offers an intelligent way to discover conflicts between rApps that were unknown to human users.

The final stage in our conflict management evolution is based on “intent-based management”. The Conflict Management approaches discussed so far are missing some important details about the conflicting rApps; what are they trying to achieve? what is their goal or “intent”? This is where Intent Based Management can help.

Our simple conflict example in this blog involved two rApps that had conflicting business goals (capacity versus coverage), with the need for the SMO/Non-RT RIC framework to arbitrate between the actions of those rApps based on human user input provided by a Policy. This scenario begins to touch on the concept of intent-based network management, where the focus is on allowing users to input their requirements and wanted behavior, while the system then figures out how best to support that behavior. A truly autonomous network can change requirements dynamically without human involvement. The system has the intelligence to adapt to changing requirements and to arbitrate between potentially conflicting needs of different requirements, without the need for human user input on how to do this.

For rApps, Intent Based Management can bring several key advantages; Firstly, as the network itself becomes intent driven, rApps will be able to express their wanted goals or intents (e.g. enhanced coverage or capacity for a given set of cells) and the network figures out how best to achieve that, dealing with conflicting intents as part of that process. Secondly, rApps themselves can expose their business logic as intents, thus enabling different rApps to coordinate and cooperate with each other in an intent driven fashion.

A more comprehensive discussion on intent-based network management is beyond the scope of this blog, but it’s a very interesting topic! To learn more about intent-based network management you can read an Ericsson Technology Review article at Autonomous networks with multi-layer, intent-based operation and you can also check out this blog on Intent-Based Automation: The next evolution of network orchestration

rApp conflict management in the Ericsson Intelligent Automation Platform

In November 2021 Ericsson launched the Ericsson Intelligent Automation Platform (EIAP), our Open RAN service management and orchestration (SMO) platform. As well as supporting the automation of Open RAN and Cloud RAN networks, EIAP also supports the automation of existing purpose-built 4G and 5G networks. EIAP supports open interfaces and includes an industry-leading Software Development Kit (SDK) to provide an ecosystem of developers with all the capabilities needed to build, validate, share and deploy rApps.

EIAP will support rApp conflict management using the approaches we have described in this blog. To that end, we are working with some of our customers and ecosystem members to develop the concepts we have discussed in this blog.

Read more

You can read an overview of our Intelligent Automation Platform and find out more about how our EIAP Ecosystem supports developers in building novel RAN automation rApps today! For the latest updates on our ever-growing ecosystem you can read our recent blog on Delivering RAN management and automation innovation through telecommunications leading open rApp ecosystem

Explore 5G