The 5G Monetization Conundrum: Understanding the Pipe vs. Platform Dilemma

Operators have spent heavily on 5G. The open question is where the money is actually made, and whether operators can realistically move up into enterprise software.

Every new generation of cellular technology brings back the same argument about where operators fit in the technology value chain. 5G has made that argument hard to ignore:

• Heavy capital spending: Operators paid for mid-band spectrum, massive MIMO upgrades at cell sites, and standalone (SA) cloud-native cores.
• Value earned above the radio layer: The higher-margin enterprise software revenue keeps going to cloud providers, specialized aggregators, and vertical systems integrators.
• Second thoughts on strategy: Some now ask whether communication service providers (CSPs) should stay as infrastructure operators or try to package complete enterprise solutions.

5G was standardized in 3GPP Releases 15 through 17, and its early pitch centered on enterprise transformation: ultra-reliable low-latency communication (URLLC), deterministic network slicing, and edge compute (MEC). In practice, Fixed Wireless Access (FWA), which is essentially a broadband replacement sold on capacity, has become 5G’s clearest commercial success. Bespoke enterprise offerings have been much harder to monetize.

Industry initiatives like the CAMARA project and GSMA Open Gateway try to close this gap. They expose standardized network capabilities, such as Quality-on-Demand (QoD) and device verification, to developers through RESTful APIs.

That leaves operators with a debate still running in boardrooms and engineering teams: Does relying on third-party developers and cloud ecosystems turn the operator into a low-margin utility, or is trying to become an enterprise software provider an even riskier use of capital?

Both sides have a case, so it is worth looking at each.

Perspective A: The Risk of the API and Aggregator Model

Why handing solution packaging to others puts margin and customer relationships at risk

The worry that telcos will end up as undifferentiated "dumb pipes" rests on patterns already visible in enterprise digital services.

1. Why Software Earns the Margin

In a layered technology stack, gross margin tends to go to whoever owns the end-user workflow and the application logic. Take an industrial automation deployment or a connected fleet:

• The application layer: The enterprise usually contracts with a cloud provider, software vendor, or systems integrator for orchestration dashboards, data pipelines, and security analytics. These are often billed as recurring monthly platform retainers running to several thousand dollars (at software gross margins typically above 70%).
• The network layer: Under a standardized API model, the application calls carrier APIs, such as dynamic latency adjustments or SIM location checks, only when it needs them and pays per transaction.

Individual API calls tend to be priced down quickly toward the marginal cost of a transaction. The party carrying the physical risk (cell site leases, power, backhaul transport, and spectrum amortization) therefore captures only a fraction of the value the enterprise pays for.

2. The A2P Messaging Precedent

We have seen this before in Application-to-Person (A2P) messaging over the past two decades.

Operators owned the networks that carried two-factor authentication (2FA) codes and programmatic enterprise alerts. But each operator offered its own interface, tied to its own jurisdiction and commercial terms, so communications platform as a service (CPaaS) aggregators stepped in to bridge the gap.

These platforms standardized the developer experience, published solid SDKs, and won the direct enterprise relationships. Over time the aggregators kept the valuable client integration and account management, while carrier connectivity was routed wherever wholesale termination pricing was lowest.

3. Abstraction Platforms and Enterprise Stickiness

Industrial IoT shows the same problem in dealing with enterprises directly.

Platforms such as Cisco IoT Control Center (formerly Jasper) were built to meet global enterprise needs that individual national operators could not easily meet alone. When a global automotive OEM or industrial manufacturer deploys connected assets worldwide, the setup looks like this:

The enterprise integrates once with the management platform, which automates SIM lifecycles, applies zero-trust security policies, and manages cross-border roaming profiles.

With standard GSMA eUICC (eSIM) profiles and multi-carrier orchestration, local connectivity becomes an interchangeable input. If one operator tries to force proprietary software add-ons or change commercial terms, the platform can move device profiles over the air to another network partner.

Seen this way, exposing capabilities through third-party developer platforms risks a future where operators carry the capital costs while others own the customer relationship and the pricing power.

Perspective B: The Fallacy of Telco-as-a-Software-Vendor

Why building proprietary vertical enterprise stacks does not fit what operators do well

The commoditization risk is real. The opposing view is that turning operators into direct enterprise software providers gets wrong both what operators are good at and how enterprises buy.

1. The Realities of Enterprise IT/OT Environments

