Network APIs: Driving new revenue streams for telcos

Network APIs promise new revenues for telcos

Since 2020 there has been a resurgent interest in applications interfacing with the network they run over. The exponential increase in the number of connected devices and complex traffic, particularly video, is exerting pressure on network resources. Applications must become more aware of network and edge compute resource availability to meet increasingly stringent customer requirements as well as energy efficiency targets – for example, by prioritising critical applications. MEC allows data to be collected and processed closer to the customer (more information on edge computing is available on our Edge hub).

STL Partners forecasts the revenue opportunity created by mobile network APIs to reach over $20 billion by 2028 (the full version of this report provides a breakdown of the opportunity for the top 11 network APIs), as well as enabling powerful new applications that leverage programmable, cloud-native networks.

Increased network programmability will enable developers to build applications that require guaranteed connection speed and bandwidth, giving users/providers the option to pay a premium for network resource when and where they need it. The network APIs fuelling this market fall into two broad categories:

  • Network information APIs: Basic network APIs that provide real-time information about the network will reach extremely high volumes over the next decade. These will gradually be consolidated into the core network offering as a hygiene factor for all operators. Examples include network performance (information only), hyper-precise location, real-time device status, etc.
  • Network configuration APIs: APIs that instruct the network will not reach the same volume of usage, instead offering a premium service to a smaller pool of users wanting to define their network environment. Examples of these APIs include quality-of-service on-demand, slice configuration and device onboarding. These APIs offer a longer-term monetisation opportunity for operators, although there is little visibility around what developers and enterprise will pay for these services (e.g., pay per use vs. monthly subscription, etc.).

In this report, we explore the work that is currently happening to develop network APIs from a technical and commercial point of view, surveying the telecoms industry consortia that are proactively building the technical and commercial tools to make network-as-a-service a revenue-driving success.

Enter your details below to download an extract of the report

Two API domains: The macro network and MEC

MEC APIs control both the compute and networking elements at the edge. In the instance that a telco is operating and managing the edge site, these APIs come under their remit. In some instances, however, the MEC APIs could be defining edge or cloud compute not operated by the telco. Therefore, we do not consider all MEC APIs to come under the umbrella of network APIs (See figure below).

MEC APIs vs. Network APIs

Source: STL Partners

A MEC API is a set of programming interfaces that allow developers to access and utilize the resources of mobile edge computing platforms. These resources include computing power, storage, and network connectivity, and can be used to run applications, services, and tasks at the edge of the network, closer to the end users. MEC APIs can provide a way to offload workloads from the cloud to the edge, reducing latency and improving the performance of applications and services. CSPs must make a strategic decision on where to focus their development: general network APIs (quality-on-demand, location, etc.) or MEC APIs (edge node discovery, intent-based workload placement, etc.).

Need for reliable, real-time connectivity across a wide area will drive demand

Based on our interviews with application developers, we developed a framework to assess the types of use cases network APIs are best suited to enable. This framework sets out the network API opportunity across two dimensions:

  • The geographic nature of the use case: Local area vs. wide-area use cases. This influences the type of edge that is likely to be used, with local-area use cases leveraging the on-premiseedge and wide-area use cases better suited to the network edge.
  • Need for real-time vs. non-real time insight and response: This depends on the mission criticality of the use case or the need from the application point of view to be dynamic (i.e., adapt to changing circumstances to maintain a consistent or enhanced customer experience).

As network operators, telcos’ primary value-add is the ability to provide quality connectivity. Application developers leverage awareness of the network throughout their development process, and the ability to define the network environment enables use cases which require constant, ultra-reliable connectivity (see figure below).

Importance of connectivity features for developers

Source: STL Partners Survey (December 2022), n=101

