5 Performance management requirements

32.1043G Performance Management3GPPRelease 1999Telecommunication managementTS

5.1 Introduction

This subclause describes all basic functions to allow the system operator to have measurement data collected by the NEs and to forward the results to one or more OS(s), i.e. EM or NM. All functions are gathered to provide the system operator with the means to administer, plan, execute measurements and to store and evaluate the measurement results.

5.1.1 Basic functions

The Performance Management concept as applicable in this specification is based on the general framework for 3G-telecom management as outlined in 3GPP TS 32.101 [1] and 3GPP TS 32.102 [2]. As an example, figure 1 outlines this concept in the context of the UTRAN.

As the O&M functions for NodeB are partitioned into Logical and Implementation Specific O&M (3GPP TR 32.800 [9]), it should be understood that the functionalities described in the present document are completely within the scope of Implementation Specific O&M. This implies that no information pertaining to measurement administration and result transfer, as described here, is exchanged between the RNC and NodeB via the Iub interface. Such information may, however, be sent or received by the NodeB over the Iub physical bearer (3GPP TS 25.442 [4]).

The basic requirement from an NE for measurements is to collect data according to the definition of the measurements and to return results to an OS (EM or NM).

The EM shall be able to administer the measurements, e.g. create/delete measurement jobs and define their schedules. The EM and/or the NM can retrieve the measurement results via appropriate interfaces. This data may be used in its original form or processed according to the system operator requirements.

A standard set of measurements that generate the required data is defined in annex C of the present document. However, a significant number of additional measurements is expected from real implementations. These will mainly consist of measurements for the underlying technologies, which are not 3G specific, such as ATM or IP, but is also due to specific vendor implementations. While the NM interface (Itf-N) for result transfer of both standard and non-standard measurements is fully standardised in annexes A and B of the present document, the interface between EM and NE is implementation specific.

The data collected in the NE will be made available according to the schedule defined by the measurement parameters. With respect to the retrieval of this data, the EM can control:

– the transfer of scheduled reports from the NE to the EM;

– the storage of scheduled reports in the NE; and

– deferred retrieval by the EM of scheduled reports stored in the NE.

Depending on the implementation option chosen for the NM interface (cf. subclause 4.2.4), the EM and/or NM may be involved in the control of the measurement result transfer to the NM. For details see subclause 5.3.2 and annex B.

5.1.2 Measurement administration

(Performance) measurement administration functions allow the system operator, using functions of the EM, to determine measurement data collection in the network and forwarding of the results to one or more OS(s).

A (performance) measurement concept covers:

1) measurement data collection requirements:

Measurement types. Corresponds to the measurements as defined in annex C, i.e. measurement types specified in the present document, defined by other standards bodies, or manufacturer defined measurement types;

Measured network resources. The resource(s) to which the measurement types shall be applied have to be specified, e.g. one or more NodeB(s);

Measurement recording, consisting of periods of time at which the NE is collecting (that is, making available in the NE) measurement data.

2) measurement reporting requirements:

– the measurement related information to be reported has to be specified as part of the measurement. The frequency at which scheduled result reports shall be generated has to be defined.

3) measurement result transfer requirements:

– measurement results can be transferred from the NE to the EM according to the measurement parameters, and/or they are stored locally in the NE and can be retrieved when required;

– measurement results can be stored in the network (NEs or EM) for retrieval by the NM when required.

A (performance) measurement job, covers the measurement data collection and measurement reporting requirements, as described in points 1 and 2 above. It is up to the implementation whether requirements for the result transfer or the local storage of results are specified within the measurement job, particularly since the use of standard protocols, such as FTP, is foreseen.

A measurement job can be created, modified, displayed or deleted by the EM. In addition, measurement job activities in the NE can be suspended and resumed on request of the EM.

The system operator shall specify the required measurement parameters upon initiation of a measurement job. These parameters consist of, among others, recording schedule, granularity, and measurement type(s).

5.2 Measurement jobs

When defining a measurement job, the following aspects have to be considered:

5.2.1 Measurement job characteristics

5.2.1.1 Measurement types

Every measurement job consists of one or more measurement types (as defined in annex C), for which it collects measurement data. The measurement type(s) contained in a job may apply to one or more network resources of the same type, e.g. a measurement job may be related to one or several NodeB(s). A measurement job will only produce results for the measurement type(s) it contains.

5.2.1.2 Measurement schedule

The measurement schedule specifies the time frames during which the measurement job will be active. The measurement job is active as soon as the starttime – if supplied in the schedule – is reached. The system shall support a job starttime of up to at least 30 days from the job creation date. If no starttime is provided, the measurement job shall become active immediately. The measurement job remains active until the stoptime – if supplied in the schedule – is reached. If no job stoptime is specified the measurement job will run indefinitely and can only be stopped by EM intervention, i.e. by deleting or suspending the measurement job.

The time frame defined by the measurement schedule may contain one or more recording intervals. These recording intervals may repeat on a daily and/or weekly basis and specify the time periods during which the measurement data is collected within the NE. A recording interval is identified by an interval starttime and an interval endtime, which lie between 00.00 and 24.00 hours, aligned on granularity period boundaries. Thus the length of a recording interval will be a multiple of the granularity period. For a single measurement type it shall be possible to specify several measurement jobs with different recording intervals as long as these intervals do not overlap. If it is required that a measurement type be observed by multiple measurement jobs with overlapping schedules then the system shall support multiple instances of that measurement type.

