It is worth noting that as communication service providers- CSPs check out new ways in order to drive value from their respective networks, application programming interfaces- APIs happen to be taking center stage. CSPs are indeed opening up 5G networks to application developers so as to kickstart innovation.
The API Economy
The fact is that one is experiencing moments pertaining to a major evolution in how the networks work fundamentally. Massive 5G advancements, network slicing, edge computing, as well as network-cloud convergence have all come together to make networks more programmable as well as containerized, all of which has made networks phenomenally nimbler as well as more responsive to transitions at scale, which, in turn, go on to create opportunities in order to think creatively in terms of new routes to revenue pertaining to network services. However, capitalizing on this architectural evolution needs a fresh look in terms of how networks get monetized. Network exposure enables CSPs to shift the network into a programmable service enablement platform by way of exposing network capabilities through open APIs so that Third-Party developers and enterprises can have access.
It is well to be noted that applications have gone on to become the bedrock of the modern digital economy. Moreover, these applications happen to be composed of microservices and self-contained software components that happen to work in tandem, thereby enabling these applications to ensure that they fulfill functions that are essential. Although it is the communication in these software components where the opportunity is. APIs happen to bridge the metaphorical gap between software elements, hence enabling the applications to communicate with each other. In today’s age, the digital economy happens to be foundationally dependent on a sophisticated ecosystem of microservices as well as APIs. While the application value has long been recognized, the value of the APIs as well as the ability to monetize such distinct assets goes on to present a new opportunity for the CSPs as part of the API economy.
Marrying networks as well as applications
Telecom companies have been kind of limited players when it comes to the application ecosystem, thereby largely offering connectivity indirectly to downstream applications while at the same time not interfacing directly in order to achieve outcomes for particular applications. Traditionally, application developers go on to do business by way of leveraging cloud services through Hyperscaler Marketplace, while there is limited ability for networks in order to engage with the requirements of certain applications. Network exposure not only enables discrete network functions to be made accessible at the application level, but at the same time also allows operators to go ahead and serve industries that have presented a challenge in the past because of a lack of in-house domain knowledge or even uncertain ROI.
The fact is that exposing the network APIs goes on to furnish ready as well as eager domain experts, in the form of application developers, with the tools they require so as to build and also enhance their own application offerings across the new markets. Placing the networks firmly at the center of this cross-industry innovation ecology and offering significant value to businesses as well as consumers alike, these businesses can readily elevate the functionality along with the user experience of their applications by way of integrating the telecom services, while consumers can go on to access advanced communication properties and make optimal use of the seamless integration of telecom services along with their digital applications.
Exposure happens to be more than NEF
5G went on to herald a fresh dawn in how networks go on to work. One could very well say that a move towards softwarization of networks meant a transition towards architectures that decoupled the software executing network functions as well as the protocols from the hardware beneath. This goes on to introduce network flexibility as well as speed, which enables the launch and scaling of new services with remarkable efficiency. As part of the 5G network function catalog, the Network Exposure Function- NEF happened to be introduced. NEF goes on to enable the CSPs to expose, in a secure way, certain new capabilities of the 5G core to external Third-Party applications throughout the standardized APIs. This happens to include data and information about the location as well as the reachability of devices, and at the same time, the ability to apply quality-of-service along with charging rules to certain data flows.
The CSPs who happen to have an interest when it comes to making network exposure a reality has by now likely gone on to select a NEF vendor and happen to be keenly looking at ways so as to monetize. Most happened to be rolling out a phased approach, thereby initially placing these APIs to be made use of internally so as to simplify operations and at the same time make major data throughout the business more accessible when it comes to a wider range of functions. Now, the challenge of how to best monetize network APIs externally happens to be becoming central to how CSPs anticipate creating novel revenue streams in the years to come. Telecom consultancy as well as research firm STL Partners forecast that the market for all mobile network APIs, which also includes MEC, would be US$22 billion by 2028. The addressable market can indeed be very clear, but there is indeed a lot to consider when it comes to assessing the go-to-market choices as far as network exposure is concerned.
Exposure Models
Go-to-market considerations happen to be intricate when working out how to best monetize exposed assets in newer markets. The fundamental decision that needs to be made here is where exactly the APIs or exposed network services are going to be made available for the application developers. CSPs can have a choice to sell APIs directly by way of their own shopfront or also through collaborating with a Hyperscaler marketplace depending upon how much of the application relationship the CSP is wanting to manage in-house. Whether electing an individual CSP model or collaborating as part of an international aggregator model, both ways happen to have their own set of advantages.
For example, the CSP that goes on to decide to make their APIs accessible by way of a CSP-branded marketplace or even portal advantages from a direct relationship with customers and doesn’t have to contend with offerings being marketed along with competitor offerings, as they will be in a hyperscaler marketplace setting. Making use of the CSP’s own platform enables the hardware to be bundled into such kind of offerings, thereby giving the opportunity in terms of greater potential footprint gains within the target verticals.
In contrast, leveraging the Hyperscaler marketplace goes ahead and offers a greatly expanded market reach within some fresh industries that already happen to have a concrete relationship with cloud service forums and may as well be less au fait while engaging with the networks directly. This avenue to market also goes on to  simplify the inherent complexity when it comes to exposing the APIs by enabling the CSPs to onboard novel services to a central aggregator, who goes on to manage the downstream access to the application.
Abstracting the intricacy
Significantly, the key to all of this is the way each CSP looks to manage exposure entirely. APIs are intricate and sort of messy to coordinate as well as monetize as they go ahead and form a blizzard of protocols that will become increasingly complex as the new APIs happen to be made available in the standards. Because of this reason, many CSPs happen to be looking to go ahead and transform their networks into service enablement platforms, which means creating a layer above the network that is dedicated to managing such APIs and also coordinating with external third-party applications. There happen to be many advantages to this approach; most significantly, it addresses the security issue. Opening up networks to external parties needs a significant shift within the mindset of CSPs, and security is indeed a significant as well as understandable concern.
Adding an abstraction layer on top of the NEF enables there to be a single security policy that gets applied consistently throughout all the APIs. It also helps in the use of a single protocol format and goes on to create a single point of access by way of one mapping engine for all the APIs. This enables the CSPs to apply rate limiting to the APIs, for instance, to prevent too many calls being made to certain APIs.
CSPs happen to be uniquely positioned so as to capitalize on network exposure by way of creatively monetizing exposed services through chargeable APIs. There are numerous choices available when it comes to considering how to charge for the usage of such APIs. Network exposure happens to provide an opportunity for the creation of certain innovative charging models. Modes of charging could go on to include a subscription model needing a recurring fee for the usage of a specific API, a revenue share model in which the CSP charges a certain percentage of an application item, or there could as well be a time-of-day model wherein the rates for use are surged during the predefined peak times. Alternatively, one might as well simply charge for the API calls that are made. Whatever the strategy, there happens to be significant monetization flexibility in terms of network exposure and how to make the same pay.
