Why the Future of 3GPP UE Certification is a Digital Testbench, Not a Physical Box
The industry is quietly shifting from shipped hardware testers to browser-accessed digital labs. Here is what that means for chipset, modem, and OEM teams shipping in 2026.
For twenty-five years, if you wanted to run a 3GPP conformance campaign against a UE, you bought a box. The box lived in a lab. Someone in your organization was paid to keep the box running, to argue with the vendor when the firmware regressed, to fight for chamber time when three teams needed it, and to explain to finance why a single line item on the capex plan was worth more than a small building. That was the deal. Everybody signed it because there was no other deal on offer.
There is another deal on offer now. It looks like this: no box, no rack, no shipping crate, no calibration ticket, no service contract. Instead, a URL, a login, a build upload, and a verdict. The tester still exists — the RF hardware, the shielded enclosures, the SDR boards, the ATS and the SS still live somewhere — but they live in our racks, not yours, and you reach them the same way you reach GitHub or Datadog: through a browser tab.
The core difference: we ship a digital box, not a physical tester
Every legacy vendor in this market — Anritsu, Keysight, Rohde & Schwarz, Spirent, VIAVI — sells a physical box. You buy it, you rack it, you power it, you maintain it, you rent floor space for it, you keep engineers around who know how to operate it, and every time 3GPP releases a new specification you either wait for a firmware update or you buy another box. That model made sense in 1998. It stopped making sense the moment SDR became stable, cloud became universal, and every serious engineering team started living inside a browser and a git repository.
AEON Cloud is not a physical tester. We do not ship you hardware. There is nothing to unbox, nothing to rack, no shipping crate, no calibration ticket, no service contract on a chassis. What we ship is a URL. Your team opens the AEON Cloud web application from any laptop in any office, uploads a UE build, and executes real 3GPP TTCN-3 conformance campaigns against real SDR-backed radio lanes that we operate on your behalf. The tester exists — the antennas, the shielded enclosures, the LimeSDR and Ettus B210 boards, the ATS and the SS — but it lives in our racks, and you reach it through the same browser tab you use for GitHub.
That single architectural choice changes everything downstream: procurement becomes a signup instead of a purchase order, capacity becomes elastic instead of fixed, upgrades happen server-side instead of on a truck, teams in three time zones share the same lane instead of fighting over one chamber, and CI systems can trigger conformance runs the same way they trigger a unit test. Nothing to install. Nothing to maintain. Just a browser and a build.
What actually changes when the tester becomes a service
The most obvious change is financial. A hardware tester is a capex line item; a digital testbench is an opex line item. But the financial change is downstream of a much bigger change: the tester stops being scarce. When the tester is a physical box in a lab, it is a rival good. Two engineers cannot use it at the same time. Ten engineers cannot use ten copies of it without ten purchase orders. When the tester is a URL, it is a shared good. Ten engineers can hit it in parallel from ten cities. A CI system can hit it from an unattended runner at 3 a.m. A regression suite that used to take a week because it was serialised on a single chamber can now take an hour because it fans out across ten lanes.
The second change is upgrade velocity. Every 3GPP release adds testcases; every SDR generation improves fidelity; every clarification note in a working group patches an ambiguity. When the tester is a box, all of that arrives in a firmware update that you either apply or postpone. When the tester is a service, all of that arrives silently. You log in Tuesday morning and the catalog has 40 new testcases. Nobody at your company had to do anything.
The third change is that the tester stops being an operational burden. Chambers require calibration cycles. RF cables loosen. Fans fail. Power supplies degrade. Firmware has to be pinned. When the tester is a service, the calibration, the cable checks, the fan swaps, the firmware pins, and the version matrix are somebody else's job. Your engineers get to spend their time on the thing you hired them for — designing and validating a modem — instead of on the thing you did not hire them for, which is running a radio lab.
The objections, honestly answered
The obvious objection is fidelity. Can a cloud-based SDR-backed tester really reproduce the timing, the RF conditions, and the determinism of a full-chamber ATS? The honest answer is: for the majority of protocol conformance under TS 38.523, yes, with margin to spare. For RF conformance under TS 38.521, partially — the parts that require an anechoic chamber and calibrated OTA antennas are the parts we route to shielded enclosures rather than open air, and the parts that require true environmental extremes we do not claim to cover. Any vendor who claims that an SDR replaces a full RF chamber for every part of TS 38.521 is not being honest with you; we are.
The second objection is data residency. If the tester is somebody else's cloud, does your UE firmware go through somebody else's network? The answer is: only into the region you pick, with an encrypted control plane, per-workspace key material, and a documented DPA. The build artifacts stay in the region you specify, the logs and PCAPs stay in the region you specify, and the audit log will tell you exactly which engineer pulled which artifact at which timestamp.
The third objection is lock-in. If the tester is a service, are we locked into your API forever? The API is a thin wrapper around 3GPP-standard concepts: builds, lanes, suites, executions, verdicts, reports. Your CI job that calls the AEON Cloud CLI to run a conformance campaign is not meaningfully different in shape from a CI job that calls a locally-hosted TTCN-3 runner. If you ever choose to leave, your test artifacts leave with you.
Who this is for, and who it is not for
It is for chipset vendors who want to run pre-silicon and post-silicon regressions without owning three chambers per region. It is for modem software teams who want CI-integrated conformance the same way web developers have CI-integrated end-to-end tests. It is for UE OEMs who want to ship a device in four countries without renting four labs. It is for certification consultancies who want to bill customers for verdicts rather than for chamber time.
It is not for teams whose entire test plan is TS 38.521-2 conducted OTA in an anechoic chamber. It is not for research groups whose work is inventing new PHY primitives that no SDR can yet emulate. And it is not for organisations whose procurement process cannot approve a SaaS subscription. We are not trying to be everybody's tester. We are trying to be the right tester for the majority of the industry that is spending most of its budget on the boring middle of the certification cost curve.
What the next five years look like
Every category eventually goes through this transition. Compute went from mainframes you owned to instances you rented. Storage went from arrays you racked to buckets you called an API against. Observability went from Nagios installations you maintained to Datadog dashboards you logged into. Test automation for web apps went from Selenium grids you ran to BrowserStack lanes you booked. There is no reason 3GPP conformance is going to be the one category that stays on-premises forever. It is going to move, and it is going to move for the same reasons every other category moved: elasticity, upgrade velocity, and the disappearance of the operational tax.
AEON Cloud is the shape that move takes for telecom. No box. No rack. No shipping crate. Just a browser, a build, and a verdict.
How to try this on AEON Cloud
If you want to see a full conformance campaign running against your own UE build without buying, renting, or shipping any hardware, the fastest path is to create a free workspace, upload a build artifact, and reserve a lane from the browser. The entire loop — from signup to first verdict — is designed to complete in an afternoon, not a quarter.
Because the tester is a service rather than a device, you never have to plan around a hardware refresh cycle. When 3GPP publishes a new release, the catalog updates server-side and every workspace sees it the next time they log in. When a new SDR generation lands in our lab, your existing campaigns benefit from the improved fidelity without a purchase order.
Further reading
The AEON Cloud documentation covers the CLI, the REST API, the TTCN-3 catalog, the AI Telecom Copilot, and the security model in depth. If you are evaluating for procurement, the pricing page includes a plan comparison matrix and a technical FAQ. If you are evaluating for engineering, the platform page documents the six pillars and the cloud-vs-chamber comparison.
