Engineering

Open architectures don’t fail at the specification.

They fail at integration — which is where we work. The specifications exist. The hard part is that a disaggregated network has to be integrated, tested, certified and then operated across suppliers who have never had to interoperate, and kept working as each of them ships software on its own schedule.

01 / O-RAN

O-RAN engineering

Where the engineering effort goes.

01

Disaggregation & interfaces

RU / DU / CU split behaviour, Open Fronthaul over eCPRI at Split 7.2x, and the O1 management surface. We read these interfaces; we never write to them.

RU/DU/CU · Open Fronthaul · O1
02

Interoperability methodology

Test cases, reference configurations and integration playbooks for multi-vendor combinations. This is the work that decides whether an open estate can actually be operated at all.

Test design · reference configs · playbooks
03

SMO & RIC context

How management and orchestration layers consume normalized data, and what a diagnostic layer has to expose to be useful to them rather than duplicative of them.

SMO · Non-RT RIC · policy surfaces
04

Timing & synchronisation

PTP (IEEE 1588) lock, holdover and offset behaviour at the fronthaul, and its correlation with throughput degradation — one of the least-served areas in a mixed estate.

IEEE 1588 · SyncE · holdover analysis
02 / EQUIPMENT

Equipment

Specification through dispatch, in one building.

Radio access and adjacent network equipment, specified against published interface definitions rather than one vendor's implementation — then built, configured, verified and shipped by the same technical team that wrote the spec.

Step 01

Specify

Requirement definition and technical specification written against 3GPP and O-RAN interface definitions.

Step 02

Build

Assembly, firmware loading and parameter configuration using our own reference configurations.

Step 03

Verify

Functional and interoperability verification before shipment, against the configuration it is sold into.

Step 04

Stage

Kitting, labelling and documentation, so what arrives on site is ready to install, not ready to debug.

Step 05

Dispatch

Receipt, staging, dock handling and outbound distribution — capability the company already operates.

Radio access equipment

Radio units and adjacent access hardware, specified for the band plan, split architecture and fronthaul budget of the deployment it is going into.

Transport & fronthaul

Fronthaul and backhaul elements, timing distribution and the sync chain that a Split 7.2x deployment lives or dies on.

Edge & compute

Server and edge platforms for DU/CU hosting and O-Cloud footprints, sized against the workload rather than a catalogue.

03 / ADVISORY

Advisory

How customers engage us.

01

Scoped investigation

A defined engagement against one specific fault or degradation, run on exported performance data. No integration, no network access. This is how most customer relationships begin.

02

Integration support

Remote and on-site support bringing multi-vendor equipment into service, working from reference configurations we maintain rather than improvising per site.

03

Change verification

Independent before-and-after measurement of a software upgrade, a parameter campaign, or a supplier's performance claim. The party making the claim cannot credibly be the party measuring it.

04

Architecture & roadmap

Technology-roadmap work for operators and equipment suppliers moving toward open, disaggregated networks — including where not to disaggregate.

05

Platform subscription

Continuous access to the diagnostics platform, priced on cells under management rather than on seats.

04 / MARKETS

Who we work with

Estates that are mixed, and teams that are small.

Tier-2 & Tier-3 operators

Multi-vendor estates with small internal tooling teams — the primary market for equipment supply and diagnostics alike.

Neutral hosts & private networks

Enterprise, campus and venue deployments, where equipment supply and integration support are typically bought together.

Equipment vendors

QA and integration organisations that need vendor-neutral verification before a release reaches the field.

System integrators

Delivery partners on multi-vendor builds who need reference configurations and interoperability evidence they did not have to generate themselves.

05 / POSTURE

Standards, data handling and neutrality

Commitments that are architectural, not editorial.

These are not policies that can be relaxed for a single customer. They are properties of how the systems are built.

01

Standards alignment

Engineering work follows 3GPP and O-RAN ALLIANCE specifications. Reference configurations are stated against published interface definitions rather than one vendor's implementation, so a customer can check our work against the standard rather than against our word.

02

Data handling

Read-only access to data the operator already exports. No inbound connection to the network, no write path anywhere in the codebase, and no subscriber identifiers ingested in the current release.

03

Security posture

Least-privilege read credentials scoped to the export directory, encryption in transit and at rest, per-customer separation, and a full audit log of access and export.

04

Neutrality

We do not act as a channel for the RAN vendors whose equipment our reports assess. That independence is precisely what makes a verification report usable in a supplier conversation.

Engineering engagement

Tell us what broke. We’ll tell you where.

Scoped investigations start from exported data and finish with an evidence pack you can take to your supplier.