Content for &nbsp; TS 23.222 &nbsp; Word version:&nbsp; 19.3.0

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.

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.

Figure 8.25.3.2-1: Service API discovery involving multiple CCFs

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.

8.25.3.2 Service API discovery involving multiple CCFs p. 85

This subclause describes a procedure for service API discovery involving multiple CCFs

Pre-conditions:

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.
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, Fig. 8.25.3.2-1: Service API discovery involving multiple CCFs

The API invoker sends a service API discover request to the CCF-A. It includes the API invoker identity and query information.

The CCF-A verifies the identity of the API invoker and retrieves the stored service API(s) information. The information of CCF-B matching the discovery criteria is returned to API invoker in the service API discover response.

Figure 8.25.3.3-1: Service API discovery for CAPIF interconnection

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.

8.25.3.3 Service API discovery for CAPIF interconnection p. 86

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:

The CCF-A is configured with the CCF-B information.
The CCF-B is configured with the CCF-A information.
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, Fig. 8.25.3.3-1: Service API discovery for CAPIF interconnection

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.

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.

Figure 8.25.3.4-1: Interconnection API unpublish

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.

8.25.3.4 Service API unpublish for CAPIF interconnection |R19| p. 87

This clause describes the procedure for service API unpublish for CAPIF interconnection.

Pre-condition:

CCF-A sends an interconnection API unpublish request to CCF-B. The request includes a service API published information reference. If the shareable information IE was present in the interconnection API publish request (see clause 8.25.2.1), the API unpublish request should be forwarded to the provided list of CAPIF provider domain information during the publish procedure.
CCF-B is configured as the designated CAPIF core function in the trust domain of CAPIF provider A.
CCF-A has successfully published service APIs to the designated CCF (i.e., CCF-B) using the procedure in clause 8.25.3.1.

Reproduction of 3GPP TS 23.222, Fig. 8.25.3.4-1: Interconnection API unpublish

CCF-A sends an interconnection API unpublish request to CCF-B. The request may include a set of (previously published) service API information. If the shareable information IE was present in the interconnection API publish request (see clause 8.25.2.1), the API unpublish request should be forwarded to the provided list of CAPIF provider domain information during the publish procedure.

Upon receiving the interconnection API unpublish request, the CCF-B checks whether the CCF-A is authorized to unpublish service APIs. If the check is successful, CCF-B will remove the requested service API information from the API registry.

Figure 8.25.3.5-1: Retrieve service APIs for CAPIF interconnection

CCF-B sends an interconnection API unpublish response to CCF-A containing the operation result and triggers notifications to subscribed API invokers (if any) as described in subclause 8.8.4.

8.25.3.5 Retrieve service APIs for CAPIF interconnection |R19| p. 88

This clause describes the procedure to retrieve service APIs information in a CAPIF interconnection scenario.

Pre-condition:

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. 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.
CCF-B is configured as the designated CAPIF core function in the trust domain of CAPIF provider A.

Reproduction of 3GPP TS 23.222, Fig. 8.25.3.5-1: Retrieve service APIs for CAPIF interconnection

CCF-A sends an interconnection get service API request to CCF-B with service API published information reference provided by the CAPIF core function when the service API was published.

Upon receiving interconnection get service API request, CCF-B checks whether CCF-A is authorized to get the published service APIs information. If the check is successful, the corresponding service API information is retrieved from the CAPIF core function (API registry).

Figure 8.25.3.6-1: Update service APIs for CAPIF interconnection

CCF-B sends a service API get response to CCF-A which includes the requested service API information if the retrieval operation was successful.

8.25.3.6 Update service APIs for CAPIF interconnection |R19| p. 89

Figure 8.25.3.6-1 illustrates the procedure for updating the published service APIs information by a CAPIF core function.

Pre-conditions:

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. 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.
CCF-B is configured as the designated CAPIF core function in the trust domain of CAPIF provider A.

Reproduction of 3GPP TS 23.222, Fig. 8.25.3.6-1: Update service APIs for CAPIF interconnection

The CCF-A sends an interconnection update service API request to the CCF-B, including the information in Table 8.25.2.9-1.

Upon receiving the interconnection update service API request, the CCF-B checks whether the CCF-A is authorized to update the published service APIs information. If the check is successful, the service API information provided by the CCF-A is updated at the CCF-B (API registry).