Tech-invite3GPPspaceIETFspace
21222324252627282931323334353637384‑5x

Content for  TS 32.401  Word version:  17.0.0

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

 

5.4  Measurement jobsp. 20

Measurement jobs may be only visible at the (proprietary) interface between the EM and the NE. Measurement job administration functions in the EM may hide the measurement jobs from the user interface by providing higher levels of abstraction for the benefit of ease of use.
When defining a measurement job, the following aspects have to be considered.

5.4.1  Measurement job characteristicsp. 20

5.4.1.1  Measurement typesp. 20

Every measurement job consists of one or more measurement types (as defined in Performance Measurement File Format Definition TS 32.432), 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.4.1.2  Measurement sub-typesp. 20

Many of the measurement types specified produce single result values, i.e. the measurement is characterised by a single measurement type as specified in TS 52.402, TS 32.405, TS 32.406, TS 32.407, TS 32.408, TS 32.409, TS 32.425, TS 32.426, TS 32.452, TS 32.453, TS 28.402 and TS 28.403. In other cases, however, the event or procedure being measured can be characterised by several sub-types, or, depending on the measurement definition, by several causes, e.g. successful termination of a procedure and unsuccessful termination for all failure causes. As far as a measurement type is defined to capture per cause information of the event or procedure being measured, the causes and cause codes are specified in "other" 3GPP TSs, i.e. in the TS defining the procedure being measured. In other cases, the sub-types are specified in the measurement type definitions in TS 52.402, TS 32.405, TS 32.406, TS 32.407, TS 32.408, TS 32.409, TS 32.425, TS 32.426, TS 32.452, TS 32.453, TS 28.402 and TS 28.403. For UMTS systems, combined UMTS/GSM systems and for LTE systems, this information is described in detail in the measurement definition templates, see TS 32.404.
Per cause measurements, where the causes are defined in the 3GPP TS that specifies the procedure or event being measured, may lead in certain cases to a huge number of measurement sub-types which will increase substantially the size of the measurement result file. Since not all per cause measurements may be useful for the system operator, two options are possible for the management of the corresponding measurement sub-types:
  • support all the sub-types corresponding to the cause codes defined in the 3GPP TS that specifies the procedure or event being measured. In that case, the sum over the result values of all supported per cause measurements is equal to the total sum across all defined sub-types, and therefore no sum value shall be provided in the measurement result files.
  • support only a subset of the causes (allowed only if the cause codes are specified in "other" 3GPP TSs). In that case, the first value of the result sequence in the measurement result files must be the total sum across all the sub-types as defined in the "other" 3GPP TS, which may then be different from the sum over the result values of the supported sub-types. The keyword .sum placed behind the measurement type is used to identify the sum subtype.
If the definition of a measurement refers to specific failure causes or other sub-types then care shall be taken to assess which causes or sub-types are included. The choice of the supported causes/sub-types in the above cases is manufacturer dependent. Measurement job administration in the EM may also allow the system operators to select the sub-types of the measurement types that make up the measurement job, otherwise all sub-types supported by an implementation are included.
Up

5.4.1.3  Measurement schedulep. 21

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.
Up

5.4.1.4  Granularity periodp. 21

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.4.1.5  Measurement reportingp. 21

Each measurement job running on an NE produces scheduled measurement reports (measurement records) 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 reports (measurement records) generated by the NEs may be vendor specific. Multiple measurement reports shall be collated, based on reporting period, into a measurement result file for transfer, e.g from the NE or the EM. The file format of this aggregated file is specified by Performance Measurement File Format Definition TS 32.432.
Clause 5.5.2 specifies how these reports can be transferred to the destination EM and/or NM.
Up

5.4.1.6  Illustration of the measurement scheduling principlesp. 22

The diagram below gives an example of a NE which runs a measurement job, with a 15 minute granularity period, that has a recording interval start and end time, respectively, of 12:00 and 14:00.
Copy of original 3GPP image for 3GPP TS 32.401, Fig. 2:
Figure 2
(⇒ copy of original 3GPP image)
Up
  • At 12:00 the measurement job starts collecting data for its defined measurements.
  • At 12:15, and every 15 minutes during the Recording Interval, the results for the measurements will be computed from the data gathered over the previous 15 minutes, and measurement reporting occurs as specified in clause 5.3.1.4.
  • Beginning at 12:15, the results for the expired granularity periods may be sent to a destination OS.
  • At 14:00 the measurement job activity is terminated for this recording interval.

