Appearance
Standard vs Telecom Flavor
Telovix ships two sensor flavors. The standard flavor covers Linux and Kubernetes runtime security. The telecom flavor builds on standard and adds protocol-aware monitoring for 5G Core and Open RAN workloads. Both use the same enrollment process, the same mTLS trust model, and the same heartbeat delivery path.
The flavor is embedded in the binary. You select it at install time, and it cannot be changed without reinstalling. Sensor identity (mTLS certificates, sensor ID, policy pack assignments) is preserved across a flavor change.
Choosing a flavor
| Scenario | Flavor |
|---|---|
| Standard Linux servers, VMs, edge nodes | standard |
| Kubernetes worker nodes (no 5G workloads) | standard |
| Kubernetes nodes running 5G Core NFs (AMF, SMF, UPF) | telecom |
| O-RAN nodes (O-DU, O-CU-CP, O-CU-UP, gNB) | telecom |
| Near-RT RIC | telecom |
| Mixed node where you are unsure | telecom with observe-only pack |
The telecom flavor adds collection overhead proportional to the protocol traffic it observes. On nodes with no telecom protocol traffic, the overhead above the standard baseline is negligible (the protocol parsers are epoll-driven and do not poll). On active 5G Core nodes the reported overhead in the Helm chart values is less than 0.2 cores CPU and under 120 MB RSS at peak GTP-U throughput.
Capability comparison
Core eBPF collection (both flavors)
| Capability | Standard | Telecom |
|---|---|---|
Process execution (kprobe sys_execve) | Yes | Yes |
| Process fork and exit | Yes | Yes |
File open and write (kprobe openat, sys_write) | Yes | Yes |
Privilege change (sys_setuid, sys_setgid) | Yes | Yes |
Namespace creation (sys_clone with CLONE_NEW*) | Yes | Yes |
Kernel module load (sys_init_module) | Yes | Yes |
| ptrace attach | Yes | Yes |
| Network connections (TCP outbound, inbound, listen) | Yes | Yes |
| DNS queries and resolution correlation | Yes | Yes |
| TCP flow tracking (duration, state, bytes) | Yes | Yes |
| BPF map access detection | Yes | Yes |
| File Integrity Monitoring (SHA-256 baseline) | Yes | Yes |
| Process ancestor chain enrichment | Yes | Yes |
| Kubernetes workload context (pod, namespace, workload) | Yes | Yes |
| SBOM scanning via Trivy (container images) | Yes | Yes |
| Behavioral anomaly scoring (per-binary baselines) | Yes | Yes |
| Kernel guard monitoring | Yes | Yes |
Telecom-specific collection (telecom flavor only)
| Capability | Protocols / Standards | Notes |
|---|---|---|
| NF role detection (24 roles) | 5G SA, EPC, O-RAN | Port binding, process name, binary path, gRPC port heuristics with confidence scoring |
| NGAP parsing and KPI tracking | 3GPP TS 38.413, port 38412 SCTP | InitialContextSetup failures, UEContextRelease, handover anomalies, NGSetup failures |
| PFCP session tracking | 3GPP TS 29.244, port 8805 UDP | Session creation latency, session churn, SEID collision, dropped packets |
| GTP-U tunnel monitoring | 3GPP TS 29.281, port 2152 UDP | TEID reuse, invalid TEID, encapsulation loop, payload size anomaly |
| F1AP monitoring | 3GPP TS 38.473, port 38472 SCTP | DU registration, RRC context setup, setup failures |
| E1AP monitoring | 3GPP TS 38.463, port 38462 SCTP | CU-UP registration, bearer setup latency |
| XnAP monitoring | 3GPP TS 38.423, SCTP | Inter-gNB handover, neighbor registration |
| E2AP monitoring | O-RAN WG3, port 36421 SCTP | RIC subscription, indication, control actions |
| O1 interface monitoring | O-RAN Alliance, Netconf/SSH port 830 | YANG model version changes, config rollback detection |
| O2 interface monitoring | O-RAN Alliance, REST/OpenAPI | Resource exhaustion, orphaned containers |
| xApp monitoring | O-RAN WG3 | Rogue RIC peer detection, non-standard E2 port |
| SCTP association tracking | RFC 9260 | Association churn, chunk loss rate, RTT, abort reason codes |
| Diameter peer monitoring | RFC 6733, 3GPP TS 29.230, port 3868 | CER failure, auth success rate, accounting data loss |
| RADIUS monitoring | RFC 2865/2866, ports 1812/1813 UDP | Access-reject rate spikes, accounting data loss |
| SIP session monitoring | RFC 3261, port 5060 UDP/TCP | Invitation rejection rate, session count anomaly |
| SBI / HTTP2 monitoring | 3GPP TS 29.501, port 7777 / 29500-29599 | NF-to-NF API calls, unexpected service call matrix |
| NAS 5G decoding | 3GPP TS 24.501 | Registration rejection, auth failures, PDU session failures |
| M3UA / SS7 | RFC 4666 | (Collected for legacy 4G/IMS contexts) |
| IKEv2 | RFC 7296 | IPsec tunnel setup monitoring |
| TLS uprobe (OpenSSL, GnuTLS, Go TLS, BoringSSL) | 3GPP TS 29.501 mTLS requirements | SBI plaintext detection, TLS posture per NF |
| NF SLO monitoring | 3GPP TS 22.261 | Per-role availability targets (5-nines for AMF/UPF/SMF) |
| NF privilege escalation detection | Unexpected setuid to root or cross-NF boundary | |
| Rogue process detection | NF spawning unexpected child binaries | |
| Configuration drift detection | NF config file changes outside maintenance windows | |
| Timing analysis | NF response latency distribution per interface | |
| Visibility gap detection | AF_XDP, VFIO, DPDK bypass detection on GTP-U port | |
| Telecom anomaly scoring | Protocol violations, SLO breaches, integrity issues combined into risk score (0-100) |
Console UI differences
The Telovix Console vertical (selected during initial setup) must match the sensor flavor in use. A standard Console with telecom sensors will store telecom heartbeat data in the database but will not surface it in the UI.
| Console section | standard vertical | telecom vertical |
|---|---|---|
| Telco navigation section | Hidden | Visible |
| 5G Core NF inventory view | Not shown | Active |
| NGAP KPI charts | Not shown | Active |
| O-RAN interface status | Not shown | Active |
| SLO dashboard | Not shown | Active |
| Protocol analytics (PFCP, GTP-U, SCTP) | Not shown | Active |
| Telecom compliance frameworks (3GPP TS 33.117, O-RAN WG11) | Not shown | Available in reports |
| AI assistant telecom tools | Not available | All 44 tools including get_telco_nf_inventory, get_ngap_kpis, get_oran_status, get_slo_metrics |
NF role detection
The telecom sensor auto-detects the network function role of running processes from:
- Port binding patterns (PFCP port 8805 - SMF or UPF; NGAP port 38412 - gNB or AMF; GTP-U port 2152 - UPF or gNB)
- Process name heuristics (
smf,upf,amf,nrf, etc.) - Binary path patterns (
/opt/open5gs/,/usr/local/open5gc/, etc.) - gRPC service port detection (port 7777 and 29500-29599 for SBI)
Auto-detection uses a confidence score combining all signals. The Console can promote a generic_linux declared role to telecom_core or telecom_ran based on detected evidence, but it never downgrades an already-set telecom role.
Roles detected:
| Category | Roles |
|---|---|
| 5G Core | AMF, SMF, UPF, NRF, UDM, UDR, PCF, AUSF, NEF, CHF, BSF, NSSF, NWDAF, SMSF, SEPP, LMF, GMLC, AF |
| 4G/EPC | MME, SGW, PGW, HSS, PCRF |
| RAN | gNB (variants), eNB, E2Node, Near-RT RIC, xApp |
| Infrastructure | OAM endpoint, PTP/SyncE node, Diameter node, RADIUS server, IMS node, SIGTRAN gateway |
SLO targets by role (telecom flavor)
The telecom sensor monitors NF process uptime and reports availability against 3GPP TS 22.261 targets:
| Target | Roles |
|---|---|
| 99.999% (5-nines) | AMF, UPF, SMF, MME, SGW, PGW |
| 99.99% (4-nines) | NRF, AUSF, UDM, UDR, HSS |
| 99.9% (3-nines) | PCF, CHF, BSF, NSSF, NEF, gNB variants, Near-RT RIC |
| 99.0% (2-nines) | All other roles |
A breach alert fires after a minimum 300-second observation window and is suppressed for 1 hour to avoid alert storms during recovery.
Visibility gaps
If a GTP-U user plane is handled by a kernel-bypass mechanism (AF_XDP, VFIO, or DPDK), eBPF cannot observe packet contents inside the tunnel. The telecom sensor detects these conditions by checking /proc/{pid}/maps, /sys/bus/pci, and /proc/meminfo for evidence of bypass frameworks, then sets gtp_visibility_gap=true in the heartbeat. The Console surfaces this as a warning: "User plane traffic not visible to monitoring."
This limitation applies only to GTP-U inner payload inspection. All control-plane signaling (NGAP, PFCP, SBI, F1AP, E1AP) remains fully visible through eBPF regardless of the user-plane data path.
Installing with the correct flavor
The Deploy Sensor wizard generates the correct install command with the flavor, node role, node name, and enrollment token already embedded. Select the flavor in the wizard and copy the generated command to run on the target node.
For Kubernetes, set flavor: telecom in the Helm values file. This deploys the registry.gitlab.com/telovix/sensor:<version>-telecom image tag instead of <version>.