TRANSMISSION Technical Field

The present invention relates to methods of analysing performance monitoring data to adapt a code for coding for transmission of the data, to methods of coding using the adapted code, to methods of decoding using the adapted code, to analysers for adapting the code, to coders and to decoders and to corresponding programs for such methods.

Background

It is known to provide Performance Management, PM, functions in a communications system, such as a mobile communications system, typically for monitoring, trouble shooting and optimisation of the communications system. The PM functions can be based on events and counters generated by various elements of the mobile communications system, such as radio access units or Base Stations, BS, radio network controllers, backhaul nodes, core network nodes and other system nodes and servers. Events are used to monitor and investigate the system operation. Relevant information of the operation of the system can be obtained from analysis of long term observation of the events data.

Counters can be used to obtain aggregate or statistical information of the system. Counters are typically implemented in the various network elements but can also be created from events and event parameters. Over the life time of the network there can be an increasing number of counters that are recorded in the network elements. Examples for the recording of events are the General Performance Event handler, GPEH, and User Equipment Traffic Recording, UETR, functions of system elements. In third generation, (3G), and Long Term Evolution, (LTE), mobile telecommunications systems for example, events data and counter values generated by a plurality of system elements may be collected by a common server or gateway instead of by the elements themselves. The events data and counter values may be forwarded directly, in real-time, to a management server or gateway, which is part of an Operating Support System, OSS. This can involve using a streaming application, for example, or the events and counters may also be collected in files for a set period of time, called the Result Output Period, ROP, before forwarding to the OSS. ROP files are retrieved periodically from the system elements and processed in the OSS. Both, real-time events data and counter values as well as ROP files may be available for processing by the OSS.

An OSS can implement several types of PM functions such as traffic monitoring, trouble-shooting, radio and transport network optimisation. From the processed events and counters, Key Performance Indicators, KPIs, can be derived for use for monitoring, trouble shooting and planning purposes. KPIs are used for high level monitoring and business planning functions. These functions are not necessarily part of the OSS. An OSS may also include applications for user defined counters to be created from events or event combinations, which can provide an extended observation possibility for telecommunications systems. Besides the above, the events data and counter values may be used by other applications as well.

LTE networks, for example, implement many auto-configuration functions and use default configurations which provide fast installation and stable operation in the initial phase of a systems setup. However, monitoring of the overall operation of the large number of network elements usually requires a centralized management system. Exceptional conditions and operations should be observed by a performance monitoring OSS. Performance monitoring tools and functions are also needed in order to optimise the operation of networks such as LTE networks. A problem of performance monitoring is the large numbers of counters to be monitored, such as in the case of LTE networks, nodes and cells, i.e. femto cells, that have to be monitored. These nodes, also called LTE eNodeB, generate larger numbers of events and counters that have to be processed compared to previous mobile Radio Access Network, RAN, systems, such as GSM RAN, for example. Scalability issues occur if the OSS has to communicate and collect events data and counter values directly for large numbers of system elements, such as the LTE eNodeBs. It is possible to use (intermediate) control nodes, for collecting and pre-processing PM data from the network elements in GSM and WCDMA RAN systems. The OSS capability to collect performance (PM) data from the subtended network elements reliably and promptly is a key feature to keep the network under monitoring allowing the operator to take required actions to always assure best network performances and preserve business service performance.

Typically PM data are first collected by the nodes, then compressed by the nodes (zip or tar) and finally moved into the OSS owned disk area via FTP. Sometime PM records are instead collected by OSS application via proper node MIB leaves collection. During an OSS based performance collection task scheduling, a key point for a Management System Operator is to identify the proper trade-off between the need to collect as much PM data as possible and the risk of overloading the OSS platform (e.g. disk space, cpu processing, etc.) or the communications resources of the DCN (e.g. DCN links bandwidth, GNE packets forwarding capabilities, etc.) used for collecting the PM data. The management system operators face the problem of how to properly set up the PM collection task taking into consideration how much this choice affects the overall management system behavior.

It is known from WO201 1069546 (A1 ) to aggregate counter values for a number of result output periods, i.e. for a second, third, fourth, etc. result output period, to provide scalability and adequate time based statistics for the counters. Events and counters that relate to short term problems are aggregated for a correspondingly short result output period and events and counters that relate to long term problems are aggregated for a correspondingly long result output period, for example to provide performance management information in accordance with the time scale relevant for the specific information. This can enable larger numbers of events data and counter values to be handled and analysed, such as the large quantity of performance management data generated in LTE, for example. This still leaves some problem with the amounts of PM data to be transmitted.

Summary

Embodiments of the invention provide improved methods and apparatus. According to a first aspect of the invention, there is provided a method of adapting a coder for coding of performance management data of a network element, for transmission, having a step of receiving performance management data relating to the network element over a past time period. There are also steps of analysing the received performance management data to make a prediction of which values of that performance management data are more likely to occur in a future period than other values, and modifying the coder according to the prediction to code the predicted values preferentially compared to the other values for the future period. This can enable the coder to be modified to code a relatively small set of the more likely values since typically only small proportion of the range of possible values occurs. So the coder can now code preferentially a smaller number of possible values. Thus it can achieve more efficient or more accurate coding for example.

Any additional features can be added, and some are described below and set out in dependent claims.

Another aspect provides a computer program having instructions that when executed by processing circuitry cause the processing circuitry to carry out the method. Another aspect provides a computer program product comprising a computer readable medium having stored on it the computer program.

Another aspect of the invention provides an analyser for adapting a coder for coding of performance management data of a network element, for transmission, the analyser having a processing circuit and a memory circuit, the memory circuit having instructions executable by the processing circuit. Said processing circuit when executing the instructions is configured to receive performance management data relating to the network element over a past time period, and analyse the received performance management data to make a prediction of which values of that performance management data are more likely to occur in a future period than other values. The processing circuit is also configured to modify the coder, according to the prediction, to code the predicted values preferentially compared to the other values for the future period.

Another aspect provides a coder for sending coded performance management data of a network element, the coder having a processing circuit and a memory circuit, the memory circuit having instructions executable by the processing circuit. Said processing circuit when executing the instructions is configured to modify how to code the performance management data, according to a prediction of which values of that performance management data are more likely to occur in a future period than other values. It is also configured to code values of the performance management data occurring in the future period, in the modified manner, such that the predicted values are coded preferentially compared to the other values, and send the coded values to a management system.

