Telcos are paying the price for a standards process optimised for vendor optionality rather than operator discipline, but how do we get out of this?
Last week the operator-led NGMN Alliance published a white paper called “Framework for Network Simplification: An Operator View“. The paper identifies four technology enablers for simplification (cloud-native architectures, agentic and generative AI, federated API exposure, and optical fibre evolution) plus one organisational enabler (agile ways of working). It maps the challenges operators face in adopting them across radio, core and transport domains, and proposes a prioritisation framework tailored to operators at different stages of 5G maturity.
The trade press has quite reasonably reported it as a useful piece of industry guidance, which it is. But the more interesting reading is between the lines.
What this paper really documents, I assume unintentionally, is that the global mobile industry is still treating the consequences of structural decisions made years ago as if they were implementation problems that better planning can resolve.
The catalogue of consequences
In fairness, the paper is unusually candid. Written by operator contributors including Liberty Global, BT, China Mobile, Turkcell, MTN and US Cellular, it doesn’t pretend that simplification is straightforward. The RAN section alone identifies performance gaps in virtualised and Open RAN products relative to purpose-built equipment; fragmentation among cloud reference platforms with no consensus on a common framework; data siloed across domains and vendors in formats that predate the AI era; vendor lock-in on radio network optimisation because open interfaces for AI-driven performance tuning don’t yet exist; and the inconvenient fact that 5G radio interfaces were never designed with AI in mind.
The core network section acknowledges that slow development of standardised cloud orchestration layers has left early adopters stranded on proprietary or NFV architectures. The transport section notes dependence on fibre deployment that many operators can’t afford to accelerate. And the paper explicitly excludes BSS from scope, deferring it to TM Forum — even though the federated API exposure and service creation themes it champions are fundamentally customer-facing capabilities that can’t realistically be divorced from the systems that bill and provision them.
Each of these problems is real, but none of them appeared overnight, and few of them are primarily technology problems. They are consequences of decisions embedded in the standards, the vendor ecosystem, and the industry’s institutional habits.
Six years is a long time to say “this isn’t working”
The first commercial 5G networks launched in 2019. Even then, informed observers were pointing out that 3GPP had rushed out a compromise architecture, featuring both Standalone and Non-Standalone deployment options, in response to internal stakeholder pressures as much as market demand. Some operators and vendors wanted to go to market quickly using existing 4G core infrastructure. Others wanted the full architectural benefits of a new 5G core. 3GPP accommodated both, which meant the standards had to support two fundamentally different deployment paths.
The result created increased specification complexity, larger vendor product portfolios, harder interoperability testing, and operational headaches that persist to this day. That’s not a problem with the fundamental technology itself, but is the outcome of a standards process that tends to keep options open rather than forcing hard choices.
So, nearly six years on, the operators’ own alliance is publishing a framework to help them cope with complexity that was, at least in part, baked in at the design stage. The question is whether anyone is doing anything to prevent the same pattern repeating with 6G.
The 6G déjà vu
NGMN’s own 6G Key Messages paper from June 2025 states outright that 6G standards must learn from the mistakes of 5G, including “multiple architecture options, features that are never used and use cases that have no market pull.”
It goes further, stating that 6G should have “only one option of architecture.” So it’s clear that the NGMN, currently helping operators navigate the wreckage of exactly this kind of optionality in 5G, sees the problem. However, stating lessons in a position paper and embedding them in the standards process are two very different things.
3GPP Release 20 is under way. While there are contributions from a wider overall set of stakeholders, the same vendors tend to dominate the contribution process. The same dynamic persists, where vendors push capabilities into standards partly to establish patent positions, regardless of whether operators or their customers have signalled commercial demand.
Meanwhile the ITU’s IMT-2030 framework defines usage scenarios that are even more diverse and more ambitious than those that shaped 5G. The NGMN’s own 6G paper simultaneously calls for modularity, simplicity, native voice support from day one, seamless evolution from 5G, global harmonisation, and support for an expanded set of use cases.
These objectives exist in tension with each other, and the standards process has no mechanism for resolving that tension other than accommodation — which is precisely how complexity accumulates.
The fundamental institutional incentives haven’t changed from one generation to the next.
- Vendors benefit from feature-rich standards that create patent licensing opportunities.
- Operators have divergent timelines and market conditions that create pressure for optionality.
- 3GPP operates by consensus, which structurally favours accommodation over hard choices.
Unless one or more of those dynamics shifts, the most probable outcome for 6G is a somewhat cleaner initial specification that gradually accumulates complexity through subsequent releases.
It’s not the technology
What makes the NGMN simplification paper most revealing is how it connects to a pattern that extends well beyond network architecture.
A TelcoForge survey of almost 160 senior executives in late 2025 found that 66% cited skills and recruitment gaps as their biggest challenge, actually ahead of AI disruption and capital expenditure pressures. The NGMN paper identifies agile ways of working as a critical enabler for simplification, but then acknowledges that operators’ existing organisational structures, culture and skills aren’t equipped for the multi-vendor, cloud-native environments the industry is trying to build.
In each case the message is the same: the bottleneck is in the organisation and its capabilities, not the network. Teresa Cottam, Chief Analyst at Omnisperience, put it more bluntly in a recent TelcoForge interview: “Operators are brilliant at running networks and terrible at running businesses.”
The NGMN paper’s decision to exclude BSS from scope, while promoting network API exposure and federated service creation, is an example of this divide. You can’t work to simplify the creation and delivery of new services while treating the commercial and customer-facing systems as someone else’s problem.
What would actually help
If the NGMN wants to prevent a repeat performance with 6G, the intervention needs to happen upstream, in the standards governance process itself. Three suggestions that might help, and which are I’m sure not exhaustive:
First, operators need to exercise collective demand-side discipline over feature proliferation in 3GPP. The fundamental asymmetry is that vendors drive contributions and operators adopt — or, increasingly, don’t adopt — the results. Operators organising through a body like the NGMN or GSMA theoretically have the collective weight to refuse validation of features without demonstrated commercial demand. In fact, GSM was driven by operators specifying the outcomes they wanted and handing it over to vendors to standardise, so it’s possible to do. But it requires coordinating on saying no, which has always been harder than coordinating on aspirational targets.
Second, mandatory review gates for standards features. The 5G specifications accumulated options because there was no mechanism to remove them once added. If every feature or architecture option carried a built-in provision to demonstrate commercial deployment within a defined window or face removal, the standards would stay leaner over time. As it stands, 5G standards contain many specifications which aren’t deployed at all; you’ll hear different numbers bandied about, but the gist is that most of 5G specifications are unused. This is a governance reform, not a technology initiative.
Third, and most difficult: fewer options, harder choices. NGMN’s own 6G paper already calls for a single target architecture. Enforcing that through the standards process would require operators to accept that not every market will get a deployment path tailored to its specific constraints. That’s a genuinely uncomfortable thought, but the alternative is already documented in the simplification paper: years of accumulated complexity, rising operational costs, and a growing gap between what the network can theoretically do and what operators can practically deliver.
The real test
None of this undermines the fact that the NGMN paper is genuinely valuable for operators working through 5G deployment decisions today. The challenge catalogue is honest, the domain-by-domain analysis is thorough, and the maturity-based prioritisation is sensible guidance for CTOs navigating immediate trade-offs.
However, the paper does also reflect institutional limitation within the telecoms industry. It addresses the symptoms of a governance problem with operational guidance, and it arrives over six years after the architectural decisions that created much of the complexity it catalogues.
The real test for the NGMN, and for the wider telecoms industry, is whether this recognition translates into structural change in how 6G standards are developed and governed. The lessons have been clearly articulated by the NGMN itself and others. Whether the industry is willing to act on them, rather than publishing another framework in 2036 to help operators cope with the consequences of not doing so, remains an open question.
