MWC 2023: Camara Project and Open Gateway details are revealed but no answers about commercial models
"Network-as-a-service API collaboration projects are underway and operators should stay informed about progress."
This is the first of two articles on operator API initiatives. This article provides a summary of the different APIs and the model. The second article, Aligning different interests is essential to the success of the Camara Project and Open Gateway initiative, provides our analysis of the announcements.
The GSMA used Mobile World Congress 2023 (MWC 2023) to announce that its Open Gateway initiative had the support of 21 operators (since increased to 23 operators), representing 45% of global connections. The Open Gateway initiative is an open-source project that seeks to develop network-as-a-service 5G application programming interfaces (NaaS 5G APIs), allowing developers (directly or through hyperscalers, such as AWS) to access network functionality beyond that which is currently available. Open Gateway is designed to ensure easy network access for developers worldwide, without the developers needing to know how the network functions and regardless of the network implementation.
The Open Gateway initiative works within the Camara Project framework announced at MWC22, run by Linux Foundation. CAMARA is a global 5G API alliance between 40 operators and 35 other partners, which is designed to ensure the standardisation of APIs across networks, simplifying cross-network integration accessible through GitHub. The API documents are available in multiple coding languages including C#, Go, JavaScipt and Python.
CAMARA will host all the open-source APIs developed by Open Gateway, and other API projects will align with CAMARA
CAMARA has announced that it is working on 11 APIs,1 and Open Gateway has announced it is working on eight (Figure 1). Six of the eight Open Gateway APIs are a subset of the 11 CAMARA APIs. Two of the eight Open Gateway projects are similar to, or extensions of, projects listed on Camara’s website: Open Gateways’ Edge API expresses intent to include routing capacities (in the future), and Open Gateway has explicitly stated that number verification SMS 2FA is a separate API to number nerification.
Figure 1: APIs being developed under the Camara Project
| API name | Camara Project | Open Gateway | Summary | Use case | ||
| Carrier billing check-out | Yes | No | Consumers can make e-commerce purchases with the payment amount added to their bill or deducted from their prepaid balance. | Mobile payments. Payment systems. | ||
| Device identifier | Yes | Yes | Identifes what device is being used. | Security. | ||
| Device location | Yes | Yes | Identifies the location of the device. | Fraud prevention. Retail marketing. Asset tracking. | ||
| Device status | Yes | No | Consumer can request to prioritise traffic to a specific device on their home network. | Fraud prevention. IoT connectivity/ roaming monitoring. | ||
| Edge cloud | Yes | No | API to capture, store and manage privacy data as compliant with regulations (e.g. GDPR). | All edge cloud uses. | ||
| Home devices QoD | Yes | Yes | Consumer can request to prioritise traffic to a specific device on their home network. | Home working. Home entertainment. | ||
| Identity and consent management | Yes | No | API to capture, store and manage privacy data as compliant with regulations (e.g. GDPR). | Security and data management. | ||
| Number verification | Yes | Yes | Verifies the phone number connected to the device, the operator will confirm if successful or unsuccessful. This API has an active website: www.numberverify.org | App onboarding. App logins. Password resets. Fraud prevention. On boarding to digital services. Account management. | ||
| OTP validation | Yes | No | One-time password user authorisation for security. | Fraud prevention. | ||
| Quality on demand | Yes | Yes | Request and set a specific level of quality for connections (e.g. latency, jitter). | Automation. Live-steaming media. | ||
| SIM swap | Yes | Yes | Data tracking of any SIM pairing change associated with the user's mobile account. | Fraud prevention. | ||
| Edge site and routing | No | Yes | Similar to the CAMARA API, except it goes beyond edge discovery to edge routing although that is not in scope at present. | All edge cloud uses. | ||
| Number verification (SMS 2FA) | No | Yes | Delivers short-code messages via SMS to mobile devices. Future iterations may facilitate other channels. | On-boarding digital transactions. Account management. |
The CAMARA framework applies to 5G networks. It does not stipulate whether the APIs should exist within the 5G standalone (5G SA) or non-standalone (5G NSA) network. Which network the API is built upon will depend on the API; for example, the quality-on-demand (QoD) API is supported by the 5G SA network.
Other initiatives to develop APIs for telecoms operators include those developed by the European Telecommunications Standards Institute (ETSI) under its multi-access edge computing (MEC) API programme. ETSI’s MEC APIs will align with the Open Gateway and CAMARA frameworks.
Routes to market have been established, but a common pricing strategy has not been agreed
Telefónica demonstrated three NaaS 5G APIs at MWC 2023: quality on demand, carrier billing and device location, all of which are currently on trial. These demonstrations showcased six business use cases across six companies that are NaaS API customers and are developing use cases for the technology. Telefónica emphasised the ease of integrating the carrier billing API; Kanto Living App (available on Telefónica’s Movistar Plus+) adopted the API within 5 working days. Telefónica is seeking sign-ups for its early adopter programme to trial the APIs.
The APIs will be sold through three routes.
- Direct from the network owner that sells its own APIs.
- Using a single operator for API roaming (that is, the service offered by a second operator is sold through a primary operator).
- Direct from an aggregator such as a hyperscaler (for example, AWS Marketplace), or an application-to-person (A2P) messaging vendor (for example, Infobip, Twilio, Vonage), which collate the offerings of two or more operators and potentially other types of service – AWS with AWS capabilities, Vonage with other A2P services. This is more appropriate for customers who do not want to manage relationships with multiple operators, or customers who want more than just network APIs.
There is no common strategy for selling these APIs via the various routes, so operators are able to differentiate themselves via their business model. However, potential charging strategies include the following:
- time-based charging, which could be used for quality-on-demand (QoD) APIs, for example
- pay for access for over a given period (for example, unlimited number of API calls in a 24-hour period) – could be used for logging into a mobile application
- a tiered system, in which premium customers have prioritised access to network capabilities (for example, QoD API for viewing extended reality (for example, virtual or augmented reality) medical scans could be prioritised over QoD API for recording a children’s football match
- revenue-sharing may be appropriate for the carrier billing check-out API
- pay per 24-hour period for the SMS 2FA number verification (similar to the WhatsApp business messaging)
- pay per change in routing site may be appropriate for the edge site and routing API
- home device QoD API could be charged as an add-on service to the end-user.
The CAMARA and Open Gateway initiatives offer an attempt to monetise the network via network-as-a-service capabilities. Multiple APIs are currently in development, but the pricing models are yet to be determined. Further questions must yet be answered about the consumer demand for these APIs as well as those about managing competing, and sometimes opposing, interests of key stakeholders such as operators, hyperscalers and A2P vendors.