ETSI TS 132 404 V8.4.

0 (2009-10)
Technical Specification

Digital cellular telecommunications system (Phase 2+);

Universal Mobile Telecommunications System (UMTS);
LTE;
Telecommunication management;
Performance Management (PM);
Performance measurements - Definitions and template
(3GPP TS 32.404 version 8.4.0 Release 8)
 3GPP TS 32.404 version 8.4.0 Release 8 1 ETSI TS 132 404 V8.4.0 (2009-10)

Reference
RTS/TSGS-0532404v840

Keywords
GSM, LTE, UMTS

ETSI

650 Route des Lucioles

F-06921 Sophia Antipolis Cedex - FRANCE

Tel.: +33 4 92 94 42 00 Fax: +33 4 93 65 47 16

Siret N° 348 623 562 00017 - NAF 742 C

Association à but non lucratif enregistrée à la
Sous-Préfecture de Grasse (06) N° 7803/88

Important notice

Individual copies of the present document can be downloaded from:

http://www.etsi.org

The present document may be made available in more than one electronic version or in print. In any case of existing or
perceived difference in contents between such versions, the reference version is the Portable Document Format (PDF).
In case of dispute, the reference shall be the printing on ETSI printers of the PDF version kept on a specific network drive
within ETSI Secretariat.

Users of the present document should be aware that the document may be subject to revision or change of status.
Information on the current status of this and other ETSI documents is available at
http://portal.etsi.org/tb/status/status.asp

If you find errors in the present document, please send your comment to one of the following services:
http://portal.etsi.org/chaircor/ETSI_support.asp

Copyright Notification

No part may be reproduced except as authorized by written permission.

The copyright and the foregoing restriction extend to reproduction in all media.

© European Telecommunications Standards Institute 2009.

All rights reserved.
TM TM TM TM
DECT , PLUGTESTS , UMTS , TIPHON , the TIPHON logo and the ETSI logo are Trade Marks of ETSI registered
for the benefit of its Members.
TM
3GPP is a Trade Mark of ETSI registered for the benefit of its Members and of the 3GPP Organizational Partners.
LTE™ is a Trade Mark of ETSI currently being registered
for the benefit of its Members and of the 3GPP Organizational Partners.
GSM® and the GSM logo are Trade Marks registered and owned by the GSM Association.

ETSI
3GPP TS 32.404 version 8.4.0 Release 8 2 ETSI TS 132 404 V8.4.0 (2009-10)

Intellectual Property Rights

IPRs essential or potentially essential to the present document may have been declared to ETSI. The information
pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found
in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in
respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web
server (http://webapp.etsi.org/IPR/home.asp).

Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee
can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web
server) which are, or may be, or may become, essential to the present document.

Foreword
This Technical Specification (TS) has been produced by ETSI 3rd Generation Partnership Project (3GPP).

The present document may refer to technical specifications or reports using their 3GPP identities, UMTS identities or
GSM identities. These should be interpreted as being references to the corresponding ETSI deliverables.

The cross reference between GSM, UMTS, 3GPP and ETSI identities can be found under
http://webapp.etsi.org/key/queryform.asp.

ETSI
3GPP TS 32.404 version 8.4.0 Release 8 3 ETSI TS 132 404 V8.4.0 (2009-10)

Contents
Intellectual Property Rights ................................................................................................................................2
Foreword.............................................................................................................................................................2
Foreword.............................................................................................................................................................4
1 Scope ........................................................................................................................................................5
2 References ................................................................................................................................................5
3 Definitions and template ..........................................................................................................................6
3.1 Definitions .......................................................................................................................................................... 6
3.2 Abbreviations ..................................................................................................................................................... 7
3.3 Measurement definition template ....................................................................................................................... 8
3.4 Definition of private Object Classes ................................................................................................................. 11
3.4.1 RA............................................................................................................................................................... 11
3.4.2 MMS Relay/Server ..................................................................................................................................... 11
3.4.3 ObservedDestination................................................................................................................................... 11
3.5 Management of per cause measurements ......................................................................................................... 12
3.6 Rule for generic measurements definition ........................................................................................................ 13

Annex A (informative): Examples for "(n-1) out of n" approach ......................................................14

A.1 Attempt/success/failure procedure measurements .................................................................................14
A.2 GSM/UMTS combined measurements...................................................................................................14
A.3 Embedded "(n-1) out of n" approaches ..................................................................................................15
Annex B (informative): Top-Down Performance Measurement Definition Process........................16
B.1 Scope of this annex.................................................................................................................................16
B.2 Overview ................................................................................................................................................16
B.3 Measurement User Communities ...........................................................................................................17
B.3.1 Network Operator Business Community .......................................................................................................... 17
B.3.2 Network Operator Maintenance Community ................................................................................................... 18
B.3.3 Network Operator Traffic Engineering Community ........................................................................................ 18
B.3.4 Network Operator Customer Care Community ................................................................................................ 18
B.3.5 Equipment Vendor Performance Modelling Community ................................................................................. 19
B.3.6 Equipment Vendor Development Engineering Community ............................................................................. 20
B.3.7 User Community Conclusion ........................................................................................................................... 20
B.4 Enhanced GQM ......................................................................................................................................21
B.4.1 GQM Methodology .......................................................................................................................................... 21
B.4.2 Enhanced GQM (EGQM) Methodology .......................................................................................................... 23
B.5 Measurements Life Cycle Process .........................................................................................................25
B.6 Conclusion..............................................................................................................................................26
Annex C (informative): Change history ...............................................................................................27
History ..............................................................................................................................................................28

ETSI
3GPP TS 32.404 version 8.4.0 Release 8 4 ETSI TS 132 404 V8.4.0 (2009-10)

Foreword
This Technical Specification has been produced by the 3rd Generation Partnership Project (3GPP).

The contents of the present document are subject to continuing work within the TSG and may change following formal
TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an
identifying change of release date and an increase in version number as follows:

Version x.y.z

where:

x the first digit:

1 presented to TSG for information;

2 presented to TSG for approval;

3 or greater indicates TSG approved document under change control.

y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections,
updates, etc.

z the third digit is incremented when editorial only changes have been incorporated in the document.

Introduction
The present document is part of a TS-family covering the 3rd Generation Partnership Project; Technical Specification
Group Services and System Aspects; Telecommunication management; as identified below:

32.401 Performance Management (PM); Concept and requirements

