O-RAN Architecture
Deep Dive

The old base station is one closed box. Inside that box, baseband processing, radio control, and RF amplification are tightly coupled — and so is the supplier relationship. If your initial 4G rollout was Ericsson, your 5G upgrade is Ericsson. If you want a new traffic-steering algorithm, you wait for Ericsson's roadmap. If a startup invents a brilliant beam-management model, it cannot run on your network unless Ericsson ports it. This is the structural problem the O-RAN ALLIANCE was created to solve.

O-RAN's answer is three changes layered together: (1) disaggregate the gNB into a Central Unit, a Distributed Unit, and a Radio Unit, with the Lower-Layer Split (7.2x) at PHY-Low so each can come from a different vendor; (2) standardize the interfaces between them (E1, F1, Open Fronthaul) so they actually interoperate; (3) introduce a new node — the RAN Intelligent Controller — that runs vendor-neutral software (xApps and rApps) which can optimise the network in real time using AI/ML.

The monolithic gNB is sliced into three nodes along well-defined protocol-stack boundaries. The O-CU (Central Unit) holds the upper layers — RRC, SDAP, PDCP — and runs in regional or central datacenters; one O-CU typically aggregates many cells. The O-DU (Distributed Unit) hosts the time-critical layers — RLC, MAC, and the upper PHY (High-PHY) — and lives at the edge to meet HARQ deadlines. The O-RU (Radio Unit) handles the rest of PHY (Low-PHY: IFFT/FFT, beamforming) plus the analog RF chain, and sits at the antenna site.

The split between O-CU and O-DU is the F1 interface (3GPP F1-AP, control plane) plus the E1 interface separating CU-CP and CU-UP for service-based control. Between O-DU and O-RU the split is the Open Fronthaul 7.2x — defined by O-RAN WG4 — which carries CUS-Plane (control/user/sync) IQ samples over eCPRI. Splitting at 7.2x rather than the older CPRI Option-8 reduces fronthaul bandwidth from ~25 Gbps to ~2-3 Gbps per cell — that's what makes commodity fibre and white-box radios viable.

The Near-Real-Time RAN Intelligent Controller — Near-RT RIC — is the most disruptive thing in the entire O-RAN architecture. It is a platform that hosts xApps: vendor-neutral applications that can observe the RAN at a sub-second timescale and influence it through control messages. xApps subscribe to E2 reports, run inference (typically ML), and issue control actions back into the gNB. Examples in production today: traffic-steering xApps that shift UEs between cells based on predicted load; QoS-prediction xApps that pre-emptively boost MCS for video flows; massive-MIMO beam-pattern optimizers.

The Near-RT RIC is a Kubernetes-based platform. xApps are containers. They communicate with the platform via the RIC SDK over the E2 interface. The control loop they run in is bounded: 10 ms ≤ loop time < 1 s. Anything faster than 10 ms stays inside the O-DU's L1/L2 firmware (HARQ, scheduling); anything slower than 1 s belongs in the Non-RT RIC. The 10ms–1s window is where most "operator intelligence" actually lives.

If the Near-RT RIC is a real-time controller, the Non-Real-Time RIC is a strategic planner. It lives inside the SMO (Service Management and Orchestration framework) and runs rApps on a >1 s timescale. rApps do three things the Near-RT RIC can't: (1) train ML models on historical data and deploy them down to xApps; (2) issue policies to the Near-RT RIC over the A1 interface (e.g., "for users in cell 42, optimise for latency over throughput"); (3) orchestrate at the network level — energy savings across thousands of cells, slice SLA assurance, network-wide ANR.

The cleanest mental model: rApps train the models, xApps execute them. An rApp watches the network for weeks, builds a "traffic-steering" model, ships it to an xApp via the AI/ML workflow, the xApp runs inference every 100 ms. Policy from the rApp (via A1) tells the xApp when and where to apply the model. Together they form the closed loop that O-RAN calls "AI-native RAN."