5.2.1.3 Granularity period

The granularity period is the time between the initiation of two successive gatherings of measurement data.
Valid values for the granularity period are 5 minutes, 15 minutes, 30 minutes, 1 hour. The minimum granularity period is 5 minutes in most cases, but for some measurements it may only make sense to collect data in a larger granularity period. The granularity period shall be synchronised on the full hour, but its value is not required to be changeable during the lifetime of the job.

5.2.1.4 Measurement reporting

Each measurement job running on an NE produces scheduled measurement reports at the end of each granularity period, and contains the information as requested by the system operator. This information consists of:

– an identification of the measurement job that generated the report;

– an identification of the involved measurement type(s) and the measured network resource(s) (e.g. NodeB);

– a time stamp, referring to the end of the granularity period;

– for each measurement type, the result value(s) and an indication of the validity of the result value(s);

– an indication if the scan is not complete, and the reason why the scan could not be completed.

The exact layout of the measurement result reports generated by the NEs may be vendor specific. For the result file transfer to the NM via Itf-N, however, annex A of the present document defines in detail which information of the report is included in the result files, as well as the file format.

5.2.2 Measurement job state and status attributes

According to the OSI systems management concept, the state of a resource is reflected in indicators (attributes). Status attributes are provided to qualify these state attributes. Full details are provided in ITU-T Recommendation X.731 [6]. As for a measurement job, the following information is provided:

Administrative state: The administrative state attribute allows the system operator to permit or prohibit administratively the execution of the measurement job (suspend/resume).

Operational state: The operational state attribute reflects the operability of the measurement job.

Availability status: The availability status attribute denotes particular conditions applicable to the measurement job. It indicates:

– whether or not the measurement job is collecting measurement data according to its schedule;

– if, for whatever reason, some of the requested measurement data cannot be collected by the measurement job, in particular whether the measurement schedule inhibits the collection of measurement data.

It should be noted that the application of OSI state and status attributes within the 3G-measurement concept does not enforce the provision of an OSI interface for measurement administration.

5.2.3 Measurement job administration

Measurement jobs can be administered by the EM according to the following stipulations.

Creating a measurement job: On creation of a measurement job, all information has to be supplied in order to collect the required data from the selected network resources as specified by the measurement job characteristics (see subclause 5.2.1).

Modifying a measurement job: In general, the modification of measurement job parameters may be requested by the EM during the lifetime of a measurement job when the job is suspended (explained below).

Displaying a measurement job: The system operator shall be able to get a list of all measurements that are currently defined, together with all available actual information as stored in the NE. This information consists of the data that is supplied on creation/modification and the actual state and status information of the measurement job.

Deleting a measurement job: A measurement job is automatically deleted by the system when it reaches the job endtime and all scheduled measurement reports have been generated. A created measurement job can also be deleted by manual intervention at any time. When deleted, the measurement process associated with the job is stopped, and all allocated resources are freed.

Suspending/resuming a measurement job: On normal operation, the measurement job collects measurement data within the NE according to the actual values of the measurement job parameters. 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 a defined measurement job at any time, using the Administrative State. This implies that the measurement job definition remains in the system, but that no measurement gathering activities are performed for this job. When the measurement job is resumed, measurement data collection is started again at the next granularity period within the measurement schedule.

5.3 Measurement results

5.3.1 Measurement result characteristics

During its specified recording intervals, each measurement job produces a result at the end of the granularity period if it is not suspended. Annex C provides for each measurement type that is specified within the present document a description of the expected measurement result.

Measurement results for all measurements of a particular measurement job are gathered in a single report at the end of the granularity period. The report may contain – in addition to the specific measurement results – fixed information, which is global for all measurement results associated with that measurement job, such as an identification of the involved network resources and a time stamp referring to the time at which the NE started collecting the measurement results. If measurement results are sent to the EM then the exact format may be vendor specific. For details about the standard file format for the transfer of measurement results to the NM via Itf-N see annex A of the present document.

Once the result reports have been generated, they shall be stored locally within the NE if so requested by the EM/system operator. The storage capacity and duration as well as the method how the data may be deleted from the NE will be implementation dependent.

If some or all of the requested measurement data cannot be collected by a measurement job (administrative state = locked, operational state = disabled, see subclause 5.2.2), this shall be indicated in the measurement report, cf. subclause 5.2.1.4. In extreme cases, no report at all can be generated by the measurement job. This means that the destination of the result report (EM and/or NM) shall be capable of coping with missing or incomplete measurement reports.

5.3.2 Transfer of measurement results

During the recording intervals specified for a measurement job, scheduled measurement reports are generated at the end of each granularity period if the measurement job is not suspended. These reports can be transferred to the EM in either of two ways:

1) immediate notifications:

The reports are automatically forwarded to the EM at the end of the granularity period.

2) deferred retrieval:

The reports are stored locally in the NE, where they can be retrieved when required.

For each individual report, the transfer of measurement results in either one or both ways is to be established by the system operator, i.e. under the control of the EM. The actual control of the result transfer and the mechanisms applied may be implementation specific.

Each implementation shall support a file transfer facility to an external OS (i.e. not supplied by the NE vendor), such as an NM. This facility shall be implemented using either the FTAM [7] or (T)FTP protocol. This interface may be located either in the NEs or the EM, as chosen by the vendor. As a result, it may not at all be necessary to transfer measurement result reports to the EM, if:

– the NM interface is implemented in the NEs, and

– the Operator chooses to post-process measurement results only in the NM.

