Tech-invite3GPPspaceIETFspace
21222324252627282931323334353637384‑5x

Content for  TS 32.401  Word version:  17.0.0

Top   Top   Up   Prev   Next
0…   4…   5…   5.4…   5.7…

 

4  Conceptp. 10

Any evaluation of PLMN-system behaviour will require performance data collected and recorded by its NEs according to a schedule established by the EM. For the scenario of mobile networks includes virtualized Network Functions, the evaluation of PLMN-system behaviour will also require the VR related performance data collected and recorded by the VNFM (see TS 28.500). 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, virtual 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 (e.g., as specified in TS 52.402 and TS 32.404). The present document concentrates on the requirements of GSM, UMTS and LTE 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 (clause 4.1.1);
  • verification of the network configuration (clause 4.1.2);
  • resource access measurements (clause 4.1.3);
  • Quality of Service (e.g. delays during call set-up, packet throughput, etc) (clause 4.1.4); and
  • resource availability (e.g. the recording of begin and end times of service unavailability) (clause 4.1.5).
In the scenario that the 3GPP NF is virtualized, data is also required to be produced by the VNFMs to support the evaluation of the impact of VR performance to 3GPP NF.
The production of the measurement result data by the NEs or VNFM 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 (clause 4.2.1);
  • the generation of performance measurement results (clause 4.2.2);
  • the local storage of measurement results in the NE or VNFM (clause 4.2.3);
  • the transfer of measurement results from the NE or VNFM to an OS (EM and/or NM) (clause 4.2.4); and
  • the storage, preparation and presentation of results to the operating personnel (clause 4.2.5).
In respect to the evaluation of the results produced by the measurements the following has to be considered:
  • to understand the nature of the results received from the network (clause 4.3.1);
  • to assure the reliability and accuracy of the measurement results (clause 4.3.2);
  • to ensure comparable measurement results for the same measurements being performed in equipment from different vendors (clause 4.3.3);
  • the ability to identify the results in the management systems: with respect to the measurement jobs by the EM, and with respect to the measurement types and measured resources by the NM (clause 4.3.4); and
  • to take into account that, in a set of n correlated measurements, any (n-1) out of the defined n measurements may be provided by the network (clause 4.3.5).
Performance measurements may also be used to supervise operator defined threshold values and generate alarms upon exceeding the thresholds (clause 4.4).
The following clauses provide further background on the performance measurement concept that is applicable to GSM, UMTS and LTE networks. Although any implementation of GSM, UMTS and LTE network elements shall adopt the concept described below, not all of the text - due to its conceptual nature - is usable to actually determine compliance of the equipment. In these cases, more strictly specified requirements, against which conformance shall be proven, are found in clause 5 of the present document.
Up

4.1  Measurement result data requirementsp. 11

This clause describes the typical requirements for performance data to be produced by the NEs, which comprise a GSM, UMTS or LTE network. 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 measurementsp. 11

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 PLMN specific measurements may be used include:
  • traffic load on the radio or core network interfaces (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 BSC, RNC, MSC;
  • handovers per BSC/RNC per hour, etc.
Up

4.1.2  Network configuration evaluationp. 12

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 accessp. 12

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)p. 12

The user of a PLMN 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 [5].
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 availabilityp. 12

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 [5].

4.2  Measurement administrationp. 12

The range of measurements which will be available from the NEs are expected to cover all of the requirements described in clause 4.1. However, not all of these measurements will be required all of the time, from every occurrence, of every relevant NE. Therefore, it is necessary to administer the measurements so as to determine which measurement types, on which measured resources, at which times, are to be executed. With a highly distributed network like a GSM, UMTS or LTE mobile telecommunication system it is also necessary to gather the measurement result data so as to perform consistent analysis of the results and to evaluate the interactions between the NEs.
This clause describes the requirements for the various areas of administration of measurements.
Up

4.2.1  Measurement job administrationp. 12

