How the O-RAN Alliance R1 interface empowers a global RAN automation community

Automation in the Radio Access Network (RAN) is a key goal for Communications Service Providers (CSPs). This is not a surprise, as ever larger and more advanced networks are costly and complex to manage. This is where Intelligent RAN Automation enters the game! 

The O-RAN Alliance aims to evolve radio access networks to be more open, intelligent, virtualized and interoperable. It introduces the concept of “rApps” as a novel solution to deliver intelligent RAN automation capabilities. rApps are software applications that act on so-called “higher-level” control loops, with a response time of seconds and above. rApps are a strong solution for automating at scale on a network or cluster level, including for operations like AI/ML-based RAN optimization, energy saving, network orchestration, and other use cases across the full RAN lifecycle. You can learn more rApp basics at rApps – your best bet for innovation in 5G networks. 

At the heart of this paradigm shift is the O-RAN Alliance 'Service Management and Orchestration' (SMO) framework. rApps are deployed on the “Non-real time RAN Intelligent Controller” (Non-RT RIC), which in turn is part of the SMO. The SMO and Non-RT RIC together provide a multi-vendor platform that enables enhanced RAN management and automation via rApps.   

The beauty of the rApp concept is that it decouples rApp life cycle management and ownership from that of the Non-RT RIC and SMO platform and the RAN. rApps can be developed by separate companies from the SMO platform vendors and can be upgraded to new versions separately from upgrades of the SMO platform. rApp developers can focus on the value-add innovation in their rApp algorithms, without being concerned with which vendor SMO platforms they will execute on.  

The SMO and Non-RT RIC provide rApp developers with various capabilities that make it easier to build and deploy rApps. The technical complexity and time-to-market for delivering novel RAN automation to the global market is therefore greatly reduced. This can enable a much larger RAN automation community, with faster innovation as a result. 

Sounds great, but can we really write rApps that can be deployed on SMO platforms from different vendors? That’s where the R1 interface enters the picture! Let us find out how. 

How can rApp developers enjoy the benefits of the R1 interface?  

rApp developers can use the R1 interface to benefit from a wide range of SMO and Non-RT RIC platform services and data. These platform capabilities ensure that rApp developers can implement their RAN automation loops more quickly and easily. Note that we say ‘a wide range’ of services; the R1 interface is like an ‘umbrella’ that spans multiple application programming interfaces (APIs). These APIs provide capability to rApps such as access to network configuration, performance and topology data, execution of AI/ML models, policy execution, security infrastructure, and much more, supporting rApp execution in both open-loop and closed-loop modes of operation.  

rApps can also register their own services and data so that they too are exposed to other rApps over R1. In addition, the R1 shields rApp developers from needing to know low-level implementation details for aspects such as how to connect to or consume data from a network function over the O1 interface.  

We can see how the R1 interface relates to rApps, the Non-RT RIC, and the SMO in Figure 1 below. 

Figure 1: rApps and the R1 interface 

As Figure 1 shows, the R1 interface is the “glue” between the rApps and the supporting functions provided by the SMO/Non-RT RIC. Importantly, usage of the R1 interface means that rApps can be deployed on SMO/Non-RT RIC implementations from different vendors, and also that CSPs can source their SMO/Non-RT RIC from a separate vendor than their rApp vendor(s). In the example in Figure 1, each color represents a different vendor. We can see three different rApps from three different rApp vendors, and a fourth vendor for the SMO/Non-RT RIC. CSPs may also opt to develop their own SMO/Non-RT RIC and/or rApps in-house. This disaggregated and multi-vendor approach is very much aligned with the open spirit of the architecture defined by the O-RAN Alliance.  

As an industry, it is vital that we produce a well-specified and easy-to-use R1 interface if we are to truly unlock the potential that rApps offer. A strong R1 interface, backed by R1-aligned vendor SMO/Non-RT RIC platforms, can foster a vibrant rApp developer community, attracted by the opportunity to write their rApps once and run them on any SMO/Non-RT RIC platform. This provides rApp developers with access to a global target market, which in turn provides CSPs with access to a larger selection of rApps and rApp vendors, with associated economic benefits.  

Note that Figure 1 also shows that the SMO platform manages the multi-vendor RAN using O-RAN Alliance interfaces such as the O1, A1, O2 and M-Plane interfaces – like the R1, these are vital O-RAN Alliance interfaces, but they are beyond the scope of this blog.   

What functionality can the R1 interface offer to rApp developers? 

The core purpose of the R1 interface is to enable RAN automation in the form of rApps. At Ericsson, we believe the R1, in tandem with the Non-RT RIC and SMO, should make it as fast and easy as possible to bring an rApp all the way from initial idea to deployment in CSP production environments. To achieve this goal the R1 needs to support a diverse range of capabilities that allow rApp developers to focus on the unique value-added aspects of their use cases as much as possible.  

In Figure 2 below, we visualize this principle in the form of an iceberg, with the non-unique and often hidden costs of developing RAN automation below the waterline; we can see in Figure 2 that these account for a significant portion of the effort in implementing this automation. The idea with rApps is that the rApp developer should be free to focus as much of their energy as possible on the parts above the waterline, while the SMO/Non-RT RIC platform handles the parts below the waterline as much as possible. This approach lowers the barrier to rApp development and enables a faster time-to-market for new rApps. 

