Skip to main content
search

O-RAN-SC Demo Highlights from Paris

By March 13, 2025March 17th, 2025Blog

The O-RAN ALLIANCE Face-to-Face Meeting, the first of 2025, took place in Paris. Members of OpenAirInterface Software Alliance (OAI), Nephio, and the O-RAN Software Community (O-RAN-SC), showcased new developments and demos around Service Management and Orchestration (SMO), the Non-RT RIC, Open Fronthaul, and more. Below is a quick walkthrough of the demos, the technology behind them, and why they matter.

1-1. Disaggregated 5G OAI gNB with O-RAN 7.2 Split & M-Plane (Presenter: Robert Schmidt)

Robert Schmidt from the OpenAirInterface (OAI) Software Alliance kicked off by showing a high-throughput, disaggregated 5G OAI gNB setup that uses:

  • O-RAN 7.2 interface (C-Plane, U-Plane, S-Plane, and now M-Plane).
  • SmallCellForum’s nFAPI split between O-DU-high (MAC) and O-DU-low (high-PHY).
  • 3GPP F1 and E1 splits to separate O-CU-CP (RRC) and O-CU-UP (SDAP, PDCP).
  • LDPC offload on the AMD T2 Accelerator card.
  • Benchmarked speeds up to ~1 Gbps DL.

Demo Highlights

  • Architecture:  OAI O-DU-high and above are deployed on one machine in docker containers. OAI O-DU-low with AMD T2 card runs on a bare metal on another server. OAI O-DU-low is further connected to the Benetel O-RU via 7.2 interface.
  • M-Plane Integration: The Benetel O-RU is automatically configured via M-Plane, setting the carrier frequency, bandwidth, MIMO mode, compression,…, without manual intervention.
  • Bandwidth Scaling: Robert showed switching from 100 MHz bandwidth to 40 MHz on the fly, verifying throughput changes (down from ~1 Gbps to ~200 Mbps range).
  • Full Pipeline: This setup includes F1 (CU ↔ DU), nFAPI(O-DU-high ↔ O-DU-low), O-RAN 7.2 fronthaul (O-DU-low ↔ O-RU), plus PTP synchronization.

Key Takeaways

  • OAI’s disaggregated stack can sustain high throughput while adhering to O-RAN’s 7.2 interface specs.
  • The M-Plane interface now supports automatic RU configuration, a big step toward “plug-and-play” for radios.

Watch the Video. 

1-2. O-RAN-SC Lab Access & Orchestration at Rutgers (Presenter: Ivan Seskar)

Context & Goals

Ivan described the new O-RAN-SC Lab co-located with the existing ORBIT and COSMOS testbeds at Rutgers. This environment provides remotely accessible servers, RUs, test equipment, and more for O-RAN-SC developers to run large-scale tests.

Demo Highlights

  • Physical Setup: The lab has low/medium/high-power O-RUs, test instruments, PTP distributions, plus a range of compute servers.
  • Access & Account Management: Users will register through a portal, deploy SSH keys, and be grouped into “projects.” However, the community still needs to decide who approves accounts, how to schedule test equipment, etc.
  • Resource Scheduling: In other testbeds (e.g., ORBIT/COSMOS), reservations are scheduled automatically for radio nodes, ensuring only one user at a time. The O-RAN-SC Lab can adopt a similar or more flexible approach.
  • Open Questions:
    1. Who approves new user accounts?
    2. How do we handle multi-tenant usage of RUs or test instruments?
    3. What is the scheduling policy for conflicting resource requests?

Key Takeaways

  • The O-RAN-SC Lab is “live,” but official policies (user roles, scheduling, ownership, etc.) need finalization.
  • Once policies are nailed down, community members can spin up remote tests or integrate new hardware, bridging real-lab experimentation with the O-RAN-SC codebase.

1-3. Nephio + O-RAN: Cluster Provisioning (Presenter: Sagar Arora)

Context & Goals

Sagar showcased how the Nephio project (under Linux Foundation Networking) can create and manage Kubernetes clusters for O-RAN-SC deployments. By taking an “intent-based” GitOps model, Nephio orchestrates O-Cloud resources and O-RAN workloads.

