The opportunity for, or value of, APIs that expose telecom service features to allow them to be used in composition of other perhaps-more-valuable services, has long been discussed. When Ericsson acquired Vonage, it was clear that the Vonage APIs were going to be a big part of any value redemption Ericsson could hope for. Well, Ericsson has written down a big chunk of its Vonage value, and formed a JV with some telcos and with Google to push network APIs. Now we hear rival Nokia is interested in offering another API option. What’s actually going to happen in this space?
The previous blog I referenced above notes that it’s insane to repeat the same actions over and over while expecting different outcomes. It follows that if Nokia doesn’t want to qualify for institutionalization, it needs to do something different with APIs. If you visit Nokia’s website and look for press releases that mention “API” you find a bunch of releases that relate to collaboration with an operator to leverage APIs to boost the value of 5G. You find one release with a bit more substance. The Network Exposure Platform release is the one that could define Nokia’s own approach. The release came out on June 11, 2024, which is before the Ericsson JV was announced, but since both Ericsson and Nokia hew to standards set by the GSMA Operator Platform, Linux Foundation CAMARA specs, and the TM Forum’s Open API specs, its fair to say the two approaches converge on the same goal set.
Standards are good, of course, but value is essential. Nobody adopts a useless standard, and conforming to one doesn’t earn vendors anything. While the set of standards I’ve summarized in the last paragraph aren’t useless, they are far short of being transformational, and in fact you can argue (which I shortly will) that they exacerbate, and hasten the criticality of, telco problems with profit.
The essential value of a network API is that it allows a higher software layer to exploit a network feature directly. The Linux Foundation’s CAMARA presentation has what I think is a critical quote: “From functional perspective the scope is limited to telco APIs, that means APIs in the domain of telco mobile networks, telco fixed line networks, telco edge cloud, etc. or supporting these.” This is standards-speak for “these APIs expose features of current network infrastructure and focus on making those features more useful to an ‘aggregator’, a provider of higher-layer service.” We’d probably recognize the largest category of aggregator as the MVNO.
This definition, IMHO, is at the core of the whole network API problem, and the core of the telco problem with return on infrastructure and stagnating capex. MVNO relationships rely on third parties who have either a special ability to sell to a niche, or who are a bulk buyer of telco services who can resell them to a price-sensitive community by taking over many of the operations roles from the telco. They are, in truth, last-ditch strategies to add some revenue without requiring telcos down-price their services to buyers who are already willing to pay retail for them.
Telco revenues are roughly set by the combination of their share of the total available market (TAM) times the average revenue per user (ARPU). The MVNO strategy increases the TAM share, but reduces ARPU, and to raise the TAM you need to lower prices. Finally, at some point, you hit the wall on TAM; every possible buyer is in the market. To get there, you’ve already committed to lower ARPU, so you’re stuck.
To get out of this mess, you need to sell something new, raising your ARPU, not facilitate a new channel of sales with lower ARPU. There is an opportunity to take some telco features, particularly OSS/BSS features, and sell them to an OTT player for use in operationalizing their own new services, but analysts including me generally say this is an opportunity worth less than ten billion total, in a global telco market that’s over a trillion dollars per year. I think it’s probably less than five billion, and I don’t think the profit margins on it are particularly good either.
Back in 2022, AT&T started to talk about what it called “facilitating services”. Some very clever AT&T service architects told me that these would include both elements of the current service set (the stuff the current API initiatives target) and new features that a telco could develop that would “facilitate” OTT service creation by taking advantage of a telco’s typically lower internal rate of return to invest in low-ROI service elements, reducing the OTT’s overall capex and first cost.
Unfortunately, those same clever service architects were a bit disillusioned by the end of 2023, because the focus of facilitating services had contracted to roughly the scope of the current API programs I’ve named above. Gone was the notion of building new facilitators; the Linux Foundation scope comment was in play. One of my contacts remarked bitterly that “You know how a group of people is braver in the dark, more so as the group gets larger? Well, a group of telcos is more fearful, and the fear increases as the size of the group increases.” Standardization, he said, killed innovation out of fear, not for technical reasons. I’ve been involved in several telco initiatives that aimed at innovation, and every one was stifled by collective conservatism.
It’s crazy to expend massive efforts to grab benefits that might increase your top line by five percent in total, when you probably need top-line growth of 5% annually to create the picture you want to paint for Wall Street. The original insightful vision of facilitating services was a potentially good idea, and the fact that telcos have backed away from it shows that they’re no more willing to plan to facilitate transformational services than they are to offer them directly. That may doom them to commoditization, because neither Ericsson’s nor Nokia’s API plans will prevent it.
The other challenge that operators themselves point out is one of return. Say you’re a telco and you like the idea of higher-level service facilitation. One path forward is to assign resources and investment to standardizing the requisite APIs, and hope that you’ve picked the right approach. Another is to sit on your hands and see if someone else takes the risk. If it pays out, you step in and implement those APIs. If it does not, you’ve made the smart choice. A majority of operators say that unless something emerged that offered them a real competitive benefit, they’d hang back.
The final issue is “regionalization”. The majority of the new service opportunities are wider in scope than any operator’s business. Thus, a retail partner really needs not only a standard but one that’s widely implemented, or they face launching something that can be sold only in selected pockets of their market area.
I think what I’m hearing points to a basic truth, which is that while it may be possible in theory to make facilitating APIs work, it will be very difficult in practice unless a vendor like Nokia or Ericsson steps up and takes the risk. I don’t know whether that’s going to happen because of the difficulty in promoting APIs that relate to new services rather than existing ones. 5G is the focus of telco and vendor API interest, and 5G has failed to meet almost all its past expectations. It will almost certainly miss the API ones, and that means that API initiatives are another flash in the pan.
