To view PDF files

You need Adobe Reader 7.0 or later in order to read PDF files on this site.
If Adobe Reader is not installed on your computer, click the button below and go to the download site.

Global Standardization Activities

Vol. 22, No. 4, pp. 54–57, Apr. 2024.

Standardization Trends of Northbound APIs in 3GPP

Haruka Eitoku


The 3rd Generation Partnership Project (3GPP) has been working on the standardization of the application programming interface (API) framework to enable 3rd party providers (e.g., application providers) to use the functionalities of an operator’s network since Release 15 for collaboration with various industries. The API is called “northbound API” in 3GPP since it can be sketched as a northbound (upward) interface provided by the operators to 3rd party providers. This article provides an overview of the method for obtaining user consent when a 3rd party provider uses the northbound APIs exposed by an operator, which is standardized in Release 18 in expectation of the expansion of 5th generation (5G)/5G advanced/6G services and introduces NTT’s standardization activities in 3GPP.

Keywords: 3GPP, northbound API, OAuth 2.0


1. Use cases of API invocation based on user’s consent

An example in which a 3rd party provider accesses an application programming interface (API) on the basis of user consent is one of the new use cases in the expectation of the development of 5th generation (5G)/5G advanced/6G services. The service flow for the quality of service (QoS) setting during an online game is illustrated in Fig. 1 as an example.

Fig. 1. New use cases of API usage based on user consent.

This example is a situation in which a user who has a contract with an operator plays a time-sensitive game using an application on the user equipment. The user may require higher quality and lower latency for their service experience. For the server of a 3rd party game provider to invoke the QoS API provided by the operator on the basis of the user request, the server needs to obtain the authorization from the operator to invoke the API. If additional fees are required for accessing the QoS API, the server needs to obtain the user’s consent for the additional fees.

To enable use cases such as the above example, the 3rd Generation Partnership Project (3GPP) is working on the standardization of Resource owner-aware Northbound API Access (RNAA).

2. RNAA overview

2.1 OAuth 2.0

The procedure to obtain user consent on the basis of OAuth 2.0 is specified for RNAA. OAuth 2.0 is a mechanism widely used on websites to protect resources such as when the API is invoked. It is specified in RFC 6749 and other related documents produced by Internet Engineering Task Force (IETF). Several grant types are applicable for OAuth 2.0, and three grant types, i.e., client credentials grant, authorization code grant, and proof key for code exchange (PKCE), are supported for RNAA in 3GPP. In this section, the OAuth 2.0 flow (Fig. 2) based on the authorization code grant is described on the basis of clauses 1.2 and 4.1 of RFC 6749.

Fig. 2. OAuth 2.0 flow.

A client that requests access to the resource (e.g., API) owned by the resource owner (e.g., end user) initiates the flow by directing the resource owner’s user agent (e.g., web browser) to the authorization endpoint inside the authorization server for obtaining the access rights to the API. The authorization server authorizes the resource owner via the user agent, and the resource owner notifies the authorization server to grant the client-access rights. This step for granting the access rights corresponds to the procedure for obtaining user consent in RNAA. The authorization server then redirects the user agent to the client. The client receives an authorization code, a one-time credential, from the user agent as an indication of the resource owner’s permission to grant the access request and sends the code to the authorization endpoint. The authorization server verifies the authorization code and validates the client, and if the result is valid, the authorization server generates an access token and sends it to the client. The client requests accessing the resource server for accessing the resources with the access token. The resource server verifies the access token, and if the request is valid, the client can access the resource on behalf of the resource owner.

2.2 RNAA architecture

3GPP is considering extending the specifications of the Common API Framework (CAPIF) [1–3] for RNAA to enable new use cases for API accessing based on user consent.

