O-RAN Architecture (DU / CU / RIC)
The telecom sensor monitors disaggregated O-RAN components (O-DU, gNB-CU-CP, gNB-CU-UP, Near-RT RIC, and xApps) as distinct roles with per-interface protocol tracking and WG11 compliance evidence.
Requires: Telecom sensor flavor and
telecomConsole vertical.
Role assignment
Set the O-RAN role for a node during enrollment using the Console enrollment wizard. The sensor uses port binding analysis to auto-detect roles when the declaration is omitted, but explicit assignment is always preferred for timing-sensitive RAN nodes.
| Component | Enrollment value | Auto-detection signal |
|---|---|---|
| gNB-CU-CP | cucp | F1AP SCTP 38472 + E1AP SCTP 38462 |
| gNB-CU-UP | cuup | E1AP SCTP 38462 |
| gNB-DU | o_du | F1AP SCTP 38472 |
| gNB (monolithic or N2 endpoint) | gnb | NGAP SCTP 38412 |
| Near-RT RIC | near_rt_ric | E2AP SCTP 36421 (37464 alternate) |
| xApp | auto-detected | E42 SCTP 36422 (connector) |
| E2 Node | auto-detected | E2AP SCTP 36421 (37464 alternate) |
| O-RU | o_ru | No protocol auto-detection; requires explicit declaration |
All RAN roles carry a 99.9% (3-nines) SLO target. The SLO breach and suppression behavior follows the same rules as 5G Core roles: 300-second minimum observation window, 3,600-second re-alert suppression.
F1 interface (gNB-CU-CP and gNB-DU)
The F1 interface connects the gNB-CU-CP to the gNB-DU over SCTP port 38472 (PPID 62). The sensor monitors F1AP at both endpoints.
Procedures monitored
| Procedure | What the sensor captures |
|---|---|
| F1SetupRequest / F1SetupResponse | DU registration with CU-CP; setup failure count |
| InitialULRRCMessageTransfer | UE RRC context establishment from DU |
| DLRRCMessageTransfer | CU-CP to DU RRC message (NAS and mobility content) |
F1AP anomalies
| Anomaly | Meaning |
|---|---|
| Repeated F1SetupFailure | DU cannot register with CU-CP; indicates radio coverage loss or configuration mismatch |
| RRC context lost unexpectedly | Bearer failure or DU crash during active UE session |
O-RAN WG11: ORAN_CUDU
The ORAN_CUDU compliance control evaluates the F1 and E1 interface boundary: whether observed F1AP and E1AP peers are authorized, whether TLS is in use on the F1 connection, and whether setup failures exceed threshold. This control covers the architectural boundary between CU and DU where unauthorized components would first appear.
E1 interface (gNB-CU-CP and gNB-CU-UP)
The E1 interface carries bearer context between the gNB-CU-CP and gNB-CU-UP over SCTP port 38462 (PPID 64).
Procedures monitored
| Procedure | What the sensor captures |
|---|---|
| E1SetupRequest / E1SetupResponse | CU-UP registration with CU-CP |
| BearerContextSetupRequest / Response | Data bearer creation, outcome |
| BearerContextModification | QoS or routing change on an existing bearer |
E1AP metrics
- Bearer setup latency per CU-UP
- Bearer setup failure count
- Bearer modification rate
Xn interface (gNB to gNB)
The Xn interface connects neighboring gNBs for inter-gNB handover coordination over SCTP port 38422.
Procedures monitored
| Procedure | What the sensor captures |
|---|---|
| XnSetupRequest / XnSetupResponse | Neighbor gNB registration |
| HandoverRequest / HandoverResponse | Inter-gNB handover |
| UEContextRelease | Tunnel cutover after handover |
XnAP anomalies
| Anomaly | Meaning |
|---|---|
| Handover success rate drops | Degraded radio conditions or inter-gNB signaling fault |
| Unexpected UEContextRelease from peer gNB | Premature teardown; possible protocol violation |
E2 interface (E2 agent and Near-RT RIC)
The E2 interface connects E2 agents (gNB components) to the Near-RT RIC over default SCTP port 36421. The sensor also recognizes port 37464 for alternate deployments. xApps connect to the Near-RT RIC via SCTP port 36422.
E2AP procedures monitored
| Procedure | What the sensor captures |
|---|---|
| E2 Setup | E2 agent registers with RIC; RANfunctions advertised (CellID, UEID, PRB) |
| RIC Subscription | RIC requests event triggers; subscription ID, action type (report, insert, policy) |
| RIC Indication | E2 node sends RIC metric samples triggered by subscription |
| RIC Control | RIC sends control action to E2 node (e.g., handover trigger) |
E2 service-model evidence
When the E2 Setup exchange maps a RAN function to a supported service model, Telovix identifies bounded container metadata for:
| Service model | Evidence available |
|---|---|
| E2SM-RC | Control or indication container format and decode status |
| E2SM-KPM | Indication container format and decode status |
| E2SM-CCC | Control or indication container format and decode status |
The service-model payload is not retained. A decoded container format confirms the structure that was observed; it does not claim that every measurement or control parameter inside the container was interpreted.
O-RAN WG11: ORAN_E2
The ORAN_E2 compliance control evaluates E2 peer verification: whether E2 agents are connecting to authorized RIC instances, whether the E2 connection uses expected ports, and whether unclassified processes are present on the E2 interface.
eCPRI fronthaul metadata
When eCPRI capture is enabled for a selected sensor and interface, Telovix reports the eCPRI revision, message type, payload size, concatenation state, and available series, sequence, or event identifiers. IQ and other fronthaul payload content is not retained.
Use Live Feed or Investigate, then select eCPRI under Telecom Searches, to inspect sampled metadata events. The Telco O-RAN view provides the bounded current capture status and message counts.
xApp and rApp monitoring
xApps are detected when a process connects to the Near-RT RIC via SCTP port 36422. Binary name patterns (xapp, oran, ric) supplement port detection.
Baseline learning
The sensor observes the xApp for 3 heartbeats (90 seconds) and records the RIC peer IP, port, and binary name. After this window closes, any change to these parameters fires an alert.
xApp alert types
| Alert | Severity | Meaning |
|---|---|---|
NewRicPeer | High | xApp connected to an unknown RIC after the learning window |
PublicRicPeer | Critical | RIC IP is a public internet address; RIC compromise risk |
RicPeerChanged | High | RIC IP changed after baseline was set; potential hijack |
MultipleRicPeers | High | Multiple distinct RIC IPs observed for one xApp; split control plane |
NonStandardE2Port | Warning | E2 connection outside the recognized standard or legacy ports; misconfiguration or attack |
WrongProcessOnE2 | High | Non-RAN process connecting to the E2 interface; architectural violation |
UnclassifiedE2Agent | Warning | Unclassified process on E2; new component or rogue agent |
O-RAN WG11: ORAN_XAPP
The ORAN_XAPP compliance control evaluates xApp and rApp API security: whether xApps connect only to known RIC peers, whether they run with expected privileges, and whether the E42 interface shows anomalous connection patterns.
O1 interface (management plane)
The O1 interface uses NETCONF over SSH (RFC 6241) on port 830 to manage O-RAN components from the SMO (Service Management and Orchestration).
NETCONF operation evidence
For NETCONF traffic visible through a supported plaintext capture path, Telovix reports bounded metadata for hello, rpc, rpc-reply, and notification messages. Evidence can include the operation name, message ID, target datastore, direction, process, and RPC error state. Telovix does not present this metadata as a complete YANG configuration diff.
O1 anomalies
| Anomaly | Meaning |
|---|---|
| New or changed management peer | O1 communication was observed with a peer outside the learned relationship |
| Public management peer | O1 communication reached a public address |
| Unexpected call-home | NETCONF call-home behavior did not match the expected management path |
| Wrong process on O1 | A process outside the expected management role used the O1 path |
O-RAN WG11: ORAN_O1
The ORAN_O1 compliance control evaluates O1 management interface security: whether NETCONF sessions originate from authorized SMO addresses, whether TLS is used on the O1 connection, and whether configuration changes are accompanied by expected notification patterns.
O2 interface (infrastructure orchestration)
The O2 interface exposes a REST API (OpenAPI 3.0, typically port 8080) to the SMO for resource and service orchestration.
Endpoints monitored
| Endpoint | Purpose |
|---|---|
/o2ims/api/v1/alarms | Alarm reporting |
/o2ims/api/v1/events | Event notifications |
/smo/api/v1/resources | Resource pool queries |
Resource tracking
The sensor tracks O2-managed resource allocation for DU, CU-CP, and CU-UP virtual components: CPU, memory, and NIC bandwidth per node, and container lifecycle events.
O2 anomalies
| Anomaly | Meaning |
|---|---|
| Resource exhaustion | CPU or memory limit hit; operational risk |
| Unallocated resource requests | Requests exceed available capacity |
| Orphaned containers | Container allocated via O2 with no corresponding E2 or O1 update |
O-RAN WG11: ORAN_O2
The ORAN_O2 compliance control evaluates O2 infrastructure interface security: whether O2 API calls originate from authorized orchestration addresses and whether resource allocation patterns are consistent with the known topology.
Timing and synchronization
O-RAN components require tight timing synchronization via PTP (Precision Time Protocol). The sensor monitors PTP processes (ptp4l, phc2sys) on nodes where they run.
O-RAN WG11: ORAN_TIMING
The ORAN_TIMING compliance control evaluates timing and synchronization integrity. It checks whether PTP processes show unexpected binary changes, unexpected parent processes, or privilege anomalies that could indicate a timing attack. Timing integrity is particularly relevant for fronthaul-connected O-DU nodes where PHY timing is critical.
Management plane access control
O-RAN WG11: ORAN_MGMT
The ORAN_MGMT compliance control evaluates management plane access control across all O-RAN component roles: whether processes with management-plane access show unexpected network connections, whether management credentials (SSH keys, tokens) are stored in expected paths, and whether new listeners appear on management ports.
WG11 compliance summary
The full set of O-RAN WG11 controls evaluated by the sensor:
| Control ID | Description |
|---|---|
ORAN_O1 | O1 management interface security |
ORAN_O2 | O2 infrastructure interface security |
ORAN_E2 | E2 interface peer verification |
ORAN_TIMING | Timing and synchronization integrity (ptp4l, phc2sys) |
ORAN_MGMT | Management plane access control |
ORAN_CUDU | CU/DU F1 and E1 interface boundary |
ORAN_XAPP | xApp and rApp API security |
Full evidence and status for these controls is available under Reports > Compliance Reports > Control Evidence. Select O-RAN WG11 as the framework.
Console views for O-RAN
O-RAN view
In the Console, go to Telco > Network > O-RAN. The page shows the O-RAN component inventory: Near-RT RIC instances, xApp connections, E2 peer state, O1 and O2 session status, and current WG11 compliance posture per component.
RAN view
In the Console, go to Telco > Network > RAN. The page shows the RAN node inventory across the fleet: gNB-CU-CP, gNB-CU-UP, gNB-DU, and gNB instances, with detected interfaces, SLO status, and current risk level per node.
Filtering runtime events by RAN role
In the Console, go to Monitor > Investigate. Use the NF Role filter to select a role such as near_rt_ric, then set the time range. The filter accepts declared and auto-detected role values.
Operational guidance
Timing-sensitive workloads: O-DU nodes with tight fronthaul timing requirements should start with observer mode before enabling enforcement. Any enforcement action that introduces latency to a timing-sensitive process can affect radio performance. Use Application Restrictions in Audit mode first on O-DU and O-RU nodes.
xApp learning window: The 90-second learning window (3 heartbeats) for xApps is short. If an xApp deployment is still stabilizing at enrollment time, the baseline may capture transient RIC peer addresses. Review the xApp baseline after the deployment reaches steady state and clear it if necessary to allow a clean re-learn.
O-RU nodes: The O-RU enrollment value is o_ru. Because the O-RU is typically a hardware device running a constrained OS, the sensor may operate in limited mode with reduced protocol visibility. Declare the role explicitly; process-level visibility depends on whether the host OS supports the eBPF runtime.
Multiple gNBs on one host: If a host runs multiple gNB component processes (e.g., both CU-CP and CU-UP in a test environment), the sensor detects both role signals and may report dual roles. In production deployments this is unusual. Set the primary role explicitly during enrollment to lock it and suppress secondary classification noise.