WO2017032394A1 - Network data sharing in communication networks - Google Patents

Network data sharing in communication networks

Info

Publication number
WO2017032394A1
WO2017032394A1 PCT/EP2015/069246 EP2015069246W WO2017032394A1 WO 2017032394 A1 WO2017032394 A1 WO 2017032394A1 EP 2015069246 W EP2015069246 W EP 2015069246W WO 2017032394 A1 WO2017032394 A1 WO 2017032394A1
Authority
WO
Grant status
Application
Patent type
Prior art keywords
data
network
infrastructure
resource
information
Prior art date
Application number
PCT/EP2015/069246
Other languages
French (fr)
Inventor
András RÁCZ
Tamas Borsos
Norbert REIDER
András VERES
Original Assignee
Telefonaktiebolaget Lm Ericsson (Publ)
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00Arrangements for maintenance or administration or management of packet switching networks
    • H04L41/08Configuration management of network or network elements
    • H04L41/085Keeping track of network configuration
    • H04L41/0853Keeping track of network configuration by actively collecting or retrieving configuration information
    • GPHYSICS
    • G06COMPUTING; CALCULATING; COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/06Digital input from or digital output to record carriers, e.g. RAID, emulated record carriers, networked record carriers
    • G06F3/0601Dedicated interfaces to storage systems
    • G06F3/0668Dedicated interfaces to storage systems adopting a particular infrastructure
    • G06F3/067Distributed or networked storage systems, e.g. storage area networks [SAN], network attached storage [NAS]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00Arrangements for maintenance or administration or management of packet switching networks
    • H04L41/14Arrangements for maintenance or administration or management of packet switching networks involving network analysis or design, e.g. simulation, network model or planning

Abstract

Operating an infrastructure resource of a communication network comprising processing and memory resources, comprising providing an infrastructure functionality; providing a data collection functionality for collecting data related to said infrastructure functionality, and providing a data sharing functionality for sharing the collected data with another infrastructure resource of said communication network.

Description

Network Data Sharing in Communication Networks

Technical Field

The present invention relates to sharing collected data amongst infrastructure resources of a communication network, and, more particularly, to sharing collected data that relates to a functionality of an infrastructure resource of a communication network, such as, for exam le , a wireless telecommunication network . The present invention thus also relates to corresponding methods of operating a communication network infrastructure resource, corresponding communication networks , and corresponding computer programs and computer program products .

Background

Modern communication networks are large-scale technical entities with a considerable number of individual components that together form the so-called infrastruc ure of the network . By means of this infrastructure the users of the communication networks can enj oy the respective network service, e.g. the users of a wireless telecommunication network can enjoy, amongst others, mobile telephony or mobile internet access . In such a case , the involved resources comprise for example a radio base station, switching centers, core network gateways and routers, or, as a more general term, so-called nodes or network elements (NEs) .

As such communication networks need to be managed, operated and controlled, and for this purpose the responsible operators will require information on the state of each involved infrastructure resource so as to be able to take respective decisions and to effect actual network control . Accordingly, conven ional communication networks already provide co-called analysis functions that collect (local) state data of infrastructure resources and that process this collected data in some sort of central depository. The network operator is thus enabled to retrieve state information regarding the equipment in the field for controlling the involved resources . In general , an infrastructure resource can be any type of individual or agglomeration of equipment provided in the field for implementing the network as such (e.g. a network element, base station, etc . ) .

Specifically, the mentioned analytics functions can be running in a cloud deployment in a corresponding data center environment . After the processing, analysis and combination of different pieces of data, the central analytics functions may produce new data models, which data models may be further used as input to other analytics processing functions . Naturally, such a setup may require that all pieces of input data are collected from the network elements (NEs) at a central place, which might impose extra overhead due to the transfer of large amount of raw data, which data might even be dropped after the processing anyway .

Another consequence of this architecture is that it does not enable the infrastructure resources (e.g. a NE) for themselves to access network data from each other or to access the composite data models produced by top level analytics functions . The limited access to different pieces of information elements and data models from the network elements limits also the possibility to execute analytics processing by the network elements themselves and use the analytics information to drive network functions and network behavior. The major bottleneck here largely stems from the somewhat limited inter-node communication facilities amongst individual infrastructure resources or network elements .

