Build a private 5G campus network that does more than connect devices. BubbleRAN combines MX-PDK and MX-AI to deliver a multi-vendor campus platform for reliable indoor and outdoor mobile services, O-RAN experimentation, AI-RAN automation, edge applications, and continuous innovation. Add MX-DT when you need a high-fidelity network sandbox for planning, what-if analysis, validation, and optimization.
A 5G campus network is a locally deployed mobile network for a defined site. It provides seamless mobility, fast data transmission, low latency, dedicated resources, and secure connectivity for many mobile devices, machines, sensors, and applications. BubbleRAN extends this foundation with open programmability and intelligence, so the same campus can support daily services, R&D, validation, demonstrations, and future 6G-oriented work.
One campus, two missions
| Campus mission | Typical requirements | BubbleRAN approach |
|---|---|---|
| Reliable campus services | Stable indoor/outdoor coverage, mobility, device identity, local data processing, QoS, availability, and operational support | Use industrial-grade cells and O-RUs with managed 5G Core, edge services, slices, observability, and Day 0 to Day 2+ automation |
| Open innovation and validation | Flexible topologies, access to RAN/Core functions, multi-vendor testing, xApp/rApp/agent development, datasets, and repeatable experiments | Use open-source and disaggregated stacks, SDRs or O-RUs, RIC/SMO DevKits, AI-RAN workflows, and isolated experimental zones |
Both missions can share the same O-Cloud, RIC, SMO, security model, data platform, and operational toolbox, while remaining isolated through tenants, slices, policies, RBAC, and dedicated resources.
Turnkey campus solution
-
Multi-vendor 5G campus platform
Deploy open-source and industrial-grade 5G components in the topology that matches your campus. MX-PDK supports open-source stacks such as OpenAirInterface, OCUDU, and Open5GS, as well as industrial-grade small cells and O-RUs, SDRs, commercial UEs, and edge devices. -
O-RAN programmability and automation
Use the cloud-native Near-RT RIC, Non-RT RIC, and SMO/OAM with E2, A1, and R1 interfaces, reusable xApps/rApps, SDKs, and a Container Development Kit to monitor, control, automate, and extend the network. -
AI-RAN intelligence with MX-AI
Add AI-for-RAN and AI-on-RAN workflows using multi-agent blueprints, reusable agents, and the BubbleRAN Agentic Toolkit. Transform observability into insights, recommended actions, and closed-loop operations for SLA, performance, configuration, anomaly, and optimization workflows. -
Campus O-Cloud and edge services
Run the platform on a telco-optimized Kubernetes cluster with time synchronization, device discovery, multi-networking, an optimized data plane, routing, and eBPF-based observability. Place the UPF and campus applications at the edge for local processing and controlled data paths. -
Observability, datasets, and security
Collect RAN, Core, terminal, infrastructure, log, trace, alarm, and energy data in a multi-source data lake. Use MX-UI dashboards, CLI, API, and extraction tools for troubleshooting, acceptance testing, analytics, and AI development. Apply RBAC, network isolation, signed rootless artifacts, SBOM, and runtime process/network security. -
Network digital twin extension with MX-DT
Mirror selected campus sites, cells, slices, or services with emulated UE-in-the-loop. Create synchronized or time-locked replicas to test configuration changes, mobility policies, faults, capacity scenarios, and AI models before applying changes to the physical campus.
Campus reference architecture
| Layer | BubbleRAN components | Campus value |
|---|---|---|
| Devices & applications | SIM-based UEs, gateways, cameras, sensors, drones, robots, vehicles, AR/VR devices, and edge applications | Secure identity, mobility, local services, and use-case-driven connectivity |
| Indoor/outdoor RAN | Industrial all-in-one cells, O-RAN O-RUs, SDRs, CU/DU/gNB options, indoor and outdoor antennas | Flexible coverage and capacity from a lab zone to a multi-cell campus |
| 5G Core & edge | 5GC, local UPF, routing, slicing, and campus edge services | Local data control, lower application path latency, and service isolation |
| O-Cloud | Kubernetes, synchronization, automatic device discovery, BGP, Multus, optimized dataplane, and eBPF observability | Repeatable deployment, portability, resource control, and scalable operations |
| O-RAN control | Near-RT RIC, Non-RT RIC, SMO/OAM, E2/A1/R1, xApp/rApp SDKs, and CDK | Programmability, lifecycle automation, multi-vendor control, and open innovation |
| AI-RAN | MX-AI AIFabric, agent catalog, BAT DevKit, AI-for-RAN, and AI-on-RAN workflows | Intelligent assistance, closed loops, anomaly analysis, and network optimization |
| Data & assurance | Multi-source data lake, Grafana dashboards, logs, traces, PCAPs, alarms, KPIs, and dataset export | Evidence-based acceptance, reproducible research, and continuous assurance |
| Optional digital twin | MX-DT Perceptor, Replicator, Scenario Kit, parallel replicas, traffic mirroring, and synthetic data generation | Safe what-if analysis, planning, AI/ML validation, and pre-deployment optimization |
Multi-vendor by design: flexibility without sacrificing stability
| Deployment profile | Typical components | Best suited for |
|---|---|---|
| Open research profile | OpenAirInterface, OCUDU, Open5GS, SDRs, open SDKs, custom xApps/rApps/agents | Feature development, teaching, protocol research, O-RAN experimentation, and rapid integration |
| Industrial campus profile | Industrial-grade all-in-one cells or O-RUs, commercial UEs/CPEs, managed edge and lifecycle workflows | Stable campus services, demonstrations, enterprise MPNs, and operational validation |
| Mixed innovation profile | Industrial coverage for campus services plus isolated open-source/disaggregated research zones | Universities, operator labs, innovation centers, and enterprises that require both reliability and openness |
BubbleRAN avoids forcing the campus into a single-vendor or single-stack model. Common blueprints, Composition Models, RIC/SMO interfaces, and observability provide a consistent operating model while allowing each zone to use the technology best suited to its purpose.
Campus engineering principles
-
Plan coverage, then validate it with measurements
Combine use-case requirements, spectrum, building and outdoor geometry, antenna patterns, and expected device density in the radio plan. Confirm the design after deployment with RSRP, RSRQ, SINR, throughput, and mobility measurements rather than relying on simulation alone. -
Treat fronthaul and synchronization as first-class design elements
Disaggregated O-RAN deployments require deterministic transport, sufficient bandwidth, and precise timing. The reference design can include dedicated management and data switching, fiber where required, PTP/GNSS timing, and time-aware O-RAN transport. -
Engineer the O-Cloud for real-time workloads
Use appropriate CPU frequency, core isolation, NUMA awareness, accelerator allocation, low-power-state controls, and network tuning. Campus performance depends on the complete compute-radio-transport chain, not only on radio specifications. -
Use vendor-specific profiles behind a common operating model
Radio, RAN, and device vendors may differ in TDD profiles, PRACH, timing, handover, and configuration parameters. BubbleRAN blueprints and operators provide repeatability while preserving the tuning required for each implementation. -
Design for lifecycle cost, not only equipment cost
Include fiber, power, antennas, mounting, synchronization, spectrum, installation, testing, software updates, and operations in the campus plan. Automation and reusable blueprints reduce recurring integration and operating effort as the network grows.
Illustrative dual-NPN indoor/Outdoor Open RAN reference profile
The following is an example engineering profile, not a fixed package. It shows how BubbleRAN can address a demanding indoor campus, R&D, or security-validation opportunity and later extend it outdoors.
| Requirement area | Reference design response |
|---|---|
| Network topology | Two independent 5G SA Non-Public Networks, each with its own RAN and 5G Core and a comparable configuration. They may run on separate O-Cloud clusters for hard isolation or on shared infrastructure with dedicated resources and network planes. |
| Standards baseline | Target 3GPP Release 17 with the selected MX-PDK stacks, satisfying a Release 16-or-higher design objective. O-RAN interface and component compliance evidence is confirmed per selected release and vendor; formal certification is component-specific. |
| Spectrum & footprint | Indoor/outdoor n78/n77 operation in 3.7-3.8 GHz, with configurable TDD and channel bandwidth up to 100 MHz where permitted. Example footprint: two 40 m2 test rooms, with a design path to outdoor coverage. |
| RAN configuration | One O-CU and one O-DU domain per NPN, at least two logical cells per RAN, and three indoor O-RUs across the solution where the selected O-RUs support the required multi-cell mapping. Otherwise, an additional O-RU is included. |
| Shielded-box profile | At least one O-RU or SDR-based RF profile with external antenna/RF connectors suitable for a shielded box. Connector type, attenuation, calibration, and safe RF limits are confirmed during hardware selection. |
| Subscriber capacity | Design target of 50-100 simultaneously active subscribers per NPN. This is an expanded capacity profile requiring multi-cell and industrial-grade sizing, an agreed traffic model, and load testing; it must not be assumed from a starter lab configuration. |
| Software-defined delivery | 5GC, O-CU/O-DU, RIC, SMO, MX-AI, and MX-DT are delivered as software wherever supported. Physical O-RUs, timing/transport hardware, and optional accelerator cards remain hardware components. |
| Interoperability | Multi-vendor validation across 3GPP N1/N2/N3 and NG-family interfaces, F1, Xn, E2/A1/R1, O1, and O-RAN 7.2a Open Fronthaul where applicable. Composition Models and blueprints provide a common operating model. |
| Mobility & services | 3GPP handover through Xn, NG, or Inter-DU profiles as supported. Per-subscriber service profiles and slices can be aligned to eMBB, low-latency/URLLC-oriented, and mMTC-oriented use cases through QoS/5QI, slice, BWP, TDD, and resource policies. Exact support is validated per stack and UE. |
| Traffic capture | PCAP, logs, traces, and KPIs can be collected at Core, RAN, RIC/SMO, and selected transport interfaces for protocol analysis, troubleshooting, and security testing. Capture points and retention are defined in the test plan. |
| Security test profile | 3GPP security parameters are exposed according to the selected stack. Controlled enable/disable of selected encryption paths is supported only where technically available and only inside an isolated test profile, with the required PKI, keys, certificates, and access controls. Production profiles keep mandatory protections enabled. |
| Roaming evolution | The design reserves a later interconnect/roaming phase. The exact model - SNPN, PNI-NPN, PLMN integration, identity federation, and security boundary - is selected and validated as a separate work package. |
| AI and assurance | MX-AI supervises observability and operational workflows; MX-DT validates capacity, handover, slice, security, configuration, and failure scenarios before changes are applied to either NPN. |
Capacity sizing note: the standard MX-PDK reference profile in the current product datasheet lists 16-32 active UEs. A 50-100 active-subscriber target per NPN therefore requires an engineered scale-out profile, selected industrial-grade components, and acceptance testing under the agreed UL/DL traffic mix.
Mobile, Open RAN, security, and validation capabilities
| Capability | Design approach | Acceptance evidence |
|---|---|---|
| Cell mobility | Xn, NG, and Inter-DU handover profiles, neighbor planning, mobility routes, and per-vendor tuning | Handover success rate, interruption time, route continuity, and application behavior |
| Slices & QoS | Multiple slices, per-UE association, QoS/5QI policies, asymmetric UL/DL resource allocation, and application-aware control | Slice isolation, minimum/maximum throughput, latency/jitter, and policy enforcement |
| Radio configuration | Configurable n78 bandwidth, TDD UL/DL patterns, BWP, power and cell parameters where supported by the selected RAN | Configuration audit, controlled change test, spectrum compliance, and performance comparison |
| O-RAN programmability | Near-RT/Non-RT RIC, KPM/RC/CCC/LLC service models, xApps/rApps, E2/A1/R1, and dynamic application lifecycle | Interface traces, subscription/control tests, app lifecycle, and KPI impact |
| Security controls | 3GPP security profiles plus O-Cloud RBAC, network isolation, SBOM, signed rootless artifacts, runtime process/network protection | Security configuration report, audit logs, vulnerability/SBOM checks, and isolated penetration-test evidence |
| Protocol visibility | PCAP/log/trace extraction at agreed N1/N2/N3, NG, F1, Xn, E2, A1/R1, and management points where supported | Timestamp-aligned captures, decryption material for approved test cases, and protocol-analysis reports |
| AI-assisted operations | Customizable agent blueprints for observability, configuration, anomaly, SLA, API, RIC/SMO, and supervisory workflows | Agent decision trace, tool/API audit, recommendation accuracy, and policy-gated action results |
| Digital-twin assurance | Scoped replicas, synchronized or frozen state, traffic/fault/mobility/spectrum scenarios, and apply-if-better gates | Twin fidelity, scenario reports, KPI comparison, approval trail, and post-change verification |
Use-cases
1) University R&D, experimentation, and validation
| Category | Details |
|---|---|
| Operational need | Indoor/outdoor coverage for research groups, students, staff, labs, shared instruments, and campus demonstrations |
| Solution | Stable service zones plus isolated experimental cells, networks, and slices using open-source, disaggregated, SDR, or industrial components |
| O-RAN & AI-RAN value | Develop xApps, rApps, and agents; collect datasets; evaluate slicing, mobility, sensing, interference, energy, closed-loop policies, and new 5G/6G features |
| Digital-twin value | Test RF/capacity assumptions, replay experiments, compare algorithms in parallel replicas, and validate changes before field demonstrations |
| Example demonstrations | Drone connectivity, robotics, V2X, positioning, object detection, cooperative communication, smart buildings, AR/VR, and edge AI |
| Outcome | Reusable infrastructure bridging teaching, prototyping, validation, and real-world demonstration |
2) Enterprise mobile private network and smart campus
| Category | Details |
|---|---|
| Operational need | Dedicated connectivity for employees, machines, sensors, cameras, autonomous systems, logistics, remote inspection, and critical IoT |
| Solution | Indoor/outdoor 5G SA, local UPF and edge services, SIM-based identity, QoS/slicing, observability, security, and lifecycle automation |
| O-RAN & AI-RAN value | Application-aware policies, traffic steering, SLA assurance, anomaly detection, configuration assistance, and progressive closed-loop operation |
| Digital-twin value | Forecast capacity, validate upgrades, test failure recovery, and evaluate new use cases before impacting live operations |
| Example environments | Manufacturing, logistics, ports and maritime campuses, healthcare estates, media campuses, utilities, and smart buildings |
| Outcome | A flexible MPN supporting current workflows while remaining open to new applications and vendors |
3) Drone, robotics, and 3D networking
| Category | Details |
|---|---|
| Operational need | Continuous connectivity and control for moving aerial and ground platforms across indoor and outdoor cells |
| Solution | Multi-cell coverage, handover, edge processing, dedicated service policies, telemetry, and mission-specific slices |
| O-RAN & AI-RAN value | Handover control, traffic steering, sensing, positioning, object detection, anomaly detection, and policy adaptation |
| Digital-twin value | Rehearse routes, mobility loads, interference, failure conditions, and control policies before live flight or robotic operation |
| Outcome | A controlled environment for validating autonomous and mobile applications before wider deployment |
4) Operator, vendor, and system-integrator validation campus
| Category | Details |
|---|---|
| Operational need | Repeatable qualification of RAN, Core, O-RU, devices, edge applications, xApps/rApps/agents, and managed MPN solutions |
| Solution | Multi-vendor blueprints, controlled test zones, automated lifecycle, observability, dataset export, and acceptance workflows |
| O-RAN & AI-RAN value | Interoperability testing, SLA/slice validation, regression, closed-loop evaluation, and customer demonstrations |
| Digital-twin value | Parallel vendor/profile comparison, rollout rehearsal, upgrade testing, and apply-if-better optimization |
| Outcome | Faster integration cycles and a lower-risk path from PoC to customer deployment |
Delivery and acceptance model
| Phase | Activities | Deliverables |
|---|---|---|
| 1. Discover & design | Use-case and device inventory, spectrum assessment, indoor/outdoor survey, security and data policies, capacity and RF planning | Campus requirements, target architecture, radio plan, acceptance criteria, and phased BoM |
| 2. Build & integrate | O-Cloud, switching and timing, RAN/Core/edge, RIC/SMO, devices, applications, dashboards, and optional MX-AI | Deployed reference design, blueprints, configurations, runbooks, and trained users |
| 3. Validate & accept | Coverage walk tests, mobility, latency/throughput, slice isolation, availability, interoperability, application tests, and security checks | Acceptance report, KPI baselines, datasets, dashboards, and remediation plan |
| 4. Operate & evolve | Day 2+ monitoring, upgrades, rollback, capacity expansion, new xApps/rApps/agents, and optional MX-DT what-if analysis | Operational service, optimization backlog, reusable campus templates, and roadmap |
Acceptance KPI framework
Exact targets are defined per site and use case. Typical acceptance domains include:
- Coverage: RSRP, RSRQ, SINR, indoor/outdoor zone compliance, and edge-of-cell behavior
- Mobility: handover success, interruption time, route continuity, and moving-device application performance
- Service performance: application latency, jitter, packet loss, uplink/downlink throughput, and edge-service response
- Assurance: slice isolation, policy enforcement, resource allocation, availability, recovery, alarms, and MTTR
- Interoperability: RAN/Core/O-RU/UE compatibility, E2/A1/R1 behavior, and xApp/rApp/agent lifecycle
- Data quality: completeness, timestamp alignment, traceability, retention, and dataset export for analytics and AI
Light Bill of Materials
- MX-PDK software, O-RAN DevKits, network blueprints, observability, UI, CLI, and APIs
- MX-AI for multi-agent AI-RAN workflows, agent development, and intelligent closed-loop operations
- O-Cloud: typically three or more high-performance compute nodes, fast NVMe storage, and 10/25 GbE networking; GPU capacity where AI-on-RAN or local models require it
- Campus transport: dedicated management/data switching, fiber as required, PTP Grandmaster and timing-aware switching for disaggregated O-RAN
- Radio options: indoor/outdoor industrial small cells, O-RUs, SDRs, antennas, and mounting appropriate to the radio plan
- Core and edge: 5GC, local UPF, campus routing, edge application hosts, storage, and optional external cloud integration
- Devices: SIMs, UEs/CPEs, gateways, sensors, cameras, drones, robots, and application-specific terminals
- Optional MX-DT: additional compute and storage for replicas, UE emulation, mirrored traffic, synthetic data, and what-if scenarios
The final BoM and capacity are sized after the spectrum, site, device, traffic, availability, and research requirements are agreed.
Why BubbleRAN?
-
One platform from research to campus deployment
Use consistent blueprints, tools, interfaces, and workflows from controlled experiments and PoCs to indoor/outdoor multi-cell deployment. -
Open-source flexibility plus industrial-grade stability
Combine open RAN/Core implementations, SDRs, and developer access with industrial small cells, O-RUs, commercial devices, and hardened operating profiles. -
Multi-vendor without a fragmented operating model
Composition Models, deployment blueprints, standard interfaces, common data, and centralized operations let each campus zone use the right technology while retaining consistent governance and automation. -
O-RAN and AI-RAN are native capabilities
RIC, SMO, xApp/rApp SDKs, multi-source data, AI agents, and closed-loop workflows are part of the platform rather than separate integration projects. -
Repeatability lowers campus complexity
Composition Models, blueprints, operators, catalogs, and automated Day 0 to Day 2+ workflows reduce one-off engineering and make expansion easier. -
A long-term innovation and operations partner
BubbleRAN supports requirements definition, radio and platform design, integration, training, custom xApp/rApp/agent development, validation, operations, and future expansion.
FAQs
1⃣ Is this a production campus network or a research testbed?
It can be either or both. BubbleRAN can provide a stable service zone using industrial-grade components and a separate innovation zone using open-source, disaggregated, or SDR-based components. Shared orchestration and observability simplify operations while policies and resource isolation protect campus services.
2⃣ Can the campus network coexist with Wi-Fi or public mobile networks?
Yes. Wi-Fi can continue to serve general office, guest, or best-effort traffic, while private 5G serves mobility, critical IoT, robotics, cameras, and applications requiring dedicated policies. Public or hybrid mobile interconnect can also be considered when roaming or off-campus continuity is required.
3⃣ Can we deploy two fully independent campus networks?
Yes. Each NPN can have its own RAN, Core, subscriber domain, security profile, and management boundary. For the strongest separation, use independent O-Cloud clusters; for efficient shared infrastructure, use dedicated compute, storage, networks, timing, namespaces, and RBAC, subject to the security requirement.
4⃣ Does the solution support handover, slices, QoS, and flexible TDD?
MX-PDK supports Xn, NG, and Inter-DU handover profiles, network slicing, QoS control, configurable TDD bands, bandwidth up to 100 MHz per cell, and BWP-related control depending on the chosen stack and radio. Exact features are verified in the acceptance matrix.
5⃣ . What makes the solution multi-vendor?
MX-PDK supports multiple RAN, Core, radio, and device options, ranging from OpenAirInterface, OCUDU, Open5GS, and SDRs to industrial-grade all-in-one cells and O-RUs. O-RAN interfaces, Composition Models, blueprints, and common observability provide a consistent operating model across these choices.
6⃣ How does AI-RAN improve a campus network?
MX-AI can turn network and application telemetry into insights and coordinated actions. Example workflows include observability assistance, SLA/performance analysis, anomaly detection, configuration support, policy execution, and AI-on-RAN edge applications. The exact level of automation is introduced progressively and validated against campus policies.
7⃣ How does MX-DT help before making a live change?
MX-DT can replicate a selected site, slice, service, or network state in a controlled sandbox. Teams can test configuration changes, faults, mobility patterns, capacity increases, xApps/rApps/agents, or AI models on synchronized or frozen replicas before applying approved changes to the physical campus.
️8⃣ Which spectrum and coverage model should we use?
The answer depends on national regulation, campus size, building materials, outdoor areas, device ecosystem, and required capacity. BubbleRAN starts with a spectrum and site assessment, produces an indoor/outdoor radio design, and validates it with measurement-based acceptance after deployment.
️9⃣ Can we start small and expand later?
Yes. Start with a lab, building, production line, port zone, or priority use case, then add cells, sites, devices, slices, edge services, and AI workflows using repeatable blueprints and the same operating model.
Ask your questions
Need more information?
Every campus has a different mix of coverage, mobility, research, security, and operational requirements. BubbleRAN can prepare a campus-specific reference architecture, run a live demonstration, support spectrum and RF planning, and provide a phased proposal for MX-PDK, MX-AI, and optional MX-DT.
Email: contact@bubbleran.com