A gNB bringing up a cell does not prove standards compliance. A successful UE attachment does not prove that the CU-CP selected the correct security algorithms, that the user plane used the signalled TEIDs and QFIs, or that the DU can recover when its CU restarts. Those questions can only be answered by examining what the implementation actually does.
CNTC RAN Certification brings that evidence-based approach to the 5G NG-RAN. It certifies a gNB in CU/DU split mode across N2, F1-C, E1, F1-U, N3 and the air interface. The complete environment runs on a single Linux host, using a software UE over a virtual radio instead of a conventional radio lab.
The first validated implementation is the OCUDU split gNB, peered with free5GC and driven by an OpenAirInterface UE. All 58 Level-1 requirements execute. The O-DU certified with all 7 essential requirements passing. The two CU product classes did not certify, because the evidence showed a specific security-policy failure: confidentiality was signalled as required, but the selected cipher was NEA0.
That result captures the purpose of CNTC. Certification is not confirmation that a system starts. It is an independent judgement based on what the system demonstrably does.
The remaining certification gap
CNTC already covers two major parts of a 5G system. UPF Certification exercises a User Plane Function over N3 and N4 and grades the observed behaviour. Control Plane Certification evaluates core network functions across NAS, NGAP, PFCP and the Service-Based Interface.
The RAN was the remaining gap, and the most difficult one to close, because RAN testing is commonly associated with spectrum, RF equipment and a dedicated radio lab.
A split gNB creates another path. Its behaviour can be observed across the standard interfaces connecting the CU control plane, CU user plane, DU, 5G Core and UE. CNTC RAN Certification turns those observations into reproducible, per-product-class verdicts.
A split gNB is not one product
3GPP TS 33.523 does not treat a split NG-RAN node as a single box. It separates the gNB into three product classes. In a disaggregated deployment these classes may come from different suppliers, and must therefore be evaluated independently.
| Product class | 3GPP name | Interfaces | Level-1 requirements |
|---|---|---|---|
| O-CU-CP | gNB-CU-CP | N2, F1-C, E1 and RRC | 30, including 16 essential |
| O-CU-UP | gNB-CU-UP | E1, F1-U and N3 | 14, including 7 essential |
| O-DU | gNB-DU | F1-C, F1-U and the cell | 14, including 7 essential |
| Total | 58, including 30 essential | ||
CNTC certifies each class separately. One class can certify while another does not. This is exactly what happened during validation against OCUDU: the O-DU certified, while the O-CU-CP and O-CU-UP did not.
A single verdict for the complete gNB would have hidden that distinction, and reduced the value of the result for operators, vendors and integrators.
Observing radio behaviour through F1
RRC conformance and Access Stratum security appear to require direct radio instrumentation. In a CU/DU split, the necessary evidence is already carried across F1.
Every RRC message crosses the F1 interface inside an F1AP container, as defined in 3GPP TS 38.473, Section 8.4. DLRRCMessageTransfer and ULRRCMessageTransfer carry the RRC PDU as an octet string that can be decoded from a packet capture.
This makes the critical procedures observable on an ordinary IP link, including RRC setup, the Access Stratum Security Mode Command, algorithm selection, and the RRC reconfiguration that establishes the data radio bearer.
The radio side still requires a UE capable of completing the attachment procedure. CNTC uses a software UE over a virtual radio for that purpose.
The result is not a simulated protocol-only test. One UE attaches through the complete split RAN, registers with the 5G Core, establishes a PDU session and reaches the data network through its tunnel.
One controlled run, focused evidence
CNTC separates measurement from judgement. The RAN engine records what happened, while the grading layer evaluates those observations against a versioned requirements catalogue.
A campaign follows one controlled sequence: acquire the test-rig lock so only one campaign runs on the rig; confirm the AMF is reachable and subscriber data can be served; start the O-CU-CP and wait for the F1-C listener; start the O-CU-UP and wait for the E1 association; start the O-DU and wait for cell activation; attach one UE, complete registration and establish a PDU session; verify reachability to the data network through the UE tunnel; stop the components so their interface captures are flushed and readable; decode the captures and execute the certification suite; and grade the evidence to produce the scorecard and certificate decision.
One attachment produces evidence for 51 of the 58 Level-1 requirements. Seven robustness cases are exercised separately, by restarting products or sending malformed input to exposed sockets.
Teardown is part of evidence collection, not merely cleanup. The tested RAN stack closes its per-interface capture files during shutdown, which is what makes the retained captures complete and readable.
What counts as evidence
| Evidence | Source | Used to evaluate |
|---|---|---|
| Wire capture | Per-interface packet captures decoded with tshark | Protocol conformance, security information elements and user-plane behaviour |
| Socket state | SCTP and other socket state | Associations, recovery and listener readiness |
| Process state | Process inspection | Liveness and crash detection |
Product logs are retained for diagnosis but never determine a verdict. This prevents a product from effectively certifying itself through its own log statements.
The distinction is deliberate: packet, socket and process evidence establish what happened; product logs help explain why it happened; and the versioned catalogue determines what that observation means for certification.
Validated against a live OCUDU split gNB
The framework was validated using an OCUDU split gNB running as three processes, free5GC on Kubernetes as the 5G Core, an OpenAirInterface nr-UE, and a ZeroMQ virtual radio. All 58 Level-1 requirements executed.
The O-DU passed all 7 of 7 essential requirements and certified.
The two CU classes did not certify. Both exposed the same underlying security condition through different interfaces. The security policy indicated that confidentiality protection was required, while the selected ciphering algorithm was the null cipher NEA0. The E1AP Bearer Context Setup Request showed:
BearerContextSetupRequest
cipheringAlgorithm: nEA0 (0)
integrityProtectionAlgorithm: i-128-NIA2 (2)
securityIndication
integrityProtectionIndication: not-needed (2)
confidentialityProtectionIndication: required (0)Integrity protection received a real algorithm in the same procedure. The stack was operational, but one specific protection had been downgraded. A successful attachment alone would not have exposed that distinction.
The condition was independently visible for two product classes across two interfaces: in the F1AP evidence for the O-CU-CP, and in the E1AP evidence for the O-CU-UP.
Not Applicable never means Pass
Not every requirement can be judged in every deployment. CNTC records such a requirement as Not Applicable, together with the reason it could not be evaluated and what would be required to evaluate it.
A Not Applicable result is never promoted to Pass. If an essential requirement cannot be evaluated, the product class is marked incomplete rather than certified. A certificate is issued only when every essential requirement for that class passes.
This produces a more meaningful report. A result set in which every untested condition quietly becomes a pass may look complete, but it does not establish conformance.
Running a certification campaign
Install the tester without installing or modifying the RAN under evaluation, or the 5G Core it uses as a peer:
git clone https://github.com/TOSSI-Foundation/CNTC.git
cd CNTC
make ran-prereqsConfigure the adapter for the target stack:
make ran-configureThe configuration workflow derives UE radio parameters from the O-DU cell configuration, removing a common source of attachment failures. Run the preflight checks before starting a campaign:
make ran-doctor CONFIG=configs/my-ran.yaml
Certify each product class independently:
make ran-run CONFIG=configs/my-ran.yaml TARGET=cucp CAMPAIGN=MY-RAN-CUCP
make ran-run CONFIG=configs/my-ran.yaml TARGET=cuup CAMPAIGN=MY-RAN-CUUP
make ran-run CONFIG=configs/my-ran.yaml TARGET=du CAMPAIGN=MY-RAN-DUEach class takes approximately two to five minutes in the validated environment. Results are rendered in a live dashboard, and every campaign retains the captures and logs needed to independently re-examine its findings.
A common certification model across the 5G system
With RAN Certification, CNTC now covers the path taken by both signalling and user traffic. RAN Certification evaluates where the UE attaches and Access Stratum security is activated. Control Plane Certification evaluates the core functions that establish and manage the session. UPF Certification evaluates the user plane that carries the traffic.
All three capabilities share a result schema, grading model and definition of what a verdict may assert. This gives operators and integrators a consistent basis for comparing results across domains.
RAN-specific integration is isolated in an adapter with a small contract: describe the implementation, expose endpoints and capture paths, report liveness, and start or stop the required components. The 58 requirements and grading logic operate on decoded evidence rather than implementation-specific logs. Supporting another split RAN therefore means adding an adapter without rewriting the certification model.
CNTC can also work with an independently supplied 5G Core. In manual core mode, the RAN engine does not probe or modify the core beyond the configured readiness checks.
Roadmap: deeper tests and additional splits
The CU/DU split is the first RAN decomposition covered by CNTC, but it is not the only interface where independently supplied components must interoperate.
| Split | Interface | Separates | Specification | Status |
|---|---|---|---|---|
| Option 2 | F1 | CU from DU | 3GPP TS 38.473 | Available in Level 1 |
| CU separation | E1 | CU-CP from CU-UP | 3GPP TS 38.463 | Available in Level 1 |
| Option 6 | FAPI and nFAPI | MAC from PHY, L2 from L1 | SCF 222 and SCF 225 | Planned |
| Option 7.2x | O-RAN Open Fronthaul | O-DU from O-RU | O-RAN WG4 | Planned |
The roadmap also deepens the test model. Level 1 asks whether a product behaves correctly when its peers behave correctly. Level 2 will ask how it responds when a peer replays, corrupts, downgrades or malforms protocol input.
Eighteen Level-2 requirements are drafted as roadmap catalogues: 10 for O-CU-CP, 4 for O-CU-UP and 4 for O-DU. Executing them requires deliberately misbehaving peer implementations, which remains future work. Additional adapters are planned for srsRAN Project and the OpenAirInterface gNB.
Open implementation, independently checkable results
CNTC is released under the Apache License 2.0 by the TOSSI Foundation. The RAN implementation builds on OCUDU for the CU/DU stack, OpenAirInterface nr-UE for the software UE, free5GC for the validation core, and Wireshark tooling for packet decoding.
Every campaign retains the packet captures and product logs associated with its findings. This allows a result to be reviewed against the same evidence used to produce it.
A result that cannot be independently checked is an opinion. A result that can be independently checked is a measurement.
- Documentation: RAN Certification
- Source code: github.com/TOSSI-Foundation/CNTC