Conventional systems usually employ between network elements corresponding interface and protocol definitions , wherein the interface is defined by the communication protocol to be used for the message exchanges over that interface . The protocol defines what kind of messages with what kind of information contents can be exchanged over the interface, how the peer NE should react when receiving a certain type of message, etc .

It is therefore clear that resources are not free in exchanging and accessing information, and in particular collected analysis data, with and from other resources . Namely, if a network element wants to exchange some specific control or status information, it is required that there exists a corresponding protocol with the necessary information element defined inside the protocol messages to exchange the given type of information. This way of defining network architecture is a generic principle valid for many types of communication systems today and thus followed by the involved standardization bodies (e.g. , 3GPP, IETF, etc . ) .

In the conventional centralized analytics architectures all analytics data models are produced centrally, leaving little room for analytics execution in the network elements . Moreover, the centralized processing requires the transfer of large amount of raw data from the network edges to the data center. This may load the transport connections and may introduce longer turn-around times and delays, limiting the real-time capabilities of the analytics system.

Unfortunately, conventional communication interfaces between NEs are not suitable for flexible data model sharing due to multiple reasons . First, it is not feasible to transmit larger amounts of data in existing interface messages . Second, the existing interfaces are inflexible, meaning that the message formats information elements need to be predefined, possibly even standardized, resulting in a case- by-case integrated solution. Further, the topology of such interface connections is also limited and inflexible, in the sense that the number of such connections per node is limited to its neighbors and there is an overhead with the maintenance and management of such connections .

At the same time, however, as modem networks become more and more powerful and complex, analytics driven network control become more and more important . Specifically, there is a need for a more self-controlled operation in the sense that individual resources can react by themselves to given situations , without { immediate) access to or control from a central entity. Further, there is a need to execute analytics functions in the resources themselves and to exchange analytics data models between individual resources in a flexible and a self -controlled way.

Summary

The above mentioned problems and drawbacks of the conventional concepts are solved by the subject-matter of the independent claims . Further preferred embodiments are described in the dependent claims .

According to an aspect of the present invention there is provided an infrastructure resource of a communication network comprising processing and memory resources configured to provide an infrastructure functionality, wherein said resources are further configured to provide a data collection functionality for collecting data related to said infrastructure functionality, and provide a data sharing functionality for sharing the collected data with another infrastructure resource of said communication network . According to another aspect of the present invention there is provided a method for operating an infrastructure resource of a communication network comprising processing and memory- resources, the method comprising a step of providing an

infrastructure functionality; a step of providing a data collection functionality for collecting data related to said infrastructure functionality, and a step of providing a data sharing functionality for sharing the collected data with another infrastructure resource of said communication

network .

According to another aspect of the present invention a computer program that comprises code is provided, the code , when executed on processing resources, instructs the processing resources to perform a method embodiment of the present invention.

According to another aspect of the present invention a computer program product that stores a code is provided, the code, when executed on processing resources, instructs the processing resources to perform a method embodiment of the present invention.

Brief Description of the Drawings

Embodiments of the present invention, which are presented for better understanding the inventive concepts but which are not to be seen as limiting the invention, will now be described with reference to the Figures in which:

Figure 1 shows a schematic view of the concept of a general embodiment of the present invention in the context of a communication network; Figure 2 shows a flowchart of a general method embodiment of the present invention;

Figure 3 shows a schematic view of an individual infrastructure resource in t e exemplary- form of a network element according to a further embodiment of the present invention;

Figure 4 shows a schematic view of an embodiment of the present invention in the context of a communication network;

Figure 5 shows a schematic view of an embodiment of the present invention where a system comprises distributed components and some central components ;

Figure 6 shows a flowchart of a more specific method embodiment of the present invention;

Figure 7 shows a flowchart of a further more specific method embodiment of the present invention;

Figures 8A to 8C show schematic views of system architectures according to further embodiments of the present invention, and

Figure 9 shows a schematic view of a conventional deployment in the context of communication networks . Detailed Description

