阅读说明：本技术 数据处理实体 (Data processing entity ) 是由 朴汶伊 伊尚·瓦什纳维 里卡多·特里维松诺 于 2019-05-06 设计创作，主要内容包括：本发明涉及一种用于处理网络实体之间的监测数据的数据处理实体,其中,所述数据处理实体用于：从第一网络实体获取第一数据请求,其中,所述第一数据请求包括第一数据标识符,所述第一数据标识符与监测数据相关；从一个或多个其它网络实体获取一个或多个第二数据标识符,其中,所述一个或多个第二数据标识符与待从一个或多个其它网络实体收集的所述监测数据相关；根据所述第一数据标识符和所述一个或多个第二数据标识符,生成关联信息；根据所述关联信息,确定所述待收集的监测数据是否已经在所述数据处理实体处可用,或者确定所述待收集的监测数据是否应该由所述数据处理实体从所述一个或多个其它网络实体收集。(The invention relates to a data processing entity for processing monitoring data between network entities, wherein the data processing entity is configured to: obtaining a first data request from a first network entity, wherein the first data request includes a first data identifier, the first data identifier being associated with monitoring data; obtaining one or more second data identifiers from one or more other network entities, wherein the one or more second data identifiers relate to the monitoring data to be collected from one or more other network entities; generating association information according to the first data identifier and the one or more second data identifiers; determining, from the association information, whether the monitoring data to be collected is already available at the data processing entity or whether the monitoring data to be collected should be collected by the data processing entity from the one or more other network entities.)

1. A data processing entity (101) for processing monitoring data between network entities, characterized in that the data processing entity is configured to:

obtaining a first data request from a first network entity, wherein the first data request includes a first data identifier, the first data identifier being associated with monitoring data;

obtaining one or more second data identifiers from one or more other network entities, wherein the one or more second data identifiers relate to the monitoring data to be collected from one or more other network entities;

generating association information according to the first data identifier and the one or more second data identifiers;

determining, from the association information, whether the monitoring data to be collected is already available at the data processing entity (101) or whether the monitoring data to be collected should be collected by the data processing entity (101) from the one or more other network entities.

2. The data processing entity (101) of claim 1,

-if the monitoring data to be collected is not available (in particular according to a subscription), the data processing entity (101) is configured to: retrieving the monitoring data to be collected from the one or more other network entities in accordance with at least one other data request, the data processing entity being configured to: after receiving the retrieved monitoring data, sending and/or forwarding the retrieved monitoring data to be collected to the first network entity; alternatively, the first and second electrodes may be,

-if said monitoring data is available at said data processing entity, said data processing entity (101) for sending and/or forwarding said available monitoring data to said first network entity.

3. The data processing entity (101) of any one of the preceding claims, wherein the data processing entity (101) is configured to: determining that the monitoring data is already available at the data processing entity (101) if the data processor (101) can receive the monitoring data from the one or more other network entities according to a data subscription.

4. The data processing entity (101) of any one of the preceding claims, wherein the data processing entity (101) is configured to: generating the at least one further data request if the monitoring data is not available at the data processing entity (101), wherein the at least one further data request comprises at least one further data identifier related to at least one subset of the monitoring data to be collected and/or requests a subscription to at least one subset of the monitoring data from at least one further network entity.

5. The data processing entity (101) of claim 4, wherein the data processing entity (101) is configured to: obtaining a second data identifier as the at least one other data identifier, wherein the second data identifier is related to monitoring data to be collected from a second network entity; the data processing entity (101) is configured to obtain the second data identifier, in particular, before receiving the first data request.

6. The data processing entity (101) of any one of the preceding claims, wherein the data processing entity (101) is configured to: generating the first data identifier and, in particular, transmitting the first data identifier to the first network entity prior to receiving the first data request.

7. The data processing entity (101) of any one of the preceding claims, wherein the data processing entity (101) is configured to associate the first data identifier with at least one data collection parameter in order to associate the first data identifier with the monitoring data to be collected, wherein the at least one data collection parameter is the second data identifier and indicates which data constitutes the monitoring data or a specific subset of monitoring data.

8. The data processing entity (101) of any one of the preceding claims, wherein the first identifier is constituted by and/or comprises at least one of the following identifiers: a data open identifier, in particular a data analysis identifier related to analysis information, the second identifier being constituted by and/or comprising at least one of the following identifiers: an event identifier, in particular an identifier relating to monitoring data to be collected from the second network entity, e.g. UE reachability.

9. The data processing entity (101) of any one of the preceding claims, wherein the first data request further comprises: filter information, in particular filtering a geographical area and/or a threshold value associated with the first identifier; and/or data reporting information and/or a target of data reporting indication, the other data request further comprising: filter information, in particular filtering of geographical areas and/or thresholds associated with said second identifier, and/or data reporting information and/or a target of data reporting instructions.

10. The data processing entity (101) of any one of the preceding claims, wherein the data processing entity (101) is a network data analysis function (NWDAF) entity, wherein the first network entity is a NWDAF service user, wherein the data processing entity (101) is configured to receive the first data request, wherein the first data request indicates a subscription and/or a request for analysis information, wherein the first data identifier is an analysis identifier, wherein the processor is configured to associate the analysis identifier and/or the first data request with data to be collected as the monitoring data, wherein the monitoring data to be collected is associated with at least one event identifier and/or event filter information and/or event reporting information and/or target-like monitoring parameter indicated by data, the data processing entity (101) is configured to: if a new subscription for analysis information is necessary, it is decided whether to trigger a collection of data from the one or more other network entities or whether the requested analysis information has been provided to the data processing entity according to an existing subscription for analysis information from the one or more other network entities (101).

11. The data processing entity (101) of any one of the preceding claims, the data processing entity (101) is a network data analysis function (NWDAF) entity, the first network entity is an NWDAF service user, wherein the data processing entity (101) is configured to receive a subscription termination request from the first network entity, the subscription termination request indicating a termination of an analysis information subscription, the data processing entity (101) being configured to terminate transmission of monitoring data related to the terminated subscription to the first network entity, the data processing entity (101) is configured to modify an association of a subscription request from the first network entity with monitoring data to be collected, or, the data processing entity is configured to delete an association relationship between the subscription request from the first network entity and the monitoring data to be collected.

12. The data processing entity (101) of any one of the preceding claims, wherein the data processing entity (101) is configured to determine a data collection procedure for collecting data from the one or more other network entities to obtain the monitoring data.

13. The data processing entity (101) of any one of the preceding claims, wherein the data processing entity is configured to determine the one or more other network entities from which data should be collected to obtain the monitoring data, based on the received first data request and/or the first data identifier.

14. The data processing entity (101) of any one of the preceding claims, wherein the data processing entity (101) is configured to receive the one or more second data identifiers from the one or more other network entities, wherein the one or more second data identifiers identify the monitoring data to be collected from the one or more other network entities.

15. A data processing method for processing monitoring data between network entities, comprising:

obtaining (401) a first data request from a first network entity, wherein the first data request comprises a first data identifier, the first data identifier relating to monitoring data;

obtaining (403) one or more second data identifiers from one or more other network entities, wherein the one or more second data identifiers relate to the monitoring data to be collected from one or more other network entities;

generating (405) association information from the first data identifier and the one or more second data identifiers;

