Patent ID: 12192065

DETAILED DESCRIPTION

FIG.1shows a first network entity100and a second network entity101, according to embodiments of the disclosure, interacting with each other. The first network entity100is suitable for analytics generation of a mobile network, and the second network entity101is suitable for examining the analytics generation. The second network entity101may, or may not be, a consumer of the analytics. The analytics may be provided as an analytics service by the first network entity100, in the form of one or more analytics outputs.

The second network entity101is configured to provide, to the first network entity100, a request102for analytics information103associated with one or more generated analytics outputs. Accordingly, the first network entity100is configured to receive the request102provided by the second network entity101.

Further, the first network entity100is configured to provide the analytics information103to the second network entity101. The analytics information103comprises data information200used to generate the one or more generated analytics outputs201(seeFIG.2), wherein the data information200comprises reference to data202(seeFIG.2) or comprises data202itself. The analytics information103may comprise the data202used to generate the one or more analytics outputs201, or may comprise reference to the data202used to generate the one or more analytics outputs201.

The reference to the data202comprises information that allows obtaining the data202. For instance, the reference may comprise a pointer to the data202, or a link to the data202, or time stamp of receiving the data202etc. The reference may also indicate a storage location where the data202is stored, or may comprises information about the entity storing the data202. Accordingly, the second network entity101is configured to receive the analytics information103from the first network entity100.

In this way, the second network entity101may, for each analytics output, become aware of the data202that was used for generating that analytics output201.

The first network entity100and/or the second network entity101may be able to uniquely identify each individual analytics output201. The first network entity100may be able to map each uniquely identified generated analytics output201to the data202used for generating the analytics output201.

For example, for each piece of data202used for generating a given uniquely identified generated analytics output201, the first network entity100may keep a mapping of one or more of:identification information of collected data202;identification information of a source of the collected data202;a temporal description of the collected data202(e.g., an interval of time of collected data sample);one or more manipulation techniques (e.g., which kind of filtering, aggregation, classification, selection mechanism) applied to the collected data202.

The first network entity100may provide a service that may, e.g., upon request by the second network entity101, provide the data information200relating to the data202used for each individual analytics output201. A mapping among multiple consumers of the uniquely identified generated analytics output201is also possible.

The first network entity100and/or the second network entity101may comprise a processor or processing circuitry (not shown) configured to perform, conduct or initiate the various operations of the first network entity100and/or second network entity101described herein. The processing circuitry may comprise hardware and/or the processing circuitry may be controlled by software. The hardware may comprise analog circuitry or digital circuitry, or both analog and digital circuitry. The digital circuitry may comprise components such as application-specific integrated circuits (ASICs), field-programmable arrays (FPGAs), digital signal processors (DSPs), or multi-purpose processors.

The first network entity100and/or second network entity101may further comprise memory circuitry, which stores one or more instruction(s) that can be executed by the processor or by the processing circuitry, in particular under control of the software. For instance, the memory circuitry may comprise a non-transitory storage medium storing executable software code which, when executed by the processor or the processing circuitry, causes the various operations of the first network entity100and/or second network entity101to be performed.

In one embodiment, the processing circuitry comprises one or more processors and a non-transitory memory connected to the one or more processors. The non-transitory memory may carry executable program code which, when executed by the one or more processors, causes the first network entity100and/or second network entity101to perform, conduct or initiate the operations or methods described herein.

In particular, the first network entity101and the second network entity101may perform methods according to embodiments of the disclosure. In particular, the first network entity100may perform—as shown inFIG.1—a method for analytics generation according to the third aspect described in the summary part, and the second network entity101may perform —as shown inFIG.1—a method for examining analytics generation of a mobile network according to the fourth aspect described in the summary part.

FIG.2shows the first network entity according to an embodiment of the disclosure, which builds on the embodiment shown inFIG.1. In particular,FIG.2shows that the first network entity100may be configured to provide an analytics output201, wherein the analytics output201is generated based on certain data202.