Figure 1 shows a schematic view of the concept of a general embodiment of the present invention in the context of a communication network. As part of such a communication network an infrastructure resource 10 (e.g. a network element, NE) comprises any kind of required processing and memory resources that are configured to provide a corresponding infrastructure functionality 101. For example , the infrastructure resource 10 may be a base station network element of a wireless telecommunication network . In this case, the corresponding infrastructure functionality 101 will at least include one or more functionalities typical to a base station, e.g. maintaining a radio link with a mobile station, transmitting and receiving data to and from a mobile station, handling hand-overs to neighboring base stations , and the like . Other examples for the infrastructure resource include switching centers , gateways , routers , etc .

The processing and memory resources of the infrastructure resource 10 are further configured to provide a data collection functiona1ity 102 for collecting data D related to the infrastructure functionality 101. This data includes suitable information for characterizing a state or mode of the (target) infrastructure functionality 101. In other words , the data collection functionality 102 may collect any data that allows to control the resources 10 or the communication network as a whole in a more desirable or efficient fashion. Specifically, the collected data D may indicate a number of mobile stations connected to a base station as one exemplary implementation of the infrastructure resource 10. If this number is disadvantageously high, for example , an analytics function may yield that a neighboring base station has free communication capacities . This would allow for a handover of some mobile stations to the neighboring base station to control the network as a whole more efficiently. The infrastructure resource 10 may optionally comprise a local data repository 103 that, at least temporarily, stores the data collected by the collection functionality 102. The processing and memory resources of the infrastructure resource 10 are further configured to provide a data sharing functionality 104 that then either accesses the optional data repository 103 or directly retrieves the data from functionality 102 for sharing the collected data with another infrastructure resource 10' of said communication network. Following the above example, the other infrastructure resource 10' may be a neighboring base stat ion with a corresponding data sharing fur:ct iona1ity 104 ' . By means of sharing data between the two data sharing functionalities 104 and 104', i.e. by sending data 91 from resource 10 to resource 10', and, likewise, data 92 from resource 10' to resource 10, the resources can effect decentralized analytics and control functions without the necessary involvement of a central analytics and/or control entity.

In any way, however, an optional registry entity 20 can be provided to facilitate and coordinate data sharing amongst infrastructure resources 10, 10' . Specifically, registry entity 20 can be configured to register what information is kept by what resource . In a way, the entity 20 may provide transparent data sharing in the sense that an individual infrastructure resource does not need to know where exactly any required information is stored. In this way, each participating data sharing functionality 104 may provide a part 103 of a distributed data base, wherein preferably, each resource stores its locally collected data into said part of the distributed data base . As a consequence, the distributed data base may be as a whole structured efficiently, so that collected data stored in one part differs from collected data stored in another part of the distributed data base in another infrastructure resource, and, in turn, redundancies in the system can be advantageously avoided. In a further embodiment, the collected data is stored in the form of virtual information data records comprising a plurality of information elements . The data sharing functionality 104 of one infrastructure resource 10 can then provide at least a part of the plurality of information elements . A particular virtual information data record can be then retrieved by the data sharing functionality by enquiring, for example , to the registry entity 20 of said communication network. The registry entity 20 can in this case register what information element of the information data record is stored in association with what infrastructure resource . Advantageously, the collected data can be as a whole accessed by virtual records whose constituent elements are generated (collected) and stored in a distributed fashion. This not only allows for minimizing data and information exchange amongst the resources , but also allows local access not involving all elements of a corresponding record.

Figure 2 shows a flowchart of a general method embodiment of the present invention. This method embodiment may for example take place in some infrast ucture resource or network element as controlling and operating the resource/element of a communication network. The method may comprise a step S10 of providing the corresponding infrastructure functionality . At a time when said infrastructure functionality S10 is provided, a step S20 of collecting data related to said infrastructure functionality is carried out . The collected data can then be shared with another infrastructure resource of the communication network in a step S30. The method embodiment may apply to operating one or more infrastructure resource (s) or a communication network as a whole .

