OPEN OPERATIONS AI-RAN RESEARCH

The operations layer
for AI-RAN.

open OSS turns live network observations into structured evidence, operational context and policy-gated decisions—giving engineers a controlled place to study how AI can improve the RAN.

Explore the platform Read the technical position

CURRENT FOUNDATION Live, read-only Open5GS assurance

PLANNED CONTROL PATH Recommend → approve → verify

REAL TELEMETRY EXPLAINABLE EVIDENCE POLICY BOUNDARIES MEASURABLE OUTCOMES

01 Observe what is real

Live functions, inventory, sessions, logs, KPIs and alarms.

02 Explain what changed

Correlated evidence with provenance, scope and confidence.

03 Control what may act

Policy, approval, audit and rollback before autonomy.

PRODUCT GALLERY

One platform.
Four operational views.

Select any image to inspect it at full size. The four files are kept separately in the images folder so the gallery can be updated without changing the page structure.

CLICK A VIEW TO ENLARGE · ARROW KEYS MOVE BETWEEN IMAGES · ESC CLOSES

A CONTROLLED DECISION SYSTEM

Intelligence is useful.
Authority must stay explicit.

open OSS separates observation, reasoning, policy and execution. That separation makes every recommendation inspectable and prevents an AI model from becoming an ungoverned network controller.

01 / DATA

Evidence plane

Adapters collect health, topology, inventory, logs, counters and KPI observations without inventing substitute measurements.

Source provenance
Capability discovery
Time-aligned snapshots

02 / CONTEXT

Operations plane

Assurance, threshold profiles and alarm correlation turn raw changes into operational cases engineers can inspect.

Scoped KPI analysis
Alarm intelligence
Maintenance awareness

03 / REASON

Decision plane

A future AI service ranks candidate actions and explains expected impact, confidence and the evidence used.

Model-independent contract
Candidate ranking
Explainable reasoning

04 / CONTROL

Authority plane

Deterministic policy decides whether a candidate may proceed, requires approval or must be denied.

Explicit permissions
Operator approval
Audit and rollback

TECHNICAL POSITION / 01

NO UNIVERSAL PLUG-AND-PLAY CLAIM

Provider-neutral at the boundary. Specific at the adapter.

The current working adapter is for Open5GS. open OSS validates a provider-neutral API at its application boundary, but another 5G core or RAN platform still needs an adapter that maps its telemetry, inventory and supported control operations into that contract.

This is the honest route to multi-vendor integration: one stable operations model, with explicit adapters for the interfaces each platform actually exposes.

IMPLEMENTEDOpen5GS observability adapter

ARCHITECTUREProvider-neutral OSS contract

REQUIRESAdapter per external platform

WHAT AI-RAN MEANS HERE

AI for the RAN.
Not AI without limits.

The AI-RAN Alliance separates the field into AI-for-RAN, AI-and-RAN and AI-on-RAN. open OSS is initially focused on the first: using operational data and AI-assisted reasoning to improve how a radio network is understood, maintained and optimised.

THE DECISION AUTHORITY STACK

AI decision service

Interprets evidence and ranks candidate actions.

PROBABILISTIC

Policy guard

Checks scope, risk, permissions and required approval.

DETERMINISTIC

Operator authority

Approves, rejects or modifies a network-changing action.

ACCOUNTABLE

Execution adapter

Applies only an authorised action and records the result.

BOUNDED

AI-for-RAN

AI assists radio optimisation, operational efficiency, resource management, fault analysis and predictive maintenance.

AI-and-RAN

AI and RAN workloads share compute infrastructure, with orchestration balancing utilisation and performance.

AI-on-RAN

RAN infrastructure hosts edge AI workloads and applications close to users and real-time data.

open OSS role

The operations and governance layer that connects evidence, reasoning, policy, operator authority and outcome verification.

ADAPTER CONTRACT / LAB VIEW 01 ACTIVE

IMPLEMENTED Open5GS

STATUS Live observability

EXTENSION Other 5G core

STATUS Adapter required

EXTENSION O-RAN / RIC

STATUS Interface mapping required

NORMALISED OSS CONTRACT


          health · capabilities · functions · RAN · UEs · sessions · KPIs ·
          events · permitted actions

CONNECT THROUGH EXPLICIT ADAPTERS

One operations model.
Many possible sources.

open OSS does not need every platform to expose identical internals. An adapter translates the platform’s real interfaces into a stable OSS contract. This preserves the same assurance, reasoning and governance workflow while keeping platform-specific behaviour visible.

For O-RAN research, those integrations may include O1 management data, R1 services for rApps, A1 policy guidance or E2-enabled near-real-time control—depending on which components are present in the lab. open OSS is not claiming those interfaces are implemented today.

TODAY Open5GS + local Agent

BOUNDARY Provider-neutral API

EXPANSION Adapter-led integration

LAB DOCUMENTATION

Connect the lab.
Keep every boundary visible.

These instructions describe the tested v0.13.0 topology. They separate the deployment envelope from the telemetry path, then show exactly where srsRAN and the future AI decision service enter the system.