E2 is the southbound interface from the Near-RT RIC to the E2 Nodes (O-CU, O-DU, eNB). It runs over SCTP on top of IP. The application protocol is E2AP — an ASN.1-encoded message set borrowed from 3GPP F1/E1 conventions. On top of E2AP rides one or more E2 Service Models (E2SM): contracts that define what an xApp can observe and what it can control. The two service models you'll meet in every real deployment are E2SM-KPM (Key Performance Measurements — read-only telemetry) and E2SM-RC (RAN Control — the action interface).

Every xApp follows the same dance: it opens an E2 connection, sends an RIC SUBSCRIPTION REQUEST describing which reports it wants and which actions it will issue, the E2 Node responds with RIC SUBSCRIPTION RESPONSE, then asynchronous RIC INDICATION messages stream in carrying telemetry. When the xApp decides to act, it sends a RIC CONTROL REQUEST with a service-model-defined action body, and the E2 Node either applies the change and replies with RIC CONTROL ACKNOWLEDGE, or refuses with RIC CONTROL FAILURE. The whole loop closes in milliseconds.

The SMO doesn't talk to the RAN directly — it talks through three carefully-scoped interfaces. A1 carries policies and enrichment data from the Non-RT RIC down to the Near-RT RIC: think "prefer URLLC over eMBB in cell 42 between 18:00-22:00." It is HTTPS + JSON, RESTful, and intentionally high-level — the Non-RT RIC tells the Near-RT RIC what to optimise for, not how to do it.

O1 is the operations & maintenance interface from the SMO down to all RAN nodes (O-CU, O-DU, O-RU, and even the Near-RT RIC itself). It carries FCAPS — Fault, Configuration, Accounting, Performance, Security — and uses NETCONF + YANG, the same stack the IETF uses for routers and switches. O2 is the interface from the SMO to the O-Cloud — the Kubernetes-based infrastructure that hosts the virtualised RAN functions. O2 handles lifecycle management of the O-Cloud itself: "deploy this O-DU container on this site's compute pool."

The Open Fronthaul interface is what makes the "any O-DU with any O-RU" promise real. It defines a single split point between High-PHY (in the O-DU) and Low-PHY (in the O-RU) — known as Lower-Layer Split 7.2x. The split happens after the resource-element mapping and just before the IFFT. By that point, the data has been channel-coded, modulated, and laid out on the resource grid — but it has not yet been turned into time-domain samples. That's the magic: you transport frequency-domain IQ samples over the fibre instead of time-domain samples, which is roughly an order of magnitude less data.

Four planes ride on the fibre: the User Plane carries the IQ data, the Control Plane tells the O-RU which resource elements to transmit in each symbol, the Synchronization Plane distributes PTP (IEEE 1588v2) so the O-RU's RF clock locks to the O-DU's frame timing, and the Management Plane handles config/inventory/alarms over NETCONF. The transport itself is eCPRI (Common Public Radio Interface — enhanced) over Ethernet, typically 10/25/100 Gbps depending on cell capacity and MIMO order.

O-RAN is no longer a slideware initiative. As of 2026, multiple Tier-1 operators run live O-RAN cells at meaningful scale. The frontier is led by Rakuten Mobile (Japan), who built a greenfield cloud-native O-RAN network from day one — currently ~50,000 cells, virtually all O-RAN, vendor mix dominated by Symphony, Mavenir, and NEC. DISH (United States) followed a similar greenfield path. 1&1 (Germany) is Europe's first fully O-RAN network, with Rakuten Symphony as the systems integrator.

Brownfield operators take the cautious path: starting with O-RAN trials in rural / low-density sites where the risk is low and the cost savings are highest. Vodafone (UK) committed to 30% O-RAN by 2030. AT&T (US) signed a $14B Ericsson deal that includes Open Fronthaul-compliant cells. Reliance Jio (India) has the largest stated O-RAN ambitions of any operator outside Rakuten — full O-RAN 5G build-out across 100,000+ cells. Across all of these, the consistent learning is: RIC + xApps are the part that delivers the operational savings; the disaggregation alone barely moves CapEx.