O-RAN / Open RAN in 5G NR
Open, disaggregated RAN — O-CU/O-DU/O-RU, the open fronthaul, and the near-RT and non-RT RIC with xApps/rApps. (O-RAN Alliance, complementary to 3GPP.)
3GPP tells you a gNB can be split into a CU, a DU and a radio — but it stops short of nailing down the radio seam or giving you a way to program the RAN in real time. O-RAN, defined by the O-RAN Alliance, fills exactly those gaps. It is complementary to 3GPP, not a replacement for it: 3GPP still defines the gNB and its CU/DU split, while O-RAN opens the fronthaul between DU and radio and bolts on a layer of programmable intelligence. This page walks the O-RAN architecture end to end — the nodes, the Open Fronthaul, the two RICs, and the interfaces that tie them together.
Introduction
Open RAN (O-RAN) is an architecture, not a new air interface. The radio protocol a UE talks — SSB, RACH, PDSCH, HARQ, RRC — is still pure 3GPP; O-RAN changes how the base station that runs that protocol is built and operated. It disaggregates the gNB into interoperable, multi-vendor pieces running as software on general-purpose (often cloud) hardware, opens the interfaces between those pieces, and adds a control layer that lets external applications steer the RAN.
O-RAN lives at the deployment and operations layer, above the per-UE call flow. It matters when an operator plans a network: which vendor supplies the radio, which supplies the baseband, how the RAN is orchestrated, and how it is optimized over time. Once cells are on the air, the O-RAN control loops (the RICs) run continuously in the background — observing measurements and pushing policy and control — while the ordinary 3GPP procedures carry the traffic underneath.
Two bodies co-author the result. 3GPP defines the gNB, the gNB-CU/gNB-DU functional split, and the F1/E1 interfaces. The O-RAN Alliance profiles those 3GPP interfaces for interoperability, standardizes the one seam 3GPP left open (the fronthaul), and adds the intelligence and management layer (the RIC, A1, E2, O1, O2, and the SMO) that 3GPP never attempted. You need both specification sets — the O-RAN Alliance documents and 3GPP TS 38.401 — to describe a complete deployment.
On this page
Why Open RAN is needed
In plain words: a traditional RAN is like a sealed appliance where the baseband, radio and management software all come from one brand and only fit each other — you cannot swap the radio for a cheaper one or plug in a smarter controller. O-RAN is the industry agreeing on the shape of the plugs and sockets, so any compliant radio fits any compliant baseband, and a third party can add a "smart thermostat" (the RIC) that tunes the network while it runs.
A traditional RAN is a single-vendor affair. The baseband, the radio and the management software all come from one supplier, wired together with proprietary internal interfaces. That works, and it is well-optimized, but it locks the operator in: the radios you bought this year only talk to that vendor's baseband, upgrades come on that vendor's schedule, and there is no third-party way to inject new control logic. Open RAN is the industry's answer to that lock-in.
O-RAN is a set of open, standardized interfaces and an intelligence layer, published by the O-RAN Alliance, that sits on top of the 3GPP-defined gNB and its CU/DU/RU disaggregation.
Open interfaces let an operator mix vendors — one supplier's O-DU with another's O-RU — and let third-party software steer the RAN. That breaks single-vendor lock-in and turns the RAN into a programmable, multi-vendor platform.
O-RAN pins down the Open Fronthaul (the DU-to-radio seam 3GPP left open), adds the RIC for programmable control, and defines the A1, E2, O1 and O2 interfaces plus an orchestration layer, the SMO.
The two motives reinforce each other. Disaggregation — already made possible by 3GPP's CU/DU split — separates the gNB into functions that can run as software on general-purpose servers. Openness is what stops disaggregation from simply re-locking you into one vendor's version of each box: if the seam between O-DU and O-RU is a published, tested profile rather than a proprietary protocol, then any compliant radio can plug into any compliant DU. Add the ability to load third-party control applications and the RAN stops being a fixed appliance and becomes something you can optimize continuously, the way you would optimize any cloud service.
The one-line framing: 3GPP defines the gNB and the CU/DU split; O-RAN opens the fronthaul seam that 3GPP left unspecified and adds an intelligence layer (the RIC) that 3GPP never defined. O-RAN complements 3GPP — it does not replace it.
The O-RAN nodes: O-CU, O-DU, O-RU
O-RAN takes the 3GPP logical nodes and gives them "O-" names to signal that they implement the open profiles. The mapping is one-to-one, so if you already know the 3GPP CU/DU/RU split you already know most of this.
The O-RAN Central Unit — the 3GPP gNB-CU. It hosts RRC, SDAP and PDCP, and is itself split by plane into the O-CU-CP (control plane: RRC, control-plane PDCP) and the O-CU-UP (user plane: SDAP, user-plane PDCP).
The O-RAN Distributed Unit — the 3GPP gNB-DU. It hosts the per-slot layers: RLC, MAC and the upper physical layer (high-PHY). It terminates the Open Fronthaul toward the radio.
The O-RAN Radio Unit. It hosts the lower physical layer (low-PHY) — FFT/iFFT, cyclic-prefix handling, beamforming — and the RF front end. It connects to the O-DU over the Open Fronthaul.
Two things are worth stressing. First, the layer boundaries are exactly the 3GPP ones: the O-CU/O-DU cut is functional-split Option 2 (above RLC), carried by the 3GPP F1 interface (F1-C signalling over F1AP, F1-U user data over GTP-U); and the O-CU-CP/O-CU-UP cut is carried by 3GPP E1 (the E1AP control-only interface). O-RAN does not redefine F1 or E1; it reuses them from TS 38.401 and the surrounding 3GPP specification set. Second, the genuinely new piece is what happens below the O-DU: the seam to the O-RU, which 3GPP listed as a family of low-layer split options but never fully standardized. That is the seam O-RAN pins down as the Open Fronthaul.
The high-PHY/low-PHY boundary inside the O-DU/O-RU pair is itself a design choice with two flavours. In a Category A O-RU the O-DU performs precoding and sends per-layer data across the fronthaul; in a Category B O-RU the precoding (and thus digital beamforming) is done inside the radio, so the fronthaul carries per-antenna-port beamforming weights and control instead. Category B is what makes massive-MIMO O-RUs practical without an unmanageable fronthaul bit rate.
Anchor fact: O-CU, O-DU and O-RU are the same logical nodes 3GPP calls gNB-CU, gNB-DU and the radio unit. O-RAN's contribution is the open interfaces between them and the intelligence layer above them — not new protocol layers inside them.
The Open Fronthaul: the 7-2x lower-layer split
The interface between the O-DU and the O-RU is the Open Fronthaul, and its defining choice is where in the physical layer to cut. O-RAN adopted a variant of 3GPP's intra-PHY Option 7, called the 7-2x lower-layer split. The idea is to keep the most bandwidth-hungry, RU-specific processing — FFT/iFFT, cyclic prefix, and (in the Category B radio) precoding/beamforming — inside the O-RU, and to send frequency-domain IQ samples across the fronthaul rather than raw time-domain samples.
This is the key contrast with the CU/DU seam. The 3GPP higher-layer split on F1 carries PDCP PDUs at roughly the user's data rate, with millisecond-class latency tolerance, so it can ride ordinary routed IP transport over long distances. The Open Fronthaul is the opposite kind of link: it carries near-constant-rate signal-processing data under microsecond timing and demands a tight, low-jitter Ethernet transport (typically eCPRI over dedicated fibre). Choosing 7-2x rather than the fully raw Option 8 (classic CPRI) cuts the fronthaul bit rate sharply — because samples are frequency-domain and beamforming is done in the radio — while still keeping the O-RU relatively simple.
Legacy CPRI ↔ O-RAN eCPRI: classic CPRI (the split-Option-8 fronthaul used in earlier C-RAN / distributed-RAN builds) carries time-domain IQ at a fixed line rate that scales with antennas and bandwidth — a massive-MIMO carrier can demand tens of Gbit/s per sector and a proprietary CPRI framing. O-RAN's 7-2x over eCPRI instead carries frequency-domain IQ (empty resource elements need not be sent) and moves beamforming into the O-RU, so the bit rate drops sharply and rides standard Ethernet rather than a vendor-specific CPRI link. Same job (DU-to-radio transport), very different economics.
The Open Fronthaul is not one pipe but four coordinated planes, each with its own job:
| Plane | Name | What it carries |
|---|---|---|
| C-plane | Control | Scheduling and beamforming commands: which resource blocks, which symbols, which beams the O-RU should act on, slot by slot. Carried in eCPRI real-time control messages, sent ahead of the matching U-plane data. |
| U-plane | User | The frequency-domain IQ samples themselves — the actual downlink/uplink waveform data, over eCPRI, with configurable IQ bit width and optional block-floating-point compression to save fronthaul bandwidth. |
| S-plane | Synchronization | Timing and frequency alignment between O-DU and O-RU — PTP (IEEE 1588v2, typically the ITU-T G.8275.1 telecom profile) and SyncE — so both ends share a common clock. TDD demands sub-microsecond alignment (the tightest category is on the order of ± a few hundred ns). |
| M-plane | Management | Configuration, software management, fault and performance reporting for the O-RU — the "how do I set up and monitor this radio" plane, using NETCONF/YANG. |
So where F1 abstracts everything into signalling (F1-C) and tunnelled PDUs (F1-U), the Open Fronthaul is far closer to the metal: it splits into control, user, sync and management planes because a real-time radio needs all four to be coordinated to sub-microsecond precision. The M-plane in particular is what makes multi-vendor radios practical — a common YANG data model means an O-DU from one vendor can configure an O-RU from another. It runs in one of two modes: hierarchical (the O-RU is managed through the O-DU) or hybrid (the SMO also has a direct M-plane path to the O-RU).
The RIC: adding intelligence to the RAN
The most distinctive thing O-RAN adds — something 3GPP has no equivalent for — is the RAN Intelligent Controller (RIC). The RIC is a platform for hosting control applications that observe the RAN and steer it, on two very different timescales. That split into two RICs is deliberate: some decisions must react within a slot or two, while others are policy and analytics that can take seconds or minutes.
The Non-Real-Time RIC lives inside the SMO and works on timescales > 1 second. It hosts rApps that do policy, analytics and model training, and it drives the Near-RT RIC through the A1 interface with policies and enrichment data.
The Near-Real-Time RIC works on 10 ms–1 second. It hosts xApps that make fast control decisions — mobility, load balancing, interference — and reaches into the O-CU and O-DU over the E2 interface to read state and send control.
The Non-RT RIC sets the strategy (an A1 policy: "prefer slice X on these cells"); the Near-RT RIC enforces it moment to moment through xApps over E2. Slow brain up top, fast reflexes below.
The E2 interface is not one monolithic protocol but a transport (E2AP) carrying pluggable E2 Service Models (E2SM) that define what an xApp can observe and control on a given RAN function. The common ones are E2SM-KPM (Key Performance Measurement — subscribe to counters and metrics), E2SM-RC (RAN Control — influence mobility, bearer and admission decisions), and E2SM-CCC (cell configuration and control). E2AP exposes four core procedures — RIC Subscription, RIC Indication (report), RIC Control, and RIC Policy — which map onto the "subscribe / receive indications / send control" pattern below. On the A1 side there are two flavours: A1-P (policies) and A1-EI (Enrichment Information, e.g. externally sourced data a Near-RT xApp can use).
A concrete example makes the division clear. Suppose you want to improve handovers for a premium slice. A rApp in the Non-RT RIC analyses days of performance data, trains a model, and issues an A1 policy that says "for this slice, bias handovers toward cells with spare capacity." The Near-RT RIC receives that policy and an xApp turns it into per-UE decisions in near real time, subscribing to measurements from the O-CU/O-DU over E2 (an E2SM-KPM subscription) and sending control actions back over the same interface (an E2SM-RC control) — all within the 10 ms–1 s window. The two loops run continuously and independently.
| Property | Non-RT RIC | Near-RT RIC |
|---|---|---|
| Timescale | > 1 second | 10 ms – 1 second |
| Where it lives | Inside the SMO | Standalone platform between SMO and the RAN nodes |
| Hosts | rApps | xApps |
| Southbound interface | A1 (policies, enrichment) to the Near-RT RIC | E2 (subscribe, report, control) to O-CU / O-DU |
| Typical job | Policy, analytics, ML model training, RAN optimization | Mobility, load balancing, admission/interference control |
| Also uses | O1 to manage RAN elements | Driven by A1 policy from above |
Memory hook: rApps run on the Non-RT RIC over A1; xApps run on the Near-RT RIC over E2. The Non-RT RIC is the slow, thoughtful brain in the SMO; the Near-RT RIC is the fast reflex sitting just above the CU/DU.
The O-RAN interfaces: A1, E2, O1, O2 and Open Fronthaul
O-RAN introduces a small set of named interfaces that layer on top of the 3GPP ones. Keep two families straight: the 3GPP interfaces (F1, E1, NG, Xn) that O-RAN reuses unchanged, and the O-RAN-defined interfaces (A1, E2, O1, O2, Open Fronthaul) that carry the new intelligence and management traffic.
| Interface | Connects | What it does |
|---|---|---|
A1 | Non-RT RIC (in SMO) ↔ Near-RT RIC | Carries policies (A1-P) and enrichment information (A1-EI) from the slow loop to the fast loop — strategy, not per-slot control. |
E2 | Near-RT RIC ↔ O-CU / O-DU (E2 Nodes) | The fast control link (E2AP + E2 Service Models): xApps subscribe to RAN metrics, receive indications, and send control actions in near real time. |
O1 | SMO ↔ all managed elements (O-CU, O-DU, O-RU, Near-RT RIC) | The management/orchestration interface: FCAPS — configuration, fault, performance and software management — over NETCONF/YANG, with streaming events via VES. |
O2 | SMO ↔ O-Cloud (the cloud platform) | Manages the cloud infrastructure (O2-IMS) and the lifecycle of the virtualized RAN functions (O2-DMS) — provisioning compute, deploying/scaling the network functions. |
| Open Fronthaul | O-DU ↔ O-RU | The 7-2x lower-layer split over eCPRI, with C/U/S/M planes — frequency-domain IQ plus control, sync and management. |
The clean way to remember the roles: A1 and E2 are about control intelligence (policy down, fast control below), while O1 and O2 are about management and cloud (managing the network functions and the infrastructure they run on). The Open Fronthaul is the odd one out — it is a data-plane radio interface, not a control or management interface — but O-RAN owns it because it is the seam 3GPP deliberately left open. Note that O1 reaches essentially every element, including the Near-RT RIC itself, because the SMO has to be able to configure and monitor the whole system.
Trap: don't confuse A1 with E2. A1 carries policy from the Non-RT RIC to the Near-RT RIC (seconds and up). E2 carries fast control from the Near-RT RIC into the O-CU/O-DU (10 ms–1 s). And neither replaces the 3GPP F1/E1 links, which still run between the nodes underneath.
The SMO and the full picture
Sitting above everything is the SMO — Service Management and Orchestration framework. The SMO is the operator's management brain for the O-RAN system: it hosts the Non-RT RIC, manages every RAN element over O1, and manages the underlying cloud platform (the O-Cloud) over O2. In other words, the SMO is where policy, analytics, configuration and cloud lifecycle all come together.
Putting the whole chain in one line: the SMO (with the Non-RT RIC inside it) drives the Near-RT RIC over A1; the Near-RT RIC steers the O-CU and O-DU over E2; the O-DU drives the O-RU over the Open Fronthaul; and O1/O2 run from the SMO down the side to manage the elements and the cloud. The 3GPP F1 and E1 interfaces still connect the O-CU, O-DU underneath — O-RAN's interfaces sit on top of, not instead of, the 3GPP ones.
SMO hosts the Non-RT RIC and drives the Near-RT RIC over A1; the Near-RT RIC steers the O-CU/O-DU over E2; the O-DU drives the O-RU over the Open Fronthaul (7-2x); and O1 from the SMO manages every element.Bottom line: the SMO is the top of the stack — policy and analytics (Non-RT RIC), element management (O1) and cloud lifecycle (O2) all live there. Below it, the Near-RT RIC gives you fast, per-slot-scale control over the same O-CU/O-DU that 3GPP already defined.
Relationship to 3GPP CU/DU/RU
It is worth being crisp about the division of labour, because it is the single most common source of confusion. 3GPP and O-RAN are not competitors and not two versions of the same thing — they are two layers of the same system, authored by two different bodies.
The gNB and its logical nodes (gNB-CU, gNB-DU), the Option-2 CU/DU split, and the F1 and E1 interfaces — all in TS 38.401 and the surrounding series. It also lists the low-layer split options but leaves the choice open.
The specific 7-2x Open Fronthaul between O-DU and O-RU, the RIC (Non-RT + Near-RT) with A1 and E2, the O1/O2 management and cloud interfaces, and the SMO — plus interoperability profiling of the 3GPP interfaces.
A fully open, multi-vendor, programmable RAN: any vendor's O-CU, O-DU and O-RU interoperate, and third-party xApps/rApps optimize it in real time — all still speaking 3GPP protocols underneath.
So when you hear "O-RAN," do not picture a rival to 3GPP. Picture 3GPP drawing the CU/DU/RU boxes and the F1/E1 seams, and O-RAN then (a) opening the one seam 3GPP left unspecified — the fronthaul — and (b) adding an intelligence-and-management layer on top that 3GPP never attempted. Everything O-RAN specifies is designed to sit on and reuse the 3GPP foundation. That is exactly why the specs cited for this topic are both the O-RAN Alliance documents and 3GPP TS 38.401: you need both to describe a complete O-RAN deployment.
⚠ Common pitfalls / gotchas
- Treating O-RAN as a new air interface. It is not — the Uu radio protocol is unchanged 3GPP NR. O-RAN changes how the gNB is built and controlled, not what the UE transmits.
- Under-engineering the S-plane. The fronthaul's tightest constraint is timing, not throughput. In TDD, if
PTP/SyncE alignment drifts beyond the O-RU's budget the cell mutes uplink/downlink switching — a "radio down" symptom whose root cause is the clock, not the RF. - Assuming any O-DU pairs with any O-RU. Interoperability requires matching the O-RU category (A vs B), the M-plane mode (hierarchical vs hybrid), and the negotiated fronthaul profile (IQ width, compression, section extensions) — "O-RAN compliant" alone does not guarantee a plug-and-play pair.
- Confusing E2 with F1.
E2is the RIC's observe-and-control channel and is optional to the call flow;F1is the mandatory 3GPP CU–DU user/control path. Pulling E2 does not drop calls; pulling F1 does.
Summary
O-RAN is 3GPP's disaggregated gNB with the gaps filled in. Keep the division of labour straight and the rest follows: 3GPP owns the gNB-CU/gNB-DU nodes, the Option-2 split, and the F1/E1 interfaces (TS 38.401); the O-RAN Alliance opens the one seam 3GPP left unspecified — the 7-2x Open Fronthaul over eCPRI with its C/U/S/M planes — and adds an intelligence-and-management layer 3GPP never attempted.
That layer is two control loops plus an orchestrator. The Non-RT RIC (in the SMO, > 1 s, rApps) sets policy over A1; the Near-RT RIC (10 ms–1 s, xApps) enforces it over E2 using E2 Service Models against the O-CU/O-DU. Above them the SMO manages every element over O1 and the cloud platform over O2. Underneath it all, the ordinary 3GPP protocols still carry the traffic.
The single most useful mental model: A1 and E2 are control intelligence; O1 and O2 are management and cloud; the Open Fronthaul is the data-plane radio seam. Get those five interfaces and two RICs placed correctly and you can describe any O-RAN deployment — and answer almost any interview question on it.
Quick Q&A
O-RAN is a favourite interview topic precisely because it forces you to separate what 3GPP owns from what the O-RAN Alliance owns — and to keep the four O-RAN interfaces and two RICs straight.
Q. Is O-RAN a replacement for 3GPP?
A. No. O-RAN is defined by the O-RAN Alliance and is complementary to 3GPP. 3GPP defines the gNB and the CU/DU split (TS 38.401, F1/E1); O-RAN adds open interfaces (notably the Open Fronthaul) and the intelligence layer (the RIC) on top. Both are needed for a complete O-RAN system.
Q. What is the difference between the Non-RT RIC and the Near-RT RIC?
A. The Non-RT RIC lives inside the SMO, works on timescales > 1 s, hosts rApps, and issues policy over A1. The Near-RT RIC is a standalone platform working on 10 ms–1 s, hosts xApps, and controls the O-CU/O-DU over E2. Slow policy brain vs fast reflex.
Q. What is the Open Fronthaul 7-2x split, and how does it differ from F1?
A. 7-2x is a lower-layer intra-PHY split: the O-RU keeps FFT/iFFT, cyclic prefix and beamforming, and frequency-domain IQ is sent over eCPRI. It needs tight, low-jitter transport. F1 is the higher-layer split (above RLC) carrying PDCP PDUs at ~user rate with relaxed latency over routed IP.
Q. What do A1, E2, O1 and O2 each connect?
A. A1: Non-RT RIC to Near-RT RIC (policy). E2: Near-RT RIC to O-CU/O-DU (fast control). O1: SMO to all managed elements (FCAPS). O2: SMO to the O-Cloud (infrastructure/lifecycle).
Q. What are the four planes of the Open Fronthaul?
A. C-plane (scheduling/beamforming control), U-plane (frequency-domain IQ data), S-plane (synchronization, PTP/SyncE), and M-plane (management/configuration over NETCONF/YANG). The M-plane's common YANG model is what makes multi-vendor O-RUs practical.
Q. Where does the SMO fit, and what does it host?
A. The SMO (Service Management and Orchestration) sits at the top. It hosts the Non-RT RIC, manages every RAN element over O1, and manages the cloud platform over O2. It is the operator's single management and orchestration brain for the O-RAN system.
Where to go next
You've seen how O-RAN opens the fronthaul and layers intelligence on top of the 3GPP gNB. To go deeper, revisit the 3GPP split that O-RAN builds on, or follow the interfaces that run underneath the O-RAN layer: