IEC 10164-5-95 (2003) Event Report Management Function: Technical Overview and Compliance Guide

Mastering Event Report Configuration and Control in OSI Systems Management

IEC 10164-5-95 (2003), formally known as Information technology – Open Systems Interconnection – Systems Management: Event Report Management Function, is a critical standard within the OSI management framework. It defines a set of services, protocols, and managed objects that enable the configuration and control of event reporting in a distributed systems management environment. This standard is technically aligned with ITU-T Recommendation X.734 and is part of the ISO/IEC 10164 series, which addresses various systems management functions.

The primary objective of this standard is to allow a managing system (manager) to specify which events generated by managed objects should be reported and to manage the forwarding of those events to selected destinations. It introduces the Event Forwarding Discriminator (EFD) managed object class, which acts as a filter and selector for event reports. Additionally, it defines the Event Log managed object for storing event information locally.

Note: This standard was first published in 1995 and later confirmed/updated in 2003. It remains the foundation for event management in many telecommunications and enterprise management systems.

Scope and Overview

The scope of IEC 10164-5-95 encompasses the Event Report Management Function (ERMF) as part of OSI systems management. It defines the managed objects (EFD and Event Log) required to configure, control, and monitor the reporting of events. The standard specifies the interactions between a managing system and the managed systems using the Common Management Information Protocol (CMIP) and the Common Management Information Service (CMIS) defined in ISO/IEC 9595 and 9596.

Key aspects covered include: the creation and deletion of EFD instances, the ability to modify the discriminator construct at runtime, the state machine governing EFD behavior, and the logging and retrieval of event records through the Event Log object. The standard does not define the semantics of individual event notifications; it focuses solely on the mechanism for forwarding events.

Use Case: ERMF is widely used in telecommunication management networks (TMN) to filter alarms and other events from network elements to operations support systems (OSS).

Technical Requirements

Event Forwarding Discriminator (EFD)

The EFD is the core managed object defined in IEC 10164-5-95. It is responsible for evaluating events generated by managed objects against a set of criteria (discriminator construct) and, if matched, sending an event report to a designated destination. Each EFD instance has the following key characteristics:

  • Discriminator Construct: An ASN.1 expression that defines the filtering criteria for events.
  • Administrative and Operational States: The EFD has both administrative (locked/unlocked) and operational (disabled/enabled) states that control its behavior.
  • Destination Addresses: A list of application entity addresses where event reports are forwarded.
  • Event Report Class: Defines the protocol to be used (e.g., M-EVENT-REPORT as per ISO/IEC 10164-5).

The state model of the EFD follows the generic state management defined in ISO/IEC 10164-2 (State Management Function).

Service and Protocol Elements

The standard defines the following CMIS-based services:

Service Description Operation Type
M-EVENT-REPORT Managed object issues a notification with event information Notification (confirmed/unconfirmed)
M-CREATE Creates an instance of an EFD or Event Log Management operation
M-DELETE Deletes an instance of a managed object Management operation
M-SET Modifies attributes of a managed object (e.g., EFD discriminator construct) Management operation
M-GET Retrieves attribute values of managed objects Management operation

Managed Object Classes Defined

The standard specifies the following managed object classes in GDMO format:

  • Event Forwarding Discriminator (EFD): Central to event report management.
  • Event Log: Provides local storage for event records, with log capacity, log filter, and log record retrieval capabilities.
  • Log Record: Represents an individual event stored in the Event Log.
Implementation Note: The EFD discriminator construct must be defined using ASN.1 macro notation as specified in ISO/IEC 10164-5. Incorrectly defined constructs can lead to event loss or excessive reporting.

Implementation Highlights

Key Attributes of the EFD

Attribute Type Description Modifiable
discriminatorId Object Instance Unique identifier for the EFD No
administrativeState Enumerated (locked, unlocked) Controls if the EFD is operationally serviceable Yes
operationalState Enumerated (disabled, enabled) Reflects the actual ability to process events No (state machine)
discriminatorConstruct ASN.1 Discrimination Filtering expression for events Yes
destinationAddress Set of AppEntity (AE) titles Where to send matched event reports Yes
eventReportClass Object Class Specifies the event report management class Yes

Event Log Management

The Event Log managed object allows the manager to control event recording. Key attributes include:

  • logFullAction: Defines behavior when the log is full (e.g., wrap or halt).
  • maxLogSize: Maximum number of records stored.
  • logFilter: Filter to select which events are recorded.

The standard defines procedures for log retrieval and record deletion. Implementation must ensure that the log management operations perform within acceptable latency bounds to avoid backpressure on the system.

Best Practice: When deploying ERMF-based systems, carefully design the discriminator constructs to minimize overhead. Use specific filters rather than wildcards to reduce unnecessary event processing.

Compliance Notes

Conformance Requirements

To claim compliance with IEC 10164-5-95, an implementation must support the Event Report Management Function as defined. Key conformance criteria include:

  • Correct implementation of the EFD and Event Log managed object classes with all mandatory attributes and notifications.
  • Support for the mandatory services: M-CREATE, M-DELETE, M-SET, M-GET for managing EFD and Event Log instances.
  • Proper handling of the state model: combinations of administrative and operational states must behave as specified in the standard.
  • Accurate processing of the discriminator construct according to the ASN.1 definition.

Testing and Validation

Conformance testing typically involves:

  1. Base conformance test of GDMO definitions for EFD and Event Log.
  2. Service tests verifying attribute manipulation and notification generation.
  3. Discriminator construct parsing and matching tests.
  4. Interoperability tests with reference implementations.
Critical: The standard requires that when an event matches the discriminator of an EFD, the event report shall be sent via the M-EVENT-REPORT service. Failure to do so is a fundamental non-compliance. Additionally, the EFD’s operational state must be consistent with its administrative state as defined by the state transition rules.

Related Standards

IEC 10164-5-95 interacts with several other OSI management standards:

  • ISO/IEC 10164-2: State Management Function (state model for EFD).
  • ISO/IEC 10164-4: Alarm Reporting Function (alarm notifications).
  • ISO/IEC 10164-7: Security Alarm Reporting Function.
  • ISO/IEC 9595: Common Management Information Service (CMIS).
  • ISO/IEC 9596: Common Management Information Protocol (CMIP).

Frequently Asked Questions

Q: What is the relationship between IEC 10164-5-95 and ITU-T X.734?
A: IEC 10164-5-95 is technically identical to ITU-T Recommendation X.734 (1997 with amendments). The two documents share the same text and are aligned by a formal liaison agreement between ISO/IEC and ITU-T. Implementers can reference either version with equivalent results.
Q: Is the Event Log object mandatory for compliance?
A: No, the Event Log managed object is optional. However, the Event Forwarding Discriminator is mandatory. An implementation may support event reporting without local logging.
Q: Can multiple EFDs process the same event?
A: Yes, an event can be evaluated by multiple EFDs. Each EFD independently filters and forwards the event to its configured destinations. This allows for complex event distribution policies.
Q: What happens if an EFD’s destination address is unreachable?
A: The behavior depends on the EFD’s configuration and the underlying CMIP service. Typically, the event report is discarded, and the EFD may generate a notification (e.g., communications alarm). The standard does not mandate retries; it leaves this to the implementation design.

This article is based on IEC 10164-5-95 (2003) and its related references. Implementers should consult the full standard text for complete details. Last updated: 2026.

📥 Standard Documents Download

🔒
Please wait 10 seconds, the download links will appear after the ad loads

Leave a Reply

Your email address will not be published. Required fields are marked *