32.1043G Performance Management3GPPRelease 1999Telecommunication managementTS
Any evaluation of 3G-system behaviour will require performance data collected and recorded by its NEs according to a schedule established by the EM. This aspect of the management environment is termed Performance Management.
The purpose of any Performance Management activity is to collect data, which can be used to verify the physical and logical configuration of the network and to locate potential problems as early as possible. The type of data to be collected is defined by the equivalent measurements (refer to annex C). The present document concentrates on the requirements of 3G-telecom management to produce this data. Any management actions performed at the OSs subsequently to analyse the performance data are not considered in the present document.
Data is required to be produced by the NEs to support the following areas of performance evaluation:
– traffic levels within the network, including the level of both the user traffic and the signalling traffic (4.1.1);
– verification of the network configuration (4.1.2);
– resource access measurements (4.1.3);
– Quality of Service (e.g. delays during call set-up, packet throughput, etc) (4.1.4); and
– resource availability (e.g. the recording of begin and end times of service unavailability) (4.1.5).
The production of the measurement data by the NEs also needs to be administered by the EM. Several phases of administration of performance measurements can be distinguished:
– the management of the performance measurement collection process (4.2.1);
– the generation of performance measurement results (4.2.2);
– the local storage of measurement results in the NE (4.2.3);
– the transfer of measurement results from the NE to an OS (4.2.4); and
– the storage, preparation and presentation of results to the operating personnel (4.2.5).
4.1 Measurement data requirements
This subclause describes the typical requirements for performance data to be produced by the NEs, which comprise a 3G system. It is important to note that an actual measurement value collected from the network may be used to satisfy requirements in more than one category of measurement described below.
4.1.1 Traffic measurements
Traffic measurements provide the data from which, among other uses, the planning and operation of the network can be carried out.
The types of traffic evaluations for which 3G specific measurements may be used include:
– traffic load on the radio interface (signalling and user traffic);
– usage of resources within the network nodes;
– user activation and use of supplementary services, etc.
Examples of measured values may include:
– pages per Location area per hour;
– busy hour call attempts per RNC, MSC;
– handovers per RNC per hour, etc.
4.1.2 Network configuration evaluation
Once a network plan, or changes to a network plan, have been implemented it is important to be able to evaluate the effectiveness of the plan or planned changes. Typically, the measurements required to support this activity indicate the traffic levels with particular relevance to the way the traffic uses the network.
4.1.3 Resource access
For accurate evaluation of resource access, each measurement result would need to be produced for regular time intervals across the network, or for a comparable part of the network.
4.1.4 Quality of Service (QoS)
The user of a 3G system views the provided service from outside the network. That perception can be described in observed QoS terms. QoS can indicate the network performance expected to be experienced by the user. For further detail see ITU-T Recommendation E.880 .
The QoS parameters applied by the network to specific user services may also be relevant to determine the charges levied towards the user for the provision of those services.
4.1.5 Resource availability
The availability performance is dependent on the defined objectives, i.e. the availability performance activities carried out during the different phases of the life cycle of the system, and on the physical and administrative conditions. For further detail see ITU-T Recommendation E.880 .
4.2 Measurement administration
The range of measurements which will be available from the NEs are expected to cover all of the requirements described in subclause 4.1. However, not all of these measurements will be required all of the time, from every occurrence, of every relevant NE. With a highly distributed network like a 3G mobile telecommunication system it is also necessary to gather the measurement data so as to perform consistent analysis of the results and to evaluate the interactions between the NEs.
This subclause describes the requirements for the various areas of administration of measurements.
4.2.1 Measurement job administration
Measurement jobs, i.e. the processes which are executed in the NEs in order to accumulate the data and assemble it for collection and/or inspection, will need to be scheduled by the EM for the period or periods for which gathering of data shall be performed.
The administration of measurement jobs by the EM comprises the following actions:
1) Create/delete a measurement job. This action implies the instantiation respectively deletion of a measurement collection process within the network.
2) Modifying a measurement job, i.e. changing the parameters (specifically the schedule) of a measurement job that has been previously created.
3) Definition of measurement job scheduling. This action defines the period or periods during which the measurement job is configured to collect performance data.
4) Suspend/resume a measurement job. The "suspend" action inhibits the collection of measurement data by a measurement job, regardless of its schedule, without deleting it. The "resume" action will re-enable measurement data collection according to the measurement job schedule.
5) Setting up the requirements for the reporting and routing of results to one or more OSs (EM and/or NM). For the NM, this is limited to the control of the result file transfer.
6) Retrieval of information related to measurement jobs, i.e. view the current measurement job definition.
4.2.2 Measurement result generation
Each measurement job will be collecting result data at a particular frequency, known as the granularity period of the measurement. At the end of the granularity period a scheduled result report shall be generated for each measurement job that is actively collecting performance measurement data.
The measurement data can be collected in each NE of the network in a number of ways:
– cumulative incremental counters triggered by the occurrence of the measured event;
– status inspection (i.e. a mechanism for high frequency sampling of internal counters at pre-defined rates);
– gauges (i.e. high tide mark, low tide mark);
– discrete event registration, where data related to a particular event is captured.
These are described in the following paragraphs.
The NE maintains a running count of the event being counted. The counter is reset to a defined value (usually "0") at the beginning of the granularity period.
Network elements maintain internal counts for resource management purposes. These counts are read at a predetermined rate, the rate is usually based upon the expected rate of change of the count value. Status inspection measurements shall be reset at the beginning of the granularity period and will only have a valid result at the end of the granularity period.
Gauges represent dynamic variables that may change in either direction. Gauges can be integer or real valued. If a gauge is required to produce low and high tide marks for a granularity period (e.g. minimum and maximum call duration), then it shall be reinitialised at the beginning of the granularity period. If a gauge is required to produce a consecutive readout over multiple granularity periods (e.g. cabinet temperature), then it shall only be reinitialised at the start of a recording interval (see definition of "recording interval" in subclause 220.127.116.11 below).
Discrete Event Registration:
This is a measurement of a specified event where every Nth event would be taken into account. The value of N is dependent on the frequency of occurrence of the event being measured. Discrete event registration measurements shall be reset at the beginning of the granularity period and will only have a valid result at the end of the granularity period.
4.2.3 Local storage of results at the Network Element
It shall be possible for the NE to retain measurement data it has produced for deferred retrieval by the OS(s). This data will be retained at the NE under the control of the EM. The storage capacity and the duration for which the data will be retained at the NE will be Operator and implementation dependent.
4.2.4 Measurement result transfer
The results of the measurement job can be forwarded to the EM in either of two standard ways:
1) the scheduled result reports generated by the NE (notifications) can be sent to the EM as soon as they are available;
2) the reports can be stored in the NE (files) and transferred to or retrieved by the EM when required.
It shall be possible for the EM to specify the details for its result retrieval as a part of the measurement administration.
Measurement results can be forwarded to the NM via a bulk transfer interface. It is an implementation option whether this interface resides in the EM or the NEs. Depending on the implementation, the control of the bulk transfer of measurement results to the NM may involve the EM and/or the NM. See annex B for details.
In a network with more than one OS (e.g. EM and NM) the data produced may be required by several OSs. It is therefore necessary to support the possibility for multiple destinations for transfer of data.
All scenarios for the result transfer, as far as they are relevant for standardisation of 3G systems, are defined above. It should be noted that, depending on an Operator’s needs, measurement results may have to be transferred to the EM only, the NM only, or both. Depending on a vendor’s implementation, measurement results may be transferred to the NM directly from the NE or via the EM. This implies that not all of the result transfer options described above shall be implemented in all cases, however, those procedures that are implemented shall comply with the present document. A detailed specification of the measurement result transfer to the NM can be found in annex B of the present document.
4.2.5 Performance data presentation
The performance data user interface presentation, including the storage and preparation of the data, is outside the scope of the present document.
4.3 Measurement definition
This subclause looks at the requirements for the definition of the individual measurements.
4.3.1 Nature of the result
The measurements defined for the 3G system have to be collected in the NEs. As each NE has its own role to play in the provision of the mobile service then each will have a different perspective on the performance of the network. The measurement definitions shall, therefore, contain a description of the intended result of the measurement in terms of what is being measured.
4.3.2 Perceived accuracy
The accuracy of measurements can be seen in three ways:
– whether the result produced represents all occurrences of the defined event;
– whether related measurements produced for the same period refer to the same events; or,
– whether a measurement result refers to the whole or part of a granularity period.
Representation of all occurrences:
The definition of a measurement needs to accurately reflect which types of events are to be included in the collection of the data. If a general event or procedure description can be characterised by several sub-types then the measurement definition will have to be precise as to which sub-types are included or specifically excluded from that measurement. Depending on the measurement definition, it may prove more acceptable to count the event or procedure termination by causes, e.g. successful termination, unsuccessful termination for all reasons. If the definition of a measurement refers to specific unsuccessful termination causes then care shall be taken to assess whether all causes are included – the sum of which can provide the total number of unsuccessful terminations – or whether the total is defined as well as the specific causes.
Same period for the same two events:
Consider two events being counted which refer to the same allocation attempt, falling on either side of a granularity period boundary. i.e. the attempt is counted in one period while the termination with a successful cause is counted in the subsequent period. This will lead to discrepancies appearing in the actual figures when trying to compare attempts and successes for the same period. In order to avoid this discrepancy, implementations shall ensure that the result of a procedure started within a given granularity period shall be captured within the measurement results for that same period, even if the completion of the procedure falls within the next granularity period.
Measurement collection periods:
A typical measurement collection period can be interrupted by system events.
These interruptions can be one or more of the following:
– failure of the measured network resource;
– failure of the procedure being measured, e.g. location update;
– resource only becomes available after the measurement period has commenced;
– procedure only becomes available after the measurement period has commenced.
In these cases the measurement result shall highlight such interruptions to indicate that the result is suspect. In extreme circumstances, no result reports at all can be generated. Any actions to be taken subsequently with regards to the usefulness of the data will depend on the circumstances and the requirements of individual 3G Operators.
4.3.3 Comparability of measurement data
In a multi-vendor network it is important to know that measurement data produced by equipment from one supplier is equivalent to the measurement data being produced by the equivalent equipment from another supplier. This is particularly important when analysing data across the whole network. The measurement definitions (in annex C of the present document) shall therefore use a common understanding of the events being measured so as to produce comparable results.
4.3.4 Measurement identification
In complex networks it is easy to generate large amounts of performance data. It is essential that all such data is recognisable in respect of each request made. As all the required information, which can distinguish each request already, exists by definition the request, it makes sense to use this information, rather than create anything new. The information, which can be used to distinguish requests from each other may be e.g. NE name, measurement type, granularity period, or a combination of these. NE names defined within the realm of CM (3GPP TS 32.106 ) shall be reused.