2 articles

Open RAN: Disaggregation, Open Interfaces and the RIC

Open RAN is one architectural idea with several confusing names attached. Strip the branding away and it is a claim about interfaces: that the seams inside a base station should be specified well enough for different vendors to meet at them.

Open RAN attracts an unusual amount of noise for what is, technically, a fairly contained idea. Underneath the vendor positioning and the policy interest, the claim is specific: the internal seams of a radio access network should be specified precisely enough that different suppliers can meet at them, and the control logic above those seams should be open to anyone.

Whether that is a good trade is a real question with a real answer that varies by operator. But the architecture itself is not mysterious.

The problem it responds to

A traditional base station is a single vendor's product from antenna to backhaul. The interfaces between its internal parts exist, but they are the vendor's own, and nothing obliges them to be documented or stable. An operator buying that base station buys the whole thing, and buying the next one from someone else means replacing all of it.

That arrangement produced a small number of very capable suppliers and very little competition at the component level. It also meant that an operator with a good idea about how their network should behave had no way to implement it except as a feature request.

What Is Open RAN? sets out the argument and, importantly, the counter-argument — the parts of the single-vendor model that exist because they solve genuine problems.

Disaggregation: splitting the base station

The first move is to divide the base station into pieces with specified boundaries. The 5G gNB already contemplates a central unit and a distributed unit as separate entities; Open RAN takes that further and pushes the split down into the physical layer.

Why the split point matters

Every candidate split trades transport bandwidth against how much intelligence sits in the remote unit. Split the stack high and the connection between the pieces carries relatively little data, but the radio unit has to be capable and therefore expensive. Split it low and the radio unit gets simpler while the fronthaul carries something close to raw samples, which is enormously demanding.

Split 7.2x is where the O-RAN ALLIANCE landed for the open fronthaul: beamforming and the RF chain in the O-RU, the rest of the physical layer in the O-DU. It is not obviously optimal from any single perspective, which is usually the sign of a genuine compromise.

The interfaces

Disaggregation is only useful if the seams are specified. The O-RAN interface catalogue is what makes multi-vendor assembly possible in principle: the open fronthaul between O-DU and O-RU, E2 from the RAN to the near-real-time controller, A1 for policy from above, and O1 for management.

O-RAN architecture walks through each interface, what crosses it, and which control loop it belongs to — the last point being the one most often skipped, and the one that determines what an interface can usefully be used for.

The RIC: control logic as applications

The RAN Intelligent Controller is the part of Open RAN that is genuinely new rather than a rearrangement of existing pieces.

The near-real-time RIC operates on control loops between roughly 10 milliseconds and a second, hosting xApps that can influence RAN behaviour while it is happening — handover decisions, resource allocation policy, interference coordination. The non-real-time RIC operates above a second, hosting rApps concerned with policy, planning and the slower optimisation problems, and it is where model training naturally sits.

The timescale split is not bureaucratic. It reflects what is physically achievable over an interface that has to cross a network, and it is why an xApp cannot make per-slot scheduling decisions — that loop is orders of magnitude too fast. Understanding which loop a problem belongs to is most of what separates a workable RIC application from one that cannot exist.

Where it meets the AI story

Open RAN and network intelligence are frequently discussed as one thing. They are not the same, but the connection is real: the RIC is the most concrete answer anyone has to the question of where learned control logic would actually run and what it would be allowed to touch.

That makes this section a natural neighbour of the AI-native networks material, and of AI-RAN, which looks at what changes when the radio network itself incorporates learning rather than being optimised from outside.

Getting hands on

The Open RAN tutorial is the practical counterpart to the architecture material: it walks from the component model to writing and running a first xApp, which is the fastest way to develop an intuition for what the E2 interface does and does not let you do.

How to read this section

Read what Open RAN is first if the terminology is new — Open RAN, O-RAN and vRAN get used interchangeably in the trade press and they are not interchangeable. Then the architecture article for the interfaces and the RIC. The tutorial rewards being read last, when the component names already mean something.

The 5G RAN material is useful background throughout. Open RAN changes who builds the parts and how they connect; it does not change what they do.

Prefer to practise? Drill 5G concepts with the flashcard deck (opens on 5G6GTech in a new tab) on 5G6GTech.

Frequently asked questions

What is the difference between Open RAN, O-RAN and vRAN?

Open RAN is the general idea — a radio access network built from components that interoperate across open interfaces. O-RAN, with the hyphen, usually means the O-RAN ALLIANCE and the specific specifications it publishes, which are the dominant concrete expression of that idea. vRAN means virtualised RAN: base station functions running as software on general-purpose compute. They are independent. You can virtualise without opening the interfaces, and a specified interface says nothing about what the software runs on.

Does Open RAN actually save money?

Sometimes, and rarely in the way the business case predicts. Component-level competition can reduce hardware cost, but disaggregation moves cost into integration, testing and operations that a single-vendor deployment charges for implicitly. Operators who report savings tend to be ones with the engineering capacity to absorb the integration themselves. For an operator without that capacity, the sums often do not work.

What is the RIC and why does it matter?

The RAN Intelligent Controller is where control logic that used to be buried inside a vendor's base station becomes an application anyone can write. The near-real-time RIC runs xApps on a 10 ms to 1 s control loop, close enough to influence scheduling behaviour. The non-real-time RIC runs rApps above one second, for policy and optimisation. It matters because it turns RAN optimisation from a feature request into something an operator can implement.

Which functional split does Open RAN use?

Split 7.2x between the O-DU and the O-RU is the one the O-RAN ALLIANCE specified for the open fronthaul, and it is what people usually mean. It divides the physical layer so that beamforming and the RF chain sit in the radio unit while the rest of the physical layer sits in the distributed unit. It is a deliberate compromise: a lower split would need impractical fronthaul bandwidth, a higher one would put too much into the radio unit to keep it cheap.

Is Open RAN production-ready?

In greenfield and targeted deployments, demonstrably yes — several operators run it at national scale. As a drop-in replacement for a mature multi-band macro network, the honest answer is that it depends on the band, the feature set and the operator's integration capability. Feature parity on the long tail of radio features is where deployments usually encounter friction.

Do I need Open RAN experience to work on it?

You need RAN experience. Open RAN changes where functions run and who supplies them; it does not change what the physical layer does or how scheduling works. Someone who understands the air interface and the base station can pick up the interface model quickly. The reverse — knowing the O-RAN interface catalogue without understanding the RAN — is much less useful.