![]() |
|||||||||
|
|||||||||
Global Standardization Activities Vol. 23, No. 4, pp. 43–46, Apr. 2025. https://doi.org/10.53829/ntr202504gls Latest Trends in Network API Standardization: GSMA Open Gateway and CAMARA ProjectAbstractThe CAMARA project, in collaboration with GSMA Open Gateway, aims to accelerate third-party service provider”Ēs access to telecommunication-operator-network functions by developing standardized, operator-agnostic application programming interface (API) specifications. This article provides an overview of the rationale behind this API standardization, partnership between the CAMARA project and GSMA Open Gateway, and unique characteristic and methodologies of the CAMARA project and outlines NTT”Ēs future work within the project. Keywords: network API, GSMA Open Gateway, CAMARA 1. GeneralCAMARA is an open-source project under the Linux Foundation that aims to develop standardized, operator-agnostic application programming interface (API) specifications. These APIs enable third-party service providers and application developers to access various operator network functions regardless of region, country, or network operator [1]. Operator network functions in this context include wireless quality of service, network authentication, and carrier billing, among others. While individual network operators have made efforts to provide APIs for accessing these functions, widespread adoption has been hindered due to variations in specifications. Although northbound APIs were standardized under the 3GPP (3rd Generation Partnership Project) for fourth-generation mobile communication network (4G) and 5G systems, their implementation by network operators seems limited. Additionally, application developers—primarily web developers—often face the challenge of requiring specialized knowledge to use these APIs effectively. To address these challenges, the CAMARA project focuses on lowering entry barriers for developers by creating simple, operator-agnostic APIs that do not demand extensive knowledge of operator networks. As of November 2024, the CAMARA project has over 400 participants, including network operators and vendors, with 31 API development projects underway. Active discussions are being held to design APIs that accommodate diverse use cases and business scenarios. 2. ScopeThe CAMARA project focuses on APIs that are exposed to API consumers, which include third-party service systems or applications running on client devices. This means that the scope does not cover the implementation of internal functional blocks or reference points within operator networks that provide these functionalities (see Fig. 1). The project’s approach emphasizes offering common APIs to these consumers. Regarding concrete implementations within operator networks, it enables each network operator to choose the most appropriate approach on the basis of its network configuration and development status. This flexibility is intended to facilitate broader adoption across operator networks.
3. Relationship with GSMA Open GatewayGSMA Open Gateway is an initiative within the GSMA (Global System for Mobile Communications Association) aimed at developing standardized, operator-agnostic APIs for telecommunication network functions. As of 2024, 62 mobile operators are participating in the initiative, working toward the global commercialization of these standardized APIs. The CAMARA project operates with the support of GSMA Open Gateway. While some API development efforts are independently launched by the CAMARA project, its primary focus is on defining detailed API specifications on the basis of use cases and service requirements provided by GSMA Open Gateway [2]. GSMA Open Gateway has been actively promoted at events such as the Mobile World Congress, and its activities are expected to expand as more network operators and vendors join the initiative. Consequently, the outputs of the CAMARA project, which provide detailed specifications for the standardized APIs proposed by GSMA Open Gateway, are expected to see widespread adoption. As of November 2024, several APIs that were initially released have already been implemented and are in commercial use across several countries [3]. 4. CharacteristicsThe CAMARA project operates as an open-source project, primarily managing and discussing API specification documents on GitHub*. Face-to-face meetings are not typically held, with regular online meetings serving as a supplement to address issues that cannot be resolved through GitHub Issues or Pull Requests. In cases of disagreement, decisions are made either by majority vote or at the discretion of the Sub Project lead. This approach contrasts sharply with traditional de jure standardization processes, which typically involve formal decision-making protocols and aim for unanimous agreement during meetings. Nevertheless, the CAMARA project also exhibits characteristics of a standardization organization, such as appointing a project lead to mediate each Sub Project, establishing clearly defined roles (e.g., reviewers with decision-making authority and general contributors), and codifying these practices. These efforts help ensure the development of API specifications that are widely adopted.
5. Project structureThe CAMARA project is organized into the Governing Board/Technical Steering Committee, several Working Groups, and Sub Projects. Working Groups are responsible for activities not tied to specific APIs, such as accepting API proposals, managing releases, and coordinating API specification guidelines. Sub Projects are responsible for developing individual API specifications. When a new API proposal is submitted, it is first discussed in the API Backlog Working Group, where the proposal’s content is reviewed. The Technical Steering Committee then decides whether to initiate API development and either selects the appropriate existing Sub Project or creates a new Sub Project if none are suitable (see Fig. 2). Taking into account Sub Projects’ frequent establishment and refinement of the API specification guidelines, the project’s activities continue to expand, reflecting its growing momentum.
6. Release processEach API specification developed in the Sub Projects is written in the OpenAPI format and managed as a YAML file, a data format used to serialize structured data and objects into strings. These YAML files are stored in a GitHub repository assigned to each Sub Project. The API specifications undergo a pre-release period, during which no operational guarantees are provided. Once the documentation is finalized and bugs are fixed, the YAML file containing the API specification, along with related documentation, is released as a public release. Semantic versioning is applied to the version numbers of each API. The initial public release is published as v0.y.z, indicating the first public API, and when it is deemed stable enough for commercial use, it is updated to v1.0.0 as the stable public API. For versions v1.0.0 and above, backward compatibility is guaranteed unless explicitly stated otherwise. The CAMARA project also issues a meta-release of the set of publicly released APIs every six months, with the first meta-release held in September 2024. 7. Future workNTT laboratories believe that the network APIs developed under the CAMARA project play a crucial role in expanding the use of operator network functions by third-party service providers and application developers. Therefore, we have been participating in meetings and staying up-to-date with developments in the CAMARA project since 2024. The WebRTC Sub Project is working on an API that enables Web Real-Time Communication (WebRTC) browsers to make and receive voice calls through IMS (Internet Protocol Multimedia Subsystem). This API is regarded as a key solution for enabling network operators to broadly deploy WebRTC services. It is significant not only because of its potential to facilitate voice calls but also because it may eventually extend to next-generation real-time communication using immersive media. From a standardization perspective, this Sub Project is particularly noteworthy, as it aims to establish a signaling specification for WebRTC session control that has not been specified by the IETF (Internet Engineering Task Force) or W3C (World Wide Web Consortium). We intend to contribute to the standardization of these APIs by leveraging our expertise as a telecommunication network operator. References
|