Another aspect of the invention provides a decoder for decoding received coded performance management data of a network element, the decoder having a processing circuit and a memory circuit, the memory circuit having instructions executable by the processing circuit. Said processing circuit when executing the instructions is configured to modify how to decode the received coded performance management data according to a prediction of which values of that performance management data are more likely to occur in a future period than other values. It is also configured to receive coded values of the performance management data, coded so that the predicted values are coded preferentially compared to the other values, and decode the received coded values of the performance management data, in the modified manner.

Another aspect of the invention provides a system comprising an analyser, and at least one of: a coder and a decoder.

Another aspect of the invention provides an analyser for adapting a coder for coding of performance management data of a network element, for transmission, the analyser having a receiver for receiving performance management data relating to the network element over a past time period, and an analysing module for analysing the received performance management data to make a prediction which values of that performance management data are more likely to occur in a future period than other values. The analyser also has a modifying module for modifying the coder according to the prediction to code the predicted values preferentially compared to the other values for the future period.

Another aspect provides a coder for sending coded performance management data of a network element, the coder having a modifying unit for modifying how to code the performance management data according to a prediction of which values of that performance management data are more likely to occur in a future period than other values. The coder also has a coding unit for coding values of the performance management data occurring during the future period in the modified manner, such that the predicted values are coded preferentially compared to the other values, and a sending unit for sending the coded values to a management system.

Another aspect provides a decoder for decoding received coded performance management data of a network element, the decoder having a modifying unit for modifying how to decode the received coded values of the performance management data according to a prediction of which values of that performance management data are more likely to occur in a future period than other values. The decoder also has a receiving unit for receiving coded values of the performance management data coded so that the predicted values are coded preferentially compared to the other values, and a decoding unit for decoding the received coded values of the performance management data in the modified manner.

Any of the additional features can be combined together and combined with any of the aspects. Other effects and consequences will be apparent to those skilled in the art, especially over compared to other prior art. Numerous variations and modifications can be made without departing from the claims of the present invention.

Brief Description of the Drawings: How the present invention may be put into effect will now be described by way of example with reference to the appended drawings, in which:

Figure 1 shows an overview of part of a network,

Figure 2 shows steps by an analyser according to an embodiment,

Figure 3 shows a time chart of steps by an analyser, a coder and a decoder, according to embodiments,

Figure 4 shows a time chart of steps according to another embodiment using an index,

Figure 5 shows a time chart of steps according to an embodiment showing feedback,

Figure 6 shows a time chart of steps according to an embodiment showing variable dependency,

Figure 7 shows a time chart of steps according to an embodiment showing a similarity threshold,

Figure 8 shows a time chart of steps according to an embodiment showing setting size,

Figure 9 shows a time chart of steps according to an embodiment showing sending uncoded values,

Figure 10 shows an apparatus example with NMS having scheduler and adaptation layers,

Figure 1 1 shows a time chart for an example using an NMS having scheduler and adaptation layers,

Figure 12 shows a schematic view of a radio access network, to which embodiments can be applied,

Figure 13 shows a schematic view of a PM data analyser having processing circuitry, according to an embodiment,

Figure 14 shows a schematic view of a coder having processing circuitry, according to an embodiment,

Figure 15 shows a schematic view of a decoder having processing circuitry, according to an embodiment, and

Figures 16- 18 show schematic views of modular apparatus for a data analyser, coder and decoder, respectively according to embodiments. Detailed Description:

The present invention will be described with respect to particular embodiments and with reference to certain drawings but the scope of the invention is not limited thereto. The drawings described are only schematic and are non-limiting. In the drawings, the size of some of the elements may be exaggerated and not drawn to scale for illustrative purposes.

Definitions:

Where the term "comprising" is used in the present description and claims, it does not exclude other elements or steps and should not be interpreted as being restricted to the means listed thereafter. Where an indefinite or definite article is used when referring to a singular noun e.g. "a" or "an", "the", this includes a plural of that noun unless something else is specifically stated.

References to software can encompass any type of programs in any language executable directly or indirectly on processing hardware.

References to processors, hardware, processing hardware or circuitry can encompass any kind of logic or analog circuitry, integrated to any degree, and not limited to general purpose processors, digital signal processors, ASICs, FPGAs, discrete components or logic and so on. References to a processor are intended to encompass implementations using multiple processors which may be integrated together, or co-located in the same node or distributed at different locations for example.

References to a coder are intended to encompass any type of coder, for example one which uses an index such as a look up table, and/or uses an algorithm for generating the coded values from the actual PM data values. The coder can be implemented using any kind of circuitry and/or software.

References to coding are intended to encompass any type of coding which can improve a transmission performance, for example coding for data compression, or for error detection or error correction or for security for example.

References to modifying a coder or decoder can encompass any way of modifying, including for example altering an index such as a look up table, or altering factors or parameters used by an algorithm. References to coding preferentially are intended to encompass for example coding only the predicted values and leaving other values to be transmitted uncoded or not transmitted, or allocating a disproportionately large number of possible coded values for coding the predicted values and a disproportionately smaller number of possible coded values for coding some or all of the other values, for example, or for example if the coded values can have different lengths, providing the shorter length coded values for coding the predicted values, and so on.

References to performance management data are intended to encompass any kind of data produced by a network element which could be used by a network management system, for example values taken at a given time from counters recording information such as traffic quantities, operating temperatures, buffer levels, laser parameters, component status, power consumption and so on. References to network element are intended to encompass any kind of network element at any level in a communications network.

Abbreviations:

ASIC Application Specific Integrated Circuit

BSC Base Station Controller

BTS Base Transceiver Station

CPU Central Processing Unit

DCN Data Communication Network

FPGA Field Programmable Gate Array

FTP File Transfer Protocol

GGSN Gateway GPRS Support Node

GNE Gateway Network Element

GPRS General Packet Radio Service

GSM Global System for Mobile communications

ITU-T International Telecommunications Union -Telecommunications

LTE Long Term Evolution

MME Mobility Management Entity

NE Network Element

NMS Network Management System OSS Operational Support System

OTN Optical Transmission Network

PDN Packet Data Network

