RIC and the operational layer:
why network sharing still needs structured execution

What is RIC?

Mobile networks are being asked to do more with the same resources: more traffic, more differentiated services, tighter energy targets, and budgets that are not growing to match. Across the industry, the answer is automation, and much of the current attention is focused on the radio access network — historically the most expensive and the most closed part of the network.

The RAN Intelligent Controller, or RIC, sits at the centre of the O-RAN architecture defined by the O-RAN Alliance, whose stated direction is an open, intelligent, virtualised and fully interoperable RAN. The idea behind the RIC is simple to state: take control logic that used to live inside individual base stations and move it into software that works across the network over open interfaces. The radio network becomes programmable, and optimisation becomes something you can deploy as an application rather than wait for in a vendor release.

How RIC works in the O-RAN stack

In practice there are two controllers. The Near-Real-Time RIC operates close to the radio, in control loops between roughly ten milliseconds and one second. It hosts applications called xApps that make fast, direct adjustments: handover optimisation, traffic steering, load balancing, interference management and energy saving. The Non-Real-Time RIC lives inside the Service Management and Orchestration layer, or SMO — the orchestration environment around the whole stack — and works in loops longer than a second. Its applications, called rApps, handle the slower, more deliberate work: developing longer-term optimisation policies, training the AI and machine-learning models that the faster loops rely on, analytics, and assuring the service levels of network slices.

Commercial RIC platforms are shipping, and early operator deployments have reported meaningful performance gains — with most of the practical traction so far on the non-real-time side, where the risk of intervening in a live radio network is lower. The technology is still maturing, but the direction is clear: the RIC helps networks think and react. Decisions inside the radio network are increasingly made by software, continuously, at a pace no operations team could match.

Where the operational gap remains

Everything the RIC does, however, happens inside one operator's network. It makes your radios run better, your slices behave as promised, your energy bill smaller. Reacting intelligently is only one part of the story. What the RIC does not answer is a question that sits one level up: when one service provider needs capacity and another service provider has it, how do those two find each other, agree terms, and hold each other to them?

That is a different kind of loop — a commercial one, between organisations rather than between network functions. Even in a network full of intelligence, someone still must interpret the demand, match it to relevant capacity, align the stakeholders involved, and make the whole arrangement repeatable. Today that work mostly runs on bespoke bilateral agreements, spreadsheets and manual coordination: each arrangement negotiated from scratch, verified by hand, and difficult to repeat. Network intelligence is valuable. Operational fit is what makes it usable.

How TEASOL Exchange fits

This is the layer TEASOL Exchange is being built for: structured demand-to-capacity matching between parties. A capacity need is expressed in a structured form, matched to available capacity on another network, agreed under clear terms, and monitored against its service-level agreement — in a way that is transparent, repeatable and operationally realistic. The platform is technology- and vendor-agnostic by design, and it brings its own intelligence to this layer: AI-powered matching and demand prediction, applied to the market-facing flow of analysing demand, matching resources and automating the resulting agreements. It does not compete with the intelligence inside any single network — it complements it, one layer up.

And the connection to the RIC layer is not just conceptual. Within the O-RAN architecture, TEASOL is developing the TEASOL rApp: a monitoring application hosted on the Non-RT RIC that continuously measures utilisation, spare capacity and SLA-relevant KPIs — per cell, per slice and per sharing party — over the standard O-RAN interfaces, with data collected via O1 and exposed via R1. That standards-based design keeps it portable across conformant Non-RT RIC and SMO implementations, independent of any single vendor. The rApp is deliberately read-only towards the live network: it observes and quantifies, turning invisible capacity headroom into a trustworthy signal, and publishes that signal to the Exchange Platform. The division of labour is clean — the rApp is the network-facing intelligence that makes sharing decisions well-informed; the Exchange is the commercial layer that acts on them.

Sewn this way, the RIC and an exchange layer are not competing ideas but connected ones — parts of a single automation continuum, and TEASOL deliberately works across the seam between them: an rApp inside the network intelligence layer, and the Exchange in the commercial layer above it. Radio-level intelligence optimises how a network runs. Slice and service management decides what the network offers. And an inter-party layer above that decides whose demand meets whose capacity, on what terms, with what assurance. Intelligence exists at every one of these layers; what differs is the question each layer's intelligence is answering.

Where structured matching earns its keep

The value of structured matching becomes clearest when service demand changes and execution has to happen in a real operational environment. An MVNO needs capacity access in an area its host does not cover well. A neutral host must coordinate several operators at a single venue. A private network needs to expand temporarily beyond its own footprint. Two operators want to move a sharing arrangement from a static contract to a dynamic one, with automated visibility on whether the agreed service levels are actually being met. In each of these cases, the intelligence to run the networks involved may already exist; what is missing is a structured, repeatable way to arrange the sharing itself. That same capability underpins the solutions on our website — Network Sharing Exchange, Slice Exchange, Private Network Marketplace and Neutral Host Trading Platform — which are different entry points into one underlying layer, across the telecom ecosystem rather than for a single operator type.

Network intelligence needs operational fit

RIC is part of a broader shift toward more intelligent, open and interoperable networks — a shift that is also a central theme in the Future Network Services program, in which TEASOL participates. Our focus in that shift is a specific one: helping intelligent networks become operationally usable between parties, not only within them. We are in the validation phase, testing whether structured demand-to-capacity matching holds up in real telecom environments, with real operational constraints. If you are working on RAN automation, slicing assurance or network sharing and see the same gap between an optimised network and a shareable one, we would be glad to compare notes.

RIC brings intelligence to the network. TEASOL is working to turn that intelligence into structured demand-to-capacity matching and repeatable execution — from the rApp that sees the capacity to the Exchange that arranges its use.