By Yuji Suzuki (SNAAPP Rapporteur, NTT docomo), Basu Pattan (SA6 Vice-chair) and Alan Soloway (SA6 Chair)

First published May. 2023, in Highlights Issue 06   

3GPP specified the Common API Framework (CAPIF) in Rel-15 to provide a framework for accessing 3GPP northbound APIs^[1]. In Rel-18 SNAAPP work, 3GPP SA6 studied CAPIF (3GPP TS 23.222) enhancements to support Resource owner-aware Northbound API Access (RNAA), which enables the authorization of API invokers when the APIs are invoked in the context of resource owners (e.g., MNO subscribers). This article aims to cover the use cases, architectural enhancements and technical features resulting from the Rel-18 work.

RNAA Use cases

3GPP has introduced various northbound APIs exposed to API invokers inside and outside the PLMN trust domain. For example, Service Capability Exposure Function (SCEF) and Network Exposure Function (NEF) expose the 3GPP network capabilities via APIs, and Service Enabler Architecture Layer (SEAL) APIs offer commonly used functionalities among different vertical applications.

The API invoker accesses the resources exposed by 3GPP northbound APIs and some of these resources may directly impact end user's service experience (e.g., modify QoS) or may handle end user specific information (e.g., obtain user location).

Up to Rel-17, if the API is invoked on behalf of the end user, the end user is not aware of the API invocation or does not have any control over which APIs can be executed on their behalf. RNAA aims to protect users against such unintended access to their resources via APIs.

An example use case of RNAA is QoS modification while consuming gaming services. Assume that an end user (also a subscriber of the MNO in this case) is playing a game provided by a game provider and the gaming experience of the end user has to be improved. In such a scenario, two potential use cases are elaborated below.

In both use cases, the end user, acting as a resource owner, can control whether API invoker can change their QoS before the end user is potentially charged for the high-quality service.

CAPIF architecture to support RNAA

Figure 1 shows the CAPIF architecture to support RNAA. Compared with the CAPIF architecture up to Rel-17, this architecture has new functional entities, namely the resource owner client and the authorization function, and new reference points related to those new entities.

Figure 1: CAPIF architecture to support RNAA

The resource owner client is a functional entity that provides authorization for resource access. This is typically a client application on the resource owner's UE, and the resource owner (human) can allow or deny the resource access by the API invoker via the resource owner client.

The authorization function is a functional entity to receive authorization from the resource owner client. When receiving authorization from the resource owner client, the authorization function may provide the API invoker with the authorization information, which is needed to access the resource owner's resources.

Note that, in Rel-18, these two functional entities shall be in the PLMN trust domain.

Features of RNAA

To support the use cases described above, the following features have been studied.

1. Discovery of target API information: The API invoker may serve UEs that belong to different PLMNs. For example, in the gaming use cases, the game server of a game provider serves clients who subscribe different MNO's network services. If the game server wants to change the QoS of an end user who is a subscriber of a particular MNO, the game server needs to find the right API exposing function provided by the MNO. RNAA supports the feature to help the API invoker to discover the proper API information in the multi-PLMN cases.
2.  Obtaining authorization from the resource owner: CAPIF can ask the resource owner whether they allow the API invoker to access their resources. In the QoS use case above, the end user affected by the QoS change will inform whether the QoS change is acceptable. With this feature, the API invoker cannot invoke service APIs without authorization from the resource owner.
3. Supporting UE- and AF-originated API invocation scenarios: As shown in the use cases above, RNAA supports two API invocation scenarios, namely UE- and AF-originated API invocation. For example, in the gaming use case, service APIs can be invoked by the game client on the end user's UE (UE-originated) or by the game server owned by the game provider (AF-originated). In Rel-17 CAPIF, the API invoker was regarded as a general functional entity that invokes the exposed service APIs, but in the Rel-18 SNAAPP study, SA6 has clarified that the API invoker may reside in the UE or the server.

Figure 2 illustrates the realization of the AF-originated API invocation use case 2 described above (i.e., gaming server invoking service API based on the trigger from gaming client on the UE) using the enhanced CAPIF procedures in Rel-18 3GPP TS 23.222.