Tech-invite3GPPspaceIETF RFCsSIP
Quick21222324252627282931323334353637384‑5x

Content for  TS 23.222  Word version:  17.5.0

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

 

8.25  Support for CAPIF interconnection |R16|Word‑p. 74

8.25.1  General

The procedures in this subclause corresponds to the architectural requirements on CAPIF interconnection.

8.25.2  Information flows

8.25.2.1  Interconnection API publish request

Table 8.25.2.1-1 describes the information flow interconnection API publish request from CAPIF core function to CAPIF core function.
Information Element Status Description
CCF informationMThe information of the CAPIF core function which publishes APIs, may include identity, authentication and authorization information
Service API informationO
(1)
The service API information includes the service API name, service API type, communication type, description, Serving Area Information (optional), AEF location (optional), interface details (e.g. IP address, port number, URI), protocols, version numbers, and data format.
Service API categoryO
(1)
The category of the service APIs to be published, (e.g. V2X, IoT)
Shareable informationO
(2)
Indicates whether the service API or the service API category can be published to other CCFs. And if sharing, a list of CAPIF provider domain information where the service API or the service API category can be published is contained.
NOTE 1:
At least one of the Service API information or Service API category shall be present.
NOTE 1:
If the shareable information is not present, the service API is not allowed to be shared. There is one and only one CAPIF provider domain information sharable via the CAPIF‑6e interface.
Up

8.25.2.2  Interconnection API publish response

Table 8.25.2.2-1 describes the information flow interconnection API publish response from CAPIF core function to CAPIF core function.
Information Element Status Description
ResultMIndicates the success or failure of publishing the service API information
Service API published information referenceO
(1)
The information which can be used for referencing the information (set) about the published service API by the CCF which publishes service APIs
NOTE 1:
This information element is included when the Result indicates success.
Up

8.25.2.3  Interconnection service API discover request

Table 8.25.2.3-1 describes the information flow interconnection service API discover request from one CAPIF core function to another CAPIF core function.
Information Element Status Description
CAPIF core function identity informationMIdentity information of the CAPIF core function discovering service APIs
Query informationMCriteria for discovering matching service APIs or CAPIF core function (e.g. service API type, Serving Area Information (optional), preferred AEF location (optional), interfaces, protocols, service API category) (see NOTE)
NOTE:
It should be possible to discover all the service APIs.
Up

8.25.2.4  Interconnection service API discover responseWord‑p. 75

Table 8.25.2.4-1 describes the information flow interconnection service API discover response from one CAPIF core function to another CAPIF core function.
Information Element Status Description
ResultMIndicates the success or failure of the discovery of the service API information
Service API informationO
(1)
List of service APIs corresponding to the request, including API description such as service API name, service API type, Serving Area Information (optional), AEF location (optional), interface details (e.g. IP address, port number, URI), protocols, version, data format
CAPIF core function identity informationO
(1)
Indicates the CAPIF core function matching the service API category in the query criteria
NOTE 1:
The service API information or the CAPIF core function identity information or both shall be present, if the Result information element indicates that the interconnection service API discover operation is successful. Otherwise, both shall not be present.
Up

8.25.3  Procedure

8.25.3.1  Service API publish for CAPIF interconnection

This subclause describes the procedure for service API publish for CAPIF interoperation.
Pre-conditions:
  1. CCF-A and CCF-B connect to each other, and either belong to the single trust domain of the same CAPIF provider or trust domains of different CAPIF providers.
  2. CCF-B is configured as the designated CAPIF core function in the trust domain of CAPIF provider A.
  3. When CCF-A and CCF-B belong to trust domains of different CAPIF providers, the two CAPIF providers have business agreement for service API sharing.
Reproduction of 3GPP TS 23.222, Figure 8.25.3.1-1: Interconnection API publish
Up
Step 1.
CCF-A gets the service APIs to be shared with CCF-B from the API publish function which is in the same CAPIF provider domain of CCF-A as described in subclause 8.3.3, or from another CCF as described in this procedure.
Step 2.
Based on the shareable information for the service API or the service API category information, the CCF-A determines to publish the service API or the service API category information to the CCF-B. The CCF-A sends the interconnection API publish request to CCF-B with the details of at least one of service APIs or the category information of the service APIs, along with the identity information of CCF-A, shareable information and CAPIF provider domain information if allowed to share. The API topology hiding may be enabled.
Step 3.
CCF-B stores the service API information or service API category provided by the CCF-A.
Step 4.
CCF-B provides an interconnection API publish response to the CCF-A indicating success or failure result and triggers notifications to subscribed API invokers as described in subclause 8.8.4.
Up