Measurement jobs, i.e. the processes which are executed in the NEs or VNFM in order to accumulate measurement result 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. Specification of the measurement types to be contained in the job, e.g. "number of GPRS attach attempts".
    In GSM, the measurement jobs are administered by individual measurement types, which are specified in TS 52.402. In UMTS and LTE, the measurement jobs may be administered per individual measurement type or per measurement family, which comprises a collection of related measurement types. The measurement types and families for UMTS and combined GSM/UMTS networks are specified in TS 32.405, TS 32.406, TS 32.407, TS 32.408 and specified in TS 32.409 for IMS. Measurement types and families for E-UTRAN are specified in TS 32.425 and for EPC in TS 32.426. Measurement types and families for Home Node B (HNB) Subsystem (HNS) are defined in TS 32.452 and for Home enhanced Node B (HeNB) Subsystem (HeNS) in TS.32.453 [40].
  5. Identification of the measured resources, i.e. the NEs (e.g. MSC, NodeB) or NE components (e.g. trunkgroups, radio channels, transceivers) to which the measurement types or measurement families, specified in the measurement job, pertain.
  6. Suspend/resume a measurement job. The "suspend" action inhibits the collection of measurement result data by a measurement job, regardless of its schedule, without deleting it. The "resume" action will re-enable measurement result data collection according to the measurement job schedule. It may also be possible for the system to suspend a measurement job without any operator's action in case of overload. It should then be possible, at any time, for the operator to resume a job suspended by the system.
  7. Setting up any necessary requirements for the reporting and routing of results to one or more OSs (EM and/or NM).
  8. Retrieval of information related to measurement jobs, i.e. view the current measurement job definition.
A measurement job is thus characterised by a set of measurement types and/or measurement families which all pertain to the same set of measured resources and share the same schedule. Typically a large number of measurement jobs will run simultaneously within the NEs comprising the PLMN, and one or more EM is involved in the administration of those measurement jobs. In order for the operator to manage this large number of measurement jobs effectively and efficiently, it is necessary that the administration functions in the EM can not only deal with individual measurements on individual NEs, but also scope the execution environment across the measured resources, and apply an additional filter to the resources/NEs selected by the measurement scope. The scoping and filtering of the measurement(s) shall then be automatically adapted if measured resources that match the selection criteria are added or removed.
There are several instances of this "plug&measure" feature:
  1. execute the same (set of) measurement type(s) on a set of identical resources within a single NE. An example of this is to measure the average bit error rate on all channels in a cell, or all channels of the cell that match the filter criterion;
  2. execute the same (set of) measurement type(s) on a set of identical NEs or resources according to the hierarchical structure of the network. Examples of this are to measure the average bit rate on all IuPS links of the same U-MSC or to measure inter-cell handovers for all cells attached to the same BSC;
  3. execute the same (set of) measurement type(s) across all resources/NEs of the same type that belong to a specific administrative domain. An example of this is to measure the call set-up failure rate in all cells located in a certain city, or otherwise defined geographical area (this may be a combination of scope and filter), or within the responsibility area of system operator number 2.
The definition of those administrative, or management, domains may be part of either the measurement job administration functions or the CM functions provided by the EM. The functionality of scoping and filtering of measurements within the same NE may either be distributed across the NE and the EM (e.g. EM creates a single measurement job with scope and filter, and NE determines the measured resources that match the selection criteria), or it may be realised solely in the EM (EM determines measured resources from the scope and filter specified by the system operator, and multiple measurement jobs will be created), according to implementation choice.
Up

4.2.2  Measurement result generationp. 13

Each measurement job will be collecting result data at a particular frequency, known as the granularity period of the measurement job. At the end of the granularity period a scheduled result report is generated for each measurement job that is actively collecting performance measurement result data, i.e. for all the measurement types and measured resources covered by the job.
The measurement result data can be collected with a number of collection methods:
  • 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 ;
  • object mapping, where the measured object of the measurement is mapped from one to another.
These collection methods are:
  • Cumulative Counter (CC): The NE maintains a running count of the event being counted. The counter is reset to a well-defined value (usually "0") at the beginning of each granularity period.
  • Status Inspection (SI): 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.
  • Gauge: 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 each 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 clause 5. 4.1. 3).
  • Discrete Event Registration (DER): Data related to a particular event is captured. Every nth event is registered, where n can be 1 or larger. The value of n is dependent on the frequency of occurrence of the event being measured.
    DER measurements shall be reset at the beginning of each granularity period and will only have a valid result at the end of the granularity period.
  • Object Mapping (OM): The 3GPP entity maps the measured object(s) for the measurements, that are collected by a method defined by another SDO, from the non-3GPP defined MOI(s) to 3GPP defined MOI(s) representing the managed 3GPP NF(s), and generates the 3GPP measurement(s) for the 3GPP defined MOI with or without processing of the mapped (source) measurements.