52.402 Performance Management (PM); Performance measurements – GSM
32.404 Performance Management (PM); Performance measurements - Definitions and template
32.405 Performance Management (PM); Performance measurements Universal Terrestrial Radio Access
Network (UTRAN)
32.406 Performance Management (PM); Performance measurements Core Network (CN) Packet Switched
(PS) domain
32.407 Performance Management (PM); Performance measurements Core Network (CN) Circuit
Switched (CS) domain
32.408 Performance Management (PM); Performance measurements Teleservice
32.409 Performance Management (PM); Performance measurements IP Multimedia Subsystem (IMS)

The present document is part of a set of specifications, which describe the requirements and information model
necessary for the standardised Operation, Administration and Maintenance (OA&M) of a multi-vendor 3G-system.

During the lifetime of a 3G network, its logical and physical configuration will undergo changes of varying degrees and
frequencies in order to optimise the utilisation of the network resources. These changes will be executed through
network configuration management activities and/or network engineering, see TS 32.600 [3].

Many of the activities involved in the daily operation and future network planning of a 3G network require data on
which to base decisions. This data refers to the load carried by the network and the grade of service offered. In order to
produce this data performance measurements are executed in the NEs, which comprise the network. The data can then
be transferred to an external system, e.g. an Operations System (OS) in TMN terminology, for further evaluation. The
purpose of the present document is to describe the mechanisms involved in the collection of the data and the definition
of the data itself.

Annex B has been added to help in the definition of new performance measurements that can be submitted to 3GPP for
potential adoption and inclusion in the present document. Annex B discusses a top-down performance measurement
definition methodology that focuses on how the end-user of performance measurements can use the measurements.

ETSI
3GPP TS 32.404 version 8.4.0 Release 8 5 ETSI TS 132 404 V8.4.0 (2009-10)

1 Scope
The present document describes the measurements for UMTS and combined UMTS/GSM.
TS 32.401 [1] describes Performance Management concepts and requirements.
The present document is valid for all measurement types provided by an implementation of a UMTS network and
combined UMTS/GSM network. Only measurement types that are specific to UMTS or combined UMTS/GSM
networks are defined within the present documents.
Vendor specific measurements types used in UMTS and combined UMTS/GSM networks are not covered. Instead,
these could be applied according to manufacturer's documentation.

Measurements related to "external" technologies (such as ATM or IP) as described by "external" standards bodies
(e.g. ITU-T or IETF) shall only be referenced within this specification, wherever there is a need identified for the
existence of such a reference.

The definition of the standard measurements is intended to result in comparability of measurement data produced in a
multi-vendor network, for those measurement types that can be standardised across all vendors' implementations.

The structure of the present document is as follows:

- Header 1: Network Element (e.g. RNC related measurements);

- Header 2: Measurement function (e.g. soft handover measurements);
- Header 3: Measurements.

2 References
The following documents contain provisions which, through reference in this text, constitute provisions of the present
document.

• References are either specific (identified by date of publication and/or edition number or version number) or
non-specific.

• For a specific reference, subsequent revisions do not apply.

• For a non-specific reference, the latest version applies. In the case of a reference to a 3GPP document (including
a GSM document), a non-specific reference implicitly refers to the latest version of that document in the same
Release as the present document.

[1] 3GPP TS 32.401: "Telecommunication management; Performance Management (PM); Concept

and requirements".

[2] 3GPP TS 52.402: "Telecommunication management; Performance Management (PM);

Performance measurements - GSM".

[3] 3GPP TS 32.600: "Telecommunication management; Configuration Management (CM); Concept

and high-level requirements".

[4] GSM 12.04: "Digital cellular telecommunications system (Phase 2+); Performance data measurements".

[5] 3GPP TS 23.003: "Numbering, Addressing and Identification".

[6] Void.

[7] 3GPP TS 32.632: "Telecommunication management; Configuration Management (CM); Core

Network Resources Integration Reference Point (IRP): Network Resource Model (NRM)".

[8] 3GPP TS 32.642: "Telecommunication management; Configuration Management (CM); UTRAN

network resources Integration Reference Point (IRP): Network Resource Model (NRM)".

[9] 3GPP TS 32.622: "Telecommunication management; Configuration Management (CM); Generic

network resources Integration Reference Point (IRP): Network Resource Model (NRM)".
[10] ITU-T Recommendation E.410: " International network management – General information"

ETSI
3GPP TS 32.404 version 8.4.0 Release 8 6 ETSI TS 132 404 V8.4.0 (2009-10)

3 Definitions and template

3.1 Definitions
For the purposes of the present document, the following terms and definitions apply:

"(n-1) out of n" approach:

- The measurements result values generated by a NE can be obtained in a number of different ways. Therefore, the
"(n-1) out of n approach" has been defined in order to avoid redundancy in the measurements.

- The "(n-1) out of n approach" allows a vendor to choose any (n-1) out of the n defined counters for
implementation but some choices can offer more detailed information than others. The missing nth value can be
calculated in post-processing.

- If multiple measurements are included in one template, then the applicability of the "(n-1) out of n" scenario are
mentioned in template item A with the following sentence "The n measurement types defined in item E are
subject to the "(n-1) out of n approach"". The item D will specify the measurement result per measurement type
specified in template item E.

- If the measurements that are applicable to the "(n-1) out of n" scenario are defined in separate templates, then
they will be grouped together into a common clause of the TS, and the applicability of the approach will be
mentioned in the clause that groups the measurements.

- Examples of measurements which are subject to the "(n-1) out of n" approach are provided in the annex A.

Measurement community

Several measurement communities are defined in the present document to identify the end users of system
measurements. Each measurement should be defined to address the needs of at least one of these user communities.

Six communities have been identified so far:

- Network Operator's Business Community

- Network Operator's Maintenance Community
- Network Operator's Traffic Engineering Community
- Network Operator's Customer Care Community
- Equipment Vendor's Performance Modelling Community
- Equipment Vendor's Development Engineering Community

A comprehensive description of measurement communities is provided in Annex B. The user communities names are a
composite of the various terms used in the industry and might be subject to modification or refinement in future
releases.

Measurement family

The measurement names defined in the present document are all beginning with a prefix containing the measurement
family name (e.g. RAB.AttEstabCS.Conv, MM.AttGprsAttach). This family name identifies all measurements which
relate to a given functionality and it may be used for measurement administration (see TS 32.401 [1]).

The list of families currently used in the present document is as follows:

- HHO (measurements related to Hard Handover)

- MM (measurements related to Mobility Management)
- RAB (measurements related to Radio Access Bearer management)
- RRC (measurements related to Radio Resource Control)
- SM (measurements related to Session Management)
- SMS (measurements related to Short Message Service)

ETSI
3GPP TS 32.404 version 8.4.0 Release 8 7 ETSI TS 132 404 V8.4.0 (2009-10)

3.2 Abbreviations
For the purposes of the present document, the following abbreviations apply:

