7 Itf‑N Interface

32.106-13GPPConfiguration Management (CM)Part 1: Concept and requirementsRelease 4Telecommunication managementTS

7.1 CM principles

The Itf‑N (see ref. 3G TS 32.102 [2]) is an object oriented interface, i.e. all resources of the 3G network (functional and physical resources) whose management is standardised by the present document are represented as Managed Object Instances (MOI) of a Network Resource Model (NRM).

The NRM shall be highly simplified for the purpose of the NM, based on the assumption that all of the detailed CM actions, including fault correction after one or more alarms, are performed by an Element Manager (EM), which knows the vendor-specific NRM and configuration.

The NRM identifies the basic Network Resources (NRs) to the level of detail required by FM and PM at the Network Management (NM) level. In addition to NR identification, the NRM also supports the alarm surveillance part of FM by defining which alarms can be notified by which Managed Object Classes (MOCs).

The definition of the Network Resource Model (NRM) for the Itf‑N (connecting the NM with a "subordinate entity", which may be an EM or a NE) is described in 3G TS 32.106-5 [3], which defines the Basic CM IRP Information Model including the NRM applicable to UMTS management.

This clause describes the specific functional requirements related to CM of Network Resources (NRs) on the Itf‑N, which may be classified in two main groups:

  • Passive CM (configuration overview), which mainly provides to the NM current information about the current configuration changes and allows a retrieval and synchronisation of configuration related data on NM request.

    The forwarding of these notifications over the Itf‑N is controlled by means of configuring adequate filtering mechanisms within the subordinate entities. The Itf‑N also provides the means for storage ("logging") and later retrieval of desired information within the subordinate entities.

  • Active CM, which offers to the NM operator a real capability to change the current network configuration.

7.2 Overview of IRPs related to CM

The Itf‑N for CM is built up by a number of Integration Reference Points (IRPs) and a related Name Convention, which realise the functional capabilities over this interface. The basic structure of the IRPs is defined in [1] and [2]. For CM, a number of IRPs (and the Name Convention) are defined herein, used by this as well as other specifications For Telecom Management (TM) produced by 3GPP. All these are included in Parts 2 through 8 of the present document as follows:

Notification IRP Information Service Version 1: 32.106 Part 2

Notification IRP CORBA Solution Set Version 1:1: 32.106 Part 3

Notification IRP CMIP Solution Set Version 1:1: 32.106 Part 4

Basic Configuration Management IRP Information Model (including NRM) Version 1: 32.106 Part 5

Basic Configuration Management IRP CORBA Solution Set Version 1:1: 32.106 Part 6

Basic Configuration Management IRP CMIP Solution Set Version 1:1: 32.106 Part 7

Name Convention for Managed Objects: 32.106 Part 8

7.3 Passive CM

7.3.1 Real-time forwarding of CM-related event reports

During normal operation the NM is continuously informed by the managed subordinate entities about all network configuration changes, in accordance with the Network Resource Model (NRM) applied on the Itf‑N. For this purpose the following CM-related event reports with regard to the ITU-T Recommendation X.721 [4], ITU-T Recommendation X.730 [5] and ITU-T Recommendation X.731 [6] are forwarded to the NM:

  • Object creation;
  • Object deletion;
  • Attribute value change.

The real-time forwarding of these event reports occurs via appropriate filtering mechanisms ("discriminators" on CMIP interfaces, "subscription" on CORBA interfaces) located in the subordinate entity in accordance with ITU-T Recommendation X.734 [7] or OMG event/notification service. These filters may be controlled (i.e. created, modified and eventually deleted) locally in the subordinate entities or remotely by the NM (via the Itf‑N) in order to ensure that only the event reports which fulfil pre-defined criteria can reach the superior NM. In a multiple manager environment each NM may have its own filtering mechanism within every subordinate entity, which is able to generate CM-related notifications.

It should be possible to pack multiple notifications together for sending to NM. This provides more efficient use of data communication resources. In order to pack multiple notifications, an EM/NE configurable parameter defines the maximum number of notifications to be packed together. Additionally an EM/NE configurable parameter defines the maximum time delay before the notifications have to be sent.

7.3.2 Retrieval/synchronisation of CM-related information on NM request

As long as the network is in operation and fault free, the update of the CM-related information on NM level is continuously ensured by the real-time forwarding of concerned reports as described in subclause 7.3.1. In case of faults (either on the NM or in a subordinate entity or on the communication link) it is possible that some CM-related event reports are lost. Therefore the CM-related information on the NM may become non-aligned with the real configuration of the network (depending on the strategy of the NM where to store network configuration information). In this case a synchronisation process may be necessary to align the CM-related information of the NM with the configuration information of the subordinate entities.

The retrieval or synchronisation ("alignment") of network configuration information between the NM and one or more of its subordinate entities can be triggered at any time by the NM.

There are two different alternatives for this synchronisation:

  • via a read command with appropriate filtering;
  • as an ordered sequence of CM-related event reports.

7.4 Active CM

In Release 99 of the present document it is assumed that active CM is a task that can be performed only by the Element Managers (EMs) and/or local maintenance terminal actions. Thus it is outside the scope of the present document.

Annex A (informative):
Change history

Change history



TSG Doc.






Mar 2000



Approved at TSG SA #7 and placed under Change Control



Mar 2000




Jun 2000




Split of TS – Part 1: Main part of spec – Concept and Requirements



Mar 2001


Automatic upgrade to Rel-4