¶ O-RAN Radio Units (O-RUs)
COSMOS operates a pool of nine commercial O-RAN radio units spanning five vendors, FDD and TDD,
4T4R and 8T8R — one of the few places you can run the same O-DU/gNB stack against radios from
different vendors and compare. All units speak the O-RAN 7.2x fronthaul split over 10/25 G Ethernet
with GPS-traceable PTP (G.8275.1) timing. This page is the reference for that pool and for the
two software O-RUs the tutorials use: what each radio is, how it is managed, which O-DU stack drives
it and how, how to power it, and what currently works.
An O-RAN radio unit (O-RU) is the part of a split base station that sits at the antenna. It receives
frequency-domain IQ samples from the distributed unit (O-DU) over Ethernet, performs the low
physical-layer steps (inverse FFT, cyclic prefix, digital-to-analogue conversion, amplification),
and does the reverse for the uplink. The O-RAN introduction
explains the 7.2x split, the fronthaul planes and eAxC identifiers; the
real-time host preparation page
explains how the O-DU server at the other end of the link is prepared.
¶ The fleet
Every unit below speaks the O-RAN 7.2x split. The first four have a page of their own with the
full known configuration — the radio's own stored settings, the fronthaul mapping, and the exact
configuration blocks each O-DU stack uses with it — and that page is where the current best
configuration lives as it is tuned.
| Unit | Vendor / model | Band (MHz) | Antennas | How it is configured | OCUDU (srsRAN) | Duranta (OAI) | Page |
|---|---|---|---|---|---|---|---|
benetel-oru |
Benetel RAN650 | n78 (3300–3800) | 4T4R | M-Plane (NETCONF) or standalone — the mode is a stored RU setting | works (standalone) | works (M-Plane) | Benetel RAN650 |
liteon-oru |
LITEON FlexFi Indoor | n78 (3300–3800) | 4T4R | standalone only (no M-Plane) | works | works | LiteOn FlexFi |
foxcon-oru1 |
Foxconn RPQN-7801 | n78 (3650–3850) | 4T4R | file mode (RRHconfig_xran.xml) |
RU latches, no attach | cell and downlink up, no attach | Foxconn RPQN-7801 |
| — | Software O-RUs: nr-oru, ProtO-RU |
n78 / n41 on a USRP | 1T1R | the O-RU is a program on a server | works (ProtO-RU) | works (nr-oru) |
Software O-RUs |
foxcon-oru2 |
Foxconn RPQN-4800 | n48 CBRS (3550–3700) | 4T4R | — | not yet integrated | not yet integrated | — |
jabil-fdd-oru |
Jabil B1 (Evenstar-derived) | n1 FDD (1920–1980 UL / 2110–2170 DL) | 4T4R | — | not yet integrated | not yet integrated | — |
jabil-tdd-oru |
Jabil 8T8R (Evenstar-derived) | n78 (3450–3650) | 8T8R, 25 G fronthaul | — | not yet integrated | not yet integrated | — |
corning-oruhub + corning-oru1/oru2 |
Corning Everon hub + 2 remotes | n78 (3450–3550) | 4T4R per remote | — | not yet integrated | not yet integrated | — |
"Works" means end to end with a COTS Quectel modem: registration, PDU session and internet traffic.
¶ How the pool works
The O-RUs park in the instrument domain and are reservable into four experiment domains:
rrail, accord, osc, and sb1.cosmos. Reserving one through the portal's O-RU Scheduler
moves its fronthaul VLAN so the unit appears on your domain's network for the duration — same radio,
wherever your compute lives.
Each unit keeps a canonical address (same last two octets in every domain), so your O-DU
configuration ports across domains by changing only the prefix.
All O-RUs share one fronthaul fabric. Their control and management plane is reached over IP at
<ru>.instrument.orbit-lab.org (NETCONF on TCP 830 for units that use it); their control and user
planes are Layer 2 on VLAN 4 and VLAN 5. Eight servers carry an Intel E810 NIC with DPDK, PTP
and both VLANs and can drive any O-RU: srv17.osc, srv18.osc, srv19.osc, srv20.osc,
srv6.rrail, srv7.rrail, srv1-lg1.sb1 and srv2-lg1.sb1.
¶ Timing
Fronthaul timing is a GPS-disciplined G.8275.1 telecom profile tree: a FibroLan grandmaster clock
disciplines the fronthaul switches, which serve PTP to every O-RU and to the servers that run your
O-DU — no per-experiment timing setup required on the radio side. The O-DU server still runs its own
ptp4l/phc2sys; see real-time host preparation.
¶ Power control
O-RUs are powered with omf tell from your fronthaul console: the console of the domain your O-RU reservation targets (console.rrail, console.osc or console.sb1). Reserve the O-RU in the O-RU scheduler first and address it by its full *.instrument.orbit-lab.org name, without -d. omf tell refuses if the reservation is not yours, is not active now, or targets another domain, and names the console to use:
omf tell -a offh -t liteon-oru.instrument.orbit-lab.org
omf tell -a on -t benetel-oru.instrument.orbit-lab.org
The verbs are on|off|offh|offs|reset|reboot; there is no status. The first omf tell to an
instrument is sometimes dropped: confirm by pinging the RU from the O-DU host rather than trusting
the reply. The other domain consoles answer No such node for the O-RUs. See
OMF commands for the command itself.
¶ The shared RF space
Danger: The Benetel and the LiteOn share one RF space. Since 2026-10-16 every O-RU reservation carries its band, centre frequency and bandwidth, and the shared scheduler refuses overlapping bookings, so both may be powered only on non-overlapping channels.
cosmos-oru resetstops if a co-channel O-RU is being driven by a DU, and if any DU is already streaming at your O-RU (a forgotten one elsewhere breaks every other user's cell).
More generally, the osc, rrail and sb1 radios (SDRs, O-RUs and the Quectel UEs) are all within
about three metres of each other and hear each other. Two cells on the same carrier interfere, and
a UE may camp on someone else's cell. Leave an O-RU powered as you found it: it is a shared
instrument.
Channel: the cell runs on the channel of your O-RU reservation (band, centre, bandwidth from the shared scheduler);
cosmos-oru rf <oru>prints it. Experienced users override it with--center-freq <MHz> --bandwidth <MHz>oncosmos-oru resetand the bring-up scripts; stay inside your reservation, because the scheduler cleared only that block.
The same fact has a diagnostic consequence: on COSMOS, "the UE sees no cell" is never an antenna,
distance or link-budget problem. Either the radio is not really transmitting (a configuration or
fronthaul fault) or the UE is refusing the cell (see COTS UE: the Quectel modem).
¶ How an O-RU gets its configuration
A commercial O-RU is a small Linux computer with persistent configuration. How that configuration
is set decides which O-DU stack can drive it:
- Hierarchical M-Plane. The O-DU is the NETCONF client: it opens a session to the RU on port
830 at start-up, pushes the carrier and U-plane settings, and must hold the session. Duranta
(OAI) works this way with the Benetel. - Standalone. The RU runs from its own stored configuration with no NETCONF client. The OCUDU
gNB has no NETCONF client, so on COSMOS every O-RU it drives runs standalone (OCUDU's separate
M-Plane client,ocudu_o1_adapter, is covered against a simulated O-RU in its tutorial). - Operator-applied. COSMOS tooling writes and verifies the RU's stored configuration over SSH
before the DU starts (the O-RU profile and golden-state tools below).
Figure — hierarchical M-Plane (the O-DU is the NETCONF client and must hold the session — Duranta), standalone (the RU boots from its own stored configuration — what OCUDU needs), and operator-applied (COSMOS tooling writes and verifies the configuration before the DU starts).
¶ The golden O-RU rule
A commercial O-RU keeps whatever the last stack wrote into it, and a mismatch is silent: the
fronthaul counters stay clean, the radio transmits, and the link is unusable. A Benetel left in
Duranta's state under an OCUDU DU gives DL 3 Mbit/s instead of 248, with CQI 2 and 75 %
downlink errors, on a healthy radio.
The rule (owner, 2026-09-22): a rig counts as working only once a full O-RU state capture is
committed as its golden; every bring-up restores that golden and refuses to start the DU on a
mismatch.
Figure — one RU, two DUs that want different persistent values; each bring-up captures, restores and diffs the RU against its rig's committed golden before the DU starts. Skipping the gate leads to the "every counter healthy, DL 3 Mbit/s" branch.
The tools live on the DU host in /root/oru-setup/:
# on the DU host, before the DU starts
/root/oru-setup/oru_capture.sh # Benetel: mode + ru_config.cfg + registers
python3 /root/oru-setup/oru_golden.py diff /root/oru-setup/golden/osc-benetel-ocudu.txt
python3 /root/oru-setup/oru_golden.py restore /root/oru-setup/golden/osc-benetel-ocudu.txt
# exit 0 = matches · exit 3 = ru_config.cfg rewritten, the RU needs a PDU COLD cycle · exit 1 = drift remains
The bring-ups run the gate themselves: ocudu-72_cycle.sh at step [5b]; benetel-bringup.sh
twice (before the DU with --scope persistent, and again after Duranta's M-Plane commit, because
the DU writes registers after it starts); liteon-du-bringup.sh once at [6b]. The LiteOn needs the
same state for both stacks, so in practice only the Benetel changes hands.
¶ Stack status and performance
Which open-source O-DU stacks drive which O-RU end to end (COTS Quectel modem, registration + PDU
session + internet). Throughput is iperf3 receiver-side and depends heavily on the DU server's CPU,
so every figure carries its platform, date and image. The platforms are 2× Intel Xeon Gold 6126
(24 cores / 48 threads), 2× Intel Xeon Gold 6226 (24 cores / 24 threads) and 1× AMD EPYC 9355P
(32 cores / 32 threads).
Duranta's downlink layers depend on the server. Rows marked 1 layer were measured without CSI-RS
(the UE reports no rank, so the gNB sends one layer) or on a server too small for more. From
duranta-20260927the image enables CSI-RS and four layers, and its bring-up keeps them only where
the DU gets at least 20 CPUs (AMD EPYC: 830 Mbit/s on the Benetel); 2× Xeon Gold 6126 servers stay
at one layer, which is all their real-time L1 sustains. Details on each radio's page.
| O-RU | Stack (core) | Status | DU CPU platform | DL / UL (Mbit/s) | Date | Image |
|---|---|---|---|---|---|---|
| Benetel RAN650 | OCUDU (Open5GS) | works | 2× Intel Xeon Gold 6126, 24 cores / 48 threads | 209–220 / 78 | 2026-09-22 | ocudu-20260916 |
| Benetel RAN650 | OCUDU (Aether SD-Core) | works | 2× Intel Xeon Gold 6126, 24 cores / 48 threads | 189–214 / 74 | 2026-09-22 | ocudu-20260916 |
| Benetel RAN650 | Duranta (OAI CN5G) | works — 4 layers (image default on this server), UE on USB 3 | 1× AMD EPYC 9355P, 32 cores / 32 threads | 831 (UDP) · 207 (TCP) / 59–61 | 2026-09-27 | duranta-20260927 |
| Benetel RAN650 | Duranta (OAI CN5G) | works — 1 layer (image default on this server), UE on USB 3 | 2× Intel Xeon Gold 6126, 24 cores / 48 threads | 355 (UDP) · 189 (TCP) / 49–64 | 2026-09-27 | duranta-20260927 |
| Benetel RAN650 | Duranta (OAI CN5G) | works — 1 layer | 1× AMD EPYC 9355P, 32 cores / 32 threads | 209 / 64 | 2026-09-25 | duranta-20260925 |
| Benetel RAN650 | Duranta (OAI CN5G) | works — 1 layer | 2× Intel Xeon Gold 6126, 24 cores / 48 threads | 186–218 / 57–61 | 2026-09-22 | not recorded |
| LiteOn FlexFi | OCUDU (Aether SD-Core) | works | 2× Intel Xeon Gold 6126, 24 cores / 48 threads | 117–121 / 76 | 2026-09-22 | ocudu-20260916 |
| LiteOn FlexFi | OCUDU (Open5GS) | works | 2× Intel Xeon Gold 6126, 24 cores / 48 threads | 154 / 48.6 | 2026-09-14 | ocudu-20260909b |
| LiteOn FlexFi | Duranta (OAI CN5G) | works — 1 layer | 2× Intel Xeon Gold 6126, 24 cores / 48 threads | 157–163 / 38–39 | 2026-09-22 | not recorded |
| Foxconn RPQN-7801 | OCUDU (Open5GS) | RU latches, UE does not attach | — | not measured | — | ocudu-20260909b |
| Foxconn RPQN-7801 | Duranta (OAI CN5G) | cell detected, registration blocked | — | not measured | — | — |
Each radio's page carries its full table.
The tutorials carry their own run tables:
OCUDU over a commercial O-RU ·
Duranta over a commercial O-RU ·
OCUDU over the Foxconn O-RU.
¶ Running a stack against them
Pair an O-RU with an O-DU/CU on servers in the target domain (OpenAirInterface, OSC O-DU, or a
commercial stack). The 5G tutorials cover working configurations; M-plane
(NETCONF) details per unit are available to experimenters on request via problems@cosmos-lab.org.
Before the first run, prepare the O-DU server as described in
real-time host preparation, and
restore the O-RU's golden state as above.
¶ Further reading
- O-RAN ALLIANCE specifications — the Open Fronthaul control, user, synchronisation and management plane specifications (WG4).
- OAI 7.2 fronthaul tutorial — OAI's O-DU configuration for commercial O-RUs.
- srsRAN Project documentation — the srsRAN O-DU's Open Fronthaul configuration.
- ProtO-RU — the open software O-RU used with OCUDU.
- linuxptp — the PTP implementation on the O-DU servers.
Author(s): COSMOS team · Last reviewed: 2026-09-25 · Tags: oran, o-ru, 7.2, fronthaul, benetel, liteon, foxconn, jabil, corning, nr-oru, protoru, ptp, hardware