Patent Description:
The present specification generally relates to file based communication between two entities in a network.

Files are used in - e.g. - Third Generation Partnership Project (3GPP) management for many purposes.

For example, measurements produced by a management service (MnS) producer associated to a network function (NF) are written into files that are made available to MnS consumers.

As a further example, key performance indicators (KPI) computed by a MnS producer associated to a management function (MnF) (based on received measurements) are written into files that are made available to MnS consumers.

As a still further example, trace and minimization of drive tests (MDT) data produced by a MnS producer associated to a network are written into files that are made available to data consumers.

Further examples include analytics that are reported using files.

In each of these cases, the files generated by the MnS producer need to be uploaded to a MnS consumer that is using the data in the files for some purpose.

The upload of a file from a MnS producer to a MnS consumer is initiated either by the MnS producer or by the MnS consumer.

When initiated by the MnS producer, the MnS producer needs to know only the address of the MnS consumer where to upload the files. Whilst this method is rather simple, it suffers from a serious drawback. Namely, the MnS consumer has no control over what is uploaded to him or pushed onto him. The MnS consumer can only indirectly control the uploads by managing the related jobs controlling the data production and reporting activities on the MnS producer.

For that reason, it is typically preferred that the upload is initiated by the MnS consumer.

As an example, 3GPP Technical Specification (TS) <NUM>, clause <NUM>, describes a dedicated MnS for managing file uploads from MnS producers to MnS consumers. This dedicated MnS features a special operation named "listAvailableFiles" allowing MnS consumers to get a list of all files available for upload on a MnS producer, and a special notification named "notifyFileReady" allowing MnS producers to inform MnS consumers about the availability and location of new files.

To transfer files, file transfer protocol (FTP) (or secure file transfer protocol (SFTP)) is used.

To receive the "notifyFileReady" notification, the MnS consumer needs to create a subscription for this notification on the MnS producer. The MnS consumer needs to know how to create such subscription.

The thus provided dedicated MnS featuring the above-outlined special operation ("listAvailableFiles") and special notification ("notifyFileReady") lacks flexibility and requires overly abilities on both the MnS consumer and the MnS producer sides.

Hence, the problem arises that overly abilities are required on both the MnS consumer and the MnS producer sides to enable file uploading with little flexibility.

Hence, there is a need to provide for file upload management.

Further prior art can be found in document <CIT>, disclosing operations and notifications for performance management of <NUM> networks and network slicing. According thereto, an apparatus of a management service producer comprises one or more processors to create a measurement job for one or more network functions (NF), network slice subnet instances (NSSI), network slice instances (NSI), networks or subnetworks by receiving a CreateMeasurementJob operation request for creating a measurement job for the one or more NFs, NSSIs, NSIs, networks or subnetworks from a consumer, checking if one or more new measurement types need to be collected for the one or more NFs or constituent NSSIs or constituent NFs, requesting the NFs or the management service producer of the constituent NSSIs or constituent NFs to collect the performance data when one or more new measurements types are to be collected for the one or more NFs or constituent NSSIs or constituent NFs. The management service producer allows the consumer to choose the reporting method from performance data file reporting and performance data streaming for the collected performance data in the CreateMeasurementJob operation request.

Further prior art can be found in document <CIT>, disclosing end-to-end techniques to collect performance measurement (PM) data from a network function virtualization (NFV) infrastructure (NFVI), including creating PM jobs at the NFVI based on a request from a network manager (NM), subscribing one or more data available notifications associated with a virtual network function (VNF) related virtualization resource (VR) PM job, and reporting PM data available notification(s) to the NM.

Further prior art can be found in document <CIT>, disclosing rule-based data collection and management in wireless communication networks.

Various example embodiments aim at addressing at least part of the above issues and/or problems and drawbacks.

Various aspects of example embodiments are set out in the appended claims.

According to an exemplary aspect, there is provided a method comprising transmitting a collection job request requesting a data collection job, and receiving a collection job response, wherein said collection job response includes information on file uploading related to said data collection job.

According to an exemplary aspect, there is provided a method comprising receiving a collection job request requesting a data collection job, creating a job instance representing said data collection job, and transmitting a collection job response, wherein said collection job response includes information on file uploading related to said data collection job.

According to an exemplary aspect, there is provided an apparatus comprising transmitting circuitry configured to transmit a collection job request requesting a data collection job, and receiving circuitry configured to receive a collection job response, wherein said collection job response includes information on file uploading related to said data collection job.

According to an exemplary aspect, there is provided an apparatus comprising receiving circuitry configured to receive a collection job request requesting a data collection job, creating circuitry configured to create a job instance representing said data collection job, and transmitting circuitry configured to transmit a collection job response, wherein said collection job response includes information on file uploading related to said data collection job.

According to an exemplary aspect, there is provided an apparatus comprising at least one processor, at least one memory including computer program code, and at least one interface configured for communication with at least another apparatus, the at least one processor, with the at least one memory and the computer program code, being configured to cause the apparatus to perform transmitting a collection job request requesting a data collection job, and receiving a collection job response, wherein said collection job response includes information on file uploading related to said data collection job.