3G 3rd Generation
3GPP 3G Partnership Project
ASN.1 Abstract Syntax Notation 1
ATM Asynchronous Transfer Mode
BER Basic Encoding Rules
CN Core Network
DTD Document Type Definition
EGQM Enhanced Goal, Question, Metric
EM (Network) Element Manager
GQM Goal, Question, Metric
IEEE Institute of Electrical and Electronics Engineers, Inc.
Itf Interface
ITU-T International Telecommunication Union - Telecommunications Standardisation Sector
NE Network Element
NM Network Manager
OA&M Operation, Administration and Maintenance
OS Operations System (EM, NM)
OSI Open Systems Interconnection
PM Performance Management
QoS Quality of Service
RNC Radio Network Controller
UMTS Universal Mobile Telecommunications System
UTRAN Universal Terrestrial Radio Access Network

You can find below a list of abbreviations used within the measurement types for field E of the measurement template
(see subclause 3.3).

Att Attempt(s,ed)
Conn Connection
CS Circuit switched
Conv Conversational
Estab Establish (ed,ment)
FDD Frequency Division Duplex
HHO Hard Handover
HO Handover
Inter Inter
Intra Intra
Max Maximum
MM Mobility Management
Out Outgoing
PS Packet switched
RAB Radio Access Bearer
RNC RNC
RRC Radio Resource Control
SGSN SGSN
Sub Subscriber
Succ Success(es,ful)
UTRAN UTRAN

ETSI
3GPP TS 32.404 version 8.4.0 Release 8 8 ETSI TS 132 404 V8.4.0 (2009-10)

3.3 Measurement definition template

Following is the template used to describe the measurements contained in this subclause.

C.x.y. Measurement Name (clause header)

This is a descriptive name of the measurement type that is specified as clause C.x.y of the present document.

The measurement name shall be written in lower-case characters except abbreviations (e.g. RNC).

A measurement name can apply to one or more measurements. If the measurement name applies to several
measurements then all fields of the template will take this into account.

Measurement names shall not exceed 64 characters in length and should be constrained to 32 characters
maximum. Exceptions greater than 32 characters are allowed but should be kept to a minimum and only made
where necessary.

a) Description

This subclause contains an explanation of the measurement operation.

b) Collection Method

This n contains the form in which this measurement data is obtained:

- CC (Cumulative Counter);

- GAUGE (dynamic variable), used when data being measured can vary up or down during the period of
measurement;

- DER (Discrete Event Registration), when data related to a particular event are captured every nth event is
registered, where n can be 1 or larger;

- SI (Status Inspection).

c) Condition

This subclause contains the condition which causes the measurement result data to be updated;
This will be defined by identifying protocol related trigger events for starting and stopping measurement
processes, or updating the current measurement result value. Where it is not possible to give a precise condition,
then the conditional circumstances leading to the update are stated.

If a measurement is not available for FDD or TDD, then the measurement description shall contain a statement.

If a measurement is related to 'external' technologies, this subclause shall give a brief reference to other standard
bodies.

d) Measurement Result (measured value(s), Units)

This subclause contains a description of expected result value(s) (e.g. a single integer value). If a measurement is
related to 'external' technologies, this subclause shall also give a brief reference to other standard bodies.

The definition applies for each measurement result.

e) Measurement Type

This subclause contains a short form of the measurement name specified in the header, which is used to identify
the measurement type in the result files.

The measurement names are dotted sequences of items. The sequence of elements identifying a measurement is
organised from the general to the particular.

- The first item identifies the measurement family (e.g. HHO, RAB, SMS). Note that this family may also be
used for measurement administration purpose.

- The second item identifies the name of the measurement itself, for which the following rules shall apply:

ETSI
3GPP TS 32.404 version 8.4.0 Release 8 9 ETSI TS 132 404 V8.4.0 (2009-10)

The second item of the measurement name can be divided into <Operation>, <Reason/Result>
and <Direction> (and in that order)

Examples of Operation can be Establishment, Release, and Modification

Examples of Reason/Result can be Attempt, Failure, Success, Throughput and Volume

Examples of Direction can be Incoming, Outgoing, Uplink and Downlink

- Depending on the measurement type, additional items may be present to specify subcounters (failure causes,
traffic classes, min, max, avg, G, U ...). In case of multiple additional items, they are also represented as a
dotted sequence of items. When available, the template will describe to which standard it is referring to for
these additional items (e.g. cause, traffic class). Otherwise, the additional item semantics must be described
in details in the present document.

Standardised causes will be a number. This number shall be derived according to which of the following
rules applies:

- For the standardised causes with numeric values explicitly specified in the reference spefication, the subcounter
name will be the number assigned to this cause in this reference specification.

- For the standardised causes without numeric values explicitly specified in the reference spefication, but where
the causes are identified, the subcounter name shall be an number from 1 to n mapped in an incremental
sequence to each of the specified causes following top down sequence in the order they are identified in the
reference specification (e.g. RRC.ConnEstab.1, 1 idenfies the establishment cause 'Originating Conversational
Call', see TS 25.331);

- For the standardised causes without numeric values explicitly specified in the reference spefication and the
causes identified and the causes have been divided into different cause groups, the subcounter should be defined
as the form of "Cause group".Cause, where:

o the subcounter name of "Cause group" shall be an incremental number from 1 to n to identify each
cause group specified in a top down sequence following the order they are identified in the reference
specification,

o the subcounter name of cause within this cause group shall be an incremental number from 1 to n to
identify each cause within the group specified in a top down sequence following the order they are
identified within the cause group in the reference specification (e.g. RLM.FailRLSetupIub.2.1, 2.1
indenfies the cause 'Transport resource unavailable' in the cause group 'Transport Layer Cause', see TS
25.433). Subcounter "Cause group".sum is permitted to indentify the aggregate of measurement values
of all the causes within the cause group (e.g. RLM.FailRLSetupIub.1.sum, 1.sum identifies the
aggregate of all the causes within the cause group 'Radio Network Layer Cause', see TS25.433).

The non standardised causes should be a string (e.g. RRC.ConnEstab.NoReply).

The set of values issued for a measurement does not depend on the associated collection method (CC, SI, Gauge,
DER). For instance, a gauge collected counter does not necessarily provide min, max, average values.

The vendor-specific UMTS and combined GSM/UMTS measurement names will all begin with the VS prefix.

In addition, it is recommended that a prefix is added for non-UMTS measurements:

- Q3 for Q3 measurements;

- MIB for IETF measurements (ATM, IP);

- OS for other standards measurements.

The 3GPP standardised measurements name must not commence with the above prefixes.

Examples of valid measurement names are:

- HO.PrepAtt

- SAEB.EstabSucc

ETSI
3GPP TS 32.404 version 8.4.0 Release 8 10 ETSI TS 132 404 V8.4.0 (2009-10)

- RRC.ConnEstabAtt.Cause
where Cause identifies the failure cause.

Examples of valid measurement names for measurements defined before version 8.3.0 of the present document
are:

- VS.HO.InterSGSNReject.NoResource;

- ATM. ATML.IngressCells;

- HHO.SuccOutIntraCell;

- MM.AttachedSubs.Max;

- RAB.EstabAttCS.Conversational;

- RRC.ConnEstab.Cause
where Cause identifies the failure cause.

Abbreviations to be used within measurement types can be found in subclause 3.2 of the present document.

f) Measurement Object Class