The first network entity100can further provide the analytics information103associated to the analytics output201(as shown inFIG.1), wherein the provided analytics information103comprises the data information200related to the data202used for generating the analytics output201(as mentioned above, the data information200may comprise or be the data202, or may reference to the data202).

To this end, the analytics output201may be provided with an identification information203, so that the second network entity101can request the data information200for the particular analytics output202as identified by this identification information203.

In fact, two options of the first network entity100can be described with respect toFIG.2. The difference between these two options is in the way the analytics output201is identified: in the first option, the analytics output201may be identified with a timestamp, or with other information203(but not an extra identifier) that uniquely identifies the analytics output201.

In the second option, the analytics output202may be identified with an identifier203that is uniquely associated with that analytics output201. Note that these ways of identifying the analytics output201are only examples, and other ways could be used.

To support the above-described tracing capability of the first network entity100, which allows providing the appropriate analytics information103including the data information200associated with an analytics output201, the first network entity100may be further configured to somehow mark the data202used to derive the analytics output201. In an example, this marking could be realized by crating and/or maintaining mapping information300(e.g., a mapping table) as shown inFIG.3.

For instance, in a mobile network, like a 5G network, both the control plane and the management plane may store the data202in various memories or databases. This data202may be fed to one or more analytics functions—as for instance implemented by the first network entity100to provide the analytics service—wherein the analytics functions can derive one or more analytics outputs201, e.g., possible insights and/or recommendations, based on this data202.

The first network entity100may maintain the mapping information300. The mapping information300may comprise one or more entries301, wherein each entry301may be related to a generated analytics output201, and wherein each entry301may comprise an identification information203associated with the respective generated analytics output201. Further, each entry301may comprises data information200about the data202, which is or was used for generating the respective generated analytics output201.

InFIG.3, the mapping information300is exemplarily realized using a data structure called “KPI-Info-List per recommendation ID” (e.g., the data202is maintained in the data structure per analytics output201, wherein a list of the data202is referred to as the “KPI-Info-List” and the analytics output201is exemplarily referred to as “recommendation”).

Note that the recommendation ID refers to the second option described above, e.g., it refers to an identifier of the analytics output201. In the first option described above, for instance, the entire row (in the table shown inFIG.3representing the data structure) related to the analytics output201could serve for identifying the analytics output201.

In addition to identifying the analytics output201, the KPI-Info-List may store a list of so-called “KPI-info objects”, e.g., pieces of data202used for generating this analytics output201.

Assuming the data202is composed of values of various key performance indicators (KPIs) with their respective timestamps, the KPI-Info object may just record the initial timestamp and the final timestamp, together with every KPI identifier, and optionally together with the location of the database where it is stored.

Upon receiving the request102(e.g., a request getDataForRecommendation) from the second network entity101for analytics information103, the first network entity100may simply fetch the KPI-Info-List from that database according to the mapping information300, and may provide a link (reference) to the data202as data information200, as well as the timestamps of the data202used for generating the analytics output201.

Alternatively, the first network entity100may fetch the entire data202itself, and may then provide the data202to the second network entity101as the data information200.

In the following, exemplary implementations based on the first network entity100and the second network entity101, according to embodiments of the disclosure, will be described.

FIG.4andFIG.5relate to an embodiment for end-to-end (E2E) management to support the above described tracing capability.

FIG.4shows a Table 1, which illustrates a generic analytics service, exemplarily in ETSI GS ZSM002 V1.1.1 (2019-08). The tracing capability enables to request102analytics information103, including data information200about data202that was used to generate an analytics output201(in Table 1 the analytics output201is referred to as “result X (M)”, wherein the “M “proposes that this is a mandatory capability of the analytics service).

The procedure inFIG.5shows how the tracing capability of the first network entity100can be used by the second network entity101(here the second network entity101is also the consumer of the analytics service provided by the first network entity100).