8.25.3.2  Service API discovery involving multiple CCFsWord‑p. 76

This subclause describes a procedure for service API discovery involving multiple CCFs
Pre-conditions:
  1. CCF-A and CCF-B connect to each other, and either belong to the single trust domain of the same CAPIF provider or trust domains of different CAPIF providers.
  2. When CCF-A and CCF-B belong to trust domains of different CAPIF providers, the two CAPIF providers have business agreement for service API sharing.
Reproduction of 3GPP TS 23.222, Figure 8.25.3.2-1: Service API discovery y involving multiple CCFs
Up
Step 1.
The API invoker sends a service API discover request to the CCF-A. It includes the API invoker identity, and may include query information.
Step 2.
The CCF-A verifies the identity of the API invoker and retrieves the stored service API(s) information and service API categories. The information of CCF-B with the service API category matching the discovery criteria is returned to API invoker in the service API discover response.
Step 3.
The API invoker sends an service API discover request to the CCF-B. The identity of API invoker is included. The query information is also provided.
Step 4.
Upon receiving the service API discover request, the CCF-B verifies the identity of the API invoker. The CCF-B retrieves the stored service API(s) information as per the query information in the service API discover request. Further, the CCF-B applies the discovery policy and performs filtering of service APIs information which matches the discovery criteria.
Step 5.
The CCF-B sends an service API discover response to the API invoker with the list of service API information for which the API invoker has the required authorization.
Up

8.25.3.3  Service API discovery for CAPIF interconnectionWord‑p. 77

This subclause describes a procedure for service API discovery for CAPIF interconnection. The CCF-A and the CCF-B may belong to the same CAPIF provider domain or different CAPIF provider domains. When the CCF-A and the CCF B belong to different CAPIF provider domains, the two CAPIF providers shall have business agreement for service API discovery.
Pre-conditions:
  1. The CCF-A is configured with the CCF-B information.
  2. The CCF-B is configured with the CCF-A information.
  3. The CCF-A is triggered (e.g. API invoker service API discovery, periodic service API discovery) to perform service API discovery with the CCF-B.
Reproduction of 3GPP TS 23.222, Figure 8.25.3.3-1: Service API discovery for CAPIF interconnection
Up
Step 1.
The CCF-A sends the interconnection service API discover request to the CCF-B. The identity of the CCF-A and the query information are included.
Step 2.
The CCF-B upon receiving the interconnection service API discover request verifies the identity of the CCF-A. The CCF-B retrieves the stored service API(s) or the CCF(s) information as per the query information in the interconnection service API discover request. Further, the CCF-B applies the discovery policy and performs the filtering of service APIs or the CCF(s) information. The topology hiding policy may be applied to the retrieved list of service API information.
Step 3.
The CCF-B sends the interconnection service API discover response to the CCF-A with the list of service API information for which the CCF-A has the required authorization or the CCF(s) information that matches the discovery criteria.
Up

8.26  Update API invoker's API list |R16|Word‑p. 78

8.26.1  General

The procedure in this subclause corresponds to the architectural requirements for updating the API invoker's API list on the CAPIF core function. The CAPIF enables API invoker to update its own API list e.g. subsequent to discovering new API(s).

8.26.2  Information flows

8.26.2.1  Update API invoker API list request

Table 8.26.2.1-1 describes the information flow update API invoker API list request from the API invoker to the CAPIF core function.
Information Element Status Description
API invoker identity informationMIdentity information of the API invoker requesting update
APIs for updateMList of APIs that need update (e.g. enroll new API(s), disenroll API(s)).
Up

8.26.2.2  Update API invoker API list responseWord‑p. 79

Table 8.26.2.2-1 describes the information flow update API invoker API list response from the CAPIF core function to the API invoker.
Information Element Status Description
ResultMIndicates the completely successful or partially successful or failure of the update operation
API informationO
(1)
List of APIs and the types of APIs that the API invoker can access
ReasonO
(2)
This element indicates the reason when update status is failure and for which API(s)
NOTE 1:
Information element shall be present when update API invoker API list status is partial or completely successful.
NOTE 2:
Information element shall be present when update API invoker API list status is partial successful or failure.
Up

