Built on the Telecom Foundation Model — Product 02

Open RAN, orchestrated
by intent,
not by scripts.

Most SMO platforms are configuration management dressed up as orchestration. You write the scripts. You maintain the policies. You intervene every time the network changes. Otter Agentic SMO replaces that model with AI agents built on our Telecom Foundation Model — agents that observe, reason, and act, within guardrails you define.

17–25% Energy savings per cell site
15 min SLA breach prediction horizon
Days Time to onboard a new O-RAN component
L4 TM Forum autonomous network target
Design targets — to be validated with design partners
Designed for O-RAN-compliant deployments from leading vendors
Nokia Ericsson Samsung Mavenir Kubernetes OpenStack

Traditional SMO is configuration management with a new name.

The promise of Open RAN is a disaggregated, vendor-agnostic, intelligently managed radio network. The reality for most operators is that their SMO is a collection of scripts, static policies, and manual change management processes that require constant human intervention to keep pace with the network.

01 — Script sprawl
3,000+
Lifecycle management scripts in a typical operator's SMO environment. Adding a new rApp means writing new deployment, monitoring, and rollback scripts. New vendor? Another few hundred scripts to maintain.
02 — Static policies
Monthly
How often most operators update their RAN optimisation policies. Traffic patterns, interference conditions, and subscriber behaviour change by the hour. You are always optimising for last month's network.
03 — Autonomy gap
4%
of operators have reached TM Forum Level-4 conditional autonomy. The gap isn't ambition — it's the absence of an orchestration layer intelligent enough to close the loop between telemetry and action without human intervention at every step.

A continuous closed loop: observe, reason, act, verify.

Agentic SMO replaces the static policy-and-script model with an always-on agentic loop. Agents hold network state, reason over operator intents, take actions, and verify their own outcomes — without waiting for a human to trigger the next step.

01 / Observe

Continuous network state

Subscribes to all O-RAN data sources — O1 PM/FM streams, R1 data services, and cloud infrastructure metrics. Builds and continuously updates a model of network state: KPIs, topology, resource utilisation, slice SLAs, and energy consumption.

Data sources O1 NETCONF/YANG · R1 data services · Prometheus · InfluxDB · cloud telemetry
02 / Reason

Intent-aware decisions

AI agents evaluate current network state against operator-defined intents and guardrails. They identify optimisation opportunities, forecast SLA breaches up to 15 minutes ahead, and resolve conflicts between competing agent objectives before acting.

Engine Multi-agent framework · intent graph · conflict resolution · breach prediction
03 / Act

Targeted, logged actions

Deploys rApps to the Non-RT RIC via R1, pushes A1 policies to the Near-RT RIC for xApp control, and scales cloud-native RAN workloads via O2. Every action is logged with full rationale, expected KPI impact, and a rollback plan.

Interfaces R1 rApp lifecycle · A1 policy API · O2 cloud management · O1 config push
04 / Verify

Automatic rollback

Monitors every action against its expected KPI outcome. If the expected improvement doesn't materialise within the defined window, the agent automatically rolls back and escalates to the operator. Successful actions feed back to improve future decisions.

Mechanisms Canary evaluation · A/B comparison · automatic rollback · feedback loop

Specialised agents.
Coordinated outcomes.

Each Otter agent operates within a defined domain and operator-approved guardrails. The agent coordinator resolves conflicts — for instance, when the Energy agent proposes sleeping cells that the SLA Guardian needs active. Operators see every decision and can override at any time.

Energy Optimisation Agent

Continuously monitors cell-level traffic, load, and KPI telemetry to identify windows where radio resources can be safely reduced. Proposes cell sleep schedules and transmit-power reduction policies, then deploys them as energy rApps to the Non-RT RIC.

Dynamic cell sleep scheduling — traffic-aware, SLA-safe
Transmit power stepping during low-load periods
Automatic wake-up on demand surge detection
Rollback on KPI degradation within configurable window
Interfaces: O1 · R1 · Non-RT RIC · energy-sleep rApp family
SLA Guardian Agent

Monitors per-slice KPIs — latency, throughput, packet loss, availability — against contracted SLAs. Uses trend analysis to predict degradation up to 15 minutes before subscribers are affected, then preemptively adjusts resource allocations via A1 policy.

Per-slice SLA monitoring with 15-minute prediction horizon
Priority-aware resource allocation: URLLC > eMBB > mMTC
Preemptive A1 policy push before SLA breach occurs
Operator alert with evidence if guardrails prevent action
Interfaces: A1 · Near-RT RIC · slice-guardian xApp · O1 PM
rApp Lifecycle Agent