FIG.5shows in particular the exemplary analytics service shown in Table 1 inFIG.4. An integration fabric500may be arranged between the first network entity100and the second network entity101. The integration fabric500may be an optional communication medium configured to transfer messages between the first network entity100(providing the analytics service) and the second network entity101(consuming the analytics service). A consumer of the analytics service could also be any other software/hardware entity, a managed entity, or a person.

The following steps present an example of the use of the tracing capability that can be used by the second network entity101.

The analytics function/service of the first network entity100is in normal processing, e.g., producing one or more analytics outputs201with the tracing capability enabled. This means that any generated analytics output201provided by the first network entity will have the tracing option enabled. Alternatively, the second network entity101could selectively enable tracing only for some generated analytics outputs201.

2/3. The analytics output201is generated published to the subscribed consumer(s) (here including the second network entity101), or to the integration fabric500which may relay it to the consumer(s). Alternatively the second network entity101could request a particular analytics output201.

4. In step 4 at least one of the analytics consumer(s) (here the second network entity101) would like to inspect the data202used for generating an analytics output201, which is identified with “XXX” as the identification information203. “XXX” may denote any mechanism usable to identify the analytics output201, such as a universally unique identifier (UUID) or a timestamp. Thus, it sends the request103indicating the identification information203to the first network entity101. Note that the request102for the analytics information103(i.e., in effect for the data202) could be for a set of analytics outputs201, not just a single analytics output201.

5/6. The tracing capability of the first network entity101may gather the respective data202(or pointers to the data202), i.e., may obtain the data information200, and may provide a reply including the analytics information103comprising the data information200to the second network entity101.

For an embodiment in 3rdgeneration partnership project (3GPP) SA5, a similar tracing capability can be implemented, thus allowing the management system (represented by the first network entity100) to provide one or more consumer(s) (including, e.g., the second network entity101) the data202that is used, for instance, by the MDAS for generating one or more analytics outputs201.

FIG.6toFIG.9relate to an implementation for a control plane analytics service, which is able to expose a relationship between a generated analytics output201(related to an analytics ID) and data (samples) used for generating the analytics output201(e.g., 3GPP SA2 based).

In this implementation, the analytics service is mapped to services provided by the NWDAF (as defined in 3GPP TS 23.501 and detailed in 3GPP TS 23.288). The first network entity100may comprise the NWDAF. In this case, there are two alternative implementations:

Option 1: Two changes are introduced in the NWDAF services.

First, the output parameters of the NWDAF services providing an analytics output201(for an analytics ID), e.g., Nnwdaf_AnalyticsSubscription_Notify and Nnwdaf_AnalyticsInfo_response, are extended with a new parameter, which uniquely identifies the mapping between the analytics output201and the data202that is used by the NWDAF100(e.g., by a machine learning (ML) engine, analytics model, big data inference engine, etc.).

Second, a new service dedicated to provide the analytics information103, which comprises the data information200about the data202(i.e., a reference to the data202or the data202itself) used for a given analytics output201generated by the NWDAF100, upon a received request102. The request102may contain the unique identifier of the mapping of the analytics output201to the data202used for the analytics output generation.

Option 2: Only a single change in the NWDAF services.

Introduction of a new service in the NWDAF100, which is able to provide the analytics information103, which comprises the data information200about the data202used for a given analytics output201generated by the NWDAF100, upon receiving a request102. The request102may contain a set of fields that uniquely identifies the analytics output201, and/or the analytics ID for which the analytics output201is provided, and/or the specific analytics output instance. For example, if multiple analytics outputs201for the same analytics ID are generated, each of these analytics outputs201is an analytics output instance. Further, the request102may contain an identification information of the consumer (e.g., and ID of the second network entity101) of the analytics output201.

Table 2 inFIG.6shows a dataset representing an implementation for mapping information300between a generated analytics output201and data202used for generating the analytics output201.

Table 3 inFIG.7shows an implementation of the described NWDAF service extensions/enhancements. Although not represented in Table 3, the same extension of parameters are applicable to the NWDAF services, which are related to the request/response model.

