O-RAN Architecture: Interfaces, RIC, and the Functional Split

This is the reference article — the functional split, every interface, and how the two RICs divide the control problem between them. If you're looking for what Open RAN is for and why operators are pursuing it, start with What Is Open RAN? instead.

The thing to keep straight throughout: O-RAN does not replace 3GPP. It takes the 3GPP disaggregated RAN as its baseline and adds interfaces, controllers, and cloud infrastructure around it.

3GPP defines the CU/DU split and the F1 and E1 interfaces. O-RAN specifies the O-DU/O-RU Open Fronthaul that 3GPP left open, plus the entire management, orchestration, and intelligent-control layer.

---

The architecture elements

Eight named elements make up the reference architecture:

---

The functional split

Everything in O-RAN terminology follows from where the protocol stack gets cut.

O-CU-CP and O-CU-UP

The Central Unit is split by plane rather than by layer.

The O-CU-CP hosts RRC and the control-plane portion of PDCP. It terminates the control-plane part of F1 toward the O-DU, and it's an E2 node — meaning the Near-RT RIC can observe and influence it.

The O-CU-UP hosts SDAP and user-plane PDCP, carrying user traffic between the RAN and the 5G Core. It's also an E2 node.

The two halves coordinate over E1, a 3GPP-defined interface. Both connect to the O-DU over F1 — F1-C for control, F1-U for user plane.

O-DU

The O-DU carries the hard real-time load: RLC, MAC, upper PHY, scheduling, and HARQ.

This is the performance-sensitive element and the one that makes cloudification genuinely difficult. Scheduling decisions run on slot boundaries. HARQ has a fixed timing budget. When people talk about hardware acceleration in Open RAN — inline versus lookaside, FEC offload — they're almost always talking about the O-DU.

O-RU

The O-RU handles lower PHY and RF: digital front-end processing, FFT/IFFT, RF filtering, power amplification, and the antenna interface.

Where exactly the PHY splits between O-DU and O-RU depends on the chosen split option. O-RAN's Open Fronthaul work centres on Split 7-2x, which puts the boundary inside the physical layer — chosen as a compromise between fronthaul bandwidth and O-RU complexity.

---

Open Fronthaul

This is the interface that defines O-RAN in practice, and the one that consumes the most integration effort.

Four planes, each with its own specification surface:

C-Plane carries scheduling and beamforming commands from O-DU to O-RU — what to transmit, when, and in which beam.

U-Plane carries the IQ data itself. This is where the bandwidth goes, and why fronthaul transport requirements are what they are.

S-Plane handles synchronisation, typically PTP and SyncE. Timing accuracy here directly determines whether TDD operation and MIMO work at all — this is the plane that quietly breaks multi-vendor deployments.

M-Plane handles O-RU management and configuration, using NETCONF/YANG. It comes in hierarchical and hybrid models depending on whether the O-RU is managed through the O-DU or directly by the SMO.

O-RAN WG4 owns these specifications, and its interoperability profiles exist because "specification compliant" and "works with that specific O-DU" turned out to be different states.

---

The interfaces

A useful way to read that table: O1 and O2 are management, A1 and E2 are intelligence, Open Fronthaul is radio, and F1/E1 were already there.

O1 uses NETCONF/YANG and carries everything an OSS traditionally needed. O2 deals in infrastructure and deployment lifecycle — provisioning O-Cloud resources, deploying network functions onto them — not radio traffic.

E2 is the interesting one. It's structured around E2 Service Models (E2SM) — the contract defining what a given E2 node exposes. KPM for performance metrics, RC for RAN control, CCC for cell configuration. An xApp is written against a service model, not against a specific vendor's RAN.

---

The two RICs

O-RAN splits intelligent control by timescale, and the split is more principled than it first looks.

The Non-RT RIC decides what the network should optimise for. The Near-RT RIC decides how to react right now.

Non-RT RIC

Lives within the SMO and operates on timescales greater than one second. It handles policy management, RAN analytics, AI/ML model training and lifecycle, enrichment data, and guidance to the Near-RT RIC over A1.