Details of the file format to be used on the NM interface can be found in annex A of the present document. The measurement report file conventions and transfer procedure are specified in annex B.

Annex A (normative):
Measurement Report File Format

This annex describes the format of measurement result files that can be transferred from the network (NEs or EM) to the NM. Two alternative format definitions are specified, one using ASN.1 with binary encoding (BER), the other applying XML, which is ASCII based. Each 3G-system implementation complying with the present document shall support at least one of the two alternatives.

Both the ASN.1 and XML file format definitions implement the measurement result structure and parameters defined in subclauses 5.2 and 5.3 of the present document, except from the measurement job id, which is only needed to correlate measurement result reports with measurement jobs within the area of measurement administration (see subclause 5.2.1.4). The two defined file format definitions correspond 1:1 to each other. This implies that the value ranges and size constraints defined in the ASN.1 definition shall also be valid for implementations of the XML format definition. From that perspective, the two format definitions can be regarded as two different instances of the same single format.

The following conditions have been considered in defining this file format:

  • Since the files are transferred via a machine-machine interface, the files applying the format definitions should be machine readable using standard tools;
  • The file format should be independent of the data transfer protocol used to carry the file from one system to another;
  • The file format should be generic across 3G systems;
  • The file format should be flexible enough to include all possible measurement types, i.e. those specified within annex C as well as measurements defined within other standards bodies, or vendor specific measurement types;
  • The file format should not impose any dependency between granularity periods for the generation of measurement results and file upload cycles for the file transfer from the network to the NM;
  • The file format should be flexible enough to support both the NE-based and the EM-based approaches, as discussed in annex B.1.1 of the present document;
  • The file format should be usable for other interfaces than Itf-N if required. The measurement file header could be augmented to indicate this other usage, however this would be a non-standard extension. In the ASN.1 file format definition, this is accommodated by the use of the ellipse notation. XML allows such additions through extra DTDs, provided by the definer of the non-standard extension.

A.1 Parameter description and mapping table

Table A.1 maps the tags defined in the ASN.1 file format definition to those used in the XML file format definition.
It also provides an explanation of the individual parameters. The XML tags defined in the DTD (see subclause A.3.1) have been kept as short as possible in order to minimise the size of the XML measurement result files.

Table A.1 Mapping of ASN.1 Measurement Report File Format tags to XML tags

ASN.1 Tag

XML

tag

Description

MeasDataCollection

mdc

This is the top-level tag, which identifies the file as a collection of measurement data. The file content is made up of a header (“measFileHeader”), the collection of measurement result items (“measData”), and a measurement file footer (“measFileFooter”).

measFileHeader

mfh

This is the measurement result file header to be inserted in each file. It includes a version indicator, the name, type and vendor name of the sending network node, and a time stamp (“collectionBeginTime”).

measData

md

The measData construct represents the sequence of zero or more measurement result items contained in the file. It can be empty in case no measurement data can be provided. The individual measData elements can appear in any order.

Each measData element contains the name of the NE (“nEId”) and the list of measurement results pertaining to that NE (“measInfo”).

measFileFooter

mff

The measurement result file footer to be inserted in each file. It includes a time stamp, which refers to the end of the overall measurement collection interval that is covered by the collected measurement results being stored in this file.

fileFormatVersion

ffv

This parameter identifies the file format version applied by the sender. The format version defined in the present document shall be “1” for both the XML and ASN.1 formats alike.

senderName

sn

The senderName uniquely identifies the NE or EM that assembled this measurement file, according to the definitions in 3GPP TS 32.106. It is identical to the sender’s nEDistinguishedName. The string may be empty (i.e. string size =0) in case it is not configured in the sender.

senderType

st

This is a user configurable identifier of the type of network node that generated the file, e.g. NodeB, EM, SGSN. The string may be empty (i.e. string size =0) in case the “senderType” is not configured in the sender.

vendorName

vn

The vendorName identifies the vendor of the equipment that provided the measurement file. The string may be empty (i.e. string size =0) if the “vendorName” is not configured in the sender.

collectionBeginTime

cbt

The collectionBeginTime is a time stamp that refers to the start of the first measurement collection interval (granularity period) that is covered by the collected measurement results that are stored in this file.

nEId

neid

The unique identification of the NE in the system. It includes the user name (“nEUserName”) and the distinguished name (“nEDistinguishedName”) of the NE.

nEUserName

neun

This is the user definable NE name, cf. 3GPP TS 32.106. The string may be empty (i.e. string size =0) if the “nEUserName” is not configured.

nEDistinguishedName

nedn

This is the distinguishedName defined for the NE in 3GPP TS 32.106. It is unique across an operator’s 3G network. The string may be empty (i.e. string size =0) if the “ nEDistinguishedName ” is not configured.

measInfo

mi

The sequence of measurements, values and related information. It includes a list of measurement types (“measTypes”) and the corresponding results (“measValues”), together with the time stamp (“measTimeStamp”) and granularity period (“granularityPeriod”) pertaining to these measurements.

measTimeStamp

mts

Time stamp referring to the end of the granularity period.

granularityPeriod

gp

Granularity period of the measurement(s) in seconds.

measTypes

mt

This is the list of measurement types for which the following, analogous list of measurement values (“measValues”) pertains. The 3G standard measurement types are defined in annex C of this TS.

measValues

mv

