SLO and Resource Monitoring
The telecom sensor tracks NF availability, recovery time, and resource consumption alongside runtime security events. This gives operators a single view that combines protocol health, process behavior, and operational metrics for every monitored network function.
Requires: Telecom sensor flavor.
SLO targets
SLO targets are based on 3GPP TS 22.261 availability requirements. The sensor assigns a target to each NF role automatically at role classification time.
| Tier | Target | Roles |
|---|---|---|
| 5-nines | 99.999% | AMF, UPF, SMF, MME, SGW, PGW |
| 4-nines | 99.99% | NRF, AUSF, UDM, UDR, HSS |
| 3-nines | 99.9% | PCF, CHF, BSF, NSSF, NEF, gNB variants, Near-RT RIC |
| 2-nines | 99.0% | All other roles (DiameterNode, RadiusServer, ImsNode, SigtranGateway, TelecomProcess, etc.) |
For a 5-nines target, the allowed downtime per year is approximately 5 minutes 15 seconds. Breach detection is designed to catch sustained outages, not transient restarts; the minimum observation window of 300 seconds ensures the sensor has enough data before firing.
Availability calculation
The Sensor computes availability for each role and Sensor as:
availability_pct = total_uptime_secs / total_observation_secs * 100.0- Observation time: elapsed time since the NF was first observed or the Sensor enrolled, whichever is shorter
- Uptime: time during the observation window when the NF process was in a stable running state
The calculation starts after the NF completes its learning window. Downtime begins when the observed NF process stops and ends when the same role returns to a stable running state.
Breach detection
Breach detection activates after the NF has been observed for at least 300 seconds (5 minutes). Before this threshold, availability data is collected but no breach alert fires.
When availability falls below the role's target, Telovix records a breach and raises an alert with the role, observed availability, and target. Repeat alerts are suppressed during a sustained outage. When availability recovers, Telovix records the recovery and raises a recovery alert.
MTTR tracking
Mean Time To Repair is the average delay between an NF process exit and the next successful start of the same role on the same sensor.
- The Sensor maintains a bounded window of recent recovery samples per role.
- Each sample measures the interval from an observed stop to the next stable start of the same role.
- When MTTR exceeds an expected recovery time, an alert fires.
Interface latency and timing
The sensor tracks NF response latency per interface using the timing analysis module. Latency is measured as the elapsed time between a request and its response on each protocol interface.
Interfaces tracked: N4 (PFCP), SBI (HTTP/2), N2 (NGAP), F1 (F1AP), E1 (E1AP), Xn (XnAP)
Statistics reported per interface: mean, p50, p95, p99
The SLO workspace presents observed latency distributions and interface status when request and response evidence can be paired.
Timing anomalies
| Anomaly | Meaning |
|---|---|
| Sudden latency spike | Potential DDoS or internal resource contention |
| Latency asymmetry (request fast, response slow) | Uplink/downlink imbalance on the interface |
| Per-UE latency variance | Per-bearer QoS misconfiguration or targeted session attack |
Interface SLA reference
| Interface | Protocol | Latency SLA |
|---|---|---|
| N4 | PFCP (SMF to UPF) | Session create < 100ms |
| E2 | E2AP (RAN to Near-RT RIC) | RIC response < 100ms |
| SBI | HTTP/2 | Request < 500ms |
NF resource metrics
Telovix records bounded per-role resource history for observed network functions.
Metrics reported per NF role:
| Metric | Field |
|---|---|
| CPU usage (%) | Per NF role process |
| Memory (RSS, bytes) | Per NF role process |
| Network interface throughput | Per telecom interface (N3, N4) |
| Power estimate (watts) | Per NF role, hourly aggregated |
Resource history enables:
- Comparing resource consumption before and after a runtime policy change
- Identifying resource spikes that correlate with security events
- Comparing the same NF role across different sites or clusters
Energy metrics
Telovix reports an estimated energy profile for each observed NF role. The estimate is shown separately from hardware-measured power so operators can interpret it correctly.
Energy metrics are most useful in multi-site deployments where operators are comparing cost and load across locations or between different RAN component types (O-DU versus CU-CP, for example).
Console views for SLO and resource monitoring
SLO dashboard
In the Console, go to Telco > Assurance > Service Levels. The dashboard shows per-NF SLO targets, current observed availability percentages, MTTR values, restart counts, and current breach status across the fleet. Use the sensor and role filters to narrow the view.
AI assistant SLO tool
Ask the AI assistant: "Show SLO status for all UPF nodes."
The assistant summarizes availability, MTTR, and breach state for the requested roles and Sensors.
Telecom overview
In the Console, go to Telco > Network > Overview. This page includes SLO status as part of the full telecom fleet overview alongside NF inventory, protocol KPIs, and risk summary.
Sensor tuning for resource-constrained nodes
On nodes with limited memory or high event rates, the eBPF ring buffer size, local spool cap, and SBOM scanning are configurable in Console Settings under the sensor configuration for that node.
Reduce the ring buffer size on nodes where kernel memory is limited. If events are being dropped due to ring buffer overflow, the sensor logs a warning and increments an overflow counter visible in the heartbeat. Reducing the spool cap limits disk usage on nodes with small local storage but increases the risk of event loss during Console outages longer than the spool capacity allows. SBOM scanning can be disabled individually for resource-constrained nodes in Console Settings.
Operational guidance
First-heartbeat SLO: SLO monitoring does not produce meaningful data until the NF has been observed for at least 300 seconds. During initial enrollment or after a sensor restart, SLO availability will show a short observation window. Do not treat a low availability percentage in the first five minutes as a breach indicator.
Role accuracy matters: SLO targets are tied to role classification. A UPF misclassified as generic_linux does not receive a 5-nines SLO target. Declare the node role explicitly during enrollment to ensure correct tier assignment from the first heartbeat.
MTTR window: MTTR is computed from the last 10 recovery samples. A single very long restart skews the MTTR average until 10 subsequent recoveries replace it. On nodes with infrequent restarts, the MTTR window may cover months of history.
Breach suppression and maintenance: The 3,600-second re-alert suppression prevents storm conditions during sustained outages. During planned maintenance (rolling restarts, upgrades), availability will drop below the SLO target and fire a breach alert at the start of the window. The suppression prevents repeated alerts during the maintenance period. The SLO_RECOVERED alert confirms when availability returns above target.
Correlating resource spikes with security events: The nf_resource_report and runtime event stream share the same sensor timestamps. When investigating an anomaly or attack chain, pull both the security events and the resource report for the same time window to determine whether the suspicious behavior coincides with a CPU or memory spike.