Table of Contents

  • Executive Summary
  • Network APIs promise new revenues for telcos
    • Two API domains: The macro network and MEC
    • Need for reliable, real-time connectivity across a wide area will drive demand
    • Layers of API needed to translate network complexity into valuable network functions
    • Cross-telco collaboration and engagement of developers
    • Each industry fora focuses on specific layers of the API value chain
  • Operators must leverage multiple distribution channels for network APIs
    • Failure to standardise quickly allows other distribution channels to achieve greater scale
    • Operators must engage the developer community to play an aggregator role
  • Challenges and barriers: What needs to change
  • Conclusion
  • Appendix
    • Understanding the fundamentals of APIs
    • What are network APIs and what has changed?

Related research

Enter your details below to download an extract of the report

Personal Data 2.0: Industry fails Carrier IQ test

The debacle with Sprint, AT&T and T-Mobile US over Carrier IQ’s phone monitoring software highlights the pitfalls and opportunities of recording user behaviour, controlling mobile broadband networks and working with personal data – a key enabler of the new digital economy and new telco business models. This is our analysis of the issues and key lessons. (December 2011, Executive Briefing Service)

Carrier IQ Smartphone Eye image Dec 2011 Telco 2.0

Read in Full (Members only)   To Subscribe click here

Below is an extract from the 15 page Telco 2.0 Report that can be downloaded in full in PDF format by members of the Telco 2.0 Executive Briefing service here. Non-members can subscribe here or for other enquiries, please email contact@telco2.net / call +44 (0) 207 247 5003.

To share this article easily, please click:



Introduction

Telco 2.0 were talking to the World Economic Forum’s Re-thinking Personal Data project team – discussing the new white paper coming out for Davos which is all about putting the user in control of their personal data to unleash a new wave of innovation around this emerging asset – when we heard about the debacle with Carrier IQ.

Carrier IQ is a company which has reportedly been behind “invasive” software installed on some mobile phones, notably Android smartphones supplied by Sprint, AT&T and T-Mobile in the US. A widely-seen video by researcher Travis Eckhart shows the software apparently capturing keystrokes, website details and SMS’s sent and received on his device.

Travis Eckhardt’s YouTube Video of Carrier IQ

NB Please see our User Data and Privacy research category for further analysis.

The story so far

A festival of finger-pointing

Device vendors and operators around the world have been issuing statements of clarification or denial about their use of similar capabilities – although the careful wording of many press releases hints at the complexity of unravelling what is really in today’s smartphone software, who agreed to install it – and exactly how it is configured and used.

After a false start in which Carrier IQ (CIQ) tried to suppress some of Eckhart’s early findings with an injunction, it has belatedly embarked on a PR charm-offensive to salvage its reputation. We have also seen some more measured and probing analysis of the offending software’s capabilities, after a few days of shrill – and somewhat unfair – rhetoric.

What is known is that the company has embedded its products on around 150m shipped devices, although with wide variations in actual implementation and usage. It seems that most but not all of these devices have been smartphones, sold through operator channels as tailored variants rather than “vanilla” open-retail versions. In general, the software is intended to “improve the customer experience”, by reporting to the operator on various parameters, such as network coverage, failed connections and – most controversially – the user’s behaviour and application usage. Theoretically, this type of monitoring should help the operators fix holes in their networks, or diagnose other problems when the customer calls in for support. Other benefits are possible too – watching which applications are active can help identify which are hogging battery power, for example.

(It should be noted that this on-device monitoring concept is not new – a now-defunct company called IntuWave had a broadly similar solution for Symbian handsets as far back as 2003, while Nokia’s own “360” function also monitors user behaviour of its phones, but with permission. Apple has various reporting functions on its devices, but typically with user opt-out. It is also widely suspected that various security agencies have some smartphone surveillance capabilities).

The problem is that there is a fine line between “monitoring”, “diagnosis” and “surveillance”. The semantics tend to reflect the knowledge and permission of the user, as to what data is being collected and when, and for whom. There is also a distinction between collecting information, transmitting it, storing it and actually “mining” it – and whether it is anonymised or not.

