4 Detailed description of the measurement system for a PLMN

12.043GPPPerformance data measurementsTS

4.1 Introduction

Clause 3 of the present document describes the required functions for the administration of performance measurements and the retrieval of their results. For this purpose, the characteristics of measurement jobs and measurement results have been defined.

This part of the ETS explains how these requirements can be met using standard OSI systems management functions or SNMP management operations and, where necessary, tailoring them for PLMN use. In the following, managed object classes and their properties (attributes, notifications, etc.) to be used on the object oriented interface between OS and NEs for the execution of performance management functions are specified.

4.1.1 Basic measurement system functions

Before measurement data from the NEs can be collected and the results be forwarded to the OS, the measurement jobs that generate the required data shall be activated in the system. In object oriented terms, this corresponds to the instantiation of managed objects which model the measurement process. In order to control the measurement process, appropriate attributes of these objects shall be defined and have to be set to the required/desired values, either when the objects are created or during the lifetime of the objects. The specific attributes and their values will determine the measurement schedule, the measured network resources, the measurement types and the generation of scheduled result reports as well as the layout of the reports. Scheduled results can be forwarded to the OS using a notification that is defined specifically for this purpose as a part of the measurement object class definitions. A dedicated action will be used for requesting current results of active measurements.

4.1.2 Measurement Object Administration

The management of objects in an open system is performed utilising the internationally standardised "Common Management Information Service Element" (CMISE ITU-T Recommendation X.710 [13] or IETF RFC 1157 A Simple Network Management Protocol (SNMP) [30]). Managed objects for the execution of PLMN performance measurement functions can be instantiated and deleted using the M-CREATE and M-DELETE services or SNMP SET and GET operations. Reading and modifying attributes of these objects can be achieved employing the M-GET and M-SET services of CMISE or SET and GET operations of SNMP. The CMISE M-EVENT-REPORT service and SNMP TRAP is defined for the emission of notifications, while actions can be executed using the M-ACTION service.

Specific notifications defined in the OSI object management function (see ITU-T Recommendation X.730 [15]) are used to notify the OS of the creation and deletion of managed objects and of the change of attribute values. For the formal definition of the PLMN performance management object model, refer to annex C.

The measurement job can be ideally modelled by the managed object class "simpleScanner" as defined in ITU-T Recommendation X.738 [19]. The "simpleScanner" is derived from the "homogeneousScanner" object class (see ITU-T Recommendation X.738 [19]), which in turn is a specialisation of the "scanner" class of managed objects (see ITU-T Recommendation X.738 [19]). The "simpleScanner" object has attributes to determine:

– the measurement types;

– the measured network resources;

– the recording periods; and

– the reporting requirements;

of the measurement job. The "simpleScanner" generates measurement result reports in the form of notifications, according to the attributes that prescribe the reporting requirements. The measurement transfer requirements are not modelled in the scanner objects, since generic and general services are used (see subclause 4.3.2 and annex D).

4.2 Modelling of measurement jobs

A measurement job is represented by a "simpleScanner" object. The following subclauses define how the measurement job characteristics are mapped onto the properties of the "simpleScanner" managed object class, and how the measurement types of a measurement job are modelled in the PLMN performance measurement system.

4.2.1 Measurement job characteristics Measurement Function

Every measurement job collects measurement data from selected measurement types across one or more network resources of the same type. The selected measurement types shall be identical throughout all network resources observed by a measurement job. For each network resource, the related measurement types have been grouped in one or more measurement functions.

Measurement functions, are modelled by various "measurementFunction" object classes (see annex C). The measurement types for the PLMN performance measurement system are defined in annex B, and their result values are included as attributes in the appropriate "measurementFunction" object class. In case the measurement type is a counter, the attribute represents the counter value as is. In all other cases, the attribute delivers a calculated value (e.g. a mean), over the observed period. The "measurementFunction" objects are contained in the objects that represent the network resource to which the measurement types included in the "measurementFunction" refer. All measurement types that relate only to a network resource alone are grouped into one "measurementFunction" class which is unique for that network resource. Measurement types that are related to the network resource and the same type(s) of adjacent resource(s) (e.g. Handover neighbour cell) are also grouped into one unique type of measurement function which may exist once or more per instance or per set of that adjacent resource(s). The instances of the adjacent resources that are to be addressed by the measurement function are identified by the values of attributes which are part of that specific "measurementFunction" object class definition.