Figure 3 shows a schematic view of an individual infrastructure resource 10 in the exemplary form of a network element according to a further embodiment of the present invention. In general , the infrastructure resource can be any entity in a communication network that provides some well- defined functionality and wherein said infrastructure functionality is subject to data collection for analysis, maintenance, or control purposes . Specifically, infrastructure resource 10 can be any communication network element or entity that comprises processing resources 111 (e.g. processing unit , processing unit collection, CPU, share of a data/processing center, etc . ) , memory resources 112 (memory device, database, share of a data center) , and communication means 113. By means of the latter, the resource 10 can communicate with the remainder of the communication network 30.

The memory resources 112 may store code that instructs the processing resources 111 during operation to implement any embodiment of the present invention. Specif cally, the memory resources 112 may store code that instruct the processing resources 111 during operation to provide the (target) functionality of the infrastructure 10 , e.g. one or more functionalities involved for implementing a network element such as a base station. According to the present embodiment , the memory resources 112 further store code that instruct the processing resources 111 during operation to provide a data collection functionality for collecting data related to the infrastructure functionality, and provide a data sharing functionality for sharing the collected data with another infrastructure resource of the communication network .

In other words , embodiments of the present invention propose a distributed and virtualized data sharing infrastructure for communication networks , where individual infrastructure resources (e.g. a network elements) themselves form a distributed information space, like a distributed virtual database . This proposed infrastructure enables to share data and execute analytics processing on the data across all the network elements in a communication network. The solution defines the communication mechanisms to be supported by NEs and the necessary infrastruc ure components that manage the placement, the movement and the access to the data in this virtualized data space . This generic data sharing service built into the system makes it easy to develop and deploy use cases in the network without the need to implement data communication mechanisms each time a new use case is realized. In general , embodiments of the present invention propose a distributing and virtualizing of the access, the storage and the processing of network data in a communication network .

The embodiments of the present invention do further not require replacing any existing network interfaces and architecture, which can be kept with the same functionality as today. The proposed functionality can be seen as an add-on that makes data and analytics capabilities available for the network functions . Embodiments of the present invention may generally provide the benefit that existing resources or network elements are used to build a distributed, general purpose data sharing infrastructure , where the data is stored and processed in a distributed way in the network nodes such that the whole sys em appears as one data platform for the applications . This means , for example, that the analytics applications and network functions can access any data available in the network in a transparent way without knowing the exact location of the data . Further, any of the resources {NEs) can produce data, process the data and provide the data as a "service" to others and likewise consume data and services from others . Thereby it becomes possible to implement new kinds of features in the network nodes and/or enrich existing features with new capabilities that cannot be realized today simply due to the lack of necessary information in the node .

Figure 4 shows a schematic view of an embodiment of the present invention in the context of a communication network . In a way, the proposed embodiment may also be referred to as Network Near Analytics (NNA) in the context of the present disclosure . According to the present embodiment , so-called "virtualized data models" are proposed, which may be identified as data models that are virtual ized in the sense that the different pieces of the data model may be located, stored at different physical locations in the network . For example, a data model storing user equipment (UE . Mobile terminal) state "UEState" may have pieces of information from the radio access network (RAN) side, i.e., radio connection state stored in the radio base station (RBS) and also service layer information stored in a core network node . Similarly, the UEState information pieces of one user may be located in node A, while the pieces of information of another user may be stored in node B . A virtualized data model may hold only the references to the physical pieces of the data model , holding the reference to the physical location of the data .

More specifically, the system according to the present embodiment includes a registry function 20 , which maintains the virtualized data models and their mapping to actual physical data and location. Network Elements 10, 10' , 10" as infrastructure resources may include local distributed analytics functions, which can access virtualized data models via well-defined APIs using the services of the Registry function 20. Each resource 10, 10' , 10" may locally store data elements Da, Db, Dd' , ... that are referenced to by virtual data models of different kinds 200 in the registry function 20. Accordingly, the local analytics function 102 can access the virtualized data by enquiring to the registry function 20. The API services and the Registry function are described in more details in connection with further embodiments as part of the present disclosure .

