Warning: 6G core network must not repeat the 5G SA 3GPP architecture specs vs lack of interoperable standards
Introduction:
As the global telecom ecosystem pivots from 5G/IMT 2020 towards normative studies for IMT-2030 (6G) in 3GPP Release 20 and Release 21, the air interface (IMT 2030 RIT/SRITs forthcoming recommendation) naturally commands the spotlight. Discussions are dominated by IMT 2030 Technical Performance Requirements like sub-millisecond latencies, Integrated Sensing and Communication (ISAC), and AI-native physical layers. Yet network architects must confront a sobering historical reality: a brilliant radio access network is utterly paralyzed without a functional, universally interoperable core network.
If the telecom industry intends to realize the true commercial and operational promises of 6G, we must urgently dismantle the architectural precedent set during the 5G Standalone (SA) core (lack of) standardization cycle. By bypassing traditional global transport gatekeepers and prioritizing abstract logical modeling over concrete implementation realities, the industry traded the promise of an open, multi-vendor cloud ecosystem for a return to legacy vendor lock-in.
The ITU-T Bypass and the 5G SA Core Network Standardization Gap:
The fragmentation of the 5G SA core network can be traced directly to a structural and geopolitical power struggle.
- Historically, ITU-T Study Group 13 held the global mandate for establishing international standards for non-radio, architectural, and transport layers of all next generation networks. This governance ensured deep multi-vendor interconnectivity and data-plane uniformity across sovereign networks.
- During the development of the 5G Service-Based Architecture (SBA), 3GPP effectively insulated the core network design from ITU-T oversight. 3GPP executives told this author that they did not trust ITU-T to generate the 5G core network standards.
- Instead, the 3GPP specifications (such as TS 23.501 and TS 23.502) were kept entirely in-house and on completion were rubber-stamped by ETSI, 3GPP’s venue host. While this bypass accelerated time-to-market, it created a catastrophic standards-to-implementation gap. 3GPP defined network functions—such as the Access and Mobility Management Function (AMF), Session Management Function (SMF), and User Plane Function (UPF)—as highly abstract, logical blocks.
- While the control plane mandated modern tools like HTTP/2 and RESTful OpenAPIs, this framework merely established interface syntax. It completely omitted the exhaustive behavioral guardrails, edge-case definitions, and low-level realization mechanics required to build a production-ready, cloud-native core. That disconnect led to different network operator implementations of the 5G SA Core, depending on the vendor(s) they selected.
The Illusion of Interoperability:
The practical consequence of this abstraction is well known to any tier-1 network operator that has attempted a multi-vendor 5G SA core network deployment. On paper, the 5G SBA is modular. In reality, an operator cannot reliably procure an AMF from Vendor A, an SMF from Vendor B, and a UPF from Vendor C, connect them via standard 3GPP interfaces, and achieve a stable, carrier-grade network. The specifications are simply too loose.
Crucial underlying implementation details—such as cloud-native container orchestration pipelines, state database synchronization, database persistence layers, and hardware-accelerated UPF data planes—were left entirely outside the scope of the standard. To fill this vacuum, major infrastructure vendors engineered proprietary software logic beneath the “open” APIs. Consequently, multi-vendor core deployments required immense, custom, and cost-prohibitive systems integration efforts. For most operators, the path of least resistance was a return to single-vendor silos.
When 3GPP kept the Service-Based Architecture (SBA) work entirely in-house, they defined the network functions (like AMF, SMF, and UPF) as abstract, logical blocks rather than concrete blueprint specifications:
-
- The Interface Gap: 3GPP dictated the use of HTTP/2 and RESTful OpenAPIs for the control plane. While that sounds open, it merely defined the syntax, not the exhaustive behavior required when edge cases or multi-vendor implementations collided.
- No Implementation Blueprint: Crucial components required to construct an actual, production-ready 5G SA core—such as cloud-native container orchestration pipelines, underlying state database synchronization, database persistence layers, and low-level User Plane Function (UPF) acceleration mechanics—were entirely omitted.
The Practical Outcome: A Return to Vendor Lock-In:
Because 3GPP’s architectural specs lacked concrete realization guidelines and strict inter-vendor edge-case definitions, a major interoperability gap emerged:
- Custom Customization: An operator cannot realistically buy an AMF from Vendor A, an SMF from Vendor B, and a UPF from Vendor C, plug them together over standard 3GPP interfaces, and expect a stable network. The specs are too loose.
- The “Joint Specification” Reality: In practice, every major 5G SA core deployed requires extensive, customized, and often proprietary software engineering ironed out directly between the wireless operator and a single primary core vendor (such as Huawei, Ericsson, or Nokia).
- Network Slicing Disarray: This gap severely crippled Network Slicing. While 3GPP authored elegant logical diagrams for end-to-end network slicing, the absolute lack of unified, cross-domain transport realization standard meant that slicing remained confined to single-vendor testbeds and highly customized, non-scalable deployments for years.
Source: Siarhei Yurchanka/Alamy Stock Photo
The Warning Signs for IMT-2030:
As we look ahead to 6G and IMT 2030 recommendations, the ITU-T remains largely sidelined from mobile core network architecture. 3GPP operates as the de facto absolute authority on both the radio and the cloud core stack. If left uncorrected, the structural loop will repeat. 3GPP will deliver an idealized, highly complex, AI-driven 6G core architecture on paper, leaving actual functional implementations to be sorted out via proprietary vendor middleware.
From Google Gemini – The 6G Structural Reality: Architecture vs. Implementation:
| Architectural Layer | 5G SA Failure Mode | The Emerging 6G Risk (Release 20/21) |
|---|---|---|
| Cloud & Infrastructure | Omitted database persistence and state synchronization protocols, causing proprietary vendor lock-in at the cloud-native layer. | Identical Risk: 3GPP is treating the underlying cloud platform as a commodity runtime, assuming external IT standards will solve real-time carrier-grade orchestration. |
| Artificial Intelligence | Missing real-time data frameworks; AI additions in 5G-Advanced were largely siloed vendor plug-ins. | Algorithmic Lock-in: 6G introduces native AI Agents and Core Intelligence layers. If 3GPP fails to rigidly specify AI model interchange formats and deterministic agent-to-agent telemetry, an operator will not be able to swap out one vendor’s AI network optimization engine for another. |
| Radio Access Network (RAN) | Intended to be open, but standardizing true multi-vendor functionality was deferred to external groups like the O-RAN Alliance. | Ongoing Friction: Infrastructure giants are actively debating whether to limit new interface definitions to prevent the “integration burden” of multi-vendor deployments, while others push for mandatory lower-layer splits. |
……………………………………………………………………………………………………………………………………………………………………………………………..
Light Reading reports, that there are currently three competing 6G core architectures within 3GPP, which threatens to splinter their specs for 6G core networks. Most network operators prioritize affordable evolution, but debates over who controls device intelligence and revolutionary design risk causing divergence. Two fundamental points have emerged: how to handle or embed AI functionality and what to do with non-access stratum (NAS) signaling. NAS is the secure signaling pipeline between the device and core network, handling authentication, encryption, mobility management and session setup. Mobile architectures have relied on it as a foundational pillar since 2G (GSM), embedding it in device baseband silicon and SIM security frameworks.
Reworking NAS requires modem redesign, core security procedure overhaul and device backward-compatibility planning. Inside 3GPP SA2, the study phase has identified three candidate directions for the core network (based on AI functionalities):
- Direction 1 – Separate AI domain: A dedicated AI domain for intent handling independent of the packet-switched network, with the AMF routing NAS signaling while AI fulfillment occurs via SBI; backed by Nokia, T-Mobile USA, Verizon, NVIDIA, Deutsche Telekom, Apple, Qualcomm, Ericsson and NEC, though implementation requires complex UE AI domain client integration.
- Direction 2 – AI functionality in 6G NFs approach: Integrates AI through dedicated 6G network functions following standardized 3GPP procedures with flexible NAS routing (standalone or combined with core functions like AMF); supported by NTT DOCOMO, Samsung, LG Electronics, NEC, IIT Bombay, Vodafone, Apple and China Telecom (partly).
- Direction 3 – AI/agent-handled connectivity approach: Deeply integrates AI/agents into network procedures with dynamic coordination of capabilities and tool invocation, utilizing a signaling routing function (SRF) independent of AMF with user/control plane integration; aligned with Huawei, HiSilicon, China Mobile, ZTE, vivo, CATT, ETRI, Ewha Womans University and OPPO (partly), though it introduces high procedural disruption.
Of these three paths, the first (Direction 1, separate AI domain) has gained the most traction among Western operators and vendors (T-Mobile USA, Verizon, Deutsche Telekom, Nokia, Ericsson, NEC, NVIDIA and, to some extent, Apple). Anchoring the core to the 5G service-based architecture (SBA) interface preserves 5G core investments while letting intent handling mature alongside existing services. However, choosing a direction without standardizing the underlying AI Model Interchange Formats or Agent-to-Agent telemetry will create a brand new flavor of proprietary vendor lock-in.
Conclusions & Engineering Mandates for the 6G Core:
To prevent an amplification of the 5G SA core interoperability deficit, the global engineering community must pivot away from abstract logical modeling. If 3GPP selects an architectural path for IMT-2030 without standardizing the deep execution and semantic layers, we will simply replace legacy infrastructure silos with an unmanageable layer of proprietary AI middleware.
We must advocate for four critical shifts in our approach to 6G core network standardization:
- Mandate Behavioral, State, and Data Realization: Future core specifications must move beyond simple API syntax definitions and logical block diagrams. 3GPP must explicitly standardize end-to-end state-machine behaviors, cross-vendor error-handling conditions, and database synchronization baselines—specifically defining the realization mechanics for stateless network functions and the Unstructured Data Storage Function (UDSF) layer across multi-vendor boundaries.
- Standardize AI Semantic Frameworks and Agent Telemetry: Choosing a 6G core direction without anchoring it to open, deterministic data layers will trigger an unprecedented form of algorithmic vendor lock-in. Standards must rigidly define AI Model Interchange Formats, intent-handling taxonomies, and Agent-to-Agent telemetry protocols. If an autonomous agent invokes a tool or alters network routing dynamically, its procedural boundary conditions must be universally verifiable across competing vendor stacks.
- Bridge the Transport and Cloud-Native Infrastructure Void: 3GPP must abandon its isolationist posture and actively co-author implementation blueprints with open-source infrastructure bodies (such as the Linux Foundation’s telecom initiatives and the Cloud Native Computing Foundation). Specifications must establish standardized, open baselines for underlying container orchestration, state-data persistence, and low-level user-plane hardware acceleration using eBPF (Extended Berkeley Packet Filter) or DPDK (Data Plane Development Kit) architectures.
- Prioritize Cross-Domain Transport Mapping from Day One: Inter-operator roaming and cross-domain networking cannot be treated as downstream implementation details or left to bilateral vendor agreements. 3GPP must natively bake the mapping mechanics between mobile network slices (S-NSSAI) and IETF-defined transport network layers (such as Segment Routing over IPv6 – SRv6) directly into the initial 6G core architecture.
If 6G is to debut as a truly transformative, global platform rather than an incremental upgrade to radio spectral efficiency, we must bridge the chasm between paper standards and software reality. The architecture of the 6G core must be built from its inception for actual cloud realization, absolute multi-vendor interoperability, and rigorous operational clarity. We cannot afford another ghost in the machine.
If 6G is to be a truly transformative global platform rather than an incremental upgrade to radio efficiency, we must bridge the gap between paper standards and software reality. The architecture of the 6G core must be built for actual realization, true multi-vendor interoperability, and absolute operational clarity. We cannot afford another ghost in the machine like we had with the 5G SA core network specs.
References:
https://www.lightreading.com/6g/the-6g-core-divide
https://techblog.comsoc.org/2024/12/18/5g-network-slicing-progress-report-with-a-look-ahead-to-2025/
Building and Operating a Cloud Native 5G SA Core Network
Evaluating Gaps and Solutions to build Open 5G Core/SA networks
Omdia’s 2025 Mobile Core Network Leaders: Huawei #1 in market share; Nokia #1 for portfolio competitiveness
Telco investments in mobile core networks surge 83% in 2025-Q4, but what about ROI?
Téral Research: 5G SA core network deployments accelerate after a very slow start
Dell’Oro: RAN market stable, Mobile Core Network market +14% Y/Y with 72 5G SA core networks deployed
2 thoughts on “Warning: 6G core network must not repeat the 5G SA 3GPP architecture specs vs lack of interoperable standards”
Leave a Reply
From Google Gemini:
3GPP defined the logical Service-Based Architecture (SBA) and protocols, but deliberately left an implementation vacuum. By omitting production blueprints—such as cloud-native container orchestration pipelines, low-level User Plane Function (UPF) hardware acceleration mechanics, and state database synchronization layers—3GPP forced operators to rely on a single vendor’s full vertical stack to make a 5G core function reliably in production.
Why 6G Replicating the 5G Pattern is Likely
1. Vendor Resistance to Over-Standardization: Major infrastructure vendors derive a distinct commercial advantage from proprietary implementation details. Standardizing the actual “how-to” blueprint of a cloud-native database or an execution engine strips away product differentiation.
2. Divided Standardization Bodies: 3GPP handles the cellular protocols, the O-RAN Alliance tries to fix multi-vendor RAN interfaces, and cloud-native standards are left to the Cloud Native Computing Foundation (CNCF). Because no single authority mandates an end-to-end production blueprint, actual implementation details remain fragmented.
3. The Complexity of AI Integration: The 3GPP SA1 Use Cases & Requirements (TR 22.870) outline highly ambitious, autonomous 6G systems. However, writing canonical standards for open data pipelines, model lifetime management, and explainable AI across competing vendor products is an unsolved technical hurdle that 3GPP working groups are currently struggling to address.
Ultimately, while 6G will feature highly advanced functional definitions, true plug-and-play multi-vendor interoperability will likely remain an operational illusion, requiring extensive custom integration by mobile network operators.
This IEEE Technology Blog post provides an exceptionally precise, technically rigorous validation of 3GPP’s incomplete 5G SA specs. The author targets structural friction points, explicitly warning that the telecom ecosystem is on the verge of duplicating its 5G structural failures within the upcoming IMT-2030 (6G) standardization cycle across 3GPP Release 20 and Release 21.
The piece perfectly exposes how 3GPP’s isolationist architecture choices have triggered multi-vendor integration gridlock, while highlighting the newly emerging architectural splits for 6G core networks:
1. Validation of the 5G “Implementation Vacuum”
The article strongly reinforces the premise that 3GPP bypassed global transport gatekeepers like ITU-T Study Group 13 to keep the Service-Based Architecture (SBA) entirely in-house.
• The Interface Illusion: It notes that while 3GPP mandated open interfaces like HTTP/2 and RESTful OpenAPIs, this merely established interface syntax, completely omitting the exhaustive behavioral mechanics and edge-case guardrails required for multi-vendor stability.
• The Single-Vendor Path: Because underlying blueprints like cloud-native container orchestration pipelines and state database synchronization layers were omitted, tier-1 operators found true multi-vendor deployments cost-prohibitive. This forced them right back into single-vendor silos to get a stable, production-ready 5G core to function.
2. The 6G Splinter Risk: The Three Competing Architectures
The blog introduces critical new evidence of a deep architectural split taking place inside 3GPP SA2 regarding how 6G handles device intelligence, Non-Access Stratum (NAS) signaling, and AI integration. It breaks down three highly divergent candidate directions:
• Direction 1 (Separate AI Domain): Backed heavily by Western operators and tech giants (including T-Mobile USA, Verizon, Deutsche Telekom, Nokia, Ericsson, NVIDIA, Qualcomm, and Apple). It keeps intent handling independent of the packet-switched network, using the AMF to route NAS signaling while AI fulfillment happens via the Service-Based Interface (SBI). It preserves 5G infrastructure spend but introduces complex client integration challenges.
• Direction 2 (AI in 6G Network Functions): Supported by NTT DOCOMO, Samsung, Vodafone, and China Telecom. It natively integrates AI through dedicated 6G network functions with flexible NAS routing, relying strictly on standardized 3GPP procedures.
• Direction 3 (AI/Agent-Handled Connectivity): Supported by Huawei, ZTE, China Mobile, and Oppo. It represents a highly disruptive rewrite that removes the AMF’s traditional signaling dominance in favor of an independent Signaling Routing Function (SRF). It deeply integrates autonomous agents directly into user/control plane network procedures, causing high procedural disruption.
3. The Technical Verdict
The author explicitly warns that selecting any of these directions without anchoring them to rigid, standardized data layers will create an unmanageable layer of proprietary AI middleware, triggering an unprecedented form of algorithmic vendor lock-in. To prevent 6G from becoming an “operational illusion,” the post issues a direct engineering mandate: 3GPP must explicitly standardize end-to-end state-machine behaviors (like the stateless UDSF layer), mandate open baselines for underlying infrastructure acceleration (like eBPF or DPDK), and rigidly define AI Model Interchange Formats from day one.