This subclause describes the measured object class (e.g. UtranCell, RncFunction, SgsnFunction). The object
class used for this purpose shall be in accordance with NRMs defined in any NRM IRPs, such as those defined in
3GPP TS 32.622 [9], TS 32.632 [7] and TS 32.642 [8].

For object classes currently not defined according to the above, the present document defines its own
nomenclature (e.g. RA, LAC).

It is possible to use the same measurement name for a standardized measurement type implemented at a different
object class level than the one defined in the Standard. The same measurement type can apply to one or more
measurements for which all fields of the measurement template are the same except the clause f) "Measurement
Object Class". For instance, a measurement which uses the same template as a given measurement type but
relates to another or different object classes (e.g. UtranCell instead of UtranRelation, or RncFunction and
UtranCell) shall have the same name.

g) Switching Technology

This subclause contains the Switching domain(s) this measurement is applicable to i.e. Circuit Switched and/or
Packet Switched.

h) Generation

The generation determines if it concerns a GSM, UMTS, EPS, combined (GSM+UMTS+EPS) or IMS
measurement.

- GSM: pure GSM measurement; it only counts GSM events. In a combined (GSM+UMTS+EPS) NE the
count would be exactly the same as in a pure GSM NE. In a pure UMTS, pure EPS or combined UMTS and
EPS NE this counter does not exist;

- UMTS: pure UMTS measurement; it only counts UMTS events. In a combined (GSM+UMTS+EPS) NE the
count would be exactly the same as in a pure UMTS NE. In a pure GSM, pure EPS or combined GSM and
EPS NE this counter does not exist;

- EPS: pure EPS measurement; it only counts EPS events. In a combined (GSM+UMTS+EPS) NE the count
would be exactly the same as in a pure EPS NE. In a pure GSM, pure UTMS or combined GSM and UTMS
NE this counter does not exist;

- GSM/UMTS: measurement applicable to both GSM and UMTS systems; in a combined (GSM+UMTS) NE
separate subcounts for GSM and/or UMTS events can be obtained;

- GSM/UMTS/EPS: measurement applicable to GSM, UMTS and EPS systems; in a combined

(GSM+UMTS+EPS) NE separate subcounts for GSM, and/or UMTS, and/or EPS events can be obtained;

ETSI
3GPP TS 32.404 version 8.4.0 Release 8 11 ETSI TS 132 404 V8.4.0 (2009-10)

- Combined: measurement applicable to combined GSM, UMTS and EPS systems, but regardless of whether
the measured event occurred on the GSM, UMTS or EPS part of the system. This means that in a combined
NE only one total (i.e. GSM+UMTS+EPS) count is obtained for the measured event.

The above aspects are also reflected in the measurement type name in template item E by adding a "G" to the
GSM measurements, "U" to the UMTS measurements, "E" to the EPS measurements.

- IMS: measurement applicable to IMS.

NOTE: The 2G component of combined 2G/3G equipment may actually choose to implement GSM
measurements according to the present document or GSM12.04 [4] / TS 52.402 [2], based on GSM
specifications.

i) Purpose

This optional clause aims at describing who will be using the measurement. It is proposed to indicate in this
clause the targeted categories of users based on the measurement user communities described in Annex B.

When available, this clause provides additional information on the interest of the measurement but is however
purely indicative.

3.4 Definition of private Object Classes

Private Object Classes are Object Classes which are needed for PM purposes, but that are not yet defined by CM.

3.4.1 RA
The Object Class RA (Routing Area) is needed to conduct measurements on RA level. For the purpose of the present
document, the Routing Area should be encoded in the file format as the concatenation of the MCC, MNC, LAC and the
RAC, in decimal notation. See further definition of Routing Area Identification in TS 23.003 [21]. Since LAC is a 2
byte number (00000-65535), 5 characters are needed in the moid PrintableString. Since RAC is a 1 byte number
(000-255) 3 characters are needed in the moid PrintableString. MCC is 3 digits and MNC 2 or 3 digits. The
concatenated moid PrintableString will always contain 14 characters. In the case where MNC has the length 2, a leading
underscore character will be added.

a) EXAMPLE 1: LAC = Hexadecimal 4E20 = Decimal 20000;

RAC = Hexadecimal BE = Decimal 190; MCC = Decimal 046; MNC = Decimal 01
moid = "046_0120000190".

The Object Class RA (Routing Area) is needed to conduct measurements on RA level. For the purpose of the present
document the Routing Area should be encoded in the file format as the concatenation of the LAC and the RAC, in
decimal notation. Since LAC is a 2 byte number (00000-65535) 5 characters are needed in the moid PrintableString.
Since RAC is a 1 byte number (000-255) 3 characters are needed in the moid PrintableString. Hence concatenated moid
PrintableString will always contain 8 characters.

EXAMPLE 2: LAC = Hexadecimal 4E20 = Decimal 20000;

RAC = Hexadecimal BE = Decimal 190;
moid = "20000190".

3.4.2 MMS Relay/Server

The Object Class MMS Relay/Server is needed to conduct measurements on MMS Relay/Server level. No specific
moid structure is defined for the MMS Relay/Server. The moid is a PrintableString which contains a maximum of
20 characters.

