Tech-invite3GPPspaceIETF RFCsSIP
indexN21222324252627282931323334353637384‑5x

Content for  TS 23.222  Word version:  18.2.0

Top   Top   Up   Prev   Next
0…   4…   5…   6…   6.3…   6.4…   7…   8…   8.5…   8.8…   8.9…   8.13…   8.17…   8.21…   8.25…   8.28…   9…   10…   10.4…   10.7…   11…   A   B…   B.2…   B.3…   C…   D…

 

8.28  Registering the API provider domain functions on the CAPIF |R16|p. 86

8.28.1  Generalp. 86

The procedure in this subclause corresponds to the architectural requirements for registering the API provider domain functions on the CAPIF. This procedure registers the API provider domain functions as authorized users of the CAPIF functionalities.

8.28.2  Information flowsp. 86

8.28.2.1  Registration requestp. 86

Table 8.28.2.1-1 describes the information flow, registration request, from the API management function to the CAPIF core function.
Information Element Status Description
List of API provider domain functionsMList of API provider domain functions including role (e.g. AEF, APF, AMF) and, if required, specific security information.
API provider nameOThe API provider name uniquely identifies an API provider (e.g. Internet Service Provider).
Security informationMInformation for CAPIF core function to validate the registration request
Up

8.28.2.2  Registration responsep. 87

Table 8.28.2.2-1 describes the information flow, registration response, from the CAPIF core function to the API management function.
Information Element Status Description
List of identitiesM
(1)
List of identities, for each successfully registered API provider domain function and any specific security information.
Security informationOInformation to be used by the API provider domain function in subsequent CAPIF API invocations. Provided when registration is successful.
ReasonO
(2)
Information related to registration result specific to individual API provider domain functions. Provided when the registration fails.
NOTE 1:
Information element shall be present when at least one registration request is successful.
NOTE 2:
Information element may be present when at least one registration requests fail.
Up

8.28.3  Procedurep. 87

Figure 8.28.3-1 illustrates the procedure for registering API provider domain functions on the CAPIF core function.
Reproduction of 3GPP TS 23.222, Fig. 8.28.3-1: Procedure for registration of API provider domain functions on CAPIF
Up
Step 1.
For registration of API provider domain functions on the CAPIF core function, the API management function sends a registration request to the CAPIF core function. The registration request contains a list of information about all the API provider domain functions, which require registration on the CAPIF core function.
Step 2.
The CAPIF core function validates the received request and generates the identity and other security related information for all the API provider domain functions listed in the registration request.
Step 3.
The CAPIF core function sends the generated information in the registration response message to the API management function.
Step 4.
The API management function configures the received information to the individual API provider domain functions.
Up

8.29  Update registration information of the API provider domain functions on the CAPIF |R16|p. 88

8.29.1  Generalp. 88

The procedure in this subclause corresponds to the architectural requirements for update of the registration information of the API provider domain functions on the CAPIF.

8.29.2  Information flowsp. 88

8.29.2.1  Registration requestp. 88

Table 8.29.2.1-1 describes the information flow, registration update request, from the API management function to the CAPIF core function.
Information Element Status Description
List of API provider domain functions requiring updateMList of API provider domain functions requiring updates, including role (e.g. AEF, APF, AMF) and, if required, specific security information.
Security informationMInformation for CAPIF core function to validate the registration request
Up

8.29.2.2  Registration update responsep. 88

Table 8.29.2.2-1 describes the information flow, registration update response, from the CAPIF core function to the API management function.
Information Element Status Description
List of identitiesM
(1)
List of identities, for each successfully updated API provider domain function and any specific security information.
Security informationOInformation to be used by the API provider domain function in subsequent CAPIF API invocations. Provided when registration update is successful.
ReasonO
(2)
Information related to registration update result specific to individual API provider domain functions. Provided when the registration fails.
NOTE 1:
Information element shall be present when at least one registration update request is successful.
NOTE 2:
Information element may be present when at least one registration update requests fail.
Up

8.29.3  Procedurep. 89

Figure 8.29.3-1 illustrates the procedure for updating the registration information of the API provider domain functions on the CAPIF core function.
Reproduction of 3GPP TS 23.222, Fig. 8.29.3-1: Procedure for update of registration information of API provider domain functions on CAPIF
Up
Step 1.
For updating the registration information of API provider domain functions on the CAPIF core function, the API management function sends a registration update request to the CAPIF core function. The registration update request contains a list of information about all the API provider domain functions, which require registration update on the CAPIF core function.
Step 2.
The CAPIF core function validates the received request and updates the identity and other security related information for all the API provider domain functions listed in the registration request.
Step 3.
The CAPIF core function sends the updated information in the registration update response message to the API management function.
Step 4.
The API management function configures the received information to the individual API provider domain functions.
Up