The need for data tracing can be defined either statically, e.g., hard-coded at the NWDAF100, or it could be indicated dynamically, e.g., via an analytics subscription parameter—as illustrated in Table 3.

The procedures shown inFIG.8andFIG.9are examples of how the services defined in Table 2 and Table 3 can be used, and examples of entities interacting with such services.

The interactions between the first network entity100(NWDAF) and the second network entity101(analytics consumer) shown inFIG.8, consider an implementation where the analytics consumer explicitly indicates to the NWDAF100—via a subscription/request800—the need for tracing data202used for analytics output generation regarding one or more analytics outputs201(for one or more analytic IDs).

The analytics consumer101may particularly invoke the NWDAF service Nnwdaf_AnalyticsInfo_Request_request (with the existing parameters as defined in TS 23.288). In addition, this request800may also include a parameter called “Activate Trace” set to “true”. The benefit of using this parameter is that the NWDAF100can obtain from the consumer101the indication, for which generated analytics output201the data202needs to be traced. The consumer101can accordingly use the request800as an activation request for tracing the data202. If this parameter is not sent, in an alternative, it may be up to the internal logic of the NWDAF100to decide when and which generated analytics output201should be generated, or the NWDAF100may be configured to trace all generated analytics output201. Further, the parameter in the request800can support a better resource usage of the NWDAF resources. Nevertheless, this parameter may also introduce a trade-off, as it also imposes that it is up to the consumer101to decide, which data202used for which analytics output generation will be actually traced.

Based on the received request800with the “Activate Trace” parameter set to true, the NWDAF100may create a new dataset called “Analytics Data Trace”, and may define a unique identifier “Analytics Data Trace ID”. This unique identifier can be either a UUID or an analytics data trace correlation identifier, which relates the request800of the analytics output201to the “Analytics Data Trace ID”. For instance, the analytics trace correlation identifier can be a function of the subscriber identification and the analytics ID.

The NWDAF100performs the analytics output generation (e.g., the NWDAF100) may calculate the analytics output201according to the requested “Analytics Target” and/or “Analytics Reporting” and/or “Analytics Filter” included in the request800).

For the generated analytics output201, the NWDAF100creates the dataset “Data Trace Information”, and defines the unique identifier “Data Trace ID” for the “Data Trace Information”. The “Data Trace Information” may be mapped and included as part of the “Analytics Data Trace” dataset for the “Analytics Data Trace ID” related to the generated analytics output201. When creating the “Data Trace Information”, the NWDAF100includes in this information all the fields defined in Table 2.

The NWDAF100sends a response801to the consumer101using the Nnwdaf_AnalyticsInfo_Request_response including the parameters as defined in TS 23.288, and in addition including the parameters “Analytics Data Trace ID”, and “Data Trace ID”. The first parameter is important for the consumer101to be able to query the NWDAF100to retrieve the actual information of the “Analytics Data Trace” for the analytics output201it consumed (or will consume in the future). The second parameter is important in the case of multiple analytics outputs201generated for the same analytics ID. In this case, the consumer101can also request only the “Data Trace Information” for an analytics output201it received, not needing to retrieve all the “Data Trace information” for all received analytics outputs201.

The NWDAF100exposes the service Nnwdaf_AnalyticsDataTrace that can be invoked by the consumer101to retrieve—as respective implementation of the data information200comprised in the analytics information103—either the records of the “Analytics Data Trace” for a given or all generated analytics outputs201(for one or more analytics IDs), and/or all or some records of the “Data Trace Information” for a given generated analytics output201. This service exposes the operation for a query request (see step 6a), that produces a query response (see step 6b).