determining (407) whether the monitoring data to be collected is already available at the data processing entity or whether the monitoring data to be collected should be collected from the one or more other network entities, depending on the association information.

Technical Field

The present invention relates to a Data handler entity (Data handler) in a communication network, in particular in a 5G or 3GPP communication network.

Background

In a 5G communication network, generally referred to as a 5G System (5G System, 5GS), it is necessary to support monitoring services for different network elements, such as user entities, base stations, or controllers, for different purposes. Different functional components of the 5GS require monitoring data from other different functional components of the 5 GS. In other words, a logical entity of the 5GS functional component, i.e., a Network Function (NF), generates monitoring data used by other logical entities of the 5GS functional component (e.g., other NFs).

The monitoring data may be performance data related to a network, a service, NSI, NSSI or NF etc., or fault supervision data or application data or data related to data analysis, or warranty data or SLA data or security data or data related to a UE or a user. Each logical entity of the 5GS functional component (e.g., application, warranty, or data analysis) may be a monitoring data generating entity of a particular monitoring service and/or a monitoring data consumer of a particular monitoring service, which entities are defined by way of example as follows:

a monitoring data generating entity: a network entity (e.g., NF in 5GS) produces any type of monitoring data related to a 5GS network or network slice, such as Key Performance Indicators (KPIs), Service Level Agreements (SLAs), analytical data, security, performance (PM, FM) related to network or network slice resources, services, or applications.

Monitoring data user: a network entity (e.g., NF in 5GS) uses any type of monitoring data related to the 5GS network and network slice, e.g., network/network slice resources, service or application related KPIs, SLAs, analytics data, security, performance (e.g., PM, FM).

As for the 3GPP standard, the 3GPP SA5 range focuses on network and/or network slice operation procedures related to the 5G CN Management Plane (MP), and the 3GPP SA2 range highlights the 5G CN Control Plane (CP) for signaling and the User Plane (UP) for logical network slices of payload traffic. However, in the current 5GS, there are some limitations related to monitoring services.

In 5G CN, monitoring services (e.g., PM services for NSI/NSSI/NF) are performed only in the 3GPP management plane. However, the 5GC CP may require its own monitoring service, e.g., collecting UP-related monitoring data from the UP.

The current monitoring services provided by the Management Plane (MP) may not be sufficient to support vertical service requirements, e.g., URLLC slices requiring very low latency. If the monitoring data passes through the MP NF (e.g., PM/FM) from CP/UP NF to other CP/UP NFs, the data collection time through the MP may not meet URLLC requirements (e.g., 5ms for E2E latency).

For example, a monitoring service (e.g., PM service) from the MP collects monitoring data from the CP or UP NF and supports monitoring data consumers (e.g., NWDAF in CP) of any network entity (e.g., NF) in CP, UP, and MP. Since the interaction between CP and UP functions is typically for UP related monitoring data (e.g., NWDAF uses UP monitoring data), collecting data by MP monitoring services is practically infeasible. Initially, MPs define monitoring services (i.e., PM/FM services) to collect monitoring data including CPs and UPs related to network performance and network slices. However, there is a need for directional interaction of monitoring services between CP and UP to reduce time and complexity.

Another limitation is more important for Ultra-high reliability Ultra-Low Latency Communication (URLLC) applications. Since URLLC applications require real-time operational evaluation, the delay requirement will not be met if the monitored data passes through the MP. As shown, the NWDAF requires different time delays to collect monitoring data from the UP, CP and MP. Clearly, if there is a monitoring service (like the PM service) for CP and UP, the required data collection latency can be significantly reduced.

Therefore, there is a need for more efficient processing of monitoring data in a communication network.

Disclosure of Invention

Embodiments of the invention are defined by the features of the independent claims and other advantageous implementations of the embodiments are defined by the features of the dependent claims.

In a first aspect, the present invention relates to a data processing entity for processing monitoring data between network entities, wherein the data processing entity is configured to: obtaining a first data request from a first network entity, wherein the first data request includes a first data identifier, the first data identifier being associated with monitoring data; obtaining one or more second data identifiers from one or more other network entities, wherein the one or more second data identifiers relate to the monitoring data to be collected from one or more other network entities; generating association information according to the first data identifier and the one or more second data identifiers; determining, from the association information, whether the monitoring data to be collected is already available at the data processing entity or whether the monitoring data to be collected should be collected by the data processing entity from the one or more other network entities.

Thus, data collection efficiency may be improved, as there is no need to collect monitoring data already available in the data processing entity. This may reduce data traffic.

The data processing entity may be implemented as a service within a network entity, or may be implemented as a network entity. The data processing entity may be a network entity or a network device or a network component, wherein the network entity or network device may be a physical or logical entity. For example, the Data processing entity may be a Network Data analysis Function (NWDAF) defined in 3 GPP. The Data processing entity may be Operation Administration and Management (OAM) or Management Data Analysis Function (MDAF) defined in 3 GPP. The data processing entity may be a Network Exposure Function (NEF).

Where the data processing entity is an NWDAF, an example of the first data request is a subscription and/or request for analytical information. Further, the first data identifier associated with the subscription to the analysis information (i.e., the first data request) may be an analysis ID or the like that uniquely identifies the analysis information. In particular, when a request and/or subscription for analysis information is received, the NWDAF generates association information based on the request and/or subscription for analysis information and the required data to be collected. Based on the association information, the NWDAF may decide whether a new data collection needs to be triggered.

A user of a data processing entity is a network entity and/or a network device and/or a network component that needs the data processing entity to provide information. Any 5GC NF/AF/OAM entity or component defined in 3GPP may be the first network entity.

The information provided by the data processing entity may be analysis information or performance data or fault supervision data or assurance data or security data or management data, such as a Network or service or Network Slice Instance (NSI) or Network Slice Subnet Instance (NSSI) or Network Function (NF) or Application Function (AF) or OAM and/or user correlation. If the information provided by the data processing entity is analysis information, the analysis information may be, for example, specific analysis information of network performance or network slice performance, or NF load information, etc.

The monitoring data sent to and/or forwarded to the first network entity may be raw data such as performance data or may be processed data such as analysis data. Examples of monitoring data are data related to performance or fault supervision of a network, a service, an NSI, an NSSI or an NF; data related to an application or UE or user; data relating to analysis information and/or guarantees or service level agreements and/or security, in particular data relating to a network or a service or an NSI or an NSSI or an NF or a UE or an application.

The data processing entity may forward the monitoring data without any change, or may process the monitoring data before sending the data.

The second data identifier is used to obtain monitoring data provided by a data generating entity (i.e. one or more other network entities). Basically, the second data identifier is defined and supported by the data generating entity (e.g. comprising 5G NF/AF/OAM). The data processing entity obtains the list of second data identifiers from the data generating entity by: for example (i) by pre-configuring the list at the data processing entity, and/or (ii) by exchanging said second data identifier via a third party network entity and/or directly. One specific example of the second data identifier is an event identifier or event ID, where the event ID is used to acquire monitoring data provided by any 5GC NF/AF defined in 3 GPP. For example, the event ID may be set to, for example, "UE reachability" and/or "roaming status" from the 5G NF.

To obtain the correlation information, the corresponding indices may be compared with each other or mapped to each other.

