Telecom technology & networks
Operators run mixed Ericsson, Nokia, Samsung and Open RAN estates — and have no common way to read them. Tosso ingests the performance data they already export, normalizes it into one model, and tells their engineers what is actually broken.
The problem
Vendor diversification succeeded at procurement and failed at operations. The faults that matter most are precisely the ones that cross a vendor boundary — and those are the faults no vendor's own toolchain will ever show you.
Ericsson, Nokia, Samsung and O-RAN elements each emit counters under different names, at different granularities, on different time bases, keyed to different object identifiers. The same dropped call appears four different ways.
Each vendor's element manager sees only its own footprint. That is not an oversight — it is the commercial model. Building a good cross-vendor view would make a competitor's equipment look fine in their customer's dashboard.
Handover failures at the seam, fronthaul timing drift, uplink interference between estates, PCI collisions that survive because neither planning tool sees both sides. The interesting faults live exactly where no one is looking.
Export to CSV, pivot in a spreadsheet, reconcile timestamps, then argue with two vendors' support desks holding incompatible evidence. Weeks of senior engineering time per incident.
The approach
Every product that writes to a live network inherits a change-management board, a security review of write access, lab certification and a carrier-grade on-call obligation. We took the other path deliberately. Tosso reads exports the operator already produces — and never touches a parameter.
Security review of write access to a live network. Change-board sign-off per release. 24/7 carrier-grade SLA from day one. Lab certification before any production traffic. An 18–36 month procurement cycle against a CTO capex line.
The path we did not takeA data-handling review only — there is no write path to audit. No change control, because nothing in the network changes. Business-hours support is acceptable at entry. Deployment against exported files, in weeks rather than quarters.
Architectural, not a limitationNon-negotiable boundaries
No E2, no near-real-time RIC integration, no direct element access. All acquisition is outbound-initiated pull from the operator's own export target, or the operator pushes to us.
There is no write path anywhere in the codebase and no credential in the system capable of changing a network parameter. Closed-loop optimization is permanently out of scope.
Performance counters are aggregate and contain no subscriber data. Call trace records do — so the first release does not ingest them. When they are added, they are pseudonymized at the customer boundary before transfer.
No radio units, no baseband, no probes, no taps. Nothing we ship sits between the network and its traffic.
What we do
Each line is a different way of selling the same underlying understanding of how mixed radio estates actually behave — and each one feeds the others.
Open RAN architecture and engineering: disaggregated RU/DU/CU behaviour, Open Fronthaul over eCPRI at Split 7.2x, the O1 management surface, interoperability methodology, and the normalization work that makes multi-vendor data comparable in the first place.
O-RAN architecture · interoperability · normalizationSpecification, configuration, verification and supply of radio access and adjacent network equipment — staged, firmware-loaded and interoperability-tested at our own facility before anything ships to site.
specification · pre-ship configuration · supplyRead-only ingest of performance and configuration data, normalization into a single canonical model, cross-vendor fault localization, and independent verification of any change an operator or supplier makes.
normalize · diagnose · proveThe equipment line puts us in front of the customer and in physical contact with the hardware. The platform gives that same customer something no single equipment vendor is able to provide — because no vendor sees the other side of the seam.
How it works
Five stages, one direction of travel. Every number the platform puts on screen can be traced back to the source file it came from.
SFTP pull, customer-owned object storage, or a scoped manual upload. Read-only credentials, always.
Per vendor, per format, per software release. Versioned parsers — this is the connector library.
Identity resolution, time alignment, KPI semantics. The part nobody else can copy quickly.
Deterministic rules plus per-object statistical baselines. Ranked objects, not anomaly scores.
A self-contained pack an engineer can forward to a vendor support desk without us in the room.
What the platform finds
A diagnosis is not a dashboard. Each takes defined inputs, runs deterministic detection against a statistical baseline, and emits a ranked list of named objects with the evidence attached.
| Ref | Diagnosis | What it returns |
|---|---|---|
| D1 | Cross-vendor handover failure | Ranked relations crossing a vendor boundary with failure rates materially above the estate baseline, split by preparation versus execution failure, with the far-end cell resolved and named. |
| D2 | Neighbour relation inconsistency | Missing relations, asymmetric relations, relations pointing at cells that no longer exist, and blacklisted relations still carrying traffic. Configuration only — so it produces findings on day one. |
| D3 | PCI collision & confusion | Collisions and confusions ranked by traffic exposure. These survive longest at cross-vendor borders, because neither vendor's planning tool sees both sides. |
| D4 | Sleeping cell detection | Cells reporting healthy in fault management while traffic has collapsed against both their own baseline and their neighbours' — a persistent, largely silent source of lost revenue. |
| D5 | Post-change regression | For a given change window, the KPIs and cells that moved beyond their pre-change confidence band, with the configuration diff attached. |
| D6 | Accessibility decomposition | For a degraded accessibility KPI, which stage of the setup chain is failing, and whether it tracks load, coverage, or a specific parameter value. |
Every cross-vendor number carries a comparability grade — exact, directional, or not comparable. Displaying a cross-vendor comparison without that grade is how you get an engineer to stop trusting a product permanently.
Why now
Fewer suppliers, not fewer vendors. Operators are left holding the mixed estates they already built — and with less vendor support available to untangle them. The diagnostic gap became structural rather than temporary.
Open RAN specification work has entered a consolidation phase. Slowing churn removes the differentiation story for challenger equipment makers — and simultaneously makes a stable, long-lived normalization schema possible to build and maintain with a small team.
Every AI-driven RAN claim an operator buys now needs independent, vendor-neutral before-and-after measurement. The supplier making the claim cannot credibly be the party measuring it.
Start with one question
Most engagements begin as a scoped investigation against a single fault or degradation, run on performance data you already have. No integration, no network access, no procurement cycle.