From Git Push to Verdict: A Modern CI/CD Pipeline for UE Firmware

For web engineers, running an end-to-end test on every commit is unremarkable. For UE firmware engineers, running a conformance testcase on every commit has been, until recently, unimaginable. The reason was not lack of interest — it was lack of tester. When your tester is a physical chamber shared by three teams, you do not get to trigger it from a GitHub Action. When your tester is a URL, you do.

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.

The shape of a modern UE CI pipeline

A modern pipeline for UE firmware has four stages. Stage one is the build itself: cross-compile the modem stack, sign the artifact, and hash it for provenance. Stage two is unit and simulation tests: pure software validation of the pieces that do not require radio. Stage three is a smoke conformance sweep against a real UE image on a real SDR-backed lane — a handful of registration and PDU session testcases, gated on every commit to a protected branch. Stage four is the full nightly regression, run against a broader subset of TS 38.523, TS 36.523, and IMS testcases.

The change from the traditional model is stages three and four. Historically both were manual and both were slow. When the tester is a service reachable from a CLI, both become automatable and both become fast enough to fit inside a normal CI cadence.

Concretely, in GitHub Actions

A GitHub Action that pushes a build artifact to AEON Cloud, reserves a lane, runs a smoke suite, and blocks the merge on the verdict is a dozen lines of YAML plus a scoped API token. The action installs the AEON CLI, authenticates with a token stored in repository secrets, pushes the artifact tagged with the commit SHA, and calls the exec command with a named suite. The exit code of the CLI is the verdict, so the standard CI gating primitives just work.

The same pattern works in GitLab CI, Jenkins, Bitbucket Pipelines, CircleCI, and every other CI system that can run a shell command and read an exit code. There is nothing bespoke about the integration because there is nothing bespoke about the tester — it is a service you call from a shell.

What to gate and what not to gate

Do not gate every commit on the full TS 38.523 suite. It takes too long, it costs too much, and it is not the point of a smoke check. Gate every commit on a curated smoke — five to ten testcases that cover registration, security mode, one PDU session, and one mobility procedure. That is enough to catch the ninety percent of regressions that break something obvious. Reserve the full suite for the nightly build and for release candidates.

Do gate release candidates on the full suite. When a build is about to leave engineering for QA or for an operator submission, the delta between a smoke and a full run is exactly the delta between missing a certification-blocking bug and catching it. Cloud execution makes the full run cheap enough that it is no longer a debate.

Provenance and audit

Every execution on AEON Cloud carries the commit SHA, the CI job ID, the operator, the lane, the suite, and the artifact hash. That metadata is queryable from the API, so a build-provenance system on your side — Sigstore, in-toto, whatever your organisation uses — can attach the verdict to the artifact and follow it downstream. When an operator asks in twelve months whether firmware version 2.4.1 passed testcase 8.1.3.2, the answer is a query, not an archaeology dig.

How to try this on AEON Cloud

If you want to see your CI pipeline 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.