RAYDEO 5G LAB / CURRENT CONNECTION MODEL READ-ONLY NETWORK ACCESS

LAB HOST / ORCHESTRATION raydeo | terminal

01 / CORE Docker + Open5GS 5GC functions · metrics · logs · inventory

DOCKER CLI / EXEC

02 / BRIDGE open OSS Agent Normalises evidence · REST + SSE · port 4780

HTTP API / EVENT STREAMS

03 / OPERATIONS open OSS Overview · Assurance · KPI · Alarms · Network

The exact data path

Open5GS in Docker → open OSS Agent → open OSS. raydeo | terminal owns and presents the 5G Lab, but it is not an extra telemetry proxy. The desktop application connects directly to the Agent URL.

DAILY STARTUP / TESTED v0.13.0

Start from the network and move outward.

Keep Docker and the Raydeo 5G Lab running before starting the Agent. Start open OSS last so its first validation sees a real core and a complete capability response.

01
Start raydeo | terminal and the 5G Lab
Confirm Docker Desktop is running and the Open5GS core node is active inside the lab.

LAB HOST
02
Confirm the core container
The Agent discovers the first running container whose name contains raydeo-5gs-core.

DOCKER
03
Start the Agent on the Docker host
Run it on the Mac or Linux host—not inside the Open5GS container—and leave that terminal open.

PORT 4780
04
Validate the local API
A healthy response proves the bridge can inspect Docker and reach the supported Open5GS interfaces.

REST + SSE
05
Start open OSS and validate Settings
Use http://127.0.0.1:4780/api/v1, select Validate API, then open Overview.

DESKTOP

01 / LAB Confirm Open5GS is running

docker ps --filter "name=raydeo-5gs-core" \
  --format '{{.Names}}\t{{.Status}}'

02 / AGENT Install, inspect and start

cd ~/Downloads/open-oss-v0.13.0-scoped-kpi-expansion/open-oss-agent
npm install
npm run check
npm run discover
npm start

03 / API Verify health and capabilities

curl -s http://127.0.0.1:4780/api/v1/health \
  | python3 -m json.tool
curl -s http://127.0.0.1:4780/api/v1/capabilities \
  | python3 -m json.tool

04 / DESKTOP Start open OSS

cd ~/Downloads/open-oss-v0.13.0-scoped-kpi-expansion/open-oss-main-layout
npm install
npm run check
npm start

05 / STREAM Watch live assurance events

curl -N http://127.0.0.1:4780/api/v1/events/stream

06 / LOGS Watch the live AMF stream

curl -N http://127.0.0.1:4780/api/v1/logs/amf/stream

Remote access

The default Agent binds to 127.0.0.1. If open OSS runs on another machine, use a strong token, a TLS reverse proxy and a restricted origin. Never expose this development API directly to the public internet.

SRSRAN PROJECT / OPEN5GS

Add real radio at the core boundary.

srsRAN Project supplies the gNB. It connects to the Open5GS AMF over N2/NGAP and to the UPF over N3/GTP-U. Once Open5GS sees the gNB, UE and PDU session, the existing Agent can expose that core-side evidence to open OSS.

N2 / NGAP gNB → AMF SCTP · 38412

N3 / GTP-U gNB → UPF UDP · 2152

OBSERVABILITY Open5GS → Agent METRICS · INFO API · LOGS

UE / SDRNR radio

→

RANsrsRAN gNB

→

5GCOpen5GS

→

OSSAgent + open OSS

Choose a routable topology

For a real SDR lab, native Linux is the cleanest route. The gNB host must reach the AMF N2 address and the UPF N3 address. Docker Desktop on macOS adds a VM boundary, so its internal container addresses should not be assumed reachable from an external Linux radio host.

Align network identity

Match PLMN, TAC and S-NSSAI between srsRAN and Open5GS. Add the real or simulated UE credentials to Open5GS before attachment.

Configure the gNB

Set the AMF address, local N2 bind address and supported tracking area. Select the RF driver and radio configuration appropriate to your SDR, licensed band and isolated test setup.

Start in dependency order

Start the 5GC first, then the gNB, then the UE. Confirm the gNB reports an AMF connection before diagnosing radio attachment.

GNB CONFIGURATION TEMPLATE Replace every angle-bracket value

cu_cp:
  amf:
    addr: <OPEN5GS_AMF_NGAP_IP>
    port: 38412
    bind_addr: <GNB_N2_IP>
    supported_tracking_areas:
      - tac: <TAC>
        plmn_list:
          - plmn: "<MCCMNC>"
            tai_slice_support_list:
              - sst: 1

ru_sdr:
  device_driver: uhd
  device_args: type=b200

START + VERIFY Paths vary with the srsRAN build

sudo ./build/apps/gnb/gnb \
  -c configs/<your-gnb-config>.yml

curl -s http://127.0.0.1:4780/api/v1/gnbs \
  | python3 -m json.tool
curl -s http://127.0.0.1:4780/api/v1/ues \
  | python3 -m json.tool

