Tech-invite  3GPPspecsRELsGlossariesSIP
Info21222324252627282931323334353637384‑5x

full Contents for  TS 23.222  Word version:   17.0.0

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 interconnenction [R16]
8.25.1  General
The procedures in this subclause corresponds to the architectural requirements on CAPIF interconnection.
8.25.2  Information flowsWord-p. 74
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 information
M
The information of the CAPIF core function which publishes APIs, may include identity, authentication and authorization information
Service API information
O (see NOTE 1)
The service API information includes the service API name, service API type, communication type, description, Serving Area Information (optional), interface details (e.g. IP address, port number, URI), protocols, version numbers, and data format.
Service API category
O (see NOTE 1)
The category of the service APIs to be published, (e.g. V2X, IoT)
Shareable information
O (see NOTE 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 and Service API category shall be present.
NOTE 2:
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

Result
M
Indicates the success or failure of publishing the service API information
Service API published information reference
O (see NOTE)
The information which can be used for referencing the information (set) about the published service API by the CCF which publishes service APIs

NOTE:
This information element is included when the Result indicates success.

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 information
M
Identity information of the CAPIF core function discovering service APIs
Query information
M
Criteria for discovering matching service APIs or CAPIF core function (e.g. service API type, Serving Area Information (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

Result
M
Indicates the success or failure of the discovery of the service API information
Service API information
O (see NOTE)
List of service APIs corresponding to the request, including API description such as service API name, service API type, Serving Area Information (optional), interface details (e.g. IP address, port number, URI), protocols, version, data format
CAPIF core function identity information
O (see NOTE)
Indicates the CAPIF core function matching the service API category in the query criteria

NOTE:
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-condition:
  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.
Up
  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.
  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 service APIs or the category information of the service APIs, the identity information of CCF-A, shareable information and CAPIF provider domain information if allowed to share. The API topology hiding may be enabled.
  3. CCF-B stores the service API information or service API category provided by the CCF-A.
  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-condition:
  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.
Up
  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.
  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.
  3. NOTE:
    The remaining steps are only applied when the service API category is included in the interconnection API publish request as described in subclause 8.25.2.1.
  4. 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.
  5. 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.
  6. 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.
Up
  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.
  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.
  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 information
M
Identity information of the API invoker requesting update
APIs for update
M
List of APIs that need update (e.g. enroll new API(s), disenroll API(s)).

8.26.2.2  Update API invoker API list response
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

Result
M
Indicates the completely successful or partially successful or failure of the update operation
API information
O (see NOTE 1)
List of APIs and the types of APIs that the API invoker can access
Reason
O (see NOTE 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).
Up
  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).
  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.
  3. NOTE:
    Completion of updating process can require explicit grant by the CAPIF administrator or the API management, which is left out-of-scope of this solution. CAPIF can handle the grant process internally without the need of explicit grant by the CAPIF administrator.
  4. 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. 79
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 information
M
The 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 information
M
Identity information of the entity requesting the routing information

8.27.2.2  Obtain routing information responseWord-p. 80
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 information
M
The identification information of the service API for which invocation is requested.
Routing rule information for service API invocation
M
Indicates the routing rule for service API invocation, e.g., mapping of IP address range and AEF identity, or mapping of area serving the service API and AEF identity.

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 is the AEF acting as service communication entry point for the service API, and AEF‑2 is the destination AEF for handling the service API.
Up
  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.
  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.
  3. The CAPIF core function creates routing rule information for the service API and sends obtain routing information response with the routing rule information.
  4. NOTE:
    Steps 2 and 3 can be performed before step 1and after receiving the API topology hiding notify as described in subclause 8.24.3.
  5. 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.
  6. The AEF‑1 forwards the incoming service API invocation request to AEF‑2.
  7. The AEF‑2 returns the service API invocation response to AEF‑1.
  8. 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.
Editor's Note: The security aspects of this procedure are FFS in SA3.
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 functions
M
List of API provider domain functions including role (e.g. AEF, APF, AMF) and, if required, specific security information.
Security information
M
Information for CAPIF core function to validate the registration request

8.28.2.2  Registration response
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 identities
M (see NOTE 1)
List of identities, for each successfully registered API provider domain function and any specific security information.
Security information
O
Information to be used by the API provider domain function in subsequent CAPIF API invocations. Provided when registration is successful.
Reason
O (see NOTE 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  ProcedureWord-p. 82
Figure 8.28.3-1 illustrates the procedure for registering API provider domain functions on the CAPIF core function.
Up
  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.
  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.
  3. The CAPIF core function sends the generated information in the registration response message to the API management function.
  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]
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.
Editor's Note: The security aspects of this procedure are FFS in SA3.
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 update
M
List of API provider domain functions requiring updates, including role (e.g. AEF, APF, AMF) and, if required, specific security information.
Security information
M
Information for CAPIF core function to validate the registration request

8.29.2.2  Registration update responseWord-p. 83
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 identities
M (see NOTE 1)
List of identities, for each successfully updated API provider domain function and any specific security information.
Security information
O
Information to be used by the API provider domain function in subsequent CAPIF API invocations. Provided when registration update is successful.
Reason
O (see NOTE 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  Procedure
Figure 8.29.3-1 illustrates the procedure for updating the registration information of the API provider domain functions on the CAPIF core function.
Up
  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.
  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.
  3. The CAPIF core function sends the updated information in the registration update response message to the API management function.
  4. The API management function configures the received information to the individual API provider domain functions.
Up

Up   Top   ToC