5 API Definitions

29.5353GPP5G SystemAKMA Anchor ServicesRelease 18Stage 3TS

5.1 Naanf_AKMA Service API

5.1.1 Introduction

The Naanf_AKMA service shall use the Naanf_AKMA API.

The API URI of the Naanf_AKMA API shall be:

{apiRoot}/<apiName>/<apiVersion>

The request URIs used in HTTP requests from the NF service consumer towards the NF service producer shall have the Resource URI structure defined in clause 4.4.1 of 3GPP TS 29.501 [5], i.e.:

{apiRoot}/<apiName>/<apiVersion>/<apiSpecificResourceUriPart>

with the following components:

– The {apiRoot} shall be set as described in 3GPP TS 29.501 [5].

– The <apiName> shall be "naanf-akma".

– The <apiVersion> shall be "v1".

– The <apiSpecificResourceUriPart> shall be set as described in clause 5.1.3 and 5.1.4.

5.1.2 Usage of HTTP

5.1.2.1 General

HTTP/2, IETF RFC 7540 [11], shall be used as specified in clause 5 of 3GPP TS 29.500 [4].

HTTP/2 shall be transported as specified in clause 5.3 of 3GPP TS 29.500 [4].

The OpenAPI [6] specification of HTTP messages and content bodies for the Naanf_AKMA API is contained in Annex A.

5.1.2.2 HTTP standard headers

5.1.2.2.1 General

See clause 5.2.2 of 3GPP TS 29.500 [4] for the usage of HTTP standard headers.

5.1.2.2.2 Content type

JSON, IETF RFC 8259 [12], shall be used as content type of the HTTP bodies specified in the present specification as specified in clause 5.4 of 3GPP TS 29.500 [4]. The use of the JSON format shall be signalled by the content type "application/json".

"Problem Details" JSON object shall be used to indicate additional details of the error in a HTTP response body and shall be signalled by the content type "application/problem+json", as defined in IETF RFC 7807 [13].

5.1.2.3 HTTP custom headers

The mandatory HTTP custom header fields specified in clause 5.2.3.2 of 3GPP TS 29.500 [4] shall be supported, and the optional HTTP custom header fields specified in clause 5.2.3.3 of 3GPP TS 29.500 [4] may be supported..

In this release of the specification, no specific custom headers are defined for the Naanf_AKMA Service API.

5.1.3 Resources

There are no resources defined for this API in this release of the specification.

5.1.4 Custom Operations without associated resources

5.1.4.1 Overview

The structure of the custom operation URIs of the Naanf_AKMA API is shown in figure 5.1.4.1-1.

Figure 5.1.4.1-1: Custom operation URI structure of the Naanf_AKMA API

Table 5.1.4.1-1 provides an overview of the custom operations and applicable HTTP methods defined for the Naanf_AKMA API.

Table 5.1.4.1-1: Custom operations without associated resources

Operation

Custom operation URI

Mapped HTTP method

Description

register-anchorkey

/register-anchorkey

POST

Request to store AKMA related key material in the AAnF.

retrieve-applicationkey

/retrieve-applicationkey

POST

Request to retrieve AKMA Application Key information.

remove-context

/remove-context

POST

Request to remove AKMA context in the AAnF.

5.1.4.2 Operation: Register

5.1.4.2.1 Description

The custom operation allows a NF service consumer to store AKMA related key material in the AAnF.

5.1.4.2.2 Operation Definition

This operation shall support the response data structures and response codes specified in tables 5.1.4.2.2-1 and 5.1.4.2.2-2.

Table 5.1.4.2.2-1: Data structures supported by the POST Request Body on this resource

Data type

P

Cardinality

Description

AkmaKeyInfo

M

1

AKMA related key material which is requested to be stored in the AAnF

Table 5.1.4.2.2-2: Data structures supported by the POST Response Body on this resource

Data type

P

Cardinality

Response

codes

Description

AkmaKeyInfo

M

1

200 OK

The AKMA related key material was stored successfully.

RedirectResponse

O

0..1

307 Temporary Redirect

Temporary redirection, during registration. The response shall include a Location header field containing an alternative URI of the resource located in an alternative AAnF (service) instance.

RedirectResponse

O

0..1

308 Permanent Redirect

Permanent redirection, during registration. The response shall include a Location header field containing an alternative URI of the resource located in an alternative AAnF (service) instance.

NOTE: The manadatory HTTP error status code for the POST method listed in Table 5.2.7.1-1 of 3GPP TS 29.500 [4] also apply.

Table 5.1.4.2.2-3: Headers supported by the 307 Response Code on this resource

Name

Data type

P

Cardinality

Description

Location

string

M

1

An alternative URI of the resource located in an alternative AAnF (service) instance.

3gpp-Sbi-Target-Nf-Id

string

O

0..1

Identifier of the target AAnF (service) instance towards which the request is redirected.

Table 5.1.4.2.2-4: Headers supported by the 308 Response Code on this resource

Name

Data type

P

Cardinality

Description

Location

string

M

1

An alternative URI of the resource located in an alternative AAnF (service) instance.