This parameter contains the list of measurement results for the resource being measured, e.g. trunk, cell. It includes an identifier of the resource (“measObjInstId”), the list of measurement result values (“measResults”) and a flag that indicates whether the data is reliable (“suspectFlag”).

measObjInstId

moid

The “measObjInstId” field identifies the measured object class and its instance, e.g. trunk1 means object class is trunk and instance #1 is being measured The values for this parameter are defined in annex C of this TS.

measResults

r

This parameter contains the sequence of result values for the observed measurement types. The “measResults” sequence shall have the same number of elements, which follow the same order as the measTypes sequence. Normal values are INTEGERs and REALs. The NULL value is reserved to indicate that the measurement item is not applicable or could not be retrieved for the object instance.

suspectFlag

sf

Used as an indication of quality of the scanned data. FALSE in the case of reliable data, TRUE if not reliable. The default value is “FALSE”, in case the suspect flag has its default value it may be omitted.

TimeStamp

ts

GeneralizedTime format. The minimum required information within timestamp is year, month, day, hour, minute, and second.

The measInfo contains the sequence of measurements, values and related information, in a table-oriented structure.
A graphical representation of this structure, together with an ASN.1 and a XML example, can be found in annex D.

Measurement types and measurement groups will be defined in Release 2000. This also applies to the exact details concerning the arrangement of the information in the files, since that aspect may be dependent on the measurement type/group definitions.

At least for those measurement types that are re-used from non-3GPP standards (e.g. IP, ATM), it is required that the measType be operator definable. This is necessary to allow the operator to harmonise the numbering between different vendors’ systems where appropriate. Through this harmonisation, it can be assured that identical measurements always carry the same measType value, which is required by the post-processing system. This requirement will eventually be reflected in annex C, which discusses and specifies the measurement definition.

A.2 ASN.1 file format definition

For ASN.1 formatted files, BER encoding rules shall apply. Embedded comments are integral parts of the standard format; i.e. any implementation-claiming conformance to this annex shall also conform to the comments.

PM-File-Description

DEFINITIONS AUTOMATIC TAGS::= BEGIN

MeasDataCollection::= SEQUENCE

{

measFileHeader MeasFileHeader,

measData SEQUENCE OF MeasData,

measFileFooter MeasFileFooter

}

MeasFileHeader::= SEQUENCE

{

fileFormatVersion INTEGER,

senderName PrintableString (SIZE (0..400)),

senderType SenderType,

vendorName PrintableString (SIZE (0..32)),

collectionBeginTime TimeStamp,

}

— The sole purpose of the ellipse notation used in the file header is to facilitate inter-release compatibility, vendor specific additions are not allowed in implementations claiming conformance to the TS. However, it is acknowledged that this feature does enable the use of non-standard extensions to the file header without loosing compatibility to the file format specified in the present document.

SenderType::= PrintableString (SIZE (0..8))

TimeStamp::= GeneralizedTime

MeasData::= SEQUENCE

{

nEId NEId,

measInfo SEQUENCE OF MeasInfo

}

NEId::= SEQUENCE

{

nEUserName PrintableString (SIZE (0..64)),

nEDistinguishedName PrintableString (SIZE (0..400))

}

MeasInfo::= SEQUENCE

{

measTimeStamp TimeStamp,

granularityPeriod INTEGER,

measTypes SEQUENCE OF MeasType,

measValues SEQUENCE OF MeasValue

}

MeasType::= PrintableString (SIZE (1..32))

MeasValue::= SEQUENCE

{

measObjInstId MeasObjInstId,

measResults SEQUENCE OF MeasResult,

suspectFlag BOOLEAN DEFAULT FALSE

}

MeasObjInstId::= PrintableString (SIZE (0..400))

— The size of the concatenated measObjInstId and neDistinguishedName must not exceed 400.

MeasResult::= CHOICE

{

iValue INTEGER,

rValue REAL,

noValue NULL,

}

— Normal values are INTEGERs and REALs. The NULL value is reserved to indicate that the measurement item is not applicable or could not be retrieved for the object instance. The sole purpose of the ellipse notation used in the MeasResult choice is to facilitate inter-release compatibility in case the choice needs to be extended in future releases.

MeasFileFooter::= TimeStamp

END

A.3 XML file format definition

The character encoding shall be a subset of UTF-8. The characters in the ASN.1 type PrintableString are allowed, i.e.:

  • A-Z
  • a-z
  • 0-9
  • <space> ‘ ( ) + , – . / : = ?’

For encoding of the information content, XML (see Extensible Markup Language (XML) 1.0, W3C Recommendation 10-Feb-98) will be used. The XML document type declaration contains the mark-up declarations that provide a grammar for the measurement file format. This grammar is known as a Document Type Definition (DTD).
The DTD to be used is defined below. The type definitions and constraints for data types and values defined in the ASN.1 format, such as string sizes, shall implicitly be applied to the XML result files also. The representation of the timestamps within the XML file shall follow the “GeneralizedTime” ASN.1 type.

<!– MeasDataCollection.dtd version 1.1–>

<!ELEMENT mdc (mfh , md*, mff )>

<!ELEMENT mfh (ffv, sn, st, vn, cbt) >

<!ELEMENT md (neid , mi*)>

<!ELEMENT neid (neun, nedn)>

<!ELEMENT mi (mts,gp, mt*, mv*)>

<!ELEMENT mv (moid , r*, sf? )>

<!ELEMENT mff (ts)>