According to an exemplary aspect, there is provided an apparatus comprising at least one processor, at least one memory including computer program code, and at least one interface configured for communication with at least another apparatus, the at least one processor, with the at least one memory and the computer program code, being configured to cause the apparatus to perform receiving a collection job request requesting a data collection job, creating a job instance representing said data collection job, and transmitting a collection job response, wherein said collection job response includes information on file uploading related to said data collection job.

According to an exemplary aspect, there is provided a computer program product comprising computer-executable computer program code which, when the program is run on a computer (e.g. a computer of an apparatus according to any one of the aforementioned apparatus-related exemplary aspects of the present disclosure), is configured to cause the computer to carry out the method according to any one of the aforementioned method-related exemplary aspects of the present disclosure.

Such computer program product may comprise (or be embodied) a (tangible) computer-readable (storage) medium or the like on which the computer-executable computer program code is stored, and/or the program may be directly loadable into an internal memory of the computer or a processor thereof.

Any one of the above aspects enables an efficient implementation of file based communication, in particular of file uploads, between two entities in a network, to thereby solve at least part of the problems and drawbacks identified in relation to the prior art.

By way of example embodiments, there is provided file upload management. More specifically, by way of example embodiments, there are provided measures and mechanisms for realizing file upload management.

Thus, improvement is achieved by methods, apparatuses and computer program products enabling/realizing file upload management.

In the following, the present disclosure will be described in greater detail by way of non-limiting examples with reference to the accompanying drawings, in which.

The present disclosure is described herein with reference to particular non-limiting examples and to what are presently considered to be conceivable embodiments. A person skilled in the art will appreciate that the disclosure is by no means limited to these examples, and may be more broadly applied.

It is to be noted that the following description of the present disclosure and its embodiments mainly refers to specifications being used as non-limiting examples for certain exemplary network configurations and deployments. Namely, the present disclosure and its embodiments are mainly described in relation to 3GPP specifications being used as non-limiting examples for certain exemplary network configurations and deployments. As such, the description of example embodiments given herein specifically refers to terminology which is directly related thereto. Such terminology is only used in the context of the presented non-limiting examples, and does naturally not limit the disclosure in any way. Rather, any other communication or communication related system deployment, etc. may also be utilized as long as compliant with the features described herein.

Hereinafter, various embodiments and implementations of the present disclosure and its aspects or embodiments are described using several variants and/or alternatives. It is generally noted that, according to certain needs and constraints, all of the described variants and/or alternatives may be provided alone or in any conceivable combination (also including combinations of individual features of the various variants and/or alternatives).

According to example embodiments, in general terms, there are provided measures and mechanisms for (enabling/realizing) file upload management.

As mentioned above, a dedicated MnS featuring the above-outlined special operation ("listAvailableFiles") and special notification ("notifyFileReady") lacks flexibility and requires overly abilities on both the MnS consumer and the MnS producer sides.

The following improvements over current implementations/approaches can be identified when starting from example embodiments described below in more detail.

Unlike with example embodiments, to transfer files utilizing the above-outlined special operation and special notification, FTP (or SFTP) is used, whereas hypertext transfer protocol (HTTP) (or hypertext transfer protocol secure (HTTPS)) is used for the request and response messages of the operations and notifications of the MnS. This requires the MnS producer and MnS consumer to support two protocol stacks, one for FTP/SFTP, and one for HTTP/HTTPS. However, it is desirable (and achieved according to example embodiments) to have just one protocol stack to minimize implementation cost. Utilizing HTTP (or HTTPS) for communication of request and response messages as well as for file transfer is not possible today in the 3GPP solution.

Further, unlike with example embodiments, according to the current approach outlined above, a dedicated MnS is used for managing file uploads. This approach does not integrate well with the new model-driven approach followed by 3GPP SA5, where one holistic information model and generic create, read, update, delete (CRUD) operations only are used for specifying management services. Example embodiments do.

Still further, unlike with example embodiments, in the current approach as outlined above, the MnS producer cannot provide any information to the MnS consumer on where to create a subscription for the "notifyFileReady" notification. The MnS consumer (however) needs to know where to create subscriptions on the MnS producer. According to example embodiments, such necessity is removed.

Still further, unlike with example embodiments, in the current approach as outlined above, when a MnS consumer cannot receive notifications or a MnS producer cannot send notifications, the MnS consumer may use only the operation "listAvailableFiles" to find out if new files are available for him and where to get them. A disadvantage of this approach is that the MnS consumer gets always a list with all files on the MnS producer available for upload and needs to scan through a potentially large number of file meta data for identifying the file the MnS consumer is interested in and retrieve it based on that information. Here, it is noted that the capability to receive (and send) notifications always comes with additional implementation effort, since the MnS consumer and MnS producer must support both an HTTP server and HTTP client protocol stack. When no notifications need to be sent and received, according to example embodiments, the MnS producer just needs to have a HTTP server protocol stack and the MnS consumer a HTTP client protocol stack.

