From Power-On to Streaming

An Open Fronthaul cell comes up in a fixed order, because each step needs the one before it: the O-RU needs the clock before it provisions, the DU needs the O-RU provisioned before it streams. This page is that order, with the piece of Racora that owns each step, and what happens when a step fails.

The Order

1. The node is ready. The provisioner has left it fronthaul-ready: the PTP services run on the fronthaul port with the NIC's clock as the root and TAI on the wire, the RT-latency and link stages hold, and the inventory names the port (Node Provisioner). The fronthaul agent is running on it, holding the port's link settings and reading the clock's state.
2. The O-RU powers on and attaches. It asks for an address, untagged first and then on one VLAN tag after another, and the agent answers the first request it hears from a MAC a cell names: the cell's address, and the node as the M-plane controller. Answered on a VLAN, the O-RU runs its M-plane there and the agent gives the node the sub-interface and route for it. The O-RU locks its clock to the port's PTP. An O-RU that was already scanning when the cell was applied may not keep an answer it gets in the middle of a pass: one left scanning for days took each tagged lease, dropped it three seconds later and moved to the next tag, and kept only the one it was given at the end of its range, half an hour after the cell was applied. Apply the cell before the O-RU powers on, or let the pass finish, or reset the O-RU.
3. The agent sees the O-RU. Its probe reaches the O-RU's NETCONF port (the agent logs netconf-closed while the O-RU's software is still starting), and the device racora.io/oru for that cell turns Healthy (The Fronthaul Agent).
4. The cell is applied. The controller renders the DU's fronthaul configuration and the O-RU's provisioning file from the cell and its radio profile, and creates the DU Deployment. The scheduler places the pod on the node whose agent reports the O-RU healthy.
5. The sidecar provisions the O-RU. The mplane sidecar connects, provisions the O-RU from the cell, activates its carriers and supervises the session. Its /ru/ready answers 503 until every carrier is active, so the DU waits; RadioReady goes from Provisioning to Ready.
6. The DU starts. It waits for the CU-CP, brings up F1, and starts the fronthaul stream onto the O-RU; DUReady is True. A phone can attach.

Steps 2 to 6 need nobody: cable and power the O-RU, apply the cell, and the cell reports each step in its conditions.

kubectl -n racora-system get nrcell <cell> -o jsonpath='{range .status.conditions[*]}{.type}={.status}/{.reason}{"\n"}{end}'
kubectl -n distributed-unit logs <du pod> -c mplane      # the M-plane conversation

When a Step Fails

What you see	What happened	What Racora does	What you do
the DU pod stays Pending, Insufficient racora.io/oru; RadioReady=False/Unreachable	no fronthaul-ready node reaches the O-RU on its NETCONF port	waits: the pod schedules the moment an agent reports the O-RU healthy	the agent's log: a DHCP line means the O-RU asked and got its address (then netconf-closed is its software still starting); no DHCP line means it never asked (power, cable), or asked from a MAC no cell names (an UnknownORU Event on the node: check ruMacAddr)
DHCP lines on one tag after another, each with an OFFER and an ACK, and the O-RU still unreachable	the O-RU was scanning before the cell was applied and does not keep a lease in the middle of a pass	keeps answering every request it hears, so the attach comes when the pass completes	wait for the end of the pass (hours at most), or reset the O-RU so it starts over untagged
RadioReady=False/Provisioning for minutes	the sidecar is connected but the O-RU does not reach active carriers: no PTP lock, an account the O-RU refuses, an edit it rejects	keeps trying; the DU keeps waiting	read the sidecar's log and its /ru/status (Troubleshooting)
DUReady flips to False, then the pod is replaced; Event DURestarted	the DU container restarted	deletes the pod: a DU must never resume a stream onto an O-RU that kept its carriers active; the replacement provisions the O-RU again before its DU starts	nothing, unless it repeats: then the DU's log
RadioReady=False/Unreachable under a running DU; after the grace the pod is replaced; Event RadioUnreachable	the O-RU stopped answering: it reset, lost power or its cable	after ofhUnreachableGraceSeconds deletes the pod; the replacement waits for a healthy O-RU, then provisions it again	find out why the O-RU went away; once it is back and reachable the cell comes up on its own
the node rebooted	power, or you	the DU pod the node left behind is removed and its replacement waits for the O-RU; the agent, back with the node, answers the O-RU's request on whatever tag it is on, and the cell comes up as on first apply	nothing
the cell is deleted	you took it down	the pod goes, and with it the DU and the M-plane session; the agent stops serving the O-RU and removes its VLAN sub-interface	nothing; the O-RU's own supervision watchdog notices the lost session, takes its carriers down and, on most O-RUs, resets; it asks for an address again, and gets one again once a cell names it

Taking a cell down and restarting one are on Connect a Radio.