The CAPIF allows 3rd party providers to use the functionalities of an operator’s network and has been standardized by 3GPP since Release 15. The main capability of the CAPIF is discovering appropriate northbound APIs. The northbound APIs used by 3rd party operators are provided by the service capability exposure function (SCEF) and network exposure function (NEF) in the Evolved Packet Core (EPC) and 5G Core (5GC) networks. The SCEF/NEF is connected to the network functions of the EPC/5GC of carriers via the southbound interface, and the SCEF/NEF can access the EPC/5GC functionalities (e.g., QoS setting) via this interface on the basis of the request for API call from the 3rd party providers.

RNAA extends the CAPIF specifications by introducing new functional entities, called resource owner client and authorization function, and the related reference points (Fig. 3). The authorization function is inside the CAPIF core function (CCF) in Release 18, and the resource owner client resides on the user equipment.

Fig. 3. RNAA architecture.

The API invoker is the source of an API call, which can be either an operator or 3rd party provider. The API exposing function (AEF) exposes the northbound API called the service API, and the SCEF/NEF corresponds to the AEF. The API publishing function (APF) publishes information of the service APIs to the CCF. The API management function (AMF) manages the published service APIs (e.g., auditing the service API invocation logs received from the CCF). The CCF is the key functional part of the CAPIF and capable of authenticating API invokers, maintaining service API information, and discovering service APIs on the basis of the information. The API invoker can invoke the CAPIF API exposed by the CCF to execute common procedures such as authentication and authorization of the API invoker for invoking the service APIs and discovering APIs.

Although the CAPIF assumes cases in which the CCF and AEF/APF/AMF are provided by different providers, the current RNAA specification assumes that the CCF and AEF/APF/AMF are all provided by the same operator.

2.3 RNAA procedure

In the procedure [3] to obtain user consent for invoking the service API between the API invoker and AEF, the API invoker first calls the CAPIF API exposed by the CCF to authenticate itself to the CCF, which discovers the appropriate API after the API invoker’s authentication. The API invoker then calls the CAPIF API again to negotiate the method for authentication and authorization (i.e., security method) between the API invoker and AEF. If user consent is required, the authorization method used to obtain user consent is expected to be negotiated at this time. The AEF authenticates the API invoker using the negotiated security method, and the authorization server authorizes the API invoker using one of the grant types supported by RNAA (i.e., client credentials grant, authorization code grant, PKCE).

3. Future prospects

3GPP has been working on the standardization of detailed procedures for RNAA since 2023 in Technical Specification Group (TSG) Core Network and Terminals Working Group 3 (CT3)*1, and TSG Service and System Aspects Working Group 3 (SA3)*2. The specifications provided by CT3 and SA3 follow the service requirements and architecture specified in SA1*3 and SA6*4; NTT is responsible for the work in CT3. The normative work of RNAA in Release 18 is expected to be completed (at the time of writing this article) in March 2024. NTT will continue to contribute for the collaboration with various industries and the creation of new services through standardization activities in 3GPP.

*1 CT3: Group studying interworking between networks and protocols in 3GPP.
*2 SA3: Group studying architectures and protocols for security and privacy in 3GPP.
*3 SA1: Group studying service requirements.
*4 SA6: Group studying application enabler.


[1] 3GPP TS 23.222: Common API Framework for 3GPP Northbound APIs, SpecificationDetails.aspx?specificationId=3337
[2] 3GPP TS 29.222: Common API Framework for 3GPP Northbound APIs, SpecificationDetails.aspx?specificationId=3450
[3] 3GPP TS 33.122: Security aspects of Common API Framework (CAPIF) for 3GPP northbound APIs, SpecificationDetails.aspx?specificationId=3420
Haruka Eitoku
Researcher, NTT Network Service System Laboratories.
She received an M.S. from Graduate School of Science, Kyushu University, Fukuoka, in 2017. Since joining NTT in 2017, she has been contributing to standardization efforts in 3GPP for interconnection between IMS networks and for immersive real-time communication technologies. She received the Telecommunication Technology Committee (TTC) Distinguished Service Award in 2000.