Still further, as described above, files are often used to store and report management data produced on a MnS producer. This data is produced as a result of a request by MnS consumers. MnS consumers request data production by instantiating so called (data production) jobs on the MnS producer. In the service based management architecture (SBMA), many different MnS consumers can create jobs on a MnS producer. However, unlike with example embodiments, in the current approach as outlined above, the file information in the "listAvailableFiles" response or the "notifyFileReady" notification does not contain any information allowing a MnS consumer to associate a job on a MnS producer to the files generated by this job and stored on the producer. In other words, the MnS consumer cannot really find out if a file was produced based on the MnS consumer's request or based on another MnS consumer's request. The current functionality thus only works in deployment scenarios where a single MnS consumer interacts with a MnS producer. This is due to historical reasons. The current file upload MnS as outlined above was originally designed for a single client architecture. When SA5 migrated to SBMA, the old functionality was not improved. Here, it is noted that a job identifier (ID) might be included in a file name. The file name is part of the file information conveyed to the MnS consumer. The MnS consumer could hence parse the file name to check whether job IDs of interest are contained in the file name. This approach, however, is not really straight forward, clean and easy to implement. According to example embodiments, thus straight forward, clean and easy to implement measurements are provided, which enable that only files of interest for the MnS consumer are adverted and uploaded.

Still further, unlike with example embodiments, in the current approach as outlined above, is not possible to send to the MnS consumer in the "listAvailableFiles" response or the "notifyFileReady" notification only file information for files associated to jobs the MnS consumer created or is interested in. Here, it is noted that the job ID might be included in the file name. A subscription filter could be set that filters out all "notifyFileReady" notifications whose file names do not contain certain job IDs. However, this does not ensure that the MnS consumer gets only file information of interest. Only if the set of file information in a notification does not contain the job ID, the complete notification is filtered out. Leave alone that filtering on substrings in complex data types is not easy to implement or can run on nodes with limited processing power. According to example embodiments, thus, it is enabled that only files of interest for the MnS consumer are adverted and uploaded.

Still further, unlike with example embodiments, the current approach as outlined above relies on implementing an operation and/or a notification. It does not allow for very simple implementations, where, e.g., the MnS consumer just polls a location on the MnS producer where only the MnS consumer's files are stored, as example embodiments do.

Still further, unlike with example embodiments, in the current approach as outlined above, when a MnS consumer creates a data production job with file based reporting, the MnS consumer needs to create the subscription for the "notifyFileReady" notification in a second step using a new create operation. It is not possible with the current approach to ask the MnS producer in the job creation request to create an implicit subscription. Such a capability is desirable for efficient operational processes. Accordingly, according to example embodiments, a possibility to ask the MnS producer in the job creation request to create an implicit subscription is provided.

Still further, unlike with example embodiments, in the current approach as outlined above, MnS consumers cannot delete files on MnS producers or indicate to the MnS producers that they are not interested any more in files, e.g. after retrieval of the file. Such functionality is provided according to example embodiments.

Hence, in brief, according to example embodiments, a fully model-driven approach using normal CRUD operations only to manage file uploads is provided.

Example embodiments are specified below in more detail.

<FIG> is a block diagram illustrating an apparatus according to example embodiments. The apparatus may be a network entity <NUM> such as a management service consumer (entity) comprising a transmitting circuitry <NUM> and a receiving circuitry <NUM>. The transmitting circuitry <NUM> transmits a collection job request requesting a data collection job. The receiving circuitry <NUM> receives a collection job response. Here, the collection job response includes information on file uploading related to said data collection job. <FIG> is a schematic diagram of a procedure according to example embodiments. The apparatus according to <FIG> may perform the method of <FIG> but is not limited to this method. The method of <FIG> may be performed by the apparatus of <FIG> but is not limited to being performed by this apparatus.

As shown in <FIG>, a procedure according to example embodiments comprises an operation of transmitting (S51) a collection job request requesting a data collection job, and an operation of receiving (S52) a collection job response. Here, the collection job response includes information on file uploading related to said data collection job.

<FIG> is a block diagram illustrating an apparatus according to example embodiments. In particular, <FIG> illustrates a variation of the apparatus shown in <FIG>. The apparatus according to <FIG> may thus further comprise a creating circuitry <NUM>, a retrieving circuitry <NUM>, and/or a querying circuitry <NUM>.

In an embodiment at least some of the functionalities of the apparatus shown in <FIG> (or <FIG>) may be shared between two physically separate devices forming one operational entity. Therefore, the apparatus may be seen to depict the operational entity comprising one or more physically separate devices for executing at least some of the described processes.

According to further example embodiments, said collection job response includes an identifier of a job instance representing said data collection job.

According to further example embodiments, said information on file uploading related to said data collection job includes information on a file availability notification subscription address.

According to a variation of the procedure shown in <FIG>, exemplary additional operations are given, which are inherently independent from each other as such. According to such variation, an exemplary method according to example embodiments may comprise an operation of creating a file availability notification subscription for said data collection job based on said file availability notification subscription address, and an operation of transmitting said file availability notification subscription.

According to further example embodiments, said file availability notification subscription includes an identifier of a job instance representing said data collection job.

According to a variation of the procedure shown in <FIG>, exemplary details of the creating operation are given, which are inherently independent from each other as such. Such exemplary creating operation according to example embodiments may comprise an operation of creating a subscription instance name-contained by said job instance, or an operation of creating a subscription instance name-contained by a predetermined realm instance.

According to a variation of the procedure shown in <FIG>, exemplary additional operations are given, which are inherently independent from each other as such. According to such variation, an exemplary method according to example embodiments may comprise an operation of receiving a file availability notification subscription acknowledgement including an identifier of said file availability notification subscription.