PM Performance Management

RAN Radio Access Network

RBS Radio Base Station

RNC Radio Network Controller

SCTP Stream Control Transmission Protocol

SGSN Serving GPRS Support Node

SGW Serving Gateway

TCP Transmission Control Protocol

UDP User Datagram Protocol

UMTS Universal Mobile Telecommunications System Introduction to issues addressed

By way of introduction to the embodiments, some issues with conventional designs will be explained. Regarding the overall size of collected performance data, this typically depends on these parameters:

1 The number of NEs

2 The number of resources on each NE which are monitored

3 The granularity of collection of the historical counters (i.e. how often the PM counters are retrieved)

4 The number of counters which can be collected for a specific resource

5 The granularity of the PM counters itself (how many bytes for each counter)

Typically the first four of these five parameters are dominant. As a result, the size of the OSS PM collection task is then kept manageable by using a limited set of counters, on a limited set of nodes, with a pre-defined periodicity. The fifth parameter, the granularity of the PM counters itself (how many bytes for each counter), is usually considered as an input information to the process evaluating the PM collection task footprint from a storage, processing and network utilization perspective. Often this PM collection task footprint evaluation process implies as a result some limited configurability options that affect the OSS system capability to monitor from a performance perspective the overall network behavior. In such cases where an overall view of actual network performances matters more than details collection of resource PM counters, the possibility to act on PM counters granularity (e.g. moving their size from a number of bytes to few bits per counter) would definitely help to reduce the overall PM collection task footprint, allowing the OSS System to monitor from a performance perspective a notably larger network portion.

Introduction to features of embodiments

The embodiments described include apparatus and methods have in most cases a useful consequence of improving transmission of PM data by adaptively coding (e.g. compressing) performance data in a communications network. As will be explained, this is based on realizing that some intrinsic features of the PM data can be exploited, to enable the network elements to adaptively code the PM data so as to provide, in normal operative conditions a better transmission, (e.g. higher compression ratio) than existing methods which take no account of the characteristics of the PM data. For example, a data analyser can learn from the network which is the set of values that each counter type usually assumes; if significant differences exist, different sets can be available according to the time of the day, the day in the week, particular operative conditions (e.g. maintenance) and others.

This learned information relating to predicted values of the PM data, can be used in adapting a code sent to the network elements (NE); as a NE collects the value of a counter for a given interval, it can code the new PM data for example by checking which one of the typical values fits the counter with the minimum error. It can then for example send coded values to the management system such as a bit code (e.g. 3 bits if the number of predicted values is up to 8) instead of the full length value without coding. If none of the typical values ensure an error less than a given threshold, the full length uncoded value can be sent to the management system (NMS), or it can be coded in some other way, or can remain untransmitted. Hence the relatively small range of coded values is used preferentially for coding the predicted values. Thus an improvement in compression ratio or other transmission benefit can be obtained by coding the counters value into a set of typical values known on both NMS and NEs, so just a relatively short bit code has to be sent to the management system.

Some characteristics of the PM data which can be taken into account by the analyser in a phase of learning are:

- usual values assumed by PM counters; and

- recursive patterns of variation of these values.

Some benefits of some examples of the coding (e.g. compression) are:

- potentially improved error ratio in representing a small number of predicted values (compared to a conventional compression in which the error is typically inversely proportional to the desired compression ratio);

- potentially error free for the exceptional "less likely" values, e.g. those exceeding the normal values by a certain threshold (highlighting typically a critical condition);

- ability to "learn" recursive (repeating) patterns of variation of the PM counters values over past time periods for use in predicting the most likely current values; and

- ability to automatically adapt the coding to changes in the communications network configuration and operative conditions which might affect these predictions.

Notable also is the adaptability of the coding to provide a PM data coding (e.g. compression) algorithm which can be adaptively configured so as to optimize its compression (or other transmission capability) depending on the network behaviour basing on a learning procedure. Notable also is the application of this adaptive coding to the context of the PM data compression, and the node information model objects which can implement it.

Figure 1 , architectural overview of entities involved in embodiments Figure 1 shows a schematic overview of entities involved in embodiments. A number of Network Elements 60 are shown which are each a source of PM data values. A coder 20 is provided for each Network Element NE (or possibly a group of NEs) to code the PM data values for transmission to a management system 40, where they are decoded by a decoder 30. The coder 20 is adaptable in the sense of modifying how it does the coding of the PM data. A data analyser 10, is provided for adapting the coders on the basis of past PM data values. These past PM data values can be provided by the management system, or from elsewhere such as from the network elements themselves. Each network element may have its coder adapted individually on the basis of its own past PM data values, or the same coder can in principle be shared by number of similar network elements. The same modification or at least a corresponding modification can be made to the respective decoder, corresponding to whatever adapted coder was used to generate the respective coded values. Again each NE may have a dedicated decoder at the management system or a single decoder can be timeshared to decode PM data values from many NEs. The decoder can be dedicated individually for each NE or can in principle be shared by number of similar NEs, if such sharing was carried out at the coder. It is usually convenient to locate the PM data analyser at or near the management system, or in some convenient central location, though in principle it can be located anywhere, and can be distributed either completely or partly. Thus part or all could be located at the NEs, or located at the coders and/or decoders for example. As described, figure 1 shows an example of a system comprising an analyser operable as will be described below in relation to various embodiments, and at least one of: a coder and a decoder as will be described below in relation to various embodiments.

Figure 2, method according to an embodiment

Figure 2 shows steps of a method of analysing data to adapt the code, by a data analyser 10 as shown in figure 1 . The code can be for coding of performance management data of a network element 60, for transmission. The method has steps of receiving 70 performance management data relating to the network element over a past time period, and analysing 75 the received performance management data to predict which values of that performance management data are more likely to occur in a future period than other values. At step 80 the coder is modified according to the prediction so that the predicted values will be coded preferentially compared to the other values. Optionally this can involve sending an indication of how to modify the adaptable coder to the coder and decoder, if they are located away from the data analyser.