<!ELEMENT ts (#PCDATA)>

<!ELEMENT sf (#PCDATA)>

<!ELEMENT r (#PCDATA)>

<!ELEMENT mt (#PCDATA)>

<!ELEMENT moid (#PCDATA)>

<!ELEMENT gp (#PCDATA)>

<!ELEMENT mts (#PCDATA)>

<!ELEMENT nedn (#PCDATA)>

<!ELEMENT neun (#PCDATA)>

<!ELEMENT cbt (#PCDATA)>

<!ELEMENT vn (#PCDATA)>

<!ELEMENT st (#PCDATA)>

<!ELEMENT sn (#PCDATA)>

<!ELEMENT ffv (#PCDATA)>

<!– end of MeasDataCollection.dtd –>

The number of Measurement Result tags (r) per observed object instance tags (moid) shall always equal the number of Measurement Types (mt) tags. In case the result is a REAL value the decimal separator shall be “.”. In case the result is “NULL” then the “r” mark-up shall be empty.

The following header shall be used in actual XML measurement result files (cf. annex D for an example):

<?xml version="1.0"?>

<?xml-stylesheet type="text/xsl" href="MeasDataCollection.xsl" ?>

<!DOCTYPE mdc SYSTEM "MeasDataCollection.dtd" >

<mdc xmlns:HTML="http://www.w3.org/TR/REC-xml">

  • Line 1: xml version number 1 shall be used.
  • The reference to an XSL (Extensible Stylesheet Language) or CSS (Cascading Style Sheet) file in line 2 of the header is optional. It may be configured by the operator to be inserted for the purpose of presenting the XML file in a web browser GUI. It is up to the receiver of the file to decide on the usage of this stylesheet reference, e.g. ignore it if not needed or choosing a configured default if no style sheet reference is supplied in the file.
  • Line 4: A reference to the W3C Recommendation web page for XML.

Quick guide to XML notation: ? zero or one occurrence
+ one or more occurrences
* zero or more occurrences
#PCDATA parsed character data

Annex B (normative):
Measurement Report File Conventions and Transfer Procedure

This annex describes the conventions how files containing performance measurement results are generated in the network (EM or NEs) and the procedure to transfer these files from the network to the NM.

B.1 Conventions

The following subclauses define conventions for the generation and the naming of measurement-result files.

B.1.1 File generation

Since vendors may choose to implement the NM interface either in the NEs or the EM, the measurement result files for collection by the NM (push or pull transfer mechanism) may be provided by the NEs or the EM. Note that within one 3G network both possibilities may occur, since NEs of different types may use either one of the two possible approaches (NE based or EM based). This is particularly true in a multi-vendor network.

The procedures for the transfer of the files to the NM from either the NE or the EM are described in clause B.2 below.

B.1.1.1 NE based approach

The NE shall generate one file immediately at the end of each granularity period. This file shall contain all measurement results produced by the NE within that granularity period. For example, if a NodeB runs 10 measurements with a granularity period of 15 minutes and 5 measurements with a granularity period of 5 minutes, then it shall generate one file containing 10 results every 15 minutes, and one file containing 5 measurement results every 5 minutes.

In the event of two or more granularity periods coming to an end at the same time, the NE shall generate one file per granularity period. Hence in the above example, the NodeB shall generate 2 files – one containing 10 results (15min granularity period) and the other containing 5 measurement results (5min granularity period), when the end time of the granularity periods coincide.

The NE and the granularity period shall be identified both in the file name and the file contents. NE identifiers (names) used for the files shall be in accordance with the NE naming conventions defined in 3GPP TS 32.106 [3]. The file shall be available for transfer to or collection by the NM as soon as all applicable results have been assembled.

Each NE is responsible for the generation and maintenance of the files pertaining to its own measurements (i.e. the measurements it executes). In particular, this implies that the RNC is not involved in the generation, provision or transfer of measurement result files of its controlled NodeBs, i.e. for the measurements defined for the NodeB in the present document, no results will be sent via the Iub interface. (Note that NodeB measurement results may be routed across the same physical interface as Iub, see 3GPP TS 25.442 [4] for details).

B.1.1.2 EM based approach

This approach requires that measurement results be forwarded to the EM according to the mechanisms described in subclause 4.2.4 of the present document. The EM may choose to provide measurement result files as described above for the NEs, however, additional flexibility may be offered. For example, measurement results from several granularity periods and/ or several NEs could be written into one single file. These NEs may be determined based on network hierarchy (e.g. all NodeBs controlled by the same RNC, all NEs controlled by the same EM), or management domains configured by the system operator (e.g. NodeBs belonging to a certain (management or geographical) area). In case such rules are applied by the EM for the routing of measurement results to specific files then they shall be operator configurable. If results from more than one NE are contained in a file, the NE identifier used for the file shall be the EM name as defined in 3GPP TS 32.106 [3], or a domain name configured by the system operator. If results from more than one granularity period are contained in the file then the beginning of the first and the end of the last granularity period shall be indicated in the file name.

The file shall be made available for transfer to or collection by the NM as soon as all applicable results have been assembled.

B.1.2. File naming

The following convention shall be applied for measurement result file naming:

<Type><Startdate>.<Starttime>-[<Enddate>.]<Endtime>_<UniqueId>[:<RC>]

1) The Type field indicates if the file contains measurement results for single or multiple NEs and/or granularity periods, where:

– "A" means single NE, single granularity period,

– "B" indicates multiple NEs, single granularity period,

– "C" signifies single NE, multiple granularity periods,

– "D" stands for multiple NEs, multiple granularity periods.

Note that files generated by the NEs will always have the Type field set to "A".

2) The Startdate field indicates the date when the granularity period began if the Type field is set to A or B. If the Type field is either "C" or "D" then Startdate contains the date when the first granularity period of the measurement results contained in the file started. The Startdate field is of the form YYYYMMDD, where:

– YYYY is the year in four-digit notation,

– MM is the month in two digit notation (01 – 12),

– DD is the day in two digit notation (01 – 31).

3) The Starttime field indicates the time when the granularity period began if the Type field is set to A or B. If the Type field is either "C" or "D" then Starttime contains the time when the first granularity period of the measurement results contained in the file began. The Starttime field is of the form HHMM, where:

– HH is the two digit hour of the day, based on 24 hour clock (00 – 23),

– MM is the two digit minute of the hour, possible values are 00, 05, 10, 15, 20, 25, 30, 35, 40, 45, 50, and 55.

4) The Enddate field shall only be included if the Type field is set to "C" or "D", i.e. measurement results for multiple granularity periods are contained in the file. It identifies the date when the last granularity period of these measurements ended, and its structure corresponds to the Startdate field.

5) The Endtime field indicates the time when the granularity period ended if the Type field is set to A or B. If the Type field is either "C" or "D" then Endtime contains the time when the last granularity period of the measurement results contained in the file ended. Its structure corresponds to the Starttime field, however, the allowed values for the minute of the hour are 05 10, 15, 20, 25, 30, 35, 40, 45, 50, 55, and 00.

6) UniqueId. This is the name of the NE, EM or domain, as defined in subclauses B.1.1.1 and B.1.1.2 above.

7) The RC parameter is a running count, starting with the value of "1", and shall be appended only if the filename is otherwise not unanimous, i.e. more than one file is generated and all other parameters of the file name are identical. Therefore it may only be used by the EM, since the described situation can not occur with NE generated files.

Some examples describing file naming convention:

1) file name: A20000626.2315-2330_NodeBId,
meaning: file produced by NodeB <NodeBId> on June 26, 2000, granularity period 15 minutes from 23:15 to 23:30.

2) file name: B20021224.1700-1705_EMId,
meaning: file containing results for multiple NEs, produced by EM <EMId> on December 24, 2002, granularity period 5 minutes from 17:00 to 17:05.

3) file name: D20050907.1030-20050909.1500_DomainId:2,
meaning: file containing results for NEs belonging to domain <DomainId>, start of first granularity period 07 September 2005, 10:30, end of last granularity period 09 September 2005, 15:00. This file is produced by the EM managing the domain, and it is the second file for this domain/granularity periods combination.

B.2. File transfer procedure

Both push (i.e. triggered by the NE) and pull (triggered by the OS) transfer modes shall be supported on the NM interface. Implementation specific means may be employed for the administration and control of the file transfer, concerning

– the time of the transfer (in push mode);

– the routing of the transfer to one or more OS(s) (in push mode);

– the storage/deletion of the files in the NE, particularly when the EM based approach is chosen (cf. subclause B.1.1.1 above).

Measurement result files shall be retained by the file generator (i.e. NE or EM) at least until they have been successfully transferred to or collected by the NM. The storage capacity and the duration for which the data can be retained at the NE or the EM will be Operator and implementation dependent.

The file transfer procedure implemented in the system (NE or EM) shall ensure that no data can get lost under normal operating conditions. The procedure shall also ensure that the files will be deleted after successful transfer to the NM. Depending on the exact implementation of the procedure, the NM may be responsible for deleting those files, or older files will be eventually overwritten by new ones by the file generator in a round robin fashion.

Each implementation shall support all primitives of the selected protocol (e.g. put file, get file, inspect directory contents, delete file) which are needed by the NM. These primitives depend on the details of the procedure, as defined by the manufacturer.

Annex C (normative):
Performance Measurement (PM) requirements summary

The present document is valid for all measurement types provided by an implementation of a 3G network. These may be measurement types defined within this annex, measurements defined within other standards bodies, or vendor specific measurement types.

Only measurement types that are specific to 3G networks are defined within this annex. I.e. vendor specific measurement types and measurements related to "external" technologies used in 3G networks, such as ATM or IP, are not covered. Instead, these could be applied as described by the other, "external" standards bodies (e.g. ITU-T or IETF) or according to manufacturer’s documentation.

C.1 Measurement Definition Template

C.1.1 Template Specification

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

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

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

a) Description

This section contains an explanation of the measurement operation;

b) Collection Method

This section 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 section 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.

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

This section contains a description of expected result value(s) (e.g. a single integer value).

e) Measurement Type

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

f) Measurement Object Instance