According to further example embodiments, said collection job request is indicative of a notification recipient address.

According to further example embodiments, said collection job response includes an identifier of a file availability notification subscription created in response to said notification recipient address.

According to a variation of the procedure shown in <FIG>, exemplary additional operations are given, which are inherently independent from each other as such. According to such variation, an exemplary method according to example embodiments may comprise an operation of transmitting a request for deletion of said file availability notification subscription, said request for deletion of said file availability notification subscription includes said identifier of said file availability notification subscription.

According to a variation of the procedure shown in <FIG>, exemplary additional operations are given, which are inherently independent from each other as such. According to such variation, an exemplary method according to example embodiments may comprise an operation of receiving a file availability notification. Here, the file availability notification includes information on a file location of a file object instance representing a file generated based on data collected for said data collection job.

According to further example embodiments, said file availability notification includes an identifier of a job instance representing said data collection job.

According to a variation of the procedure shown in <FIG>, exemplary additional operations are given, which are inherently independent from each other as such. According to such variation, an exemplary method according to example embodiments may comprise an operation of retrieving file content of said file and/or file meta data of said file from said file location.

According to further example embodiments, said collection job request is indicative of a requested file-based reporting with notifications.

According to further example embodiments, said information on file uploading related to said data collection job includes information on a file retrieval address.

According to a variation of the procedure shown in <FIG>, exemplary additional operations are given, which are inherently independent from each other as such. According to such variation, an exemplary method according to example embodiments may comprise an operation of querying information on available files from said file retrieval address, and an operation of receiving said information on said available files.

According to a variation of the procedure shown in <FIG>, exemplary additional operations are given, which are inherently independent from each other as such. According to such variation, said information on said available files includes information on a file location of a file object instance representing a file generated based on data collected for said data collection job, and an exemplary method according to example embodiments may comprise an operation of retrieving file content of said file and/or file meta data of said file from said file location.

According to further example embodiments, said information on said available files includes an identifier of a job instance representing said data collection job associated with said file object instance representing said file generated based on data collected for said data collection job.

According to further example embodiments, said information on said available files includes file content of said available files and/or file meta data of said available files.

According to further example embodiments, said collection job request is indicative of a requested file-based reporting with polling.

According to a variation of the procedure shown in <FIG>, exemplary additional operations are given, which are inherently independent from each other as such. According to such variation, an exemplary method according to example embodiments may comprise an operation of transmitting a request for deletion of a file object instance representing a file generated based on data collected for said data collection job.

<FIG> is a block diagram illustrating an apparatus according to example embodiments. The apparatus may be a network entity <NUM> such as a management service producer (entity) comprising a receiving circuitry <NUM>, a creating circuitry <NUM>, and a transmitting circuitry <NUM>. The receiving circuitry <NUM> receives a collection job request requesting a data collection job. The creating circuitry <NUM> creates a job instance representing said data collection job. The transmitting circuitry <NUM> transmits a collection job response. Here, the collection job response includes information on file uploading related to said data collection job. <FIG> is a schematic diagram of a procedure according to example embodiments. The apparatus according to <FIG> may perform the method of <FIG> but is not limited to this method. The method of <FIG> may be performed by the apparatus of <FIG> but is not limited to being performed by this apparatus.

As shown in <FIG>, a procedure according to example embodiments comprises an operation of receiving (S61) a collection job request requesting a data collection job, an operation of creating (S62) a job instance representing said data collection job, and an operation of transmitting (S63) a collection job response. Here, the collection job response includes information on file uploading related to said data collection job.

<FIG> is a block diagram illustrating an apparatus according to example embodiments. In particular, <FIG> illustrates a variation of the apparatus shown in <FIG>. The apparatus according to <FIG> may thus further comprise a collecting circuitry <NUM>, a generating circuitry <NUM>, a providing circuitry <NUM>, and/or a deleting circuitry <NUM>.

According to further example embodiments, said collection job response includes said identifier of said job instance.

According to a variation of the procedure shown in <FIG>, exemplary additional operations are given, which are inherently independent from each other as such. According to such variation, an exemplary method according to example embodiments may comprise an operation of receiving a file availability notification subscription for said data collection job created based on said file availability notification subscription address.

According to a variation of the procedure shown in <FIG>, exemplary additional operations are given, which are inherently independent from each other as such. According to such variation, an exemplary method according to example embodiments may comprise an operation of transmitting a file availability notification subscription acknowledgement including an identifier of said file availability notification subscription.

According to a variation of the procedure shown in <FIG>, exemplary additional operations are given, which are inherently independent from each other as such. According to such variation, said collection job request is indicative of a notification recipient address, and an exemplary method according to example embodiments may comprise an operation of creating a file availability notification subscription for said data collection job for said notification recipient address.

According to further example embodiments, said collection job response includes an identifier of said file availability notification subscription.

According to further example embodiments, said file availability notification subscription is implemented as a subscription instance created name-contained by said job instance, or a subscription instance created name-contained by a predetermined realm instance.