An advantage of a modifiable coder based on predicting is that it enables a relatively small set of the more likely values to be identified since typically only small proportion of the range of possible values occurs. So the coder can now code preferentially a smaller number of possible values. Thus it can achieve more efficient or more accurate coding for example, and thus the data can be transmitted more efficiently with relatively few bits and thus with a better compression ratio, or transmitted with more error correction information or more security or other coding characteristic related to improved transmission, for example. In turn this can enable more network scaling or less overload of transmission resources for the performance management data. Furthermore, this coding based on predicted values need not be an alternative to conventional data compression for transmission, but can complement such conventional compression.

The steps of analysing as set out above can be carried out at any location in the network in principle, for example a centralised data analyser can be provided, or they can be carried out remotely on servers in the so called cloud. This can make it easier to manage and maintain the data analysis parts, especially for a large network. The steps can be carried out in a partially or completely distributed fashion, for example some or all of the steps can be carried out at each network element, though this may become harder to manage for large networks.

Figure 3, time chart of actions of embodiments of analyser, coder and decoder Figure 3 shows a time chart of actions of embodiments. Time flows down the chart, and a left hand column shows actions of a PM data analyser 10, a central column shows actions of a coder 20 at a network element or elsewhere, and a right hand column shows actions of a decoder 30 at a management system for example. The actions of the analyser 10 are similar to the steps shown in figure 2. Performance management PM data relating to the network element over a past time period is received and analysed to make a prediction of which values of that performance management data are more likely to occur in a future period than other values. Then there is a step of modifying how the coder codes according to the prediction so that the predicted values will be coded preferentially compared to the other values. Optionally this can involve sending an instruction of how to modify the adaptable coder to the coder and decoder, if they are located away from the data analyser, for example. Or it can involve modifying more directly by altering an index used by the coder or decoder for example.

The actions of the coder 20 include receiving the modification of how to code, for example as an instruction, or as a direct modification of an index for example, then coding values of PM data of the future period according to that modification, so that the predicted values are coded preferentially compared to other values. The values to be sent can be live values being sent immediately they are recorded or sensed, or they can be values are effectively "off-line", and are stored before sending, either to form batches for more efficient sending and processing or to avoid sending during busy times, or for any other reason. Once coded the coded values can be sent to the management system. This sending can involve further coding such as compression, following conventional practice.

The actions of the decoder 30 can include receiving the modification of how to decode, for example as an instruction, or as a direct modification of an index for example, then receiving and decoding the coded values of PM data of the future period in the modified manner. The decoded values can then be used by the management system and further processed or stored as desired. This figure is an illustration of an example of further steps of using the coder as modified to code values of performance management data occurring in the future period, such that the predicted values are coded preferentially, and of sending the coded values to a management system. It also illustrates an example of further steps of modifying how to decode received coded performance management data of a network element 60, and receiving coded values of the performance management data, coded so that the predicted values are coded preferentially compared to the other values, and decoding the received coded values of the performance management data in the modified manner. Figure 4, time chart of actions of embodiments featuring patterns and an index Figure 4 shows a time chart similar to that of figure 3 and reference is made to the description of figure 3. In this embodiment, the prediction is made by the data analyser by detecting repeated patterns in the past PM data to enable predictions for the future time period. By determining a repeating pattern of occurrence and making the prediction accordingly, the prediction may be more accurate than one based on a single previous pattern and so better coding, such as better compression ratios, can be achieved.

The step of modifying the coder by the data analyser is carried out by modifying an index used by the coder. Such an index is a convenient way of coding, by associating those predicted values of the performance data, with corresponding coded values, and can be implemented for example by a look up table. An advantage of an index is ease of coding and decoding and ease of modifying, compared to for example an algorithm for coding.

Figure 5, time chart of actions of embodiments featuring feedback and adaptation of predictions

Figure 5 shows a time chart similar to that of figure 3 and reference is made to the description of figure 3. In this embodiment, the step of analysing by the PM data analyser further comprises receiving feedback relating to prediction errors occurring in the future period, and adapting the prediction according to the feedback. An advantage of such feedback is it can enable automated improvement of the prediction and therefore improvement of the coding and decoding, with use. One way of adapting the prediction according to the feedback is to analyse whether any of the other values that are not predicted, are occurring in the future period more frequently than any of the predicted values, and if so, adapting the prediction to include such other less likely values. This is a convenient way of adapting the coding and thus the compression ratio if the prediction is not sufficiently accurate. Other ways of adapting the prediction can be envisaged. The feedback can be sent from the coder or the decoder for example, and can be any type of representation of prediction errors. For example it can be indications of which less likely values are occurring, and their frequencies, or it could be every less likely value, or just those less likely values which are occurring more frequently than any of the predicted values, and so on.

Figure 6, time chart of actions of embodiments featuring dependency on a variable

Figure 6 shows a time chart similar to that of figure 3 and reference is made to the description of figure 3. In this embodiment, the analysing step can involve analysing dependence of the performance management data on at least one of the following variables: time of occurrence, conditions of network traffic, configuration of network and current status of network elements. These are some variables which can have an effect on the prediction and thus on the coding. Then the step of modifying how the coder codes can involve modifying the coder according to the dependence. An advantage is that it can enable the coding to be more adaptable to different variables, and so improve the coding such as improving a compression ratio. The dependence can be implemented in many different ways, for example as additional parameters in an algorithm, or as additional entries in an index, effectively making the index multi dimensional or have multiple pages, each for a different current state of the respective variable.

The actions of the coder now involve coding according to the modification so that the predicted values are coded preferentially, and according to a current state of the variable. So if the coding is done by a modifiable look up table, the coder will add the current state of the variable as an input to the look up table, and thus the coded value output by the look up table will now be dependent on the current state of that variable. Similarly at the decoder, if the decoding is done by a modifiable look up table, the decoder will add the current state of the variable as an input to the look up table, and thus the decoded value output by the look up table will now be dependent on the current state of that variable.

Figure 7, time chart of actions of embodiments featuring same coding for multiple predicted values, and use of a similarity threshold

