home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Internet Standards
/
CD2.mdf
/
ccitt
/
1992
/
q
/
q544.asc
< prev
next >
Wrap
Text File
|
1991-12-30
|
44KB
|
859 lines
All drawings appearing in this Recommendation have been done in Autocad.
Recommendation Q.544
DIGITAL EXCHANGE MEASUREMENTS
1 General
This Recommendation applies to digital local, combined, transit and
international exchanges for telephony in Integrated Digital Networks (IDN) and
mixed (analogue/digital) networks, and also to local, combined, transit and
international exchanges in an Integrated Digital Networks (ISDN). The field of
application of this Recommendation is more fully defined in Recommendation Q.500.
Some measurements only apply to a certain type (or types) of exchange. Where this
occurs, the application is defined in the text. Where no such qualification is
made, the measurement applies to all exchange applications.
This Recommendation includes traffic and performance measurements that are
necessary for provisioning and operating exchanges so as to satisfy grade of
service objectives covered in the E.500 series of Recommendations. These
measurements are typically performed during specified periods and intervals after
which the results are sent to designated local and/or remote exchange terminals
or operation and maintenance centres (OMC) or any other appropriate data handling
centre. In some cases, data may be utilized in its original form whereas in other
cases data may need to be processed to determine when pre-set thresholds are
exceeded and/or to recognize an abnormal condition when it occurs. In this
Recommendation, no particular system design requirement is implied. Different
designs may have more or less data accumulated and processed within the exchange
or by an external system.
Different types and sizes of exchanges may require different sets of
measurements. Also, different Administrations may have different requirements for
measurements depending on policies, procedures or national network
considerations. An Administration may thus find it desirable in some applications
to measure items that are not covered by this Recommendation whereas in other
applications some measurements may not be desired.
Exchange measurements are required for both national and international
service. Requirements for international service take into consideration the
following CCITT Recommendations:
- Recommendations E.401 to E.427: International telephone network
management and checking of service quality;
- Recommendations E.230 to E.277: Operational provisions relating to
charging and accounting in the international telephone service.
The aspects of traffic engineering are given in Recommendations E.500 to
E.543. Recommendations on traffic meaurements for SPC exchanges are provided by
Recommendations E.502, E.503 and E.504.
Additional measurements in an exchange, not specified in this
Recommendation, are required, e.g. for:
- Transmission performance (Recommendations Q.551, Q.552, Q.553 and
Q.554).
- Digital access signalling (Recommendations Q.920 to Q.931). This is for
further study.
- Packet mode (Recommendations X.25 and X.75). This is for further study.
- Signalling System No. 7 (e.g. those measurements specified in
Recommendation Q.791 for the message transfer part require further
study to determine their applicability to this Recommendation).
Note - For the terms and definitions of teletraffic used in this
Recommendation, see Recommendation E.600.
2 Measurement processes
2.1 General
The activities involved in exchange measurements can be split in four
processes as represented by Figure 1/Q.544.
Figure 1/Q.544 - CCITT 72180
On choice of each individual national Administration, the above four
processes can be fully or partially integrated into the exchanges.
It is nevertheless recommended that:
Fascicle VI.5 - Rec. Q.544 PAGE1
a) data collection be fully integrated into the exchange for all types of
data;
b) data presentation be integrated into the exchange and/or at the O&M
centre at least for the measurements required by O&M personnel.
Presentation of data required for planning and administration activities
could be performed at the O&M personnel premises or in other locations which
could be more centralized and generally takes place at a deferred time.
2.2 Data collection
Three different activities of data collection can be identified:
- event registration;
- traffic registration (traffic intensity and/or volume of traffic);
- call records registration.
The data generated by event registration and traffic registration are
suitable for direct utilization (immediate presentation).
Call records can only be utilized after off-line analysis. Processing of
call records can generate any type of data, including the event registration and
traffic registration.
2.3 Bulk data storage, analysis and processing
Data storage for collected data can be required for accumulation of a
massive data base suitable for subsequent analysis and processing.
These data can be held in the exchange for processing at the exchange
location or transferred to administrative and engineering centres.
PAGE14 Fascicle VI.5 - Rec. Q.544
2.4 Data presentation
It is the function through which the collected data are becoming readable.
Features related to the data presentation are:
a) location of presentation;
b) time frame of presentation. It is dependent on the nature of the data
and their utilization. The activities of maintenance and network
management require immediate presentation;
c) physical support of the displayed data and relevant format. These
aspects are mainly related to the type of data and are to be left to
individual implementations.
3 Types of measurement data
Measurement data primarily consists of counts of various events and the
traffic intensity on various resources. For certain measurement data, sampling,
or time averaging techniques may provide an acceptably accurate result. In some
cases, externally generated test calls may provide the most practical method of
obtaining the data. In other cases, call records, such as detailed charging
records, may be used.
3.1 Event counts
Events, for example incoming seizures, call attempts encountering busy,
and call attempts to specified destination codes should be countable. Some event
counts may be accumulated over the whole exchange whereas others may be
accumulated only over a subset such as an inter-exchange circuit group. In some
cases, event counts may be accumulated several ways.
3.2 Traffic intensity
Traffic intensity on a pool of resources is the traffic volume divided by
the duration of observation. It is thus equal to the average number of busy
resources. As in the case of event counts, traffic intensity data may be for the
whole exchange or for various subsets.
3.3 Call records
Call records contain data used by the exchange for the setting up of
calls. The data may include the identity and classification of the originating
line or incoming circuit, the dialled number, the call routing and disposition,
and possibly the time of occurrence of certain events during the entire call
period.
Call records can be generated and outputted by the exchange to allow the
establishment of a data base suitable for off-line processing to determine
traffic values and characteristics. Output of the call records associated with a
statistical sample of total calls may be sufficient for this purpose.
4 Measurement administration
Exchanges should provide capabilities for operating personnel to establish
measurement schedules and direct the output routing of measurement results. The
methods of establishing measurement schedules should be designed to minimize the
introduction of errors when defining relevant parameters. It should be possible
to have a number of measurements simultaneously active with different schedules
and output routings. A single measurement should be capable of having more than
one measurement schedule and/or output routing simultaneously. The number of
measurement types running concurrently may be limited to conserve exchange
storage and processing resources. Criteria for measurement and recording of
traffic may be found in Recommendation E.500 and other related E-Series
Recommendations.
4.1 Scheduling
4.1.1 Recording periods
A recording period is the time interval during which a measurement is
performed. Measurements can be activated either on-demand or according to a time
schedule.
Different measurement periods may be schedulable for different days of the
week. For example, a measurement may be scheduled for 0900 to 1800 on Monday
through Friday and 0900 to 1200 on Saturday. The measurements for an entire week
may be programmed and the weekly cycle may be repeated until a new command will
stop it.
4.1.2 Result accumulation periods
Fascicle VI.5 - Rec. Q.544 PAGE1
A recording period contains one or more result accumulation periods. The
beginning and ending of the recording period must correspond to the beginning and
ending of result accumulation periods.
The measurement result outputs are to be made available at the end of each
result accumulation period and shall refer to that period.
More than one result accumulation period may be required for an individual
measurement.
4.2 Data output criteria
4.2.1 On schedule
Measurement data output typically occurs shortly after the end of each
result accumulation period specified by the measurement schedule. Alternatively,
the exchange may store the data in its memory for limited periods, e.g. in the
event of contention for output resources.
4.2.2 On demand
(For further study.)
4.2.3 On exception
The exchange should be able to provide measurement data when specified
criteria are met, for example, when the rate of incoming call attempts exceeds a
particular value.
4.3 Data output routing
4.3.1 To a local or remote terminal
Measurement data should be able to be routed for printing or display on
designated terminals which are either directly connected to the exchange or
remotely connected via dedicated or switched circuits.
4.3.2 To an external processing centre
Measurement data should be routable to external locations such as OMC that
provide data collection and analysis functions for multiple exchanges.
4.3.3 To local storage media
An Administration may require exchanges to store measurement data in bulk
memories such as magnetic tapes for later processing and analysis. This could be
an alternative to sending the data to an OMC.
4.4 Priorities
High priority should be assigned to certain measurements that are
essential, e.g. those associated with collection and output of data used for
overload detection, network management and accounting. These should not be
discontinued during periods of exchange processing congestion (see Recommendation
Q.543, S 3.8). Measurements that have been suspended should be resumed in an
order that is reverse to the order in which they were suspended.
When recovery procedures are invoked, records associated with call
accounting and billing should be retained.
5 Application of measurements
5.1 Planning and engineering
Measurement data is essential for planning efficient telecommunication
networks that meet specified grade-of-service standards. Analysis of data
accumulated over a period of time provides information needed to forecast future
demand and to plan and engineer extensions to the network.
5.2 Operation and maintenance
Operation and maintenance functions are supported by the following types
of measurement data:
i) performance data pertaining to call handling irregularities and delays;
ii) availability data for the exchange, its subsystems, and its connecting
subscriber lines and interexchange circuits;
iii) load on various components of the exchange.
The above data may be used to evaluate exchange and network performance
and to plan rearrangements to improve the service provided by the existing
network equipment.
5.3 Network management
Data for network management includes certain traffic and performance
measurements and status indications. These are used to detect abnormalities in
the network and to automatically enable, or allow manual operation of, network
management controls. In some cases, the data must be analyzed to determine
whether specified thresholds are being exceeded. Since the effectiveness of
network management actions depends upon their responsiveness to changing
conditions in the network as a whole, it may be appropriate to perform this
analysis by a data processing system serving one or more exchanges and display
PAGE14 Fascicle VI.5 - Rec. Q.544
the results at a network management centre. Network management functions are
covered in Recommendations E.410 through E.414 and Q.542.
5.4 Accounting in international service
Accounting in international service needs to be mutually agreed between
Administrations; Recommendations E.230 to E.277 apply.
5.5 Subdivision of revenue
Subdivision of revenue is a matter of agreement between RPOAs of the same
country. Requirements in this area are a national matter.
5.6 Tariff and marketing studies
The studies are intended to identify subscriber needs and trends.
Requirements in this area are a national matter.
6 Call events definition
This section is applicable to 64 kbit/s circuit switched call attempts.
Application to other types of calls or Supplementary Services is for further
study.
6.1 General
Every call attempt coming from a subscriber line or interexchange circuit
moves across a branch of the possible status of call events reference diagram
shown in Figure 2/Q.544.
6.2 Call events detailed description
6.2.1 Seizure from a subscriber line or incoming circuit
This is the starting point for an incoming/outgoing call attempt.
6.2.2 Valid address
The incoming/originating seizure is successfully accepted by the exchange.
6.2.3 Not routed call attempt
A call attempt that is not routed through the exchange, perhaps due to an
exchange condition or to receipt of an address that is incomplete or invalid.
6.2.3.1 False start
An incoming seizure signal that has been recognized without being followed
by digit reception.
6.2.3.2 Incomplete dialling (time out, abandon)
An incoming seizure that has been received but the number of received
digits is not sufficient to perform call routing.
6.2.3.3 Invalid address
An attempt where the received digits do not correspond to an existing or
allowed destination. The call is then given interception treatment (tone or
announcements or operators).
6.2.3.4 Call not routed due to the exchange
A call attempt where the system cannot perform call routing due to
internal reasons (congestion):
1) Blocking through the switching network
Although there is an outgoing circuit/subscriber line available for the
required destination, the connection cannot be realized through the
switching network, and no further routing choices are available.
2) Unavailability of common resources
Unavailability of service circuits or other common resources (e.g.
memory areas)
3) System faults
Presence of some internal fault in the exchange.
Figure 2/Q.544 - T1107780-87
6.2.4 Calls routed to interexchange circuits
These calls are successfully routed to an outgoing circuit available for
the required destination or routed to another circuit group for overflow reasons.
When making overall exchange measurements, these calls can be counted all
together.
6.2.4.1 Seizure of outgoing circuit
These are calls that are routed to a specific circuit. They have to be
separately counted when making measurements on the outgoing circuit group.
6.2.4.2 Overflow to next circuit group
These are calls that cannot be routed on a specific circuit group but are
Fascicle VI.5 - Rec. Q.544 PAGE1
routed to a subsequent routing-choice circuit group. They have to be counted
separately when making measurements on the outgoing circuit group. Measurement of
the subsequent events associated with these calls are only associated with
circuit group on which the calls are routed.
6.2.5 Calls not routed due to network conditions
6.2.5.1 Calls in overflow from the last routing choice (all circuits busy)
These are calls on which the system cannot perform routing due to the
unavailability of outgoing circuits towards the required destination.
6.2.5.2 Calls blocked by network management controls
These are call attempts that are suppressed by the exchange as a
consequence of the application of network controls.
6.2.6 Successful backward call set-up signal
These are calls for which a backward signal is received, indicating the
conclusion of call routing at a remote exchange, but not answered. The set of
signals typically includes:
- end of selection
- address complete
- subscriber line free
6.2.7 Unsuccessful call attempts
6.2.7.1 Receiving an unsuccessful backward call set-up signal
This occurs when a backward signal is received indicating the
impossibility of setting up the call.
These backward signals typically are:
- congestion signals
- subscriber line busy signals
- signals defined as part of the UBM (Unsuccessful Backward set-up
information Message) group of messages in CCITT Signalling System No.7
(see Recommendation Q.723).
6.2.7.2 Not receiving a backward call set-up signal
These are calls that are abandoned or forced-out before reception of any
backward call set-up signal. They include:
- calls abandoned by the calling party
- calls forced out by the expiration of timers.
Note that within these categories of calls there are several types of call
disposition that cannot be distinguished by the exchange since they may be
characterized by tones, announcements or the lack thereof, for instance:
- ring-back tone
- busy tone
- congestion tone
- announcements
- no tones or announcements
- incompletely dialled calls
6.2.8 Calls routed to subscriber line
These are call attempts that are successfully routed to a subscriber line.
6.2.9 Calls not routed due to called line conditions
These are unsuccessful call attempts which do not reach answer status due
to the particular condition of the called subscriber line:
- busy
- out-of-service
- rerouted call
- no free outlet
- etc.
6.2.10 Answered calls
These are calls that reach the "answered" status. Depending on the
signalling protocol answered status can be reached in one of the following ways:
- reception of an answer signal
- reception of a metering pulse
PAGE14 Fascicle VI.5 - Rec. Q.544
- immediate answer status on seizure (of the subscriber line/outgoing
interexchange circuit).
The following events are not included in this class of calls:
- reception of Re-answer signal
- answer from an intercepting device (automatic or manual) due to call
diversion at the transit exchange.
6.2.11 Not answered call attempts
These are calls on which an answer signal is not received after a
successful backward signal has been received, or after the seizure of the called
subscriber line. These include:
- calls forced-out by the expiration of timers
- calls abandoned by the calling party after listening to ring-back tone.
7 Traffic measurements
This section is applicable to 64 kbit/s circuit switched traffic.
"Application to other types of traffic or supplementary services is for further
study."
7.1 General
Traffic in an exchange can be categorized as shown in Figure 3/Q.544. All
measurements listed in this section can be obtained by recording and analyzing
events that can be experienced by calls.
Figure 3/Q.544 - CCITT 69130
It is not intended that every exchange should be required to make all the
different measurements in this Recommendation. Due to the application of various
signalling methods and differing switching system designs, some variation of the
measurements might be appropriate in a specific exchange. For example, an
Administration may require more detailed counts of events to permit a meaningful
call failure analysis on a specific exchange. Furthermore, the traffic categories
to which any measurement relates may vary depending on system design, on system
application and measurement utilization.
Measurements may be combined into sets appropriate to a specific type of
exchange, for example, local or transit. In particular, Administrations may
consider that, by the use of a few measurement sets, it is possible to satisfy
the majority of their requirements.
7.2 Overall measurements
The following measurements are applicable to the total traffic of an
exchange. Due to possible variations in sytem design, the traffic categories to
which any measurement relates may vary from that shown in the following text.
Figure 3/Q.544 illustrates the exchange traffic categories.
7.2.1 Originating traffic
a) Originating call attempts.
b) Invalid call attempts for example:
- no dialling,
- incomplete dialling,
- invalid number dialled.
c) Call attempts not routed due to the exchange, for example, due to:
- blocking through the switching network,
- unavailability of common resources,
- system faults.
d) Internal call attempts.
7.2.2 Incoming traffic
a) Incoming seizures.
b) Invalid call attempts for example:
- incomplete dialling,
- invalid number dialled.
Fascicle VI.5 - Rec. Q.544 PAGE1
c) Call attempts not routed due to the exchange, for example, due to:
- blocking through the switching network,
- unavailability of common resources,
- system faults.
d) Transit call attempts.
7.2.3 Terminating traffic
a) Call attempts routed to subscriber lines.
b) Call attempts not routed due to line condition.
7.2.4 Outgoing traffic
a) Outgoing call attempts routed to an interexchange circuit.
b) Call attempts not routed due to network condition.
c) Unsuccessful call attempts.
7.2.5 Service utilization
The exchange should be able to measure the utilization of each type of
basic and supplementary service it provides. The mix of services and the
corresponding exchange measurements depends upon switching system capabilities
and Administration policies.
7.3 Interexchange circuit groups
The measurements apply to individual circuit groups. All circuit groups
should be measurable. For traffic intensity, it may be desirable to measure all
circuit groups simultaneously. Information for estimating the average number of
circuits in service during the result accumulation period should be provided in
addition to the traffic data for each circuit group.
7.3.1 Incoming traffic
Incoming traffic is understood to be:
- the traffic on incoming circuit group,
- the incoming traffic on both-way circuit groups.
The following parameters should be measured:
a) traffic intensity,
b) number of seizures.
7.3.2 Outgoing traffic
Outgoing traffic is understood to be:
- the traffic on outgoing circuit groups,
- the outgoing traffic on both-way circuit groups.
The following parameters should be measured:
a) traffic intensity,
b) number of seizures,
c) number of call attempts overflowing from the group,
d) answered call attempts.
PAGE14 Fascicle VI.5 - Rec. Q.544
7.4 Subscriber line groups
These measurements are applicable to groups of subscriber lines that share
switching network access paths. The lines served by a particular line
concentration unit of a local exchange would be an example of such a group. In
systems where traffic levels on such line groups could result in failure to meet
grade of service objectives, appropriate measurements for load balancing purposes
should be provided.
a) Originating calls
i) Number of call attempts
ii) Number of call attempts resulting in an outgoing seizure
iii) Number of answered calls
iv) Traffic intensity
b) Terminating calls
i) Number of call attempts
ii) Number of answered calls
iii) Traffic intensity
c) Internal (e.g. intra-concentrator calls)
i) Number of call attempts
ii) Number of answered calls
iii) Traffic intensity
7.5 Auxiliary units
Auxiliary units provide functions such as multifrequency signalling,
tones, announcements, and access to operators. Grouping of auxiliary units may
vary with system implementation characteristics. Groups in this section refer to
system independent functional groups. Some systems may allow calls to wait for an
auxiliary circuit of one is not immediately available.
The measurements indicated below are intended to provide information for
the dimensioning of auxiliary units. They should be provided for each group which
may require dimensioning. Measurements may be activated for any specified list of
auxiliary units. Information for estimating the average number of units in
service during the result accumulation period should be provided in addition to
the traffic data for each circuit group:
a) traffic intensity,
b) number of seizures,
c) number of bids not served.
7.6 Control unit(s)
These measurements are highly system dependent and therefore no specific
recommendations can be made. However, it is essential that systems will have
provisions for determining the utilization of control equipment, such as
processors, for dimensioning, planning, and grade of service monitoring of the
exchange.
7.7 Call attempt destinations (see also S 9.3)
These measurements are used to assess the probability of success on calls
to various destinations and may be used in deciding on any network management
actions considered necessary. The number of destination codes specified for
measurement at any one time may be limited. For any specified destination code,
the following parameters should be measured:
a) number of call attempts,
b) number of call attempts resulting in an outgoing seizure,
c) number of answered calls.
Intensity measurements for specified destination codes may be required by
some Administrations for traffic engineering purposes.
8 Exchange performance and availability measurements
8.1 Performance measurements
For monitoring the exchange grade of service, a certain number of
parameters should be observed. They may include the measurements given in
Recommendation E.543 for delay grade of service monitoring. However, other
processing delays (see relevant paragraphs of Recommendation Q.543) may be
observed for complete monitoring of the exchange grade of service.
Measuring processing delays on a per call or statistical basis could be
burdensome to the exchange. Moreover, some processing delays may not be
Fascicle VI.5 - Rec. Q.544 PAGE1
measurable with an acceptable time accuracy and others may not be easily measured
by the exchange itself.
Operating procedures of Administrations will impose constraints on the
accuracy of the measurements for grade of service monitoring purposes. When such
accuracy requirements allow, it may be possible to measure processing delays on a
sample or test call basis. Requirements in this area are therefore a national
matter.
8.2 Availability measurements
The exchange should record the beginning and ending time of all detected
instances during which service is unavailable to one or more exchange
terminations. The recorded information should permit the determination of the
number and identity of terminations affected if possible.
9 Data for network management
9.1 General
Procedures for network management are specified in Recommendations E.410
through E.414. Those procedures make use of data from exchanges to determine
overall network performance and, when required, appropriate control actions. Much
of the data required for network management is also needed for other operation
and maintenance functions. However, effective network management requires control
actions to be executed quickly in response to changing network and traffic
conditions. Therefore, exchanges that Administrations have designated to provide
network management functions must be able to provide traffic and status data to
other exchanges and network management centres on a pre-arranged basis or when
triggered by a specific event, such as an overload condition. The network
management functions provided by any specific exchange will depend upon factors
such as its size, position in the network, and Administration policies.
Details of traffic measurement requirements for network management are
found in Recommendation E.502. Most of the information required for network
management operations can only be generated by the exchanges and consist of two
general categories of data:
a) Network status information, for example:
- busy/idle status of circuit groups
- individual equipment's availability
- alarms
- network management action (controls) in effect
Status information generally does not require measurements.
b) Network traffic load and performance information, for example:
- number of bids per route per hour
- answer/seizure ratio per route per destination.
This type of information requires "real-time" monitoring of network
performances via exchange measurements, and it is specifically the subject of
this part of the Recommendation. The objects and entities of measurement are
given in full details by SS 9.2, 9.3 and 9.4.
The exchange generated information can be:
- utilized at the source exchange, if network management actions are
taken locally,
- transmitted to other exchanges or elements of the TMN (typically to
network management centres) for possible network management actions.
It should be noted that exchange internal overload controls are
complementary to network management functions, and the information generated by
the internal overload monitoring system can also be used for network management
functions. Exchange performance under overload conditions is dealt with in
Recommendation Q.543, S 3.
9.2 Management on interworking circuit groups
9.2.1 General
Performance monitoring of interexchange circuit groups for network
management purposes should be performed on outgoing traffic. This is where the
offered and routed traffic can be seen.
Circuit group monitoring should be organized on the basis of individual
interexchange circuit groups. It should be possible to monitor the performance of
all circuit groups. However, the number of circuit groups to be monitored
simultaneously at an exchange and the length of data accumulation periods will
depend on many aspects of the network management implementation and the function
of the exchange in the network. For example, a large transit exchange may require
performance monitoring on a large percentage of its outgoing circuit groups while
PAGE14 Fascicle VI.5 - Rec. Q.544
a local exchange may only require monitoring on a few groups.
It should be possible to readily activate/deactivate measurements on
circuit groups.
9.2.2 Entities to be measured on interexchange circuit groups
The following measurements should be made on outgoing interexchange
circuit groups for network management purposes:
a) outgoing bids (see Note)
b) outgoing seizures (see Note)
c) overflow bids (see Note)
d) answers received
e) count of calls affected by network management circuit group controls.
Note - Any two of these measurements are necessary. The third can be
derived from the other two.
9.2.2.1 Additional measurements required on international circuit groups at
international transit exchanges
- transit bids (international traffic only)
- incoming seizures (international transit traffic only).
9.2.3 Calculated network performance parameters
The entities of measurement in S 9.2.2 can be used to calculate all the
network management performance parameters required for network management on the
basis of (Draft) Recommendation E.411 as follows:
a) bids per circuit per hour
b) seizures per circuit per hour
c) percentage overflow
d) answer/seizure ratio
e) answer/bid ratio
f) mean holding time per seizure.
Depending on the type of network management implementation the network
performance parameters can be calculated at the source exchange, or in other
elements of the TMN, consistent with the distribution of the network management
functions in the TMN.
9.3 Measurements on call destinations
9.3.1 General
Depending on the network management implementation and the function of the
exchange in the network, the exchange should be able to make traffic measurements
to different numbers of destinations indicated on a preliminary basis to be
critical destinations. Call destinations can be represented by country codes,
area codes, exchange codes or any combination of them.
Measurement by destination is essential for the implementation of the
hard-to-reach network management feature. Typically, traffic measurements by
destination will be limited to a predetermined set of destination codes (e.g.
country or area code). It should be possible to readily expand the scope of the
measurements within a focused area when certain thresholds are exceeded.
9.3.2 Entities to be measured on call destinations
The following are the entities that should be measurable per destination
for network management purposes:
a) outgoing bids;
b) outgoing circuit seizures;
c) answers;
d) counts of calls affected by network management controls by type of
control.
9.4 Measurements on exchange resources
9.4.1 General
The exchange should be able to monitor the level of utilization of its own
common resources, like processing capacity, call registers, hardware units such
as digit senders and receivers, etc., in order to provide the information on
exchange congestion level to the network management function (see Recommendation
E.411).
Since the common resource monitoring function is also required for
overload protection purposes, the same mechanisms of measurement can be used for
both functions, namely, exchange overload protection and network management.
Fascicle VI.5 - Rec. Q.544 PAGE1
9.4.2 Objects and entities to be measured on exchange resources
The objects and entities of exchange resources to be measured depend on
the system architecture. The decision concerning which kind of specific objects
and entities should be measured is therefore left to individual Administrations
or Operating Agencies.
PAGE14 Fascicle VI.5 - Rec. Q.544