According to a variation of the procedure shown in <FIG>, exemplary additional operations are given, which are inherently independent from each other as such. According to such variation, an exemplary method according to example embodiments may comprise an operation of receiving a request for deletion of said file availability notification subscription, said request for deletion of said file availability notification subscription includes said identifier of said file availability notification subscription, and an operation of deleting said file availability notification subscription.

According to a variation of the procedure shown in <FIG>, exemplary additional operations are given, which are inherently independent from each other as such. According to such variation, an exemplary method according to example embodiments may comprise an operation of collecting data corresponding to said data collection job, an operation of generating a file to be uploaded based on said data, an operation of creating a file object instance representing said file, and an operation of transmitting a file availability notification based on said file availability notification subscription. Here, the file availability notification includes information on a file location of said file object instance.

According to a variation of the procedure shown in <FIG>, exemplary additional operations are given, which are inherently independent from each other as such. According to such variation, an exemplary method according to example embodiments may comprise an operation of providing file content of said file and/or file meta data of said file at said file location.

According to a variation of the procedure shown in <FIG>, exemplary additional operations are given, which are inherently independent from each other as such. According to such variation, an exemplary method according to example embodiments may comprise an operation of collecting data corresponding to said data collection job, an operation of generating a file to be uploaded based on said data, an operation of creating a file object instance representing said file, an operation of receiving a query for information on available files from said file retrieval address, and an operation of transmitting said information on said available files including said file.

According to a variation of the procedure shown in <FIG>, exemplary additional operations are given, which are inherently independent from each other as such. According to such variation, said information on said available files includes information on a file location of a file object instance, and an exemplary method according to example embodiments may comprise an operation of providing file content of said file and/or file meta data of said file at said file location.

According to a variation of the procedure shown in <FIG>, exemplary additional operations are given, which are inherently independent from each other as such. According to such variation, an exemplary method according to example embodiments may comprise an operation of receiving a request for deletion of a file object instance representing a file generated based on data collected for said data collection job, and an operation of deleting said file object instance.

Example embodiments outlined and specified above are explained below in more specific terms.

According to example embodiments, object instances are created, maintained and referenced, where the object instances represent files (potentially to be uploaded), and where the object instances are instances of an object following an information model as follows.

Namely, in particular, according to example embodiments, files that are available for upload on a MnS producer by a MnS consumer are modeled with instances of dedicated managed object classes (MOC).

A class name of the dedicated managed object classes is for example "File".

According to example embodiments, these objects can be name-contained by any other managed object such as those already specified in TS <NUM> and TS <NUM>.

The "File" class definition includes attributes for meta-data describing the content of the file and an attribute indicating which data production job produced this file. According to example embodiments, the file content shall be retrieved using a normal Read operation on a "File" object. To this end, the object may have an attribute representing the content. According to example embodiments, reading this attribute returns the file content. It is noted in this regard that this attribute just represents the file content. The actual file may be stored elsewhere in a file system.

For grouping files sharing some common properties (for example, all files are related to a single job), according to example embodiments, a special collection class is introduced.

A class name of the collection class is for example "Files" (plural used to align with 3GPP naming conventions).

According to example embodiments, the "Files" class can be name-contained by any managed object and the "File" instances pertaining to the group are name-contained by "Files".

According to example embodiments, the "Files" class definition includes meta-data describing the collection of contained "File" instances such as the total number of files, the total size of all files, date and time of the last file removal or addition.

The name-containment relationship between the parent object of "File" or "Files" and the "File" or "Files" object itself shall have special semantics in the sense that it identifies the parent object as related to the files. The exact semantics depends on the parent object.

According to example embodiments, "Files" and "File" objects support the normal notifications for notifying object creation, object deletion and attribute value change. In addition or as alternative to an object creation notification, "File" objects may support the existing dedicated file ready notification reporting availability of the new file and all files, that became available before.

As mentioned above, according to example embodiments, the "File" class defines meta-data describing the file. The following data, already defined in TS <NUM>, may be included as meta-data of a "File" class according to example embodiments:.

According to current known implementations/approaches as outlined above, information about which process is related to the generation of a file is not provided.

Such processes related to the generation of files include, for example,.

To include the information about the process related to files in the information model, thereby allowing a MnS consumer to get this information and especially to get only the information related to processes the MnS consumer is interested in, according to example embodiments, the "Files" or "File" objects are name-contained by the related job object.

Alternatively, to include the information about the process related to files in the information model, thereby allowing a MnS consumer to get this information and especially to get only the information related to processes the MnS consumer is interested in, according to example embodiments, the "Files" or "File" objects include a pointer attribute carrying the identifier of the related job or the identifiers of the related jobs.

Two properties are inherent to the first alternative according to example embodiments ("Files" or "File" objects are name-contained by the related job object). Namely, firstly, file objects can exist only when the parent job object exists. This ensures that files are deleted (assuming that files are deleted when the objects representing the files are deleted) when the job is deleted, thus preventing files that are of no use any more from piling up on MnS producers. Secondly, the file can relate to one job only, which might be a limiting factor.

