Telecommunications - 5G

Their RIC Was Making Decisions on 2-Second-Old Data

Open RAN promises intelligent network optimization. But when your telemetry takes 2.3 seconds to reach the RIC, you're optimizing based on what the network looked like 2.3 seconds ago. In mobile, that's ancient history.

3,847 Cell Sites
89ms RIC Latency (was 2.3s)
47% Lower Splunk Bill

Client

European Telecom Operator

Industry

Telecommunications

Use Case

O-RAN Telemetry Processing & Network Optimization

Products Used

Expanso, OpenShift SNO, Red Hat Stack

Timeline

12 sites pilot, full rollout in 14 weeks

ROI

47% reduction in observability platform costs

The Challenge

The network ops team had a dashboard problem. Their O-RAN deployment was generating 2.1GB of telemetry per cell site per hour. Multiply that by 3,847 sites and you're looking at 8TB/hour hitting your observability platform. Splunk was happy to invoice them accordingly.

  • 3,847 cell sites generating 2.1GB/hour each - 8TB/hour total
  • Near-RT RIC latency was 2.3 seconds - too slow for real optimization
  • Splunk ingestion costs were $847K/month and climbing
  • Backhaul links saturated during peak hours
  • Red Hat mandate: everything runs on OpenShift or it doesn't run
  • Four different RAN vendors, four different telemetry formats

The Solution

We put Expanso on OpenShift SNO at each cell site. Raw telemetry stays local. The site computes aggregates, detects anomalies, and transforms everything to OTLP before sending. Splunk gets 450MB/hour instead of 2.1GB. The RIC gets what it needs in 89ms instead of 2.3 seconds.

Local Aggregation

Each site rolls up 15-second metrics into 5-minute summaries. Anomaly detection runs locally - Splunk only sees events that need attention. Raw data stays on-site for 72 hours if you need it.

OpenShift SNO Native

Runs as a standard OpenShift workload on their existing SNO deployments. Same GitOps pipeline, same monitoring, same security policies. IT didn't have to learn anything new.

Multi-Vendor OTLP

Samsung, Nokia, Ericsson, Mavenir - each has their own telemetry format. Expanso translates everything to OTLP at the edge. Central systems see one consistent format.

The Results

The RIC finally works like it's supposed to. Network optimization decisions happen on 89ms-old data instead of 2.3 seconds. The Splunk bill dropped 47% - not because they're logging less, but because they stopped sending noise.

78% Telemetry Reduction
89ms RIC Latency
47% Cost Reduction
14 weeks Full Rollout
  • Telemetry volume dropped from 2.1GB to 450MB per site per hour
  • RIC optimization latency improved from 2.3 seconds to 89 milliseconds
  • Splunk monthly cost reduced from $847K to $449K
  • Backhaul utilization dropped 31% - more headroom for customer traffic
  • Single OTLP format across all four RAN vendors
  • 12-site pilot validated in 3 weeks, remaining 3,835 sites in 11 weeks
  • Same OpenShift GitOps workflow they already had
"We were paying Splunk to store telemetry we never looked at. Ninety percent of it was just 'everything's fine, everything's fine, everything's fine.' Now we only send the interesting stuff, and the RIC actually has time to react before the problem goes away on its own."
Network Operations Director, European Mobile Operator
Background

Drowning in telemetry?

If your observability bill keeps climbing and your RIC decisions are based on stale data, we should talk. We've done this at scale across multiple RAN vendors.