Demo Highlights

  • Nephio Architecture:
    • Kubernetes-based operators (known as “Focom Operator” and “O2 IMS Operator”) extend K8s with custom resource definitions.
    • Users define “cluster templates” and pass them as an O2-based orchestration request.
    • Nephio dynamically provisions a cluster with the specified configuration (e.g., K8s “kind” cluster).
  • Workflow:
    • SMO’s Focom sends a provisioning request (YAML) that references an O-Cloud and cluster template.
    • The O2 IMS operator instantiates a K8s cluster, returning a success/failure status.
    • The final outcome is a new “Edge” cluster that can host network functions (e.g., OAI components).
  • Roadmap:
    • Nephio aims to automate not just cluster creation but also NF instantiation and day-2 config changes.
    • Future demos will integrate Tacker or O2 DMS for deploying actual O-RAN workloads on these auto-provisioned clusters.

Key Takeaways

  • Demonstrates an end-to-end pipeline: SMO Focom → O2 IMS → K8s cluster provisioning.
  • Brings a straightforward GitOps approach for multi-cloud or multi-site RAN orchestration.
  • Positions Nephio as part of the O-RAN-SC SMO puzzle, handling the “how” of cluster creation, so that O-RAN workloads can be placed seamlessly.

Watch the Video.

1-4. OAI O-DU/O-CU with O1 & E2 Interfaces (Presenter: Teodora Vladic)

Context & Goals

Teodora closed out the session with a look at OAI’s support for O1 management (via NETCONF) and E2 (via FlexRIC, a nearRT-RIC + xApp framework). The goal: demonstrate real-time reconfiguration and performance reporting from a COTS UE, plus monitoring via E2-based xApps.

Demo Highlights

  • Testbed Setup:
    • A COTS UE sits in a Faraday cage → connected to OAI O-DU via USRP. OAI O-CU and OAI 5GC deployed one another machine.
    • SMO (ONAP/O-RAN-SC-based) communicates over O1 to read/write DU/CU settings (bandwidth changes, etc.).
    • The nearRT-RIC hosts an xApp implementing the RAN Control E2 service model.
  • Bandwidth Scaling:
    • The O-DU starts at 40 MHz, achieving ~127 Mbps DL.
    • SMO triggers a reconfig to 20 MHz on the O-DU, verified in logs. Throughput drops proportionally (~60–70 Mbps DL).
  • E2 Agent / xApp Observability:
    • The E2SM-RC xApp receives UE RRC messages, decodes and displays the RRC State Changes, periodically reported channel quality, as well as RRCReconfiguration message.
    • Periodic measurements reflect the behavior of the phone when inside and outside the Faraday cage.

Key Takeaways

  • OAI has a multi-interface approach: F1 (CU-DU), O1 (SMO-DU/CU), E2 (nearRT-RIC), plus 5GC for end-to-end service.
  • The O1 adapter for OAI extends the SMO’s netconf-based control to real radio parameters—illustrating dynamic bandwidth changes with minimal fuss.
  • The nearRT-RIC + E2SM RC xApp monitors and could eventually optimize RAN resource usage based on real-time channel conditions.

Watch the Video. 

2-1. Getting an O-RU Online with DHCP (Presenter: Alex Stancu)

What was shown?

Alex kicked off the demo session with a deep dive into how an O-RU can automatically discover its management-plane (M-Plane) endpoint using DHCP. According to the latest Open Fronthaul M-Plane specs (Release 16.0.1), DHCP can carry far more information than just an IP address—particularly, details about the SMO’s domain name and whether NetConf call-home should happen via SSH or TLS.

Why it’s important:

In real-world deployments, radios need a fast, standardized way to locate their controlling SMO (or OAM system). By embedding these parameters within DHCP, operators can streamline the “power-on” or “plug-and-play” workflow for large numbers of O-RUs. This demo clarifies how the RU can use DHCP Option 43 to retrieve not just its IP address, but also SMO’s FQDN, NetConf transport type, and even references to event-collector endpoints.

Key takeaways:

  • Alex and team used a Kea DHCP server in a container-based setup with two Docker networks (Macvlan for DHCP broadcast, Bridge for normal communication).
  • A python-based (PyNTS) RU simulator boots, asks DHCP for an IP, parses the extra “Option 43” details, and immediately calls home via NetConf over TLS.
  • With only minimal changes, a real RU could replicate that same automated discovery.

2-2. A Unified View of Network Topology & Inventory (Presenters: John Keeney & Jeff van Dam)

What was shown?