When a file becomes available for upload on the MnS producer, according to example embodiments, the MnS producer creates a "File" object instance representing the new file, and notifies interested MnS consumers about the availability of the new file, assuming the MnS consumer has requested to be notified about new files. With the information model according to example embodiments illustrated above, a "notifyMOICreation" notification as defined in TS <NUM> serves the purpose. Alternatively, dedicated notification types can be specified for this event, with the same triggering event. According to example embodiments, as dedicated notification type the "notifyFileReady" notification defined in TS <NUM> is used, where the dedicated notification type the "notifyFileReady" notification is extended with parameters allowing identifying the related jobs, i.e. a pointer attribute holding the distinguished names (DN) of the related jobs.

No matter the notification type, 3GPP defined notifications contain always the same notification header, whose objectClass and objectInstance parameters shall be set to identify the new "File" object.

To receive notifications, MnS consumers need to create an appropriate subscription as usual. Based on the information model according to example embodiments illustrated above, subscriptions can be created that notify MnS consumers only about files that are related to jobs they created or they are interested in.

Depending on where the "File" objects are contained, the subscription looks different (assuming the "NtfSubscriptionControl" object defined in TS <NUM> is used for subscription, which is allowed to be contained only under "ManagedElement" and "SubNetwork"; and assuming, as well, the scope attribute is set in a way to encompass "File" objects):.

According to example embodiments, the "NtfSubscriptionControl" object can be name-contained as well below job objects. This shall have the implicit semantics that the subscription is only related to objects of the subtree whose base object is the job object; hence to all "File" objects contained by the job object. This approach may work only for the case when "File" objects are contained by job objects. In this case, according to example embodiments, the following provisions are taken in the subscription:.

To create a subscription for notifications informing about the availability of files, the MnS consumer needs to know where these subscriptions need to be name-contained. Two known methods are imaginable for providing this information to the MnS consumer:.

However, according to example embodiments, a much simpler and efficient approach is provided as follows:.

To retrieve files from MnS producers, MnS consumers need to know the exact location of a file, or the parent object (folder) where files are stored as children. The current approach in SA5 allows reporting the exact location in the "notifyFileRead" notification announcing a file is available for upload. The exact location is also contained in the "listAvailableFiles" operation response. When neither the "notifyFileRead" notification nor the "listAvailableFiles" operation are implemented, the MnS consumer has no way to find out in a standardized manner the location of the parent object below which files are stored and where he can poll for available files.

Two proprietary workarounds are imaginable such as:.

According to example embodiments, a much simpler and efficient approach is provided as follows:.

According to example embodiments, in the job class definition it is also included an attribute allowing the MnS consumer to request, when selecting the file based reporting method, to be notified about new files with notifications (file-based reporting method with notifications) or not. Further, according to example embodiments, if the MnS consumer does not request to be notified about new files with notifications (file-based reporting method with notifications), the MnS consumer will poll the MnS producer instead for new files (file-based reporting method with polling).

According to example embodiments, further, a mechanism is provided for implicit subscription creation by the MnS producer. Namely, according thereto, when the MnS consumer requests the MnS to create a job and selects file based reporting with notifications, the sent request message may include as well an indication to the MnS producer to create the required subscription on behalf of the MnS consumer (implicit subscription). In this case, according to example embodiments, MnS consumer includes the notification recipient address in the request message. The presence of the notification recipient address may be used as implicit indication to create the subscription. The subscription is only related to notifications reporting the availability of files related to the job that the MnS consumer requests to be created.

Implicit subscriptions are especially beneficial for simple MnS consumers that support only requests for the creation of single objects (and hence cannot combine the request for creating a job and a subscription into a single request) and that shall be shielded from the complexities of how to create a subscription (i.e., including complexities regarding knowledge of the parent objects, below which it is possible to create a subscription, knowledge about properly forming of a request for creating a subscription, and knowledge about proper population of all attributes in the request with values).

According to example embodiments, further, a mechanism to decouple the address of the "File" object representing a file and the address where the file can be retrieved if provided by including a file location attribute in the "File" object. Typically, these addresses are identical, especially when the same protocol is used for file transfer and object manipulations. However, there are also deployments where the addresses might not be identical, for example when different protocols are used for file transfer and object manipulation or when the files are stored on a dedicated file server. To deal with this situation, according to example embodiments, the "File" class contains a "fileLocation" attribute with the complete address of the file location.

For example, the URI of the "File" object might be
"https://example. com/3gppManagement/Files=<NUM>/File=<NUM>"
and the value of the file location might be
"sftp://example. com/3gppManagement/Files=<NUM>/File=<NUM>".

In another example, the URI of the "File" might be
https://example. com/5GNB=<NUM>/PerfMetricJob=<NUM>/File=<NUM>.

<FIG> (<FIG> and <FIG>, where <FIG> is a continuation of <FIG>) shows a schematic diagram of signaling sequences according to example embodiments, and in particular illustrates an example procedure for requesting and retrieving data using notifications (without implicit subscription) based on the above explained information model according to example embodiments.

In a step <NUM> of <FIG>, according to example embodiments, the MnS consumer sends a job creation request to the MnS producer. In the request, the administrative state attribute of the job is set to "locked" and the reporting method to "file-based reporting with notifications".

In a step <NUM> of <FIG>, according to example embodiments, the MnS producer creates the job instance and generates an identifier (DN) for the new resource.

In a step <NUM> of <FIG>, according to example embodiments, the MnS producer sends the job creation response to the MnS consumer that includes the identifier of the new resource, and information about where the MnS consumer can create the subscription for notifications on the availability of new files.