5.4.2  Measurement job state and status attributesp. 22

Void.

5.4.3  Measurement job administrationp. 22

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 clause 5.4.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 temporarily not used…). The system operator therefore is able to suspend a defined measurement job at any time. 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. In addition to the suspend operation which may be triggered by the operator, the system may selectively suspend one or more measurement jobs in case of overload. When a measurement job is suspended, a "job suspended" notification shall then be generated so that the Network Manager(s) will be warned of such an event.
Up

5.5  Measurement resultsp. 23

5.5.1  Measurement result characteristicsp. 23

During its specified recording intervals, each measurement job produces a result at the end of the granularity period if it is not suspended. Performance Measurement File Format Definition TS 32.432 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 Performance Measurement File Format Definition TS 32.432.
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, this shall be indicated in the measurement report, cf. clause 5.4.1.5. 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.
Up

5.5.2  Transfer of measurement resultsp. 23

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 ISO 8571 [7], (T)FTP protocol or FTIRP([30]). 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 Performance Measurement File Format Definition TS 32.432. The measurement report file conventions and transfer procedure are also specified in Performance Measurement File Format Definition TS 32.432.
The results of the measurement job can be forwarded to the EM in either of two standard ways:
  1. the scheduled result reports generated by the NE (notifications) can be sent to the EM as soon as they are available;
  2. the reports can be stored in the NE (files) and transferred to or retrieved by the EM when required.
It shall be possible for the EM to specify the details for its result retrieval as a part of the measurement administration.
Measurement results can be forwarded to the NM via a bulk transfer interface. It is an implementation option whether this interface resides in the EM or the NEs. Depending on the implementation, the control of the bulk transfer of measurement results to the NM may involve the EM and/or the NM. See Performance Measurement File Format Definition TS 32.432 for details.
In a network with more than one OS (e.g. EM and NM) the data produced may be required by several OSs. It is therefore necessary to support the possibility for multiple destinations for transfer of data.
All scenarios for the result transfer, as far as they are relevant for standardisation of 3GPP systems, are defined above. It should be noted that, depending on an Operator's needs, measurement results may have to be transferred to the EM only, the NM only, or both. Depending on a vendor's implementation, measurement results may be transferred to the NM directly from the NE or via the EM. This implies that not all of the result transfer options described above shall be implemented in all cases, however, those procedures that are implemented shall comply with the present document. A detailed specification of the measurement result transfer to the NM can be found in Performance Measurement File Format Definition TS 32.432.
Up

5.6  Usage of Alarm IRP for performance alarmsp. 24

Performance alarms allow Network Operators to be quickly informed of significant PM-related events. Authorized users can (a) set the measurement thresholds and (b) define the characteristics of related performance alarm notifications (e.g. perceivedSeverity). (a) Crossing or (b) reaching of thresholds shall result in the emission of a performance alarm notification.
Performance alarms may be defined against any managed object supporting measurement definitions, e.g. UtranCell, SgsnFunction. The source object of the performance alarm shall be the source object instance of the measurement that caused the alarm. Upon threshold (a) crossing or (b) reaching, the subscribed users (i.e. Notification IRP Managers) shall be notified via the Alarm IRP and Notification IRP. The Alarm IRP and Notification IRP are described in TS 32.111-2 and TS 32.302.
All parameters of the alarm notification as described in TS 32.111-2 can be used for performance alarms. This information shall be provided by the PM application as the user of the Alarm IRP, with respect to at least the event type, probable cause, perceived severity, and thresholdinfo, plus all other user supplied mandatory parameters of the alarm notification. The parameter thresholdinfo shall be present for all performance alarm notifications and shall contain information pertinent to the context in which the performance alarm was triggered.
The thresholdinfo parameter shall provide the following information:
  • The identifier of the measurement which (a) crossed or (b) reached the threshold
  • The value of the measurement
  • The threshold (a) crossing or (b) reaching direction (up or down)
  • The threshold value (if hysteresis thresholds are supported, both raise and clear trigger values are provided)
Once a performance alarm has been raised, it shall be managed as other kinds of alarms, e.g., acknowledged, unacknowledged or annotated. Performance alarms may not be cleared manually (i.e., via the ADMC [automatic detection and manual clearing], see TS 32.111-1). Performance alarms shall be cleared when the threshold is (a) crossed or (b) reached in the opposite direction to the one that triggers the alarm.
Up

Up   Top   ToC