The “measObjInstId” field identifies the measured object class and its instance, e.g. trunk1 means object class is trunk and instance #1 is being measured. The object class and instance values used for this purpose shall be in accordance with 3GPP TS 32.106 [3], i.e. the NE/resource object model (defined in the Basic CM IRP Information Model – 3GPP TS 32.106-5) and naming conventions (defined in the Name Convention for Managed Objects – 3GPP TS 32.106-8). This parameter, if applicable, shall be provided in the measurement job.

g) Switching Technology

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

C.1.2 Examples of measurement definitions

The following measurement definitions examples correspond to those used in the XML example file in annex D. Though these examples relate to measurements defined in GSM 12.04, they are mentioned here for illustrative purposes only.

C.x. Measurements collected by the RNC

C.x.1. Measurements related to the RNC

C.x.2. Measurements related to cells

C.x.2.1. Attempted TCH seizures

a) Description

This measurement counts the number of attempts by UEs to seize a traffic channel.

b) Collection Method

CC

c) Condition

Transmission of "ASSIGNMENT COMMAND" Message to the MS (GSM 04.08);

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

A single integer value;

e) Measurement Type

attTCHSeizures

f) Measurement Object Instance

cell= <cellID> (to be aligned with the object model in 3GPP TS 32.106-5).

