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).
Figure 8.6.2-1 illustrates the procedure for service API analytics enablement solution.
Pre-conditions:
-
ADAES acts as API management function in CAPIF.
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.
The following information flows are specified for service API analytics based on
clause 8.6.2.
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 ID | M | The information to determine the identity of the subscribing entity (consumer). |
Service API information | M | The service API name or type. |
Analytics ID | O |
The identifier of the analytics event. This ID can be for example "service API analytics".
|
Analytics type | M | The type of analytics for the event, e.g. statistics or predictions. |
Criteria | M | The 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 horizon | O | Time validity of the subscription request and time horizon for the predictions. |
Area of interest | O | Geographical or topological area for which the subscription applies. |
Notification reception information | O | The information of the subscribing entity for receiving the notifications for the event. |
Reporting requirements | O | It 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. |
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 |
Result | M | The result of the analytics subscription request (positive or negative acknowledgement). |
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 information | M | Identity information of the originated application querying service API log request. |
ADAES ID | M | Identity information of the ADAES. |
Service ID or UE ID | M | Identity of the application service or UE for which the historical API invocations apply. |
Target API(s) information | M | Information on target API or list of target APIs (name or type). |
> Query information | O | List of query filters such as invoker's ID and IP address, service API name and version, input parameters, and invocation result. |
> API aggregation abstraction flag | O | What type of aggregation or abstraction/filtering needs to be applied. |
Reporting configuration | O | The 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 validity | O | The geographical area for which the request applies. |
Time validity | O | The time validity for the request. |
Exposure level requirement | O | The level of exposure requirement (e.g. permissions on the logs like read/write/delete) for the logs to be exposed. |
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 |
Result | M | Identity information of the originated application querying service API log request. |
Service ID or UE ID | M | Identity of the application service or UE for which the API invocations apply. |
Target API (s) information | M | The target service API name or type. |
> Target API(s) logs | M | The 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 info | O | The time and area for which the reporting applies. |
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 ID | M | The information to determine the identity of the subscribing entity (consumer). |
Service API information | M | The service API name or type for which analytics apply. |
Analytics ID | O |
The identifier of the analytics event. This ID can be for example "service API analytics".
|
Analytics Output | M | Stats 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 level | O | For predictive analytics, the achieved confidence level can be provided. |
Area of validity | O | Geographical or topological area for which the analytics apply. |