R1, A1, E2, O1: a practical map of who talks to whom in O-RAN

Why start with the interfaces

An O-RAN architecture diagram has a lot of boxes and even more letters. If you build rApps or xApps, four of those letters matter from the first day: R1, A1, E2 and O1.

Each one answers a different question. R1 is how an rApp gets the services it needs. A1 is how the slow controller guides the fast one. E2 is how the fast controller observes and steers the RAN nodes. O1 is how the whole thing is managed. This post walks through them from the top down, which is also the path a decision takes on its way to the radio.

Three control loops, three time scales

The O-RAN architecture description defines three control loops. The non-real-time loop runs at one second or longer and lives in the Non-RT RIC, which is part of the Service Management and Orchestration (SMO) framework. The near-real-time loop runs between 10 ms and 1 s and lives in the Near-RT RIC. The real-time loop runs below 10 ms and stays inside the RAN nodes, for example the scheduler in the O-DU.

The interfaces follow from this split. The exact timing depends on the use case, but one rule holds in practice: the slower loop has to be clearly slower than the loop it guides. If a policy changes as often as the controller underneath it reacts, the two will work against each other.

R1: the only door an rApp has

R1 sits between the rApps and the Non-RT RIC framework. It is service based. Functions in the framework and the SMO register services, and rApps discover and consume them. The specified service groups are service management and exposure, data management and exposure, A1-related services, RAN OAM-related services, O2-related services, AI/ML workflow services and rApp management services.

The practical consequence is easy to miss. An rApp never opens a NETCONF session to a DU and never sends an A1 policy by itself. It asks for these things through R1, and the framework owns the actual interface terminations. This is what makes an rApp portable between SMO platforms, at least on paper.

An rApp can also be a producer. It can register a data type it generates, for instance an energy estimate per network slice, and other rApps can subscribe to it through the same data management services.

A1: guidance, not commands

A1 connects the Non-RT RIC to the Near-RT RIC. It offers three services: policy management (A1-P), enrichment information (A1-EI) and ML model management (A1-ML). On the wire it is a REST interface: HTTP with JSON bodies, protected by TLS.

An A1 policy is declarative. It has a scope, such as a UE, a group of UEs, a slice, a QoS flow or a cell, and a statement with objectives or resource preferences. It says what should be achieved and for whom. How to achieve it is left to the Near-RT RIC and its xApps. Policy types are identified by a type ID and described with a JSON schema, and the Non-RT RIC can query which types a given Near-RT RIC supports.

Feedback goes both ways. The Near-RT RIC reports whether a policy is currently enforced. Whether the objective is really met is judged by the Non-RT RIC, mostly from data that arrives over O1.

Enrichment information is data the Near-RT RIC cannot get from the RAN itself, such as predictions or information from external sources. The Near-RT RIC creates an EI job, and the Non-RT RIC delivers the results.

E2: where measurements and control meet the RAN

E2 runs between the Near-RT RIC and the E2 nodes: O-CU-CP, O-CU-UP, O-DU and O-eNB. The protocol is E2AP, carried over SCTP.

It helps to think of E2 as two layers. E2AP provides the generic procedures such as setup, subscription, indication and control. On top of it, E2 service models (E2SM) define what the messages mean for a specific RAN function. E2SM-KPM covers performance measurements, E2SM-RC covers RAN control such as handover and radio bearer parameters, and E2SM-CCC covers cell configuration and control.

E2AP defines four RIC services. REPORT: the node sends data when a trigger fires. INSERT: the node pauses a procedure and asks the RIC what to do, with a timer running. CONTROL: the RIC starts or changes a procedure in the node. POLICY: the RIC installs a rule and the node applies it by itself when the trigger occurs.

During E2 Setup the node lists the RAN functions it supports. An xApp can only use what the node exposes, which is why two "E2 compliant" nodes can offer quite different control options. Also, xApps do not terminate E2 themselves. They go through the platform's E2 termination and subscription management, which gives the platform a place to detect conflicts between xApps.

O1: the management plane

O1 connects the SMO to the managed functions: the Near-RT RIC, O-CU-CP, O-CU-UP, O-DU and O-eNB. It covers the classic FCAPS tasks and is aligned with the 3GPP management services. Configuration uses NETCONF with YANG models. Fault and performance notifications are sent as JSON over HTTPS, in VES or 3GPP-defined format. Performance data can be reported as files or as a stream, and file transfer uses SFTP or FTPES.

The O-RU is a special case. It is managed through the Open Fronthaul M-Plane, which is also NETCONF and YANG based. In the hierarchical model the O-DU manages the O-RU. In the hybrid model the SMO has a direct management connection to the O-RU as well.

O1 can look like plain operations tooling, but it matters for applications. Most of the data an rApp learns from arrives over O1, and most long-lived actions, such as changing a parameter or switching off a cell, leave over O1.

One decision, four interfaces

Take energy saving at night as an example. Performance counters from the DUs and CUs flow over O1 into the SMO. An energy saving rApp subscribes to them through the R1 data management services.

The rApp predicts low load in a cluster and decides that one capacity cell can sleep. First it uses the A1-related services on R1 to create a traffic steering policy that asks the Near-RT RIC to avoid that cell for the UEs in scope. The policy travels over A1.

In the Near-RT RIC, a traffic steering xApp already has an E2SM-KPM subscription and sees per-cell and per-UE measurements. It uses E2SM-RC control messages to hand the remaining UEs over to neighbouring cells.

When the cell is empty, the rApp requests the configuration change through the RAN OAM-related services on R1, and the SMO carries it out over O1. After that, O1 performance data shows whether energy use went down and whether service quality held. The rApp keeps, adjusts or deletes the policy based on that.

Nothing in this chain skipped a layer. Each step used the interface that fits its time scale.

The interfaces we skipped

Four interfaces are not the full picture. O2 connects the SMO to the O-Cloud for infrastructure and deployment management. The Open Fronthaul connects O-DU and O-RU with its control, user and synchronization plane plus the M-Plane, based on the 7-2x split. Y1 lets the Near-RT RIC expose RAN analytics to consumers outside the RIC. The 3GPP interfaces such as F1, E1, Xn and NG remain in place underneath all of this.

They deserve their own posts. For application work, the four above come first.

What to check before you design an app

Start by asking which loop your use case belongs to. Then find out which interface delivers the data you need and which one carries your action. If the answer is "the same xApp reads O1 files" or "the rApp sends E2 control", the design needs another look.

Then check what your target platform really supports: which R1 services, which A1 policy types, which E2 service models and which versions. The specifications allow a lot, and implementations expose a subset.

The specifications are free to download from the O-RAN ALLIANCE website. The most useful ones for this topic are the WG1 Architecture Description, the WG2 documents on R1 and A1, the WG3 documents on E2AP and the E2 service models, and the WG10 O1 Interface Specification.