It has the luxury of time and data volume, which is why model training lives here.

Near-RT RIC

Operates between 10 milliseconds and one second, connected to E2 nodes over E2.

That lower bound matters. The Near-RT RIC is deliberately not in the scheduling loop — sub-10ms decisions stay inside the O-DU, because a control loop crossing a network interface can't meet slot-level timing. Traffic steering, mobility optimisation, QoS enforcement, interference coordination, load balancing, and slice-aware resource management all fit comfortably above 10ms.

Comparison

---

xApps and rApps

xApps run on the Near-RT RIC platform, consuming E2 service models to read RAN state and issue control actions. Typical examples: traffic steering, mobility optimisation, QoS management, interference coordination, load balancing.

rApps run in the Non-RT RIC ecosystem: analytics, capacity planning, energy optimisation, model training, policy generation.

The intended division is clear once you see them working together. Take energy saving:

The rApp analyses weeks of traffic history and produces a policy — these cells are candidates for sleep during these windows, subject to these coverage constraints. The xApp receives that policy over A1 and makes the actual call minute to minute, based on live load. Neither could do the other's job: the rApp lacks real-time visibility, the xApp lacks the data history.

---

O-Cloud

O-Cloud is the infrastructure layer hosting virtualised O-RAN functions — typically the O-CU and O-DU, since the O-RU stays physical.

It's managed by the SMO over O2, covering infrastructure inventory, resource provisioning, and deployment lifecycle. What makes it distinct from generic telco cloud is the RAN workload profile: real-time kernels, CPU pinning and isolation, huge pages, SR-IOV or DPDK datapaths, precision timing distribution, and typically FEC acceleration.

---

Why 7.2x and not one of the others

The functional split debate ran for years and produced eight options. Understanding why the industry landed on 7.2x explains most of what Open Fronthaul is.

Split further up the stack — options 6, 8 — and the radio unit becomes simpler and cheaper, but the fronthaul carries more. Option 8 is CPRI: raw time-domain IQ samples, at a bit rate that scales with antenna count and bandwidth regardless of how much traffic there is. A 64-element massive MIMO radio at 100 MHz would need hundreds of gigabits per second. That is the wall CPRI hit, and it is why massive MIMO effectively ended the option 8 era.

Split further down — options 1 through 5 — and the radio unit absorbs more processing, becoming a more capable and expensive box, which erodes the point of centralising anything.

Split 7.2x places the boundary inside the physical layer: precoding, beamforming and the inverse FFT sit in the radio unit, everything above in the distributed unit. The fronthaul then carries frequency-domain samples after precoding, so the bit rate scales with layers actually transmitted rather than with antenna elements. A 64-element array transmitting four layers carries four layers' worth of data, not sixty-four.

That is the whole argument. The split was chosen to make massive MIMO fronthaul tractable, and the rest of Open Fronthaul follows from it.

---

Where the RIC actually gets its data

The RIC is often drawn as a box connected by an arrow, which hides the part that determines whether it works.

E2 carries the near-real-time path. The E2 node exposes its capabilities through service models — E2SM-KPM for reporting measurements, E2SM-RC for controlling radio parameters, E2SM-NI for network interface data. An xApp subscribes through a service model, specifying what it wants and how often, and the node streams it back.

The service model matters more than the interface. Two E2 nodes both claiming E2 compliance may expose entirely different measurement sets, because the service model defines what is available and implementations choose what to support. Portability of an xApp between vendors depends far more on service model coverage than on E2AP conformance.

O1 carries the management path — configuration, fault, performance — using NETCONF/YANG, and feeds the non-real-time RIC and the SMO. It operates on timescales of seconds and above.

A1 is the policy interface between the two RICs, and it is deliberately thin. The non-real-time RIC does not command the near-real-time one; it sets intent — a target, a preference, a constraint — and the near-real-time RIC decides how to meet it within its own loop.