The measurement result data can be collected in a non-3GPP defined NE of the network with a number of collection methods which are not defined in this document. These collection methods are referred to as "externally defined collection methods"
This following item describes the collection method to be used for collecting measurements result data from a non-3GPP defined NE.
Transparent Forwarding (TF):
The non-3GPP defined NE maintains a count based on the NE's "externally defined collection method". The 3GPP system maintains a measurement count that is a snapshot/reading of the non-3GPP defined NE count at each granularity period.
Up

4.2.3  Local storage of results at the NE/EMp. 14

It is necessary for the NE or management entity to retain measurement result data it has produced until they have been sent to, or retrieved by, the destination OS(s). Depending on implementation and configuration details, e.g. the transfer method, the number and type (EM/NM) of the destination OS(s), this data will be retained at the NE or management entity under the control of the destination OS(s), or solely under the control of the EM. The storage capacity and the duration for which the data will be retained at the NE or management entity will be Operator and implementation dependent.
If the measurement result data are routed to an NM via the EM, then it is necessary for the EM to retain the data in a storage for NM retrieval. The storage capacity and the duration for which the data will be retained are Operator and implementation dependent.
Up

4.2.4  Measurement result transferp. 14

Measurement results produced by the NEs are transferred to an external OS for storage, post-processing, and presentation to the system operator for further evaluation. In a network with more than one OS (e.g. EM and NM) the data may be required by several OSs. It is therefore necessary to support the possibility for multiple destinations for the transfer of measurement result data.
Case when the NE does not involve VNF(s):
From the NE to the EM, the results of the measurement jobs can be forwarded in either of two standard ways:
  1. the scheduled result reports, generated by the measurement jobs executing in the NE, can be sent to the EM as soon as they are available (notifications);
  2. the reports can be stored in the NE (files) and transferred to or retrieved by the EM when required.
From the network to the NM, measurement results can be forwarded via a bulk transfer (i.e. file-based) interface. It is an implementation option about the location of this bulk transfer interface to the NM.
Case when NE involves VNF(s):
The results of the performance measurements of VRs utilized by the NE, can be forwarded in either one of the two standard ways:
  1. the scheduled result reports, generated by the measurement jobs executing in the VNFM, can be sent to the EM as soon as they are available (notifications);
  2. the reports can be stored in files by VNFM and transferred to or retrieved by the EM when required.
From the network to the NM, measurement results can be forwarded via a bulk transfer (i.e. file-based) interface. It is an implementation option about the location of this bulk transfer interface to the NM.
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 have to be implemented in all cases.
Up

4.2.5  Performance data presentationp. 15

The performance data user interface presentation, including the storage and preparation of the data in the OS(s), is outside the scope of the present document.

4.3  Measurement type definitionsp. 15

This clause looks at the requirements for the definition of the individual measurement types.

4.3.1  Nature of the resultp. 15

The measurement types defined for the GSM and UMTS systems 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 type definitions shall, therefore, contain a description of the intended result of the measurement in terms of what is being measured. Appropriate information is included in the measurement type definition templates, see TS 52.402 and TS 32.404.
Up

4.3.2  Perceived accuracyp. 15

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 by causes, e.g. successful termination, unsuccessful termination for all reasons. If the definition of a measurement refers to specific failure causes then care shall be taken to assess whether all causes are included - the sum of which can provide the total number of failures - or whether a count of the total is defined as well as for the specific causes. This is particularly important if not all of the causes are supported by an implementation, or if not all of the causes are requested in the measurement job definition.
Same period for the same two events: consider two events being counted which refer to the same resource allocation procedure, falling on either side of a granularity period boundary. I.e. the attempt is counted in one period while the termination is counted in the subsequent period. This will lead to discrepancies appearing in the actual figures when trying to compare attempt and termination counts for the same period. In order to avoid this discrepancy, implementations shall ensure that the termination of a procedure started within a given granularity period shall be captured within the measurement results for that same period, even if the termination 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:
  1. failure of the measured network resource;
  2. failure of the measurement procedure;
  3. the measured network resource only becomes available after the measurement period has commenced;
  4. the measurement procedure only becomes available after the measurement period has commenced.
  5. system error (e.g. disk failure/lack of memory);
  6. communication error (e.g. link failure between the network manager and the measured network resource).
