Ericsson Becomes an Aggregator and Throws Down the Gauntlet on Vendor API Strategy

Ericsson is leading a Joint Venture (JV) for a global network Application Programming Interface (API) platform that will service at least a dozen Communication Service Providers (CSPs). Ericsson has been leveraging its ownership of Communication Platform-as-a-Service (CPaaS) provider Vonage for advancements within the network API market. This is the latest instance of that strategy, as Ericsson integrates CPaaS and network API functionality, and teams with Vonage operator clients. Ericsson’s inclusion of Google Cloud in the deal is also noteworthy for expanding the reach of the developer ecosystems to Google’s millions of developers. The JV was instituted through the creation of a new, unnamed company, of which Ericsson will assume 50% ownership, while partners will make up the other half. The platform is built on Ericsson’s Vonage heritage, the Global Network Platform, with personnel shifting to the new company.

Network APIs have been around for nearly a decade. The technology has improved through more granular management in controlling network resources, such as network slices in 5G; however, vendors still need to overcome historic challenges with getting APIs to market. Key challenges include: finding an ecosystem of developers interested in network APIs based on new use cases, supporting the onboarding of developers who may be unfamiliar with network programming, and implementing a fair business model that compensates contributions among operators, vendors, and developers. So far, network API platforms by individual operators have proven incapable of overcoming these frictions to scale to a large developer ecosystem.

This is where a JV and aggregated API platform may provide an extra push in the right direction to support API implementation. The aggregation of individual operators’ network APIs into a shared platform improves the appeal and simplicity for both operators and developers. Operators may gain early momentum through partnerships, especially if they are late to the API movement and can still be placed on the level with advanced operators and learn from adjacent products on the platform. Operators will also no longer be required to build their own commercialized platform for their API, making this an optional step. The cardinal benefit is that developers will be able to build API-based applications in an operator-agnostic way, and they will not need to retool and re-platform the APIs across operators. This reflects the goals of the Open API initiative within a single platform. Network vendors will continue to take the lead in these aggregated platforms because: 1) their service is required for exposing the core network and integrating APIs; 2) the success of APIs will support business for their 5G Core products; and 3) they have deep familiarity with telco standards to oversee compliance. The partnership with CPaaS provides a jumpstart on communications use cases. CSPs and hyperscalers lack one or more of these qualities for platform leadership. ABI Research anticipates that network vendors will use aggregated API platforms as a vehicle for moving API implementation beyond its historic limitations.

The Ericsson-led Network API platform presents opportunities for CSPs and builds competitive pressure for rival network vendors to be decisive about API commercialization strategies. Competing network vendors may consider the following tactics:

• Differentiate through High-Value Use Cases: So far, commercial markets are building toward low-value use cases like device management, user network status, and communications. There remains significant market opportunity for high-value use cases like network slice management, which will develop alongside the transition to 5G Standalone (SA). High-value use cases will further support enterprise API business, where SA is more advanced, and which are outside the direct commercial focus of this global platform. The standardization of high-value APIs through CAMARA should speed API development here, allowing vendors to enhance API appeal for developer applications and gain market momentum.
• Service the Standardization of Network APIs for Aggregated Platforms: Not all operator APIs are conformant to standards, and as more operators join these aggregated platforms, there will be more demand for standardization. So far, the de facto client of the new platform has been existing Vonage customers, but there are no formal exclusions of non-Vonage or non-Ericsson customers to join, and Ericsson will host APIs built on non-Ericsson infrastructure. A wide wave of operators are expected to join the global platform—from Canadian to Chinese CSPs. Each of their APIs require alignment with platform standards. Alignment further requires familiarity with the network cores that will be exposed through the API. This presents an opportunity for vendors to support API alignment of their own products for those platforms. These services will not only be for the Ericsson API platform, but also for a handful of aggregated platforms expected to emerge in the future.
• Compete over Developer Outreach with Hyperscaler Strategy: A successful API market strategy comes down to reaching developers that can add top quality applications. The Ericsson JV reaches a bustling Google developer community, but it remains to be seen whether Ericsson and Google will provide sufficient appeal and support—financial and technical—for developers to do their job. There is room for network operators to open up their existing hyperscaler relationships to the API services and put their weight behind building a developer community. The top two most prominent telco hyperscalers, Amazon Web Services (AWS) and Microsoft Azure, are still unassociated with any major aggregated network-API platform.