3.4.3 ObservedDestination
The Object Class ObservedDestination is needed to conduct measurements on ObservedDestination level.
For the purpose of the present document, the ObservedDestination could be country code, or/and an area code, or/and
an exchange, or/and other location number, or/and a special service number) in decimal notation (ITU-T E.410 [10].
The moid is a PrintableString which contains a maximum of 20 characters.

ETSI
3GPP TS 32.404 version 8.4.0 Release 8 12 ETSI TS 132 404 V8.4.0 (2009-10)

3.5 Management of per cause measurements

Per cause measurements may lead in certain cases to a lot of subcounters which will increase substantially the size of
the measurement report file. Since all per cause measurements are not necessarily useful to the end-user, two options
are possible for the management of the corresponding subcounters:

- support all the subcounters corresponding to the cause codes as defined in the 3GPP standards. In that case, the
sum of all supported per cause measurements is equal to the total sum across all subcounters;

- support only a subset of the subcounters (allowed only if the cause codes are specified in 3GPP standards). In
that case, the first value of the result sequence must be the total sum across all the cause codes as defined in
3GPP standards. This implies that all subcounters of a given measurement type appear as uninterrupted sequence
in the result file. The keyword .sum placed behind the measurement type is used to identify the sum subcounter.
The choice of the supported cause codes is manufacturer dependent.

ETSI
3GPP TS 32.404 version 8.4.0 Release 8 13 ETSI TS 132 404 V8.4.0 (2009-10)

3.6 Rule for generic measurements definition

The measurement definitions shall not be duplicated. Reference should be used instead.
If one measurement is needed in several places, there should be only one single definition with complete structure.
All other occurrences should make reference to the original one, whether they are in the same specification or not.

The measurements having the same definition of the following items are regarded as duplicated:

a) Description
b) Collection Method
c) Condition
d) Measurement Result (measured value(s), Units)
f) Measurement Object Class

The duplicated occurrence shall make reference to the original occurrence in two ways.

1. "Refer to <Clause number> for concrete definition"

in the case where both occurrences are within the same specification.

2. "Refer to <Specification number><Version Number><Clause number> for definition"

in the case the occurrences are in different specifications.

For the differing measurement template items e), g), h), i) the difference shall be pointed out after the reference notice.
The presentation of the differing items should follow the same format as in the measurement template.

ETSI
3GPP TS 32.404 version 8.4.0 Release 8 14 ETSI TS 132 404 V8.4.0 (2009-10)

Annex A (informative):
Examples for "(n-1) out of n" approach
The measurements result values generated by a NE are often redundant, or the info contained in the measurement
results can be obtained in a number of different ways.

The "(n-1) out of n" approach allows a vendor to implement a subset of 3GPP defined measurements, for example if
there exists a relation (A+B=C) then any 2 out of 3 defined measurements A, B, C are sufficient information to
calculate the third (n=3). In case there exists a relation (A+B+C=D), then any 3 out of the 4 would suffice, and the same
kind of approach would be applicable.

A.1 Attempt/success/failure procedure measurements