In general, the installation of CIQ has been at the behest of specific operators customising phones sold to their subscribers – typically part of the software “stack” that might also include various additional apps or functionalities. The telcos tell their device suppliers to install the software either at the factory or further down the distribution chain and define “profiles” about what information they want to receive and when. A good analysis of the architecture is given by security analyst Dan Rosenberg .

A selection of previous industry data gaffes

Monitoring of user data is not an issue confined to handsets either – use of Deep Packet Inspection (DPI) capabilities for various use-cases in telco networks has been so controversial that some vendors now use euphemisms instead. The 3GPP standards body has now re-grouped and re-branded various policy and control technologies as the more benign-sounding “traffic detection function” (TDF). Various analytic solutions also exist for operators’ BSS/OSS systems – Telco 2.0 has long discussed the valuable information on subscribers collected by telcos, as well as the huge privacy issues surrounding its exploitation.

The recent Dutch implementation of some of the most draconian Net Neutrality laws in the world stemmed not from fears about the “purity” of the Internet, or even competition issues – but instead because the Dutch people resented the use of DPI to watch (and charge for) different applications in their Internet access data stream. It was the perceived invasion of privacy by KPN – perpetrated on one of the world’s most libertarian-minded populations – that was the trigger for discord. Previously telcos have fallen foul of similar concerns with the use of the notorious Phorm platform, used to deliver advertising based on an ISPs’ observations of their users’ web browsing behaviour.

What does Carrier IQ technically do that’s worrying?

It’s important to understand what people are actually objecting to about CIQ. No-one’s demonstrated that it sends back key-logger information. But they have demonstrated that it keeps everything it collects in a plain text file on the device in user-space. This means that any other application on the device can both read and write to it – and this is potentially very worrying, as explained in Appendix 1: An explanation of the technical risks.

Why the Carrier IQ issue has ‘blown up’

Although arguably exaggerated, several unfortunate issues have compounded each other in this case, to raise the current CIQ debate to public prominence and outrage:

Carrier IQ’s mistakes

While it is possible to feel a degree of sympathy with the embattled people at Carrier IQ, who were ostensibly just providing a service the operators had asked for, we believe they have made two key errors:

  • Carrier IQ’s initial response to their accuser was unnecessarily litigious – and Eckhart’s involvement of the Electronic Frontier Foundation guaranteed a much wider audience than might have otherwise occurred. Too many techno-illiterate lawyers under-estimate the power of blogs, Twitter and social media to bring issues such as this to wide awareness in a matter of hours.
  • The implementation of the software (on the Android phone in the now-infamous video) seems to be collecting far too much data for the purpose the operator seems to need. Even if the unnecessary data is just collected and then discarded, its initial all-encompassing capture looks both suspicious and poorly-conceived in terms of software security best-practice. (For instance, a cache of the logged data could be a goldmine for a handset thief, even if it doesn’t get sent to the operator).

Operators’ mistakes

  • Various operators have been using Carrier IQ (or equivalents) without clearly telling their customers what they were doing. A vague mention of “collecting data” in the fine-print of the terms and conditions is not enough.

Paranoia feeds the Media

  • Various journalists and bloggers seem to have sensationalised the story without full understanding of what the CIQ software was actually doing.
  • In these days of editorial and journalistic cut-backs, the mainstream media can be tempted to run with ‘scary’ tech stories based on stories getting attention online and via Twitter, and in timescales which make it hard to verify or unravel the technical twists and turns of complex stories.
  • Many consumers don’t read past the headline, and those that do may only read the first paragraph of an article, so any caveats or explanations that are actually carried in the detail are often lost.