That layering is the architectural point. Slow, data-rich analysis informs fast, narrow control, and the two never block each other.

The architecture composes into three nested loops at different timescales:

Each loop handles what the loop below it can't see and the loop above it can't reach in time. Understanding which loop a given optimisation belongs in is most of what RAN control design consists of.

---

Security surface

Disaggregation multiplies the trust boundaries. Instead of one vendor's integrated system, an O-RAN deployment may involve separate suppliers for O-CU, O-DU, O-RU, RIC platform, individual xApps and rApps, SMO, and cloud infrastructure.

That expands the surface across open interfaces, platform APIs, cloud and container infrastructure, the application ecosystem, the software supply chain, AI/ML models and their training data, and certificate and identity management.

Two risks are specific to this architecture and worth naming: a malicious or badly-written xApp has legitimate RAN control authority through E2, and model poisoning against an rApp's training data can corrupt policy without ever touching a network element. The O-RAN Security Working Group's zero-trust framing follows directly from both.

---

What the SMO is for

The Service Management and Orchestration framework is the least discussed element and the one that determines whether an O-RAN deployment is operable.

It owns four things. Lifecycle management — instantiating, scaling and terminating network functions on the O-Cloud. Configuration management over O1, pushing parameters and collecting the current state. Fault and performance management, aggregating alarms and counters across a multi-vendor estate into one view. And hosting the non-real-time RIC, which is a function within the SMO rather than a peer of it.

That last point is a common misreading. The non-real-time RIC is not a separate box connected to the SMO; it is where rApps run inside it, drawing on the data the SMO already collects.

The operational significance is that the SMO is where multi-vendor actually becomes manageable. Without it, an operator running three DU vendors runs three element management systems with three data models and three alarm taxonomies. With it, O1's common YANG models normalise that into one. Whether vendors implement those models consistently enough for the normalisation to hold is, predictably, where integration effort concentrates.

---

The security surface is genuinely larger

Disaggregation adds interfaces, and every interface is an attack surface that did not previously exist. This is the most substantive technical criticism of Open RAN, and it deserves a straight answer rather than dismissal.

In a monolithic base station, the boundary between CU, DU and RU is internal — inside one chassis, one vendor's software, unreachable from outside. Splitting it puts those boundaries on a network, where they must be authenticated and encrypted rather than merely assumed trusted.

The specific exposures: Open Fronthaul carries user data between DU and RU and, being latency-critical, sits awkwardly with encryption overhead. E2 allows a RIC to change radio parameters, which makes a compromised xApp a way to degrade a network rather than merely observe it. O1 carries configuration for the whole estate. And the O-Cloud introduces the entire container-platform threat model — image provenance, workload isolation, orchestrator access — into a domain that previously had none of it.

The O-RAN Alliance's response has been a dedicated security working group, a zero-trust architecture specification, and mandatory security profiles for each interface. The mitigations are real and the specifications exist. What remains true is that the surface is larger than a monolithic system's, and securing it is work an operator now owns rather than inherits.

Compressed to the relationships worth memorising:

O-RU = lower PHY and RF · O-DU = RLC/MAC/upper PHY and scheduling · O-CU = RRC/PDCP/SDAP

Open Fronthaul = O-DU ↔ O-RU · F1 = O-CU ↔ O-DU · E1 = O-CU-CP ↔ O-CU-UP

E2 = Near-RT RIC ↔ RAN · A1 = Non-RT RIC ↔ Near-RT RIC

O1 = SMO ↔ network functions · O2 = SMO ↔ O-Cloud

That's the whole vocabulary. Everything else in O-RAN — traffic steering xApps, energy rApps, O-Cloud acceleration, slice-aware control — is built from those pieces.

---

Further reading

• What Is Open RAN? — the rationale and deployment reality
• O-RAN ALLIANCE — architecture description and working group specifications
• O-RAN WG4 — Open Fronthaul control, user, synchronisation and management plane specifications
• 3GPP TS 38.401 — NG-RAN architecture, F1 and E1