Consider the number of attempts to start a specific procedure (e.g. RRC connection establishment). Some of these
attempts will fail, some will be successful. Three different counters can be defined to measure these procedures: an
attempt counter, a success counter, and a failure counter, but in fact only 2 may be provided, since we have the fixed
relation (#success + #failure) = #attempt.

It is to be noted that all combinations do not provide the same level of details. For example, in the case only #attempt
and #success are provided, it will not be possible to retrieve the detailed failure causes.

The three measurement types defined in clause 4.4 of TS 32.405 are subject to the "(n-1) out of n" approach with n=3:

- Attempted RRC connection establishments.

- Failed RRC connection establishments.
- Successful RRC connection establishments.

The "(n-1) out of n" approach is also applicable for more complex measurements split according to a specific criterion,
e.g. Queuing. For example, the CS measurements described in clause 4.1 of TS 32.405 are subject to a 4 out of 5
approach:

- Attempted RAB establishments for CS domain.

- Successful RAB establishments without queuing for CS domain.
- Failed RAB establishments without queuing for CS domain.
- Successful RAB establishments with queuing for CS domain.
- Failed RAB establishments with queuing for CS domain.

Any of the five measurements can be calculated from the four others but all combinations will not provide the same
level of details (e.g. failure causes).

A.2 GSM/UMTS combined measurements

With relation to the field H of the measurement template, a measurement indicated with GSM/UMTS is an example of
the "(n-1) out of n" approach with n=3 since (GSM + UMTS) = Combined.

In that case, all concerned measurements are included in the same template but the vendor may provide only 2
subcounters out of 3.

The measurement described in subclause 4.6.1 of TS 32.406 is subject to the "(n-1) out of n" approach with n=3:

- SM.AttActPdpContext (attempted context activation procedures with no distinction between GSM and UMTS).
- SM.AttActPdpContext.G (attempted context activation procedures for GSM only).
- SM.AttActPdpContext.U (attempted context activation procedures for UMTS only).

ETSI
3GPP TS 32.404 version 8.4.0 Release 8 15 ETSI TS 132 404 V8.4.0 (2009-10)

A.3 Embedded "(n-1) out of n" approaches

It is also possible to combine the approaches described above. For example, the measurements described in
subclause 4.5 of TS 32.406 are subject to the "(n-1) out of n" approach at two levels.

Firstly, measurements are split according to the CS/PS domain, for example:

- attempted CS SMS mobile originating;

- attempted PS SMS mobile originating;
- attempted SMS mobile originating;

where any of the three measurements can be calculated from the two others.

Secondly, each measurement provides 3 subcounters, for example for Attempted CS SMS mobile originating:

- SMS.AttMoCS;
- SMS.AttMoCS.G;
- SMS.AttMoCS.U;

where any of the three subcounters can be calculated from the two others.

ETSI
3GPP TS 32.404 version 8.4.0 Release 8 16 ETSI TS 132 404 V8.4.0 (2009-10)

Annex B (informative):
Top-Down Performance Measurement Definition Process

B.1 Scope of this annex

Performance measurements within wireless telecommunications networks are required in order to meet the needs of the
diverse community of end-users of those measurements. New features develop, networks evolve and operating
conditions change without sufficient consideration given to the measurements needed to keep the network running
efficiently. While Equipment Vendors define measurements to satisfy their particular needs, other perspectives,
especially the voice of the Network Operator, are sometimes lost during Equipment Vendor development processes.
Similarly, Network Operators sometimes request measurements without fully understanding who will be using the data
or what actions those people will take based on the collected data. A coherent, simple, top-down methodology for
defining performance measurements is lacking in the telecommunications industry.

This annex proposes a methodology to handle the above problems. In particular, multiple user communities have been
defined representing the end-users of system measurements. Performance goals and measurements are defined
considering these same user communities. The definition includes identification of specific problem scenarios and
corrective actions to be taken by the appropriate user community.

Measurements defined using this methodology can be contributed to 3GPP SA5 for potential adoption and inclusion in
the present document. It is believed that this methodology will help reduce development costs for the Equipment
Vendors and reduce operational costs for the Network Operators.

B.2 Overview
Performance measurements are important to the proper and efficient functioning of wireless telecommunications
networks. They have numerous uses related to resource utilization, expansion planning, network optimisation, operating
problem diagnosis and network availability monitoring. For the wireless telecommunications world, product
performance measurements are necessary to support multiple communities of users.

In addition, once performance measurements are defined for a wireless telecommunication network they must be
maintained. The evolution of a wireless telecommunication network for capacity increases and feature extensions leads
to the evolution of the collected measurements. Performance measurements need to be added, modified and made
obsolete from the overall measurement repository. These changes must be defined completely and accurately to meet
the requirements of each community of users.

The development of a performance measurement life cycle process to oversee this need is proposed in this annex. The
life cycle process addresses the multiple user communities whose perspectives are needed to supply the requirements
for the performance measurements.

The proposed performance measurement life cycle process is a usage-based process. The basic Goal, Question, Metric
(GQM) method is enhanced to define problem scenarios and corrective actions. These descriptions are not only used to
filter out proposals for performance measurements that provide no defined benefit, but also support user community
training in the use of the performance measurements.

The remainder of this annex is organised as follows.

- Clause B.3 defines Measurement User Communities for wireless telecommunications.

- Clause B.4 discusses the GQM and the Enhanced GQM methods.
- Clause B.5 discusses the measurement life cycle process.
- Clause B.6 provides conclusions.

ETSI
3GPP TS 32.404 version 8.4.0 Release 8 17 ETSI TS 132 404 V8.4.0 (2009-10)

B.3 Measurement User Communities

One objective of Performance Management as a functional subset of operations and maintenance processes is to define
sets of measurements. Typical definition criteria revolve around measuring activity within the network in terms of
volume, speed and accuracy. While this approach produces measurement data it does not completely address the needs
and uses of the multiple consumers of network performance measurement information. The Enhanced GQM
methodology extends the measurement definition criteria to better satisfy multiple groups with diverse needs for these
measurements.

A qualitative judgement as to the efficacy of a Performance Management subsystem is how well served these different
groups are by the measurements provided. To better understand these needs, five generic categories of users, outlined
definitions and examples of their needs and requirements for measurements taken from their wireless
telecommunications network are defined. These groups are referred to as measurement user communities. These six
communities are:

1. Network Operator's Business Community

2. Network Operator's Maintenance Community
3. Network Operator's Traffic Engineering Community
4. Network Operator's Customer Care Community
5. Equipment Vendor's Performance Modelling Community
6. Equipment Vendor's Development Engineering Community

B.3.1 Network Operator Business Community

The first measurement user community is the Network Operator's Business Community. This community is defined
under the assumption that the wireless telecommunications network is fully operational, adequately engineered for
traffic load per quality of service definitions and in commercial service. The primary objective of this community is to
guarantee the financial health and welfare of the Operating Company. They expect a properly configured wireless
telecommunications network to supply the revenue per subscriber unit necessary to meet their financial goals.

An understanding of the elasticity of demand can help the Business Community maximize profits within their product
pricing strategy as they alter prices according to various mixes of services. Typical measurements of interest to this
community are those based on the actual volumes of calls completed by service type. This call volume information can
lead to trends of usage over time. Correlation between price mix and call volumes can help to identify pricing strategies
geared towards increasing revenue per subscriber unit.

ETSI
3GPP TS 32.404 version 8.4.0 Release 8 18 ETSI TS 132 404 V8.4.0 (2009-10)

B.3.2 Network Operator Maintenance Community

The second measurement user community is the Network Operator's Maintenance Community. This community is
defined under the assumption that the wireless telecommunications network is less than fully operational, adequately
engineered for traffic load per quality of service definitions and in commercial service. The primary objective of this
community is to reduce Mean Time to Repair faults that occur within the network equipment of the Operating
Company.

The baseline metric for this community is the availability of the network equipment, where availability is composed of
the sum of scheduled and unscheduled outages to the network equipment. Unscheduled outages are influenced by the
inherent hardware and software quality of the products provided to the operating company. While the Maintenance
Community has no direct control over that quality, they do have control over the second component of scheduled
outage, Mean Time to Repair.

Mean Time to Repair is influenced by the Mean Time to Detect a fault. This community of user's defines measurements
that support detecting or predicting faults within the network equipment.

Measurements that support this community can come from places other than the network equipment, itself. Several
Operating Companies have been observed building information systems based on the data provided by Call Detail
Records and Billing Records. Correlation is sought within these data between call faults and location within the
Network. Detection of these faults serves a dual purpose: it allows the Operating Company a view of performance at the
level of their Network Operator (the subscriber) and it allows the Maintenance Community to target specific network
equipment for repair.

B.3.3 Network Operator Traffic Engineering Community

The third measurement user community is the Network Operator's Traffic Engineering Community. This community is
defined under the assumption that the wireless telecommunications network is fully operational, inadequately
engineered for current or future traffic load per quality of service definitions and in commercial service. The primary
objective of this community is to keep the capacity of the network equipment within 1) the Operating Company's design
criteria for the quality of service based on growth of the subscriber base, 2) changes in usage patterns based on pricing
strategies and 3) introduction of new services.

The baseline metric for this community is the trend in utilization of the network equipment. A fully instrumented
network would allow the Operating Company to understand the trend in performance of their principle capital
investment and any leased services. As these trends pass thresholds of performance, purchasing decisions or volume
pricing discounts could be triggered.

B.3.4 Network Operator Customer Care Community

The fourth measurement user community is the Network Operator's Customer Care Community. This community is
defined under the assumption that the wireless telecommunications network is fully operational, functioning at a less
than optimal level resulting in end-user dissatisfaction and in commercial service. The primary objective of this
community is interfacing with the end-user customers of offered services for the purpose of establishing and
maintaining end-user customer satisfaction. This may include customer care responsibilities such as Customer
Relationship Management (CRM), Service Level Agreement (SLA) management, quality of service (or QoS)
management, etc.

This community is interested in defining measurements related to the end-user customer experience with the network
Operator's offered services in the areas of CRM, SLA, QoS, problem reports, etc. Decisions on how to best handle
customer dissatisfaction or how to keep customers from becoming dissatisfied are based on these types of
measurements.

ETSI
3GPP TS 32.404 version 8.4.0 Release 8 19 ETSI TS 132 404 V8.4.0 (2009-10)

B.3.5 Equipment Vendor Performance Modelling Community

The fifth measurement user community is Equipment Vendor's Performance Modelling Community. This community is
defined under the assumption that the wireless telecommunications network is fully operational, adequately engineered
for traffic load per quality of service definitions and in some level of call capable service. The primary objective of this
community is to guarantee that the models used during analysis and design phases conform to real-world observations
of the network equipment of the Operating Company.

While this community is not within the Operating Company it still provides beneficial service to the Operating
Company by managing the development of subsequent features that are in line with the actual performance
characteristics of the network. Many decisions within the development life cycle depend on models developed prior to
shipping the product. These models need to be calibrated to network performance once the product is released.
Definition of measurements in concert with calibrating these models requires the direct involvement of the people
developing the models.