Measurement types that belong together are grouped together in the same package (e.g. "immediateAssignmentProcedurePackage" has attributes "attemptedImmediateAssignmentProcedures" and "successfullImmediateAssignmentProcedures" – for details refer to annex C). Since all measurement types defined in annex B may or may not be supported by the system, all packages of a "measurementFunction" which contain measurement attributes are conditional. A "measurementFunction" needs to be created before a "simpleScanner" can scan its attributes, i.e. before actual measurements can be taken. The create request from the OS shall specify the values of attributes that identify adjacent resources (like Handover neighbour cell), if any, but it may not specify any measurement attributes of the "measurementFunction" object. Upon creation of a "measurementFunction" object, the system will determine the measurement packages that are included in the object according to the measurement types the system supports. If multiple instances of the same "measurementFunction" object class are created, the packages included in the various instances may be different from instance to instance since the system may have restrictions on how many measurement packages of the same type it supports. The OS can inquire the measurement types supported by a "measurementFunction" object from the system, by reading the "packages" attribute or the attribute list of the object (see ITU-T Recommendation X.721 [14]). Unlike the former operation, the latter, however, will also return values of the measurement attributes which are not expected to be meaningful at this time (see below). Deletion of the "measurementFunction" will render the measurement types that correspond to the "measurementFunction" attributes unavailable to the OS. Creation and deletion of a "measurementFunction" will be notified to the OS using the object creation and deletion notifications as defined in ITU-T Recommendation X.730 [15].

Each measurement job may collect data from one or more measurement types across one or more network resources, i.e. a "simpleScanner" object may make a choice of one or more "measurementFunction" instances and scan the same set of attributes across all selected measurement functions. For this purpose, it can scope the set of measurement functions that are eligible for inclusion in the observation, and it may select measurement functions using filtering criteria (similar to the concept of scoping and filtering as described in ITU-T Recommendation X.710 [13]). Alternatively, it can use an explicit list of "measurementFunction" objects for scanning. The "simpleScanner" does not explicitly identify the network resource(s) it measures. Instead, this information is derived from the containment relationship between the selected "measurementFunction" instances and the objects that model the network resources, and, where necessary, through specific attributes of the "measurementFunction" objects that identify adjacent resources. In principle, a "simpleScanner" is able to scan attributes of any defined "measurementFunction", but for the purpose of the present document, each "simpleScanner" instance is only required to scan attributes of "measurementFunction" objects that are contained in the same "xxxFunction" object as the "simpleScanner" itself, where "xxx" stands for "bss", "msc", "hlr", "vlr", "eir" or "smsc", respectively (see figure C.1).

All measurement attributes of any "measurementFunction" should only be read by a "simpleScanner" that has been instantiated for this purpose. By definition they can be read directly by systems management protocol, but their values are not expected to have any meaning apart from the scan. Therefore, the system will not return the "attribute list" in the create reply, and the "attributeList" will also not be included in the object creation notification. Measurement schedule

The measurement schedule specifies the time frame during which the measurement job will be active. The schedule consist of a measurement start- and stoptime and one or more recording intervals which may repeat on a daily or weekly basis. The semantics of the scheduling parameters are described in subclause