6a. The consumer101can invoke the Nnwdaf_AnalyticsDataTrace_Query_request service operation, in order to provide the request102, with the parameters that can specify the target “Analytics Data Trace” dataset, which the consumer101wants to retrieve.FIG.8shows the example of a query operation with Option 1 (as described in Table 3). In this case, the consumer101indicates the identifier “Analytics Data Trace ID” of the “Analytics Data Trace” dataset it wants to retrieve, and optionally it also indicates one or more “Data Trace ID” related to the “Data Trace Information” that should be returned. These two parameters are used by the NWDAF100as filters, in order to select the data information200(“Analytics Data Trace” and/or “Data Trace Information”) in the analytics information103, to be retrieved and provided to the consumer101. In the example, all “Data Trace Information” associated with the “Analytics Data Trace” according to the “Analytics Trace ID” may be returned.

6b. This implementation shows the option, in which the NWDAF100sends a response802to the request101, and thus returns the actual “Analytics Data Trace” dataset, as the analytics information103including the data information200, associated with the requested “Analytics Data Trace ID” (as per example, but if more “Analytics Data Trace” were indicated in the query request, the return would be a list of “Analytics Data Trace” datasets).

The interactions described inFIG.9consider the possible implementation where the following behaviors are enabled. InFIG.9, the analytics consumer900consumes analytics output(s)201from the NWDAF (first network entity100). However, the OAM (second network entity101) may be suitable for examining the analytics generation.

The NWDAF100is configured to trigger the tracing of any analytics output201that is generated. In this case, the parameter “Activate Trace” is not required to be included (and set to “true”) in the request800and/or subscription of the NWDAF services for analytics output generation. Eventually such “Activate Trace” parameter may be set to “false”, in case the analytics consumer101of the NWDAF100explicitly decides that a data tracing for a requested analytics output201should not be performed by the NWDAF100. If this is the case, none of the steps related to the creation and association of the “Analytics Data Trace” dataset and the “Data Trace Information” dataset, may be performed by the NWDAF100.

In this implementation, the Option 2 mode of interaction as described in Table 3 is considered. In this case, there are no changes in parameters of the NWDAF services for notification and/or response on the generated analytics output201. With this mode of operation, the difference is the type of parameters that are used for querying the analytics information103including the data information200via the Nnwdaf_AnalyticsDataTrace_Query_request operation (request102). The OAM101as consumed of the NWDAF query service is not aware of the “Analytics Data Trace ID” nor of the “Data Trace ID”. Therefore, there are two possibilities for the OAM101to retrieve the “Analytics Data Trace” and “Data Trace information” datasets (i.e., the data information200in the analytics information103for an analytics output201):

Alternative 1 (with operation Option 2): The OAM101uses only the Nnwdaf_AnalyticsDataTrace_Query_request operation from the NWDAF100, and uses as filter to request the analytics information103including the data information200, information as indicated in Table 3 for Option 2. For instance, the request102may include the analytics ID (e.g., to support the identification of the “Analytics Data Trace ID”) and/or correlation information (e.g., to support the identification of the “Data Trace ID”).

Alternative 2 (with operation Option 2): The OAM101invokes the Nnwdaf_AnalyticsDataTrace_List_request operation from the NWDAF100and obtains in response a list of one or more “Analytics Trace ID” and/or a list of one or more “Data Trace ID”. The OAM101can use as filter for this service operation, the fields listed in the Table 3, for instance, per type of analytics ID, or per NWDAF100that generated the analytics ID, or per analytics output201, or per consumer of the analytics ID. This type of operation is useful when the consumer of the “Analytics Data Trace” (i.e., the data information200in the analytics information103) is not the same entity that consumed the analytics itself (the analytics consumer900). This is the implementation example described inFIG.9, where the entity consuming the “Analytics Data Trace” is the OAM101. The response901of Nnwdaf_AnalyticsDataTrace_List service operation may contain the list of one or more “Analytics Data Trace ID” and/or the list of one or more “Data Trace ID” matching the provided filters at the request102. Optionally, the response901could include the actual datasets of the “Analytics Data Trace” associated with the “Analytics Data Trace ID” and/or the “Data Trace Information” related to the “Data Trace ID” and/or a storage reference to retrieve these datasets (i.e., the data information200represented by the “Analytics Data Trace” and/or the “Data Trace Information” may be reference to data202or data202itself). In this implementation, the last case is described. When the datasets and/or the references for the storage of the datasets are not included in the response of the Nnwdaf_AnalyticsDataTrace_List service operation, the OAM101would still be configured to invoke the operation Nnwdaf_AnalyticsDataTrace_Query_request from the NWDAF100to actually retrieve the desired data information200, based on the retrieved list of “Analytics Data Trace ID” and/or list of “Data Trace ID” from the response of the Nnwdaf_AnalyticsDataTrace_List service operation invocation.