Figure 7 shows a time chart similar to that of figure 3 and reference is made to the description of figure 3. In this embodiment, the modifying step by the analyser 10 comprises modifying the coder 20 to code more than one of the predicted values to the same coded value. This has an advantage of avoiding a need for a one to one association of predicted values and coded values and thus enabling a range or set of actual values to be coded by each coded value. This implies a loss of accuracy in the transmission but a gain in compression, therefore, this enables a trade-off between compression ratio and accuracy. Also shown in this figure is the feature of the modifying step of the analyser 10 comprising setting a similarity threshold for use by the coder 20 to determine whether a value to be coded is close enough to a predicted value to be coded as if it were that predicted value. An advantage of this is that it enables the coding to be more adaptable to trade-off compression ratio with accuracy of coding as desired. The coder receives the specified similarity threshold and when coding a value to be sent, it can determine which predicted value is the closest, and if it meets the specified similarity threshold, it is coded as if it were the predicted value. Since the coder can determine which of the predicted values is closest to the value to be coded, and determine a coded value corresponding to that closest one, this can have an advantage of avoiding a need for a one to one association of predicted values and coded values and thus enabling a range of actual values to be coded by each coded value. This implies a loss of accuracy in the transmission but a gain in compression; therefore, this enables a trade-off between compression ratio and accuracy. At the decoder, the coded values are received, and decoded as if they were the corresponding predicted values. Thus there is no way to decode the value exactly back to its original value, but the similarity threshold enables the size of error to be limited as desired.

Figure 8, time chart of actions of embodiments featuring limiting a size of coded values

Figure 8 shows a time chart similar to that of figure 3 and reference is made to the description of figure 3. In this embodiment, there is a step by the analyser 10 of setting a size of coded values to be generated by the coder 20. As the size governs how many different coded values can be generated, and thus how much precision the predicted values can have, and also governs how much compression can be achieved, setting or limiting this size can enable a trade-off between compression ratio and precision to be controlled. At the coder, the specified size is received from the analyser 10, and the coding is carried out according to the size. The size can be specified in any way, for example as a number of bits or as an upper limit on the number of bits, or as a conditional specification, with different values for different conditions, such as how congested the network is or what time of day it is for example. Similarly at the decoder the specified size can be received from the analyser 10, (or from the coder for example) and the coding can be carried out according to the size. The size can be specified for each value or for a group of values or for a period for example. Figure 9, time chart of actions of embodiments featuring sending less likely values without using the coding

Figure 9 shows a time chart similar to that of figure 3 and reference is made to the description of figure 3. In this embodiment, the analyser 10 has a step of modifying how the coder codes, so as not to code other less likely values. The coder has a step of coding by determining whether the value to be coded is one of the less likely other values, by comparing the value to be coded to the closest of the predicted values according to a similarity threshold. If so, the step of sending comprising sending the less likely other value without coding it in the manner of the predicted values. This can have an advantage of enabling all the possible coded values to be used for the predicted values, thus enabling more accurate or more efficient transmission of the predicted values. Correspondingly at the decoder, there is a step of decoding by accepting these other less likely values as decoded values.

Another feature which is shown is the coder sending an indication that the value sent has not been coded in the manner of the coding of the predicted values. An advantage of sending this indication is to enable easier or more reliable decoding. At the decoder the indication is recognised, and values received and associated with the indication, are accepted as decoded values without applying the decoding process.

Fig 10 shows apparatus example with NMS having scheduler and adaptation layers

Figure 10 shows a schematic view of a system according to an embodiment. There is a management system in the form of a network management system NMS 42. The NMS typically has a number of components, some of which are shown. Typically it has a vendor specific OSS Network Element Management application usually deployed to allow the FCAPS (Fault, Configuration, Accounting, Performance, Security) functionalities on a Transport Network. As shown there is an analyser 10 in the form of a PM data analyser, and adaptation layers 15 which mediate the information of the PM data analyser to the different protocols available to be able to communicate with different network elements. The PM data analyser can be implemented as a software module running on the NMS which calculates and keeps up-to-date the predicted values by learning. The NMS can also include a PM scheduler 13. As shown at least one of the adaptation layers (A) has a decoder 30 in the form of a PM data decoder such as a decompressor.

At the network element 60 there is shown a coder in the form of a PM data coder such as a compressor. The PM data coder can be implemented as a software module running on the network element able to apply the compression algorithm to the PM data. There is also a PM data collector 23 for providing the PM data to be sent to the management system.

An NMS can implement the data collection in any way, for example in a way in accordance with specific standard bodies and the behavior of the managed network elements. One way is that the PM data are sent to the NMS from the NEs whenever there is a request (e.g. every 15 minutes), by using a main management protocol (e.g. NETCONF, SNMP). Alternatively, the PM data can be collected in a file which is sent separately (e.g. by SFTP) over a longer period of time (e.g. every day). Embodiments can use either way of data collection or other ways.

The PM data analyser can process the past PM data and make predictions in the form of predicted values sets for example. The PM data analyser can implement an algorithm which is able to capture and elaborate for example: usual values assumed by PM counters, and recursive patterns of variation of these values. The analyser defines for each counter type a predicted values set, which contains the values which most likely will fit the real counter values for a future period. As the predicted values of the counters can be time variant, different sets can be applied to the same counter type according to the specific time interval. Thus the prediction can be made dependent on this variable. In this context the prediction can be made adaptable by using feedback of prediction errors. This can be implemented by feeding back how many counters deviated from the predicted values and apply an algorithm to modify (if needed) the prediction by adapting the predicted value set.

Different predicted values sets can be provided, for different states of variables such as:

- date and time (e.g. hour in the day, day in the week, holiday periods)

- operative conditions:

o particular patterns occurring e.g. when some network elements go to maintenance

o PM values which maintains for a period of time a value different than the expected one due to persistent faults, misconfigurations and so on The PM data analyser can decide the strategy of application of the different predicted value sets and their distribution to coders at the network elements and which of them to use in a period of time (e.g. for the time intervals occurring during the night). Whilst in the date and time use cases the distribution is simply triggered by the date and time itself, for any other use case the PM data analyser itself can be able to recognize the condition and make the decision to distribute the corresponding counters set to the NEs at the right moment.

The following the parameters can be used to influence the decision on which / how many predicted values are suitable for a specific counter type for example: - a similarity threshold representing the maximum accepted deviation between real and learned values. This can come from a trade-off between compression ratio and need to have precise PM data counters. This similarity threshold parameter can be configurable by the operator.

- typical variance of the counter values: this influences the number of bits used for coding the predicted values; e.g. if a specific counter type has a typical value which rarely changes, a 1 -bit representation in the algorithm could be acceptable, providing a higher compression ratio.

