Open source transformed telecom. It gave the industry freedom from proprietary stacks, accelerated innovation, and enabled an ecosystem where operators, vendors, researchers, system integrators, and developers could build together. Today, nearly every major component of a modern 5G network has an open-source implementation. But one fundamental question has remained unanswered: how do we know an open network function is truly production ready?
A successful demo proves that software runs. A certification proves that software can be trusted.
Today, The TOSSI Foundation is proud to introduce Cloud Native Telecom Certification (CNTC), an open certification framework designed to bring measurable quality, standards compliance, reproducible validation, and trusted certification to cloud-native telecom software.
The journey begins with the release of the CNTC UPF Certification Module.
Open Telecom Needed More Than Open Source
The telecom industry has invested heavily in open ecosystems: Open RAN, open 5G Core, Kubernetes-native deployments, programmable data planes, and cloud-native network functions. But openness alone does not answer the questions operators ask before deploying software into production.
Does the implementation comply with 3GPP specifications? Can it handle malformed or hostile protocol traffic? Will it behave consistently under subscriber load? Can different implementations be evaluated fairly using the same methodology?
Until now, every organization has answered these questions differently, using different scripts, environments, benchmarks, and assumptions. The result is fragmented validation instead of shared assurance. CNTC changes that.
Introducing Cloud Native Telecom Certification
CNTC is not simply another testing framework. It is an open-source certification platform that turns technical validation into objective certification. Instead of only executing test cases, CNTC evaluates network functions against a versioned standards catalog, applies transparent grading criteria, and produces reproducible scorecards and certificates.
At the core of CNTC is a separation between test execution and certification logic. The execution layer drives traffic, establishes PFCP sessions, injects protocol events, collects metrics, captures logs, and records raw evidence. The certification layer, through a separate Verdict Engine, evaluates those results against a versioned catalog that defines which tests exist, which are essential, how categories are scored, and when certification can be awarded.
This makes CNTC standards-driven, vendor-neutral, reproducible, auditable, and open for community review. Certification should not depend on who ran the tests. It should depend on whether the software satisfied clearly defined technical requirements.
Why CNTC Begins with the User Plane
CNTC begins with one of the most critical components of the 5G Core: the User Plane Function, or UPF. The UPF forwards subscriber traffic, enforces forwarding actions, processes GTP-U tunnels, applies QoS and policy behavior, and maintains the user-plane data path. Every subscriber packet passes through it, and every latency or throughput measurement ultimately depends on its correctness.
CNTC treats the UPF as a black box and validates it through the same production interfaces used in real 5G deployments:
- N3 for GTP-U user-plane traffic
- N4 for PFCP control-plane procedures
- N6 for the data network interface
This allows different UPF implementations to be tested using the same methodology and certification criteria. The first CNTC UPF Certification Module supports:
- SD-Core BESS-UPF
- OpenAirInterface OAI-UPF
- Open5GS-UPF
For SD-Core BESS-UPF, CNTC also supports validation across multiple forwarding modes: AF_PACKET, DPDK, AF_XDP, and CNDP. This ensures certification covers both functional correctness and production-grade datapath behavior. Different implementations. Different datapaths. One certification methodology.
Certification Beyond Performance
Traditional benchmarks often focus on throughput alone. Throughput matters, but it is not enough. A UPF can forward packets quickly and still fail protocol conformance. It can pass a happy-path benchmark and still crash on malformed GTP-U traffic. It can perform well on a single tunnel but behave poorly when many subscribers are active together.
CNTC therefore evaluates the UPF through four certification suites: Performance, Load, PFCP Conformance, and N3 Robustness. Together, these suites validate forwarding capacity, scalability, standards compliance, and operational resilience.
Performance Certification
The Performance suite measures raw forwarding behavior on a single tunnel using the NDR/PDR methodology from IETF RFC 2544 and ETSI GS NFV-TST 009. It includes:
- TC-01: Throughput vs. frame size, including No-Drop Rate and Partial-Drop Rate
- TC-02: Bidirectional throughput across uplink and downlink
- TC-03: Latency and jitter from packet parsing to FAR execution
- TC-04: Burst and back-to-back packet tolerance
- TC-08: Multi-flow RSS distribution
Performance results are graded separately because throughput is always tied to the hardware and datapath that produced it. CPU, NIC, kernel version, memory, acceleration mode, and forwarding path all affect the result. CNTC keeps performance measurable, but also honest.
Load Certification
Real networks do not operate on a single tunnel. They serve many users at the same time. The Load suite evaluates how the UPF behaves when many subscribers are active together. In CNTC, each user is represented as a PFCP session with its own forwarding rules.
The suite measures maximum concurrent PFCP sessions, aggregate throughput, per-UE throughput, and latency under load. This moves certification closer to operational reality: a UPF must not only forward traffic efficiently, it must remain predictable when subscriber scale increases.
PFCP Conformance
The N4 interface is how the 5G Core programs the UPF. If PFCP behavior is incorrect, the control plane cannot reliably manage user-plane sessions. CNTC validates PFCP conformance against 3GPP TS 29.244 using five essential tests:
- CF-01: PFCP Association Setup and Release
- CF-02: Session Establishment
- CF-03: Session Modification
- CF-04: Session Deletion
- CF-05: Error Handling
The error-handling test includes cases such as unknown SEID and missing Information Elements, where the UPF must return the correct cause code rather than behave unpredictably. These tests validate protocol correctness, not just packet forwarding.
N3 Robustness
Production networks are not always clean. Malformed packets, unexpected protocol behavior, and hostile traffic can occur. The N3 Robustness suite turns crafted, non-conformant data-plane packets into reproducible pass/fail checks against 3GPP TS 29.281. It includes:
- NT-01: Unknown TEID robustness
- NT-02: Malformed GTP-U robustness
- NT-03: PDU Session Container robustness, including extension header 0x85
The goal is not only to verify that a UPF forwards valid traffic. The goal is to ensure it remains stable when traffic is invalid. That distinction is central to production readiness.
The Essential Certification Gate
Not every test carries the same weight. CNTC classifies tests as Essential, Normal, or Bonus. The current conformance profile, Catalog v0.2.0, defines seven essential tests: CF-01 through CF-05, NT-01, and NT-02.
The gate is strict. A result is PASS only when all essential tests pass, FAIL when any essential test fails, and INCOMPLETE when an essential test did not run. There is no silent pass by omission. Performance contributes to grading, but correctness determines certification.
Certification Must Be Able to Fail
Certification is meaningful only when it can reject software. During an early robustness campaign, the NT-03 PDU Session Container test exposed a reproducible denial-of-service condition in an open-source UPF. A single crafted GTP-U packet with a malformed PDU Session Container caused the data plane to terminate and restart under orchestration.
The issue is being handled responsibly and privately with the maintainers. This finding demonstrates why certification matters. Happy-path demos rarely expose this class of defect, but production networks eventually do. Certification that cannot fail software is not certification. CNTC can, and it did.
The Certificate and the Scorecard
When a CNTC run clears the Essential Certification Gate, the framework automatically issues a certificate. Each certificate records what was verified, including the certification profile, catalog version, validated standards, test environment, essential-gate result, and supporting evidence. For the UPF module, the certificate covers:
- 3GPP TS 29.244 for PFCP over N4
- 3GPP TS 29.281 for GTP-U over N3
Certificates are emitted in Markdown, HTML, and JSON, making them easy to publish, render, archive, or machine-validate. If a run fails or skips an essential test, CNTC produces a scorecard instead of a certificate. The scorecard shows per-test outcomes, category scores, essential-gate status, and the verdict block used by the Verdict Engine. The certificate represents earned certification. The scorecard represents evidence, progress, and gaps.
Transparency by Design
Every CNTC certificate is traceable to the campaign, catalog version, and evidence behind the verdict. This gives operators, vendors, maintainers, and researchers a transparent way to understand and reproduce certification results.
Every campaign can produce detailed scorecards, JSON reports, HTML and Markdown reports, PDF certification reports, execution logs, versioned metadata, and dashboard views. Nothing is hidden behind proprietary scoring. Everything is auditable.
A Dashboard Designed for Engineers
CNTC includes a live dashboard to make certification activity visible and comparable. Engineers can review live scorecards, campaign history, test catalogs, findings, certificates, per-test outcomes, category scores, and essential-gate status.
This helps maintainers prioritize defects, operators evaluate readiness, and the community compare implementations using a shared view of quality. The goal is not only to run tests. The goal is to make telecom assurance visible.
Today Is UPF. Tomorrow Is the Telecom Stack
The UPF Certification Module is only the beginning. CNTC has been designed as a modular certification platform that can expand across the cloud-native telecom ecosystem, including AMF, SMF, SBI interfaces, O-CU, O-DU, O-RU, Near-RT RIC, Non-RT RIC, xApps, rApps, SMO, end-to-end O-RAN deployments, and end-to-end 5G Core deployments.
Each module will follow the same principles: Open Standards. Open Testing. Open Certification. A trustworthy telecom stack requires trust at every layer. CNTC begins with UPF because the user plane is foundational, but the broader vision is to create a common certification framework for cloud-native telecom as a whole.
Building Trust Together
The next generation of telecom infrastructure will not be built by a single company. It will be built by an ecosystem. Certification should evolve the same way.
CNTC is released under the Apache 2.0 license because trust cannot be proprietary. Certification for open telecom should be transparent, community-driven, standards-aligned, and continuously improving. Whether you develop telecom software, integrate cloud-native networks, operate production infrastructure, contribute to open-source projects, or research next-generation 5G and 6G systems, CNTC provides a common framework for evaluating quality through objective and reproducible evidence.
Open source built modern telecom. CNTC is helping build the trust that modern telecom now requires. The launch of the UPF Certification Module is only the first milestone. The certification journey for cloud-native telecom has just begun. Welcome to CNTC.
For the full technical guide, see the Cloud Native Telecom Certification documentation and the UPF Certification deployment guide.