Figure 5 shows a schematic view of an embodiment of the present invention where a system comprises distributed components and some central components . Specifically, an infrastruc ure resource 10 comprises a data access API function 151 with data access API library functions 152 implementing the virtualized data sharing information space . These functions may provide in general one or more of the following services : a subscribe service to certain data models/sources from other nodes and applications 153, a service to publish data to other applications 153 , and a service to make actions (e.g., some node level action) . Generally, an application may operate such that it takes some input data, processes the data and produces some output data, which other applications can subscribe to . Additionally, an application may issue some commands or may trigger one or more actions . The latter actions may specifically depend on the use case, but are, in general , optional .

The entity that implements the API functions on the node side may enquire to central registry 20 to be able to find the mapping of the data to its physical location. This may involve registering the data services available from the node 10 in the central registry 20 (i.e. , to make it available for other applications, nodes , NEs, or infrastructure resources) . This may further involve an interface to node local data sources and action triggers whenever available . Such an API library function set may be provided in each node 10 that wants to be part of the NA information space . The central registry functions 250 in the central registry 20 are an entity that stores the mapping between logical data models and their physical location, which may include also the format in which the data is available (e.g. , stream based or look-up based, the time resolution of the data, etc . , ) .

The data storage and distribution functions 152 represent the data sharing and communication infrastructure, which provides the service to store and access data across the network of nodes . It can support different kinds of storage and data sharing methods, for exam le, in-memory look-up based access or real-time message stream based access, etc . It can be further assumed that as a standard solution, the node 10 could include an in-memory database (e.g. , Redis DB, no- cluster) and a real-time message bus system for data exchange and communication. The application space 153 can then be identified as an execution environment where data processing and analytics applications can be deployed to implement a particular use-case . The applications can access the data services across the network (e.g. , to access and information that is not available locally) via the data access API library functions .

Further details of the API services and associated requirements can be identified on the A interface between analytics applications and the analytics layer in the system as follows :

- A subscribe operation may be provided to "subscribe" to one or more data models . Accordingly, an application shall be able to "connect" to the subscribed model for accessing a specific data model in an abstract way without the need for taking into consideration the physical location of that data . The analytics API services can accordingly map the data model to a physical location (e.g. , to a specific data stream at a given IP address or to a specific in-memory database at a specific IP address/port) in a transparent way. That means that the analytics application developer only needs to deal with data models , not with the way how to physically access that data .

- An addressing operation may be provided for an application to address the data models that it wants to subscribe to . For identification the following general format can be assumed: Stream: DataType : IdType : IdValue, where "Stream" specifies the format , in which we want to access the data (in this example streamed format) , "DataType" identifies the type of the data (e.g. , user_session_record, cell_state__record, ...) , the "IdType" identifies the type field that is to be used as the identifier to filter which specific data records should be received (e.g., IMS I, celllD, ...) . The "IdValue" identifies the specific values of the IDType field of interest (e.g. , IMSI = 222154488448) .

- A publish operation may be provided for an application to make available its own data models to other applications , independently of the location of the other applications in the system (i.e. , being in another network node or in the analytics cloud ) . The "publishing" application should notify the system about its own data models without dealing with how other applications will physically access that data, as this should be solved by the system transparently . When creating a new data model the publishing application may specify the preferred storage type and location of the data but it is the system itself that will eventually decide about the placement .

Generally, it is noted that the location of data models may not even be static in the system. The API can transparently support the change in the physical location of a data model at any time . For instance, some instantaneous per user information may be stored locally, which information may need to be relocated to other nodes (eNodeB or local analytics server) in order to, e.g. , optimize the distance between the location of the data and the "consumer" of the data .

An exemplary modus of operation of the above embodiment is described in the following . For example, an application on a first infrastructure resource "1" (e.g. an eNodeB) produces a data model that stores current cell status (incl. the UE status in the cell) , that is to be accessed by a neighboring node "2" . At the same time node λλ2" also wants to access real-time traffic data of its users from the top level analytics cloud. In the application at node " 1" a new data model is created by declaring a new data type "CellState" and setting its properties . The properties of the data model may include at least the "StorageModel" and "AccessMethod" of the data, where the StorageModel give hints for the system how to store the data, for example, it could be "InMemory-Lookup" or "Database-Lookup" or "FileBased" , etc . , while the AccessMethod property specifies how the data should be accessed, which could be e.g., "Stream", "KeyValue-Lookup" , "SQL-query" , or the like . In this particular example of the CellState data model, it is chosen to set the StorageModel to inMemory-Lookup and the AccessMethod to KeyValue-Lookup .

