Appearance
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 (listener) |
| xApp | auto-detected | E42 SCTP 36422 (connector) |
| E2 Node | auto-detected | E2AP SCTP 36421 (connector) |
| 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 60). 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 60).
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 SCTP port 36421. 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) |
E2AP metrics
| Metric | SLA |
|---|---|
| Cell-level PRB utilization | Tracked |
| Cell beam state and interference | Tracked |
| UE-level SINR and CQI | Tracked |
| RIC response time | < 100ms |
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.
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 to a port other than 36421; 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).
YANG model coverage
The sensor observes O1 management sessions and tracks YANG model interactions for:
- Hardware inventory (transceiver, fan, power supply state)
- Software management (version, package status)
- Configuration management (cell, beam, beamforming weights)
- Performance counters (TX power, RX noise, RIC latency)
O1 anomalies
| Anomaly | Meaning |
|---|---|
| Unexpected YANG model version change | Firmware upgrade without change notification |
| Configuration rollback | Potential attack or unauthorized management action |
| Hardware failure not reported to O1 | Monitoring bypass or sensor failure |
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 in the Console. Go to Compliance > O-RAN WG11.
Console views for O-RAN
O-RAN view
In the Console, go to Telco > 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 > 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 Activity > Runtime Events. Use the NF Role filter to select a role such as near_rt_ric and the time range selector to set the window. The filter accepts any declared or auto-detected role value.
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 Guardian Profiles 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.
Further reading
- O-RAN WG11 Compliance
- RAN Signaling (NGAP / F1AP / E2AP)
- SLO and Resource Monitoring
- Telecom Overview
- Guardian Profiles and Policies
- 5G Core (AMF / SMF / UPF)
- O-RAN Alliance - O-RAN Architecture Description
- O-RAN WG3 - E2 Application Protocol (E2AP)
- O-RAN WG10 - O1 Interface Specification
- O-RAN WG6 - O2 Interface Specification