A signaling point is a node in a signaling network, which either originates or receives signaling messages, transfers signaling messages from one signaling link to another, or both. A signaling point that only transfers messages from one signaling link to another is known as a signaling transfer point (STP). All signaling points in a SS7 network are identified by a unique code known as a point code.

Examples of nodes in a signaling network that constitute signaling points are:

• exchanges (switching centres);
• service control points;
• signaling transfer points;
• operations, administration and maintenance centers.

The pre-determined path, consisting of a succession of signaling points/signaling transfer points and the interconnecting signaling links, that a message takes through the signaling network between the origination point and the destination point is the signaling route for that signaling relation.

All the signaling routes that may be used between an originating point and a destination point by a message traversing the signaling network is the signaling route set for that signaling relation.

To effectively manage the resources provided by an SS7 network, it is necessary to monitor and measure the present, and estimate the future performance, utilization and availability of these resources. Proprietary management interfaces typically employ a combination of measurements and alarms to monitor the current status of the SS7 Network. From these results an operator can derive the expected future performance. Measurements (or statistics) are network characteristics that are occasionally or periodically polled by management applications. Alarms, on the other hand, are used to inform management applications that an unexpected change in state has occurred within a network element. While measurement requests are explicitly initiated by management applications, the sending of alarms to management applications is automatically triggered when a particular condition becomes true.

A complete list of the potential fault, real-time, performance, network administration, accounting and configuration measurements that potentially can be invoked by a manager application are listed for MTP-L3, SCCP, ISUP and TCAP protocol layers in the ITU recommendation for monitoring and measuring SS7 networks (Reference [4]). These measurements are the raw, primitive data that potentially can be extracted from an SS7 network and utilized by a manager application. This is not an exhaustive list of measurements but rather a collection of what may be considered the measurements most desirable to collect from a monitoring, control and maintenance point of view. Recommendations are given for measurements regarding the categorization, unit of measurement, when and how often collection should be made, and whether or not it is defined as obligatory from a management point of view to present these measurements. Although this clearly defined set of statistics is contained in an international recommendation, most proprietary management interfaces only support a subset of the obligatory measurements listed.

The purpose of management is to provide a service, and this can be classified as the initial provisioning of a service, the maintaining of an existing service, and expansion or contraction of the service.

OSI defines the following management categories (Reference [10]):

• fault management
• configuration management
• performance management
• accounting management
• security management.

Of these, the first three categories are will be supported by JAIN OAM API specification Release 1.0 as the remaining two categories are for further study within the SS7 Recommendations.

Fault management encompasses fault detection, location, isolation and the correction of abnormal operation of the SS7 network. Correction of faults can in some instances require fault diagnosis. Faults can cause the network to fail to meet operational objectives (e.g. visible faults might reduce the network's traffic capacity, latent faults would reduce the network's reliability).

Fault management includes:

• Handling of alarm conditions, e.g. the failure of a signaling linkset or the inaccessibility of a signaling point.
  
  
• The activation of measurements or tests. Such actions allow correlation of reports in an attempt to resolve and isolate specific faults.
  
  
• The network-wide collection of statistics could be used by staff in preventive maintenance.

• Statistics collected about network components might be used for detection of marginal performance of those elements.

Configuration management controls the resources and collects and provides data, for the signaling network and its components. This facilitates the preparation for, and initialization of, signaling services, and allows such services to be started, continued, and stopped.

Two main activities can be distinguished:

• setting the static configuration in the SS7 network (e.g. installing and initializing SS7 components); and

• altering the configuration of the network while it is running, and providing information about its changing state.

The division of effort between the two above activities depends to some extent upon the method adopted of installing the network. A network might be nearly fully provisioned at the start, and hence dynamic changes could be limited to preserving existing service, or it could be grown from a small initial provision, and thus dynamic configuration changes would initially mainly consist of those for growth.

The JAIN OAM API specification shall employ the 'Managed Object' paradigm (see Section 3.3) that shall allow network components to be initially configured and subsequently altered using the operations provided by the managed objects. Certain operations might require higher security authorization than others (e.g. removing the last linkset from a routeset), however secure authorization is beyond the scope of the JAIN OAM API specification Release 1.0. It will be the responsibility of an implementation of the API to ensure that operation requests are processed in a secure manner.

Information regarding the changing state of network components can be provided to management applications by events emitted by the managed objects.

This enables the behavior of network resources and the effectiveness of communication activities in the network to be evaluated.

Performance management functions include:

a) collection of measurements to enable long and short term control:

• alarm monitoring;
• activation of certain measurements;
• provision of network information from these measurements regarding resource usage, e.g. route utilization;

b) medium term control of resources, e.g.:

• modification of linkset capacity (e.g. increasing the number of active links);
• modification of route capacity (e.g. coordinated increase in constituent linkset sizes);
• timer adjustments;

c) real time control of message and traffic flows in the network, e.g.:

• real time adjustment of routing tables (e.g. changing time of day routing);
• activation of additional signaling links or linkset.

Figure 2.2 depicts the relationship between JAIN OAM objects, JAIN TCAP objects and an SS7 stack. Each stack vendor shall be responsible for implementing the interaction between the JAIN objects and their SS7 stack. Whether or not two physical stacks are used for high availability shall be hidden from a JAIN application by the stack vendor's implementation.

Each Protocol layer supported has a discreet set of MOs defined. For each MO a set of attributes, allowable operations and possible alarms and statistics (events) that may be emitted by the MO shall be defined.

For each protocol layer a particular MO, hereafter known as a 'Protocol Layer MO', shall be used to create instances of any MOs belonging to that layer. Once an instance of a MO has been created an application may directly modify or inspect the characteristics of the MO using the operations the MO supplies.

An application shall express an interest in MOs belonging to a particular protocol layer of the SS7 Stack by registering with the appropriate Protocol Layer MO as an Event Listener. Once registered as a Listener, an application will be informed of state changes in any of the MOs belonging to that layer by Events sent to the application from the MOs. Note that in SS7 stack management systems these Events are frequently known as 'alarms'. For the purposes of the JAIN OAM API specification Release 1.0, the scope of the MOs supported will be limited to the MOs belonging to the MTP-2, MTP-3, SCCP and TCAP layers. An application may register as an Event Listener for more than one protocol layer. If an application registers as a Listener for more than one protocol layer, the application shall receive Events from each layer.