The Story Behind SDG OpenCAPIF

ETSI has recently announced the new Software Development Group OpenCAPIF, which will have their kickoff meeting on January 18th, 2024, at Telefónica HQ in Madrid. This first blog post is here to share the story behind OpenCAPIF.

Our story begins in 2020, with the H2020-ICT-41-2020 innovation call. One especific challenge for this call was “Software networks provide high flexibility through implementation of virtual network functions (VNFs). VNF’s may be chained across several domains to create Network Applications (NetApps) tailored to the requirements of specific tenants, as demonstrated under previous 5G PPP phases. This requires open platforms that provide access to networks resources which can then be used to develop NetApps supporting requirements and developments from specific vertical sectors.”

Europe was calling to deliver Open Platforms allowing to develop Network Applications and project Evolved5G addressed this challenge by developing the tools allowing SMEs (well, in fact, any type of company) to create Apps that can use the Network Resources through APIs. When thinking about APIs and Networks, you need to turn to 3GPP SA6 Working Group which is taking care of “Application Enablement and Critical Communication Applications”. SA6 WG has specified a number of concepts since 3GPP Release 15.

SEAL (Service Enabler Architecture Layer) provides an abstraction of common resources for multiple verticals, e.g. Group (of UEs) Management, Location Management, … VAL is the Vertical Application Layer on top of SEAL that creates the solutions for a specific vertical industry, e.g. V2X. The EDGEAPP framework enables Applications to be deployed at Edge locations in 3GPP networks addressing problems such as Discovery or Service continuity when moving between Edge locations. All these layers have their own APIs specified in 3GPP Technical Specifications and made available under the 3GPP GitLab repository.

SA6 WG realized soon that managing all these APIs, especially in an environment where developers are creating Applications, will also require a management layer that enforces the strong security policies defined by SA3 WG (e.g., Mutual TLS Authentication).

This is where CAPIF comes to the picture. Starting in Release 15, CAPIF was defined in TS 23.222 and 29.222 with security aspects being addressed in TS 33.122. CAPIF is the “Common API Framework” defined by 3GPP to manage the APIs exposed by 3GPP networks in their northbound interfaces. But wait a moment, the northbound interface was not supposed to be addressed by NEF (Network Exposure Function, defined in TS 29.522)?

Absolutely…. NEF defines the APIs to be exposed in the northbound interface, and CAPIF defines HOW developers should consume those APIs in 3GPP networks. In a world where operators will expose network resources to multiple applications, this management layer comes to the rescue to avoid one to one integration among Operators/NEF vendors and Application developers.

So, being CAPIF the solution proposed by 3GPP to open the Networks to Applications, EVOLVED5G decided to bet in this winning horse and create the first Open Source implementation of CAPIF based in Release 17 (which is the latest stable release before Release 18 is concluded).

CAPIF defines three types of entities:

• API Providers, which are the entities exposing APIs (e.g., NEF)
• API Invokers, which are the entities that consume APIs (e.g., Applications), and
• the CAPIF Core Function, that manages the relationships between the other two.

The CAPIF Core Function is the cornerstone of the Common API Framework and provides the following capabilities:

• Authenticating the API Invoker based on its identity and other information;
• Supporting mutual authentication with the API Invoker;
• Providing authorization for the API Invoker prior to accessing the exposed APIs;
• Publishing, storing, and supporting the discovery of service APIs information;
• Controlling the service API access based on PLMN operator configured policies;
• Storing the logs for the service API invocations and providing the service API invocation logs to authorized entities;
• Charging based on the logs of the service API invocations;
• Monitoring the service API invocations;
• Onboarding a new API Invoker and offboarding an API Invoker;
• Storing policy configurations related to CAPIF and service APIs;
• Support accessing the logs for auditing (e.g., detecting abuse); and
• Support publishing and discovery of service APIs information among CAPIF Core Function (CAPIF interconnection).

The following diagram shows how API Invokers and API Providers interact with the CAPIF Core Function to Register in CAPIF, Publish APIs, Discover APIs and Consume APIs. It is important to highlight that the CAPIF Core Function is not a classical API Gateway. The API consumption takes place directly between the API Invoker and the API Provider. Therefore, CAPIF does not impact API performance in API consumption between API Invokers and API Providers.

When facing the development of an API defined by Open API specifications, you do not start from scratch. Tools such as Open API Generator can help you create a working server based in the YAML files describing the APIs. In the context of EVOLVED5G project, Telefónica and Fogus, took the lead in implementing the Common API Framework and releasing it as Open Source in the EVOLVED5G Github repository.

The first release addressed basic functionality, such as enabling the Registration of API Invokers and Providers, the Publication of APIs and the Discovery of those published APIs. EVOLVED5G also developed a NEF Emulator (provided by NCSRD) that was used as the first API Provider. The Applications developed by the 12 SMEs involved in the project, acted as API Invokers. Later releases included additional features such as Mutual TLS Authentication, Security Context management, API Logging and Auditing, Access Control Lists, … And this is how EVOLVED5G ended up having the first CAPIF implementation available for testing and rapid prototyping over real 5G networks.

As mentioned, EVOLVED5G is a 2020 ICT-41 project finalizing by end of 2023. When looking for options to provide continuity to the development and a longer term home to the community, the ETSI Software Development Groups seemed to be the perfect approach. SDGs are a new type of group at ETSI, tailored for collaborative software development alongside standardization work. Participation is open to ETSI-members, non-members and individuals, and each group can choose the license that better suits their goals, including open source licenses.

So EVOLVED5G partners teamed up and submitted a proposal for the creation of ETSI SDG OpenCAPIF in July 2023 that was consequently discussed by ETSI Board and approved in September 2023.

On one hand, ETSI is developing a framework that will be key for the openness and programmability of future networks to foster and support an ecosystem of developers to create better applications that will be build and tested against a proven standard. Applications tested with OpenCAPIF will be easier to integrate in commercial networks from operators and service providers, improving the competitiveness of small and European players.

On the other hand, the European funded effort carried out in EVOLVED5G will continue under ETSI guidance, while the initial community of developers grows beyond the original project boundaries. Indeed, not only several recently launched SNS projects have committed their plans to use OpenCAPIF in their testbeds, and contribute to future releases, but SDG OpenCAPIF will strive to build a global and diverse community of contributors.

As an ETSI SDG, OpenCAPIF will be able to further support 5G/6G research and network services, while fostering standards alignment and providing early and regular feedback to standardization activities.

This is the exciting story of OpenCAPIF. In future posts we will deep dive into its architecture and capabilities. Stay tuned, there is much more coming on OpenCAPIF!