Figure 1 1 , time chart of embodiment for NMS having scheduler and adaptation layers

Figure 1 1 shows a time chart of actions of various parts shown in figure 10, according to embodiments. Time flows down the chart. A left hand column shows actions of a PM data analyser 10, a next column to the right shows actions of a PM scheduler 13, and a third column to the right shows actions of an adaptation layer 15 at the NMS. A fourth column to the right shows actions of a PM data collector 23 at the NE, and a fifth column to the right shows actions of a PM data coder 20. A starting action is the PM data analyser 10 analysing past PM data to set learned (predicted) values and a similarity threshold (referred to as an error threshold). This is sent to the PM scheduler by a procedure call internal to the NMS, sent on by another procedure call to the adaptation layer 15 of the NMS and sent out to the PM data coder 20 of the NE by a specific NE message API. Next the scheduler sends a request for a PM collection, by an internal procedure call to the adaptation layer then on to the PM data collector 23 by a specific NE message API.

The data collector responds to this request by collecting PM data for the requested measuring point or counter, and type and time period. The requested PM data values are sent from the collector 23 to the PM data coder 20 for compression. The compressed data values are sent back to the data collector and either sent on or stored (shown as option (1 )). If sent on, (shown as option (2)), they are sent on to the adaptation layer 15 of the NMS, by a specific NE message API. The adaptation layer passes the coded data on to the PM scheduler 13 and from there to the PM data analyser 10 by internal procedural calls. Note that option (1 ) stands for PM data saved by the node on a file, periodically loaded by the NMS; and option (2) stands for PM data sent to NMS interval by interval through the main communication protocol.

In relation to remote network monitoring, reference is made to RFC 2819 Remote Network Monitoring Management Information Base. For ways of managing a network, reference is made to ITU-T M.3010 Principles for a telecommunications management network. As one typical way of implementing communications between NEs and a management system, reference is made to G.7712, ITU-T Architecture and Specification of Data Communication Network.

Example of a node information model object

The modifications to the coding by the coder can be communicated from the PM data analyser by having the analyser adapt a node information model, and have the coder access the model to implement the coding. This model can be implemented as a new object: the PM data analyser can specify a predicted value set for all the counter types; this object can be accessed by the coder for applying the coding (compression) algorithm. An example of a possible definition of the object is as follows (in which predicted values are referred to as learned values): learnedPMvaluesTable OBJECT-TYPE SYNTAX SEQUENCE OF learnedPMvaluesEntry MAX-ACCESS not-accessible

STATUS current

DESCRIPTION

"A list of learnedPMvaluesentries."

::= { learnedPMvalues 1 } learnedPMvaluesEntry OBJECT-TYPE

SYNTAX learnedPMvaluesEntry

MAX-ACCESS not-accessible

STATUS current

DESCRIPTION

INDEX { learnedPMvalueslndex }

::= { learnedPMvalues 1 } learnedPMvaluesEntry::= SEQUENCE { learnedPMvalueslndex Integer32,

learnedPMvaluesCounterType String,

learnedPMvaluesBits INTEGER,

learnedPMvaluesError Float,

learnedPMvaluesList OBJECT IDENTIFIER

} learnedPMvalueslndex OBJECT-TYPE

SYNTAX Integer32 (1 ..65535)

MAX-ACCESS read-only

STATUS current

DESCRIPTION

"The value of this object uniquely identifies this learnedPMvalues entry."

::= { learnedPMvaluesEntry 1 } learnedPMvaluesCounterType OBJECT-TYPE

SYNTAX String

MAX-ACCESS read-only

STATUS current

DESCRIPTION

"The value of this object identifies a counter type as defined by the network element model."

::= { learned PMvaluesEntry 2 } learnedPMvaluesBits OBJECT-TYPE

SYNTAX INTEGER {

One bit(1 ),

Two bits(2),

Three bits(3)

} MAX-ACCESS read-only

STATUS current

DESCRIPTION

"The value of this object identifies how many bits are used for indexing the learned value list."

::= { learnedPMvaluesEntry 3 }

learnedPMvaluesError OBJECT-TYPE

SYNTAX Float

MAX-ACCESS read-only

STATUS current

DESCRIPTION

"The value of this object identifies threshold representing the maximum accepted deviation between real and expected values "

::= { learnedPMvaluesEntry 4 } learnedPMvaluesList OBJECT-TYPE

SYNTAX SEQUENCE of COUNTER64

MAX-ACCESS read-only

STATUS current

DESCRIPTION

"This object lists the element of the learned values set"

::= { learnedPMvaluesEntry 5 } Example of compression algorithm and coding format

Let's assume:

NLV = number of learned (predicted) values

N=number of bits used to represent the learned (predicted) values (N=log ₂ NLV bits)

M=number of bits used by the NE data collector to represent the counter

CVi (T) = PM data value to be coded, relating to the i-th counter at interval T as calculated by the NE

LV (T) = list of the predicted values for the i-th counter available for the time range which interval T belongs to, as predicted by the analyser: e.g. assuming N=3, j can assume values in the range 0-7

The coder calculates the j satisfying the following condition:

Min I LVj _j (T) - C (T) | and | LV ₉ (T) - C (Τ) \ < ε (1 )

Where ε is a similarity threshold representing the maximum accepted deviation between real and predicted values

- if (1 ) is true, j is sent as the coded value to the decoder at the NMS

- if (1 ) is false, CV, (T) is sent as the value to the decoder at the NMS

The values can be sent using the following coding format for example. The Control Bit is an example of an indication of that a value associated with the indication, has been sent uncoded. The control bit informs the decoder at the NMS whether the reported data is an index of the chosen predicted value (set to 1 ) or a full uncoded value representation (set to 0). These following diagrams show examples of the format of what is transmitted between the coder and decoder. Other examples can be envisaged.

For the values matching condition (1 ):

For the values not matching condition (1 ):

Examples with N=3 and M=64:

For the data values matching condition (1 ):

For the data values not matching condition (1 ):

An evaluation of the compression ratio (CR) of data values for an example using a single counter on a daily collection of 96 intervals of 15 minutes, if S = number of values (= number of intervals) successfully coded into corresponding coded values is as follows:

CR = 96 M /[ S (N+1 ) + (96-S) (M+1 ) ]