Manages the full lifecycle of rApps hosted in the Non-RT RIC — from catalogue discovery through onboarding, staged canary rollout, automated promotion, version management, and graceful retirement. Eliminates the bespoke scripting that prevents operators from running more than a handful of rApps simultaneously.

Automated onboarding from signed rApp catalogue
Canary rollout with configurable confidence thresholds
Dependency resolution and version conflict detection
Graceful retirement with traffic drain and rollback
Interfaces: R1 · Non-RT RIC · rApp catalogue · O1
Capacity Planning Agent

Analyses multi-day traffic trends, event calendars, and historical patterns to forecast demand. Pre-scales cloud-native CU and DU workloads via the O2 interface ahead of known peaks — stadiums, commuter surges, planned outages — without waiting for congestion to materialise.

Traffic trend analysis and demand forecasting
Event-aware pre-scaling via O2 cloud interface
Coordinated with Energy Agent to avoid conflicting actions
Scale-down after peak with graceful traffic drain
Interfaces: O2 · Kubernetes · OpenStack · O1 PM telemetry

Built on open interfaces.
Not locked to any vendor stack.

Otter Agentic SMO implements the O-RAN Alliance SMO interface specifications, enabling it to work with any O-RAN-compliant RU, DU, CU, or RIC regardless of vendor. The same SMO manages Nokia and Ericsson and Samsung simultaneously, over the same standardised interfaces.

O1
Operations & management
Configuration, fault, performance, and software lifecycle management of all O-RAN network functions — O-DU, O-CU-CP, O-CU-UP, O-RU — over NETCONF/YANG.
A1
AI/ML policy delivery
SMO / Non-RT RIC to Near-RT RIC policy and enrichment information interface. Used by the SLA Guardian and Energy agents to push real-time control policies to xApps.
O2
Cloud infrastructure
SMO to cloud management. Lifecycle management of virtualised and containerised RAN workloads across OpenStack, Kubernetes, and major cloud providers. Used by the Capacity Planning agent.
R1
rApp services
SMO services exposure to rApps. Covers registration, discovery, subscription to network data, and publishing of optimisation actions. The primary interface for the rApp Lifecycle agent.

Sits on top of your Open RAN stack.

Agentic SMO is an additive intelligence layer. It does not replace your Non-RT RIC, Near-RT RIC, or cloud infrastructure — it orchestrates them. It's designed to integrate in weeks, starting in read-only observer mode before any autonomous action is enabled.

O-RAN Non-RT RIC
viaR1 interface · rApp catalogue · A1 mediator
Core
O-RAN Near-RT RIC
viaA1 policy interface · xApp coordination
Core
O-RAN O-DU / O-CU
viaO1 config management · NETCONF/YANG · RESTCONF
Core
Cloud infrastructure
viaO2 · Kubernetes · OpenStack · AWS / Azure / GCP
Core
Ericsson Cloud RAN
viaO1 NETCONF · A1 · Ericsson rApp SDK compatibility
Vendor
Nokia AirScale / ReefShark
viaO1 · A1 · Nokia SMO adapter
Vendor
Samsung vRAN · Mavenir
viaO1 · A1 · O-RAN-compliant interfaces
Vendor
Service assurance
viaPrometheus · Grafana · DCAE · webhook outbound
Outbound

Agentic SMO versus the alternatives.

Operators evaluating their SMO strategy typically have three options: a vendor-bundled SMO that ties them to one equipment supplier, an open-source SMO they must staff and maintain themselves, or a purpose-built agentic layer that adds intelligence without adding headcount.

Dimension
Vendor-bundled SMO
Open-source SMO
Otter Agentic SMO
Intelligence model
Rule-based scripted policies
Community rApps, manual lifecycle
Agents on a Telecom Foundation Model, with intents and guardrails
rApp lifecycle
Vendor-specific tooling, proprietary formats
Manual CI/CD scripting per rApp
Automated onboarding, canary, promotion, rollback
Multi-vendor RAN
Optimised for own equipment
Spec-compliant, limited validation
Nokia, Ericsson, Samsung, Mavenir — one engine, open interfaces
SLA assurance
Alert-driven, reactive
Depends on rApp quality
Predictive — 15-minute breach horizon, preemptive
Time to adapt
Change management cycle — days to weeks
Developer cycle — hours to days
Sub-minute for policy updates, automated for rApps
Entry effort
Long integration, vendor lock-in
Self-managed complexity, ops overhead
Additive deployment, design-partner PoC, no lock-in

Intent defined. Agents deployed.
Shape the SMO with us.

We're partnering with a small number of operators and O-RAN vendors as design partners. We start in read-only observer mode on your O-RAN environment, demonstrate what the agents would do, and you approve any autonomous action before it's taken. No rip-and-replace, no long-term commitment.

Design-partner program · On-premises or cloud · Your data never trains another operator's model