Patent Application
20220261383
Examples of embodiments relate to apparatuses, methods, systems, computer programs, computer program products and (non-transitory) computer-readable media usable for registering, discovering and retrieving data, in particular so-called historical data indicating events or measurements of the past, in a communication network based on e.g. 3GPP standards.
The following description of background art may include insights, discoveries, understandings or disclosures, or associations, together with disclosures not known to the relevant prior art, to at least some examples of embodiments of the present disclosure but provided by the disclosure. Some of such contributions of the disclosure may be specifically pointed out below, whereas other of such contributions of the disclosure will be apparent from the related context.
The following meanings for the abbreviations used in this specification apply:
According to an example of an embodiment, there is provided, for example, an apparatus for use by a communication network element or function configured to act as a data collection coordination function in a communication network, the apparatus comprising at least one processing circuitry, and at least one memory for storing instructions to be executed by the processing circuitry, wherein the at least one memory and the instructions are configured to, with the at least one processing circuitry, cause the apparatus at least: to receive, from a data consumer, a request for providing data from a data source for processing by the data consumer, and to process the request, to obtain, from a configuration management function, a meta data instance related to the requested data, to create a schema of the requested data based on the meta data instance, to obtain a schema for accessing the data being provided by a data source for making the data reusable as history data, and to register the obtained meta data instance and the schema for accessing the data in a repository.
Furthermore, according to an example of an embodiment, there is provided, for example, a method for use in a communication network element or function configured to act as a data collection coordination function in a communication network, the method comprising receiving, from a data consumer, a request for providing data from a data source for processing by the data consumer, and processing the request, obtaining, from a configuration management function, a meta data instance related to the requested data, creating a schema of the requested data based on the meta data instance, obtaining a schema for accessing the data being provided by a data source for making the data reusable as history data, and registering the obtained meta data instance and the schema for accessing the data in a repository.
According to further refinements, these examples may include one or more of the following features:
According to an example of an embodiment, there is provided, for example, an apparatus for use by a communication network element or function configured to act as a data store controlling function in a communication network, the apparatus comprising at least one processing circuitry, and at least one memory for storing instructions to be executed by the processing circuitry, wherein the at least one memory and the instructions are configured to, with the at least one processing circuitry, cause the apparatus at least: to receive, from a data collection coordination function, a request for providing information regarding a data storage in which data being provided by a data source for making the data reusable as history data can be stored, wherein the request comprises a schema of the data based on a meta data instance related to the data to be stored, and to process the request, to determine a data storage being suitable for the request, to create a schema for accessing the data, and to send an indication of the determined data storage and the schema for accessing the data to the data collection coordination function.
Furthermore, according to an example of an embodiment, there is provided, for example, a method for use in a communication network element or function configured to act as a data store controlling function in a communication network, the method comprising receiving, from a data collection coordination function, a request for providing information regarding a data storage in which data being provided by a data source for making the data reusable as history data can be stored, wherein the request comprises a schema of the data based on a meta data instance related to the data to be stored, and processing the request, determining a data storage being suitable for the request, creating a schema for accessing the data, and sending an indication of the determined data storage and the schema for accessing the data storage to the data collection coordination function.
According to further refinements, these examples may include one or more of the following features:
According to an example of an embodiment, there is provided, for example, an apparatus for use by a communication network element or function configured to act as a repository in a communication network, the apparatus comprising at least one processing circuitry, and at least one memory for storing instructions to be executed by the processing circuitry, wherein the at least one memory and the instructions are configured to, with the at least one processing circuitry, cause the apparatus at least: to receive, from a data collection coordination function, a request to resolve a meta data instance, generated on the basis of a request for providing data, to an indication of data resources for the data corresponding to the requested data, and to process the request, and to provide, to the data collection coordination function, the indication of the data resources for the data.
Furthermore, according to an example of an embodiment, there is provided, for example, a method for use in a communication network element or function configured to act as a repository in a communication network, the method comprising receiving, from a data collection coordination function, a request to resolve a meta data instance, generated on the basis of a request for providing data, to an indication of data resources for the data corresponding to the requested data, and processing the request, and providing, to the data collection coordination function, the indication of the data resources for the data.
According to further refinements, these examples may include one or more of the following features:
In addition, according to embodiments, there is provided, for example, a computer program product for a computer, including software code portions for performing the steps of the above defined methods, when said product is run on the computer. The computer program product may include a computer-readable medium on which said software code portions are stored. Furthermore, the computer program product may be directly loadable into the internal memory of the computer and/or transmittable via a network by means of at least one of upload, download and push procedures.
Some embodiments of the present disclosure are described below, by way of example only, with reference to the accompanying drawings, in which:
In the last years, an increasing extension of communication networks, e.g. of wire based communication networks, such as the Integrated Services Digital Network (ISDN), Digital Subscriber Line (DSL), or wireless communication networks, such as the cdma2000 (code division multiple access) system, cellular 3rd generation (3G) like the Universal Mobile Telecommunications System (UMTS), fourth generation (4G) communication networks or enhanced communication networks based e.g. on Long Term Evolution (LTE) or Long Term Evolution-Advanced (LTE-A), fifth generation (5G) communication networks, cellular 2nd generation (2G) communication networks like the Global System for Mobile communications (GSM), the General Packet Radio System (GPRS), the Enhanced Data Rates for Global Evolution (EDGE), or other wireless communication system, such as the Wireless Local Area Network (WLAN), Bluetooth or Worldwide Interoperability for Microwave Access (WiMAX), took place all over the world. Various organizations, such as the European Telecommunications Standards Institute (ETSI), the 3rd Generation Partnership Project (3GPP), Telecoms & Internet converged Services & Protocols for Advanced Networks (TISPAN), the International Telecommunication Union (ITU), 3rd Generation Partnership Project 2 (3GPP2), Internet Engineering Task Force (IETF), the IEEE (Institute of Electrical and Electronics Engineers), the WiMAX Forum and the like are working on standards or specifications for telecommunication network and access environments.
In the following, different exemplifying embodiments will be described using, as an example of a communication network to which examples of embodiments may be applied, a communication network architecture based on 3GPP standards for a communication network, such as a 5G/NR, without restricting the embodiments to such an architecture, however. It is obvious for a person skilled in the art that the embodiments may also be applied to other kinds of communication networks, e.g. Wi-Fi, worldwide interoperability for microwave access (WiMAX), Bluetooth®, personal communications services (PCS), ZigBee®, wideband code division multiple access (WCDMA), systems using ultra-wideband (UWB) technology, mobile ad-hoc networks (MANETs), wired access, etc. Furthermore, without loss of generality, the description of some examples of embodiments is related to a mobile communication network, but principles of the disclosure can be extended and applied to any other type of communication network, such as a wired communication network.
The following examples and embodiments are to be understood only as illustrative examples. Although the specification may refer to “an”, “one”, or “some” example(s) or embodiment(s) in several locations, this does not necessarily mean that each such reference is related to the same example(s) or embodiment(s), or that the feature only applies to a single example or embodiment. Single features of different embodiments may also be combined to provide other embodiments. Furthermore, terms like “comprising” and “including” should be understood as not limiting the described embodiments to consist of only those features that have been mentioned; such examples and embodiments may also contain features, structures, units, modules etc. that have not been specifically mentioned.
A basic system architecture of a (tele)communication network including a mobile communication system where some examples of embodiments are applicable may include an architecture of one or more communication networks including wireless access network subsystem(s) and core network(s). Such an architecture may include one or more communication network control elements or functions, access network elements, radio access network elements, access service network gateways or base transceiver stations, such as a base station (BS), an access point (AP), a NodeB (NB), an eNB or a gNB, a distributed or a centralized unit, which controls a respective coverage area or cell(s) and with which one or more communication stations such as communication elements, user devices or terminal devices, like a UE, or another device having a similar function, such as a modem chipset, a chip, a module etc., which can also be part of a station, an element, a function or an application capable of conducting a communication, such as a UE, an element or function usable in a machine-to-machine communication architecture, or attached as a separate element to such an element, function or application capable of conducting a communication, or the like, are capable to communicate via one or more channels via one or more communication beams for transmitting several types of data in a plurality of access domains. Furthermore, core network elements or network functions, such as gateway network elements/functions, mobility management entities, a mobile switching center, servers, databases and the like may be included.
The general functions and interconnections of the described elements and functions, which also depend on the actual network type, are known to those skilled in the art and described in corresponding specifications, so that a detailed description thereof is omitted herein. However, it is to be noted that several additional network elements and signaling links may be employed for a communication to or from an element, function or application, like a communication endpoint, a communication network control element, such as a server, a gateway, a radio network controller, and other elements of the same or other communication networks besides those described in detail herein below.
A communication network architecture as being considered in examples of embodiments may also be able to communicate with other networks, such as a public switched telephone network or the Internet, as well as with individual devices or groups of devices being not considered as a part of a network, such as monitoring devices like cameras, sensors, arrays of sensors, and the like. The communication network may also be able to support the usage of cloud services for virtual network elements or functions thereof, wherein it is to be noted that the virtual network part of the telecommunication network can also be provided by non-cloud resources, e.g. an internal network or the like. It should be appreciated that network elements of an access system, of a core network etc., and/or respective functionalities may be implemented by using any node, host, server, access node or entity etc. being suitable for such a usage. Generally, a network function can be implemented either as a network element on a dedicated hardware, as a software instance running on a dedicated hardware, or as a virtualized function instantiated on an appropriate platform, e.g., a cloud infrastructure.
Furthermore, a network element, such as communication elements, like a UE, a terminal device, control elements or functions, such as access network elements, like a base station (BS), an gNB, a radio network controller, a core network control element or function, such as a gateway element, or other network elements or functions, such as management elements or functions, as described herein, and any other elements, functions or applications may be implemented by software, e.g. by a computer program product for a computer, and/or by hardware. For executing their respective processing, correspondingly used devices, nodes, functions or network elements may include several means, modules, units, components, etc. (not shown) which are required for control, processing and/or communication/signaling functionality. Such means, modules, units and components may include, for example, one or more processors or processor units including one or more processing portions for executing instructions and/or programs and/or for processing data, storage or memory units or means for storing instructions, programs and/or data, for serving as a work area of the processor or processing portion and the like (e.g. ROM, RAM, EEPROM, and the like), input or interface means for inputting data and instructions by software (e.g. floppy disc, CD-ROM, EEPROM, and the like), a user interface for providing monitor and manipulation possibilities to a user (e.g. a screen, a keyboard and the like), other interface or means for establishing links and/or connections under the control of the processor unit or portion (e.g. wired and wireless interface means, radio interface means including e.g. an antenna unit or the like, means for forming a radio communication part etc.) and the like, wherein respective means forming an interface, such as a radio communication part, can be also located on a remote site (e.g. a radio head or a radio station etc.). It is to be noted that in the present specification processing portions should not be only considered to represent physical portions of one or more processors, but may also be considered as a logical division of the referred processing tasks performed by one or more processors.
It should be appreciated that according to some examples, a so-called “liquid” or flexible network concept may be employed where the operations and functionalities of a network element, a network function, or of another entity of the network, may be performed in different entities or functions, such as in a node, host or server, in a flexible manner. In other words, a “division of labor” between involved network elements, functions or entities may vary case by case.
In order to support network operators of telecommunication networks, in particular wireless telecommunication networks, with information usable for diagnostic and troubleshooting, several mechanisms are established. For example, subscriber and equipment trace procedures as standardized e.g. by 3GPP are known. Trace procedures are also used for jobs like collection of minimization of driving test (MDT) measurements, radio link failure (RLF) reports and the like which are added to trace specifications and used for centralized coverage and capacity optimization.
Minimization of driving test (MDT) is a standardized mechanism introduced, for example, in 3GPP to provide operators with network performance optimization tools in a cost-efficient manner. Characteristics of MDT include, for example, that the operator is able to configure UE measurements independently from the network configuration, the UE reports measurement logs at a particular event (e.g. radio link failure), the operator has the possibility to configure the logging in geographical areas, the measurements are linked with information which makes it possible to derive the location information, and to a time stamp, and the like.
Data being required for purposes like diagnostic and troubleshooting, as described above, such as MDT/trace, but also other data like performance management (PM) measurements or the like, are originally generated by a so-called data producer, such as a communication network in the access network, like a gNB, eNB or the like, according to a corresponding request of a data consumer, which is e.g. a network data analytics function (NWDAF) providing analytics that assist control decisions at the network, e.g. in connection with NWDAF-assisted RAT/frequency selection, detection of anomaly events and helping in analyzing its cause, and the like. The data produced reports the requested data to its requesting data consumer. At the same time, they may also be reported to a data storage to be kept as historical data as well.
For example, 3GPP specification TR 28.806-g10 defines use cases for a data consumer to request non-file based trace reporting from the corresponding data producer. There are also use cases to report the same data to a data storage where the data can be kept and reused as historical data.
Furthermore, 3GPP defines, in order to support management and orchestration of communication networks, such as 5G networks, a concept referred to as Network Resource Model (NRM). NRM is an information model representing the manageable aspects of the communication network.
Basically, the NRM is a collection of so-called information object classes (IOCs), inclusive of their associations, attributes and operations, representing a set of network resources under management.
A network resource represents, for example, a discrete entity for the purpose of network and service management. A network resource may represent, for example, intelligence, information, hardware and software of a communication network. In an object-oriented environment, the network resource is represented, for the purpose of management, by the IOC, wherein the IOCs of the network resources, corresponding attributes of an IOC and relationships between IOCs are defined in the NRM.
An IOC, on the other hand, represents the management aspect of a network resource. It describes the information that can be passed/used in management interfaces. Their representations are technology agnostic software objects. The IOC has attributes that represents the various properties of the class of objects. Furthermore, the IOC can support operations providing network management services invocable on demand for that class of objects. An IOC may support notifications that report event occurrences relevant for that class of objects. It is modelled using the stereotype “class” in the UML meta-model.
In a network management architecture, which is e.g. a service-based management framework, a Management Service (MnS) is defined which combines elements of management service components. The MnS components are combined to allow an MnS consumer to interact with an MnS producer via a specified service interface. The NRM specifies, for example, MnS components by management information represented by an information model of managed entities.
A managed object (MO), on the other hand, is an instance of a Managed Object Class (MOC) representing the management aspects of a network resource. Its representation is a technology specific software object. It is also called MO instance (MOI). The MOC is a class of such technology specific software objects. An MOC is the same as an IOC except that the former is defined in technology specific terms and the latter is defined in technology agnostic terms.
A management information base (MIB) is an instance of an NRM and has some values on the defined attributes and associations specific for that instance. An MIB consists, for example, of a name space (describing the MO containment hierarchy in the MIB through distinguished names), a number of MOs with their attributes and a number of associations between these MOs.
In the current 3GPP based networks, in the NRM, only 3GPP network-specific IOCs are standardized. In other words, NRM has only limited 3GPP network-specific IOCs standardized. This makes it difficult for network interfaces and network functions to support registration, discovery, and retrieval of data as historical data.
That is, it is required to define a mechanism allowing registration, discovery, and retrieval of historical data so that a reuse the historical data in a standardized manner is possible.
For this, it is required to provide the following standard control functionality:
(1) means for registering data to a repository,
(2) means for controlling proper data storage, and
(3) means for discovery of the stored data which include a discovery API and an API to query and retrieve the stored data (i.e. historical data).
In addition, it is preferable to ensure that stored (historical) data can be reused by data consumers of different vendors and multiple data consumers (i.e. a multivendor and multi-consumer scenario). By means of this, it is possible to avoid that data collection of (otherwise already existing) data has to be repeated, which is advantageous as it allows to avoid expenses, since a corresponding data collection requires resources and time.
As shown in
The DCCF 24 is, for example, a control-plane function that coordinates data collection and triggers data delivery to the data consumer. The DCCF can support multiple data sources, data consumers, and message frameworks. The DCCF provides a data exposure service to data consumers (e.g. NWDAF), and uses the services of the data sources to obtain data.
Moreover, as shown in
Furthermore, as shown in
Furthermore, as shown in
As indicated in
According to examples of embodiments, there are proposed means and procedures allowing, in a standardized way, to register information about stored data (i.e. meta data) from a data producer which allows, at a later point of time, discovery and reuse of the stored data.
That is, in a first phase or procedure, also referred to hereinafter as procedure A, a specific meta data instance for the data from a data producer is created before said data is produced. For the creation of such metadata, for example, a process described in the following is usable in which combined meta data are formed, i.e. (1) meta data describing standard data, (2) meta data describing proprietary data, and (3) meta data describing context data.
In a next phase or procedure, also referred to hereinafter as procedure B, a control procedure for selecting the suitable format or schema applicable to the data of the producer is applied. By means of this, when the data are stored, they can be discovered and reused by any data consumer in a standardized manner. It is to be noted that reuse means in the context of examples of embodiments also that there is a selection of specific data instance according to a search criteria.
Then, in a next phase or procedure, also referred to hereinafter as procedure C, a registration procedure for data instances is implemented. Specifically, a data instance includes the meta data of the data generated by the data producer. The result of such registration procedure is an index or catalogue that provides means to discover and access the stored data.
Then, in a next phase or procedure, also referred to hereinafter as procedure D, a data storage is executed so as to store the produced data to the data storage in a proper manner. Furthermore, the data being (newly) produced are forwarded to a data consumer.
Finally, in a next phase or procedure, also referred to hereinafter as procedure E, a processing for conducting discovery and reuse are executed which allows any data consumer to locate and reuse the stored (historical) data. This processing is based on a combination of meta data of the stored data, wherein it is to be noted that the combination is required when more than two individual pieces of stored data are discovered. Moreover, the processing includes also the exposure of the combined meta data of the stored data so as to allow any data consumer to understand the type and semantics of the received data, e.g. when relaying the data to another data consumer (also known as service chaining).
Details of the above described procedures A to E are explained in the following, wherein reference is also made to the elements indicated in
Concerning the procedure for creating a meta data instance (i.e. procedure A), elements being involved are the DCCF 24 which receives a request from a data consumer (e.g. data consumer A 10) regarding data, and the CM MnF 26.
When the CM MnF receives a request from the DCCF to activate a data producer (e.g. a data producer being able to provide some specific sort of data) to produce and report certain data to the DCCF, the CM MnF creates a meta data instance describing the data, that will be produced later by a corresponding data producer. Then, the CM MnF sends a response to the DCCF containing the created meta data instance. It is to be noted that the response to the DCCF may also include an identifier for the meta data instance. This identifier can be used at a later point of time when reporting the produced data. In addition, the DCCF also needs the meta data to create MOI(s) for the needed data producer(s) to produce the requested data.
It is to be noted that according to some examples of embodiments, the DCCF may be also omitted. That is, for the CM MnF, the DCCF acts in this phase basically as a data consumer. Thus, a direct communication between the data consumer A 10 and the CM MnF 26 is also conceivable wherein then the data consumer has to indicate IDs of suitable data producers.
In the following, examples of embodiments are described in which the creation of the specific meta data instance for the data from a data producer before the data is produced are further explained.
As indicated above, a management function for the communication network according to examples of embodiments is configured to create and activate corresponding meta data instances when a data consumer (e.g. data consumer 10 in
First, a definition of meta data for data types is described.
Meta data is provided for describing different types of data, such as meta data describing standard data (e.g. 3GPP standard related data), meta data describing proprietary data, and meta data describing context data.
Meta data attributes and definitions for meta data describing data types are indicated in table 1 below, wherein a corresponding support qualifier is assumed to be mandatory (M). It is to be noted that the definitions provided for the attribute represent only one of a plurality of examples, i.e. the type of data concerned by this data set is not limited to that specified here and could by any other suitable type of data.
Meta data attributes and definitions for meta data describing data types that are not standardized, i.e. fully proprietary, are indicated in table 2 below, wherein a corresponding support qualifier is assumed to be mandatory (M). It is to be noted that also here the definitions provided for the attribute represent only one of a plurality of examples, i.e. the type of data concerned by this data set is not limited to that specified here (i.e. UTF-8 data, i.e. UCS Transformation Format, wherein UCS means Universal Coded Character Set) and could by any other suitable type of data.
Next, a definition of context data for meta data types is described.
Basically, instances of the data types (i.e. the “real” data) are related to the context, in which they have been produced. According to examples of embodiments, this context relates to the time of production and a purpose, i.e. what is described by the data (i.e. the scope of the data).
Attributes and definitions describing context data for meta data instances are indicated in table 3 below, wherein a corresponding support qualifier is assumed to be mandatory (M). It is to be noted that also here the definitions provided for the attributes represent only one of a plurality of examples, i.e. the scope or time frame related to the data set is not limited to that specified here and could by any other suitable type of data.
In the following, a definition of a model for non-3GPP data sources is described.
As described above, NRM describes generic Information Object Classes (IOCs) and relationships thereof. These artefacts are network technology agnostic (i.e. generic) and are used for modelling aspects of networks that do not differ between different network types, such as GSM, LTE, UMTS and 5G or transport networks.
A corresponding modelling pattern is also applied in examples of embodiments for modelling entities producing data. In the following, it is explained how to apply a suitable modelling pattern and required extensions to different kinds of data producers. Specifically, different concepts for modelling are proposed for data produced, depending on how close the data producer is integrated with telecommunication network.
Basically, as a key concept of IOCs used in 3GPP networks for NRM, a so-called ManagedElement and a so-called ManagedFunction are provided.
A ManagedElement is an IOC that represents a device or equipment providing support and/or service to a user or subscriber. A ManagedElement instance is used for communicating with a manager (directly or indirectly) over one or more management interfaces for the purpose of being monitored and/or controlled.
A ManagedFunction is an IOC that provides attribute(s) that are common to functional IOCs.
It is to be noted that a ManagedElement may contain one or more managed functions, and a managed function may contain other managed functions as specified for a specific subclass. When multiple ManagedFunction instances are contained, they can be all of different kinds, all of the same kind, or some of different kind and some of the same kind.
Another key concept the so-called “job” concept. A “job” is a process with some purpose running on a network function or a management function. Multiple jobs are often associated with some common purpose. These jobs are represented in the model with dedicated objects, whose class normally includes the word “job”, like XYZJob.
The main difference between a job and a managed function is that the jobs are dynamically created and deleted as part of the normal daily operational process (normal configuration management, CM), whereas managed function instances correspond to either physical resources or virtualized resources. When associated with virtualized resources, managed functions have typically a longer lifetime and their life cycle is managed by life cycle management processes.
In the following, different modelling approaches depending on how well the data producer is integrated with telecommunication network functions are described.
First, a situation is assumed in which the entity producing data is a stand-alone managed element not attached to any 3GPP defined network function. For example, this is the case for data producers 1 (camera) or data producer 2 (news feed) which are shown in
In this case, the entity producing non-3GPP data is modelled as follows:
For example, the specialized Managed Function is derived by inheritance from the ManagedFunction IOC defined in present 3GPP standard, such as the 3GPP TS 28.622 standard. It is to be noted that in one example the ManagedFunction IOC in turn may inherit from Function_IOC defined in 3GPP standard TS 28.620 and the TopX IOC defined in 3GPP standard TS 28.622, for example.
For example, as a name of the specialized ManagedFunction, XYZFunction may be set, wherein with XYZ indicating the type of the ManagedFunction, such as Non3GPPDataSourceFunction, or cameraFunction.
On the other hand, when the entity producing data is tightly integrated/associated with one or more 3GPP defined NFs (and hence also with the Managed Element containing the Network Function), a differing model approach may be used. For example, the entity producing such non-3GPP data is modelled as follows:
It is to be noted that the XYZsFunction in this case may have a relationship to other objects in the model, for example to a cell object, when the data it is producing is related to that cell.
According to examples of embodiments, the XYZFunction in the above cases contains inherited attributes and attributes as defined in the following Table 4. It is to be noted that attribute constraints are defined in Table 5.
Specifically, attribute names and definitions describing the attributes of the XYZFunction are indicated in table 4 below, wherein a corresponding support qualifier is assumed to be mandatory (M) or conditional mandatory (CM).
On the other hand, attribute constraints of the data source function IOC are indicated in table 5 below.
Furthermore, when the entity producing data is fully integrated with a 3GPP defined network function and is no managed function by its own, the entity producing the data can be modelled as follows:
Next, examples of embodiments for exposing the meta data in order to allow data consumers to understand the received type of data are described.
As described above, meta data are contained in an attribute of XYZFunction Managed Object Instance (MOI). This allows any data consumer to read the meta data and to understand from that what kind of data and for what purpose it can get from the data source represented by the MOI.
With regard to the association of meta data and context data to data instances, meta data and context data describes the data instances produced by the data producer. When reporting data instances to data consumers, meta data and context data is usually reported together with data instances.
However, in order to reduce an amount of transferred data, according to examples of embodiments, the meta data can be omitted from being transferred with every data instance. Instead, data consumers may get the meta data from data producers in alternative ways.
As one alternative, the meta data can be read by the data consumer from the object representing the data producer. Another alternative is that headers are defined with the meta data when reporting the data instances with files. Furthermore, dedicated packets carrying meta data can be defined when reporting the data in data streams. Moreover, specific addresses for retrieving data instances can be defined wherein certain meta data are associated to these addresses.
In the next phase which concerns the procedure for selecting a data storage (i.e. procedure B), elements being involved are the DCCF 24 and the DSC MnF 40.
The DSC MnF receives a request from the DCCF to provide an address where data, that will be produced later by the data producer, shall be stored. The request contains the meta data for the data to be produced. For example, the address is typically a URI.
Furthermore, the DSC MnF generates a schema describing the format in which the produced data and the associated meta data are to be stored into the storage. For example, the schemas may include one of an XML schema, a JSON schema or a YANG schema.
Then, the DSC MnF allocates an address. This process includes, for example, selecting an appropriate data storage or creating a new data storage in case no appropriate data storage exists. In REST it may also mean creating a resource (identified by a URI) where the produced data will be written to and read from. The representation of this resource may then be described, for example, by the JSON schema as indicated above. A query pattern for retrieving the stored data at a later point of time may be generated as well.
Thereafter, the DSC MnF returns the address to the DCCF. It is to be noted that in case the query patter is generated, the query pattern is returned as well.
In the next phase which concerns the procedure for registration (i.e. procedure C), elements being involved are the DCCF 24 and the repository 22.
The data storage (i.e. the identifier thereof, like URI), location and query pattern, which are selected in procedure B, are registered in the repository by the DSC MnF. Furthermore, the meta data instance created in procedure A is registered in the repository by the DCCF.
In the next phase which concerns the data storage procedure (i.e. procedure D), elements being involved are the data producer B 30, the DCCF 24 and the storage 50.
When the requested data are produced, the data producer B 30 sends the produced data to the DCCF 24. Furthermore, the produced data are stored in the storage 50. For this purpose, either the DCCF or alternatively the data producer sends the produced data to the storage 50, where it is stored. In addition, the DCCF sends the produced data to the data consumer A.
Then, as the next phase, the procedure for discovery and reuse of the (stored) data (i.e. procedure E) is described. Elements being involved here are the DCCF 24, the CM MnF 26, the DSC MnF 40, the storage 50 and the repository 22.
When the DCCF receives a request for certain data from data consumer A, which may have already been produced and are stored beforehand in the storage, the DCCF forms a request for these data, including metadata of the data. This request is sent to the repository.
On the repository side, the meta data are resolved into the URI(s) of the relevant data producer(s) or the URI(s) of the relevant data storage, depending on where the needed piece of data is available or maybe become available in the future. It is to be noted that in the present examples of embodiments, it is assumed that the requested piece of data has been stored in the storage 50 and has been registered to the repository. That is, it is recognized that the data only needs to be fetched from the data storage, without the need to produce it.
In this situation, the repository responds to the DCCF with the registered URI(s) where the needed data can be retrieved. The DCCF then requests the CM MnF to create and activate a datamining job via the DSC MnF.
In reaction to the datamining job, the data storage reports the corresponding (historical) data extracted from the storage to the DCCF which in turn provides the data consumer with the retrieved data.
It is to be noted that a service chaining configuration can be also applied. In the service chaining configuration, a data consumer may act as data producer and provide the received data further to another data consumer. The (first) data consumer may also inform the (second or other) data consumer about the combined meta data of the extracted piece of data. For example, the DCCF may act as data consumer and as data producer for the respective counterpart.
In the following, examples of embodiments illustrating a specific implementation of the concepts described above are described in connection with
Specifically,
In the example discussed in
DCCF knows that there are no such data available yet, and decides consequently that they need to be newly produced. This is based, for example, on the time period requested, or the kind of data being requested. On the other hand, the DCCF also recognizes that the requested data (here the MDT data) represent valuable and expensive data to be produced. This determination may be based, for example, on a processing allowing to recognize what type of data is to be produced, which data consumer requests the data, or the source from where the data are to be obtained.
Consequently, the DCCF decides to start two tasks, i.e. (1) to activate the MDT job and provide the produced MDT data to the data consumer, and (2) to register the produced data as a reusable resource and to store the data for a later reuse.
In the present example, the schema to store the produced MDT data instance (i.e., for example, nrRLFReport) is defined by the DCCF, for example, as a relation schema for a relational database of the following manner:
relation schema: table name <“nrRLFReport”>:: standardizationBody “3GPP” standard “TS37.320”: version “g00”: time “1.12.2020-31.12.2020”: scope: <ID of network entities>: jobType: “mdt”: 1..*(attribute name <attribute_value_type>:).
In the signaling diagram according to
Specifically, in S200, the data consumer 10 sends a request for data to the DCCF 24, which is in the present example related to MDF data. In the request message, as also indicated above, a scope indication regarding a time indication, such as a starting time (like 00.00 h on 1.12.2020 to 23.59 h on 31.12.2020), an interval for the data provision (e.g. seconds, minutes etc.) and the like, an indication of the purpose of the data (such as a set of supported technology, like 3GPP TS37.320 g00; MDT) and an indication regarding a data name (such as nrRLFReport) are provided.
In S205, the DCCF 24 makes a decision that relevant data sources are to be discovered, i.e. a discovery process for relevant data producers is initiated.
In S210, the DCCF 24 sends to the CM MnF 26 an indication regarding provisioning of a management service. In the indication, the CM MnF 26 is informed, for example, that it has to provide all available data producers being capable to provide data regarding the scope indication obtained in the request from the data consumer in S200, i.e. time, purpose and data name. That is, the CM MnF 26 receives a request from the DCCF 24 to activate available data producers to produce and report the required data to the DCCF 24.
In S213, the CM MnF 26 creates a meta data instance describing the data that are to be produced by a data producer. In the present example, the meta data instance indicates e.g. 3GPP, TS37.320 g00, nrRLFReport_MDT, scope and time as indicated above).
In S215, the configuration MnF 26 responds to the indication received in S210 with a provisioning MnS response message, in which the relevant MDT data producers are indicated (i.e. a list of IDs of one or more MDT data producers). Furthermore, the generated meta data instance of S213 is indicated. It is to be noted that according to some examples of embodiments the response may include also an identifier for the meta data instance. This identifier may be used later when reporting the produced data. In addition, DCCF 24 requires the meta data to create MOI(s) for the needed data producer(s) to produce the requested data.
In S220, the DCCF 24 informs the CM MnF 26 that a MOI is to be created for provisioning the MnS. In this connection, the DCCF 24 informs that an MDT job is to be created wherein the meta data instance information is also included. As consumer of the data, the DCCF 24 may be indicated.
In S225 and S230, the CM MnF 26 communicates with the indicated data producer(s) (in the present example only data producer B is used) for creating the MOI. In detail, in S225, the CM MnF 26 informs the data producer B in a provisioning MnS indication that a MOI with an MDT job is to be created wherein the meta data instance information is also provided. In S230, the data producer B confirms the successful MOI creation.
In S245, the CM MnF 26 confirms to the DCCF 24 the successful MOI creation indicated in S220.
In S250, the DCCF 24 creates a schema for the data to be produced (i.e. the MDT data in the present example). In other words, the DCCF 24 defines a nrRLFReport schema to be generated by the data producer(s) (here, data producer B).
In S255, the DCCF 24 informs the DSC MnF 40 that a data object is to be created for provisioning the MnS. In this connection, the DCCF 24 informs about the nrRLFReport schema. That is, the DSC MnF 40 receives a request from the DCCF 24 to provide a resource or an address where data, that will be produced later by the data producer B, shall be stored. The request contains the meta data for the data. It is to be noted that according to examples of embodiment the address is a URI, for example.
In reaction to the indication in S255, the DSC MnF 40 generates a schema describing the format in which the produced data and the associated meta data shall be stored into a data storage. For example, this schema can include an XML schema, a JSON schema or a YANG schema. Moreover, the DSC MnF 40 allocates an address for the storing of the data. This process include, for example, a selection of an appropriate data storage (in the present example, this is e.g. data storage 50). Alternatively, a new data storage can be created (e.g. in a cloud environment) in case no appropriate data storage exists. In REST, it may also mean creating a resource (identified by a URI) where the produced data will be written to and read from. The representation of this resource can then be described by the JSON schema generated by the DSC MnF, as described above.
Moreover, the DSC MnF 40 generates a query pattern for retrieving the stored data later. That is, the DSC MnF 40 specifies a read query and write query for accessing the data (e.g. the nrRLFReport) to be stored in the data storage.
In S260, the DSC MnF 40 returns to the DCF 24 the address and the defined data access schema (read query and write query of the nrRLFReport, for example).
In S265, the DCCF 24 registers the obtained information, i.e. the meta data instance, the address or ID (URI) of the data storage and the data access schema (read query, write query) in the repository 22 by using a provisioning message.
In S270, the repository 22 confirms to the DCCF 24 the successful registration.
In S273, the data producer (here data producer B) which is instructed to create the required data (in the present example the MDT data) starts the production of the date. For this, the data producer conducts a configuration processing according to the meta data instance being provided in S225, and activates the corresponding MDT job. It is to be noted that the processing in S273 is independent from the order of processing shown in
In S275, the data producer B sends the produced data to the DCCF 24, e.g. in the form of an MDT MnS report signaling including the data being produced, the meta data (or an identifier thereof, as indicated above), and an indication regarding a sub scope, such as a list of cells and the like.
In S280, the DCCF sends the produced data to the data storage 50 in which the data are to be stored. For this, a MDT MnS signaling for storing data is sent to the data storage 50, including e.g. the URI, the write query instance of the nrRLFReport data.
It is to be noted that the processing in S280, i.e. the storing of the produced data, can be also effected by data producer B, which can directly store the nrRLFReport data to the data storage. For this, it is required that the data storage URI and the writeQuery instance of the nrRLFReport data are indicated to the data producer B in advance, e.g. by the DCCF or the DSC MnF, when they are available.
Furthermore, it is to be noted that the processing of S275 and S280 is executed in a loop, i.e. the processing is executed per MDT data producer (in case more than one producer is involved) and per MDT report.
In S285, the DCCF 24 conducts a processing for transforming the data reported from the data producer B, for example, the RLF report data are combined. It is to be noted that S285 is optional and can also be omitted, depending on the system setting.
S290, the DCCF 24 sends the produced data to the (original) data consumer A. The report can also include the meta data instance.
In the example discussed in
In contrast to the example discussed in
In addition, according to the present example, the CM MnF plays a role in which it is requested to create and activate an datamining job for DSC MnF so as to extract the needed piece of data with the registered URI(s) and the combined meta data. The datamining job at DSC MnF is used to extract the needed piece of data from the data storage according to the resolved URI and combined meta data of the requested piece of data. Then, the data storage provides the extracted data to DCCF which in turn can forward them to the data consumer.
In the signaling diagram according to
In S300, similar to S200 in
In S305, the DCCF 24 forms a request for data, including meta data of the data. That is, a meta data instance including, for example, the information obtained in S300, i.e. the scope indication obtained in the request from the data consumer in S200, like time, purpose and data name.
In S310, the request formed in S305 is sent to the repository 22 by means of an indication regarding provisioning of a management service. In the indication, the repository 22 is informed, for example, about the meta data instance.
Since, in the present example, the needed piece of data has been stored in data storage (e.g. in a process as described in connection with
In S320, the DCCF 24 indicates to the CM MnF 26 that a MOI is to be created for provisioning the MnS. In this connection, the DCCF 24 informs that an datamining job is to be created wherein the meta data instance information, the URI(s) and the read query of the nrRLFReport are also included. As consumer of the data, the DCCF 24 may be indicated. In other words, the DCCF 24 requests CM MnF 26 to create and activate a datamining job via the DSC MnF 40.
In S325 and S330, the CM MnF 40 communicates with the DSC MnF 40. Specifically, in S325. In detail, in S325, the CM MnF 26 informs the DSC MnF 40 in a provisioning MnS indication that a MOI with an datamining job is to be created wherein the meta data instance information, the URI(s) and the read query of the nrRLFReport are also included. Furthermore, it is defined that the DCCF is the call-back entity. In S330, the DSC MnF confirms the successful MOI creation.
In S335, the CM MnF 26 confirms to the DCCF 24 the successful MOI creation indicated in S330.
In S340, the DSC MNF 40 starts the datamining job. For this, the DSC MnF 40 conducts a configuration processing with the data storage 50 according to the meta data instance being provided in S325, and activates the datamining job for retrieving the requested data. In this context, the DSC MnF 40 informs the data storage 50 also about the DCCF being the call-back entity, and indicates the read query of the nrRLFReport.
In S345, the data storage 50 sends the historical data extracted in the datamining back to the DCCF 24, e.g. in the form of a data storage MnS report signaling including the data being retrieved and the meta data (or an identifier thereof, as indicated above).
In S350, the DCCF 24 conducts a processing for transforming the data reported from the data storage, for example, the report data are combined. It is to be noted that S285 is optional and can also be omitted, depending on the system setting.
In S355, the DCCF 24 sends the reported data to the (original) data consumer A. The report can also include the meta data instance.
In S400, the DCCF receives, from a data consumer, e.g. data consumer A, a request for providing data from a data source for processing by the data consumer, and to process the request. This corresponds, for example, the processing related to S200 in
According to examples of embodiments, the request includes at least one of a geographic location or an indication of a network part to which the requested data are to be related, at least one of a time indication or a time period to which the requested data are to be related, and a purpose of the data, e.g. as described in connection with S200 in
In S410, the DCCF obtains, from a configuration management function, such as CM MnF 26, a meta data instance related to the requested data, as described above in connection with S210, S213, and S215 in
In S420, the DCCF creates a schema of the requested data based on the meta data instance, as described above, for example, in connection with S250 (i.e. the schema of the specified MDT data nrRLFReport, for example).
Furthermore, in S430, the DCCF obtains a schema for accessing the data being provided by a data source for making the data reusable as history data. This is in correspondence, for example, with the processing described in connection with S255 and S260 in
In S440, the DCCF registers the obtained meta data instance and the schema for accessing the data in a repository, such as repository 22, as described in connection with S265 and S270 in
According to some further examples of embodiments, when obtaining the meta data instance related to the requested data e.g. from the CM MnF 26 in S410, there is provided also an identification of at least one data source being able to produce the requested data, such as of data producer B. Then, the DCCF sends an indication to create a managed object instance to the CM MnF 26 based in the received identification of the data source being able to produce the requested data, as described, for example, in connection with S220 to S245 in
Moreover, according to examples of embodiments, the DCCF conducts also a processing as described in connection with
When the DCCF receives the history data from a data storage, as indicated in connection with S345 in
In S500, the DSC MnF receives, from a data collection coordination function such as DCCF 24, a request for providing information regarding a data storage in which data being provided by a data source for making the data reusable as history data can be stored. The request comprises, for example, a schema of the data based on a meta data instance related to the data to be stored. For example, the processing in S500 is in accordance with the processing described above in connection with S255 in
In S510, the DSC MnF determines a data storage being suitable for the request. According to examples of embodiments, for determining the data storage, an existing data storage being suitable for storing the data can be selected, or a new data storage being suitable for storing the data can be created.
In S520, the DSC MnF creates a schema for accessing the data, as described, for example, in connection with S255 in
Then, in S530, the DSC MnF sends an indication of the determined data storage and the schema for accessing the data to the DCCF, as described in connection with S260 in
In S600, the repository receives, from a data collection coordination function, such as DCCF 24, a request to resolve a meta data instance, generated on the basis of a request for providing data, to an indication of data resources for the data corresponding to the requested data. In the processing in S600, a processing corresponding to that described in connection with S310 in
In the processing in S600, according to some examples of embodiments, the repository is configured to determine, as the data resources for the data corresponding to the requested data, one of a data producer capable of producing the data (e.g. data producer B) or a data storage (e.g. storage 50) storing history data corresponding to the requested data.
In S610, the repository provides, to the DCCF 24, the indication of the data resources for the data, as also described in connection with S315 in
According to examples of embodiments, the repository receives, from the DCCF 24, also a request to register a meta data instance and a schema for accessing data being provided by a data source for making the data reusable as history data. This processing is in correspondence with the processing described in connection with SS265 and S270 in
The DCCF 24 shown in
The processor or processing function 241 is configured to execute processing related to the above described control processing. In particular, the processor or processing circuitry or function 241 includes one or more of the following sub-portions. Sub-portion 2411 is a processing portion which is usable as a portion for receiving a request for data. The portion 2411 may be configured to perform processing according to S400 of
The data store control management element or function 40 shown in
The processor or processing function 401 is configured to execute processing related to the above described management control processing. In particular, the processor or processing circuitry or function 401 includes at least one or more of the following sub-portions. Sub-portion 4011 is a processing portion which is usable as a portion for processing a request for providing data storage information. The portion 4011 may be configured to perform processing according to S500 of
The repository 22 shown in
The processor or processing function 221 is configured to execute processing related to the above described control processing. In particular, the processor or processing circuitry or function 221 includes one or more of the following sub-portions. Sub-portion 2211 is a processing portion which is usable as a portion for receiving and processing a resolve request. The portion 2211 may be configured to perform processing according to S600 of
It is to be noted that examples of embodiments of the disclosure are applicable to various different network configurations. In other words, the examples shown in the above described figures, which are used as a basis for the above discussed examples, are only illustrative and do not limit the present disclosure in any way. That is, additional further existing and proposed new functionalities available in a corresponding operating environment may be used in connection with examples of embodiments of the disclosure based on the principles defined.
According to a further example of embodiments, there is provided, for example, an apparatus for use by a communication network element or function configured to act as a data collection coordination function in a communication network, the apparatus comprising means configured to receive, from a data consumer, a request for providing data from a data source for processing by the data consumer, and to process the request, means configured to obtain, from a configuration management function, a meta data instance related to the requested data, means configured to create a schema of the requested data based on the meta data instance, means configured to obtain a schema for accessing the data being provided by a data source for making the data reusable as history data, and means configured to register the obtained meta data instance and the schema for accessing the data in a repository.
Furthermore, according to some other examples of embodiments, the above defined apparatus may further comprise means for conducting at least one of the processing defined in the above described methods, for example a method according to that described in connection with
According to a further example of embodiments, there is provided, for example, an apparatus for use by a communication network element or function configured to act as a data store controlling function in a communication network, the apparatus comprising means configured to receive, from a data collection coordination function, a request for providing information regarding a data storage in which data being provided by a data source for making the data reusable as history data can be stored, wherein the request comprises a schema of the data based on a meta data instance related to the data to be stored, and to process the request, means configured to determine a data storage being suitable for the request, means configured to create a schema for accessing the data, and means configured to send an indication of the determined data storage and the schema for accessing the data to the data collection coordination function.
Furthermore, according to some other examples of embodiments, the above defined apparatus may further comprise means for conducting at least one of the processing defined in the above described methods, for example a method according to that described in connection with
According to a further example of embodiments, there is provided, for example, an apparatus for use by a communication network element or function configured to act as a repository in a communication network, the apparatus comprising means configured to receive, from a data collection coordination function, a request to resolve a meta data instance, generated on the basis of a request for providing data, to an indication of data resources for the data corresponding to the requested data, and to process the request, and means configured to provide, to the data collection coordination function, the indication of the data resources for the data.
Furthermore, according to some other examples of embodiments, the above defined apparatus may further comprise means for conducting at least one of the processing defined in the above described methods, for example a method according to that described in connection with
According to a further example of embodiments, there is provided, for example, a non-transitory computer readable medium comprising program instructions for causing an apparatus to perform, when used in a communication network element or function configured to act as a data collection coordination function in a communication network, a processing comprising receiving, from a data consumer, a request for providing data from a data source for processing by the data consumer, and processing the request, obtaining, from a configuration management function, a meta data instance related to the requested data, creating a schema of the requested data based on the meta data instance, obtaining a schema for accessing the data being provided by a data source for making the data reusable as history data, and registering the obtained meta data instance and the schema for accessing the data in a repository.
According to a further example of embodiments, there is provided, for example, a non-transitory computer readable medium comprising program instructions for causing an apparatus to perform, when used in a communication network element or function configured to act as a data store controlling function in a communication network, a processing comprising receiving, from a data collection coordination function, a request for providing information regarding a data storage in which data being provided by a data source for making the data reusable as history data can be stored, wherein the request comprises a schema of the data based on a meta data instance related to the data to be stored, and processing the request, determining a data storage being suitable for the request, creating a schema for accessing the data, and sending an indication of the determined data storage and the schema for accessing the data storage to the data collection coordination function.
According to a further example of embodiments, there is provided, for example, a non-transitory computer readable medium comprising program instructions for causing an apparatus to perform, when used in a communication network element or function configured to act as a repository in a communication network, a processing comprising receiving, from a data collection coordination function, a request to resolve a meta data instance, generated on the basis of a request for providing data, to an indication of data resources for the data corresponding to the requested data, and processing the request, and providing, to the data collection coordination function, the indication of the data resources for the data.
By means of embodiments of the present invention, it is possible to provide a mechanism allowing to register, discover and retrieve data, in particular so-called historical data indicating events or measurements of the past, in a communication network based on e.g. 3GPP standards. Specifically, means for obtaining historical data needed, for example, for artificial intelligence based processing in troubleshooting and diagnostic procedures as well as analytics application in network management and control are provided. That is, movement of data to applications that may be coming from different vendors is supported.
It should be appreciated that
Although the present disclosure has been described herein before with reference to particular embodiments thereof, the present disclosure is not limited thereto and various modifications can be made thereto.
| Number | Date | Country | Kind |
|---|---|---|---|
| 21157890.1 | Feb 2021 | EP | regional |