In response to that the local API function decides to store the CellState information model in the local Redis-DB on the node and will register the availability of this data in a Central registry. The Central registry is responsible for storing the mapping between the logical data models and their physical location (in this example, specifying the mapping of CellState data record for CellID-A -> Redis-DB IP address : port) .

In the application at node "2" , a command can now be issued that opens access to this data model (e.g. "CellState : CellID- l" ) and read-out data. In response to that , the API library functions in node 2 will first interrogate the central registry to get the physical location of the requested data with IP address and then the library functions will establish the necessary connec ion to the Redis-DB at node 1. The API function will use this connection to fetch the data, whenever the application at node 2 makes a look-up . All of these steps may happen fully t ansparently for the application.

In order to access the real-time traffic information from top level analytics cloud, the application at node 2 opens a stream referencing the wanted data mode1 , filtered for the user identities of the specific users located at cell 2 : UETrafficlnfo: CellID-2. I response to that the API function at node 2 will interrogate the central registry to check whether such data stream is provided by the analytics cloud and to get the physical reference to that data stream. Then, one of the messaging ports at node 2 will be connected to a messaging port on the cloud side and the messages will start to flow.

The above operation may be generally summarized by the more specific method embodiments of the present invention as described in conjunction with the flowcharts of Figures 6 and 7. Specifically, Figure 6 shows a flowchart of a more specific method embodiment of the present invention, where in a step S61 an application creates a new data model and calls a "publish ( ) " API function . The API function can accordingly select suitable storage and communication methods for the data model in step 62. In a step S63 , the API function sends a register request to a central registry (e.g. registry 20) . This registry creates in a step S64 an entry for the new data model .

The corresponding access to shared data is then described in conjunction with Figure 7 showing a flowchart of a further more specific and corresponding method embodiment of the present invention. Specifically, in a step S71 an application references a data model that is not available locally . The API function requests in step S72 a location mapping for the referenced data from the central registry. The API function then establishes in step S73 a connection to the location point of the requested data by means of the information provided by the central registry. This can be, for example, a database connection. In a step S74 the API function fetches the requested data via the established connection and delivers it to the application.

The different types of data that can be exchanged in systems along the embodiments of the present invention are described by data models , where each data model identifies a certain type of data . For example, "CellState" can be a data model, which holds information about the real-time status of the cell , such as instantaneous load or number of users, etc . Each data model may include at least one or more of the following attributes specified: "Name" : the name of the model as a unique reference (e.g., CellState, UEState, UEHi story...) "Access type" : the ways how the data can be accessed, e.g., Stream, KeyValue-Lookup , SQL-query, "Storage type" : the ways how the data is stored, e.g., InMemory-Lookup or Database-LookUp or FileBased, "Time resolution" : the resolution of the data in time, i.e., how often the data is changing. For example, a state data record may contain the aggregated state for the last 5 minute and thereby refresh at every 5 minute; "Addressable IDs" : the list of data model fields that can be used as an ID when addressing the data (for example , in the CellState model the field CelllD may be used as an identifier when addressing the data) ;

As f r as the central registry is concerned, for example the entities 20 as described in conjunction with one or more of the Figures, may be configured to store the mapping between logical data models and their physical location, including also the other attributes of the data model (including e.g., access type, storage type, etc . , ) . It is assumed that the API library functions register on behalf of the applications the data models produced by the given application, so this mechanism remains totally transparent for the application and the application developer . Then, the API library functions of other nodes can interrogate the registry to get the location of any given data, when some applications on that node request access to that data . In addition, the registry may store mapping of different identities used in the system (e.g. , different node IDs mapped to each other or to IP addresses, etc . ) , which might be useful when implementing certain API services . In an actual implementation along an embodiment of the present invention, a suitable scenario would consider that there are already some central analytics services of an operator doing some analytics processing of the netwo k data . These services may already be running in a cloud environment implemented, in turn, by a data center type deployment . The scenario would exploit the provision by the embodiments of being capable to interact with and complement such central analytics services with the node distributed components .

