Learn O-RAN O1 interactively

You'll interact with a real simulated O-RAN network function and see how O1 management actually works - NETCONF/YANG, configuration, fault management, performance management - by doing it, not just reading about it. No account, no installation, nothing to lose: every step uses this console's real functionality against the real simulator, and any configuration the tutorial changes is restored automatically when you finish.

8 interactive steps · about 5 minutes

1. What is O1?
2. Meet the Network Function
3. Explore its YANG model
4. Establish the NETCONF session
5. Read configuration (GET-CONFIG)
6. Change configuration (EDIT-CONFIG)
7. Create and investigate a fault
8. Observe performance

O1 Guided Demo Complete

You have explored:

• a managed O-RAN network function
• YANG data models
• NETCONF capabilities
• GET-CONFIG
• EDIT-CONFIG
• fault management
• performance management

Simulator Status

Simulator Intervals

Alarm Generation Rate

Burst Actions (testing/demo - immediate, one-shot, capped to protect the host)

Browser UI → O1 Simulator Console → NETCONF → YANG-managed NF → O-RAN Simulator

Every action below is a genuine round trip through this whole chain: your browser calls this dashboard's own backend, which opens a real NETCONF session (SSH, RFC 6241) to the simulator's NETCONF server, which reads or writes the actual YANG-modeled running configuration of the simulated O-RAN network function. Nothing shown as a "request" or "reply" below is synthesized - it's the real XML exchanged over that session.

O1 Simulator Console → AI Agent for SMO rApps → Gemini

