home *** CD-ROM | disk | FTP | other *** search
-
-
-
-
-
- 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
-
-