3gpp-Sbi-Target-Nf-Id

string

O

0..1

Identifier of the target AAnF (service) instance towards which the request is redirected.

5.1.4.3 Operation: Retrieve

5.1.4.3.1 Description

The custom operation allows a NF service consumer to retrieve AKMA Application Key information for the UE.

5.1.4.3.2 Operation Definition

This operation shall support the response data structures and response codes specified in tables 5.1.4.3.2-1 and 5.1.4.3.2-2.

Table 5.1.4.3.2-1: Data structures supported by the POST Request Body on this resource

Data type

P

Cardinality

Description

AkmaAfKeyRequest

M

1

Parameters to request to retrieve AKMA Application Key information.

Table 5.1.4.3.2-2: Data structures supported by the POST Response Body on this resource

Data type

P

Cardinality

Response

codes

Description

AkmaAfKeyData

M

1

200 OK

The requested AKMA Application Key information was returned successfully. (NOTE 2)

n/a

204 No Content

If the requested data does not exist, the AAnF shall respond with "204 No Content".

RedirectResponse

O

0..1

307 Temporary Redirect

Temporary redirection, during retrieval. The response shall include a Location header field containing an alternative URI of the resource located in an alternative AAnF (service) instance.

RedirectResponse

O

0..1

308 Permanent Redirect

Permanent redirection, during retrieval. The response shall include a Location header field containing an alternative URI of the resource located in an alternative AAnF (service) instance.

ProblemDetails

O

0..1

403 Forbidden

(NOTE 3)

NOTE 1: The manadatory HTTP error status code for the POST method listed in Table 5.2.7.1-1 of 3GPP TS 29.500 [4] also apply.

NOTE 2: For the "AkmaAfKeyData" data structure used in the current release of this specification, the “gpsi” attribute is not applicable and the "supi" attribute shall be included, except in the case of the anonymous user access procedure using the Naanf_AKMA_ApplicationKey_AnonUser_Get service operation, as defined in clause 6.2.2 of 3GPP TS 33.535 [14].

NOTE 3: Failure cases are described in clause 5.1.7.3

Table 5.1.4.3.2-3: Headers supported by the 307 Response Code on this resource

Name

Data type

P

Cardinality

Description

Location

string

M

1

An alternative URI of the resource located in an alternative AAnF (service) instance.

3gpp-Sbi-Target-Nf-Id

string

O

0..1

Identifier of the target AAnF (service) instance towards which the request is redirected.

Table 5.1.4.3.2-4: Headers supported by the 308 Response Code on this resource

Name

Data type

P

Cardinality

Description

Location

string

M

1

An alternative URI of the resource located in an alternative AAnF (service) instance.

3gpp-Sbi-Target-Nf-Id

string

O

0..1

Identifier of the target AAnF (service) instance towards which the request is redirected.

5.1.4.4 Operation: Remove

5.1.4.4.1 Description

The custom operation allows a NF service consumer to delete the AKMA context for the UE.

5.1.4.4.2 Operation Definition

This operation shall support the response data structures and response codes specified in tables 5.1.4.4.2-1 and 5.1.4.4.2-2.

Table 5.1.4.4.2-1: Data structures supported by the POST Request Body on this resource

Data type

P

Cardinality

Description

CtxRemove

M

1

Parameters to request to delete the AKMA context for the UE.

Table 5.1.4.4.2-2: Data structures supported by the POST Response Body on this resource

Data type

P

Cardinality

Response

codes

Description

n/a

204 No Content

Successful case: The AKMA context matching the "CtxRemove" in the request body was deleted, the AAnF shall respond with "204 No Content".

RedirectResponse

O

0..1

307 Temporary Redirect

Temporary redirection, during remove procedure. The response shall include a Location header field containing an alternative URI of the resource located in an alternative AAnF (service) instance.

RedirectResponse

O

0..1

308 Permanent Redirect

Permanent redirection, during remove procedure. The response shall include a Location header field containing an alternative URI of the resource located in an alternative AAnF (service) instance.

ProblemDetails

O

0..1

404 Not Found

(NOTE 2)

NOTE 1: The manadatory HTTP error status code for the POST method listed in Table 5.2.7.1-1 of 3GPP TS 29.500 [4] also apply.

NOTE 2: Failure cases are described in clause 5.1.7.3

Table 5.1.4.4.2-3: Headers supported by the 307 Response Code on this resource

Name

Data type

P

Cardinality

Description

Location

String

M

1

An alternative URI of the resource located in an alternative AAnF (service) instance.

3gpp-Sbi-Target-Nf-Id

String

O

0..1

Identifier of the target AAnF (service) instance towards which the request is redirected.

Table 5.1.4.4.2-4: Headers supported by the 308 Response Code on this resource

Name

Data type

P

Cardinality

Description

Location

string

M

1

An alternative URI of the resource located in an alternative AAnF (service) instance.

3gpp-Sbi-Target-Nf-Id

string

O

0..1

Identifier of the target AAnF (service) instance towards which the request is redirected.

5.1.5 Notifications

Notifications are not applicable to this API.

5.1.6 Data Model

5.1.6.1 General