For example, when the data processing entity is an NWDAF, the NWDAF has an analysis ID for identifying specific analysis information (e.g., "network performance", "UE mobility", "UE communication", "NF load information"). The NWDAF obtains an event ID of monitoring data to be collected from a monitoring data generator. The NWDAF generates the association information by creating a mapping table that indicates which second data identifiers are required for which requested analysis IDs, e.g., time IDs from monitoring data producing entities.

In another embodiment of the first aspect, the data processing entity comprises a network interface and/or a service for receiving and/or obtaining the respective network identifier and for communicating with the network entity. The first network entity may be a data consumer using monitoring data and the one or more other network entities may be data generating entities generating the monitoring data. The data processing entity may comprise one or more processors for processing data.

In another embodiment of the first aspect, the association information indicates an association between data that may have been received by the data processing entity and the monitoring data to be collected, e.g. according to a subscription. The association information indicates that data that has been receivable by the data processing entity and the monitoring data correspond or peer to each other if the monitoring data corresponds to the data that has been receivable by the data processing entity. The association information indicates that the data that may have been received by the data processing entity is at least partially different from the monitored data if the monitored data does not correspond to data that may have been received by the data processing entity.

In particular, the NWDAF should be able to decide whether a new data collection needs to be triggered when collecting data from the NF/AF to prevent unnecessary data collection signals and unnecessary data transmissions. The NWDAF may take the following actions:

-the NWDAF generating association information by creating a mapping table indicating that requests and/or subscriptions to analysis information (e.g. analysis ID) are associated with data collection parameters (e.g. event ID + event filter information + event reporting target).

-the NWDAF processing triggering a new event open subscription according to the association information.

If an available event subscription can be associated with a new analysis request/subscription, no new event subscription will be created.

Otherwise, the NWDAF will create a new event subscription or modify an existing subscription.

In another embodiment of the aspect, if the monitoring data to be collected is not available (in particular) according to a subscription, the data processing entity is configured to: retrieving the monitoring data to be collected from the one or more other network entities in accordance with at least one other data request, the data processing entity being configured to: after receiving the retrieved monitoring data, sending and/or forwarding the retrieved monitoring data to be collected to the first network entity; alternatively, if the monitoring data is available at the data processing entity, the data processing entity is configured to send and/or forward the available monitoring data to the first network entity.

In another embodiment of the first aspect, the data processing entity is configured to: determining that the monitoring data is already available at the data processing entity if the data processor can receive the monitoring data from the one or more other network entities according to a data subscription.

In another embodiment of the first aspect, the data processing entity is configured to: generating the at least one other data request if the monitoring data is not available at the data processing entity, wherein the at least one other data request comprises at least one other data identifier related to at least one subset of the monitoring data to be collected and/or requests a subscription to at least one subset of the monitoring data from at least one other network entity. The other network entity may be any monitoring data generating entity of the data processing entity. The monitoring data generating entity of the data processing entity is a network entity or a network device or a network component that discloses the information requested by the data processing entity. For example, the 5GC NF/AF/OAM defined in 3GPP may be other network entities generating monitoring data, and may be other network entities of the data processing entity, e.g. NWDAF.

In another embodiment of the first aspect, the data processing entity is configured to: obtaining a second data identifier as the at least one other data identifier, wherein the second data identifier relates to monitoring data to be collected from or by a second network entity, the second network entity being one of the other network entities; the data processing entity is configured to obtain the second data identifier, in particular, prior to receiving the first data request.

In particular, the data processing entity is configured to obtain the second data identifier associated with the monitoring data from the second network entity in a static and/or dynamic manner. In a static manner, the data processing entity configures and stores the second data identifier in coordination with the data generating entity. In a dynamic manner, the data processing entity may obtain the second data identifier from one or more other network entities using a request/response mode or a service-based architecture and/or through a third-party network entity.

In another embodiment of the first aspect, the data processing entity is configured to: generating the first data identifier and, in particular, transmitting the first data identifier to the first network entity prior to receiving the respective data request.

For example, the data processing entity is configured to generate the first data identifier, which is configured to identify specific information provided by the data processing entity. The list of first data identifiers is to be exchanged with a user of the data processing entity in a static manner or in a dynamic manner.

The identifier may be a word, number, letter, symbol, or any combination of such words, numbers, letters, symbols. The first data identifier is used to obtain information provided by the data processing entity. In order to support a data consumer (e.g., 5G NF/AF/OAM) of information provided by a data processing entity, the data processing entity should provide the first list of data identifiers to the data consumer. The data processing entity configures and/or generates a first data identifier to identify supported data types. The data consumer uses the first data identifier when requesting data from the data processing entity. In particular, an analysis ID (where the analysis ID is a first data identifier) is used to obtain analysis information provided by an NWDAF, where the NWDAF is the data processing entity. The NWDAF should provide the data consumer (including the 5GNF/AF/OAM defined in 3 GPP) with a list of analytics IDs that it supports. Each data consumer (e.g., SMF) requests analysis information from the NWDAF using a specific analysis ID. For example, the analysis ID may be set to "network performance" and/or "UE mobility" and/or "UE communication" and/or "NF load information".

In another embodiment of the first aspect, the data processing entity is configured to associate the first data identifier with at least one data collection parameter, in order to associate the first data identifier with the monitoring data to be collected, wherein the at least one data collection parameter is the second data identifier and indicates which data constitutes the monitoring data or a particular subset of monitoring data.

In particular, the data processing entity associates an initial configuration of a mapping indicating which specific information requires which specific monitoring data from the monitoring data generating entity. In particular, the data processing entity generates the association information by creating a mapping table indicating which requested information and/or which second data identifiers the monitoring data requires from the monitoring data generating entity.

In another embodiment of the first aspect, the first identifier is constituted by and/or comprises at least one of the following identifiers: a data open identifier, in particular a data analysis identifier related to data analysis information, the second identifier being constituted by and/or comprising at least one of the following identifiers: an event identifier, in particular an identifier relating to monitoring data to be collected from the second network entity, e.g. the time identifier or time ID may be set to "UE reachability" and/or "roaming status" from the 5G NF.

In another embodiment of the first aspect, the first data request further comprises: filter information, in particular filtering a geographical area and/or a threshold value associated with the first identifier; and/or data reporting information and/or a target of data reporting indication, the other data request further comprising: filter information, in particular filtering of geographical areas and/or thresholds associated with said second identifier, and/or data reporting information and/or a target of data reporting instructions.

In another embodiment of the first aspect, the data processing entity is a network data analysis function (NWDAF) entity, the first network entity is an NWDAF service consumer, the data processing entity is configured to receive the first data request, the first data request indicating a subscription and/or request for analytical information, the first data identifier being an analytical identifier, the processor is configured to generate the association information by creating a mapping table of the analysis identifier and/or the first data request with data to be collected as the monitoring data, wherein the monitoring data to be collected is associated with at least one event identifier and/or event filter information and/or event reporting information and/or monitoring parameters such as a target indicated by data reporting, and the data processing entity is configured to: if a new subscription for analysis information is necessary, it is decided whether to trigger and/or update the collection of data from the one or more other network entities or whether the requested analysis information has been provided to the data processing entity based on an existing subscription for analysis information from the one or more other network entities.

In particular, the NWDAF executes the association information upon receiving a data request from a user.