Figure 2: The effort involved in delivering RAN Automation 

Figure 2 highlights that there are multiple tasks involved in developing RAN automation software algorithms, and many are common to most if not all such automation loops. For example, many of them will need to securely consume network performance, topology and configuration data, consume or generate analytics insights from this data, use this data as input to AI/ML models, update the network configuration data or create an O-RAN Alliance A1 interface policy, and so on. The R1, backed by the SMO/Non-RT RIC, will provide common platform services to simplify these tasks, thereby reducing the cognitive load on developers and ensuring their rApps can be deployed on R1-aligned SMO platforms across the globe. In summary, the R1 makes rApp development easier by allowing the rApp to access a range of automation-enabling services and data in a standardized fashion. 

As an example, consider an rApp that wants to employ an AI/ML-based algorithm to optimize the RAN in terms of energy efficiency. The rApp developer can easily request network topology data, such as network devices and cells and their relationships, from the R1 Topology service. For these entities, it can then subscribe to a stream of network performance data, again via the R1 interface. The rApp developer does not need to address aspects such as subscribing for and collecting this data from the network devices; the SMO platform takes care of this. The rApp can feed the performance data and other necessary data into an AI/ML model that can be executed by the SMO platform. The rApp can then optimize the network based on the output of this algorithm, for example by requesting an update to the device or cell configuration over the R1 interface. The SMO/Non-RT RIC platform then handles multiple cross-cutting aspects in the background, including secure connection to the network device over the O1 interface, providing an audit trail of the executed operations, and ensuring that the requested network updates do not conflict with changes requested by other rApps. 

R1 interface specification work in O-RAN Alliance, and Ericsson’s involvement 

At Ericsson we are strong believers in the R1 interface. To ensure it delivers on its potential, we are heavily invested in and committed to driving the R1 specifications in the O-RAN Alliance. Figure 3 below shows an overview of our share of contributions to selected O-RAN Alliance working groups, as of October 2023. It shows that we are the leading contributor to Workgroup 2, “The Non-Real-Time RAN Intelligent Controller and A1/R1 Interface Work Group”, which defines the R1 interface. We have made approximately 35% of the total contributions to the WG2 specifications (based on our evaluation of O-RAN Alliance data on member contributions). We hold a co-chair position in Workgroup 2, which is one of our three O-RAN Alliance co-chair positions. We are also the ‘rapporteur’ for the R1 interface specifications, which means that we are responsible for tasks such as editing the specifications to reflect the Workgroup 2 agreements and reviewing change requests for the specifications. 

Figure 3: Ericsson’s share of contributions to selected O-RAN Alliance working group specifications (as of end of October 2023) 

A question we’re sometimes asked is: “How mature is the R1?” Our view on the R1 is that “there is a lot done, and a lot more to do.” Workgroup 2 published the first R1 specifications in 2021. The specifications have evolved continuously since then, with multiple new versions published per year, and will continue to evolve in future. The workgroup is contributed to by multiple participants from the global CSP and vendor community.   

A strong focus, so far, has been on defining the means by which rApps can access data and services that are exposed by the SMO platform or by other rApps, as well as the way in which rApps can publish their own data and services to other rApps. Ensuring secure access to services exposed over R1 has also been a strong focus area; collaboration with the O-RAN Alliance Security Workgroup 11 has been important to enable this. Significant progress has already been made in specifying these aspects of R1. 

The R1 specifications will continue to evolve in future. As the specifications continue to mature, they will likely define additional services that further simplify rApp development. Examples include AI/ML model management, training and execution, a service that calculates RAN Key Performance Indicators (KPIs), policy engine support, and more. These services will help to achieve the vision of a rich R1 interface that allows portable rApps to be rapidly developed by a large, diverse and global RAN automation community. 

R1 interface support 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.  

rApp support is at the heart of EIAP, and from the outset we’ve been building it to align with the R1 specifications. Our development teams work closely with our delegates in the O-RAN Alliance to ensure that EIAP development aligns with the R1 evolution. We also use the real-world experience gained from developing our platform to influence the development of R1.  

Ahead of the game 

There are times when CSP and business requirements mean that the Ericsson Intelligent Automation Platform development needs to move ahead of the R1 specifications. In other words, the EIAP platform exposes services to rApps that are not yet part of the R1 interface. We use the term ‘R1*’ to describe this scenario (sometimes also referred to as ‘R1+’). Our strategy is to design ‘R1*’ services in a manner that can be seamlessly added to R1 in the future. We can then collaborate with the O-RAN Alliance Workgroup 2 members to evolve the R1 specifications to include these services.  

Read more:  

We believe that industry-wide collaboration on the R1 interface specifications is key to fostering a global RAN automation community. We encourage rApp vendors, SMO vendors, CSPs, and other interested parties to join the R1 specification activities in the O-RAN Alliance Workgroup 2. To view the latest R1 interface specifications, look under the Workgroup 2 heading on the O-RAN Alliance 'O-RAN Specifications' page. 

You can also 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! 

Finally, you can read more of the basics about rApps for Intelligent Automation and read a more in-depth discussion on rApps: Transforming network management with intelligent automation apps