¶ 5G SA platforms on COSMOS: OCUDU, Duranta and Amarisoft
COSMOS ships three complete 5G Standalone (SA) software stacks as ready-to-run node images, and three 5G cores that can sit behind them. This page compares them and helps you choose one. It explains what each platform and each core is, which ways of attaching a radio each one supports, how they interoperate, and which tutorial to start with. Read it after 5G SA fundamentals and before any hands-on tutorial.
¶ What a "platform" is here
Every 5G SA network has the same three parts: a user equipment (UE), a radio access network (RAN) whose base station is called the gNB (next-generation Node B), and a 5G core network (5GC). The UE is a phone, a modem or a software UE. The gNB turns IP packets into radio waveforms and back. The core authenticates the UE, gives it an IP address and forwards its traffic to a data network such as the internet.
Figure — The three parts of a 5G SA network. The gNB talks to the Access and Mobility Management Function (AMF) over N2 (control) and to the User Plane Function (UPF) over N3 (user data); notice that the core is a set of separate network functions, so the RAN and the core can come from different projects.
A RAN platform in this group is a software package that implements the gNB, plus the tools that come with it: usually a software UE, sometimes a software radio unit, and a default core. A core is a separate package that implements the 5GC network functions: the AMF, the Session Management Function (SMF), the UPF, and the subscriber and discovery functions. The interfaces between gNB and core (N2, carrying the NG Application Protocol (NGAP), and N3, carrying GTP-U user data) are standardized by 3GPP. That is why the same gNB can run against different cores.
COSMOS standardizes the parts a user touches, so that moving between stacks does not mean re-learning the UE side:
- Test PLMN
00101(mobile country code 001, mobile network code 01) on every cell and every SIM. The 2-digit MNC is not arbitrary: the software UEs split an IMSI as MCC(3)+MNC(2)+MSIN(10) and cannot form a 3-digit-MNC identity, so00101is the one PLMN every UE on the testbed can use. - UE address pool
192.168.100.0/22, gateway192.168.100.1, with internet access. - One commercial UE, the Quectel RM520N-GL modem, set up the same way for every stack. See the commercial UE.
¶ The three RAN platforms
| OCUDU | Duranta | Amarisoft | |
|---|---|---|---|
| Lineage | built on the srsRAN Project (C++); also packaged by the Aether project as a container | a fork of OpenAirInterface (OAI, C) | commercial product |
| Licence | permissively licensed, no licence server | permissively licensed, no licence server | floating network licence, one seat per component tag, testbed-wide |
| gNB binary | gnb (CU and DU in one process) |
nr-softmodem |
lteenb (eNB and gNB) |
| Software UE | srsRAN 4G srsue (over ZMQ) |
nr-uesoftmodem (over RFsim) |
lteue, many UEs on one radio |
| Software O-RU | ProtO-RU (third-party, built on the OCUDU code base) | nr-oru |
none |
| O-RAN M-Plane client | no — a commercial O-RU must run standalone | yes — the gNB is the NETCONF client | not applicable |
| E2 agent (for a RIC) | yes — E2SM-KPM monitoring works | not used on COSMOS | not used on COSMOS |
| Default core | Open5GS | OAI CN5G | its own ltemme |
| Configuration | srsRAN Project YAML | libconfig .conf |
JSON-like .cfg |
| Node image | ocudu.ndz |
duranta.ndz |
amarisoft.ndz (+ lte5gue.ndz for the UE host) |
The *.ndz names are stable pointers to the newest promoted dated image, and omf load -i <name>.ndz always pulls that build. As of 2026-10-02: ocudu.ndz → ocudu-20261001, duranta.ndz → duranta-w39-20261001 (Duranta 2026.w39), amarisoft.ndz → amarisoft-20261002 and lte5gue.ndz → lte5gue-20261002 (both Amarisoft 2026-09-11 by default, 2026-06-12 selectable with amari-select). Duranta also keeps one image per weekly release (duranta-w37.ndz, duranta-w38.ndz, duranta-w39.ndz), so a tutorial can be repeated on the exact release it was verified on. Each platform has an overview page with its architecture, image contents, tutorials in order and a full performance table: OCUDU · Duranta · Amarisoft.
OCUDU is a 5G central unit / distributed unit (CU/DU) built on the srsRAN Project. One gnb process contains the whole base station. The radio is attached through a pluggable radio-unit layer: a USRP software-defined radio (SDR), a ZMQ socket that exchanges samples with a software UE, or an O-RAN Open Fronthaul (7.2x) link to a separate radio unit. It is the platform with the most COSMOS tutorials, the only one used with Aether SD-Core and with a near-real-time RIC, and the one that works over a software O-RU (ProtO-RU) as well as three commercial O-RUs.
Duranta is an OpenAirInterface fork. Its gNB, nr-softmodem, uses OAI's RFsim for a radio-less link to nr-uesoftmodem, drives a USRP directly, or acts as an O-RAN distributed unit (O-DU) through a DPDK-based 7.2 fronthaul library. Unlike OCUDU it contains an O-RAN M-Plane client, so it can configure and supervise a commercial O-RU over NETCONF. It also ships OAI's own software O-RU, nr-oru, and runs against the OAI CN5G core in Docker containers.
Amarisoft is a commercial LTE and 5G stack: lteenb (a 4G eNB and a 5G gNB), ltemme (a unified 4G EPC and 5G core in one binary), and lteue (a software UE that can simulate many UEs on one radio). It is COSMOS's commercial reference stack, the only platform that also runs 4G LTE here, and the tool for multi-UE scale experiments. Every Amarisoft component needs a licence seat from a network licence server.
¶ The three cores
| Core | What it is | How it runs on COSMOS | Used by |
|---|---|---|---|
| Open5GS | open-source 5G core (and 4G EPC), AGPL-licensed, one process per network function | natively, as systemd services on the RAN host itself | the OCUDU tutorials |
| OAI CN5G | the OpenAirInterface project's 5G core | Docker containers (oai-amf, oai-smf, oai-upf, mysql, oai-ext-dn) on the RAN host or a core host |
the Duranta tutorials |
| Aether SD-Core | the Aether project's cloud-native 5G core | Kubernetes (Helm charts on RKE2) on its own server; stand it up with Deploy Aether SD-Core | the two-server SD-Core tutorial, the 2026-09-22 OCUDU O-RU runs and the RIC tutorial |
Amarisoft's ltemme is a fourth core in practice, but it is normally used only with Amarisoft's own gNB.
The cores differ mainly in how much machinery they bring. Open5GS is the lightest: a soft-only cell needs one node, and restarting a network function is one systemctl command. OAI CN5G is a fixed Docker Compose set that the Duranta images bring up for you. SD-Core is closest to a production deployment and is the right choice when the core itself is the object of study, but it needs its own server and has operational rules of its own (for example, never restart its SMF; restart the AMF or the UPF pod instead). The core pages explain each one.
¶ The three modalities
COSMOS runs each stack in up to three ways of attaching the radio. The concepts are introduced in 5G SA fundamentals and, for the split, in O-RAN on COSMOS.
Figure — The three modalities side by side. Notice what moves: in soft-only everything is on one host and no radio exists; over the air the gNB drives an SDR itself; in O-RAN 7.2 the low PHY leaves the server and runs in a separate O-RU reached over a fronthaul network.
- Soft-only (no radio). The gNB and a software UE exchange baseband samples over a software transport (ZMQ for OCUDU, RFsim for Duranta) on one node. No SDR, no RF, no radio reservation; it runs on any COSMOS server node. Use it to learn the stack, for CI and for protocol work. Throughput is not limited by the air interface, so the server's CPU sets it.
- Over the air (SDR). The gNB drives a USRP SDR (NI N310 or X310) directly, and a UE attaches over a real n41 (2.6 GHz) air interface. These tutorials run on the
sb1andgriddomains, which have the USRPs. You get real RF, real link adaptation, and a commercial modem as the UE. - O-RAN 7.2 split. The low physical layer (FFT, cyclic prefix, PRACH extraction) moves out of the gNB into a separate O-RU. The server becomes an O-DU and exchanges frequency-domain IQ samples with the O-RU as eCPRI frames over Ethernet, with PTP timing. The O-RU is either a commercial radio (Benetel RAN650, LiteOn FlexFi, Foxconn RPQN-7801; see the O-RU pool) or a software O-RU driving a USRP. This modality needs a prepared real-time host; see Preparing a real-time RAN host.
¶ Modality × platform matrix
The status of every combination, with the tutorial that covers it. "Works" means end to end: registration, PDU session, ping and iperf3 through the UE.
| Modality | OCUDU | Duranta | Amarisoft |
|---|---|---|---|
| Soft-only | works — ZMQ + srsue + Open5GS (three-mode parity 2026-09-14) |
works — RFsim + nr-uesoftmodem + OAI CN5G (three-mode parity 2026-09-08) |
not available — Amarisoft has no software radio transport between lteenb and lteue |
| Over the air, USRP | works — N310 + Open5GS, modem and lteue (three-mode parity 2026-09-16) |
works — N310 + OAI CN5G + modem (three-mode parity 2026-09-08) | works — gNB + core + lteue or modem (2026-07-15); 1–64 UE capacity sweep (2026-09-13) |
| O-RAN 7.2, software O-RU | works — ProtO-RU on a USRP N310 (2026-09-15) | works — nr-oru on a USRP B210 (2026-09-16) |
not applicable |
| O-RAN 7.2, commercial O-RU | Benetel and LiteOn work; Foxconn does not attach yet — tutorial, Foxconn status | Benetel and LiteOn work; Foxconn is an open blocker — tutorial | no standardized tutorial |
| Cloud-native core (SD-Core) | works — two-server tutorial (2026-09-18) and the 7.2 O-RUs (2026-09-22) | not documented | uses its own core |
| Near-RT RIC (E2) | KPM monitoring works; RC control is rejected by this build — tutorial (2026-09-22) | not documented | not documented |
The dates are each tutorial's Last verified date; follow the link for what was verified and on which image.
¶ Headline results on the commercial O-RUs
The most recent like-for-like measurements, all on the same CPU platform (B: 2× Intel Xeon Gold 6126, 24 cores / 48 threads), 100 MHz n78, a Quectel RM520N-GL UE, and the O-RU restored to its captured working state before the DU started. Each platform page has the complete matrix across all modalities and CPU platforms.
| RAN platform | O-RU | Core | DL, Mbit/s | UL, Mbit/s | Date · image |
|---|---|---|---|---|---|
| OCUDU | Benetel RAN650 | Open5GS | 209–220 | 78 | 2026-09-22 · ocudu-20260916 |
| OCUDU | Benetel RAN650 | Aether SD-Core | 189–214 | 74 | 2026-09-22 · ocudu-20260916 |
| OCUDU | LiteOn FlexFi | Aether SD-Core | 117–121 | 76 | 2026-09-22 · ocudu-20260916 |
| Duranta | Benetel RAN650 | OAI CN5G | 186–218 | 57–61 | 2026-09-22 · image not recorded in the run notes |
| Duranta | LiteOn FlexFi | OAI CN5G | 157–163 | 38–39 | 2026-09-22 · image not recorded in the run notes |
UL on these rows is bounded by DL-heavy TDD patterns, not by the platform. Do not compare these numbers with the soft-only or over-the-air rows on the platform pages: those use 10 MHz and 40 MHz carriers.
¶ Which platform should I start with?
The honest answer depends on what you want to learn. Each recommendation below gives the reason.
- You want to see 5G SA work end to end with no hardware. Start with the OCUDU soft-only tutorial or the Duranta soft-only tutorial. Either runs on any server in about 20 minutes, and the whole attach sequence appears in the logs. OCUDU's path leads into the most follow-on tutorials; Duranta's leads into the M-Plane work.
- You want real RF and a commercial modem, without O-RAN. Take an over-the-air tutorial on
sb1orgrid. OCUDU's is the most recently verified; Duranta's is the same shape with OAI's scheduler; Amarisoft's shows a commercial stack. - You want to understand the O-RAN 7.2 fronthaul itself. Use a software O-RU first (OCUDU + ProtO-RU or Duranta +
nr-oru). Both ends of the fronthaul are software, so you see timing-window and sequence counters on both sides, which a commercial O-RU never shows. - You want a commercial O-RU at 100 MHz. Both open platforms work with the Benetel and the LiteOn. Choose OCUDU if you also want SD-Core or a RIC on the same rig. Choose Duranta if you want to study the M-Plane: it is the only platform here that configures the O-RU over NETCONF, and Duranta with the LiteOn is the positive control for "is the radio broken, or is this DU unable to drive it?".
- You want the core to be the object of study. Use OCUDU with Aether SD-Core: a Kubernetes-native core on its own server, with N2 and N3 on a real data plane. Start with Deploy Aether SD-Core.
- You want RAN telemetry or closed-loop control. Use OCUDU with the near-RT RIC. Monitoring (E2SM-KPM) works today; control (E2SM-RC) does not yet.
- You want many UEs, 4G LTE, or a commercial reference point. Use Amarisoft.
lteuedrives 1 to 64 simulated UEs from one radio in the capacity-sweep tutorial, and it is the only stack here that also runs LTE. - You need licence-free or open-source software. OCUDU or Duranta. Amarisoft needs a licence seat for each component, and only one seat per component tag exists on the whole testbed.
¶ How the platforms interoperate
Because PLMN, UE pool and SIM provisioning are common, the parts mix:
- Any RAN with any open core. The gNBs speak standard NGAP and GTP-U, so OCUDU runs against Open5GS or SD-Core, and the cores are documented separately from the RANs. The tested pairings are the ones in the tables above; other pairings are possible but not documented.
- Cross-vendor UEs. Amarisoft's
lteue, on a second USRP, is used as a UE against OCUDU over the air and against Duranta over a Benetel O-RU (see each platform's performance table). The Quectel modem works with all three. - Shared O-RUs. OCUDU and Duranta drive the same physical Benetel and LiteOn radios. That sharing is the source of the most expensive trap in the group, described below.
¶ UE options
| UE | Type | Works with | Notes |
|---|---|---|---|
| Quectel RM520N-GL | commercial (COTS) 5G modem | over the air on all three; O-RAN 7.2 on OCUDU and Duranta | the reference UE; see the commercial UE |
Amarisoft lteue |
software UE over a second USRP | over the air on Amarisoft and OCUDU; Duranta over the Benetel O-RU | many UEs on one radio; does not attach until it receives power_on through its API |
srsRAN srsue |
software UE over ZMQ | OCUDU soft-only | part of the OCUDU soft-only tutorial |
OAI nr-uesoftmodem |
software UE over RFsim | Duranta soft-only | part of the Duranta soft-only tutorial |
If the modem registers and receives an IP address but passes no traffic, the usual cause is on the UE host, not in the RAN: the modem's USB bulk transfers fail with -EPROTO. The tutorial bundles reset the USB device automatically; the manual recovery is on the commercial UE.
¶ The shared O-RU keeps the last stack's configuration
A commercial O-RU stores configuration that survives power cycles. OCUDU and Duranta need different values on the same Benetel RAN650: OCUDU needs the RU standalone (M-Plane off), mimo_mode 1_2_3_4_4x2, dynamic_compressed and the TDD pattern DDDDDDDSUU; Duranta needs M-Plane on, 1_2_3_4_4x4, static_compressed and DDDSU. The M-Plane mode also moves the Benetel's PRACH eAxC lanes from 4,5,6,7 (standalone) to 8,9 (M-Plane). A DU started against a radio configured for the other stack sees a clean fronthaul and healthy counters and still fails: an OCUDU DU on Duranta's settings delivers about 3 Mbit/s downlink where the correctly configured rig delivers 209–220.
Warning: Before starting a DU on a shared O-RU, restore that rig's golden O-RU state (the capture committed when the rig last worked) and confirm the diff is empty. The 7.2 bring-up scripts do this and refuse to start the DU on a mismatch. The concept is explained in O-RAN on COSMOS; the commands are in each 7.2 tutorial.
Figure — The three ways an O-RU gets its configuration. Duranta uses the first (it is the NETCONF client and holds the session); OCUDU needs the second (the RU runs from its own stored configuration); COSMOS tooling adds the third, writing and verifying the RU state before any DU starts.
¶ Tutorials by platform
The group is laid out as a course; the full learning path is on the group landing page. Within each platform, take the tutorials in this order.
| Step | OCUDU | Duranta | Amarisoft |
|---|---|---|---|
| 1 — Soft-only | OCUDU soft-only | Duranta soft-only | — |
| 2 — Over the air | OCUDU over the air | Duranta over the air | Amarisoft over the air |
| 3 — 7.2, software O-RU | OCUDU + ProtO-RU | Duranta + nr-oru |
— |
| 4 — 7.2, commercial O-RU | OCUDU + Benetel/LiteOn/Foxconn · Foxconn status | Duranta + Benetel/LiteOn/Foxconn | — |
| 5 — Cloud-native core | Deploy SD-Core → OCUDU + SD-Core, two servers | — | — |
| 6 — RAN intelligence | OCUDU + near-RT RIC, E2/KPM | — | — |
| 7 — Scale and measurement | — | — | Amarisoft UE capacity sweep |
¶ Reference: how the 7.2 fronthaul reaches a server
For the O-RAN 7.2 split, the fronthaul does not get its own interface or IP address. The eCPRI user/control planes and the PTP synchronization plane ride as tagged VLANs on the server's data-plane switch port. Each O-RAN server's fronthaul NIC connects to one switch port configured as a G.8275.1 PTP boundary-clock (BC) master, trunked as:
- untagged / native VLAN = the node's data VLAN (the data plane itself)
- tagged VLAN 4 = eCPRI U-/C-plane
- tagged VLAN 5 = PTP S-plane
- MTU 9216 (jumbo, for eCPRI IQ frames)
- PTP =
ptp enable,ptp role master,ptp transport layer2, domain 24, G.8275.1 profile
The two publicly reservable large-form servers on sb1, srv1-lg1.sb1 and srv2-lg1.sb1, each present their fronthaul NIC on such a port. On the Dell OS10 aggregation switch it looks like this:
interface ethernet 1/1/25:1
description "srv1-lg1.sb1 fronthaul"
switchport mode trunk
switchport access vlan 38 ! node data VLAN, untagged
switchport trunk allowed vlan 4-5 ! eCPRI (4) + PTP S-plane (5), tagged
mtu 9216
ptp enable
ptp role master
ptp transport layer2
ptp announce interval -3
ptp sync-interval -4
The switch itself must be a G.8275.1 boundary clock (ptp clock boundary profile g8275.1, domain 24, ptp system-time enable) with a slave port toward the grandmaster. The O-RAN server's ptp4l then locks the NIC's hardware clock (PHC) from this port, and phc2sys disciplines CLOCK_REALTIME from the PHC. The same pattern applies to every O-RAN 7.2 server. The host side of this (PTP, CPU isolation, SR-IOV, MTU) is on Preparing a real-time RAN host; the data-plane MTU standard is on Data-plane MTU.
¶ Where to go next
- New to 5G SA: 5G SA fundamentals.
- New to O-RAN terms (7.2x, eAxC, M-Plane, T1a/Ta4): O-RAN on COSMOS.
- Ready to choose: the OCUDU, Duranta or Amarisoft overview.
- Ready for hands-on work: step 1, the OCUDU soft-only tutorial.
- Testbed basics: Getting started · SSH access · OMF commands · SDR hardware · Domains.
¶ Further reading
- 3GPP TS 23.501 — the 5G system architecture: network functions and reference points.
- 3GPP TS 38.401 — NG-RAN architecture, including the CU/DU split.
- O-RAN ALLIANCE specifications — the Open Fronthaul, M-Plane and E2 specifications.
- srsRAN Project documentation — the code base under OCUDU.
- OpenAirInterface — the project Duranta forks.
- Amarisoft Tech Academy — vendor documentation for
lteenb,ltemmeandlteue. - Open5GS documentation · OAI CN5G · Aether documentation — the three cores.
Author(s): COSMOS team · Last verified: not re-tested; updated 2026-09-14 (O-RAN 7.2 status, tutorial lists, per-platform overview pages). Base content verified 2026-07-15; see each tutorial for its own date. · text revised 2026-09-24 · Standardized on: PLMN 00101, UE pool 192.168.100.0/22, images ocudu.ndz / duranta.ndz / amarisoft.ndz / lte5gue.ndz · Tags: 5g, sa, ocudu, srsran, duranta, oai, amarisoft, oran, overview