The compression ratio depends on the reliability of the predictions. Some examples will now be evaluated.

Example 1: for counters having typically a single value in normal operative conditions let's assume N=1 , M=64, 100% of the values matched the predicted values (at least within threshold ε) in a day (96 values of the 15 mins interval) Compression ratio = 32

Example 2: for counters where 8 predicted values are used, let's assume N=3, M=64, 100% of the values matched the predicted values

Compression ratio = 16

Example 3: assuming N=3, M=64, only 80 out of 96 matched the predicted values due to a temporary problem:

Compression ratio = ~ 4,5

Example 4: assuming N=3, M=64, none of the 96 matched the predicted values: Compression ratio = ~ 0,98

Note the compression ratio of the proposed compression algorithm is not strictly comparable with any other data semantics agnostic compression algorithms commonly applied (e.g. zipping the PM data file); in fact, the same general purpose algorithms can be in turn applied to the outcome of the proposed one, providing an even higher overall compression.

Figure 12, network view for example of a radio access network

Figure 12 shows a schematic view of an example of a known wireless communications system 1 15, 129, 139, 149 in relation to which embodiments can be applied. The wireless communications system may be of the type based on GSM, UMTS and/or LTE, and is exemplified as comprising a core network 139 and a RAN 129 interconnected with the core network 139. A base station 131 is shown comprised in the RAN 129, serving a cell 1 15, and is configured for wireless communication with one or more wireless devices, such as a wireless terminal 120 shown in the figure. The base station 131 is an example of a network node comprised in the RAN 129. An example of a network node in the wireless communications system is a first network node 132 comprised in the RAN 129, as shown in the figure. In case of a GSM based wireless communications system, the first network node 132 may correspond to a BSC, and in case of a UMTS based wireless communications system 100, the first network 132 node may correspond to a RNC. In case of a LTE based wireless communications system, there may be no first network node 132 in the RAN 129 since the base station 131 in the RAN 129, i.e. an eNB in LTE, may communicate directly with a second network node, e.g. a MME or Serving Gateway (SGW), in the core network 139.

Further examples of network nodes are the second network node 141 and a third network node 142 comprised in the core network 139. In case of a GSM or UMTS based wireless communications system, the second network node 141 may correspond to a Serving GPRS Support Node (SGSN) and the third network node 142 may correspond to a Gateway GPRS Support Node (GGSN). In case of a LTE based wireless communications system, the second network node 141 may correspond to a Serving Gateway (SGW) and the third network node 142 may correspond to a Packet Data Network (PDN) Gateway. The third network node 142 may thus function as a gateway node for communication to and/or from an external network 172, e.g. the Internet, which external network may comprise one or many data sources 171 from and/or to which data may be communicated and transported via a data path to and/or from the base station 131 for further communication to and/or from one or more wireless devices, e.g. the wireless device 120.

The wireless communications system also comprises a transport network 149 relating to infrastructure suitable for transportation of data. Data transport in the transport network 149 is typically accomplished by means of general standards and protocols for data transport, such as one or more of the following: Internet Protocol (IP), Ethernet, User Datagram Protocol (UDP), Transmission Control Protocol (TCP), Stream Control Transmission Protocol (SCTP). Data communication to and/or from each radio network element 132, 153, e.g. as a result from data communication via the data path 157, involves data transport in the transport network 149. In general, a radio network element such as any one of the radio network elements 132, 153, provides functionality specific for the radio network, besides transport functionality for the transport network 149, and may e.g. correspond to or be comprised in any one of the following network nodes:

An RBS, that may be a Multi-Standard (MS) RBS, and depending on standard involved and terminology used may be named e.g. BTS, NodeB, eNodeB etc. A BSC, e.g. when the wireless communications system is based on GSM. The BSC being an example of a radio control and user plane entity. An RNC, e.g. when the wireless communications system is based on WCDMA. The RNC being an example of a radio control and user plane entity. A Mobility Management Entity (MME), e.g. when the wireless communications system is based on LTE. The MME being an example of a radio control plane entity. A gateway (GW), e.g. a session or packet gateway, such as SGW or PDN gateway, e.g. when the wireless communications system is based on LTE. The GW being an example of a radio user plane entity. There may be many network elements of the transport network 149. A first transport network element 153 and a second transport network element 132 are shown as examples in Figure 12 and may correspond to e.g. an Ethernet IP hub, switch, router, firewall etc., just to mention some examples.

The wireless communications system further comprises a management system NMS 42, that supports operation and maintenance of the wireless communications system and is typically controllable by and provides managing functionality to an operator of the wireless communications system. The management system 42 may correspond to a single entity, i.e. may correspond to a management device, or may correspond to physically separated but interconnected parts. The management system 42 can have a PM data analyser and is configured to communicate with the network elements 131 , 132, 153, 154, 141 , 142, each of which may have coders as described above for sending PM data to the NMS, using the prediction made by the PM data analyser. Figure 13, embodiment of a data analyser having processing circuit

Figure 13 shows a schematic view of a data analyser 10 for adapting a coder 20 for coding of performance management data of a network element 60, for transmission. The analyser has a processing circuit 180 and a memory circuit 185, the memory circuit having instructions 188 executable by the processing circuit, wherein said processing circuit when executing the instructions is configured to operate as shown in any of figures 2 to 9 for example. That is, to receive 70 performance management data relating to the network element over a past time period, analyse 75 the received performance management data to make a prediction of which values of that performance management data are more likely to occur in a future period than other values, and to modify 80 the coder, according to the prediction, to code the predicted values preferentially compared to the other values for the future period. This can be implemented in various ways as described above and can provide advantages as described above, and can have any additional features.

For example the processing circuit can also be configured to analyse by determining a repeating pattern of occurrence and making the prediction according to the repeating pattern. It can be configured to modify the coder by modifying an index associating those predicted values of the performance data, with corresponding coded values. It can be configured to analyse by receiving feedback from a coder relating to prediction errors occurring in the future period, and to adapt the prediction according to the feedback. It can be configured to adapt the prediction according to the feedback by analysing whether any of the other values that are not predicted, are occurring in the future period more frequently than any of the predicted values, and if so, adapt the prediction to include such other less likely values.