Example : Cell=997

(the complete RDN can then be constructed prefixing the nedn : System=UTRANNetwork,RNC=123, Cell=997)

g) Switching Technology

Valid for Circuit and Packet Switching;

C.x.2.2. Successful TCH seizures

a) Description

This measurement counts the number of successful traffic channel seizures by the UEs.

b) Collection Method

CC

c) Condition

Receipt of "ASSIGNMENT COMPLETE" Message from the MS (GSM 04.08);

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

A single integer value;

e) Measurement Type

succTCHSeizures

f) Measurement Object Instance

cell= <cellID> (to be aligned with the object model in 3GPP TS 32.106-5).

Example : Cell=997

(the complete RDN can then be constructed prefixing the nedn : System=UTRANNetwork,RNC=123, Cell=997)

g) Switching Technology

Valid for Circuit and Packet Switching;

C.x.2.3. Attempted Immediate Assignment Procedures

a) Description

This measurement provides the number of attempted immediate assignment procedures.

b) Collection Method

CC

c) Condition

Receipt of "CHANNEL REQUIRED" Message.
The establishment causes are: "EMERGENCY CALL", "CALL RE-ESTABLISHMENT", "ANSWER TO PAGING", "ORIGINATING CALL" , "LOCATION UPDATING", "ONE PHASE PACKET ACCESS", "SINGLE BLOCK PACKET ACCESS" and "OTHER PROCEDURES" as defined in GSM 04.08.

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

A single integer value;

e) Measurement Type

attImmediateAssignProcs

f) Measurement Object Instance

cell= <cellID> (to be aligned with the object model in 3GPP TS 32.106-5).

Example : Cell=997

(the complete RDN can then be constructed prefixing the nedn : System=UTRANNetwork,RNC=123, Cell=997)

g) Switching Technology

Valid for Circuit and Packet Switching;

C.x.2.4. Successful Immediate Assignment Procedures

a) Description

This measurement provides the number of successful immediate assignment procedures.

b) Collection Method

CC

c) Condition

Transmission of "IMMEDIATE ASSIGN COMMAND" Message;
This message contains either an "IMMEDIATE ASSIGNMENT" Message or an "IMMEDIATE ASSIGNMENT EXTENDED" Message. If an "IMMEDIATE ASSIGNMENT EXTENDED" Message is transmitted, the counter shall be incremented by two, because that Message contains assignment information for two mobiles (GSM 04.08).

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

A single integer value;

e) Measurement Type

succImmediateAssignProcs

f) Measurement Object Instance

cell= <cellID> (to be aligned with the object model in 3GPP TS 32.106-5).

Example : Cell=997

(the complete RDN can then be constructed prefixing the nedn : System=UTRANNetwork,RNC=123, Cell=997)

g) Switching Technology

Valid for circuit and packet switching;

C.2 Measurements related to The RNC

It should be investigated whether GSM BSC measurements can be re-used.

C.3 Measurements related to the NodeB

It should be investigated whether GSM BTS measurements can be re-used.

C.4 Measurements related to the MSC

It is expected that GSM measurements can be re-used to a large extent.

C.5 Measurements related to the HLR

It is expected that GSM measurements can be re-used to a large extent, especially those added for GPRS.

C.6 Measurements related to the VLR

It is expected that GSM measurements can be re-used to a great extent.

C.7 Measurements related to the EIR

Check if there is a similar functionality in 3G networks, possibly re-use GSM measurements.

C.8 Measurements related to the SMS IWMSC/GMSC

It is expected that GSM measurements can be re-used to a great extent.

C.9 Measurements related to the SGSN

It is expected that GSM GPRS measurements can be fully re-used (more to be added?).

C.10 Measurements related to the GGSN

It is expected that GSM GPRS measurements can be fully re-used (more to be added?).

Annex D (informative):
The table oriented file format structure

Measurement Items (counters) are typically grouped according functionality (cfr GSM 12.04 [8] Measurement Function). The term “measured object class” is used to identify such a group. The file format is based on the fact that the measurements are always collected in sets of one functional group.

The measInfo contains the sequence of measurements, values and related information, in a table-oriented structure.
It includes a list of measurement types (“measTypes”) and the corresponding values (“measValues”), together with the time stamp (“measTimeStamp”) and granularity period (“granularityPeriod”) pertaining to these measurements. Whenever one of these 4 elements changes, then a new measInfo sequence is started. If the “measTypes” change, then also the “measValues” change, because these elements are connected in the following way: the “measTypes” correspond to a specific measurement object (NE, trunk, cell, …), of which one or more instances can exist inside the NE.
Hence for one set of “measTypes”, there can be one or more sets of “measValues”, according to the “measObjInstId”.

The above is best explained with an example: consider the CELL measurement function (GSM 12.04 [8]). Then the measured object class is Cell. The measInfo contains a “header” line defining which measurements related to Cell are collected (measTypes), and in which order. The subsequent “data” lines will then contain the values of the measurements for each specific cell, which is measured, one data line per cell (measValues).