In a step <NUM> of <FIG>, according to example embodiments, the MnS consumer creates a subscription for notifications reporting the availability of files with "his" data. To make sure this subscription is only for notifications relating to jobs created by, or of interest to, the MnS consumer, according to example embodiments, the MnS consumer has three possibilities, whose selection is governed by where subscriptions can be created by MnS consumers and where the MnS producer creates "File" objects:.

In a step <NUM> of <FIG>, according to example embodiments, the MnS producer acknowledges the creation of the subscription by sending a creation request response to the MnS consumer.

In a step <NUM> of <FIG>, according to example embodiments, the MnS consumer sets the administrative state of the job on the MnS producer to "unlocked".

In a step <NUM> of <FIG>, according to example embodiments, the MnS producer sends a response to the MnS consumer to acknowledge the attribute value change.

In a step <NUM> of <FIG>, according to example embodiments, the MnS producer opens a file and starts collecting data.

In a step <NUM> of <FIG>, according to example embodiments, the MnS producer writes the produced data into the file until the end of the reporting period is reached.

In a step <NUM> of <FIG>, according to example embodiments, the MnS producer closes the file.

In a step <NUM> of <FIG>, according to example embodiments, the MnS producer creates a "File" object representing the new file.

In a step <NUM> of <FIG>, according to example embodiments, the MnS producer emits a notification to report availability of the file.

In a step <NUM> of <FIG>, upon reception of the notification, according to example embodiments, the MnS consumer extracts the file location from the "objectInstance" parameters in the notification header. According to example embodiments, it is also possible that the notification contains a dedicated file location parameter in the notification body specifying a location potentially different from the location defined by the "objectInstance" parameters in the notification header.

In a step <NUM> of <FIG>, according to example embodiments, the MnS consumer sends a read request to the extracted location whilst specifying the file content shall be returned, or the meta data and the file content.

In a step <NUM> of <FIG>, according to example embodiments, the MnS producer responds with the file content or the file content and the file meta data.

In a step <NUM> of <FIG>, after retrieval of the file, according to example embodiments, the MnS consumer may ask the MnS producer to delete the file by deleting the corresponding "File" object.

In a step <NUM> of <FIG>, according to example embodiments, the MnS producer acknowledges that the "File" object was deleted (after deletion).

In a step <NUM> of <FIG>, according to example embodiments, if file preparation has failed, a corresponding notification is sent to the MnS consumer.

Alternatively, in step <NUM> of <FIG>, according to example embodiments, the MnS consumer sends a job creation request to the MnS producer. In the request, the administrative state attribute of the job is set to "locked" and the reporting method to "file-based reporting with notifications". Besides that, the request includes an indication to create a subscription on behalf of the MnS consumer by the MnS producer (referred to herein as implicit subscription). This indication may be embodied by an included notification recipient address. According to this alternative, in step <NUM> of <FIG>, according to example embodiments, the MnS producer creates not only the job instance and generates not only an identifier (DN) for the new resource, but, based on the indication to create a subscription (implicit subscription), also creates a subscription for notifications reporting the availability of files with the MnS consumers data (following the principles explained for step <NUM> of <FIG>) on its own, and generates an identifier for the (implicit) subscription. According to this alternative, in step <NUM> of <FIG>, according to example embodiments, the MnS producer sends the job creation response to the MnS consumer that includes the identifier of the new resource (job). The job creation response does not include information about where the MnS consumer can create the subscription for notifications on the availability of new files. Instead, the job creation response may include the generated identifier of the (implicit) subscription. According to this alternative, step <NUM> of <FIG> is performed while omitting steps <NUM> and <NUM> shown in <FIG>, i.e., according to example embodiments, subsequently to receipt of the job creation response (step <NUM> of <FIG>), the MnS consumer sets the administrative state of the job on the MnS producer to "unlocked", and the procedure of this alternative follows the further steps of <FIG>.

According to example embodiments, the MnS consumer may ask the MnS producer to delete a subscription (by stating the identifier of the subscription) Further, according to example embodiments, the MnS producer may delete the identified subscription accordingly.

<FIG> (<FIG> and <FIG>, where <FIG> is a continuation of <FIG>) shows a schematic diagram of signaling sequences according to example embodiments, and in particular illustrates an example procedure for requesting and retrieving data using polling based on the above explained information model according to example embodiments.

In a step <NUM> of <FIG>, according to example embodiments, the MnS consumer sends a job creation request to the MnS producer. In the request, the administrative state attribute of the job is set to "locked" and the reporting method to "file-based reporting with polling". According to example embodiments, the MnS consumer has specified the reporting period in the request and the MnS consumer can determine from that information when files should become available on the MnS producer.

In a step <NUM> of <FIG>, according to example embodiments, the MnS producer sends a response to the MnS consumer that includes the DN of the new resource, and information about where the MnS producer will create the files (e.g. a pointer to the parent resource where "File" objects will be created as children).

In a step <NUM> of <FIG>, according to example embodiments, the MnS consumer extracts the address where "File" objects will be created.

In a step <NUM> of <FIG>, according to example embodiments, the MnS producer writes the produced data into the file until the end of the reporting period is reached. Namely, according to example embodiments, the MnS consumer has specified the reporting period in the request indicating when files should become available on the MnS producer.

