Can ecosystem models advance network API monetisation?

The network API opportunity

In our report Network APIs: Driving new revenue streams for telcos (April 2023) STL Partners forecast a revenue potential of more than US$22 billion globally for the top 11 network APIs by 2028 – a significant revenue opportunity for telecoms operators. Realisation of this potential depends on the telcos’ ability to select the right commercialisation strategy.

Telcos will need to distribute network APIs widely. For this, they could consider API distribution through:

  • their own platforms (providing services to large enterprises, e.g. T-Mobile’s DevEdge Platform in the US and Germany)
  • supply-side aggregators (similar to Twillio or Vonage)
  • system integrators
  • hyperscalers

But these options do have drawbacks. For example, telco-own platforms may struggle to scale (due to coverage limitations), margins and ability to add value through aggregators are limited, system integrator routes could also struggle to scale – and hyperscaler channels could risk ceding more control to these players than the telcos would like.

Work being done by the likes of CAMARA and the GSMA Open Gateway initiative to increase standardisation and interoperability of APIs may open up further distribution and commercialisation options in time. But additionally, we propose that telcos examine API distribution mechanisms that leverage the benefits of ecosystem business frameworks.

In our report Telco ecosystems: How to make them work (July 2020), STL Partners outlined several benefits of ecosystem business frameworks and why they can be particularly suited to new product and service areas where there is some uncertainty:

  • They support responsiveness to customer requirements (e.g., enable alternative feature bundling as the market moves).
  • They support continuous value-creation and innovation (partners bring in new service elements).
  • They support scale (the telco does not have to do everything on its own as more customers attract more partners, etc.).

The network API opportunity is still emerging and could benefit from the adoption of a flexible commercial approach, such as that presented by an ecosystem business framework. Ecosystem ways of working can encourage and make it easier for developers and enterprise to innovate, leveraging network API capabilities. In this report, we look at four examples of ecosystem-based business frameworks (the business models of existing companies) and consider how they might apply (hypothetically) to the network API opportunity – with a view to exploring the attractiveness of the approach for telcos navigating this area.

Our aim is to extend telco understanding of such models – as opposed to furnishing them with a specific recommendation regarding the commercialisation of network APIs – in the first instance. We wish to highlight the factors that telcos should bear in mind when considering ecosystem strategies.

Enter your details below to download an extract of the report

The ecosystem way

Ecosystem business frameworks are an alternative way of structuring economic activity and value creation versus vertical integration or linear, supplier-based frameworks. See Figure 3.

Comparing business frameworks

Source: STL Partners

The framework requires a strong customer value proposition in the first instance. In digital ecosystems, the value proposition typically involves using technology to link different aspects of a customer’s digital life in new ways (for example, Google Maps to show the way to a searched-for store). Once the value proposition is clear, the ecosystem creator (orchestrator) considers the components of the proposition and how to make it commercially viable (e.g. scale). They focus on their strengths within the set-up (what they do well) and invite others (suppliers/complementors) into the ecosystem to build out the proposition. This requires them to attract external stakeholders into an orchestrated business environment, where they share strong assets and capabilities with participants to help them create value for end customers (and the participant themselves). To be successful, ecosystems must therefore be designed with both customer and participant engagement and motivations in mind (insufficient participant engagement may mean supply-side failure).

Key requirements for a successful ecosystem are:

  • Putting the end-customer needs at the centre of an ecosystem to ensure the delivery of customer value (this requires a deep understanding of behaviour and motivations).
  • The ability to deliver an excellent experience for customers and participants to attract and maintain their engagement (i.e., minimising friction for all parties).
  • Enabling continuous innovation to deepen/extend relationships.
  • The ability to follow a dynamic strategic approach to enable the ecosystem to adjust, or even change direction, to accommodate unforeseen ecosystem consequences, as well as changes in customer requirements or market forces.