Enterprise digital transformations rarely fail for lack of cellular bandwidth; they stall during integration with legacy systems.

Industrial and enterprise environments do not purchase abstract connectivity features like "network slicing" in isolation:

• Healthcare: A hospital network does not buy "sub-5ms latency." It buys a HIPAA-compliant medical imaging pipeline that works natively with its Electronic Health Record (EHR) system, such as Epic or Oracle Health (formerly Cerner).
• Manufacturing: A factory operator does not buy a "5G private slice." It needs deterministic communication that works with established industrial protocols (PROFINET, EtherCAT) and connects directly to programmable logic controllers (PLCs) from vendors like Siemens or Rockwell Automation.

Enterprise software demands fast release cycles, deep domain knowledge, and heavy post-sales consulting. When operators have built bespoke vertical software in-house, the products have struggled to keep up with dedicated software vendors. The result is often high professional services costs and limited scalability.

2. The Multi-Carrier Footprint Limitation

The biggest barrier to operators becoming full-stack enterprise platform providers may be geographic fragmentation.

Few enterprises stay inside one operator's licensed footprint, as the diagram shows:

If an operator in North America builds an advanced logistics tracking or asset-monitoring application, an enterprise with supply chains across Europe and Asia cannot adopt it globally. Enterprise CIOs deliberately avoid juggling dozens of carrier portals, varying service-level agreements (SLAs), and non-standard data schemas.Enterprises naturally turn to global software layers, such as hyperscalers, enterprise network vendors, and global systems integrators, because these give them one consistent environment regardless of whose cell tower carries the packet.

3. Re-evaluating the Economics of the Infrastructure Moat

Calling network connectivity a "dumb pipe" overlooks how strong a business high-barrier infrastructure can be.

Providing physical, licensed connectivity is still a resilient business. It offers:

• High barriers to entry from licensed radio spectrum and rights-of-way.
• Mission-critical utility status, with predictable, recurring consumer and business cash flows.
• Healthy operating margins at the transport layer, provided capital spending matches actual subscriber demand.

Pressure on operators’ return on invested capital (ROIC) has often come not from the core connectivity business but from misallocated capital: buying non-core media assets, subsidizing speculative internal software projects, or building capacity far ahead of demand.

The 5G Reality Check

The commercial record of 5G suggests that operators are best at large-scale, high-availability infrastructure engineering and much less suited to running vertical software businesses.

Efforts to bypass third-party platforms and sell vertical applications directly have produced modest returns. The practical plays, such as delivering FWA broadband to households or acting as the connectivity layer for established industrial IoT platforms, still account for the clear majority of realized returns.

Where This Leaves Operators

Carriers are very good at building networks and keeping them running. They are much less good at selling software, and 5G has not changed that. The money 5G has made came from home broadband and from carrying traffic for other companies’ platforms, not from custom enterprise products.

That points to a plain strategy: get the most out of the network they already own. But staying in their lane does not mean standing still. The network has to stay hard to replace, and the best way to do that is to make it easy to build on. Cloud infrastructure works this way. The provider sells compute and storage by usage through clean, stable interfaces and leaves the applications to others. Developers build against those interfaces, so usage grows on its own, and rewriting an integration becomes a cost customers avoid. Operators can earn the same way: expose the network's capabilities cleanly, let others build on them, and get paid on the volume that follows.

This is not free of risk. The companies building on top will keep most of the customer relationship, but are there any other options?

Looking Ahead: What 5G’s Limitations Mean for 6G

The unresolved tension between network infrastructure and software value capture in 5G sets the agenda for 6G:

• Built-in integration: Can next-generation architectures build in capabilities such as Integrated Sensing and Communication (ISAC) and Non-Terrestrial Networks (NTN, first added in 5G Release 17) from the start, so they give software platforms clear, measurable value without complex custom integration?
• Slicing versus cloud orchestration: Will 6G move past the complex, carrier-centered slicing models that struggled in 5G, toward interfaces that fit standard Kubernetes and multi-cloud practice?
• Capex and spectrum: As research moves into the upper mid-band (the 7–15 GHz part of FR3) and AI-native radio interfaces, will 6G deliver real unit-cost reductions for operators, or repeat 5G's capital spending cycle without clear top-line growth?

In my upcoming article, "The 6G Conundrum: Physics, Capex, and the Architectural Reset," I will look at the emerging radio frameworks, deployment economics, and engineering choices shaping the road to 2030.