The NWDAF associates an event ID with an analytics ID for a particular request and/or subscription of analytics information to:

one event ID (e.g. event instance ID) of a particular data request information may be associated with a plurality of analysis instance IDs;

one analysis ID (e.g. analysis instance ID) of a particular data request information may be associated with a plurality of (unique) event IDs of the particular data request information;

-when the NWDAF receives a new request/subscription for analysis information (e.g. indicated by an analysis ID); the NWDAF creates an analytics ID only for specific data request information (e.g., analytics instance ID) if no existing analytics ID can support the new request/subscription;

-when the NWDAF creates a new analysis ID for a particular data request information (e.g., an analysis instance ID);

if an existing event ID cannot be used, the NWDAF creates a new time ID only for certain data request information (e.g., event instance ID).

The NWDAF may generate an analysis ID (e.g., an analysis instance ID) for particular data request information and one or more event IDs (e.g., event instance IDs) for particular data request information for analyzing data to be collected for a user's particular data request. Examples of event instance IDs may relate to associations of event IDs and/or event filter information and/or event reporting targets. Examples of analysis instance IDs may relate to associations of analysis IDs and/or analysis filter information and/or reporting information and/or targets of analysis reporting information.

The NWDAF may perform the associating information with the associated event identifier by creating a mapping table of analysis information requests and/or subscriptions to particular data requests and/or subscriptions for analysis information.

The NWDAF may perform association information with association requests and/or subscriptions to analysis information (e.g., analysis IDs) by creating a mapping table of event identifiers for particular monitoring data to be collected for particular data request information.

In another embodiment of the first aspect, the data processing entity is a network data analysis function (NWDAF) entity, the first network entity is a NWDAF service user, the data processing entity is configured to receive a subscription termination request from the first network entity, the subscription termination request indicates termination of an analysis information subscription, the data processing entity is configured to terminate transmission of monitoring data related to the terminated subscription to the first network entity, the data processing entity is configured to modify an association between a subscription request from the first network entity and the monitoring data to be collected, or the data processing entity is configured to delete an association between a subscription request from the first network entity and the monitoring data to be collected.

In another embodiment of the first aspect, the data processing entity is adapted to determine a data collection procedure for collecting data from the one or more other network entities to obtain the monitoring data.

In another embodiment of the first aspect, the data processing entity is configured to determine the one or more other network entities from which data should be collected to obtain the monitoring data, based on the received first data request and/or the first data identifier.

In another embodiment of the first aspect, the data processing entity is configured to receive the one or more second data identifiers from the one or more other network entities, wherein the one or more second data identifiers identify the monitoring data to be collected from the one or more other network entities.

In another embodiment of the first aspect, the data processing entity is configured to communicate in a 5G communication network.

In a second aspect, the present invention relates to a data processing method for processing monitoring data between network entities, wherein the data processing method includes: obtaining a first data request from a first network entity, wherein the first data request includes a first data identifier, the first data identifier being associated with monitoring data; obtaining one or more second data identifiers from one or more other network entities, wherein the one or more second data identifiers relate to the monitoring data to be collected from one or more other network entities; generating association information according to the first data identifier and the one or more second data identifiers; determining, from the association information, whether the monitoring data to be collected is already available at the data processing entity or whether the monitoring data to be collected should be collected by the data processing entity from the one or more other network entities.

The data processing method may be implemented by the data processing entity of the first aspect.

Drawings

Other embodiments of the invention will be described hereinafter in conjunction with the following drawings, in which:

fig. 1 shows a data processing entity in a communication scenario;

FIG. 2 illustrates a data processing entity in a communication scenario;

3A-3D illustrate operations and services in a communication scenario;

FIG. 4 illustrates a data processing entity in a communication scenario;

FIG. 5 illustrates a data processing entity in a communication scenario;

FIG. 6 illustrates a data processing entity in a communication scenario;

FIG. 7 illustrates a data processing entity in a communication scenario;

FIGS. 8A and 8B illustrate operation of a data processing entity in a communication scenario;

FIGS. 9A and 9B illustrate operation of a data processing entity in a communication scenario;

FIG. 10 illustrates the operation of a data processing entity in a communication scenario;

FIG. 11 illustrates the differences between a conventional approach and an approach according to some embodiments;

FIG. 12 illustrates the differences between a conventional approach and an approach according to some embodiments;

fig. 13 is a flowchart of a data processing method.

Detailed Description

Fig. 1 shows a communication scenario for a data processing entity 101 for processing monitoring data between network entities 107-1 and 107-2. The data processing entity 101 is connected to the first network entity 107-1 via a connection 111-1. Fig. 1 also shows, for example, a connection 111-2 between the data processing entity 101 and another first network entity 107-2. The description relating to the first network entity corresponds to the second network entity 107-2. The data processing entity 101 communicates with the data generating entity 109 via connection 114-1.

Connections 111-x and 114-x may be 5G corresponding network connections.

The data processing entity 101 is configured to: obtaining a first data request from a first network entity 107-1 over a connection 111-1, wherein the first data request comprises a first data identifier, the first data identifier relating to monitoring data; obtaining one or more second data identifiers from one or more other network entities 109, wherein the one or more second data identifiers relate to the monitoring data to be collected from one or more other network entities 109; generating association information according to the first data identifier and the one or more second data identifiers; determining, from the association information, whether the monitoring data to be collected is already available at the data processing entity or whether the monitoring data to be collected should be collected by the data processing entity 101 from the one or more other network entities.

The second network entity 107-2 may transmit a second data request including other data identifiers, which may be the same as or different from the first data identifier, over the connection 111-2 to request monitoring data. The data processing entity 101 processes the second data request in the same way as the first data request.

Network entities 107-1 and 107-2 are users of the monitored data and network entity 109 is a generating entity of the monitored data. The entities 107-1, 107-2, and 109 may be Network Functions (NFs) and may be disposed in the same or different network planes, such as a Control Plane (CP), a User Plane (UP), or a Management Plane (MP).

The data processing entity may be implemented as a service within a network entity, or may be implemented as a network entity. The data processing entity may be a network entity or a network device or a network component, wherein the network entity or network device may be a physical or logical entity. For example, the Data processing entity may be a Network Data analysis Function (NWDAF) defined in 3GPP or the like. The Data processing entity may be Operation and Management (OAM) or Management Data Analysis Function (MDAF) defined in 3 GPP. The data processing entity may also be a Network Exposure Function (NEF).

In one embodiment, the data processing entity 101 may efficiently support monitor task management, e.g., a 5G system (5G system, 5GS) between the data consumers NF 107-1 and 107-2 and the data generation entity NF 109 to avoid unnecessary data collection signaling and unnecessary data transmission.

In one embodiment, the data processing entity 101 supports 5GS to efficiently reuse monitoring services across CPs, UPs and MPs.

In one embodiment, the data processing entity 101 supports 5GC by providing efficient monitoring services between the data consumers NF 107-1 and 107-2 and the data production entity NF 109.

In one embodiment, the data processing entity 101 efficiently coordinates monitoring services in 5GS and non-3 GPP systems.

In one embodiment, the data processing entity 101 reduces the data collection time to meet the requirements of vertical services like URLLC services in 5 GS.

In one embodiment, the data processing entity 101 may provide a Monitoring as a Service (MaaS) function, which may support:

monitoring services and task management between the data production entity 109 and the data consumers 107-1 and 107-2.

Any reusable monitoring service model between the data generating entity 109 and the data consumers 107-1 and 107-2 and/or for the User Plane (UP), Control Plane (CP) and Management Plane (MP) and/or for the integration of Control Plane (CP) and Management Plane (MP) and/or for the E2E monitoring services across the technical/Management domain and/or for the coordination of E2E monitoring services with non-3 GPP systems.

In one embodiment, the data processing entity 101 supports MaaS producers, MaaS users, or MaaS discovery/registration procedures. The term "MaaS" relates to the monitoring as a service provided by the data processing entity 101 to the involved network entities.

In one embodiment, the data processing entity 101 enables the 5GS to support monitoring services and task management of overlay CPs, UPs and MPs.

In one embodiment, the data processing entity 101 enables the 5GS to support monitoring data collection of URLLC applications in a faster manner.

In one embodiment, the data processing entity 101 enables the 5GS to integrate legacy systems, third party and/or non-3 GPP systems to support monitoring data opening and task management by:

(i) providing the following MaaS features consisting of MaaS functions:

MaaS producers for monitoring data production entities,

MaaS users for monitoring data users,

MaaS discovery/registration procedure for proxy services monitoring data,

a MaaS task manager for processing monitoring tasks;

(ii) the services provided by the MaaS task manager function are provided, and in particular,

data collection task control/management between production program and user to avoid unnecessary data subscription/request signaling or unnecessary data transmission;

(iii) a service interface is provided.

Further embodiments of MaaS features, comprised of MaaS functionality, are described with reference to fig. 2, 3A to 3D, illustrating embodiments of services and operations.

Each MaaS feature may be constituted by a service provided by the MaaS function.

The MaaS generator function is proposed for the data generation entity 109. Any Network Function (NF) on the CP, UP and MP that generates monitoring data may require the generator Function to support any Network entity that requests the monitoring data. As shown in fig. 2, the services of the MaaS producer 109 may be the following services:

service P # 1: the distribution, and the associated templates,

service P # 2: the configuration, and the associated templates,

service P # 3: the notification, and the associated template,

service P # 4: open, and related templates.

