referring initially to fig1 there is shown a performance management system 1 for measurement of the performance of a managed telecommunications network 2 having traffic machines 3 . the traffic machines 3 perform traffic handling and produce raw traffic data which is used as the basis for performance data . the raw data is transmitted over a high - speed interface and is received by a filter 22 which forms the logical boundary between the system 1 and the managed network 2 . the filter 22 acts as a gateway or mediation device for real time performance of the management system . thus , unnecessary data may be readily discarded while also reformatting data from the raw format to one which may be used by the management system . the system 1 comprises a hierarchy of performance agents 10 . each agent 10 is responsible for the processing , analysis and abstraction of the performance data received from the traffic machines 3 or lower level agents 10 . agents 10 at any level of the hierarchy may be connected to a user interface 11 which presents the information to a user . the arrangement of the user interface is quite flexible , for example , there may be an interface associated with each agent and a centralised interface may be connected to more of the agents than is illustrated in is fig1 . an authority is the management system responsible for a domain , the domain being defined as a unit of responsibility of abstraction which may optionally be taken to include any and all sub - ordinate domains in the hierarchy . the upwardly - directed arrows indicate flow of event signals , whereas the downwardly - directed arrows indicate flow of subscription signals instructing the agents . these subscription signals are described in detail below . in principle , the level of abstraction increases as one traverses up the hierarchy ( indicated by the arrow a ) and the amount of global knowledge decreases as one traverses down the hierarchy ( indicated by the arrow b ). at the sane timer the level of detailed knowledge of the network resources decreases as one traverses up the hierarchy ( a ). these principles are illustrated in fig2 . each agent 10 reports a small pre - defined set of performance metrics as a minimum to its parent in the hierarchy , which in turn uses the received data to generate the same set of metrics for itself . this set of metrics taken together with a set of defined threshold values specify a set of states for the network . these states are a meaningful abstraction of the current condition of the network resources and form the basis for network monitoring and control activities . as each agent 10 at each level in the hierarchy is required to generate the same set of metrics then each agent 10 must understand the contribution of the metric values it receives from its subordinate agents 10 and incorporate these into a value to be sent up to the parent agent 10 . this is achieved through use of a weighting function which is best explained through use of an illustrative example . consider the trivial situation as shown in fig2 where there is a three layer hierarchy of agents 10 corresponding to cells , region and network . if one of the metrics being generated is congestion then each of the agents 10 will be required to generate a congestion value . the value of congestion generated by pa 2 will be based on the values received from pa 3 and pa 4 . however , pa 3 and pa 4 may be cells with very different characteristics , say pa 3 is a busy cell in the commercial district of a city , while pa 4 is a cell in a low populated rural area . obviously , the value of congestion generated by pa 2 should be biased in favour of the value received from pa 3 even if this value is lower than that received from pa 4 . in this way , a truer picture of the overall congestion in the region related to pa 2 is present to pa 1 . this means that each agent 10 in the hierarchy which has a set of children must calculate their metrics using a weighted combination of the performance metrics received from its children . this can be expressed mathematically as value level   i = f all   subordinate   agent j   ( w j i  value j ) , ∀ j   and   ∑ w j i = i , ∀ i , j in which w i j is the weight applied by agent i to metrics from agent j . in addition to the generation of the performance metrics , each agent 10 may also be required to calculate a set of performance statistics . these performance statistics are lower in level than the performance metrics and are only sent to another agent 10 on request . the agent 10 may also calculate some statistics on request and store them locally for future retrieval by another agent . an important aspect of the invention is the ability to analyze network failure conditions in conjunction with performance information to determine the actual severity of the failure condition . events relating to failure conditions are called exception events and these events are generated either by the traffic machines when they detect a hardware / software fault , or by an agent 10 when a performance threshold is crossed . once an agent 10 receives an exception event , it correlates it with the performance information to determine how severe the exception condition is . this correlation is called the severity function and it takes into account the nature of the failure condition , the measured ( or anticipated ) effect on the performance of the network , the configuration of the underlying , resources ( e . g . a failure of a backup antenna may not be an urgent condition ), the weighting factor described earlier ( e . g . loss of a rural cell is not as crucial as the loss of a cell in the commercial quarter of a city ), in addition to other factors which might be defined by an operator . because the management network contains a hierarchy of agents 10 , each with a higher level and wider view of the network resources then the severity of a particular exception event could be measured and correlated by different agents 10 at different levels in the hierarchy . each agent 10 could send its &# 39 ; view of the severity to a maintenance management system which based on the severity will prioritise maintenance activities accordingly . depending on how the hierarchy is organised , it may happen that an agent 10 from more than one superior authority is interested in the information being generated by an agent 10 in a lower level authority . this effectively means that an agent 10 could be interacting with more than one superior agent 10 . this is not a problem for the hierarchy of agents 10 , but it is assumed that a particular agent 10 gives preference in reporting information to its own authority and to the parent authority in the control hierarchy . in other words , the invention is so defined that it is flexible to fit into a strict hierarchy of authorities or a looser network of authorities . how the control hierarchy is arranged is not constrained . however , the relative importance of each subscriber to a particular agent 10 must be represented by the agent . this is achieved by use of a priority rating scheme in each agent 10 . there are two different types of interaction between the agents 10 , namely , subscription interactions which set the activity required by an agent and event passing interactions which are used for passing the performance data . a subscription may instruct an agent to store some information in its database such as periodic statistical reports , or an exception event relating to a particular failure condition . an agent can subscribe to two types of events , namely , periodic performance events and exception events , referred to in the specification as periodic subscriptions and exception subscriptions . in the case of the former , the subscription message must contain a specification of the timing constraints related to the subscription . in some cases , the agent receiving the subscription may find that it is unable to meet these timing constraints due to the extra load that it would place upon the agent and the load already on the agent . for this reason , the subscription interactions are confirmed ( i . e . the subscriber receives a reply indicating whether the agent accepts the subscription or not ). in the case of the exception subscriptions the subscriber must specify the nature of the exception event as part of the subscription . an exception subscription effectively tells the receiving agent 10 under what circumstances to generate exception events and where to send them . the subscription could be as simple as a specification of the particular type of events to send , or could contain some filter expression which when evaluating to true the corresponding exception is sent to the subscriber . in order for agents to tell the agent 10 the particular information which is required , then it is necessary that both share a common notation for describing the performance information and filtering expressions for events . this notation or language is used as part of the subscription messages and describes to the receiver the particular performance information which is required as part of the subscription . the use of subscriptions between consumers of performance information and performance agents allows significant flexibility to subscribers in gaining access to and specifying the performance information they require . the use of subscriptions also allows a receiving performance agent to analyze new requirements in terms of the loads they will place upon the agent . this means that the performance agent can ensure that it will meet the subscriptions that it accepts . in this way , the network of performance agents cannot be overloaded by subscriptions which cannot be met . the passing of performance and exception information between the agents 10 and other agents is achieved by event passing . there are two types of events : exception events which report exceptional conditions in the network ( e . g . performance threshold passed , or equipment failure ) and periodic events which are evaluations of particular performance metrics at a particular instant in time . the event passing should occur in real ( or close to real ) time , but as will be seen in the next section the real time requirements differ for periodic and exception events . the use of events as the medium for reporting of performance information allows the information to be exchanged immediately it is required , rather than being stored and retrieved later as is often the case in current systems . there is often a confusion between what is meant by a real time system and a high performance system . in a real time system information or tasks have a temporal meaning — it is not just the information or task which is important but also the time at which the information is available or the task is complete . in a high performance system , the information is available or the task is complete in a short period of time . in the real time system , the activity may not be complete in a short period of time , but should complete before a deadline . in other words , the difference between the real time system and the high performance system is that the real time system has timing constraints in the form of deadline which should be met , while a high performance system performs its activities fast but does not give any guarantees about when the activity will be complete . in general , there are three types of real time systems which are categorised by the deadlines which are required : 1 . a hard real time system is one in which it is critical that the system responds to its inputs within the specified deadlines . the consequences of missing a hard deadline are catastrophic . 2 . a soft real time system is one in which the response times of the system are important but the system will still function if the deadlines are missed . thus , a soft deadline will often have a few characteristics which describe the deadline . for example , these could include the deadline itself , the upper bound on the probability of missing the deadline , an upper bound on the lateness of the delivery . 3 . a firm real time system is a variation of a soft real time system . the firm real time system will recover from a missed deadline but once the deadline is missed , the activity is stopped . it is important to note that the obvious objective is to meet these deadlines but failure to do so is not catastrophic . as mentioned above , the real time requirements are purely on the reporting of event based information on the status of the network . the subscription interactions do not have any real time requirements associated with them . there are two types of real time information to be reported and each has different real time requirements : 1 . the periodic performance which is generated by each performance agent in response to its subscriptions . it can be seen that the periodic information has firm deadlines , in that , once the data has passed the deadline then it is effectively discarded by the real time system ( the same piece of data may be stored for future analysis in a database but this activity does not have a real time requirement ). 2 . the exception event information which are generated either by the tms in response to hardware / software failure conditions or by agents 10 when a performance threshold is crossed . the exception information has slightly different temporal requirements to the periodic performance information . the exception information does not have the same ephemeral characteristics as the periodic information . the periodic information ( as mentioned above ) has a lifetime of some small multiple of the sampling period . the exception events have a lifetime which is ( for the most part ) the same as the failure condition which raised it . thus , while it is important to send the exception event to its subscriber as soon as is possible , there is not an implicit deadline associated with an exception . consequently , we can say that we would like all exception events to be received by their subscribers within some time period of their occurrence . this would essentially form a soft deadline which could be violated , but late exceptions will not be discarded . referring now to fig3 construction of a particular agent 10 is illustrated . the following are the components . a subscription handler 20 , which has the responsibility for handling incoming subscriptions and determines whether the agent 10 can deliver the required information . this decision is based on whether the underlying information is available within the agent or from subordinate agents 10 and whether the agent 10 itself is able to meet the deadline associated with the subscriptions . this last decision is taken in conjunction with the scheduler and may also be based on interactions with subordinate agents 10 for source information . an important part of the subscription handler is mapping from the specification language in the subscription to the underlying information contained in the agent 10 . if a subscription is accepted , the handler modifies the parameters of the filter and sets up any required subscriptions to subordinate agents 10 , the subscription handler supports the non real time communications interfaces for agents 10 . an analyzer 21 which calculates the metrics , determines the severity of exception , compares metrics against thresholds , analyses trends and correlates exception events and performance data , each having a certainty value describing the accuracy of the data . a database 23 which stores the analyzed information and selected raw information as required by the agent 10 . the information which is to be stored is specified by supra agents via a subscription , and by the local agent 10 itself . it is assumed that there is a default set of information which each agent 10 stores . an event handler 24 which performs prioritisation and the scheduling of the transmission of the events to be sent from the agent having regard to the associated certainty value . the event handler supports the real time communications interface for the agent 10 . a task scheduler 24 which is responsible for the scheduling of tasks within the performance agents so that task deadlines are met . the scheduler has the ability to schedule the tasks using a real time scheduling algorithm ( e . g . earliest deadline first or least slack time ). the scheduler should also understand the relative importance of tasks to each other ( i . e . the ability to assign different priorities to the tasks ). the scheduler has access to the network clock for consistency of time . in addition to the components of the performance agent , the following components are assumed to be a part of the underlying authority platform . it is assumed that they are consistent across the whole of the system . a clock 26 which gives the agent 10 access to the system wide “ real time ” clock , thus ensuring that the distributed agents all have the same consistent view of time . this is an extremely important part of the invention and is essential for the real time behaviour of the measurement system . a naming service 27 which provides consistent system wide names for the performance agents and the resources which they manage . a management information repository 28 , which is a database storing the following information : this database is needed to ensure the consistency of the above mentioned information across the management network . also , other management agents such as control agents may use the information repository . the task of the management information repository ( see fig5 ) is to receive and store the definition of the above mentioned information from the operator and provide it to the agents . other agents such as a control agent in need of management and managed network information can access this repository . therefore , the information repository has two distinct interfaces , one towards the gui / operator and one towards the agents . the interface towards gui / operator is used for the definition of the models and metrics / states / exception events . the interface towards the performance agent is used to respond to queries regarding the management network seen from that performance agent , the resources it monitors , providing metrics / states / exception event expression and updating the performance agent of changes in the management network related to that agent and the monitored resources of that agent . other management agents may use the repository for information regarding the management network and the managed resources by performance agents . there are no real time requirements on the activities of the information repository . as agents are working in real time , they may keep a copy of relevant management information . in order to keep consistency of data , each agent can refer only to changes of relevant information in the repository . the repository provides the advantage of consistency of management information and performance data definition is maintained . it also enables “ hot updates ”— new measurements can be defined without restarting or recompiling agents . an important aspect of any real time system is the ability to predict the behaviour of the system . in particular , the prediction of the temporal behaviour of the system is important . for a single performance agent operating on a dedicated computer this is quite challenging , but it is very unlikely that a single performance agent would have a dedicated computer . instead the performance agents will have to reside with other performance agents on the same workstation and share and contend for the same resources ( e . g . processor , communications links , etc .). this means that common aspects of the performance agents should be centralised into a performance agent shell which then offers these facilities as performance agent services . the agent specific logic ( i . e . abstraction , and modelling functions ) then utilise these services . an example of the subscription process between the performance agents 10 and the management information repository ( mir ) is described in more detail . when an agent requires real time information on a managed resource , the agent sends a request to the responsible performance agent 10 . the performance agent 10 queries the mir to determine how to evaluate the requested data . the performance agent receives a response , containing the elements of the subscription for the specified performance data and managed response if found in the mir or an error if not located . this error triggers an error in the performance agent which is transmitted to the subscribing agent . such an error may occur when the performance data is not defined in the mir . when a suitable response is received from the mir , the performance agent continues the subscription process . the pa first checks if it can meet the requested deadline . if the deadline cannot be met , pa sends a negative answer to the subscribing agent . if the response from the mir indicates that the pa needs additional data from some of its subordinates , it formulates new subscription requests and sends them to the appropriate performance agents . when formulating the new subscription requests , the pa calculates how much time it can give to its subordinates to perform their part of the task and still meet the deadline . this new deadline is sent in the subscription requests . this process continues until the filter receives the subscription request . an important feature of the invention is the dynamic real - time calculation at available deadlines to subordinate performance agents . when the filter receives the subscription request , it checks again with the mir to find out what the requested performance data means and how it should map the performance data generated by tm . if the subscription makes sense and if it can meet the given deadline , it sends a positive acknowledgement to the subscribing agent , otherwise a negative acknowledgement is sent . whenever a pa sends a positive acknowledgement , it starts scheduling the activity and continues reporting until the subscription is cancelled . referring to fig4 a shell 30 is illustrated on a computing platform 31 . the individual components are as described with reference to fig3 . an important aspect of the invention is the fact that agents gather data from subordinate agents , thus allowing filtering of information in a progressive manner and abstraction to the required level . transmission of the subscription signals sets the operation for a particular agent and this provides a large degree of versatility . for example , a user interface could be connected directly to an agent at a low level in the hierarchy thus providing a large degree of low - level data where this is required . at the same time , there could be a large degree of filtering at an agent in the low level of the hierarchy to provide abstraction at a low level where this is required . the important point is that there is a large degree of versatility with the system . referring to fig6 there is shown an alternative arrangement to that described with respect to fig2 wherein similar components are identified by the same reference numerals generally . the performance agents 10 are arranged as before with the same characteristic levels of abstraction and network knowledge . in this case , the performance agents 10 pass information to a control device 40 through an interface 41 . this is an important feature of the invention allowing data to be communicated with an external control device . the control device may respond to this information by generating subscriptions . because the system comprises decentralised agents , the resources are spread out and are scalable to meet the volume of performance data captured from the traffic machines . this allows true real tune performance and allows resilience to such things as sudden bursts of information which would otherwise cause overload situations to arise . the system of the invention can also provide a view of the network performance which is temporally consistent across the network . further , measurements activities can be prioritised according to their relative importance . it will be appreciated that the subscription passing between subscribing and performance agents , must of necessity have a subscription priority indicator . this subscription priority indicator is made up of two distinct components . the first component indicates the relative importance assigned by the subscribing or performance agent to the subscription and the second component defining a precedence level for the agent within the management network . another advantage of the invention is the fact that granularity of measurement can be significantly lower than the prior art . the invention is not limited to the embodiments hereinbefore described , but may be varied in construction and detail .