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:
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.

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
	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, § 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 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 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
–	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.

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.

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 § 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 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 §§ 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, § 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 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 § 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.
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.