The “fog of war”, industry panic and opportunism

  • The “fog of war” in terms of Carrier IQ rumours over the last few days has brought many operators and device vendors to deny publicly any involvement in using the technology. This can be seen as both a defensive response about a perceived risk to Xmas-season sales – but also as an opportunistic offensive move against some operators / vendors that are more directly embroiled in the “scandal”.
  • Android devices have software from multiple sources and in multiple layers – from Google, the handset vendor (e.g. Samsung, HTC) adding their own tweaks, operators adding customisations such as Carrier IQ or other elements and so forth. It can be difficult to work out exactly who is responsible for what functionality – hence some public statements from Carrier IQ executives expressing bemusement about the extent of data collected in this instance. (There is a suggestion that the “debug mode” of the software was the problem, not the normal usage mode). Generally, Apple and BlackBerry devices are more homogenous, although both companies do slightly-altered variants for favoured operator customers.

Result = Industry Failure

The net result is that the Carrier IQ brand is now seen as “toxic” in the eyes of many in the industry, irrespective of the benefits that some of its capabilities bring.

More worrying perhaps has been the inability of the industry as a whole to deal with these issues without panicking and resorting to a playground farce of finger-pointing.

It is at best careless, and in some cases illegal to treat personal data without appropriate care, protection and respect. But it is downright irresponsible to collectively risk the chance to develop a useful, legitimate and valuable ‘Personal Information Economy’ (PIE), which would benefit consumers, telcos, and other players alike, for the sake of some relatively minor corporate tit-for-tat in the media.

This is why we think our research on this topic, and the work we’ve been contributing to at the World Economic Forum on ‘Rethinking Personal Data’ is so important, and why consumer groups, telcos and other industry players need to get fully engaged to develop and adopt workable principles and practices on personal data.

Winners and Losers

In terms of losers, the obvious one is Carrier IQ itself, which seems to have made several poor decisions and has been overwhelmed by events – even if it has been unfortunate in the manner that everything has blown up, perhaps beyond the level which is truly proportionate.

Certain operators (notably Sprint) are likely to be doing some serious back-pedalling here. Samsung and HTC, as leading Android vendors have some questions to answer, but are likely to pass the buck to the operators and Carrier IQ itself. Huawei is also an (announced) user of Carrier IQ, notably for its mobile broadband devices such as USB dongles. The press release from February 2011 shows a strong awareness of privacy issues, as well as the notion of opt-in from individual users. Given the company’s troubles in getting its network products accepted by security authorities in the US in particular, this association might be problematic.

One beneficiary of this is likely to be Apple. Apple knows that it “owns” the whole software stack, so does not need to get embroiled in ‘finger pointing’ such as is going on between operators, Samsung, HTC and Carrier IQ. Apple is also not keen on customising the software stack for operators, and his episode will give it another excuse to push back against operators which want to be able to perform customisation.

BlackBerry is perhaps in the same situation, while Nokia/Microsoft are in a good position to take the moral high ground as well. (All this assumes, of course, that they don’t also have privacy skeletons in their closets – although both Apple and Google have dealt with such issues – much better – in the past).

To read the note in full, including the following additional analysis…

  • What should Telcos and others do?
  • Putting the user in control of their data – the World Economic Forum (WEF) guidelines
  • Dos and Don’ts of implementing software that use personal data
  • How to address and respect privacy concerns
  • Managing personal data across the business
  • Using ‘Intelligent Software’
  • An explanation of the technical risks

Members of the Telco 2.0 Executive Briefing Subscription Service can download the full 15 page report in PDF format here. Non-Members, please subscribe here or please email contact@telco2.net / call +44 (0) 207 247 5003.

Organisations, people and products referenced: 3GPP, Android, Apple, AT&T, BlackBerry, Carrier IQ, Electronic Frontier Foundation, Facebook, Google, HTC, Huawei, IntuWave, KPN, Microsoft, New Digital Economics, Nokia, Onavo, Openet, Phorm, Samsung, Sprint, Symbian, T-Mobile, Travis Eckhart, World Economic Forum (WEF).

Technologies and industry terms referenced: analytics, Deep Packet Inspection (DPI), Net Neutrality, personal data, smartphones, SMS, traffic detection function (TDF), WiFi.