Open Fronthaul in Racora
An O-RU over Open Fronthaul (the O-RAN 7.2 split) is driven on three planes and
locked to one clock, and all four come from different places. The U-plane and
C-plane are the radio samples and their control, raw Ethernet frames the DU sends
to the O-RU's MAC address over the node's fronthaul port. The M-plane is a
NETCONF session that provisions the O-RU (its carriers, its VLANs, its endpoints)
and supervises it while it runs. The S-plane is PTP: the O-RU locks its clock
to the fronthaul port's grandmaster and refuses to carry anything until it has.
Racora runs all of it from one NRCell and from the
node that cell lands on.
Who Runs What
| Part | Runs as | Does |
|---|---|---|
| the DU | the du container of the cell's DU pod, on the host network of a fronthaul-ready node | the U/C-plane stream to the O-RU's MAC over the node's fronthaul port, F1 to the CU; the OFH timing and TX/RX threads on the node's first isolated cores |
| the M-plane client | the mplane native sidecar of the same pod: the OCUDU O1 adapter | provisions the O-RU from the cell's ru.yml, holds the supervised session, and gates the DU: its startup probe is the adapter's /ru/ready, which answers only once every carrier is active |
| the fronthaul agent | the DaemonSet fronthaul-agent, one per fronthaul-ready node | gives every O-RU a cell on its node names its address (DHCP on the fronthaul port, on whatever VLAN tag the O-RU asks on, with the O-RAN options that name the node as its M-plane controller), probes it from the port, and advertises it as the device resource racora.io/oru: the DU schedules only where its O-RU answers, and the controller sees the O-RU's health while the DU runs (The Fronthaul Agent) |
| the node substrate | the provisioner, on the host, before the node joins | the timing: the NIC's hardware clock as the root (a grandmaster free-running on the NIC's oscillator or following GNSS, or an ordinary clock to your grandmaster), TAI on the wire; the RT-latency stage; the racora.io/fronthaul-ready label and the inventory that names the port |
| the controller | racora-controller | renders both ends of the fronthaul from the cell (the DU's ru_ofh and the O-RU's ru.yml), places the pod, writes RadioReady and DUReady, and replaces the pod when the DU restarted or the O-RU went unreachable |
The division follows what each part can see. The controller sees API objects, never hardware. The sidecar lives and dies with the DU pod, so it can hold a session but cannot be the thing that is there when no DU is. The agent is on the node and outlives every pod, so it is the one that watches the port. The provisioner runs before Kubernetes does, so it owns what has to be true before the first pod starts.
What a Cell Declares
One NRCell with radioBackend.ruType: ofh carries everything the fronthaul needs,
and nothing is typed twice:
- the radio side in
radioBackend.ofh: the O-RU's MAC (ruMacAddr), the VLAN, the eAxC identifiers, the gains and the compression, either on the cell or in a radio profile ConfigMap the cell names (profileRef), the cell winning on conflicts; - the M-plane session in
radioBackend.ofh.mplane: the O-RU's address (netconfHost, orcallHomefor an O-RU that dials in) and the Secret that holds its account (credentialsSecret); - the node in
duAssignment.nodeName, when more than one node isfronthaul-ready.
From those the controller renders the DU's fronthaul configuration and the O-RU's provisioning file, the agent knows which O-RU to watch and from which port, and the sidecar knows what to provision. The step by step is Connect a Radio; what each backend produces is How Radios Are Driven.
What Your Fronthaul Network Provides
The cabling, the fronthaul port's own address (the provisioner leaves that to the host's network configuration), and power to the O-RU. The O-RU's address is Racora's: the cell names it, and the agent on the node hands it out when the O-RU asks, on whatever VLAN tag it asks on. There must be no other DHCP server on the fronthaul segment. An O-RU with a static address is only probed, never asked for.
In This Section
- The Fronthaul Agent: what the node-side agent watches, what it advertises, and how the DU and the controller use it.
- From Power-On to Streaming: the order things happen in, from the O-RU powering on to the DU streaming, and what Racora does when one step fails.