This clause specifies the application data model supported by the Naanf_AKMA API.

Table 5.1.6.1-1 specifies the data types defined for the Naanf_AKMA service based interface protocol.

Table 5.1.6.1-1: Naanf_AKMA specific Data Types

Data type

Clause defined

Description

Applicability

AkmaKeyInfo

5.1.6.2.2

AKMA related key material.

CtxRemove

5.1.6.2.3

Indicate the AKMA context to be remove.

Table 5.1.6.1-2 specifies data types re-used by the Naanf_AKMA service based interface protocol from other specifications, including a reference to their respective specifications and when needed, a short description of their use within the Naanf_AKMA service based interface.

Table 5.1.6.1-2: Naanf_AKMA re-used Data Types

Data type

Reference

Comments

Applicability

AKId

3GPP TS 29.522 [16]

AkmaAfKeyData

3GPP TS 29.522 [16]

Parameters to present AKMA Application Key information.

AkmaAfKeyRequest

3GPP TS 29.522 [16]

Parameters to request to retrieve AKMA Application Key information.

RedirectResponse

3GPP TS 29.571 [15]

Contains redirection related information.

Supi

3GPP TS 29.571 [15]

SupportedFeatures

3GPP TS 29.571 [15]

Used to negotiate the applicability of the optional features.

5.1.6.2 Structured data types

5.1.6.2.1 Introduction

This clause defines the structures to be used in resource representations.

5.1.6.2.2 Type: AkmaKeyInfo

Table 5.1.6.2.2-1: Definition of type AkmaKeyInfo

Attribute name

Data type

P

Cardinality

Description

Applicability

supi

Supi

M

1

SUPI of UE

aKId

AKId

M

1

A-KID

kAkma

string

M

1

KAKMA

suppFeat

SupportedFeatures

O

0..1

Indicates the list of Supported features used as described in clause 5.1.8.

5.1.6.2.3 Type: CtxRemove

Table 5.1.6.2.3-1: Definition of type CtxRemove

Attribute name

Data type

P

Cardinality

Description

Applicability

supi

Supi

C

0..1

SUPI of UE

NOTE: In current release of specification, only "supi" can be used to indicate the AKMA context to be remove. The "supi" attribute shall be included.

5.1.6.3 Simple data types and enumerations

5.1.6.3.1 Introduction

This clause defines simple data types and enumerations that can be referenced from data structures defined in the previous clauses.

5.1.6.3.2 Simple data types

None in this release of the specification.

5.1.6.4 Data types describing alternative data types or combinations of data types

None in this release of the specification.

5.1.6.5 Binary data

None in this release of the specification.

5.1.7 Error Handling

5.1.7.1 General

For the Naanf_AKMA API, HTTP error responses shall be supported as specified in clause 4.8 of 3GPP TS 29.501 [5]. Protocol errors and application errors specified in table 5.2.7.2-1 of 3GPP TS 29.500 [4] shall be supported for an HTTP method if the corresponding HTTP status codes are specified as mandatory for that HTTP method in table 5.2.7.1-1 of 3GPP TS 29.500 [4].

In addition, the requirements in the following clauses are applicable for the Naanf_AKMA API.

5.1.7.2 Protocol Errors

No specific procedures for the Naanf_AKMA service are specified.

5.1.7.3 Application Errors

The application errors defined for the Naanf_AKMA service are listed in Table 5.1.7.3-1.

Table 5.1.7.3-1: Application errors

Application Error

HTTP status code

Description

K_AKMA_NOT_PRESENT

403 Forbidden

Indicates that the KAKMA identified by the A-KID provided in the AKMA Application Key retrieval request body is not present at the AAnF.

AKMA_CONTEXT_NOT_FOUND

404 Not Found

Indicates that the AKMA context to be deleted indicated by the "CtxRemove" Data type in the request body is not found.

5.1.8 Feature negotiation

The optional features in table 5.1.8-1 are defined for the Naanf_AKMA API. They shall be negotiated using the extensibility mechanism defined in clause 6.6 of 3GPP TS 29.500 [4].

Table 5.1.8-1: Supported Features

Feature number

Feature Name

Description

5.1.9 Security

As indicated in 3GPP TS 33.501 [8] and 3GPP TS 29.500 [4], the access to the Naanf_AKMA API may be authorized by means of the OAuth2 protocol (see IETF RFC 6749 [9]), based on local configuration, using the "Client Credentials" authorization grant, where the NRF (see 3GPP TS 29.510 [10]) plays the role of the authorization server.

If OAuth2 is used, an NF Service Consumer, prior to consuming services offered by the Naanf_AKMA API, shall obtain a "token" from the authorization server, by invoking the Access Token Request service, as described in 3GPP TS 29.510 [10], clause 5.4.2.2.

NOTE: When multiple NRFs are deployed in a network, the NRF used as authorization server is the same NRF that the NF Service Consumer used for discovering the Naanf_AKMA service.

The Naanf_AKMA API defines a single scope "naanf-akma" for the entire service, and it does not define any additional scopes at resource or operation level.

Annex A (normative):
OpenAPI specification