Any such interruption implies that the affected measurement result is incomplete, and in extreme circumstances, no result reports at all can be generated. In these cases the measurement result shall highlight such interruptions to indicate that the result is suspect (see also setting of suspectFlag in Performance Measurement File Format Definition TS 32.432).
Any actions to be taken subsequently with regards to the usefulness of the data will depend on the circumstances and the requirements of individual Operators.
Up

4.3.3  Comparability of measurement result datap. 16

In a multi-vendor network it is important to know that measurement result data produced by equipment from one supplier is equivalent to the measurement result data being produced by the equivalent equipment from another supplier. This is particularly important when analysing data across the whole network. The measurement type definitions (in TS 52.402, TS 32.405, TS 32.406, TS 32.407, TS 32.408,TS 32.409, TS 32.425, TS 32.426, TS 32.452 and TS 32.453) shall therefore use a common understanding of the events being measured (e.g. by relating to protocol messages) so as to produce comparable results.
Up

4.3.4  Measurement identificationp. 16

In complex networks it is easy to generate large amounts of performance data. For the administration of the measurement jobs, and for the attribution of result data to the correct measurements, it is essential for the EM that all measurement result data is recognisable in respect of each request made. For post-processing of the measurement results in the NM, it is essential that measurement results can be attributed to the correct measurement types and NEs/measured resources.
As all the required information to distinguish the measurement results for each request, already exists in the definition of 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's, may be e.g. NE name, measurement type, granularity period, or a combination of these. NE names defined within the realm of CM (TS 32.600 and the associated network resource model in other 32.6xx TSs) shall be reused. For the measurement job administration in the EM, it is also possible to use measurement job ids, or other implementation specific parameters that identify the measurements.
Up

4.3.5  (n-1) out of n approachp. 16

The measurement result values generated by a NE can be obtained in a number of different ways. For example, measurements can be defined to provide the number of attempts for a certain procedure plus the number of failures and the number of successes, where the sum of the successes and failures equals the number of attempts. This means that actually any 2 of the above 3 measurements provide the same information. Therefore, an approach has been adopted in the present document and its companions, TS 52.402 and TS 32.404, to allow a vendor to choose any (n-1) out of the n defined counters for implementation (2 out of 3 in the above example). The benefit of this approach is to avoid redundancy in the measurement implementation, while at the same time leaving freedom for implementation of the measurements in the network elements. As all n result values of the measurement results are relevant for system operators, the missing nth value shall be calculated by post-processing running on the NM.
It is important to note, however, that, depending on the measurement type definition, some implementation choices can offer more detailed information than others. For example, if per-cause failure measurements are specified, then the implementation of the "attempts" and "successes" measurements still allows post-processing to calculate the number of failures, but per cause information can not be derived. Therefore, in this case, the failure measurement should always be implemented, while there is still freedom to choose the "attempts" or the "successes" measurement as the other one to be implemented. The "failure" measurement should still be capable of delivering a total value, if not all failure causes are supported or if the results are not requested for (all of) the failure causes in the set-up of the measurement job.
Note that the principal problem, described above, also exists for measurements where sub-types are specified.
Up

4.4  Performance alarmsp. 17

Instead of, or in addition to, generating regular scheduled result reports, measurements may be administered in a way so as to supervise operator-defined thresholds. The thresholds are set when instantiating the measurements, and alarms are generated when the threshold value is crossed. These performance alarms are generated instead of, or in addition to, the generation of the scheduled result reports, as configured by the system operator. In UMTS, the alarms are sent to the OS via the Alarm IRP specified in TS 32.111-2. In GSM, according to implementation choice, the alarms are sent either via the Alarm IRP or via the Q3 interface specified in the GSM 12.xx series of specifications. Depending on the nature of the measurement (cumulative counter, status inspection, gauge, discrete event registration), the observed value, which is checked against the threshold, can only be derived at the end of a granularity period (status inspection and discrete event registration), and may have to be reset at the beginning of a new granularity period (cf. clause 4.2.2).
A GSM, UMTS or LTE NE may also generate threshold alarms based on system-internal supervision of counters and their threshold values. Neither the threshold nor the counters can be administered, but they depend on internal system behaviour, defined by implementation. As the present document only specifies results and alarms based on manageable performance measurements, the system internal threshold alarms explained above are outside the scope of the present document and are solely within the realms of Fault Management.
Up

Up   Top   ToC