Now the RAN
gets a brain.
Intelligence is what makes Open RAN more than a cheaper radio. Here software steers the network: the two RICs by timescale, the E2 interface with its five verbs (report · insert · control · policy · query), E2SM-KPM to measure and E2SM-RC to act, A1 policies and R1 services, the AI/ML lifecycle — and one energy-saving use case threaded from an overnight model down to a Section Type 4 on the fronthaul. From O-RAN WG3 E2SM-KPM/RC, WG2 A1/R1, and the AI/ML workflow.
The intelligent RAN — RICs, E2, A1, and the AI/ML loop
The player screen is a live animation stage — the two RICs assemble on their timescales, the five E2 verbs light up, a KPM subscription builds, an RC mobility loop runs measure→decide→act, and an energy-saving use case threads down to a Section Type 4, exactly as the narration reaches each idea. Karaoke EN + Persian, fullscreen.
Run one near-RT control loop
A hot cell is at 92% load. Step the loop: the xApp measures (KPM), checks its A1 policy, acts (RC control), and the KPI shifts — all in tens of milliseconds.
E2 is verbs, not fixed messages
E2 carries service models; on top of them, five service types define what the RIC can do.
| Verb | What it does | Round trip? |
|---|---|---|
| REPORT | stream information up on a trigger you define | no (RAN → RIC) |
| INSERT | pause a RAN procedure and inject a decision mid-flight | yes |
| CONTROL | command the RAN to act now (e.g. a handover) | yes (RIC → RAN) |
| POLICY | set guardrails the RAN follows on its own | no round trip |
| QUERY | fetch information on demand | yes |
E2SM-KPM measures (counters, KPIs); E2SM-RC acts (control). RC organises abilities into control styles — Style 3 = Connected-Mode Mobility (HO / CHO / DAPS handover for a selected UE to a target cell).
How the RIC measures the RAN
| Part | Answers | Example |
|---|---|---|
| Event trigger | how often / on what condition to report | every 1000 ms |
| Report style | the shape of measurement | E2-node level / per-UE |
| Measurement list | exactly which counters | PRB usage, active UEs, throughput |
① xApp subscribes with an INSERT trigger for handover measurement reports → ② gNB gathers a UE measurement report → ③ RAN sends a RIC Indication (INSERT) with its preliminary HO decision → ④ xApp confirms / downselects retained bearers & cells → ⑤ xApp sends a CONTROL message that initiates the handover. Measure, decide, act — in tens of milliseconds.
Strategy, apps, and the learning loop
| Interface / thing | Between | Carries |
|---|---|---|
| A1 | Non-RT RIC ↔ Near-RT RIC | policies + enrichment info (A1TD policy types) |
| R1 | rApps ↔ Non-RT RIC framework | service-based framework services |
| E2 / Y1 | xApps ↔ E2 nodes / consumers | KPM measurements, RC control, analytics |
| AI/ML workflow | Non-RT RIC (train) → rApp/xApp (infer) | collect → train → deploy → infer → monitor |
Overnight an rApp (trained via AI/ML) decides to sleep cells → expresses it as an A1 policy → an xApp watches live KPM → issues an E2 RC control → the O-DU sends a Section Type 4 slot-config command (Chapter 3) → the O-RU powers down the carrier. One thread from an AI model to a bit on the wire.
🛠 Engineer detail block — what you'll actually meet in the field
- Timescale decides the RIC. If a use case must react in < 1 s, it is an xApp on E2. If it optimises over minutes/hours, it is an rApp with an A1 policy. Putting a fast loop in the Non-RT RIC is the classic design error.
- E2 nodes expose less than the spec dreams. The KPM/RC RAN-function list a real E2 node advertises is often narrower than the standard — always check what measurements and control actions the node actually supports before designing an xApp.
- INSERT is the powerful, dangerous one. It pauses a live RAN procedure waiting for the RIC. A slow or dead xApp on an INSERT loop stalls real users — budget its latency like the near-RT loop it is.
- A1 sets guardrails, not commands. Do not expect A1 to trigger a handover; it sets the policy the Near-RT RIC then enforces itself. Strategy downhill (A1), tactics on the ground (E2).
- The AI/ML loop never ends. A deployed model drifts as traffic changes. Without the monitor→retrain arm, your "AI" silently rots — the closed loop is the product, not the one-off model.