All of the above parameters are formally defined as attributes of conditional packages of the "simpleScanner" managed object class. The starttime and stoptime are included in the "duration" package and indicate, if the package is present, the specific point in time at which the "simpleScanner" will become active or inactive, respectively. If the "simpleScanner" is instantiated after the specified starttime, this will have the same effect as if no starttime was specified (see subclause

The optional recording intervals, if specified, further restrict the time during which the "simpleScanner" actively collects measurement data within the time frame determined by the duration package. The "dailyScheduling" package may be used to define one or more intervals during each day. Alternatively, the "weeklyScheduling" package can be used to define individual intervals for each day of the week. The recording interval should be a multiple of the granularity period (if non-zero) and the start- and endtimes shall be aligned with granularity period boundaries for the system to accept the values.

It is possible to create several "simpleScanner" objects which scan the same attributes of the same "measurementFunction" instances according to different recording intervals. In this case it is, however, required that these intervals do not overlap. Consequently, if it is required to measure the same measurement type with overlapping schedules, it is necessary to have an appropriate number of instances of the same "measurementFunction" available which all support the required attributes (see subclause

For the definition of the syntactical and additional behavioural aspects of the above parameters, refer to ITU-T Recommendation X.721 [14] and ITU-T Recommendation X.738 [19]. Granularity period

The granularity period defines the periodicity of the generation of results by a measurement job within the timeframe specified in the scheduling attributes. The granularity period of a measurement job is determined by the value of the "granularityPeriod" attribute of the "simpleScanner". The present document requires, as a minimum, the support of granularity periods of 5 minutes, 15 minutes, 30 minutes and 60 minutes.

The value of this attribute shall specify the required value in minutes. The underlying International Standards allow the modification of the "granularityPeriod" attribute, but for an implementation claiming conformance to the present document, it is not required that its value be changeable during the lifetime of the "simpleScanner" object. If this value is 60, measurement results will be generated every full hour. If the value is 30, results will be generated every 0 and 30 minutes past the full hour. If the value is 15, result output will occur every 0 minutes, 15 minutes, 30 minutes and 45 minutes past the full hour, and finally, if the value is 5, the "simpleScanner" will generate output every 5 minutes, synchronised on the full hour. Again, measurement results are only reported at the end of each granularity period within the recording interval. Due to these definitions, synchronisation of granularity periods through the conditional "periodSynchronisationPackage" of the "simpleScanner" is not supported in the scope of the present document.

If periodical generation of results is not required from a "simpleScanner" instance, this can be achieved by specifying the value 0 for the "granularityPeriod" attribute. In this case, it will only be possible to request current measurement results from the "simpleScanner" (see below). Scan reports

At the end of each granularity period within the measurement schedule, the "simpleScanner" will emit a "scanReport" notification, defined in ITU-T Recommendation X.738 [19], which contains the measurement results generated by the scanner at the end of that granularity period. The information in the notification shall comprise:

– the managed object class and managed object instance of the "simpleScanner" that emitted the notification, plus the notification type (i.e. "scan report");

– a time stamp that indicates the time at which the measurement results were taken, i.e. the end time of the respective granularity period;

– for each "measurementFunction" object from which measurements were taken by the scanner, a list of measurement attribute values and optional attribute identifiers, plus a suspect flag for each attribute that indicates the validity of the result value. Missing data is indicated in the list. The time stamp that indicates the time offset forward from scan initiation until the value of the measurement attribute was actually taken is not supported in the PLMN measurement system,

– for an incomplete scan the reason why the scan could not be completed.

The definition of the "scanReport" notification in ITU-T Recommendation X.738 [19] provides some flexibility with respect to the actual layout of the report. In the PLMN performance measurement system, the following options can be selected:

– suppressing the reporting of the identification of the "measurementFunction" object from which the measurements reported in the notification were collected. This is only useful when the identification of the "measuremntFunction" can be determined by other means, or if the identification is not required by the OS (e.g. when the statistics are to be calculated);

– omitting the attribute identifiers from the report. In this case, the attribute values are reported in an agreed order, which is defined by an attribute of the "simpleScanner";

– measurement values that are identical throughout all "mesurementFunction" instances from which the scanner takes measurements may be included in the report only once.

ITU-T Recommendation X.738 [19] defines in detail the attributes of the "simpleScanner" which are used to control the above features. Additional options of ITU-T Recommendation X.738 [19] which are not listed here are not supported in the PLMN performance measurement system (see conformance requirements in subclause 4.4).

4.2.2 Scanner state and status attributes

State and status indicators are defined for the measurement job in subclause 3.2.2 of the present document. These are modelled through appropriate attributes which reflect the state and status of the "simpleScanner" object. These attributes are: administrativeState, operationalState and availabilityStatus.

administrativeState: The administrativeState attribute is used to suspend and resume the scanning performed by the "simpleScanner". This attribute can be altered by means of CMISE M-SET service or SNMP SET operation for the applicable "simpleScanner" object instance.

operationalState: The operationalState attribute represents the operational capability of the scanner to perform it’s functions.

availabilityStatus: The availabilityStatus attribute reflects whether or not the simpleScanner object instance is active according to the measurement schedule.

Any changes to the values of the administrativeState and the operationalState attributes will be reported to the OS using the "stateChange" notification, as defined in ITU-T Recommendation X.731 [16].

Further details about these attributes can be found in ITU-T Recommendation X.738 [19].

4.2.3 Scanner administration

The generic CMISE services M-CREATE, M-DELETE, M-GET and M-SET or SNMP SET and GET, applied to a simpleScanner managed object instance respectively represent creation, deletion, display and modification of a measurement job. A CMISE M-ACTION primitive or SNMP SET with a specific action type for activating a scan report is defined for the retrieval of the current values of measurement results.

Creating a "simpleScanner": A "simpleScanner" can be created by issuing an appropriate M-CREATE request or SNMP SET request. On creation of the object, all attribute values have to be supplied that determine:

– the selection of "measurementFunction" instances and their attributes which shall be measured;

– the schedule of the "simpleScanner"; and

– the reporting requirements;

as defined in previous subclauses. The "measurementFunction" objects shall be created before the scanner can be instantiated, and the measurement attributes specified in the scanner shall be present in the selected "measurementFunction" instances, for the scan to return its results. For each object that does not exist, an empty report shall be returned and for each attribute that does not exist, an empty value shall be returned within the report. The relationship between the scan attributes and the scanner is explained in ITU-T Recommendation X.738 [19].

Modifying "simpleScanner" attributes: Modification of "simpleScanner" attributes may be requested by the OS during the lifetime of a scanner, using the CMISE M-SET or SNMP SET operation. The conditions for modification of attributes of the "simpleScanner" are specified in ITU-T Recommendation X.738 [19] and ITU-T Recommendation X.738 [19], but some additional restrictions, defined in the present document with respect to the changeability of "simpleScanner" attributes, apply in the PLMN performance measurement system.

Displaying scanner objects: The system operator can get a list of all "simpleScanner" objects that currently exist in the system, together with all available information as stored in the NE. This information consists of the data that was supplied on creation/modification of the objects and the values of the state and status attributes of the "simpleScanner" objects. The CMISE M-GET or SNMP GET operation can be used to selectively retrieve the required information from the system. For details see ITU-T Recommendation X.710 [13].

Deleting a "simpleScanner": A "simpleScanner" instance is automatically deleted by the system when the scheduled endtime is reached and all result reports, either scheduled or on request have been generated. A "simpleScanner" object can also be deleted by manual intervention, utilising the CMISE M‑DELETE or SNMP SET operation, at any time. When deleted, the measurement process associated with the scanner is stopped, and all allocated resources are released.

Suspending/resuming scanner operation: On normal operation, the "simpleScanner" collects measurement data from the selected "measurementFunction" objects according to the values of the "simpleScanner" attributes. However, the system operator may decide for some reason to discard temporarily the collection of measurement data (e.g. in case of system overload or congestion, measurement results not used, …). The system operator therefore is able to suspend scanner operation at any time, setting the administrativeState attribute to "locked". This implies that the "simpleScanner" instance remains in the system, but no measurement gathering and result reporting activities are performed for this scanner. When scanner operation is resumed, i.e. the administrativeState is "unlocked", measurement data collection and result reporting is started again at the next full granularity period within the measurement schedule.

Requesting current measurement result values: The system operator may for some reason be interested in the current values of the measurement results of a particular measurement process, independently of the scheduled data collection and reporting of the respective scanner, e.g. for tracing the increment of some of the measurement attributes. To this aim, the "activateScanReport" CMISE M-ACTION or SNMP GET is used as defined in ITU-T Recommendation X.738 [19]. The action reply will return current results according to the attributes of the scanner that govern the generation of the "scanReport" notification, i.e. the format of the reply is identical to that of scheduled reports generated by the scanner. Any such request does not affect the underlying measurement process, and may only be issued when the scanner is operating according to its schedule and not suspended (i.e. "offduty" not present in the availability status , administrative state equals "unlocked"), otherwise an error will be returned.

4.3 Modelling of measurement results

Each measurement produces a result at the end of the granularity period or on request of the OS. Annex B provides for each measurement type a description of the expected measurement result. Annex C contains the formal definition of the attribute that represents the measurement type.

4.3.1 Characteristics of the result report

A scheduled result report is generated in the form of a "scanReport" notification. Current measurement results requested by the OS using the "activateScanReport" action will be supplied by the system in the reply to the request. All measurement attributes that are observed by a "simpleScanner" object are included in a single report or action reply, respectively. The layout of the two result reports – notification or action reply – is identical, as far as the contained measurement information is concerned. For details on the result report characteristics, please refer to the previous subclauses.

4.3.2 Result report transfer control

Result reports from a "simpleScanner" object are either produced according to the measurement schedule (notification) or on receipt of an explicit request (action) from the OS. There are no mechanisms to control the forwarding of the reply to that request (action reply), or to store it in the NE. There are, however, functions to determine the forwarding, local storage in the NE and deferred retrieval of the "scanReport" notification. These functions are described in the following paragraphs.

The forwarding of notifications can be controlled by the OS via "Event Forwarding Discriminator" (EFD) objects, as defined in ITU-T Recommendation X.734 [17]. For each EFD, the OS can specify a discriminator construct which will be applied as a filter to any event report generated in the system. If an event report passes the filter, a notification will be forwarded to the OS accordingly. The following filter criteria are allowed in an EFD for the PLMN performance measurement system:

– the event type, which allows to enable or disable completely the forwarding of scan report notifications;

– the "simpleScanner" managed object instance, which allows to restrict forwarding of result reports to those that are generated by specific scanner instances;

– the time stamp contained in the scan report ("scanInitiationTime"), which allows to selectively enable the forwarding of result reports that were generated at a specific time or during specific periods of time;

– any operation on the above attributes in any combination.

Measurement result reports can be stored in the NE. This property is modelled through the managed object class "log", as specified in ITU-T Recommendation X.721 [14] and "log control function" as specified in ITU-T Recommendation X.735 [18]. The storage of event reports in the "log" can be controlled through a discriminator construct, similar to the event forwarding control. The present document requires for the "log" discriminator construct the same criteria as for the EFD discriminator construct.

All scan report notifications that pass the discriminator construct of the "log" will create a "scanReportRecord" object which is contained in the log. These records can be retrieved by the OS at any time, as defined in ITU-T Recommendation X.735 [18] and ITU-T Recommendation X.710 [13], using either CMISE, SNMP, FTP or using FTAM (see annex D). The use of FTAM or FTP services is especially suitable for bulk data transfer. From the common procedures defined in GSM 12.00 [8] for data transfer in a PLMN, only the method that provides logged information into file(s) can be used for the measurement system. The "resultType" requested in the action will identify the appropriate log instance(s) as the source of the measurement data, and optionally additional filter criteria which determines the actual records to be put into the file(s) can be supplied. The filter criteria that shall be supported are identical to those defined for the discriminator construct of the logs. On receipt of the action, the requested records will be put into one or more files, which will then be made available to the OS. The format of the records in the file shall be according to the definition of the "scanReportRecord" as given in ITU-T Recommendation X.738 [19].

Since all measurement attributes and the identification of the network resource observed by a "simpleScanner" are included in a single attribute of the result reports, it is not possible to filter on the measured resource or the measurement type. If the selective forwarding/logging/retrieval of measurement results referring to individual network resources or individual measurement types is required by the system operator, then "simpleScanner" objects shall be instantiated such that the scanner identity will implicitly identify the measured resource and measurement types, i.e. the scanner attributes should be set such that the scanner observes only the specific resources and/or the specific measurement attributes which shall be filtered, according to the system operator’s requirements.

4.4 Conformance requirements

In the following subclause, conformance requirements for object classes, notifications and actions defined in ITU-T Recommendation X.738 [19] are specified. In cases where requirements in the present document restrict options of ITU-T Recommendation X.738 [19], like e.g. changeability of attribute values, the conditions of the present document shall apply.

4.4.1 Simple scanner

The following subclause lists the attributes and packages of the "simpleScanner", as defined in ITU-T Recommendation X.738 [19], and those inherited from the "scanner" as defined in ITU-T Recommendation X.738 [19]. It specifies which properties shall be supported to conform with the present document.

Mandatory packages:


scannerId: this attribute identifies a "simpleScanner" instance. It is a mandatory attribute of the "simpleScanner" managed object class and will be supported in the PLMN measurement system.

granularityPeriod: this attribute specifies the granularity period of the scanner, as defined in subclause It is a mandatory attribute of the "simpleScanner" managed object class and will be supported in the PLMN measurement system.

administrativeState and operationalState: (see subclause 4.2.2) are mandatory attributes of the "simpleScanner" managed object class and will be supported in the PLMN measurement system. Their semantics are defined in ITU-T Recommendation X.738 [19].


scanAttributeIdList: this attribute is interrelated with the "numericAttributeIdArray" attribute of the "simpleScannerPackage". It is supported in the PLMN measurement system according to the definitions of subclause and ITU-T Recommendation X.738 [19].


numericAtributeIdArray: this attribute is interrelated with the "scanAttributeIdList" attribute of the "homogeneousScannerPackage". It is supported in the PLMN measurement system according to the definitions of subclause and ITU-T Recommendation X.738 [19].

suppressObjectInstance: this attribute determines whether or not the object instance of the observed measurement function is included in the measurement results. It is supported in the PLMN measurement system according to the definitions of subclause and ITU-T Recommendation X.738 [19].

activateScanReport: this action is supported in the PLMN measurement system (see below).

scanReport: this notification is supported in the PLMN measurement system (see below).

Conditional packages:


availabilityStatus: this attribute is supported in the PLMN measurement system (see subclause 4.2.2) according to the definition of ITU-T Recommendation X.738 [19].


startTime and stopTime: these attributes constitute the start- and stoptime of the scanner. They are supported according to subclause and ITU-T Recommendation X.738 [19].


intervalsOfDay: this attribute defines the periods within a day during which the scanner actively collects measurement data. It is supported according to subclause and ITU-T Recommendation X.738 [19].


weekMask: this attribute defines, for each day of the week, the periods during which the scanner actively collects measurement data. It is supported according to subclause and ITU-T Recommendation X.738 [19].


the support of this package is not required in the PLMN measurement system.


the support of this package is not required in the PLMN measurement system. Synchronisation of granularity periods is described in subclause


this package contains the object creation and object deletion notifications. Both are required in the PLMN measurement system.


this package contains the attribute value change notification. It is required in the PLMN measurement system.


this package contains the state change notification. It is required in the PLMN measurement system.


timeStampReportMode: this attribute specifies the time stamping requirements for the measurement results. The value "1" ("globalTimeStampOnly") shall be used.

scopedSelectionPackage and managedObjectInstanceSelectionPackage

either one of these packages is present in any scanner instance. The attributes contained in the packages determine the measurement functions selected for observation by the scanner. They are supported according to the definitions of ITU-T Recommendation X.738 [19].


the support of this package is not applicable in the PLMN measurement system, since the observed "measurementFunction" managed objects do not contain any time attributes.


onceReportAttributeIdList: this attribute contains a list of attribute identifiers. The values of these attributes shall be included in a result report only once if they are identical throughout all "measurementFunction" objects observed by the "simpleScanner". It may be supported in the PLMN measurement system as an option, see ITU‑T Recommendation X.738 [19].

4.4.2 Scan report record

The "scanReportRecord" managed object class will be supported in the PLMN measurement system as defined in ITU‑T Recommendation X.738 [19] and ITU-T Recommendation X.721 [14].

4.4.3 Scan report notification

The "scanReport" notification will be supported in the PLMN measurement system as defined in subclause and ITU-T Recommendation X.738 [19].

4.4.4 Activate scan report action

In the scope of the present document, there are no specific conformance requirements for the action request. The action reply will be supported according to the requirements for the scan report notification.

4.5 Application Context

The Application Context Name of the 12.04 application context shall have the following object identifier value:

{gsm-OM-DomainId gsm-12-04 (4) protocolSupport (1) applicationContext (0) gsm-Management (0)}

and the following object description value:

"gsm12.04 management application context"

The object identifier gsm-OM-DomainId is defined in the GSM 12.30 (ETR 128) [11].