Basic definitions

1.5.1 OMC-R functional architecture

The OMC-R is a BSS subsystem manager that performs mediation functions and provides a Q3 interface:

• The OMC-R manager enables exchanges with users through the Man-Machine interface, and with the OMC-R agent through the Q3 interface.

• The OMC-R agent enables exchanges with the BSSs through the OMN interface and provides mediation functions between managed objects on the Q3 interface and managed objects on the OMN interface.

The notifications are forwarded from the md to the local manager using a pseudo Q3 interface. Whereas the notifications sent to the external managers are correlated, those sent to the local manager are un-correlated.

Thus the flood of notifications is faster for the local manager, whichever is the response delay of the external managers.

Figure 2 OMC-R design

1.5.2 Objects

BSS and OMC-R interchanges are based on an object model definition. All the transactions between BSSs and OMC-R and between OMC-R agent and manager use a specific application data description.

The managed objects check the managed object defined by ISO (ISO/IEC 7498-4 OSI - Basic reference model - Management framework):

"A managed object is defined in terms of its parameters, the operations it can perform, the notifications it can issue, and its relationship with other objects".

The OMC-R manager recognizes the BSS subsystem by the objects that describe it on the Q3 interface (as the user sees the objects on the Man-Machine interface). The OMC-R agent recognizes the BSS subsystem by the objects that describe it on the Q3 and OMN interfaces.

BSS subsystems and OMC-R agent are described by objects managed on the Q3 interface. Each object describes a function or an equipment.

1.5.3 Databases

Objects are managed in two databases which are illustrated inFigure 3

"Operations database and application database" (page 33).

• The OMC-R operations database (BDE) is the main database. It is managed by the OMC-R and built as the objects are created. It is stored on the OMC-R agent disks.

The BDE is automatically updated after each operation and contains all the BSS objects, and certain specific OMC-R objects that are not known to the BSC.

• The BSC application database (BDA) is stored on the BSC disk. It is built from the BDE. The BSC database building operation is controlled by users.

To allow the system to function correctly, the two databases must be consistent. Users can check their consistency by using an auditing

command. The system warns the user if the two bases are inconsistent, by sending a specific message in response to the command.

Figure 3

Operations database and application database

1.5.4 Object classes and instances

An object, as defined above in terms of parameters, operation notifications, and relationships is a generic object. The same information structure describes same-kind individual objects that can be configured and behave differently.

For example, the same information structure is used to describe all the bts objects modelling the radio cells under OMC-R management control.

The description differentiates a non-operational cell C1 configured with two TRX/DRXs at a given time from an operational cell C2 configured with four TRX/DRXs at the same time.

To avoid any ambiguity between the generic object and the individual object, a difference is made between the object class and the object instance. In the example above, C1 and C2 are both instances of the bts object class.

1.5.5 Parameters

All the objects in a same class are described in the same way by a set of parameters. The values of these parameters vary according to the object.

There are three kinds of parameters:

• Permanent parameters, which are defined by the users

They are recorded in the BDE and BDA databases. Most of them are mandatory and are defined with the object that uses them. Some of them are optional and their value depends on the radio subsystem configuration. They are designated by the abbreviation DP (Permanent Data) in this NTP.

• Dynamic parameters, which are not controlled by the users They are not controlled by users. They are not recorded in the

databases. The BSC manages dynamic parameters that are updated by BSC applications and can be consulted on request. They are designated by the abbreviation DD (Dynamic Data) in this NTP.

• Internal parameters, which are managed from the OMC-R

They are recorded in the BDE database and cannot be modified by users. They supply additional information on the object configuration at a given time and can be consulted on request. They are designated by the abbreviation DI (Internal Data) in this NTP.

For more information on parameters:

• In alphabetical order, refer to NTP <124>.

• Grouped according to the objects, refer to NTP <128>.

1.5.6 Operations

Operations on objects are commands that the user sends to the OMC-R on the Man-Machine interface. They allow users to communicate with the OMC-R and update the databases when necessary.

The OMC-R checks the command semantics before forwarding the commands to the BSC to ensure that it only receives commands that are likely to be correctly executed.

The same set of operations apply to all the objects in a given class. The main types of operation are as follows:

• Create an object.

• Delete an object.

• Lock or unlock an object.

• Set an object’s permanent parameters.

• Display an object’s permanent and internal parameters.

• Display an object’s permanent, internal, and dynamic parameters.

• Audit a BDA to check consistency.

• Perform an action on an object.

1.5.7 Unsolicited messages

Unsolicited messages sent by the managed objects are translated into notifications that provide users with information on network operating conditions.

The same types of message apply to all the objects in a given class. These messages are grouped as follows:

• software anomaly

• hardware fault

• warning

• state change

• parameter value change

• restart

• BIST result

• purge

• observation

• trace

• build BDA request