Tech-invite3GPPspaceIETFspace
21222324252627282931323334353637384‑5x

Content for  TS 23.436  Word version:  19.2.0

Top   Top   Up   Prev   Next
0…   5…   6…   8…   8.3…   8.4…   8.5…   8.6…   8.7…   8.8…   8.9…   8.10…   8.11…   8.12…   8.13…   8.14…   8.15…   8.16…   9…   9.3…   9.4…   A…

 

8.6  Procedure for supporting service API analyticsp. 42

8.6.1  Generalp. 42

This clause describes the procedure for supporting service API analytics. Such analytics can be for one or more service APIs for a service produced by one or more service producers within the 5GS or enablement layer or the DN side (e.g., application server).

8.6.2  Procedurep. 42

Figure 8.6.2-1 illustrates the procedure for service API analytics enablement solution.
Pre-conditions:
  1. ADAES acts as API management function in CAPIF.
Reproduction of 3GPP TS 23.436, Fig. 8.6.2-1: Service API analytics procedure
Up
Step 1.
The VAL server sends a service API event subscription request to the ADAE server to receive analytics for one or more service APIs.
Step 2.
Upon receiving the event subscription request from the subscribing entity, the ADAE server checks for the relevant authorization for the event subscription. If the authorization is successful, the ADAE server stores the subscription information.
Step 3.
The ADAE server sends a service API event subscription response indicating successful subscription
Step 4.
Upon sending the subscription response, the ADAE server requests to collect API logs to be used to derive analytics and triggers API invocation log pull request towards the CAPIF core function. The API invocation log fetch request indicates the API (or list of APIs) for which logs are required. Based on the ADAE server deployment, this can be a Query service API log request which is performed via CAPIF_Auditing API as specified in TS 23.222.
Step 5.
The CCF authorizes the request and fetches the API logs from the storage unit. CCF then sends the requested information to the ADAE server via a query service API log response.
Step 6.
The ADAES may also request service API historical analytics /data from A-ADRF for the corresponding service APIs.
Step 7.
Based on the request, the ADAES receives historical analytics/data for the service APIs from the A-ADRF.
Step 8.
The ADAE server authorizes and anonymizes the API logs (if not performed by CCF) and abstracts based on exposure level. The exposure level can be known based on pre-configuration by the OAM or based on the subscription and type of invoker. The ADAE server then derives analytics on the target service API(s) based on the logs received from the CCF. Such analytics are predictions/stats for the API status based on the analytics event.
Step 9.
The ADAE server sends the analytics as event notifications to all the subscribing entities that have subscribed for the event matching the criteria. If a notification reception information is available as part of the subscribing entity event subscription, then the notification reception information is used by the ADAE server to send event notifications to the subscribing entity.
Up

8.6.3  Information flowsp. 43

8.6.3.1  Generalp. 43

The following information flows are specified for service API analytics based on clause 8.6.2.

8.6.3.2  Service API event subscription requestp. 43

Table 8.6.3.2-1 describes information elements for the service API event subscription request from the consumer (VAL server, API provider) to the ADAE server.
Information element Status Description
Consumer IDMThe information to determine the identity of the subscribing entity (consumer).
Service API informationMThe service API name or type.
Analytics IDO The identifier of the analytics event. This ID can be for example "service API analytics".
Analytics typeMThe type of analytics for the event, e.g. statistics or predictions.
CriteriaMThe event criteria include event type information relevant to the prediction or stats on the number of failure API invocations, API availability, frequency and occurrence of API version changes, API location changes for the target API, etc.
Time Validity and horizonOTime validity of the subscription request and time horizon for the predictions.
Area of interestOGeographical or topological area for which the subscription applies.
Notification reception informationOThe information of the subscribing entity for receiving the notifications for the event.
Reporting requirementsOIt describes the requirements for analytics reporting. This requirement may include e.g. the type and frequency of reporting (periodic or event triggered), the reporting periodicity in case of periodic, and reporting thresholds.
Up

8.6.3.3  Service API event subscription responsep. 43

Table 8.6.3.3-1 describes information elements for the service API event subscription response to the consumer (VAL server, API provider) from the ADAE server.
Information element Status Description
ResultMThe result of the analytics subscription request (positive or negative acknowledgement).
Up

8.6.3.4  Historical service API logs requestp. 44

Table 8.6.3.4-1 describes information elements for the historical service API logs request from the ADAE server to the A-ADRF.
Information element Status Description
Service API log requestor informationMIdentity information of the originated application querying service API log request.
ADAES IDMIdentity information of the ADAES.
Service ID or UE IDMIdentity of the application service or UE for which the historical API invocations apply.
Target API(s) informationMInformation on target API or list of target APIs (name or type).
> Query informationOList of query filters such as invoker's ID and IP address, service API name and version, input parameters, and invocation result.
> API aggregation abstraction flagOWhat type of aggregation or abstraction/filtering needs to be applied.
Reporting configurationOThe configuration for the logs reporting. This requirement may include e.g. the frequency of reporting (periodic), the reporting periodicity in case of periodic, and reporting thresholds, whether data abstraction is needed or not.
Area of validityOThe geographical area for which the request applies.
Time validityOThe time validity for the request.
Exposure level requirementOThe level of exposure requirement (e.g. permissions on the logs like read/write/delete) for the logs to be exposed.
Up

8.6.3.5  Historical service API logs responsep. 44

Table 8.6.3.5-1 describes information elements for the historical service API logs response to the ADAE server from the A-ADRF.
Information element Status Description
ResultMIdentity information of the originated application querying service API log request.
Service ID or UE IDMIdentity of the application service or UE for which the API invocations apply.
Target API (s) informationMThe target service API name or type.
> Target API(s) logsMThe API logs based on the subscription event. This may include the number of failure API invocations, API availability, frequency and occurrence of API version changes, API location changes for the target API, API throttling events, number of API invocations for a given area and time etc.
> Reporting infoOThe time and area for which the reporting applies.
Up

8.6.3.6  Service API analytics notificationp. 45

Table 8.6.3.6-1 describes information elements for the service API analytics notification to the subscriber/consumer from the ADAE server.
Information element Status Description
Consumer IDMThe information to determine the identity of the subscribing entity (consumer).
Service API informationMThe service API name or type for which analytics apply.
Analytics IDO The identifier of the analytics event. This ID can be for example "service API analytics".
Analytics OutputMStats or predictions based on abstracted or anonymized API logs (for example number of failure API invocations, API availability, frequency and occurrence of API version changes, API location changes for the target API, API throttling events, number of API invocations for a given area and time, API load statistics for a given edge network, etc).
Confidence levelOFor predictive analytics, the achieved confidence level can be provided.
Area of validityOGeographical or topological area for which the analytics apply.
Up

Up   Top   ToC