This is a genuinely separate service, not a page of this dashboard: a standalone FastAPI application (o1-agent-demo, its own container, reverse-proxied at /agent-ui/ and /api/agent/*) that polls this simulator's own /api/state and /api/pm/* endpoints, runs deterministic rule-based anomaly evaluation, and sends genuine requests to Google's Gemini API for root-cause reasoning on whatever gets flagged. Everything below - the live pipeline events, the insight feed, the Gemini narratives - is real, produced by that separate service in real time, not scripted or replayed for this page.

It is read-only and not an rApp itself - it never calls a mutating endpoint on this simulator, never makes an SMO decision, and exposes no action/command endpoint of its own (every route under /api/agent/* is a GET). It publishes structured insight records for a downstream rApp to consume - see its own integration guide for the feed contract, or "AI Agent for SMO rApps" under About for the full architecture writeup. As everywhere else in this console, the one thing that is simulated is the underlying O-DU/O-RU radio network state itself - the agent's own reasoning about it is real. All timestamps in the panel below are UTC.

Performance Measurement Jobs

Scope: All O-DUs · Granularity Period: 15 minutes (simulated network time) · Demo Acceleration: ON - 15 simulated minutes are compressed into 60s of real time for this public demo · Reporting: File-based PM · PM Files generated: 0 (0 retained).

Network Overview (latest completed PM period)

Values below are derived aggregations from the NRCellDU measurements contained in the latest PM file (sum for additive quantities, unweighted average for utilization) - not raw measurements directly reported for the O-DU itself. Expand a row to see the actual per-cell raw measurements they're derived from.

Raw PM measurements - reported directly for this NRCellDU managed object in the source PM file, never regenerated on request.

What This Is

A working demo of the O-RAN O1 interface - the standardized management interface between an SMO/OSS and a RAN network function, based on NETCONF/YANG (RFC 6241 / RFC 7950). The simulator side is a real O-DU (O-RAN Distributed Unit) built from O-RAN Software Community's sim-o1-interface project (ntsim-ng) - it runs an actual NETCONF server backed by sysrepo/netopeer2, implementing standard 3GPP TS 28.541 Network Resource Model YANG modules (ManagedElement, GNBDUFunction, NRCellDU, NRSectorCarrier, AlarmList). The network functions are simulated. The management interactions are real. Configuration, topology, alarms, NETCONF RPCs, YANG schemas, and O-RAN supervision exchanges come from live O-RAN SC simulators. Simulated measurements, derived KPIs, and application-managed functions are explicitly identified throughout the playground.

Containers

Console Pages

PM Architecture

Performance Management demonstrates a 3GPP-style file-based PM reporting workflow using simulated O-DU measurement values. It is not described as "3GPP compliant" or "3GPP conformant" - those terms are reserved until the claims below are actually validated, not just structurally modeled. Three distinct layers make up the implementation:

• Simulator-backed: the managed topology (10 O-DUs / 200 NRCellDUs, dynamically read - never hardcoded) and every measurement's raw source counter value are obtained through genuine NETCONF <get>/<edit-config> against this simulator's real nts-cell-pm.yang pm-counters.
• Application-managed: the PMJOB-ALL-DU job lifecycle, its accelerated granularity clock (15 simulated minutes per period, compressed to a short demo period), PM-file creation, and the file-ready event are all managed by this application, not the simulator. This simulator's schema declares 3GPP TS 28.622's PerfMetricJob/ Files IOCs, but a real <edit-config> creating a PerfMetricJob under ManagedElement=1 fails with Unknown element "PerfMetricJob" - the simulator does not actually instantiate it, so the job concept, its file generation, and its file-ready event are clearly labeled as application-managed rather than coming from the simulator.
• 3GPP-structured but not schema-validated: the generated PM XML is structured according to the well-known 3GPP TS 32.432 measCollecFile model (fileHeader/measData/measInfo/measValue/fileFooter). No official XSD for this ships in this repository, so generated files are not schema-validated against one.

Two of the six implemented measurements (RRU.PrbUsedDl, RRU.PrbUsedUl) are legitimate 3GPP TS 28.552 names verified as scoped to the NRCellDU measured-object class. The other four (Demo.DlDataVolume, Demo.UlDataVolume, Demo.ActiveUeCount, Demo.CellAvailability) are deliberately kept as clearly-labeled custom counters rather than mapped to real 3GPP names: TS 28.552's closest equivalents (e.g. DRB.PdcpSduVolumeDL/UL, RRC.ConnMean) are scoped to GNBCUUPFunction/NRCellCU (PDCP and RRC are CU-side functions in the split gNB architecture), not NRCellDU, which is all this simulator represents - using those names here would misrepresent the measured-object class.

Network → O-DU → NRCellDU hierarchy. Raw standardized PM measurements are associated with their appropriate managed object: every cell-scoped measurement in the generated PM file is reported per NRCellDU (one <measValue measObjLdn="...NRCellDU=N"> per cell, never one per O-DU). The O-DU and network rows shown on the Performance Management page are derived aggregations computed from those NRCellDU measurements - never presented under a raw measurement's name alone, always labeled "Derived KPI" together with the aggregation used (sum for additive quantities like data volume, unweighted average for utilization/percentage measurements - this simulator has no per-cell capacity figure to weight by). Simulated counter values remain synthetic since there is no real RF traffic; it is the PM reporting pipeline itself - job, file, hierarchy, naming - that is standards-oriented.

Supervision Architecture

Fault Management's Supervision page uses the O-RAN SC NTS simulator's genuine implementation of the o-ran-supervision YANG model (O-RAN Alliance WG4). The O-RU is simulated, but the supervision protocol interaction is real. Watchdog-reset RPCs, replies and supervision notifications shown here are actual NETCONF exchanges with the O-RAN SC O-RU simulator. Supervision health is determined by the SMO-side controller from those protocol events and O-RU-provided timing information. Not called "3GPP/O-RAN compliant" or "conformant" anywhere in this app, since no formal conformance testing has been done; "3GPP-style" / "structured according to the O-RAN PM/supervision model" is the accurate phrasing this app uses throughout.

The Supervision page deliberately separates two things: Supervision Health (HEALTHY / WARNING / LOST / DISCONNECTED / ERROR) - a persistent conclusion that stays HEALTHY for the whole duration a normal cycle is healthy, not just the instant a notification arrives - and Cycle State (e.g. RESET SENT, WAITING FOR NOTIFICATION, NOTIFICATION RECEIVED) - which phase of the real reset/notification cycle is currently in progress, expected to change every few seconds and not itself a health signal. The protocol provides the evidence. The SMO-side controller interprets that evidence to determine whether supervision is healthy. LOST is never presented as something the O-RU announced - the O-RU does not emit a distinct "supervision lost" signal; it is the controller's own conclusion from real timing (the O-RU's next-update-at plus the real guard-timer-overhead) once no genuine notification arrives in time.

• Simulator-backed and genuinely real: the entire supervision protocol exchange - the NETCONF <hello>, the real session-id, the create-subscription, the supervision-watchdog-reset RPC and its next-update-at reply, and the asynchronous supervision-notification - is captured directly from the wire with a real O-RU simulator, not fabricated or replayed. Only Supervision Health and Cycle State are the controller's own interpretation of that evidence, computed from these real timestamps, never an independent application timer.
• Application-managed: the persistent NETCONF session, the watchdog-reset schedule, and the pause/resume/auto-recovery logic are all managed by this application (one shared server-side worker, not per-visitor) - the O-RU itself has no concept of "the SMO's polling schedule," it just implements the RPC/notification model faithfully.
• A real, known limitation: o-ran-supervision is present in the O-RU's ietf-yang-library, and RPC/notification exchanges with it are genuine, but this build's config.json explicitly excludes the SUPERVISION-WITH-SESSION-ID feature, so supervision-notification carries no session-id leaf.
• Two separate simulators, two separate roles. The O-DU used everywhere else in this console (Topology, YANG Browser, Configuration/Performance Management, most of Fault Management) does not implement o-ran-supervision at all. It remains the primary managed NF; the O-RU exists specifically to demonstrate this one real protocol mechanism.

AI Agent for SMO rApps

The "AI Agent for SMO rApps" page embeds a genuinely separate application (o1-agent-demo, its own FastAPI service and Docker container - not part of this dashboard's own codebase or process) that treats this simulator purely as a data source, the same way a real SMO-hosted rApp would treat an O1-exposed network function. It is not itself an rApp and makes no claim to be one: it produces observability insight for a downstream rApp to consume, and nothing more.

• Real, not simulated: the agent polls this simulator's own /api/state and /api/pm/* endpoints on an interval, exactly like this dashboard's own browser client does, and every root-cause narrative shown is a genuine response from Google's Gemini API (currently gemini-3.5-flash-lite) - never scripted, cached, or replayed. The one thing that is simulated, as everywhere else in this console, is the underlying O-DU/O-RU radio network state itself.
• Deterministic rules first, LLM second: anomaly detection - new/escalated MAJOR+ alarms, and sustained PRB-utilization or cell-availability threshold breaches on the six live PM counters (see "PM Architecture" above) - is entirely rule-based and runs with no LLM involved. Gemini is only asked to reason about root cause after a rule has already flagged something, and its structured JSON response (hypothesis, confidence, contributing factors, review suggestions) is parsed directly, never free-text-scraped.
• Strictly read-only toward this simulator and the network: the agent only ever calls this simulator's GET endpoints. It never calls /api/ack, /api/alarm/clear, /api/maintenance, any /api/simulator/burst-* endpoint, or any configuration/outage-write endpoint - and exposes no mutating endpoint of its own (every route under /api/agent/* is a GET). Its published suggested_focus_areas are deliberately phrased as things worth reviewing, never as actions, commands, or configuration changes - interpreting them into an actual remediation is a downstream rApp's job, not this agent's.
• R1-service-shaped: the agent's feed occupies the position an rApp's analytics/data-consumption layer would occupy relative to a non-RT RIC/SMO - the same position O-RAN's R1 interface exists to serve - with zero write path back into O1, A1, or O2 anywhere in the service. No released O-RAN spec currently fixes a canonical rApp analytics output schema, so this is modeled on that pattern rather than a claim of interoperability conformance against a specific R1 implementation.
• Transparent pipeline, real pacing: every poll/evaluate/reason/synthesize/publish step emits a live event over Server-Sent Events, visible in the panel below - including honest skipped events when a cycle genuinely found nothing to reason about, never a fabricated "working" state.
• Deliberately budget-conscious: Gemini's free tier is a real, finite daily quota. The agent enforces a single in-flight request at a time (a slow call is never cancelled and re-fired - cancelling after reaching Gemini's servers would waste the call without freeing any quota) and a self-imposed daily call ceiling spread evenly across the day rather than front-loaded. Re-explaining an alarm or PM breach already covered by a recent insight at the same or lower severity is skipped for a bounded freshness window (each of this simulator's 32 alarm IDs is permanently pinned to one site/cell for its lifetime, so a re-raise within that window is genuinely the same issue, not a new one) - once that window elapses, the signal is reasoned about again from scratch, so real Gemini activity stays visible across the whole day instead of tapering off once everything active has been explained once. When the real daily limit is hit, or the agent's own self-imposed ceiling is, published insights say so plainly rather than silently going quiet or showing a raw provider error.
• Rate-limited against abuse, not just against its Gemini budget: every /api/agent/* route enforces its own per-client-IP cap (120 requests/minute, sliding window), separate from and in addition to the Gemini budget above - a client hammering the insight feed itself, not just triggering LLM calls, still gets throttled. The live SSE stream additionally caps concurrent connections per client IP (3) on top of a global cap (50), so one visitor can't hold open most of the stream's capacity and starve everyone else watching it.

Full technical detail - the insight record schema, the feed endpoints, and how a real rApp should integrate with it - is published by the agent itself at /api/agent/integration-guide, not duplicated here.

Scope & Honesty Notes

• Every cell is treated identically for PM: the PM job reads/evolves each cell's 6 real measurement-source counters once per accelerated period (see "PM Architecture" above) - there is no separate "demo" cell, and no cell's pm-counters exposes a value/last-update via NETCONF for any counter this app doesn't actually collect. Alarms are different: all 32 pre-seeded alarm records are genuinely spread across all 10 real sites (see Fault Management), so the background alarm generator and the Simulate Outage/Supervision connectivity-loss action produce real alarm activity for whichever site is actually affected.
• PM files/periods are retained in memory only, capped at the most recent 24 periods (a full simulated day at 15-min granularity) to bound memory usage - not persisted across an application restart, which cleanly reinitializes the job rather than resuming old state.
• This is a public, unauthenticated demo - Simulator Settings enforces minimum intervals and hard per-call caps on burst actions, Configuration Management enforces real value ranges plus a basic profanity filter, and Burst Alarms is additionally rate-limited per client IP (10 calls/minute) so one visitor calling it in a tight loop can't force a stream of new alarms fast enough to burn through the separate AI Agent's daily Gemini budget - all specifically so this demo can't be used to overwhelm the host, deface it, or degrade it for everyone else.
• Alarm history and the Log Monitor buffer reset automatically at 00:00 local time daily, and the PM job's simulated clock realigns to the current time with all PM files/periods cleared - keeping the accelerated PM clock from drifting away from the real date, and keeping every in-memory buffer from growing forever. NETCONF Console's transaction history and the O-RAN supervision timeline are bounded a different way, not by the daily reset: each keeps only its own most-recent-N entries and rolls over continuously rather than waiting for local midnight. A separate background task periodically prunes the simulators' own internal rotated log files (unrelated to anything in this app's own memory - a vendor-image behavior with no cap of its own) so a long-running instance doesn't slowly fill the host's disk either.
• Time zones: every timestamp anywhere in this app - Log Monitor, alarm/ supervision history, PM job periods/files (including the PM file's own content and filename), "last poll" times - is shown as UTC and labeled as such, whether it's generated by this app or genuinely reported by the real simulator containers (e.g. a NETCONF notification's eventTime, an alarm's alarmRaisedTime). Not converted to the viewer's browser-local zone anywhere - one single, explicit, unambiguous convention throughout, rather than a mix where some times are local and others are real device data that's unavoidably UTC, with no clean way to tell which is which just by looking. The one exception is the daily reset's own schedule (00:00 local time, not UTC) - that's an operational decision about when maintenance runs, not data being displayed, so it stays on the operator's actual local clock.
• The YANG Browser only offers "Query via NETCONF" for modules that are part of this simulator's live data tree (ManagedElement/GNBDUFunction/NRCellDU and the demo PM augmentation) - most of the other loaded modules are grouping/type/RPC-only libraries or NETCONF server infrastructure with no data of their own to read. The server, not the browser, decides the query filter from its own cached schema, so a visitor can never make it query anything outside that set.
• The NETCONF Console is not a general-purpose NETCONF proxy: every operation targets an already-registered simulator connection only (never a client-supplied host/port), raw XML in Advanced mode is parsed (never string-spliced), rejected outright if it contains a DOCTYPE/ENTITY declaration, and size-capped; every EDIT-CONFIG - guided or advanced - is restricted to the same approved parameter list and constraints Configuration Management already enforces. Execution is also rate-limited across all visitors combined, not per-IP (X-Forwarded-For isn't trusted enough for that on a public, unauthenticated endpoint) - deliberately more conservative than the AI Agent's own per-IP rate limit (see "AI Agent for SMO rApps" below), because the risk differs: this console can issue a real EDIT-CONFIG write, so a spoofed per-IP identity could let one actor exhaust everyone's shared write allowance; the agent's routes are all read-only GETs, so at most a spoofed identity buys more read traffic, not a bypassed write safeguard. LOCK/UNLOCK is offered only as one self-contained demo action on its own short-lived session, never the shared session the rest of this app's background activity depends on.
• Learn O1's only simulator-mutating step is a single NRCellDU administrativeState flip (via the same EDIT-CONFIG path Configuration Management uses) - the real value is read first, so the tutorial restores it to whatever it actually was beforehand (not a hardcoded default) when you finish, restart, or exit. Its "generate an alarm" step reuses the existing capped burst-alarm action, so it adds no new mutable surface. Progress is tracked in this browser tab's own sessionStorage only - there's no server-side per-visitor session, the same as everywhere else in this app - so if two visitors run the tutorial at once and both happen to touch this same value, the later one wins; a rare, low-stakes edge case for a single boolean-ish demo parameter.
• Built with Python/Flask and vanilla JavaScript (no frontend framework), a small hand-written NETCONF-over-SSH client (no ncclient/paramiko), and Docker Compose.

Privacy & Data Protection

• What's processed: this site keeps a live visitor-country counter, visible only to the site operator. Each request's IP address is looked up against a local, offline country database (geoip2fast - no external API call, no third party ever sees your IP) purely to increment that country's count. The IP address itself is never stored, logged, or written to disk anywhere in this app - only the resulting aggregate (country name, a running count, a last-seen timestamp) is kept, and only in memory. That in-memory state is lost entirely on every application restart.
• Current visitors (shown on Home / System Health) works the same minimal way: each request's IP is hashed - salted SHA-256, a one-way hash that can't be turned back into an IP even by reading this server's own memory - and only that hash's last-seen time is kept, purely to tell "the same visitor, still here" apart from "a new visitor." Any hash not refreshed within 15 seconds is dropped, so the number reflects who's actually on the site right now; nothing per-visitor is ever shown, only the total count.
• No cookies, no tracking, no fingerprinting. This app sets zero cookies and uses no client-side analytics script of any kind - the only signal read is the IP address already present on every HTTP request by necessity.
• Legal basis: legitimate interest (GDPR Article 6(1)(f)) - understanding aggregate visitor geography and current traffic for a small public demo, weighed against the minimal, momentary, non-identifying nature of the processing (an IP is resolved to a country or a one-way hash and then discarded, never retained individually or in reversible form).
• Your right to object: honored automatically and technically, not just on request - if your browser sends Sec-GPC: 1 (Global Privacy Control) or DNT: 1 (Do Not Track), this app skips both the country lookup and the current-visitor hash entirely for that visit; nothing is processed, not even transiently.
• Everything else this console does - NETCONF traffic, configuration changes, PM/alarm data - is either synthetic simulator state or, for on-demand actions, initiated directly by whoever is using the console at that moment; none of it is personal data.