In this implementation, the “Storage reference” included in the response901of the Nnwdaf_AnalyticsDataTrace_List service operation invocation may be a reference to a Data Lake entity902of the system.

The detailed steps of this implementation are described with respect toFIG.9:

An analytics consumer900of an analytics outputs201from the NWDAF100invokes the NWDAF service Nnwdaf_AnalyticsSubscription_Subscribe with the existing parameters as defined in TS 23.288.

The NWDAF100creates the new dataset “Analytics Data Trace”, and defines the unique identifier “Analytics Data Trace ID”. This identifier can be either a UUID or an analytics trace correlation identifier, which relates the request800of the analytics ID to such “Analytics Data Trace ID”. For instance, the correlation can be a function of the subscriber identification and the analytics ID.

Steps 3-5 can be repeated, until the conditions for the end of the subscription to receive the requested analytics ID in step 1 are reached.

The NWDAF100performs the analytics output generation (e.g., the NWDAF100calculates the analytics output201according to the requested “Analytics Target” and/or “Analytics Reporting” and/or “Analytics Filter” included in the request800).

For the generated analytics output201, the NWDAF100creates the “Data Trace Information” and defines the unique identifier “Data Trace ID” for the “Data Trace Information”. The “Data Trace Information” is mapped and included as part of the “Analytics Data Trace” dataset for the “Analytics Trace ID” related to the generated analytics ID. When creating the “Data Trace Information”, the NWDAF100includes in this information all the fields defined in Table 2.

The NWDAF100sends a response to the consumer900using the Nnwdaf_AnalyticsInfo_Request_response including the parameters as defined in TS 23.288.

The OAM101(e.g., upon the need to evaluate the performance of the algorithm used by the NWDAF100for the analytics ID Service Experience consumed by service management function (SMF) for a user plane (UP) optimization) requires the “Analytics Data Trace” information for an analytics ID for an analytics consumer900of such analytics ID. The OAM101invokes the Nnwdaf_AnalyticsDataTrace_List_request operation from the NWDAF100, in order to provide the requests102, using as filter the NF ID and the analytics ID. In this case, the OAM101wants to retrieve all the “Data Trace Information” generated for the analytics ID for such NF ID consumer. This filter information is used by NWDAF100to filter the “Analytics Data Trace” datasets, whose fields (as described in Table 3) are matching the filter information received in the service operation request. Then, the operation Nnwdaf_AnalyticsDataTrace_List_response (e.g., the output parameters indicated in Table 3) from the NWDAF100provides a response901, which will contain the dataset of “Analytics Data Trace ID” for the requested analytics ID and NF consumer including the “Data Trace Information”, as the analytics information103including the data information200, as well as the reference for the entity storing such dataset (e.g., the Data Lake902).

Based on the retrieved information from the NWDAF100, the OAM101further interacts with the Data Lake902to retrieve the information associated with the “Analytics Data Trace ID”.

The present disclosure has been described in conjunction with various embodiments as examples as well as implementations. However, other variations can be understood and effected by those persons skilled in the art and practicing the claimed disclosure, from the studies of the drawings, this disclosure and the independent claims. In the claims as well as in the description the word “comprising” does not exclude other elements or steps and the indefinite article “a” or “an” does not exclude a plurality. A single element or other unit may fulfill the functions of several entities or items recited in the claims. The mere fact that certain measures are recited in the mutual different dependent claims does not indicate that a combination of these measures cannot be used in an advantageous implementation.