Current integration boundary

open OSS currently sees the radio through Open5GS evidence. It does not yet ingest srsRAN scheduler, PHY, MAC or RLC telemetry, and it cannot change gNB parameters. That deeper path requires a dedicated srsRAN telemetry/control adapter or an O-RAN RIC integration.

PLANNED AI-RAN DECISION LOOP

The model recommends. Policy decides what is permissible.

The first implementation targets AI-for-RAN: use trusted operational evidence to study a bounded optimisation, keep an accountable person in the loop and prove the outcome with real before-and-after measurements.

01 / EVIDENCE

Build a trusted case

Agent snapshots, KPI history, alarm evidence, maintenance state and experiment scope form a time-aligned input package.

02 / AI SERVICE

Rank candidate actions

A local or hosted model returns structured recommendations, evidence references, expected impact, confidence and a rollback proposal. Internet access is optional—not the source of network truth.

03 / POLICY

Apply deterministic limits

An allowlist, scope, maximum parameter delta, observation window and risk class decide whether the candidate is denied or may be presented for approval.

04 / OPERATOR

Authorise deliberately

The engineer sees the evidence and can approve, reject or modify the candidate. Every decision is timestamped and attributable.

05 / ADAPTER

Execute only in lab scope

A platform-specific adapter applies an approved change to the simulator, gNB or policy endpoint. No generic AI model receives unrestricted network credentials.

06 / VERIFY

Measure and retain the result

open OSS compares the same KPI before and after the action, records side effects and triggers rollback when the experiment breaches its guard conditions.

FIRST CONTROLLED STUDY

Mobility optimisation with one measurable outcome.

01 Detect a sustained handover condition.
02 Rank pre-defined, bounded response profiles.
03 Require policy conformance and operator approval.
04 Apply through the lab-specific adapter.
05 Compare handover KPI and automatically retain evidence.

Where O-RAN fits

A future Non-RT RIC/rApp path may use R1 services and A1 policy; near-real-time control may use an E2-connected Near-RT RIC. open OSS remains the operations, evidence and governance layer—it does not replace the specialised RIC control loops.

THE FUTURE AI-RAN PLAYGROUND

Prove the loop
before closing it.

The playground is intended for controlled R&D: create a measurable network condition, observe it in open OSS, ask an AI service for a recommendation, enforce policy, approve the action and verify the KPI outcome.

The result is a complete experiment—not a presentation about automation. Every step leaves evidence that can be replayed, compared and challenged.

Current releases remain network read-only. The decision and execution stages shown here describe the planned playground control path, not an already-available production automation feature.

CONTROLLED RESEARCH RUN / MOBILITY-021 012 CYCLES

01 Observe Capture real state

02 Detect Find a condition

03 Reason Rank candidates

04 Authorise Policy + operator

05 Execute Lab-only adapter

06 Verify Measure outcome

RF ANOMALY REVIEW CELL-07 · KPI WINDOW 15M

EVIDENCE

HANDOVER CANDIDATE RANKING GNB-02 · 03 OPTIONS

REASON

POLICY CONFORMANCE CHECK ACTION-21 · PROFILE P-04

GUARDED

BEFORE / AFTER VERIFICATION MOBILITY · BASELINE 91.8%

MEASURE

EARN EACH DEGREE OF AUTONOMY

Four modes. One visible authority model.

Autonomy should increase only when the preceding mode has produced trustworthy evidence, repeatable outcomes and safe failure behaviour.

Observer

Read-only telemetry, assurance, KPIs, alarms and evidence.

CURRENT FOUNDATION

Adviser

AI produces ranked recommendations with confidence and provenance.

PLANNED

Approved control

Policy-valid actions require an accountable operator decision.

LAB ROADMAP

Closed-loop sandbox

Pre-approved policies may act within narrow, reversible lab scope.

RESEARCH TARGET

TECHNICAL BASIS

Aligned with the industry. Honest about the implementation.

The public position on this page is grounded in current AI-RAN and O-RAN definitions, plus the real interfaces used by the Open5GS lab. Standards alignment is a direction for interoperability—not a claim of certification.

AI-RAN Alliance AI-for-RAN · AI-and-RAN · AI-on-RAN

↗ 02

O-RAN Alliance WG2 Non-RT RIC · R1 · A1 policy and AI/ML workflow

↗ 03

Open5GS metrics Prometheus observations exposed by supported functions

↗ 04

Open5GS information API Live gNB, UE and PDU-session data

↗ 05

srsRAN + Open5GS Documented gNB, core and UE integration sequence

↗ 06

srsRAN configuration reference gNB YAML, AMF connection and radio configuration

↗

OPEN OSS / IN DEVELOPMENT

Build intelligence on evidence. Place autonomy behind policy.

open OSS is a free-to-use Raydeo project for telecom engineering, experimentation and AI-RAN research. Source code remains private during the current development phase.

LAB DEVELOPMENT ACTIVE

The operations layer for AI-RAN.

One platform. Four operational views.

Intelligence is useful. Authority must stay explicit.