Table of content

  • Executive Summary
  • Table of Figures
  • Introduction
  • The ecosystem way
    • Why an ecosystem could be the best approach for APIs
  • An “association” approach – Mastercard
    • How does the model work?
    • How could this apply to APIs?
    • What does it take to work?
    • Evaluation of the approach
  • A vertical marketplace approach – Symworld
    • How does the model work?
    • How could this apply to APIs?
    • What does it take to work?
    • Evaluation of the approach
  • An OEM approach – Volkswagen/CARIAD
    • How does the model work?
    • How could this apply to APIs?
    • What does it take to work?
    • Evaluation of the approach
  • Use case marketplace – Amdocs
    • How does the model work?
    • How could this apply to APIs?
    • What does it take to work?
    • Evaluation of the approach
  • Conclusions and recommendations
    • How the ecosystem approaches are geared to succeed
    • Recommendations
  • Index

Enter your details below to download an extract of the report

NFV and OSS: Virtualization meets reality

Introduction: New virtual network, same old OSS

The relationship between NFV and OSS

This report discusses the relationship between NFV (Network Functions Virtualization) and OSS (Operations Support Systems), and the difficulties that operators and the developer community are facing in migrating from legacy OSS to NFV-based methods for delivering and managing services.

OSS are essentially the software systems and applications that are used to deliver services and manage network resources and elements in legacy telecom networks – such as, to name but a few:

  • Service provisioning: designing and planning a new service, and deploying it to the network elements required to deliver it
  • Service fulfillment: in its broader definition, this corresponds to the ‘order-to-activation’ (O2A) process, i.e. the sequence of actions enabling a service order to be logged, resourced on the network, configured to the relevant network elements, and activated
  • Service assurance: group of processes involved in monitoring network performance and service quality, and in proactively preventing or retrospectively repairing defective performance or network faults
  • Inventory and network resource management: managing the physical and logical network assets and service resources; keeping track of their utilization, condition and availability to be allocated to new services or customers; and therefore, closely related to service fulfillment and assurance.

As these examples illustrate, OSS perform highly specific management functions tied to physical network equipment and components, or Physical Network Functions (PNFs). As part of the migration to NFV, many of these PNFs are now being replaced by Virtualized Network Functions (VNFs) and microservices. NFV is developing its own methods for managing VNFs, and for configuring, sequencing and resourcing them to create, deliver and manage services: so-called Management and Orchestration (MANO) frameworks.The MANO plays a critical role in delivering the expected benefits of NFV, in that it is designed to enable network functions, resources and services to be much more easily programmed, combined, modified and scaled than is possible with PNFs and with OSS that perform isolated functions or are assigned only to individual pieces of kit.The problem that operators are now confronting is that many existing OSS will need to be retained while networks are transitioning to NFV and MANO systems. This is for a number of reasons. 

  • Executive Summary
  • Next Steps
  • Introduction: New virtual network, same old OSS
  • The relationship between NFV and OSS
  • Potential solutions and key ongoing problem areas
  • Conclusion: OSS may ultimately be going away – but not anytime soon
  • OSS-NFV interoperability: three approaches
  • OSS-NFV integration method Number 1: use the existing BSS / OSS to manage both legacy and virtualized services
  • OSS-NFV integration method number 2: Use a flexible combination of existing OSS for legacy infrastructure and services, and MANO systems for NFV
  • OSS-NFV integration method number 3: Replace the existing OSS altogether using a new MANO system
  • Three critical problem areas: service assurance, information models, and skills
  • 1. Closed-loop service fulfillment and assurance
  • 2. A Common Information Model (CIM)
  • 3. Skills, organization and processes


  • Figure 1: Classic TMN BSS / OSS framework
  • Figure 2: Telcos’ BSS / OSS strategy for NFV
  • Figure 3: Transition from BSS / OSS-driven to NFV-driven service management as proposed by Amdocs
  • Figure 4: NFV / SDN functions as modules within the Comarch OSS architecture
  • Figure 5: Closed-loop network capacity augmentation using Netscout virtual IP probes and a common data model
  • Figure 6: Service-driven OSS-MANO integration according to Amdocs
  • Figure 7: HPE’s model for OSS-MANO integration
  • Figure 8: BSS and OSS still out of scope in OSM 1.0
  • Figure 9: Subordination of OSS to the MANO system in Open-O
  • Figure 10: Vodafone Ocean platform architecture
  • Figure 11: Vodafone’s VPN+ PoC
  • Figure 12: Operators’ main concerns regarding NFV
  • Figure 13: Closed-loop service fulfillment and assurance
  • Figure 14: Relationship between Information Model and Data Models