8.30  Deregistering the API provider domain functions on the CAPIF |R16|p. 90

8.30.1  Generalp. 90

The procedure in this subclause corresponds to the architectural requirements for deregistering the API provider domain functions on the CAPIF. This procedure deregisters the API provider domain functions as authorized users of the CAPIF functionalities.

8.30.2  Information flowsp. 90

8.30.2.1  Deregistration requestp. 90

Table 8.30.2.1-1 describes the information flow, deregistration request, from the API management function to the CAPIF core function.
Information Element Status Description
Security informationMInformation for CAPIF core function to validate the deregistration request
Up

8.30.2.2  Deregistration responsep. 90

Table 8.30.2.2-1 describes the information flow, deregistration response, from the CAPIF core function to the API management function.
Information Element Status Description
ResultMIndicates the success or failure of the deregistration operation
Up

8.30.3  Procedurep. 90

Figure 8.30.3-1 illustrates the procedure for deregistering API provider domain functions on the CAPIF core function.
Reproduction of 3GPP TS 23.222, Fig. 8.30.3-1: Procedure for deregistration of API provider domain functions on CAPIF
Up
Step 1.
For deregistration of API provider domain functions on the CAPIF core function, the API management function sends a deregistration request to the CAPIF core function.
Step 2.
The CAPIF core function validates the received request and processes the deregistration request.
Step 3.
The CAPIF core function sends a deregistration response message to the API management function.
Step 4.
The API management function processes the deregistration to the individual API provider domain functions.

8.31  API invoker obtaining authorization from resource owner |R18|p. 91

8.31.1  Generalp. 91

CAPIF may authorize the API invoker to invoke the service API based on the authorization information from the resource owner given before the API invocation.
Clause 8.31.3 shows the procedure for obtaining the authorization information.

8.31.2  Information flowsp. 91

8.31.3  Procedurep. 91

Figure 8.31.3-1 illustrates the procedure for API invoker obtaining authorization from resource owner.
Pre-conditions:
  1. The resource owner can communicate with the API invoker.
Reproduction of 3GPP TS 23.222, Fig. 8.31.3-1: Procedure for API invoker obtaining authorization from resource owner
Up
Step 1.
The API invoker requests authorization information to invoke the service API.
Step 2.
The API invoker sends service API invocation request to the API exposing function with the authorization information received in step 1.

8.32  Reducing authorization information inquiry in a nested API invocation |R18|p. 92

8.32.1  Generalp. 92

The nested API invocation scenario is a scenario where the first API invocation towards the API exposing function 1 triggers this API exposing function to request another API invocation towards the API exposing function 2, which is in the same API provider domain that the API exposing function 1. Some service APIs may require invoking another service APIs. For example, if the API invoker invokes SEAL locationInfoRetrieval API, the location management server (acting as an API exposing server for the API invoker and as an API invoker for the NEF) may invoke NEF API to retrieve UE location information from 5GC. The CAPIF may reduce the authorization information inquiries for a nested API invocation scenario using procedure described in clause 8.32.3.
Up

8.32.2  Information flowsp. 92

8.32.3  Procedurep. 92

Figure 8.32.3-1 illustrates the procedure to obtain authorization information in a nested API invocation, in which an API exposing function receiving the service API invocation request interacts with another API exposing function to provide the service.
Pre-conditions:
  1. The resource owner can communicate with the API invoker.
  2. The API exposing functions 1 and 2 are in the same trust domain.
Reproduction of 3GPP TS 23.222, Fig. 8.32.3-1: Procedure for obtaining authorization information in a nested API invocation
Up
Step 1.
The API invoker requests authorization information to invoke the service API exposed by the API exposing function 1.
Step 2.
The API invoker sends service API invocation request to the API exposing function 1 with the authorization information received in step 1.
Step 3.
Based on the service API invocation request, the API exposing function 1 decides to invoke another service API exposed by the API exposing function 2.
Step 4.
The API exposing function 1, acting as an API invoker, obtains the authorization information to access the service API exposed by the API exposing function 2.
Step 5.
The API invoker sends service API invocation request to the API exposing function with the authorization information received in step 4.
Up

Up   Top   ToC