This format will generate a kind of table with as column headings the measurement names, and in the rows the corresponding measurement values per measured instance.

D.1 Graphical representation of the table structure

For clarity, the table in the example below only contains the measTypes and measValues (and suspectFlag), not the granularityPeriod and the measTimeStamp.

attTCHSeizures

succTCHSeizures

attImmediateAssignProcs

succImmediateAssignProcs

cell=997

234

345

567

789

false

cell=998

890

901

123

234

false

cell=999

456

567

678

789

false

D.2 Example of ASN.1 Measurement Report File

For readability, a kind of pseudo ASN.1 was used in stead of the BER encoding..

MeasDataCollection ::= {

measFileHeader {

fileFormatVersion ::= 1,

senderName ::= “System=UTRANNetwork,RNC=123“ ,

senderType ::= “RNC”,

vendorName ::= “Telecom corp.”,

collectionBeginTime ::= 20000301140000

},

measData {

nEId {

nEUserName ::= “RNC Telecomville“,

nEDistinguishedName ::= “System=UTRANNetwork,RNC=123“

},

measInfo {

measTimeStamp ::= 20000301141430,

granularityPeriod ::= 900,

measTypes {

“attTCHSeizures”, “succTCHSeizures”, “attImmediateAssignProcs”, “succImmediateAssignProcs”

},

measValues {

{

measObjInstId ::= “Cell=997”,

measResults { iValue ::= 234, iValue ::= 345, iValue ::= 567, iValue ::= 789},

suspectFlag ::= FALSE

},

{

measObjInstId ::= “Cell=998”,

measResults { iValue ::= 890, iValue ::= 901, iValue ::= 123, iValue ::= 234},

suspectFlag ::= FALSE

},

{

measObjInstId ::= “Cell=999”,

measResults { iValue ::= 456, iValue ::= 567, iValue ::= 678, iValue ::= 789},

suspectFlag ::= FALSE

}

}

}

},

measFileFooter ::= 20000301141500

}

D.3 Example of XML Measurement Report File

<?xml version="1.0"?>

<?xml-stylesheet type="text/xsl" href="MeasDataCollection.xsl" ?>

<!DOCTYPE mdc SYSTEM "MeasDataCollection.dtd" >

<mdc xmlns:HTML="http://www.w3.org/TR/REC-xml">

<mfh>

<ffv>1</ffv>

<sn>System=UTRANNetwork,RNC=123</sn>

<st>RNC</st>

<vn>Telecom corp.</vn>

<cbt>20000301140000</cbt>

</mfh>

<md>

<neid>

<neun>RNC Telecomville</neun>

<nedn>System=UTRANNetwork,RNC=123</nedn>

</neid>

<mi>

<mts>20000301141430</mts>

<gp>900</gp>

<mt>attTCHSeizures</mt>

<mt>succTCHSeizures </mt>

<mt>attImmediateAssignProcs</mt>

<mt>succImmediateAssignProcs</mt>

<mv>

<moid>Cell=997</moid>

<r>234</r>

<r>345</r>

<r>567</r>

<r>789</r>

<sf>FALSE</sf>

</mv>

<mv>

<moid>Cell=998</moid>

<r>890</r>

<r>901</r>

<r>123</r>

<r>234</r>

<sf>FALSE</sf>

</mv>

<mv>

<moid>Cell=999</moid>

<r>456</r>

<r>567</r>

<r>678</r>

<r>789</r>

<sf>FALSE</sf>

</mv>

</mi>

</md>

<mff>

<ts>20000301141500</ts>

</mff>

</mdc >

Annex E (informative):
Change history

Change history

Date

TSG #

TSG Doc.

CR

Rev

Subject/Comment

Old

New

Dec 1999

S_06

SP-99579

Approved at TSG SA #6 and placed under Change Control

3.0.0

Mar 2000

S_07

SP-000016

001

Reduction of measurement job advance period

3.0.0

3.1.0

Mar 2000

S_07

SP-000016

002

PM file format – ASN.1 description

3.0.0

3.1.0

Mar 2000

Cosmetic

3.1.0

3.1.1

Jun 2000

S_08

SP-000231

003

Measurement definition template

3.1.1

3.2.0

Jun 2000

S_08

SP-000232

004

Inclusion of XML file format definition

3.1.1

3.2.0

Jun 2000

S_08

SP-000233

005

Example of XML file format for PM result files

3.1.1

3.2.0

Jun 2000

S_08

SP-000234

006

Addition of missing abbreviations

3.1.1

3.2.0

Sep 2000

S_09

SP-000434

007

Clarification of the table oriented structure of the file format, and addition of ASN.1 example, according to annex D

3.2.0

3.3.0

Dec 2000

S_10

S5-000479

008

Clarification of measurement definition template

3.3.0

3.4.0

Dec 2001

S_14

SP-010638

010

Correction of declaration in XML header

3.4.0

3.5.0

Jun 2003

S_20

SP-030291

011

Remove ambiguity in NE file generation behaviour in case of multiple granularity periods

3.5.0

3.6.0

Mar 2004

S_23

SP-040133

012

Correction of XML Measurement Report File format example

3.6.0

3.7.0

Jun 2004

S_24

SP-040265

013

Correction in requirement for granularity periods

3.7.0

3.8.0

Sep 2004

S_25

S5-048676

014

Correction of measObjInstId length limitations in the Measurement Report File Format

3.8.0

3.9.0