The network that transports Network Management data often is the same network that carries call control traffic.
Clearly, the knowledge of volume levels of this traffic during anomalous operating conditions is important in order to
understand the total impact to call processing. This community would define measurements to allow the monitoring of
this type of phenomena.

ETSI
3GPP TS 32.404 version 8.4.0 Release 8 20 ETSI TS 132 404 V8.4.0 (2009-10)

B.3.6 Equipment Vendor Development Engineering Community

The sixth measurement user community is Equipment Vendor's Development Engineering Community. This
community is also defined under the assumption that the wireless telecommunications network is fully operational,
adequately engineered for traffic load per Quality of Service or Service Level Agreement definitions and in commercial
service. The primary objective of this community is to guarantee that the implementations of the designs conform to
real-world observations of the network equipment of the Operating Company.

While this community also is not within the Operating Company, it still provides beneficial service to the Operating
Company. The implementation of new algorithms carries some finite risk of performance in the Network Operator
environment versus the lab environment. Many times simulators of network activity are developed to support the
verification of these algorithms. These simulations need to be calibrated to network performance once the product is
released. Definition of measurements in concert with calibrating these simulations requires the direct involvement of the
people developing the simulations.

B.3.7 User Community Conclusion

The six measurement communities are broken into four Network Operator based groups and two Equipment Vendor
groups. However, experience shows that the measurements defined for these groups are not mutually exclusive. Other
groups may also use measurements needed by a particular group for the same or different purposes. Thus, the accurate
definition of the measurements and how to use them is necessary to allow the Network Operator to properly combine
these measurements into more complex analyses.

ETSI
3GPP TS 32.404 version 8.4.0 Release 8 21 ETSI TS 132 404 V8.4.0 (2009-10)

B.4 Enhanced GQM

The Goal, Question, Metric (GQM) method requires measurement user communities to help define goals and metrics.
This clause first presents the standard GQM method and then presents an enhanced GQM method, which provides the
measurement user communities a broader understanding of how metrics are used. The term 'Metric' in GQM means the
same as 'measurement'.

B.4.1 GQM Methodology

Basili and Weiss [23] and others originally proposed the GQM method. This methodology provides a systematic
approach for defining metrics that can be collected and analysed to determine whether or not a goal has been reached.
This methodology was originally created for quality assurance of software development processes, but has been applied
to other areas. GQM is comprised of the following three steps.

1. Identify and define Goals for a particular group;

2. Refine goals into quantifiable Questions;

3. Define Metrics that will answer the questions.

Goals are defined in terms of a purpose and a perspective. The purpose specifies the object to be analysed and why it
will be analysed. The perspective specifies the relevant aspects of the object and which measurement user community is
interested in the aspects.

Execution of the GQM methodology results in the formation of a GQM model. A GQM model contains the set of
defined Goals, Questions and Metrics. A GQM model provides trace-ability from the goals to the associated metrics.
Figure B.4.1.1 shows an example of a GQM model.

ETSI
3GPP TS 32.404 version 8.4.0 Release 8 22 ETSI TS 132 404 V8.4.0 (2009-10)

Metric a

Question 1
Metric b

Question 2
Metric c
Goal A

Question 3 Metric d

Question 4 Metric e
Goal B

Metric f
Question 5

Metric g

Figure B.4.1.1: GQM Model

GQM definition templates are often used to help produce consistent goal, question and/or metric definitions. An
example of a Goal template is shown below:

Purpose: To (characterize evaluate, predict, motivate, etc.) the (process product model, metric, etc.) in order to
(understand, assess, manage, engineer, learn, improve, etc.) it.
Example: To evaluate the system testing methodology in order to improve it.

Perspective: Examine the (cost, effectiveness, correctness, defects, changes, product metrics, reliability, etc.) from
the point of view of the (developer, manager, Network Operator, corporate perspective, etc.).
Example: Examine the effectiveness from the developer's point of view.

ETSI
3GPP TS 32.404 version 8.4.0 Release 8 23 ETSI TS 132 404 V8.4.0 (2009-10)

B.4.2 Enhanced GQM (EGQM) Methodology

As it stands, the GQM methodology works well for defining metrics, but falls short in several areas. The original GQM
methodology was enhanced to better fit within the wireless telecommunications industry for the following reasons:

a) Allow wireless measurement user communities to specify their needs at the beginning of the performance
measurement life cycle rather than waiting for product to be delivered.

b) Allow wireless measurement user communities to understand what performance measurements are being
designed for them in time to modify the associated collection, analysis and reporting processes.

c) Allow wireless measurement user communities to understand how they should analyse collected measurement
data and what actions they should take when analysis has been completed.

d) Provide criteria for rejecting unnecessary goals, useless measurements, or measurements that can not be properly
collected, analysed or understood.

e) Provide criteria for architecting metrics into the appropriate wireless network device (based on network traffic
capacity, device CPU and memory capacity, data collection capabilities, etc.).

f) Allow for consistent measurement definition by providing Enhanced GQM model definition and measurement
definition templates.

g) Help reduce development costs for Equipment Providers and reduce operational costs for the Network Operator.

The Enhanced GQM, or EGQM, methodology is comprised of the following four steps.

1. Identify and define measurement goals for a particular measurement user community;

2. Refine measurement goals into quantifiable problem scenarios;

3. Define measurements that will determine if the goal is being accomplished;

4. Define corrective actions.

EGQM's first and third steps are similar to GQM's first and third steps. EGQM's second step is different than GQM's
second step in that it focuses on problem scenarios associated with the goal rather than on questions associated with the
goal. Problem scenarios are descriptions of real world problems the measurement user community has or will
experience. Each problem scenario represents a particular aspect of the associated goal. Problem scenarios include
definitions of any formulas that will allow the measurement user community to analyse the problem scenario after
metric data has been collected from the field. EGQM's fourth step is new. Corrective actions are descriptions of what
the measurement user community should do based on analysis of metric data collected from the resulting wireless
network.

Execution of the EGQM methodology results in the formation of an EGQM model. An EGQM model contains the set
of defined goal, problem scenarios, metrics and corrective actions. An EGQM model also provides trace-ability from
the goals to the associated corrective actions. Figure B.4.2.1 shows an example of an EGQM model.

ETSI
3GPP TS 32.404 version 8.4.0 Release 8 24 ETSI TS 132 404 V8.4.0 (2009-10)

Metric a

Metric b Corrective Action 1

Problem Scenario 1

Metric c
Goal A

Problem Scenario 2 Metric d Corrective Action 2

Metric e Corrective Action 3

Figure B.4.2.1: EGQM Model