Figures 8A to 8C sho schematic views of system architectures according to further embodiments of the present invention. Specifically, Figure 8A shows a schematic view of a first system architecture, where the central analytics data and services are made accessible for the network nodes via the same data access API (cf . as discussed in conjunction with the present disclosure) . Specifically, there is proposed a coexistence of the central analytics functions provided by means of the analytics cloud data center 30 on the one hand, and the local , distributed application spaces as provided by the network elements 10 , 10' . Naturally, there can be other type of physical deployments as shown, for example, in Figure 8B, where the deployment is without the central analytics cloud, and only includes the network nodes 10, 10' and the central registry 20. In another embodiment , the deployment may consider no capabilities in the network nodes but an analytics server deployed close to the network nodes and doing the analytics processing for a cluster of nodes . In this case the analytics server may use a stripped off configuration of the analytics cloud system {i.e. corresponding components thereof) . The somewhat simplest deployment is the embodiment shown in conjunction with Figure 8C, where the system may work without any inter-node data exchange based only on node local processing and communication, in which case even the central registry 20 may be omitted. Figure 9 shows a schematic view of a conventional deployment in the context of communication networks . Specifically, data elements of different kinds are held by individual network elements 910, 91 C , 910" as exemplary infrastructure resources and accessed by a central analytics function 920.

A further general embodiment of the present invention may also be defined in terms of systems and methods for maintaining and exchanging virtualized information data records in a distributed network of nodes in a telecommunication network, wherein the virtualized information data records hold different pieces of information elements, which information elements may be located in different network nodes , wherein different samples of the same virtualized information data record type may be located at different network nodes , wherein the physical location and accessibility information to a particular virtualized information data record is stored by a Registry function in the network, and wherein Access Service Interface functions in the network nodes provide a transparent access to the virtualized data records hiding the location of the virtualized information data records . In th s embodiment , the Registry function may store the reference to the physical location and access information of any virtualized information data records . Further, in this embodiment , the Access Service Interface function may interrogate the Registry function to obtain the physical location and access information to a particular virtualized information data records and establishes the physical connection to that physical location and fetches the requested information elements of the virtualized information data record. Yet further, in this embodiment , the virtualized information data record may be characterized by at least a unique name and any of the properties of access type, storage type, time resolution and addressable information elements . Although detailed embodiments have been described, these only serve to provide a better understanding of the invention defined by the independent claims , and are not to be seen as limiting .

Claims

