| Term | Meaning |
| RU | Radio Unit — the physical hardware at the antenna. Converts digital signals into radio waves and back. |
| DU | Distributed Unit — handles time-critical, millisecond-scale processing, usually close to the tower. |
| CU | Centralized Unit — handles less time-critical processing, can serve many towers from one place. |
| Fronthaul / Midhaul / Backhaul | The three transport links: RU↔DU, DU↔CU, CU↔Core — each with progressively looser timing requirements. |
| SMO | Service Management & Orchestration — the top-level management layer overseeing the whole radio network. |
| Non-RT RIC | The slower (>1s) intelligence layer inside the SMO. Hosts rApps. Longer-term optimization and AI/ML training. |
| Near-RT RIC | A separate platform, closer to the radio, making real-time decisions (10ms–1s). Hosts xApps. |
| rApp / xApp | An automated behavior on the Non-RT RIC (rApp, slower/more sophisticated) or Near-RT RIC (xApp, faster/simpler). |
| Interface | Connects | Purpose |
| O-FH | RU ↔ DU | Standardized fronthaul (split 7.2x) — enables multi-vendor RU/DU. |
| F1 | DU ↔ CU | Midhaul, split into F1-C (control) and F1-U (user plane). |
| E1 | CU-CP ↔ CU-UP | Separates control and user plane within the CU. |
| E2 | Near-RT RIC ↔ RU/DU/CU | Real-time data up, control down — the xApp channel. |
| A1 | Non-RT RIC ↔ Near-RT RIC | AI/ML-informed policy and enrichment data, passed down. |
| O1 | SMO ↔ all RAN elements | FCAPS — fault, config, accounting, performance, security. |
| O2 | SMO ↔ O-Cloud | Cloud infrastructure and workload orchestration. |
| R1 | rApps ↔ Non-RT RIC | How an rApp registers and receives the data it needs. |
| PRB | Physical Resource Block — the basic unit of radio capacity a tower allocates. High utilization = a busy/crowded tower. |
| Handover (HO) | A phone switching from one tower's coverage to another's while moving. A failure often means a dropped call or lag. |
| Network Availability | Percentage of time the network is up and reachable — cannot exceed 100%, since it's a percentage of uptime. |
| Term | Meaning |
| UE | User Equipment — the device connecting to the network (phone, sensor, industrial modem, etc.). |
| eMBB | Enhanced Mobile Broadband — the 5G use case optimized for raw speed and capacity (video, browsing), as opposed to latency or device density. |
| URLLC | Ultra-Reliable Low-Latency Communication — the 5G use case optimized for guaranteed, near-instant delivery (industrial control, remote surgery), even at the cost of raw throughput. |
| mMTC | Massive Machine-Type Communication — the third 5G use case pillar, for huge numbers of low-power sensors/devices at once. Not separately simulated in this demo, but named here for completeness alongside eMBB/URLLC. |
| GBR | Guaranteed Bit Rate — a QoS class where the network reserves dedicated capacity for a flow, rather than best-effort sharing. |
| PDB | Packet Delay Budget — the maximum acceptable one-way delay (in ms) for a packet before it's considered a QoS violation. |
| PER | Packet Error Rate — the fraction of packets lost or corrupted in transit; URLLC targets an extremely low PER. |
| CA | Carrier Aggregation — combining multiple frequency channels into one connection to boost peak throughput. |
| DL / UL | Downlink (network → device) and Uplink (device → network) — the two directions of radio traffic. |
| RF / PHY | RF: Radio Frequency, the physical airwave signal. PHY: the Physical layer — the lowest processing layer that turns that signal into usable bits. |
| NSSI | Network Slice Subnet Instance — the RAN's piece of a network slice. |
| SLA | Service Level Agreement — a measurable, contractual promise about network quality. |
| CNF / NF Lifecycle | Cloud-native Network Function; its full lifecycle: instantiate, heal, scale, upgrade, terminate. |
| Zero-trust / CIS / SBOM | Zero-trust: nothing trusted automatically, every request checked. CIS: a published secure-config checklist. SBOM: an itemized ingredients list for software. |
| TCO / OPEX / MTTR | Total Cost of Ownership (full lifecycle cost); Operating Expenses (ongoing running cost); Mean Time to Resolve. |
| OSS / BSS | Operations Support System / Business Support System — the operator's own systems (network ops and billing/customer-facing respectively) that sit north of the SMO. |
| SME / DME | Service Management & Exposure / Data Management & Exposure — the R1 services an rApp uses to discover, request, and consume data and management functions from the Non-RT RIC. |
| DC | Data Center — the physical or regional facility hosting cloud-native network functions (e.g. vCU, vDU). |
A detailed explanation of what each tab shows, how it behaves, and why it exists.
| Tab | What it shows |
| Overview | Plain-language landing page, executive KPIs, and a clickable grid of every functional cluster. |
| RAN Architecture | Interactive RU/DU/CU diagram with the full interface map. Hover any interface — in the diagram or the reference table — to highlight it in both places at once; the highlight clears correctly regardless of which of the two you move your mouse away from. |
| FCAPS Monitor | Live fault, performance, configuration, trace, and topology/inventory views — core day-to-day network monitoring. All four scrollable panels (active alarms, live KPIs, configuration changes, trace sessions) share the same fixed box size, sized so all 10 live KPIs fit without scrolling while the others scroll within that same footprint. Active alarms: 100 synthetic alarms with independent Acknowledge and Cancel actions (Cancel removes the alarm from the list entirely). Live KPIs: 10 metrics (availability, call/RRC/handover success rates, DL/UL throughput, PRB utilization, drop call rate, URLLC packet error rate, PDB-compliance latency) — hover any one for a synthetic 24h trend line plus its minimum and maximum points, clearly labeled as illustrative rather than live history. Configuration Management: 100 change entries. Trace sessions: start new sessions on demand; hover a completed session for a synthetic trace analysis snapshot (RRC setup time, DL/UL throughput, packet error rate, handovers, duration). |
| Closed Loop | The centerpiece: a multi-vendor cell ring (plus a 10,000-cell fleet heatmap) driven by real rApp logic across all 6 rApps — Energy Saving Management, Automatic Neighbor Relation, Mobility Robustness Optimization, Mobility Load Balancing, Cell Outage Compensation, and PCI Reuse Optimization — all enabled by default. Six color-coded trigger buttons inject one condition each, matched one-to-one to the rApp that resolves it. When an rApp acts, the affected cell pulses cyan on the ring for a few seconds so the action is visible, not just logged. If two enabled rApps genuinely want to act on the same cell in the same simulation cycle, that's a real detected conflict — it's logged live to the Conflict Log tab and resolved using whichever of the three strategies is currently selected there. See Scenario Reasoning below for what each button does and why. |
| Near-RT RIC | The fast (10ms–1s) control loop over E2, running xApps — deliberately contrasted against the slower Non-RT RIC loop. |
| rApp Catalog | Toggleable rApps, each running genuine reference logic, showing which data services each one consumes. |
| Import rApp | Validates and onboards a JSON rApp descriptor — genuine logic for recognized algorithms, an honest monitoring-only stub for anything else. |
| Slice Lifecycle | Full NSSI lifecycle (Create → Modify → Monitor & Assure → Decommission) plus SLA-vs-intent visualization. Clicking through the four stages updates a dedicated panel explaining exactly what input each stage needs and where it would come from in a real deployment — e.g. Create needs an S-NSSAI, QoS profile, and RAN resource template sourced from either the "Express a business intent" panel on this tab or a formal NSMF/OSS slice order; Modify comes from either a manual change request or an automated rApp recommendation reacting to SLA drift. |
| Conflict Log | Live rApp-vs-rApp conflict detection and three resolution strategies: Allow, First-Come-First-Served, Priority-Based Override. Conflicts arrive from two sources: a manual "Simulate a conflict now" button, and genuine conflicts detected automatically on the Closed Loop tab whenever two enabled rApps both act on the same cell in the same cycle. |
| Data & Openness | A data coverage matrix, a disconnect/reconnect resilience simulator, and self-serve data-routing config. |
| Cloud & NF Lifecycle | A live, scrollable, 100-object infrastructure inventory. Click any object to select it, then Instantiate, Heal, Scale, Upgrade, or Terminate — the four action buttons other than Instantiate act on whichever object is currently selected (Instantiate always creates and selects a brand-new one). Status drifts on its own over time: a running object can spontaneously degrade, the way real infrastructure does, giving you something genuine to Heal; and any transient state (scaling/upgrading/healing/instantiating) automatically settles back to "running" after a while even if you never touch it, so nothing stays stuck. A note explains exactly where an Instantiate request's data comes from in practice (a Zero-Touch Rollout pipeline run, a Slice Lifecycle capacity change, or a manual trigger here) and confirms newly instantiated objects appear immediately in this same visibility table. |
| Zero-Touch Rollout | A 13-step governed commissioning pipeline: onboard → discover → deploy → commission → validate → audit. A note explains where a new site integration's inputs actually come from: the software package and its signature from the operator's container/artifact registry, the physical hardware auto-discovered over O1 Plug-and-Play once it's powered on-site, the site configuration generated from planning-tool design inputs via one common templating engine, and the post-launch KPI validation window reading live PM counters from the same feed shown on FCAPS Monitor. |
| Security & Trust | Evidence-based security posture — proof of controls working, not just claims — plus a live artifact-verification log. Explains exactly what "Verify next artifact" checks (a cryptographic signature and checksum against the build-time attestation, proving the artifact wasn't tampered with) and how the next artifact is chosen: not randomly, but the next one in a round-robin deployment queue, with a live "next in queue" indicator so the selection isn't a mystery. |
| Openness Scorecard | Six industry principles, each pre-populated from real state elsewhere in the demo, freely adjustable, with a recalculate button. Documents precisely which action on which tab moves each of the six scores (e.g. toggling security controls on this tab moves "Security by evidence"; enabling rApps moves "Trustworthy automation"), and clarifies slider behavior: dragging one overrides just that dimension with your own manual judgment and immediately recalculates the composite score, and that override persists until you drag it again or press Recalculate, which discards all manual overrides and pulls fresh values from live demo state. |
Each button injects one specific, isolated condition designed to be resolved by exactly one of the six rApps — so triggering a scenario and watching the matching rApp fire is a deliberate one-to-one demonstration, not a coincidence. All six rApps are enabled by default, so every button should produce a visible fix within a few seconds (watch for the cyan pulse on the affected cell in the ring, and the corresponding entry in the log).
Sets a random cell to 88% PRB utilization and "congested" state — simulating a sudden demand surge (a large event, a viral moment). Mobility Load Balancing detects utilization above its 75% threshold and automatically offloads idle-mode users to a neighboring, less-busy cell. Without this, every user on that cell suffers degraded service until an engineer manually intervenes.
Sets a random cell to 8% PRB utilization — simulating a mostly-idle tower (a business district at 3am, a quiet rural site overnight). Energy Saving Management detects sustained low utilization below its 20% threshold and applies a micro cell-sleep mode. This is the single most quantifiable value case for rApp automation in the industry: radio equipment running at full power to serve almost no users overnight is pure wasted electricity cost.
Sets a random cell to "alarm" state — simulating a hard site failure (power loss, hardware fault, fiber cut). Cell Outage Compensation automatically widens neighboring cells' coverage via antenna tilt adjustment to partially fill the resulting gap, while the underlying fault is separately raised for a technician to physically repair. Automated compensation reduces customer impact in the window before a human fixes the root cause — it doesn't replace that repair.
Pushes a random cell's handover failure rate to 5.5% — simulating a cell whose neighbor relations or radio parameters have drifted out of tune, so devices increasingly fail to hand over cleanly as they move between towers. Mobility Robustness Optimization detects the rate above its 3.0% threshold and incrementally increases handover hysteresis until the failure rate settles back down, typically over a few simulation cycles.
Flags a random cell as missing a neighbor relation across an EMS boundary — the everyday case of two cells, often from different vendors' management systems, that should know about each other for handover purposes but don't yet. Automatic Neighbor Relation discovers and adds the missing relation. Without ANR, this kind of gap is typically found only when a customer complains about a dropped call at a specific location, then traced back manually.
Flags a random cell with a Physical Cell Identity collision — two nearby cells accidentally broadcasting the same radio ID, which confuses devices trying to distinguish between them and causes intermittent connection problems that are notoriously hard to diagnose from symptoms alone. PCI Reuse Optimization detects the collision, reassigns an ID that respects the minimum reuse distance, and re-verifies PRACH consistency afterward.
Regenerates all 12 cells back to healthy baseline values — a demo-usability feature to cleanly return to a calm starting state between scenarios, styled as a neutral action since it isn't injecting any condition.
| Acronym | Full term | Acronym | Full term |
| 5QI | 5G QoS Identifier | O-FH | Open Fronthaul |
| ANR | Automatic Neighbor Relation | OPEX | Operating Expenses |
| BSS | Business Support System | OSS | Operations Support System |
| CA | Carrier Aggregation | PCI | Physical Cell Identity |
| CIS | Center for Internet Security | PDB | Packet Delay Budget |
| CNF | Cloud-native Network Function | PER | Packet Error Rate |
| COC | Cell Outage Compensation | PnP | Plug-and-Play |
| DL / UL | Downlink / Uplink | PRB | Physical Resource Block |
| DME | Data Management & Exposure | RAN | Radio Access Network |
| eMBB | Enhanced Mobile Broadband | RF / PHY | Radio Frequency / Physical Layer |
| ESM | Energy Saving Management | RIC | RAN Intelligent Controller |
| FCAPS | Fault, Config, Accounting, Performance, Security | RU/DU/CU | Radio/Distributed/Centralized Unit |
| GBR | Guaranteed Bit Rate | SBOM | Software Bill of Materials |
| HO | Handover | SLA | Service Level Agreement |
| MLB | Mobility Load Balancing | SME | Service Management & Exposure |
| mMTC | Massive Machine-Type Communication | SMO | Service Management & Orchestration |
| MRO | Mobility Robustness Optimization | S-NSSAI | Slice Selection Assistance Info |
| NF / LCM | Network Function / Lifecycle Mgmt | SON | Self-Organizing Network |
| NIST | National Institute of Standards & Technology | TCO | Total Cost of Ownership |
| NSSI | Network Slice Subnet Instance | UE | User Equipment |
| O2-DMS | O2 Deployment Management Service | URLLC | Ultra-Reliable Low-Latency Communication |