EGQM has definition templates for producing an EGQM model and for defining metrics. The EGQM model definition
template is shown in Table B1. The EGQM metric definition template that is useful for 3GPP SA5 activities is defined
in subclause 3.3 of the present document.

Table B.4.2.1: EGQM Model Definition Template

Goal Provides the name of goal and non-ambiguous definition of what needs to be accomplished.
Also provides the measurement user communities the goal is associated with.
Problem Scenario(s) Provides a description of the problem scenario associated with the goal. Contains a description
of how performance measurements will be used by the user in order to meet the goal.
Required Metric(s) Provides a list of metrics required to assess the problem scenario to see if the goal is being
accomplished.
Corrective Action(s) Provides descriptions of actions the user can execute based on data collected from the
wireless network. Contains descriptions of expected metric data values and how those values
work with the Problem Scenarios definitions.

As described in clause B.3, six measurement user communities have been defined for the wireless telecommunications
industries. EGQM supports all six communities. Representatives from each community participate in all four steps of
the EGQM methodology. This allows user communities to specify exactly what they need and/or want and to know
exactly how they will use the metrics before any software is developed. Participation in the EGQM process increases
Network Operator satisfaction through early definition of operational practices (including corrective actions) and
increases product knowledge within the Network Operator organization.

The EGQM model definition and metric definition templates provide the mechanism to reject unnecessary goals,
useless metrics, or metrics that can't be properly collected or computed. Reasons for the rejection of a goal include the
following:

a) Non-ambiguous goal definition could not be determined;

b) Problem scenarios could not be determined;

c) Definition of how performance measurement will be used within a problem scenario could not be determined;

d) Corrective actions could not be determined;

e) Metrics could not be defined to support problem scenario definitions;

f) Required metrics could not be architected into network devices for any of the following reasons:

1) Network device could not collect metric due to CPU utilization issues;

2) Network device could not collect and/or store metric due to memory issues;

3) Network could not support the uploading of measurement data from network devices to network manager;

4) Network manager could not collect and/or store measurement data due to memory issues.

ETSI
3GPP TS 32.404 version 8.4.0 Release 8 25 ETSI TS 132 404 V8.4.0 (2009-10)

B.5 Measurements Life Cycle Process

If the uses of performance measurements were confined to feature releases and occasional changes to those features,
then EGQM would suffice. However, user community needs evolve, operating conditions change, performance models
are validated, new services are introduced, etc. As these conditions change, performance measurements may need to
change. Such considerations point to the need for a complete measurements life cycle model.

A simple life cycle model to handle performance measurement changes is depicted in Figure B.5.1. New performance
measurement goal and metric definitions are provided through new features. These are made available with major
releases.

New Functional Obsolete

Modify Deleted

Figure B.5.1: Measurement Life Cycle

Performance measurements may need to be periodically reviewed. Goal and metric definition updates made during this
process are generally instantiated at major releases. When metrics are no longer useful they can be made obsolete and
eventually deleted. A waiting period between obsolescence and deletion allows user communities time to implement
and test out new metrics and analyses that are meant to replace existing metrics and analyses.

ETSI
3GPP TS 32.404 version 8.4.0 Release 8 26 ETSI TS 132 404 V8.4.0 (2009-10)

B.6 Conclusion
In the past, definition of performance measurements of wireless telecommunications networks was focused mainly on
satisfying the needs of the Equipment Vendor Performance Modelling and Development Engineering measurement user
communities. The needs of the wireless telecommunications Network Operator were not always addressed. The
Performance Measurement Definition process described in this annex addresses the needs of all measurements user
communities. The process also provides additional benefits, including the following:

• Allow measurement communities to specify their needs up front.

• Allow measurement communities to prepare for and modify their measurement monitoring and reporting
processes before product is released to them.

• Allow measurement communities to know what actions they need to perform when assessing collected
measurements.

• Provides method for rejecting unrealistic goals and measurements.

• Provides method for best architecting measurements into network devices.

• Provides method for producing consistent measurement definitions.

• Provides method for managing measurements life cycle including measurement creation, modification and
obsoletion.

The EGQM methodology may be used for:

• analyse and assess performance areas that are not well understood or are highly complex;

• non-straightforward cases where it is difficult to create useful measurement proposals;

• an understanding of real value is required before useful measurement proposals can be created;

• mine for missing measurements;

• mine for conflicting, overlapping, or existing measurements that are no longer useful.

In summary, the EGQM methodology may be used by any company to generate measurement definitions that can then
be contributed to 3GPP SA5 for potential inclusion in the present document.

ETSI
3GPP TS 32.404 version 8.4.0 Release 8 27 ETSI TS 132 404 V8.4.0 (2009-10)

Annex C (informative):
Change history
Change history
Date TSG # TSG Doc. CR Rev Subject/Comment Cat Old New
Mar 2006 SA_31 SP-060107 -- -- Split of 32.403-710 into four new TSs 32.404, 32.405, 32.406, 32.408. -- 1.0.0 7.0.0
Submitted to TSG SA #31 for Approval.
Jun 2006 SA_32 SP-060260 0001 -- Add features to the template to adapt ATM/IP PM definitions B 7.0.0 7.1.0
Jun 2006 SA_32 SP-060260 0002 -- Add IMS domain into measurement definition template B 7.0.0 7.1.0
Dec 2006 SA_34 SP-060725 0003 -- Allow different object classes using same measurement type in B 7.1.0 7.2.0
measurement template
Jun 2007 SA_36 SP-070276 0004 -- Add rule for subcounter naming of standardised causes without numeric F 7.2.0 7.3.0
value
Sep 2007 SA_37 SP-070613 0005 -- Change Routing Area to RA in private object class definition F 7.3.0 7.4.0
Dec 2007 SA_38 SP-070742 0006 -- Add private Object Class ObservedDestination - Align with 32.407 C 7.4.0 8.0.0
Mar 2008 SP-39 SP-080069 0007 -- Add rule for generic measurement definition C 8.0.0 8.1.0
Sep 2008 SP-41 SP-080465 0008 -- Add EPS into the performance measurement definition template in 32.404 B 8.1.0 8.2.0
Dec 2008 SP-42 SP-080846 0009 -- Enhancement of the measurement naming rules in the measurements B 8.2.0 8.3.0
definition template.
Sep-2009 SP-45 SP-090534 0010 -- Add missing NRMs into scope of Performance Measurements template F 8.3.0 8.4.0

ETSI
3GPP TS 32.404 version 8.4.0 Release 8 28 ETSI TS 132 404 V8.4.0 (2009-10)

History
Document history
V8.3.0 January 2009 Publication

V8.4.0 October 2009 Publication

ETSI