Claims
1. An infrastructure resource of a communication network comprising processing and memory resources configured to provide an infrastructure functionality, wherein said resources are further configured to provide a data collection functionality for collecting data related to said infrastructure functiona1ity, and provide a data sharing functionality for sharing the collected data with another infrastructure resource of said communication network .
2. The infrastructure resource of claim 1, wherein said data sharing functionality comprises providing a part of a distributed data base, and wherein said data sharing functionality stores the collected data into said part of the distributed data base.
3. The infrastructure resource of claim 2 , wherein the collected data stored in said part differs from collected data stored in another part of the distributed data base in another infrastructure resource.
4. The infrastructure resource of any one of claims 1 to 3 , wherein the collected data is stored in the form of virtual information data records comprising a plurality of information elements, and wherein said data sharing functionality provides at least a part of said plurality of information elements .
5. The infrastructure resource of claims 4 , wherein said data sharing functionality retrieves a particular virtual information data record by enquiring to a registry function of said communication network.
6. The infrastructure resource of claim 4 or 5, wherein said data sharing functionality comprises an access service interface function providing access to a virtual information data record while hiding the storage location of said virtual information data record or the information elements thereof .
7. The infrastructure resource of any one of claims 1 to 4 , wherein said data sharing functionality retrieves shared collected data from another inf astructure resource by enquiring to a registry function of said communication network .
8. The infrastructure resource of any one of claims 1 to 7 , wherein said data sharing functionality comprises providing a stream to said other infrastructure resource, and wherein said stream comprises at least a part of the collected data .
9. The infrastructure resource of claim 8 , wherein said stream is a broadcast stream being provided to subscriber infrastructure resources .
10. The infrastructure resource of claim 8 or 9 , wherein said data sharing functionality comprises registering a subscriber infrastructure resource .
11. The infrastructure resource of any one of claims 1 to
10, being any one of a network element of the communication network, a base station of the communication network, and a gateway of the communication ne work .
12. A communication network comprising at least two infrastructure resources according to any one of claims 1 to 11 and a central registry entity configured to manage the data sharing functionalities of said infrastructure resources .
13. A method for operating an infrastructure resource of a communication network comprising processing and memory- resources, the method comprising: a step of providing an infrastructure functionality; a step of providing a data collection functionality for collecting data related to said infrastructure functionality, and a step of providing a data sharing functionality for sharing the collected data with another infrastructure resource of said communication network .
14. A computer program that comprises code, the code, when executed on processing resources , instructs the processing resources to perform a method of claim 13.
15. A computer program product that stores code, the code, when executed on processing resources , instructs the processing resources to perform a method of claim 13.
PCT/EP2015/069246 2015-08-21 2015-08-21 Network data sharing in communication networks WO2017032394A1 (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
PCT/EP2015/069246 WO2017032394A1 (en) 2015-08-21 2015-08-21 Network data sharing in communication networks

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/EP2015/069246 WO2017032394A1 (en) 2015-08-21 2015-08-21 Network data sharing in communication networks

Publications (1)

Publication Number Publication Date
WO2017032394A1 true true WO2017032394A1 (en) 2017-03-02

Family

ID=54065855

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2015/069246 WO2017032394A1 (en) 2015-08-21 2015-08-21 Network data sharing in communication networks

Country Status (1)

Country Link
WO (1) WO2017032394A1 (en)

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO1998022876A1 (en) * 1996-11-22 1998-05-28 Mangosoft Corporation System and method for providing highly available data storage using globally addressable memory
US20120271903A1 (en) * 2011-04-19 2012-10-25 Michael Luna Shared resource and virtual resource management in a networked environment

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO1998022876A1 (en) * 1996-11-22 1998-05-28 Mangosoft Corporation System and method for providing highly available data storage using globally addressable memory
US20120271903A1 (en) * 2011-04-19 2012-10-25 Michael Luna Shared resource and virtual resource management in a networked environment

Similar Documents

Publication Publication Date Title
US20150063166A1 (en) System and Method for Mobile Network Function Virtualization
US20060036747A1 (en) System and method for resource handling of SIP messaging
US20050267979A1 (en) Services layer model for providing standards-based communications
US8107409B2 (en) OAMP for distributed mobile architecture
US20130054763A1 (en) Methods and apparatus to configure virtual private mobile networks with virtual private networks
US20140126581A1 (en) Systems, methods and apparatus for managing machine-to-machine (m2m) entities
US5892916A (en) Network management system and method using a partial response table
US20060041581A1 (en) Method of discovering contact identifiers for network access devices
Taleb et al. EASE: EPC as a service to ease mobile core network deployment over cloud
US20120311614A1 (en) Architecture for pervasive software platform-based distributed knowledge network (dkn) and intelligent sensor network (isn)
US20050128958A1 (en) Protocol for wireless multi-hop ad-hoc networks
US6980534B1 (en) System and method for efficient selection of a packet data servicing node
JP2008129991A (en) Relay server and relay communication system
Bouabene et al. The autonomic network architecture (ANA)
US7451199B2 (en) Network attached storage SNMP single system image
Jararweh et al. SDIoT: a software defined based internet of things framework
US7966394B1 (en) Information model registry and brokering in virtualized environments
US8600726B1 (en) System and method for virtualization of networking system software via emulation
US20140233389A1 (en) Methods, systems, and computer readable media for providing a thinking diameter network architecture
US20140025800A1 (en) Systems and methods for multi-blade load balancing
Hakiri et al. Publish/subscribe-enabled software defined networking for efficient and scalable IoT communications
US20080299988A1 (en) System and method for establishing peer-to-peer bandwidth sharing ad hoc networks
US20140348068A1 (en) Multiplexing Core Networks in RAN Sharing
US20130013793A1 (en) Apparatuses and methods for handling machineto-machine communications
CN102946354A (en) Message forwarding method and device and network equipment thereof

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 15760400

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase in:

Ref country code: DE