TTCN-3 in the Cloud: Running ETSI Test Suites Without Owning a Tester

TTCN-3 is one of the most successful standards nobody outside telecom has heard of. It is the language that ETSI, ITU-T, and 3GPP use to write conformance testcases in a portable, tool-agnostic form. Every serious modem vendor on Earth runs TTCN-3 suites at some point in their certification pipeline. Historically, running those suites meant buying a tester that could execute them. That is no longer the only option.

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 TTCN-3 actually is, briefly

TTCN-3 is a strongly-typed, event-driven testing language. A testcase describes a sequence of expected messages, timers, and verdicts against one or more system-under-test components. The language separates the abstract testcase from the concrete adaptation layer that talks to the actual UE and RF hardware. That separation is why the same TS 38.523 testcase can run on Anritsu, Keysight, R&S, or AEON Cloud without being rewritten — the abstract layer is portable, the adaptation is not.

The value of that separation is that the choice of runtime becomes an economic choice, not a technical one. If a cloud runtime can execute the same abstract testcase against the same UE with the same fidelity, the only remaining question is which runtime is cheaper, faster, and easier for your team to consume.

What runs well on a cloud TTCN-3 runtime

The majority of TS 38.523 (NR protocol conformance), TS 36.523 (LTE protocol conformance), and their IMS/VoNR extensions run cleanly on an SDR-backed cloud runtime, because they are dominated by signalling exchanges over a well-defined air interface where the SDR is entirely capable of emulating the network side. Registration, authentication, PDU session establishment, handover, paging, tracking area update, service request — the parts of the test plan that make up the bulk of a certification campaign — are excellent fits for cloud execution.

TS 38.533 RRM testcases are a partial fit. The ones that can be executed under controlled fading with a shielded enclosure run cleanly; the ones that require full anechoic conditions or specific antenna array configurations sit at the edge of what SDR can guarantee, and any vendor telling you otherwise is overselling. TS 38.521 RF conformance is the same story: the parts that require calibrated OTA antennas belong in a chamber; the parts that are conducted and dominated by signal-quality checks run fine on SDR.

The developer experience change

The reason to move TTCN-3 execution into the cloud is not just cost — it is that the developer loop becomes almost unrecognisably better. Instead of asking the lab team to schedule a chamber, uploading a build over a shared drive, and waiting for a technician to email you the log bundle, an engineer types six lines into a terminal and gets a verdict streamed back to their browser in real time. The loop from git push to verdict shrinks from days to minutes.

That change compounds. When the loop is fast, engineers run conformance more often. When they run it more often, regressions are caught closer to the commit that introduced them. When regressions are caught closer to the commit, they are cheaper to fix, because the person who wrote the code still remembers what they were doing. This is exactly the same argument that killed batch testing in web development twenty years ago; telecom is just a decade late to hearing it.

Portability and provenance

One of the underappreciated properties of TTCN-3 is that a run is fully reproducible from the testcase source, the adaptation layer version, the UE build, and the RF configuration. On AEON Cloud, every execution ships with a signed manifest that captures all of those inputs, so any verdict — pass, fail, or inconclusive — can be re-run months later against the same inputs and be expected to produce the same result. That property matters for certification submissions, for audit, and for the moment when a regulator asks you to prove that verdict number 4821 from last October was not a fluke.

Portability also means exit is cheap. Because the abstract testcases are the ones you care about and they are portable across runtimes, no team is locked in. If you ever want to migrate a subset of your suite back to a physical tester, the abstract testcase moves with you.

How to try this on AEON Cloud

If you want to see a TS 38.523 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.