Next up, John Keeney and Jeff demonstrated how SMO can provide a high-level, consolidated view of all the network domains—like RAN, Cloud, OAM systems, and more—via the newly developed Topology Exposure & Inventory Service (TE&IV). They illustrated geographic queries, grouping of network entities (e.g., by location or by type), and dynamic group updates.

Why it’s important:

Most operators have many data sources—RAN inventory, physical sites, cloud infrastructure details, and so on. O-RAN Alliance Work Group 10 is defining an API so external applications (rApps, for example) can access an abstracted, cross-domain network view rather than piecing everything together themselves. This means your advanced analytics or optimization modules can fetch “just enough” topology info in a single call.

Key takeaways:

  • TE&IV uses a Yang-driven internal model and a REST API for clients.
  • Entities and relationships are typed (e.g., “Cell has this antenna,” “Antenna is physically at this site”).
  • John and Jeff showed a Manhattan use-case, filtering antenna modules by their location polygon and retrieving just the relevant attribute (e.g., electrical tilt).
  • Future releases will expand the data model further and integrate with other open-source projects.

Watch the Video.

2-3. SMO Roadmap: Federated Orchestration & Beyond (Presenter: Shashikanth)

What was shown?

Shashikanth gave a broader look at how the O-RAN-SC SMO project is evolving. Specifically, he presented the architecture where federated O-Cloud orchestration (FOCOM) works in tandem with a Network Function Orchestrator (NFO), with supporting modules like an Inventory Management Service (IMS) and a Deployment Management Service (DMS).

Why it’s important:

Operators often need to unify orchestration across multiple clouds (public, private, or on-prem). The SMO project is exploring new ways to fold in open-source orchestration tools (e.g., StarlingX, Tacker, Open MSA) and handle both VMs and container-based VNFs/CNFs.

Key takeaways:

  • K-release: used StarlingX for the O-Cloud platform and Tacker for VNF management.
  • L-release: evaluating multiple open-source orchestrators (Open MSA and others) and aiming to handle both VM-based and container-based network functions in a single SMO workflow.
  • This lays the groundwork for more robust end-to-end lifecycle management in O-RAN networks.

2-4. O-RAN-SC Components in India’s IOS-MCN Testbed (Presenter: Shridhar Rao)

What was shown?

Shridhar showcased how the IOS-MCN project in India (backed by the Government of India) is integrating key O-RAN-SC components—especially the OAM, Non-RT RIC, and RAN-PM modules—into their real-world lab. Their setup pairs O-RAN-SC containers with OpenAirInterface (OAI) gNBs and real mobile phones.

Why it’s important:

It’s a testament to how these open-source modules (OAM, RAN-PM, etc.) can be deployed “as is” into an external system. Having minimal code modifications means that community-driven solutions truly save time for integrators. In the demo, we see OAI gNBs come online, register through NetConf, and send PM (performance) data to Kafka and InfluxDB, where the SMO visualizes throughput, number of UEs, etc.

Key takeaways:

  • IOS-MCN found the OAM and Non-RT RIC code straightforward to deploy.
  • A real lab environment with actual phones and OAI gNB underscores the code’s maturity for real testing and demonstrations.
  • They plan next steps on E2 integration (for near-RT RIC apps) once some minor interface issues are resolved.

2-5. Synthetic DU Performance Data via PyNTS (Presenter: Alex Stancu)

What was shown?

Alex returned to spotlight a PyNTS-based DU simulator that produces synthetic 5G NR performance data in the 3GPP TS 28.532 (Release 18) XML format. This O-DU simulator periodically sends “file-ready” notifications, which the SMO retrieves using standard NetConf-based triggers (SFTP for the file itself) and then pushes into InfluxDB and Kafka.

Why it’s important:

While real DUs (or OAI-based setups) are great, they may be harder to come by in early testing, or you may want to scale up 1,000 DUs for performance benchmarking. A simulator that is fully compliant with the same file-based PM approach is invaluable. It confirms the entire chain—NetConf, file retrieval, PM data ingestion, and rApp consumption—runs smoothly before swapping in actual hardware.

Key takeaways:

  • The simulator’s JSON config lets you easily define measurement types, intervals, or arbitrary numeric values for PM counters.
  • The same RAN-PM pipeline that works with a “synthetic DU” will also function with OAI or a commercial DU.
  • Demonstrates how quickly one can test the entire pipeline without specialized hardware.

Watch the full Video on the O-RAN SC YouTube channel. 

Close Menu