It can be configured to analyse by analysing dependence of the performance management data on at least one of the following variables: time of occurrence, conditions of network traffic, configuration of network and current status of network elements; and the processing circuit is also configured to modify the coder according to the dependence. It can be configured to modify the coder to code more than one of the predicted values to the same coded value. It can be configured to set a similarity threshold for use by the coder 20 to determine whether a value to be coded is close enough to a predicted value to be coded as if it were that predicted value. It can be configured to set a size of coded values to be generated by the coder.

This figure shows an example of a computer program 188 having instructions that when executed by processing circuitry cause the processing circuitry to carry out the methods as set out above. The memory circuit 185 is an example of a computer program product comprising a computer readable medium 185 having stored on it the computer program.

Figure 14, embodiment of a coder having processing circuit

Figure 14 shows a schematic view of a coder 20 according to an embodiment, for sending coded performance management data of a network element 60, the coder having a processing circuit 220 and a memory circuit 230, the memory circuit having instructions 225 executable by the processing circuit. The processing circuit when executing the instructions is configured to modify how to code the performance management data, according to a prediction of which values of that performance management data are more likely to occur in a future period than other values, to code values of the performance management data occurring in the future period, in the modified manner, such that the predicted values are coded preferentially compared to the other values, and to send the coded values to a management system 40, 42. This can be implemented in various ways as described above and can provide advantages as described above, and can have any additional features.

For example the coder can being located at the network element and the processing circuit be configured to receive from an analyser at a different location, an indication of how to modify the coding according to the prediction. It can be configured to determine which of the predicted values is closest to the value to be coded, and to determine a coded value corresponding to that closest one of the predicted values. It can be configured to determine whether the value to be coded is one of the less likely other values, by comparing it to the closest of the predicted values, according to a similarity threshold, and if so, to send the less likely other value without coding it in the manner of the coding of the predicted values. It can be configured to send an indication that the value has been sent without being coded in the manner of the coding of the predicted values.

It can be configured to carry out the coding dependent on a current state of at least one of the following variables: time of occurrence, conditions of network traffic, configuration of network and current status of network elements. It can be configured to receive an indication of a size of coded values to be generated, and to carry out the coding according to the indicated size. It can be configured to carry out the coding by using an index associating those predicted values of the performance data which are more likely to occur, with corresponding coded values.

This figure shows an example of a computer program 225 having instructions that when executed by processing circuitry cause the processing circuitry to carry out the methods as set out above. The memory circuit 230 is an example of a computer program product comprising a computer readable medium 230 having stored on it the computer program.

Figure 15, embodiment of a decoder having processing circuit

Figure 15 shows a schematic view of a decoder 30 according to an embodiment, for decoding received coded performance management data of a network element 60, the decoder having a processing circuit 320 and a memory circuit 330, the memory circuit having instructions executable by the processing circuit. The processing circuit when executing the instructions is configured to modify how to decode the received coded performance management data according to a prediction of which values of that performance management data are more likely to occur in a future period than other values, to receive coded values of the performance management data, coded so that the predicted values are coded preferentially compared to the other values, and to decode the received coded values of the performance management data, in the modified manner. This can be implemented in various ways as described above and can provide advantages as described above, and can have any additional features. For example the processing circuit can be configured to receive an indication associated with a received coded value that it was sent without being coded in the manner of the coding of the predicted values. It can be configured to decode the received coded value associated with the indication, by accepting it as a decoded value without using the adapted code. It can be configured to carry out the decoding according to a current state of at least one of the following variables: time of occurrence, conditions of network traffic, configuration of network and current status of network elements.

It can be configured to receive an indication of a size of the coded values, and the processing circuit is also configured to decode according to the indicated size. It can be configured to decode using an index associating those predicted values of the performance data which are more likely to occur, with corresponding coded values.

This figure shows an example of a computer program 325 having instructions that when executed by processing circuitry cause the processing circuitry to carry out the methods as set out above. The memory circuit 330 is an example of a computer program product comprising a computer readable medium 330 having stored on it the computer program.

Figure 16, modular embodiment of a data analyser

Figure 16 shows a schematic view of an analyser 10 for adapting a coder for coding of performance management data of a network element, for transmission, the analyser having a receiver 191 for receiving performance management data relating to the network element over a past time period. It also has an analysing module 195 for analysing the received performance management data to make a prediction which values of that performance management data are more likely to occur in a future period than other values, and a modifying module 197 for modifying the coder according to the prediction to code the predicted values preferentially compared to the other values for the future period. It can be implemented in many ways and can have any of the additional features for an analyser described above in relation to figures 2 to 12.

Figure 17, modular embodiment of a coder

Figure 17 shows a schematic view of a coder 20 according to an embodiment, for sending coded performance management data of a network element 60, the coder having a modifying unit 244 for modifying how to code the performance management data according to a prediction of which values of that performance management data are more likely to occur in a future period than other values, and a coding unit 250. This is for coding values of the performance management data occurring during the future period in the modified manner, such that the predicted values are coded preferentially compared to the other values, and there is also provided a sending unit 260 for sending the coded values to a management system 40,42. It can be implemented in many ways and can have any of the additional features for a coder as described above in relation to figures 3 to 12.

Figure 18, modular embodiment of a decoder

Figure 18 shows a schematic view of a decoder 30 for decoding received coded performance management data of a network element 60, and having a modifying unit 350 for modifying how to decode the received coded values of the performance management data according to a prediction of which values of that performance management data are more likely to occur in a future period than other values. It also has a receiving unit 355 for receiving coded values of the performance management data coded so that the predicted values are coded preferentially compared to the other values, and a decoding unit 360 for decoding the received coded values of the performance management data in the modified manner. It can be implemented in many ways and can have any of the additional features for a decoder as described above in relation to figures 3 to 12.

Concluding remarks As described above, features of embodiments can bring particular advantages. For example the use of a flexible size setting can enable a reduced PM task footprint as a share of resources at the node, management system, and DCN, enabling an extended PM network coverage. The feature of an adaptive and network specific PM counter size setting algorithm can also lead to optimized network and management system resource usage. Problems addressed by features of embodiments, include limited OSS PM collection capabilities on live networks in terms of network portion (number of nodes) or limited set of counters per node, due to the need to limit the overall PM task footprint (on resources for data storing, processing and DCN load). Many other variations can be envisaged within the scope of the claims.