In the following table, each service (P #1 to P #4) related to the MaaS generator is listed together with parameters required to create the service. For example, parameters required to create a publishing service include, but are not limited to, service information, a measurable KPI list with thresholds, reporting related information, priorities, etc., as described below. Using these parameters, a template for the publishing service can be created. The following table lists MaaS producer services (P #1 to P #4) with parameters required to create a service template.

MaaS user functionality is proposed for the data user 107. Any Network Function (NF) on the CP, UP, and MP that uses the monitoring data may require a user Function to request the monitoring data.

In one embodiment, the services of the MaaS user 107 are

Service C # 1: subscriptions, and related templates;

service C # 2: unsubscribe, and associated templates.

In the following table, each service related to the MaaS user 107 is listed together with parameters required for creating the service. Services supporting the MaaS user features include subscription and unsubscription. For example, parameters required for creating the subscription service include, but are not limited to, service information, a list of requested KPIs with notification thresholds, reporting related information, priorities, etc., as described in the following table, showing MaaS user services and operations with input parameters and return values. The following table lists MaaS user services (C #1 to C #2) with parameters required to create a service template.

In one embodiment, a MaaS registration/discovery procedure may be performed.

It is proposed to support registration and discovery services between MaaS producers and MaaS users using MaaS registration/discovery functionality. The MaaS registration/discovery function enables how MaaS generators register and how MaaS users discover monitoring data. Similar to the proxy service, this functionality may discover and register the monitoring service between the data generating entity and the data consumer. As shown in fig. 6, the basic service of MaaS registration/discovery program is

Service R # 1: the registration, and the associated templates,

service R # 2: discovery, and related templates.

In the following table, each service (R #1 to R #2) related to the MaaS registration/discovery program is listed together with a sub-service (job). The registration service is related to a release service of the MaaS producer. The MaaS registration/discovery program receives a publication service from a MaaS producer to register the service. Registration of a published service includes, but is not limited to, MaaS registration/discovery procedures creating a number of jobs (e.g., creating/deleting MaaS jobs). After MaaS jobs for registering services are created for a particular published service, the associated MaaS ID will be returned. A similar process is performed for the MaaS user to register the MaaS service instance. In this case, the relevant operation is to subscribe/unsubscribe the service from the MaaS user to create/update/delete the MaaS instance supported by the registration service.

The discovery service provides an available MaaS service directory, updates the service directory and mapping of service information (e.g., service name, source, MaaS ID, measurable KPI). The parameters required for registering and discovering the associated jobs of the program are shown in the following table.

The MaaS task manager may be implemented by the data processing entity 101. The functionality of the MaaS task manager 101 is proposed to support services between MaaS producers and MaaS consumers. The MaaS task manager function supports how to further manage monitoring data between MaaS producers and MaaS users. For example, if two data users subscribe to the same monitoring data from the same monitoring data generation entity, a single data needs to be reported from the MaaS generator instead of reporting two data streams. The task manager manages optimization of data processing tasks between the MaaS producer and the user, such as configuration tasks, optimization in data reporting, and the like.

In one example, the service of the MaaS task manager 101 is

Service TM # 1: the configuration, and the associated templates,

service TM # 2: notifications, and associated templates.

Basically, task management considers (i) configuration and (ii) notification. The configuration service includes the ability to manage subscription tasks from the same user and/or manage publication tasks from the same producer. The notification service is concerned with reporting data to the user and querying data from repository X. The services and related operations of the MaaS task manager are summarized in the following table:

in one embodiment, the service interfaces between the MaaS producer 109 and the MaaS registry/discovery program and task manager 101 and/or between the MaaS consumer 107 and the MaaS registry/discovery program and task manager 101 may be translated into service operations (i.e., service-based architecture). Exemplary service operations are supported by the MaaS functional components (MaaS producer, MaaS consumer, MaaS registration/discovery program, MaaS task manager) described in the table above.

In some embodiments, a reusable and generic monitoring framework consisting of a monitoring service for networks and network slices (MaaS) in the 5GS that overlays CPs, UPs, and MPs is provided. Furthermore, these functions can be extended to cover monitoring services from (to) 5GS to (from) third parties (e.g., Application Functions (AFs) defined by 3 GPP) and/or legacy systems and/or non-3 GPP systems (e.g., Transport Networks (TNs)).

Fig. 4 illustrates a generic model of MaaS to support monitoring services between MP, UP, and CP 5GC NF, including non-3 GPP networks (e.g., Access Networks (ANs)). The MaaS features composed by the MaaS functions may include the following:

MaaS F1: the producer of the MaaS is provided with the MaaS,

MaaS F2: the user of the MasS can use the user,

MaaS F3: the MaaS registration/discovery procedure may be,

MaaS F4: MaaS task manager.

The service is enabled by the data processing entity 101 and can be implemented as a MaaS task manager.

The MaaS task manager shown in fig. 4 is, in some embodiments, a network entity that can be considered (i) a single network entity of a 5G System (5G System, 5GS) and/or (ii) can be co-located with one or more network functions or network entities of the 5 GS.

Exemplary functions of the task manager 101 are:

-obtaining a first data request from a data consumer 107 (e.g. 107-1 and 107-2) comprising input parameters regarding data to be collected.

-associating the mapping of the request from the data consumer with the required data to be collected from the associated data generating entity 109.

Processing requests between the data consumer 107 and the data generating entity 109.

The processing of the request between the data consumer 107 and the data generation entity 109 may include, but is not limited to, the following:

identifying/checking if there already exists (similar or) the same MaaS subscription and/or extraction request,

-if the same subscription is available, no new subscription is created and opened,

-otherwise, creating a new subscription and/or modifying an existing subscription.

For example, if similar requests for the same data to be collected are received, e.g., with different reporting periods or reporting granularities or filter information that do not require a new subscription, a modification request may be sent to the MaaS generator 109.

In addition, the MaaS task manager 101 may use the local identifier to better control the association between the request and the data to be collected. In particular, the MaaS task manager 101 may:

-generating a local identifier to identify the occurrence/instance of a request ID, which the MaaS task manager 101 can generate using its specific request filter information and event reporting set;

-generating a local identifier to identify an occurrence/instance of a data collection ID request from a data producing entity using its specific filter information and event reporting set.

In the embodiment shown in fig. 5, the first network entity 107-1 may send its data request with the filter X and optionally data a for filtering. The second network entity 107-2 may send its data request with the filter Y and optionally data a for filtering. The MaaS task manager 101 may use the local identifier to better control the association between the request and the data to be collected. Data A and filter X may be sent to MaaS producer 109 over link 114-1, where data A and filter Y may be sent to MaaS producer 109 over link 114-2.

The local identifier based on the MaaS ID and the event ID may be as follows:

the MaaS ID identifies requests from MaaS users 107 that the MaaS task manager 101 may generate;

MaaS instance ID: identify the occurrence/instance < local identifier > of a MaaS ID request that the MaaS task manager 101 may generate using its specific filter information and event report set;

event ID: identify a request to a MaaS producer 109 that the MaaS task manager 101 may use to collect data;

event instance ID: the occurrence/instance of a MaaS request by a MaaS producer (e.g., NF/AF/OAM) for an event ID is identified using specific event filter information and an event report set < local identifier >.

In one embodiment, the MaaS task manager 101 associates the event instance ID with the MaaS instance ID to:

an event instance ID may be associated with multiple MaaS instance IDs;

one MaaS instance ID may be associated with multiple (unique) event instance IDs;

when the task manager receives a new request/subscription to the MaaS ID; if no existing MaaS instance ID can support new request/subscription, the task manager only creates the MaaS instance ID;

when the task manager creates a new MaaS instance ID; the task manager creates a new event instance ID only if the existing event instance ID cannot be used.

By providing data collection task control/management, the MaaS task manager may support unnecessary event open subscription/request signaling or unnecessary data transmission under the following scenarios.

In another embodiment, which may be handled by the example shown in fig. 5, the same (or similar) MaaS service requests (or subscriptions) may be managed by the user 107, the user 107 including the same type of data collection from the same data production entity. In the case of similar requests, for example, the data collection and/or reporting granularity for the same data may be different. The MaaS task manager 101 receives the same request from the MaaS user 107 and triggers multiple data collections of the same type of data from the MaaS producer.

A first network entity 107-1, i.e. a MaaS user, communicates, e.g. an info a subscription request or response, over a link 111-1. A second network entity 107-2, i.e. a MaaS user, communicates, e.g. an info a subscription request or response, over link 111-2.

The data processor 101 forming the MaaS task manager communicates with the request/response of data X through the link 114-1 and the link 114-1 event open subscription.

In another embodiment, which may be handled by the example shown in fig. 5, the MaaS task manager 101 receives different analysis requests from MaaS users 107-1, 107-2 and triggers multiple data collections of the same type of data from the MaaS producer 109. Thus, different MaaS service requests (or subscriptions) of users 107 (i.e., 107-1, 107-2) are supported, including obtaining the same type of data collection from the same data production entity 109.

A first network entity 107-1, i.e. a MaaS user, communicates, e.g. an info B subscription request or response, over a link 111-1. A second network entity 107-2, i.e. a MaaS user, communicates, e.g. an info C subscription request or response, over link 111-2.

The data processor 101 forming the MaaS task manager sends the request/response of the event open subscription and the data Y to the MaaS producer 109 through the link 114-1 and the link 114-2.

In another embodiment, which may be handled by the example shown in fig. 5, the MaaS task manager 101 receives different analysis requests from specific MaaS users 107-1, 107-2 and triggers multiple data opens corresponding to the MaaS users 107-1, 107-2. Thus, the MaaS task manager 101 manages different MaaS service requests (or subscriptions) for a particular user to synchronize/optimize data collection from MaaS data generating entities with different data reporting granularities.

A first network entity 107-1, i.e. a MaaS user, communicates, e.g. an info a subscription request or response, over a link 111-1. A second network entity 107-2, i.e. a MaaS user, communicates, e.g. an info B subscription request or response, over link 111-2.

The data processor 101, which constitutes the MaaS task manager, sends data a subscriptions and requests/responses and data B subscriptions and requests/responses to the MaaS producer 109 only over link 114-1.

In one embodiment, an association between an analytics subscription and a data collection trigger, e.g., 3GPP SA2 TS23.288, may be handled. There are two types of analytics subscriptions defined by 3GPP SA2/SA 5:

1. the subscription/notification is carried out in such a way that,

2. the request/response is extracted.

The process of analyzing the association between a subscription and a data collection trigger is described below, according to some embodiments.

In the following process, it is disclosed with reference to fig. 5 how a Network Data analysis Function (NWDAF) defined by 3GPP SA2 controls the Data collection process using the MaaS task manager 101 to avoid unnecessary Data subscription signaling and unnecessary Data transmission.

The first network entity 107-1 and the second network entity 107-2 may form network functions (NF #1 and NF #2) requesting the same analysis request from an NWDAF formed by the data processing entity 101, requiring the same data to be collected from different data sources (e.g., NF/AF/OAM). Here, AF is an application function defined by 3GPP, and OAM is an operation management function defined by 3GPP SA 5.

The flow of steps 1 to 3 is as follows according to one embodiment:

the NWDAF101 receives a request from a MaaS user (NF #1) 107-1. The request includes, but is not limited to, MaaS user information (e.g., user ID), requested MaaS service information (e.g., request ID), information about data to be collected, monitoring data, request (e.g., event ID of MaaS producer) filter information

Mapping between NWDAF101 associated user information, requested analysis ID, input data to be collected (e.g., event ID of NF/AF/OAM)

a. Optionally, during mapping, the NWDAF101 may generate an analysis instance ID and/or an event instance ID to enable better control of the data collection task in order to

One event instance ID may be associated with multiple analysis instance IDs;

one analysis instance ID can be associated with multiple (unique) event instance IDs;

NWDAF101 operates with a data collection task manager function to control the association between requested analysis IDs and relevant data collections, avoiding signaling for unnecessary data collection

a. If no existing analytics (instance) ID and/or event (instance) ID can support the new request/subscription, NWDAF101 creates a new data subscription/request (e.g., from NF #1) and/or modifies an existing subscription/request to the associated NF/AF/OAM to get the data to be collected with the required filtering information.

Otherwise, the NWDAF101 will not create a new data subscription/request to the associated NF/AF/OAM to avoid unnecessary data collection signaling. In this case, the request from the second network entity 107-1, NF #2 is the same as the second network entity 107-1, NF #1 and a subscription to data required by NF # 1107-1 has been established

In an extension of the embodiment shown in fig. 5, a third network entity NF #3, not shown in fig. 5, may be present as an analysis user entity in addition to the network entities 107-1, 107-2.

Some embodiments of data collection task control at the NWDAF101 are to deploy three requests from different analysis users NF #1, 107-1, NF #2, 107-2, and NF #3, not shown in fig. 5. This may require collecting public data from a particular data source (e.g., NF/AF/OAM).

The order of requests is as follows: NF #1- > NF #2- > NF # 3.

Step 1:NF # 1107-1 has been requested, the NWDAF101 creates an association/mapping between the user, the analysis ID, the data to be collected. The NWDAF101 sends an open request for the event ID {1,4} to the corresponding data generation entity (NF/AF/OAM).

Example of an association relationship (or mapping entry) created: user NF # 1: analyze the Filter for ID #2< - > event ID {1,4} + < ID #4-1 >

Step 2:the NWDAF101 receives the same request from NF # 2107-2. The NWDAF101 operates the data collection task control and finds the same request for the same data to be collected with the same filter information, and therefore decides that subscription (or request open) is not required.

And step 3:the NWDAF101 receives a request from NF #3 (not shown) that requires common data collection for event ID-4. The NWDAF101 creates an association/mapping relationship before the user, the analysis ID, and the data to be collected. For event ID-4, an open request has been established. Thus, the NWDAF101 only sends an open request for event ID-2 to the corresponding data generation entity (NF/AF/OAM).

Example of an association relationship (or mapping entry) created: user NF # 3: analyze the Filter for ID #5< - > event ID {2,4} + < ID #4-1 >

With reference to all embodiments described herein, the data open identifier may be an identifier for identifying a type of supporting data that the network data processing entity may generate. To support data users (e.g., 5G NF/AF/OAM), the network data processing entity should first provide a list of data open IDs for the data users. When requesting data from the network data processing entity 101, the data consumer uses the corresponding data open identifier.

For example, an NWDAF formed by data processing entity 101 may provide a list of analytics IDs (e.g., data exposure identifiers) that it supports to data consumers (e.g., 5G NF/AF/OAM) 107. Each data consumer 107 (e.g., SMF) requests analysis information from the NWDAF101 using a particular analysis ID.

The event identifier may identify the event type of the subscription. Basically, the event identifier is defined and supported by the data generation entity 109 (e.g., 5G NF/AF/OAM). The data processing entity 101 may receive the list of event identifiers from the data generating entity 109.

Example (c): the 5G NF (e.g., SMF and AMF) defines event identifiers (PDU session release defined by 3GPP 23.502, mobility of the UE outside the area of interest, etc.) that the NWDAF101 will use to associate a particular data opening ID. In the current specification of TS23.288, there is a predefined way to exchange these event identifiers between the data generating entity (e.g., 5GNF/AF/OAM) and the NWDAF.

As to receiving data requests from the data consumers 107, the data processing entity receives data requests from the data consumers, including but not limited to data openidentifiers and/or filter information and/or data reporting information and/or the target of data reporting.

Event filter information, as defined in 3GPP SA2(TS23.502), provides event parameter types and event parameter values to be matched, and in order to satisfy the condition of notifying a subscription event ID, for example, the event parameter type may be "area of interest", and the event parameter value list may be a TA list; the event filter depends on the event ID. The event filter information is provided according to the subscribed event ID: in a subscription, different events may be associated with different event filter information.

The following table exemplarily describes event reporting information. In the subscription, all event IDs are associated with unique event reporting information.

Event reporting information

The target for event reporting may indicate a particular UE or PDU session, a group of UEs, or any UE (i.e., all UEs), and in the subscription, all event IDs are associated with the same target for event reporting (possibly corresponding to multiple UEs or multiple PDU sessions).

As for the association of data requests with data collection parameters, after receiving a data request from a data consumer, the data processing entity 101 (e.g., NWDAF) may associate the data request with the corresponding data to be collected (i.e., the corresponding event identifier). Here, the association relationship may be a mapping relationship between the data open identifier and the corresponding event identifier and between the filter information and/or the data reporting information and/or the target of data reporting.

For example, the NWDAF101 associates a request and/or subscription for analysis information (e.g., analysis ID) with a data collection parameter (e.g., event ID + event filter information + target of event reporting), wherein an event identifier may be performed, optionally associated with filter information and/or data reporting information and/or target of data reporting, with an associated data open identifier.

For example, the NWDAF101 associates requests and/or subscriptions to data collection parameters (e.g., event ID + event filter information + event reporting target) with corresponding requests and/or subscriptions to analysis information (e.g., analysis ID).

With respect to the determination or processing of data collection, the data processing entity 101 may determine the processing of data collection from the association information. If the available event subscription for the event ID can be associated with a new data request, no new event subscription will be created. Otherwise, the network data processing entity creates a new event subscription to the corresponding data producing entity or modifies an existing subscription

For example, the NWDAF101 triggers a new event open subscription according to the association information processing.

If an available event subscription can be associated with a new analysis request/subscription, no new event subscription will be created.

Otherwise, the NWDAF101 will create a new event subscription or modify an existing subscription.

As for the additional information, the data processing entity 101 may or may not be a single instance or multiple instances. The data processing entity 101 can create a data open instance identifier or an event instance identifier to better control the association information. These identifiers may be considered local identifiers.

The analysis instance ID < data open instance identifier > identifies the occurrence/instance of an analysis ID request that the NWDAF may use its specific analysis filter information and analysis reporting target set generation.

The event instance ID identifies the event/instance of the NWDAF request event ID from the NF, with specific event filter information and an event reporting target set. The NWDAF101 (i.e., the data processing entity 101) associates the event instance ID with the analysis instance ID to:

one event instance ID may be associated with multiple analysis instance IDs;

one analysis instance ID can be associated with multiple (unique) event instance IDs;

if the NWDAF receives a new request/subscription for an analytics ID, the NWDAF only creates an analytics instance ID if no existing analytics instance ID can support the new request/subscription;

if the new analysis instance ID is created by the NWDAF, and it is not possible to use the existing event instance ID, then the NWDAF creates only the new event instance ID.

As for the data request mode, for example, two types of data request modes are considered.

A request, such as a one-time data request,

subscription, where such data request is an event subscription. The reporting method may be event-based or periodic.

As to terminating and/or unsubscribing a data request, upon receiving an unsubscribe to a data request, the data processing entity 101 may be operable to perform one or more of the following:

-deleting the association information of the data request and/or deleting the association information of the data request if the association is independent from other data requests

-modifying the association information relating to the data request if the association information is dependent on/from other data requests.

As for direct data transfer, the data processing entity 101 may also be used to support the direct transfer of requested data from the data generating entity to the data consumer. For example: the data processing entity 101 forwards the data collected from the data generating entity 109 directly to the data consumer 107 without further processing.

For handling data transmission, the data processing entity 101 may also be used for

Extracting data from a data repository for further data processing,

support data processing functions (e.g., aggregation, composition) of data extracted from a data store,

open processed data (e.g., aggregated data, synthetic data) to data consumers.

For example: a particular data consumer 107 (e.g., OAM) requests multiple analytics information (multiple analytics IDs) from the NWDAF101 with the same (or similar) data reporting information. For example, the analysis information #1 with a data reporting rate of 5 minutes and the analysis information #2 with a data reporting rate of 10 minutes. By processing the data transmission, the data transmission to the data user can be efficiently modified. The NWDAF101 may synthesize the analysis information #1 and #2 extracted by the repository, and open the combined analysis information every 10 minutes if the time can be synchronized to reduce data transmission.

Fig. 6 and 7 show embodiments of the data processing entity 101 constituting an NWDAF.

Fig. 6 relates to NWDAF service consumer 107 making process analysis subscribe/unsubscribe. This process may be used by any NWDAF service consumer 107 (e.g., including NF/AF/OAM) to subscribe/unsubscribe on NWDAF101 using, for example, the NWDAF _ analytics subscription service described herein to be notified on analytics information. Any network entity may use this service as described herein.

With respect to this process, the NWDAF service consumer 107 subscribes to the analysis message or unsubscribes from the analysis message by, for example, invoking a NWDAF _ analytics sub _ sub/NWDAF _ analytics sub _ ubscript service operation.

Upon receiving a subscription to analytics information, the NWDAF101 associates the subscription to analytics information with the required data to be collected and decides whether a new data collection needs to be triggered.

If the NF service consumer 107 subscribes to analysis information, the NWDAF101 notifies the NWDAF service consumer of the analysis information by invoking a Nnwdaf _ analytics sub description _ Notify service operation.

Fig. 7 depicts the process associated with the analysis request of the NWDAF service consumer 107. The NWDAF service consumer 107 (e.g., including the NF/AF/OAM) uses this process to request and obtain analytics information from the NWDAF, e.g., using the NWDAF _ analytics info service described herein.

With respect to this process, the NWDAF service consumer 107 requests the parsing information by calling the NWDAF _ AnalyticsInfo _ Request service operation.

When a request for analysis information is received, the NWDAF associates the request for analysis information with the required data to be collected and decides whether a new data collection needs to be triggered. The NWDAF 107 responds with an analysis message to the NWDAF service user 107.

In general, the data collection function allows the NWDAF101 to retrieve data from various sources (e.g., NFs such as AMFs, SMFs, PCFs, etc.) as the basis for network analytics computations.

The available data may include:

-OAM global NF data,

behavioral data related to individual UEs or groups of UEs (e.g. UE reachability), and pre-computed metrics covering the entire number of UEs (e.g. number of UEs present in a geographical area), each spatial and temporal dimension (e.g. each area over a period of time),

other NF data available in 5GC (e.g., NRF).

The NWDAF101 may use at least one of the following services:

-generic management services defined in TS28.532 [6] provided by OAM to collect OAM global NF data.

Open services provided by NF/AF to retrieve behavioural data and other non-OAM pre-computed metrics.

Other NF services (e.g. NRF) for collecting NF data.

The NWDAF101 is able to discover metrics supported by NF/AF.

The data collection process may enable the NWDAF101 to efficiently obtain appropriate data, e.g., monitoring data, at an appropriate granularity.

The NWDAF101 may not have the data needed to perform the service when a statistical or predictive request or subscription is received.

For example, providing statistical data and predicting data for past monitoring periods that may need to match an observation period. Data from past long monitoring periods are necessary for model training.

Thus, to optimize quality of service, the NWDAF101 may take the following actions:

NWDAF101 may return a probabilistic assertion by expressing a confidence in the generated analysis. The confidence is 0, for example, no analysis should be returned. In the case of a subscription, the confidence may increase.

The value of confidence depends on the level or urgency expressed by the time-out date, the level of accuracy, the availability of data as described herein. If sufficient data is not collected before the time expiration date to provide the requested estimate of the level of accuracy, the service may return zero confidence. Otherwise, the NWDAF may wait to collect enough data before providing a response or first notification.

To prepare for future statistical data requests from NF/AF/OAM, the NWDAF101 may actively collect data, e.g. data about the UE sample (e.g. mobility), after operator configuration and retain the data collected in the data store.

The amount and maximum duration of data storage is also a subject of operator configuration.

The NWDAF101 may decide to reduce the amount of data collection by prioritizing requests, reducing the duration of data collection, or the sampling ratio in case of high signaling load.

The NWDAF101 is able to decide whether new data collection needs to be triggered when collecting data from the NF/AF to prevent unnecessary data collection signals and unnecessary data transmissions. The NWDAF101 may take the following actions:

the NWDAF101 generates the association information by creating a mapping table indicating which request and/or subscription for analysis information (e.g. analysis ID) requires which data collection parameters (e.g. event ID + event filter information + event reporting target).

-the NWDAF101 processing triggering a new event open subscription according to the association information.

If an available event subscription can be associated with a new analysis request/subscription, no new event subscription will be created.

Otherwise, the NWDAF101 will create a new event subscription or modify an existing subscription.

Fig. 8A and 8B illustrate the deployment of the data processing entity 101 as a MaaS task manager in an embodiment that specifies the context of 3GPP SA2 TS 23.501/502.

In order to support monitoring services in CP and UP, MaaS functions are added in the affected 5GC NF (UPF) and 5GC NF (CP) in addition to TS 23.501. In addition, MaaS functions (registration/discovery procedures) are added to 5GC NF (NRF) to support MaaS service registration and discovery from CP and UP to OAM.

In addition to TS23.502, MaaS services (producers and consumers) are added to affected 5GC NF (CP) and 5GC NF (UPF), and MaaS services and interfaces (registration/discovery procedure) are added to 5GC NF (NRF), supporting OAM functions.

Fig. 9A and 9B illustrate the deployment of a data processing entity 101 as a MaaS task manager in the context of 3GPP SA5 TS28.532/TS28.550 and TR 28.805.

Referring to TS 28.805, MaaS functions and services are added to coordinate 5GC for SLA management. With reference to TS 28.532/550, MaaS functions and services (producer, consumer, registration/discovery procedure, task manager) are added to cover the limitations of current PM data reporting services.

Fig. 10 shows a general deployment of the data processing entity 101 in a 5G context.

Fig. 11 and 12 illustrate further functionalities of the MaaS concept as described herein and are supported by the data processing entity 101 which in embodiments constitutes a MaaS task manager, in contrast to existing 3GPP systems.

Fig. 13 shows a data processing method for processing monitoring data between network entities, wherein the data processing method comprises: obtaining 401 a first data request from a first network entity 107-1, wherein the first data request comprises a first data identifier, the first data identifier relating to monitoring data; obtaining 403 one or more second data identifiers from one or more other network entities 109 (e.g., data generating entities), wherein the one or more second data identifiers relate to the monitoring data to be collected from one or more other network entities; generating 405 association information from the first data identifier and the one or more second data identifiers; from the association information, it is determined 407 whether the monitoring data to be collected is already available at the data processing entity 101 or whether the monitoring data to be collected should be collected by the data processing entity 101 from the one or more other network entities.

The method may be implemented by a data processing entity 101. The method may also implement the MaaS service described herein.