In a step <NUM> of <FIG>, the MnS consumer reads information about available files from the MnS producer using the address returned in the job creation request. Namely, according to example embodiments, the MnS consumer has specified the reporting period in the request and the MnS consumer can determine from that information when files should become available on the MnS producer. With the above explained information model according to example embodiments, this procedure becomes a straightforward normal read operation with query parameters to limit the set of returned file meta data to information about files the MnS consumer is interested in.

In a step <NUM> of <FIG>, according to example embodiments, the MnS producer sends a response with requested file meta data to the MnS consumer. It includes the exact location of the files.

In a step <NUM> of <FIG>, according to example embodiments, the MnS consumer extracts the exact location from the response.

In a step <NUM> of <FIG>, according to example embodiments, the MnS consumer sends a read request to the extracted location whilst specifying the file content shall be returned, or the file meta data and the file content.

Alternatively, in step <NUM> of <FIG>, according to example embodiments, the MnS consumer may specify that the MnS producer shall not only include file meta data but also the file content. With that, one read request is sufficient. In other words, according to this alternative, without performing steps <NUM> to <NUM> of <FIG>, in step <NUM> of <FIG>, the MnS producer responds with the file content or the file content and the file meta data.

In the same way as in the processing illustrated in <FIG>, although not shown in <FIG>, also in the processing illustrated in <FIG>, after retrieval of the file, according to example embodiments, the MnS consumer may ask the MnS producer to delete the file by deleting the corresponding "File" object. Further, according to example embodiments, the MnS producer acknowledges that the "File" object was deleted (after deletion).

In the foregoing exemplary description of the network entity, only the units that are relevant for understanding the principles of the disclosure have been described using functional blocks. The network entity may comprise further units that are necessary for its respective operation. However, a description of these units is omitted in this specification. The arrangement of the functional blocks of the devices is not construed to limit the disclosure, and the functions may be performed by one block or further split into sub-blocks.

In <FIG>, an alternative illustration of apparatuses according to example embodiments is depicted. As indicated in <FIG>, according to example embodiments, the apparatus (network entity) <NUM>' (corresponding to the network entity <NUM>) comprises a processor <NUM>, a memory <NUM> and an interface <NUM>, which are connected by a bus <NUM> or the like. Further, according to example embodiments, the apparatus (network entity) <NUM>' (corresponding to the network entity <NUM>) comprises a processor <NUM>, a memory <NUM> and an interface <NUM>, which are connected by a bus <NUM> or the like, and the apparatuses may be connected via link <NUM>, respectively.

The processor <NUM>/<NUM> and/or the interface <NUM>/<NUM> may also include a modem or the like to facilitate communication over a (hardwire or wireless) link, respectively. The interface <NUM>/<NUM> may include a suitable transceiver coupled to one or more antennas or communication means for (hardwire or wireless) communications with the linked or connected device(s), respectively. The interface <NUM>/<NUM> is generally configured to communicate with at least one other apparatus, i.e. the interface thereof.

The memory <NUM>/<NUM> may store respective programs assumed to include program instructions or computer program code that, when executed by the respective processor, enables the respective electronic device or apparatus to operate in accordance with the example embodiments.

According to example embodiments, an apparatus representing the network entity <NUM> comprises at least one processor <NUM>, at least one memory <NUM> including computer program code, and at least one interface <NUM> configured for communication with at least another apparatus. The processor (i.e. the at least one processor <NUM>, with the at least one memory <NUM> and the computer program code) is configured to perform transmitting a collection job request requesting a data collection job (thus the apparatus comprising corresponding means for transmitting), and to perform receiving a collection job response (thus the apparatus comprising corresponding means for receiving). Here, the collection job response includes information on file uploading related to said data collection job.

According to example embodiments, an apparatus representing the network entity <NUM> comprises at least one processor <NUM>, at least one memory <NUM> including computer program code, and at least one interface <NUM> configured for communication with at least another apparatus. The processor (i.e. the at least one processor <NUM>, with the at least one memory <NUM> and the computer program code) is configured to perform receiving a collection job request requesting a data collection job (thus the apparatus comprising corresponding means for receiving), to perform creating a job instance representing said data collection job (thus the apparatus comprising corresponding means for creating), and to perform transmitting a collection job response (thus the apparatus comprising corresponding means for transmitting). Here, the collection job response includes information on file uploading related to said data collection job.

For the purpose of the present disclosure as described herein above, it should be noted that.

Generally, any method step is suitable to be implemented as software or by hardware without changing the idea of the present disclosure. Devices and means can be implemented as individual devices, but this does not exclude that they are implemented in a distributed fashion throughout the system, as long as the functionality of the device is preserved. Such and similar principles are to be considered as known to a skilled person.

The present disclosure also covers any conceivable combination of method steps and operations described above, and any conceivable combination of nodes, apparatuses, modules or elements described above, as long as the above-described concepts of methodology and structural arrangement are applicable.

Claim 1:
An apparatus (<NUM>) comprising
transmitting circuitry (<NUM>) configured to transmit a collection job request requesting a data collection job, and
receiving circuitry (<NUM>) configured to receive a collection job response,
characterized in that
said collection job response includes information on file uploading related to said data collection job.