8.26.3  Procedure

Figure 8.26.3-1 illustrates the procedure for updating the API invoker API list on the CAPIF.
Pre-conditions:
  1. The API invoker has been onboarded as a recognized user of the CAPIF and associated API invoker profile is provisioned.
  2. The API invoker has visibility to new APIs information (e.g. updates on API catalogue or dashboard, API discovery).
Reproduction of 3GPP TS 23.222, Figure 8.26.3-1: Procedure for updating the API invoker profile on the CAPIF
Up
Step 1.
For updating of the API invoker API list on the CAPIF, the API invoker triggers update API invoker API list request towards the CAPIF core function, providing the information to be updated (e.g. enroll new APIs, disenroll APIs).
Step 2.
The CAPIF core function updates the API invoker API list of the requesting API invoker, according to the grant from the CAPIF administrator or the API management.
Step 3.
The update API invoker API list response provides partial success or complete success or failure indication. Partial success and complete success result will include APIs information that the API invoker can access. When the update status is failure, the reason for failure and information for which API(s) the update operation has failed is included.
Up

8.27  Dynamically routing service API invocation |R16|Word‑p. 80

8.27.1  General

The procedure in this subclause corresponds to the architectural requirements for dynamic routing of service API invocation. The CAPIF enables dynamically routing the service API invocation request based on the detailed information of the invocation.

8.27.2  Information flows

8.27.2.1  Obtain routing information request

Table 8.27.2.1-1 describes the information flow dynamic routing information request from the API exposing function to the CAPIF core function.
Information Element Status Description
Service API identification informationMThe identification information of the service API for which invocation is requested. The service API identification is part of the specific service API invocation request.
AEF identity informationMIdentity information of the entity requesting the routing information
Up

8.27.2.2  Obtain routing information response

Table 8.27.2.2-1 describes the information flow dynamic routing information response from the CAPIF core function to the API exposing function.
Information Element Status Description
Service API identification informationMThe identification information of the service API for which invocation is requested.
Routing rule(s) information for service API invocationMIndicates the routing rule(s) for service API invocation, e.g., mapping of IP address range and AEF identity, or mapping of area serving the service API and AEF information.
Up

8.27.3  Procedure

Figure 8.27.3-1 illustrates the procedure for dynamically routing the service API invocation from the AEF acting as service communication entry point to the destination AEF for handling service API.
Pre-conditions:
  1. The API invoker has performed the service discovery and received the details of the service API which includes the information about the service communication entry point of the AEF‑1 in the CAPIF.
  2. The API invoker is authenticated and authorized to use the service API.
  3. The AEF‑1 iis the AEF acting as service communication entry point for the service API, and AEF-2 is one of the multiple destination AEF which provides the service API.
Reproduction of 3GPP TS 23.222, Figure 8.27.3-1: Procedure for dynamic routing of service API invocation
Up
Step 1.
The API invoker performs service API invocation according to the interface of the service API by sending a service API invocation request towards the AEF‑1 which exposes the service API towards the API invoker, and acts as topology hiding entity.
Step 2.
If the routing rule information for the service API invocation is not available, the AEF‑1 sends obtain routing information request to the CAPIF core function.
Step 3.
The CAPIF core function creates routing rule information for the service API and sends obtain routing information response with the routing rule information.
Step 4.
The AEF‑1 further resolves the actual destination of the service API address information (AEF‑2) according to the routing rule information and the invocation parameters in service API invocation request.
Step 5.
The AEF‑1 forwards the incoming service API invocation request to AEF‑2.
Step 6.
The AEF‑2 returns the service API invocation response to AEF‑1.
Step 7.
The AEF‑1 sends the service API invocation response to the API invoker.
Up

8.28  Registering the API provider domain functions on the CAPIF |R16|Word‑p. 81

8.28.1  General

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 flows

8.28.2.1  Registration request

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.
Security informationMInformation for CAPIF core function to validate the registration request
Up

8.28.2.2  Registration responseWord‑p. 82

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  Procedure

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, Figure 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|Word‑p. 83

8.29.1  General

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 flows

8.29.2.1  Registration request

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 response

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  ProcedureWord‑p. 84

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, Figure 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|Word‑p. 85

8.30.1  General

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 flows

8.30.2.1  Deregistration request

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 response

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  Procedure

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, Figure 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.

Up   Top   ToC