A Deep Dive into 3GPP TS 38.523: NR Protocol Conformance in the Browser

TS 38.523 is the specification that defines the protocol conformance suite for 5G NR UEs. It is the counterpart of TS 36.523 for LTE and, together with TS 38.521 and TS 38.533, it is one of the three pillars every certification programme has to satisfy. If your device is going to interoperate with a network operator's core, TS 38.523 is the specification that decides whether it does.

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.

How the specification is organised

TS 38.523 is split across three documents. Part 1 defines the common test environment. Part 2 defines the abstract testcases. Part 3 is the TTCN-3 realisation of those testcases. When engineers say ‘we are running 523’ they almost always mean Part 3, because that is the executable artifact. Part 3 is not one file; it is a family of TTCN-3 modules covering NAS, RRC, session management, mobility, and the interactions between them.

The testcases are grouped by procedure family. Registration, authentication, security mode control, PDU session establishment, handover, service request, tracking area update, paging, and the many combinations thereof each occupy their own chapter. In practice, a certification campaign is a curated subset of these testcases — the ones an operator requires for their acceptance programme, or the ones a regulator requires for market entry.

Executing a testcase end to end

A single TS 38.523 execution on AEON Cloud looks like this from a developer's perspective: pick a testcase from the catalog, select a UE build from the repository, choose a lane, hit Run. From the platform's perspective the sequence is more interesting. The scheduler assigns a lane, the SDR is brought up to the RF configuration the testcase requires, the TTCN-3 runtime loads the module, the UE build is powered up and enters the lane, and the runtime begins driving the messages the testcase specifies. Every RRC, NAS, and SM message is captured. Every timer is logged. Every unexpected message is flagged.

The verdict at the end is one of three values: PASS, FAIL, or INCONCLUSIVE. PASS means the UE followed the specified procedure. FAIL means the UE deviated in a way that violates the specification. INCONCLUSIVE means the environment did not give the testcase enough information to decide — usually because a preamble step did not complete. On AEON Cloud every verdict ships with the full log bundle, the MSC, the PCAP, and the exact testcase and adaptation-layer version, so the verdict is auditable, not just readable.

The parts that trip most teams up

The largest single source of FAIL verdicts in TS 38.523 is not a bug in the UE code — it is a mismatch between the UE capability signalling and the testcase preconditions. If the UE advertises a capability it does not fully support, or does not advertise a capability it does support, dozens of downstream testcases will FAIL for reasons that look mysterious. The second largest source is timer handling: NAS and RRC timers that expire slightly early or slightly late will cause procedures to abort in ways the testcase records as noncompliant.

The reason the browser-based loop matters here is that both of these classes of bug are fastest to fix when the engineer sees the failure minutes after the commit that introduced it, not days. When you can run TS 38.523 subsets from a laptop against a real SDR-backed lane in the time it takes to grab a coffee, the fix cycle for capability and timer bugs collapses.

How to try this on AEON Cloud

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