Platform
Diagnosis is what customers pay for. Normalization is what nobody else can copy quickly. Everything below sits on one vendor-neutral schema, built once and maintained as an asset.
Data inputs
We pull from the operator's existing PM collector, mediation layer or OSS export target — never from network elements. Three acquisition paths, all read-only.
| Category | What it is | Cadence | In v1 |
|---|---|---|---|
| PM counters | Performance measurement files, per cell / per relation / per beam | 15-min ROP | Yes — primary |
| CM configuration | Full or delta configuration dumps of the managed objects | Daily full, or on-change | Yes — primary |
| FM alarms | Fault management event stream and alarm history | Event-driven | Yes |
| Topology & inventory | Site, sector, cell, node identifiers, coordinates, bands | Weekly or on-change | Yes |
| Sync / timing | PTP and SyncE state, holdover events, fronthaul statistics | 15-min or event | Where available |
| Call traces | Per-call or per-UE trace records | Continuous, sampled | No — contains subscriber IDs |
From the operator's own file server. The most common path in Tier-2 and Tier-3 estates.
Read-only credentialA customer-owned S3 or Azure Blob bucket with a read-only policy scoped to the export directory.
Scoped bucket policyA web upload for a scoped investigation. Deliberately supported — it is how most engagements start.
No integration requiredA “3GPP-compliant” XML file from two vendors will validate against the same schema and mean different things — different counter semantics, different aggregation over the ROP, different treatment of counter reset on node restart. That gap is the business.
The normalization problem
Every measurement must resolve to a canonical cell identity — ECGI for LTE, NCGI for NR — and to a
stable internal cell_uid that survives renames. Vendor DNs encode identity positionally
and differently. Operators rename cells during site swaps and refarming. PCI is not an
identity — it is reused across the estate by design, and a PCI-keyed join produces silent, plausible,
wrong answers.
Some vendors timestamp a ROP by its start, some by its end. A one-period offset between two vendors makes every cross-vendor correlation wrong by fifteen minutes — enough to invert a causal story. Add timezone and DST inconsistency, counter resets on node restart, and suspect-flagged partial periods. We store UTC internally, always, and propagate every quality flag to the derived KPI.
“Handover success rate” is not one thing. Each vendor computes it from a different counter set, with different inclusion rules for intra-frequency, inter-frequency and inter-RAT cases, and different treatment of preparation versus execution failures. Two vendors reporting 98.2% may be measuring materially different events. KPI definitions are versioned configuration, not code — and they ship with the release so customers can read them.
Two rules that are never negotiated away
Every canonical KPI carries a comparability grade across vendors. Displaying a cross-vendor comparison without the grade is how you get an engineer to stop trusting the product permanently.
The definition library lives in version control and ships with the release. Customers can read it. Some will argue with it. That argument is a sales asset, not a support burden.
Canonical data model
We resist the urge to model the whole 3GPP information model. Every row carries
source_file and ingest_run_id — because the evidence pack has to trace any
number on screen back to the file it came from, or an operator's vendor will dismiss it.
| Entity | Grain | Key fields |
|---|---|---|
| cell | one row per cell per validity interval | cell_uid, ECGI/NCGI, vendor, rat, band, pci, site_uid, valid_from, valid_to |
| relation | one row per neighbour relation per interval | src_cell_uid, dst_cell_uid, type, dst_resolved, valid_from, valid_to |
| measurement | one row per cell or relation per ROP per KPI | cell_uid, ts_utc, kpi_id, value, denominator, quality_flag |
| config_item | one row per object per parameter per interval | object_uid, param, value, valid_from, valid_to, source_file |
| event | alarms, node restarts, upgrades, planned works | object_uid, ts_utc, type, severity, raw |
The evidence pack
When an engineer accepts a diagnosis, they need to forward it — to a colleague, a manager, or a vendor's support desk. The evidence pack is a self-contained export that circulates inside the customer's organisation without us in the room, and into the vendor relationship where it does work no dashboard can.
With every affected object named in the operator's own naming convention — not ours.
With the detection window and the statistical baseline band both marked.
The specific raw counters used, under their vendor-native names, so the vendor's own engineer can reproduce the result in their own tool.
The relevant configuration values, and the diff if a change is implicated.
Everything in the window that might bear on the finding, including planned works.
Source filenames, ROP timestamps, ingest run, the KPI definition version used, and the comparability grade on any cross-vendor number.
Formats — PDF to forward · HTML to link · JSON for the customer’s own tooling
Detection approach
The first release uses deterministic rules plus per-object statistical baselines — seasonal decomposition per cell, per KPI, with day-of-week and hour-of-day profiles. Not because machine learning would not help, but because of three things that are true at this stage.
There is no labelled fault corpus until the product has been deployed and outcomes recorded. Training on nothing produces confidence without accuracy.
An engineer will accept “this relation's failure rate is 4.1σ above its own eight-week profile, here are the counters.” They will not accept an unexplained anomaly score.
Every diagnosis must be reproducible and explainable to a vendor support desk. A model that cannot show its work generates no leverage in that conversation.
Machine learning enters in the second release, for ranking and cross-signal correlation, trained on the labelled outcomes the first release collects. That sequencing is the point.
Deployment & security
For vendor QA organisations, smaller operators and initial pilots. Runs against anonymised exports.
Time to first diagnosis · 5–15 daysInside the operator's own cloud account. The common choice for Tier-2 operators with cloud approval.
Time to first diagnosis · 3–6 weeksSame container images with an offline registry bundle, for regulated markets and air-gapped estates.
Time to first diagnosis · 6–12 weeksNo inbound connection to the network — all acquisition is outbound-initiated pull, or the customer pushes to us. No write path exists in the codebase. There is no credential in the system capable of changing a network parameter.
Least-privilege read credentials scoped to the export directory. Encryption in transit and at rest. Per-tenant key separation. A full audit log of access and export. SOC 2 on the roadmap ahead of the first Tier-2 operator deal.
Next step
A scoped investigation needs no integration and no network access — only a sample of the performance data you already produce.