From CPaaS to a global network API platform, enabling CSPs to monetize on 5G
Over the past two decades, web and telecommunications technologies have diverged significantly. While web technologies have democratized innovation, telco technologies remain complex and inaccessible. To harness the full potential of 5G, the telecommunications community must act to democratize new capabilities and make them globally accessible.
The history
Over the past two decades, the trajectories of web and telecommunications technologies have diverged significantly. The remarkable innovations within the web have given rise to an unprecedented surge of novel ideas, concepts, and entrepreneurial ventures. This surge is attributed to the intrinsic democratization of web technologies (like HTML, HTTP, Rest, and Java Script), characterized by their global accessibility, openness, and user-friendliness, making them easily adoptable even by high school students. Additionally, using open web models and related technologies offers immediate global outreach, enabling a customer base that transcends geographical boundaries.
The telco industry's widespread success and global impact have facilitated the worldwide adoption of mobile telephony (voice, SMS, and MBB), connecting over 8 billion people and contributing to the global expansion of the Internet. Communications Platform as a Service (CPaaS) technology has been effectively used by companies to enable web developers to send SMS messages and initiate voice calls using just a few lines of code. While the first SMS was sent in 1992, the widespread adoption of SMS APIs (Application Programming Interfaces) began in the mid to late 2010s when CPaaS took off. As an industry, we cannot afford to wait any longer for network APIs to reach the desired scale. Our ambition is to democratize all new 5G capabilities rapidly, and this calls for action by the whole telecommunications community.
New telco technologies are currently the opposite of web technologies, making it challenging for developers to use advanced 5G features beyond plain mobile broadband (MBB) connectivity. Such technologies are complex, not easily accessible, and lack global conformity. Imagine a scenario where a brilliant new idea set to be introduced to society requires functionalities provided by a 5G network. Finding skilled developers capable of utilizing the 5G technology poses a substantial challenge. Even if these developers can be identified, the integration works with hundreds of service providers worldwide, and maintaining the solution becomes a complex and resource-intensive task, which requires technical integration and the establishment of individual commercial relationships with each service provider.
The reasons behind CSPs’ earlier failures to expose network functions are several, but one can be attributed to the absence of globally accessible uniform APIs making it easy for applications developers to use the CSPs' network capabilities. Application service providers (ASPs) and developers prefer to use APIs that work seamlessly across all CSP networks, ensuring that their customers are connected without any issues.
APIs offered by only a limited number of CSPs are less useful and will limit the scale, especially in the B2B2C model, which is the standard CPaaS “any-to-any” model where the API user and the target user are not the same nor managed by the same enterprise (B2B model). In interactions with ASPs, we have seen that interest significantly increases when an API covers more than 70% of subscribers within a specific country.
Furthermore, having ubiquitous exposure across most CSPs is not enough. Even if all CSPs offered the same API, applications would still face the complex task of technical integration with each service provider and establishing separate commercial relationships with them. This represents a challenge for any business, given the vast number of CSPs worldwide, numbering in the hundreds. Therefore, for most applications, this complexity poses a significant barrier to success.
As illustrated above, the CSP API ecosystem experiences a significant simplification when an aggregator is introduced into the value chain. This aggregator takes on the responsibility of centralizing and simplifying both technical and commercial relationships between CSPs and ASPs.
Vision and mission
The idea behind a global network API platform is to redefine how the telecom industry can deliver and capture value. The network provides advanced and differentiated capabilities – such as speed, bounded latency, differentiated connectivity, location, authentication, device information, and many other values, which developers can use to create new, emerging, and unidentified applications.
A global network API platform will make the network capabilities easily accessible through aggregation for a broad ecosystem of millions of developers and enterprises to build their services. They won’t need to understand the technical workings of a network, but they can use its underlying capabilities and pay for them in a dynamic and flexible way. This will be open and embrace a truly multi-vendor ecosystem in which any network vendor, CSP, and network platform provider can take part.
The vision is to collaborate with CSPs to create a leading global communication and network API platform for open innovation on 5G and beyond, enabling the development of the next wave of premium communication experiences.
The network API business is still in its early stages and faces the typical "chicken and egg" problem associated with the two-sided business models. Without CSPs offering new APIs, it is challenging to create demand among developers and enterprises for APIs that do not yet exist. Conversely, if there is no demand for new network APIs, CSPs are reluctant to invest in making them available.
Ericsson has joined forces with global telecom leaders to redefine the industry with network APIs. Together with like-minded CSPs and other industry partners, we are engaging with early adopters of these network APIs – the developers. The developers are the primary decision- makers in the API industry. They will not only innovate and create new use cases with new network APIs, but they will also offer valuable feedback to the CSPs.
From communication APIs to network APIs
CPaaS focuses on communication services like SMS, voice, and video, while network APIs provide services such as quality on demand (QoD), slicing, location, network insights, and device information. However, these are closely related, and the transition from today’s CPaaS to a global network API platform is expected to be more of an evolutionary process. This will involve CSPs combing communication and network APIs in a collaborative effort to engage developers and enterprises.
Firstly, the similarities are apparent in the double-sided business models. In both cases, we have hundreds of CSPs on one side who need to expose their capabilities and hundreds of thousands of ASPs on the other side who need easy access to these capabilities through an aggregator. Easy access is not only about simplifying technical integration. The aggregator needs to provide unified APIs, unified service level agreements (SLAs), pricing, contracts, and customer support to the ASPs in both CPaaS and a global network API platform.
Secondly, developer outreach is paramount for both CPaaS and a global network API platform. Developers are the driving force of innovation, and both network APIs and communication APIs must be offered with a developer-first mindset. Furthermore, the APIs on their own are not enough; they need to be complemented by user friendly documentation, software development kits (SDK), coding samples, developer tools, and community support to be truly effective. Communications APIs in CPaaS began to scale when millions of developers gained easy access to them and started to create innovative use cases, such as SMS 2FA (two-factor authorization). The same is true for network APIs.
Finally, communication APIs and network APIs are synergistic, meaning that they can complement and be combined in different models. For example, QoD network APIs can be used with video communication APIs, and it is fair to assume they will often be consumed together. For instance, a premium video API could include video communication capabilities that incorporate different levels of QoD to ensure the desired video communication experience. Moreover, various location and device information network APIs can be bundled with SMS and voice communication APIs in anti-fraud solutions.
However, there is one major difference between these types of APIs that requires special attention. For communication APIs, the CSPs themselves never changed their existing business models; they only exposed capabilities. In contrast to network APIs, the CSPs, in addition to exposure, will need to adopt performance-based models to fully unlock the potential of differentiated connectivity business.
Network APIs and performance- based business models
The CSP business model has transformed with the evolution of mobile services. Consumers once paid for voice calls per minute and messaging per message, and today mobile broadband (MBB) subscriptions based on fixed data buckets is the dominant model. Yet another evolution is needed for CSPs to be able to fully monetize the investments they have made in the networks.
Performance-based offerings are different from today’s one-size-fits-all best-effort MBB offerings. With performance-based business models, CSPs can find a sweet spot for delivering the appropriate performance at a suitable cost and price, catering to the diverse needs of consumers and enterprises.
The industry's best practice will involve discrete and finite performance levels. This is enabled through a set of different charging models, such as a generic connectivity subscription bundled with applications, embedded in the application offering, complementing the MBB charging model, or offered as a one-time performance differentiation for applied dynamicity.
Differentiated connectivity will be offered both as subscriptions and for one-time consumption; where differentiated performance is required for a limited period and is applicable for both consumers and enterprises in B2B and B2B2C models. The more CSPs adopt a performance-based model, the more an open global network API platform will be able to orchestrate and harmonize differentiated performance for the ASPs on a global scale, playing its part in helping CSPs with API-driven network monetization.
The ecosystem
The success of an open and global network API platform requires close collaboration with all CSPs and vendor technologies. It needs to work with standard APIs and standard products such as radio, core, or business support systems (BSS). The network API market will not take off unless it is a fully open market with multiple actors in the ecosystem. ASPs and developers need APIs that cover all CSPs and are completely independent of the underlying CSPs and their equipment vendors.
We believe that the Camara and Open Gateway initiatives are key to the telco mission of exposing network APIs. Developers and ASPs cannot work with too many variations in exposed APIs, and uniform behavior is key to success. Of course, an aggregated global network API platform will need capabilities to abstract the differences between CSPs' implementations and handle conversions of non-Camara APIs to Camara. But this is not optimal. Some Camara APIs will not support backward compatibility, and not all non- Camara APIs will map onto Camara APIs in a meaningful way. Therefore, at times, it will be difficult to get developers excited about network APIs that behave differently in different CSPs' networks. The more CSPs follow Camara and Open Gateway, the faster network APIs will scale and provide significant monetization to CSPs.
Conclusion
The journey from CPaaS and communication APIs to a global network API platform is just beginning. The CSP monetization opportunities for network APIs are in the nascent stage today, but by 2030, they will make significant leaps to reach the CPaaS potential and will at some point surpass it. Ericsson has made significant investments in this area and will take the lead to materialize the vision with a global network API platform. A single organization cannot achieve this on its own; instead, vendors and CSPs must collaborate to establish an ecosystem that can effectively scale network APIs for substantial monetization. CSPs need to embrace Camara, TMF, and Open Gateway and begin implementing performance-based business models to unlock the full potential of 5G and APIs-based monetization.