¶ Aether SD-RAN on COSMOS — the ONOS-based near-RT RIC
Aether SD-RAN is the Aether project's near-real-time RAN Intelligent Controller (near-RT RIC): a set of ONOS microservices on Kubernetes that terminate the O-RAN E2 interface, keep a live model of the RAN, and host xApps. This page explains what SD-RAN is made of, how it differs from the O-RAN Software Community (O-RAN SC) RIC that COSMOS uses with its real radios, how it is deployed on COSMOS next to Aether SD-Core, and what works today. Read the near-RT RIC page first for the concepts (E2, E2AP, service models, xApps); this page goes into SD-RAN only.
¶ What it is
A near-RT RIC observes a live radio access network (RAN) over E2 and, where the base station allows it, steers it on timescales from about 10 ms to 1 s. The O-RAN introduction places it in the O-RAN architecture; the RIC page explains the E2 procedures.
Figure — The O-RAN architecture. SD-RAN occupies the near-RT RIC box: it reaches the O-CU and O-DU over E2 and is itself reached from the SMO over A1. Notice that it is not on the path between the UE and the core.
SD-RAN was developed by the Open Networking Foundation (ONF) as part of Aether, the open-source private-5G platform now hosted by the Linux Foundation. It is built on µONOS, a rewrite of the ONOS network operating system as Kubernetes microservices, and uses Atomix for replicated state. Its documentation is at docs.sd-ran.aetherproject.org; the Helm charts are published as oci://ghcr.io/onosproject/charts/....
The problem SD-RAN set out to solve is the controller side of an open RAN: a scalable, highly available platform where the RAN's topology, per-UE state and configuration live in shared stores that many xApps can read, with standard northbound APIs instead of vendor tools. It ships with a RAN simulator (RANSim) so that xApp logic can be developed and tested without radios.
Info: SD-RAN is in maintenance upstream. Its current chart,
sd-ran1.5.2, dates from 2024-11, and Aether OnRamp's separateaether-sdranrepository was archived in 2026-03; the deployment roles now live in OnRamp itself (deps/sdran,make aether-sdran-install).
¶ Architecture and components
Figure — E2 between a gNB and a near-RT RIC. The gNB's E2 agent opens an SCTP association to the RIC's E2 termination; indications flow up to xApps and control requests flow down. SD-RAN is drawn as the alternative RIC: on COSMOS its E2 termination (onos-e2t) serves RANSim's simulated nodes, while a real OCUDU gNB does not complete E2 Setup with it.
Figure — SD-Core (namespace aether-5gc) and SD-RAN (namespace sdran) share one RKE2 cluster; the gNB reaches the core over N2/N3 and the RIC over E2. RANSim completes E2 Setup; a real gNB does not yet.
On COSMOS, SD-RAN runs as eleven pods in the Kubernetes namespace sdran, plus two platform charts in kube-system.
| Component | What it does | Where |
|---|---|---|
| onos-e2t | The E2 termination: the SCTP endpoint E2 nodes connect to (container port 36421). It decodes E2AP v2, completes E2 Setup, and relays subscriptions from xApps to E2 nodes and indications back. The release deployed on COSMOS has no separate subscription-manager pod; subscriptions go through onos-e2t. |
sdran |
| onos-topo | The topology store: every E2 node and cell as an entity with typed aspects (onos.topo.E2Node, onos.topo.E2Cell, mastership state). onos topo get entities reads it. |
sdran |
| onos-config | The configuration service: holds configuration for RAN elements and applies it through gNMI. | sdran |
| onos-uenib | The UE network information base: per-UE state that xApps publish and read. | sdran |
| onos-a1t | The A1 termination: the interface on which a non-real-time RIC in the SMO sends policies to xApps. | sdran |
| onos-kpimon | The KPI-monitor xApp: subscribes to E2SM-KPM on every E2 node it finds and stores the reported measurements. | sdran |
| onos-cli | A pod carrying the onos command-line client for all of the services above. |
sdran |
| ran-simulator | RANSim: simulated E2 nodes with cells and UEs, speaking E2AP to onos-e2t exactly as a real gNB would. |
sdran |
| sd-ran-consensus-0, -1, -2 | A three-member Atomix consensus store (Raft) that holds the replicated state of the ONOS services. | sdran |
| atomix | The Atomix platform chart (controllers for the consensus stores). | kube-system |
| onos-operator | The operator that manages ONOS configuration models and applications. | kube-system |
xApps in the catalogue. Besides onos-kpimon, the SD-RAN project ships xApps for PCI conflict resolution (onos-pci), mobility handover (onos-mho), mobility load balancing (onos-mlb), RAN slicing (onos-rsm) and traffic steering. None of them runs on COSMOS; onos-kpimon is the only xApp in the deployed release.
Service models. SD-RAN speaks E2AP v2. It implements E2SM-KPM v2 plus ONF-specific service models: RC-PRE (a pre-standard RAN control model), MHO (mobility handover) and RSM (RAN slice management). The xApps above depend on those ONF models; a gNB that implements only the O-RAN ALLIANCE models can serve onos-kpimon but not the control xApps.
¶ How SD-RAN differs from the O-RAN SC RIC
Both are near-RT RICs and both terminate E2, but they are built for different jobs. The O-RAN SC RIC used in the E2 KPM tutorial is a set of Docker containers on one host, tested upstream against the srsRAN E2 agent that OCUDU inherits. SD-RAN is a Kubernetes-native platform whose state lives in replicated stores and whose default RAN is a simulator.
| O-RAN SC near-RT RIC | Aether SD-RAN | |
|---|---|---|
| Origin | O-RAN Software Community, i-release, packaged by srsRAN as oran-sc-ric |
ONF µONOS, part of Aether |
| Deployment | Docker Compose, one host | Kubernetes (RKE2 on COSMOS) + Helm |
| E2 termination | e2term, with e2mgr and submgr alongside |
onos-e2t |
| E2AP | the generation the srsRAN/OCUDU E2 agent speaks | E2AP v2 |
| Service models | E2SM-KPM, E2SM-RC | E2SM-KPM v2, RC-PRE, MHO, RSM |
| State | Redis (dbaas) |
Atomix consensus store; topology and UE stores as services |
| Default RAN | a real gNB | RANSim |
| xApps on COSMOS | KPM monitor, RC control example | onos-kpimon |
| Status on COSMOS | KPM monitoring works with OCUDU on soft, LiteOn and Benetel rigs | works with RANSim; a real gNB cannot complete E2 Setup |
¶ How it runs on COSMOS
SD-RAN runs on the same single-node RKE2 cluster as Aether SD-Core, on the SD-Core core host, in its own namespace sdran. The core's namespace aether-5gc is not touched: during and after the SD-RAN install all sixteen SD-Core pods stayed Running. Stand the core up first with Deploy Aether SD-Core, then follow SD-RAN with RANSim.
The install is three Helm releases: atomix 1.1.2 and onos-operator 0.5.6 into kube-system, then sd-ran 1.5.2 into sdran. OnRamp carries these steps in its deps/sdran roles; on the COSMOS checkout the role's variables were not wired, so the same Helm installs were run by hand, as the tutorial shows.
SD-RAN needs one thing the SD-Core cluster does not have by default: a default StorageClass for its persistent volumes. COSMOS adds the Rancher local-path provisioner and marks it default. That was safe on the SD-Core cluster because it had no StorageClass at all and SD-Core uses no persistent volume claims.
The E2 termination is published outside the cluster as the NodePort Service onos-e2t-external, which maps node port 36401 to the pod's SCTP port 36421. A gNB points its E2 agent at the core host's data-plane address and port 36401.
¶ When to choose it
For work with the real COSMOS radios, use the O-RAN SC RIC: it pairs with the E2 agent built into OCUDU, it is maintained upstream, and it is proven on COSMOS end to end for KPM monitoring. The RIC page compares them in full.
Choose SD-RAN when the object of study is the RIC platform or xApp logic rather than a particular radio:
- to see a Kubernetes-native RIC — replicated state, a topology service, operators and Helm — next to a Kubernetes-native core on the same cluster;
- to develop against the ONOS northbound APIs and the larger xApp catalogue (handover, PCI, load balancing, slicing, traffic steering) using RANSim, without reserving radios;
- to compare two RIC architectures side by side.
Its honest limitations on COSMOS: it drives only its own simulator, a real OCUDU gNB does not complete E2 Setup with it, the control xApps need ONF service models that OCUDU does not implement, and upstream development has stopped.
¶ Tutorials
| Step | Tutorial | What it covers | Status |
|---|---|---|---|
| 5 | Deploy Aether SD-Core | the cluster SD-RAN runs on | working |
| 6 | SD-RAN with RANSim — deploy and read KPM | install SD-RAN on the SD-Core cluster, list the simulated E2 nodes and cells, confirm KPM indications | working with RANSim, verified 2026-09-22; real gNB open |
| 6 | Near-RT RIC + OCUDU — E2 KPM monitoring | the O-RAN SC RIC with a real gNB, for comparison | verified 2026-09-22 |
¶ Performance
SD-RAN has no throughput measurement on COSMOS: with RANSim, the reported values are simulated, and no real gNB has completed E2 Setup with it. The measured E2/KPM results on COSMOS are all from the O-RAN SC RIC and are on the RIC page.
What was verified on 2026-09-22 with RANSim: onos topo get entities lists 2 E2 nodes and 3 cells; onos-e2t logs RICIndication successfully decoded; and onos-kpimon's subscriptions are acknowledged every second.
¶ Known limitations and open issues
- A real gNB's E2 Setup is never acknowledged (open). An OCUDU gNB pointed at
onos-e2tlogsE2: Connection ... established, offers its KPM, RC and CCC RAN functions, and after five seconds logsE2 Setup procedure failed. cause=unknown. The SCTP association itself is healthy: INIT, INIT ACK, COOKIE ECHO and COOKIE ACK complete, ten streams are negotiated, and heartbeats flow in both directions.onos-e2tlogs an accepted connection followed by end-of-file, never a decode error or a rejected setup. Exposingonos-e2tthrough the NodePort and through a ServiceexternalIP(the way SD-Core's AMF carries N2 over SCTP from the same gNB host) fail identically. Message size, SCTP stream counts and the pod network do not explain it, and the same gNB binary completes E2 Setup with the O-RAN SC RIC. Captures taken at the RIC end in the two exposure modes disagree about whether the E2 Setup Request's DATA chunks reach the core host at all; the next diagnostic step is to capture the gNB host and the core host simultaneously. The cause is open. - Service-model mismatch for control. Even with E2 Setup working, SD-RAN's control xApps use ONF service models (RC-PRE, MHO, RSM) that OCUDU's E2 agent does not offer; only KPM would be common ground.
- Maintenance mode upstream. Expect no fixes; pin the chart versions shown in the tutorial.
- Storage side effect. The install adds a default StorageClass to the cluster. On a cluster that already has a default, do not repoint it.
¶ Further reading
- SD-RAN documentation — architecture, the ONOS components, RANSim and the xApps.
- SD-RAN Helm charts — the
sd-ranumbrella chart and its sub-charts. - Aether documentation and Aether OnRamp — the platform and the deployer (
deps/sdran). - O-RAN ALLIANCE specifications — E2AP and the E2 service models.
- O-RAN Software Community — the other near-RT RIC.
- Kubernetes documentation and RKE2 documentation — the cluster SD-RAN runs on.
- On this wiki: Near-RT RIC · Aether SD-Core · O-RAN introduction · O-RAN SMO · OCUDU.
Author(s): COSMOS team · Last verified: 2026-09-22 (SD-RAN chart 1.5.2 with RANSim on the SD-Core RKE2 cluster; real-gNB E2 Setup open) · page written 2026-09-24 · Tags: sd-ran, onos, ric, near-rt-ric, e2, kpm, xapp, ransim, aether, kubernetes, overview