delim @@
| 5i'
|
SECTION 3 DESIGN OBJECTIVES AND MEASUREMENTS |
DIGITAL EXCHANGE DESIGN OBJECTIVES -- 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 Services Digital Network (ISDN). The field of application of this Recommendation is more fully defined in Recommendation Q.500. Some objectives 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 objective applies to all exchange applications.
The exchange and/or any associated operations and maintenance systems/centers shall have the capabilities needed to allow the exchange to be operated and administered efficiently while providing service in accordance with an Administration's performance requirements.
2.1 Exchange modifications and growth
The exchange should be capable of having hardware and/or software added or changes made without causing a significant impact on service (see §§ 4.4, 4.10.2 -- Planned outages).
2.2 Service provisioning and records
There should be efficient means of establishing service, testing, discontinuing service and maintaining accurate records for:
-- subscriber lines and services,
-- interexchange circuits.
2.3 Translations and routing information
Fascicle VI.5 -- Rec. Q.541 1
There should be efficient means of establishing, testing and changing call processing information, such as translation and routing information.
2.4 Resource utilization
There should be efficient means of measuring performance and traffic flows and to arrange equipment configurations as required to insure efficient use of system resources and to provide a good grade of service to all subscribers (e.g., load balancing).
2 Fascicle VI.5 -- Rec. Q.541
|
2.5 |
Physical design objectives The exchange shall have a good physical design that provides: -- adequate space for maintenance activities, -- conformance with environmental requirements, -- uniform equipment identification (conforming with the Administration's |
requirements), |
|
|
-- a limited number of uniform power up/down procedures |
for all component parts of the exchange. |
||
3.1 Exchange timing distribution
The timing distribution system of an exchange will be derived from a highly reliable exchange clock system. The distribution of timing within the exchange must be designed so that the exchange will maintain synchronism on 64 kbit/s channel timeslots in a connection through the exchange.
3.2 Network synchronization
Within a synchronized IDN/ISDN, different methods of providing timing between exchanges may be used. An exchange should be able to be synchronized:
a) by an incoming digital signal at an interface A (or B, if provided) as defined in Recommendation Q.511; this applies only to signals derived from a Primary Reference Source, as defined in Recommendation G.811;
b) directly by a Primary Reference Source, using an interface complying with Recommendation G.811;
c) optionally, by an analogue signal at one of the frequencies listed in Recommendation G.811.
Plesiochronous operation should also be possible.
The clock of the local, combined or transit exchange shall be responsible for maintaining the synchronization in the part of the network associated with that exchange.
The timing performance of the clocks in local, combined or transit exchanges should comply with Recommendation G.811. The timing performance of clocks at subscriber premises, at digital PABXs, in digital concentrators, at muldexes, etc., require further study.
Synchronized national networks may be provided with exchange clocks not having the frequency accuracy required for international interworking. However, when these synchronized networks within national boundaries are required to interwork internationally as part of the international IDN/ISDN, it will be necessary to provide means to operate these national networks to the internationally recommended value of frequency accuracy in Recommendation G.811.
3.3 Slip
The design objective controlled slip rate within a synchronized region (see Note) controlled by the exchange should be zero provided that input jitter and wander remain within the limits given in Recommendation G.823 and G.824.
The design objective controlled slip rate at a digital exchange in plesiochronous operation (or operating to another synchronized region) shall be not more than one slip in 70 days in any 64 kbit/s channel, provided that input jitter and wander remain within the limits given in Recommendations G.823 and G.824.
Fascicle VI.5 -- Rec. Q.541 3
The operational performance requirements for the rate of octet slips on an international connection or corresponding bearer channel are covered in Recommendation G.822.
The occurrence of a controlled slip should not cause loss of frame alignment.
Note -- A synchronized region is defined as a geographic entity normally synchronized to a single source and operating plesiochronously with other synchronized regions. It may be a continent, country, part of a country or countries.
4 Fascicle VI.5 -- Rec. Q.541
3.4 Relative Time Interval Error (TIE) at the exchange output
Relative Time Interval Error (TIE) at the exchange output is defined as the difference in time delay of a given timing signal when compared to a reference timing signal for a given measurement period (see Recommendation G.811).
3.4.1 Interface V1
Relative Time Interval Error (TIE) at the exchange output at the interface to the basic access digital section requires further study.
3.4.2 Interfaces A, B, V4 [ mangled text ].
The relative TIE at the output of the digital interfaces A, B, V2, V3and V4over the period S seconds should not exceed the following limits:
1) (100 S) ns + 1/8 UI for S < 10.
|
2) |
1000 ns for S ³" 10 (see Figure 4/Q.541). |
Figure 1/Q.541, p. |
In the case of synchronous operation the limits are specified on the assumption of an ideal incoming synchronizing signal (no jitter, no wander and no frequency deviation) on the line delivering the timing information. In the case of asynchronous operation the limits are specified assuming no frequency deviation of the exchange clock, (this is equivalent to taking the output of the exchange clock as the reference timing signal for the relative TIE
Fascicle VI.5 -- Rec. Q.541 5
measurements).
It is recognized that the approach of using relative TIE to specify the performance of an exchange in the case of synchronous operation in some implementations (e.g., when mutual synchronization methods are used) requires further study.
6 Fascicle VI.5 -- Rec. Q.541
Any internal operation or rearrangement within the synchronization and timing unit or any other cause should not result in a phase discontinuity greater than 1/8 of a Unit Interval (UI) on the outgoing digital signal from the exchange.
The limits given in Figure 4/Q.541 may be exceeded in cases of infrequent internal testing or rearrangement operations within the exchange. In such cases, the following conditions should be met:
The Relative Time Interval Error (TIE) over any period up to 211 unit intervals should not exceed 1/8 of a UI. For periods greater than 211 UI, the phase variation for each interval of 211 UI should not exceed 1/8 UI up to a maximum total Relative TIE defined in Recommendation G.811 for long time periods.
3.5 Synchronization requirements when interworking with a digital satellite system
On a provisional basis the following should apply:
The transfer from the timing of the terrestrial digital network to the timing of the satellite system, if required (plesiochronous operation), will not be performed by the digital exchange. The earth station will be equipped with buffer memories of suitable size to compensate for the time delay variations due to shifts of the satellite from its ideal position (and due to any other phenomena with similar effects) and to meet the slip performance requirements established in CCITT Recommendation G.822.
4.1 General
Availability is one aspect of the overall quality of service of an exchange.
Availability objectives are important factors to be considered in the design of a switching system and may also be used by administrations to judge the performance of a system design and to compare the performance of different system designs.
Availability may be determined by collecting and evaluating data from exchanges in operation in accordance with draft Recommendation E.450. Data collection may be facilitated by the use of the Telecommunications Management Network (TMN).
Availability may be expressed as the ratio of the accumulated time during which the exchange (or part of it) is capable of proper operation to a time period of statistically significant duration called the mission time.
Availability (A) =
@ { ccumulated~up-time } over { ission~time } @ =
@ { ccumulated~up-time } over { ccumulated~up-time~+ } @
Availability (A) = accumulated up-time =
accumulated down-time
Sometimes it is more convenient to use the term unavailability (instead of availability) which is defined as:
Unavailability (U) = 1 -- A.
The terms used in this section, when they already exist, are in accordance with CCITT Recommendation G.106. 4.2 Causes of unavailability
Fascicle VI.5 -- Rec. Q.541 7
This Recommendation deals with availability as observed from the exchange termination point of view. Both planned and unplanned outages need to be considered, and both types need to be minimized. Unplanned outages reflect on the inherent reliability of the exchange and are therefore considered separately from planned outages in this Recommendation.
Unplanned unavailability counts all failures that cause unavailability. Thus hardware failure, software malfunctions and unintentional outages resulting from craftperson activity are to be counted.
8 Fascicle VI.5 -- Rec. Q.541
4.3 Intrinsic and operational unavailability
Intrinsic unavailability is the unavailability of an exchange (or part of it) due to exchange (or unit) failure itself, excluding the logistic delay time (e.g. travel times, unavailability of spare units, etc.) and planned outages.
Operational unavailability is the unavailability of an exchange (or part of it) due to exchange (or unit) failure itself, including the logistic delay time (e.g. travel times, unavailability of spare units, etc.).
4.4 Planned outages
Planned outages are those intentionally induced to facilitate exchange growth or hardware and/or software modifications. The impact of these activities on service depends on their duration, the time of day they are introduced and on the particular system design.
4.5 Total and partial unavailability
Exchange unavailability may be either total or partial. Total unavailability affects all terminations, and consequently, all traffic that is offered during the outage is equally affected. A partial outage has an effect only on some terminations.
From the point of view of one termination on an exchange (e.g. a subscriber line termination), the numerical value of mean accumulated downtime (and hence the unavailability) for a specified period of time should not depend on the exchange size or its traffic handling capacity. Similarly, from the point of view of a group of terminations of size n , the mean accumulated downtime for a specified period of time, in case they are simultaneously unavailable , should not depend on exchange size. However, for two groups of
terminals of differing size n and m such that n is greater than m (n > m), the mean accumulated downtime (and hence the unavailability) for n will be less than the mean accumulated downtime (MADT) or the unavailability for m .
|
Thus: |
||||
|
MADT(n ) < MADT(m ) where n > m |
||||
|
and |
||||
|
U(n ) < U(m ) |
The lower limit of m is one termination, and it can be specified as having a mean value of T minutes per year.
4.6 Statistical basis
Any estimation of unavailability is of necessity a statistical quantity, because outages are presumed to occur randomly and they are of random duration. Therefore, availability measurements are significant when made over a statistically significant number of exchanges. It follows then, that a single exchange may exceed the unavailability objectives. Further, to be statistically significant the mission time must be adequate in order to have sufficient collected data. The accuracy of the result is dependent on the amount of collected data.
4.7 Relevant failure events
Different types of failure events may occur in an exchange. In order to evaluate the unavailability of an exchange (or part of it) only those events having an adverse effect on the exchange's ability to process calls as required should be taken into account. A failure event which is short in duration and results only in call delay rather than in a call denial can be disregarded.
Fascicle VI.5 -- Rec. Q.541 9
4.8 Availability independence
The design objectives for the unavailability of a single termination or any group of terminations of size n are independent of exchange size or internal structure.
4.9 Intrinsic downtime and unavailability objectives
The recommended measure for use in determining intrinsic unavailability is mean accumulated intrinsic down time (MAIDT) for individual or groups of terminations, for a given mission time, typically one year.
10 Fascicle VI.5 -- Rec. Q.541
|
For one termination: |
MAIDT(1) 30 minutes per year. |
For an exchange termination group of size n :
MAIDT(n ) < MAIDT(m ) where n > m .
This reflects the consequences (e.g. traffic congestion, social annoyance, etc.), of the simultaneous outage of a large number of terminations.
The above expression is a statement of principle and means that units serving larger group sizes shall have lower MAIDT.
4.10 Operational unavailability objectives
4.10.1 Logistic delay time
Due to differing national conditions, logistic delay times may vary from country to country and therefore may not be subject to international Recommendation.
Nevertheless, for design guidance, an indication of the Administration's logistic delays is considered desirable to establish overall operational performance objectives. It is left for the operating Administration to determine how it should be accounted for in the determination of operational unavailability.
4.10.2 Planned outages
|
Planned outages are to be minimized to the greatest extent practicable. They should be scheduled so as to have |
||
|
least 4.11 |
impact on service practicable. Initial exchange availability performance A system rarely meets all long-term design objectives when first placed into service. The objectives contained in |
this Recommendation may therefore not be fulfilled for a limited period of time after the newly designed switched system has been put into service; this period of time should be minimized to the greatest extent practicable.
A bound on the rate of hardware failures is recommended. It includes all types of hardware failures and the failures counted are independent of whether or not there is a resulting service degradation.
An acceptable hardware failure rate for an exchange is a function of the exchange size and the types of terminations.
The following formula can be used to verify that the maximum failure rate does not exceed the Administration's requirements:
|
F |
||
|
=maxC |
||
|
0 + |
||
|
Fascicle VI.5 -- Rec. Q.541 11 |
@ pile { fIn above sum above i~=1 } @C
iT
i
where:
Fm\da\dx the maximum acceptable number of hardware failures per unit of time;
Ti the number of terminations of type i ;
n the number of distinct types of terminations;
C0 to be determined taking into account all failures which are independent of exchange size;
Ci coefficients for terminations of type i , reflecting the number of failures associated with individual terminations of that type. Different hardware used with different types of terminations may result in different values for Ci.
12 Fascicle VI.5 -- Rec. Q.541
DIGITAL EXCHANGE DESIGN OBJECTIVES -- OPERATIONS
AND MAINTENANCE
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 Services Digital Network (ISDN).
The field of application of this Recommendation is more fully defined in Recommendation Q.500. Some objectives 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 objective applies to all exchange applications.
The exchange shall be arranged so that normal maintenance activities can be easily performed by maintenance personnel. It should be capable of providing all information necessary for the identification of trouble conditions and the direction of repair activities.
|
2.1 |
Status and other information The exchange shall provide information to maintenance personnel so that they can quickly ascertain: -- equipment/system status, -- critical load levels, -- trouble conditions, -- network management controls in effect. |
|
|
2.2 |
Inputs and outputs The exchange shall be able to transmit and receive maintenance information and respond to commands from |
on-site and if appropriate, from remote maintenance centre(s) or systems over the recommended interface(s) (Recommendation Q.513).
In performing operations and maintenance functions, the exchange shall use CCITT MML at its input/output terminals as covered in the Z.300-series of Recommendations.
2.3 Routine testing
The exchange shall have facilities for performing or directing routine test activities on its component parts and possibly with interfacing equipment or systems.
2.4 Trouble localization
Fascicle VI.5 -- Rec. Q.542 13
The exchange shall have adequate facilities for diagnosing and locating faults within the exchange.
2.5 Fault and alarm detection and actions at interfaces A, B, V4
The exchange shall interact with transmission systems as required to detect fault and alarms and take appropriate actions.
|
2.5.1 |
Fault detection The following fault conditions should be detected: -- failure of local power supply (if practicable); -- loss of incoming signal; Note -- The detection of this fault condition is required only when the fault does not result in an indication of loss |
of frame alignment.
14 3 andŽ
-- loss of frame alignment (see Recommendations G.706; the loss of frame alignment will also be assumed if no CRC multiframe alignment can be achieved or if the proportion of corrupted CRC checks exceeds a certain value);
-- excessive error ratio (without CRC procedure). The criteria for activating and deactivating the indication of the fault condition are given in draft Recommendation G.707. Consequent actions are given in § 2.5.3;
|
-- a) -- -- |
CRC error reporting, if applicable: every time a received CRC block is detected errored by the exchange termination: a report will be transmitted to the error monitoring function; the information ``one multiframe errored'' is transmitted in the outgoing signal at the interface using an |
E bit (see Recommendation G.704, § 2.3.3.4);
b) every time that an E bit in the binary state 0 is received, a report will be transmitted to the error monitoring functions.
|
(On a provisional basis the considerations related to the E bit may only apply to V interfaces -- for further study.) |
|||
|
2.5.2 |
Alarm signal detection The following alarm indications should be detected: -- Alarm indication (remote alarm) received from the remote end. -- AIS (alarm indication signal). The equivalent binary content of the alarm indication signal (AIS) is |
a |
continuous stream of ``1''s at 2048 or 8448 kbit/s.
The strategy for detecting the presence of the AIS should be such that the AIS is detectable even in the presence of an error ratio of 1 in 103. However, a signal with all bits except the frame alignment bit in the 1 state should not be mistaken as an AIS.
2.5.3 Consequent actions
2.5.3.1 Generation of alarm signals for action within the exchange
-- The service alarm indication should be generated to signify that the service is no longer available (see Table 1/Q.542).
-- The prompt maintenance alarm indication should be generated to signify that performance is below acceptable standards and that immediate maintenance attention is required locally (see Table 1/Q.542).
2.5.3.2 Generation of alarm signals transmitted by the exchange
-- Alarm signals sent in the outgoing direction at the exchange interface. The relevant alarm bits for the remote alarm indication, as recommended in G.704 should be effected as soon as possible (see Table 1/Q.542).
-- Alarm signals sent towards the switching function. Alarm indication signal applied in all received time-slots containing speech, data and/or signalling should be applied as soon as possible and not later than 2 ms after the detection of the fault condition (see Table 1/Q.542).
2.5.3.3 Removal of alarm indications
3 and 15
When all fault conditions have been cleared and alarm indication signal is no longer received, the alarm indication signal and remote alarm indication should be removed within the same respective time limits as specified in § 2.5.3.4 after the conditions have cleared.
16 3 andŽ
H.T. [T1.542]
TABLE 1/Q.542
Fault conditions and alarms detected by exchange termination functions
and consequent actions
(excluding interface V¯1)
lw(54p) | lw(54p) | lw(48p) | lw(36p) | lw(36p) . lw(54p) | cw(54p) | cw(48p) | cw(36p) | cw(36p) . Failure of power supply Yes Yes Yes, if practicable Yes, if practicable _ lw(54p) | cw(54p) | cw(48p) | cw(36p) | cw(36p) . Loss of incoming signal Yes Yes Yes Yes _ lw(54p) | cw(54p) | cw(48p) | cw(36p) | cw(36p) . Loss of frame alignment Yes Yes Yes Yes _ lw(54p) | cw(54p) | cw(48p) | cw(36p) | cw(36p) . Excessive error ratio Yes Yes Yes Yes _ lw(54p) | cw(54p) | cw(48p) | cw(36p) | cw(36p) .
{ Alarm indication received from remote end
} { 2048 | | 448 kbit/s: Yes 1544 | | 312 kbit/s: optional
|
} 1544 | | 312 kbit/s: |
Yes _ lw(54p) | cw(54p) | cw(48p) | cw(36p) | cw(36p) . |
AIS |
Note -- A Yes in the table signifies that an action should be taken. An open space in the table signifies that the relevant action should not be taken if this condition is the only one present. If more than one fault condition or alarm is simultaneously present, action should be taken if for at least one of the conditions a Yes is shown, except in the case of AIS received for which § 2.5.3.4 applies. The use of error performance monitoring in this table is for further study.
|
2.5.3.4 |
Alarm processing |
Table 1/Q.542 [T1.542], p. |
The following items are required to ensure that equipment is not removed from service due to short breaks in transmission (e.g. due to noise or transient fault) and to ensure that maintenance action does not result where no direct maintenance action is required.
-- The persistence of service alarm and of the prompt maintenance alarm indications may be verified for 100 ms before action is taken.
-- When the AIS is detected, the prompt maintenance alarm indication, associated with loss of frame alignment and excessive error rate in the frame alignment pattern, should be inhibited.
-- When the fault conditions cease, the service alarm and prompt maintenance alarm indications, if given, should be removed. Again, the persistence of this change in condition may be verified for 100 ms before action is taken.
3 and 17
-- It is possible that some systems could suffer from frequent transient faults resulting in an unacceptable quality of service. For this reason, if a persistence check is provided, fault rate monitoring should also be provided for each digital transmission system. This monitoring will result in permanent removal from service of digital transmission system which are frequently removed from the service or frequently produce transient alarm conditions. The threshold for removal from service needs study. When this action is taken the service alarm indication and the prompt maintenance alarm indication shall be given.
2.5.4 Error performance monitoring using CRC
2.5.4.1 General
When the CRC procedure is implemented at the interface, the exchange should monitor the error performance of the interface to report on the performance (see Recommendation G.821).
2.5.4.2 Error performance parameters
The exchange should derive the following information from CRC checks in the incoming signal and received E bits:
-- degraded minutes (DM),
-- severely errored seconds (SES),
-- error-free seconds (EFS).
Note 1 -- These parameters are defined in Recommendation G.821.
Note 2 -- The definition of a value for the suitable time interval during which the parameters should be assessed needs further study.
Note 3 -- The choice has to be made between the association of one type of parameter to each direction of transmission and the integration of the two directions in one type of parameter. This needs further study.
Note 4 -- The correlation between the results of CRC checks and the parameters quoted above requires further study.
|
2.5.4.3 Error performance evaluation Each of the performance parameters will be processed separately in order to evaluate the performance of the interface. The following classification of the interface maintenance conditions has to be made by the exchange (see |
I.600-series of |
|
Recommendations): |
-- correct functioning interface;
-- degraded transmission interface;
-- unacceptable transmission interface.
Note 1 -- This section may only apply to V interfaces (for study).
Note 2 -- The level at which an interface for ISDN access enters the degraded transmission condition may be dependent on the quality of service provided to the customer.
Note 3 -- The levels at which an interface enters the degraded or unacceptable transmission conditions are for further study and are outside the scope of this Recommendation.
2.5.4.4 Consequent actions
18 3 andŽ
|
2.6 |
For further study. Fault and alarm signal detection and actions at interface V |
|
|
1 The exchange shall interact with transmission systems as required to detect fault and alarm signals and take appropriate actions. a) Fault detection b) Alarm detection To be specified c) Consequent actions .bp |
||
|
2.7 |
Fault and alarm signal detection and actions at interface Z a) Fault detection b) Alarm detection To be specified c) Consequent actions |
|
|
2.8 |
Fault and alarm signal detection and actions for transmission systems Faults and alarms which cannot be directly detected by the exchange termination function but which are detected by transmission |
equipment (e.g., group pilot failure) should be accepted by the exchange as needed to take appropriate action.
|
2.9 2.9.1 |
Fault and alarm signal detection and actions for channel associated signalling (2048 and 8448 kbit/s) Fault detection The exchange signalling function should detect the following fault conditions for each multiplex carrying a 64-kbit/s signalling channel: -- failure of local power supply (if practicable), -- loss of 64 kbit/s incoming signal, Note -- The detection of this fault condition is required only when the fault does not result in an indication of loss of multiframe alignment. -- loss of multiframe alignment. The criteria for activating and deactivating the indication of the fault condition are given in Recommendations G.732 and G.744. |
||
|
2.9.2 |
Alarm detection The exchange signalling function should detect the alarm indication (remote alarm) received from the remote end. |
||
|
2.9.3 |
Consequent actions |
2.9.3.1 Generation of alarm signals for action within the exchange
3 and 19
-- The Service Alarm indication should be generated by the exchange signalling function to signify that the service is no longer available (see Table 2/Q.542).
-- The prompt maintenance alarm indication should be generated to signify that performance is below acceptable standards and that immediate maintenance attention is required locally (see Table 2/Q.542).
2.9.3.2 Alarm transmitted by the exchange
An alarm indication (remote alarm) should be applied in the outgoing direction at the transmission/switching interface as soon as possible (see Table 2/Q.542). The relevant alarm bit for the remote alarm indication is given in Recommendation G.732.
2.9.3.3 Removal of alarm indication
When all fault conditions have been cleared and AIS is no longer received, the remote alarm indication should be removed as soon as possible.
2.9.3.4 Alarm processing
Same as in § 2.5.3.4.
20 3 andŽ
H.T. [T2.542]
TABLE 2/Q.542
Fault conditions and alarms detected by the exchange signalling
function and consequent actions
lw(60p) | lw(42p) | lw(42p) | lw(42p) . lw(60p) | cw(42p) | cw(42p) | cw(42p) . Failure of power supply Yes Yes Yes, if practicable _ lw(60p) | cw(42p) | cw(42p) | cw(42p) .
|
{ Loss of 64 kbit/s incoming signal } Yes Yes Yes _ lw(60p) | cw(42p) | cw(42p) | cw(42p) . Loss of multiframe alignment |
Yes |
Yes |
Yes _ lw(60p) | cw(42p) | cw(42p) | |
|||
|
cw(42p) . { Alarm indication received from remote end } Yes Note -- A Yes |
in the table signifies that an action should be taken. An open space in the table signifies that the relevant action should not
be taken if this condition is the only one present. If more than one fault condition or alarm is simultaneously present, action should be taken if for at least one of the conditions a Yes is shown.
|
Table 2/Q.542 [T2.542], p. |
||
|
2.10 Fault and alarm signal detection and actions for channel associated channel signalling (1544 kbit/s) Requires further study. 2.11 Fault and alarm signal detection and actions for common channel signalling Requirements specified in relevant Recommendations apply. 2.12 Fault and alarm detection and consequent actions -- other functions of the exchange 2.12.1 Faulty circuits The exchange should not switch any new calls to a detected faulty circuit. |
The exchange should remove from service all circuits found to be permanently faulty as detailed in §§ 2.5, 2.8, 2.9, 2.10 and 2.11.
2.12.2 Master clock distribution
The absence of timing information distributed from a master clock located at the exchange or received from an external master clock shall be recognized and a prompt maintenance alarm shall be given.
Changeover to an alternate timing source shall be operated so as to fulfil the requirements of §§ 2.7.2 and 2.7.3 of Recommendation Q.543.
3 and 21
2.12.3 Internal timing distribution
The distribution of timing information to the major elements of the exchange shall be supervised as required. A service alarm shall be given when a failure is detected. A maintenance alarm shall be given if it is appropriate.
Note -- Remote elements may have to be taken into consideration.
2.13 Supervision or testing of interface function
The exchange shall have the capability of verifying the proper operation of the interface functions, including the fault detection and supervision functions.
Routine tests, statistical tests, manual activities and/or other means may be used to verify proper operation of these functions.
Information shall be given to the far end exchange when new calls cannot be established on the circuits on which routine tests are being initiated. Established calls, including semi-permanent connections, must not be interrupted. During the tests, the generation of alarms at the far end exchange due to the removal of circuits from service should be avoided, if possible.
2.13.1 ET functions -- Interfaces A, B, V4
The verification of the proper operation of exchange termination functions can be performed by the means of statistical observations or by testing. Testing may be manual or automatic.
2.13.2 ET functions -- Interfaces C and Z
i) Failures of codecs (except those covered in ii) below) should be recognized by the exchange using the criteria defined in Recommendation G.732.
ii) Supervision or testing of codecs of one or a small number of channels may be accomplished according to i) above or by inter-office transmission measurement and testing on circuits between exchanges or by statistical measurements.
2.13.3 ET functions -- Interface V1
To be specified.
2.14 Supervision or testing of signalling functions
In addition to fault detection required in § 2.7, the following applies.
2.14.1 Channel associated signalling
The exchange should be able to verify the proper operation of the signalling functions by generating and responding to test calls or by a statistical observation.
2.14.2 Common channel signalling
The exchange should be able to verify the proper operation of the signalling functions as required by common channel signalling recommendations.
2.15 Supervision or testing of exchange connections
22 3 andŽ
Checking the different portions of the path individually in a digital exchange network helps to ensure the continuity of the connections overall. In this respect the exchange has to verify:
-- the continuity across the exchange, as covered in this section;
-- the continuity in the transmission links terminating on the exchange as covered in §§ 2.16 and 2.17.
3 and 23
2.15.1 Continuity across the exchange
A means should be provided to determine that the operational error performance requirement (i.e., on bit error ratio) is being met. (The design objective for error performance can be found in Recommendation Q.554.)
The exchange should provide adequate provision of the cross office path continuity and verify the transmission performance. (The design objective for transmission performance can be found in Recommendation Q.543.) This will guarantee, in particular, an acceptable transmission quality to its connections.
2.15.2 Verification depending on the type of connection
The verifications to be performed by the exchange should depend also on the type of connection. In particular:
-- for 64 kbit/s switched connections, the transmission performance requirements of Q.543 may be considered to be sufficient in order to guarantee the cross office path continuity;
-- semi-permanent connections may require special supervision procedures which need further study;
-- supervision of n × 64 kbit/s requires further study for both switched and semi-permanent connections.
2.16 Supervision or testing of digital link performance
The exchange shall have the capability of monitoring digital link performance to detect when bit error ratio and loss of framing thresholds exceed operational objectives. The exchange will then take subsequent action to give appropriate trouble indications or alarms and perform other appropriate actions, such as removing circuits from service.
2.17 Supervision or testing of analogue link performance
2.17.1 Interexchange circuit continuity check
The exchange should be capable of performing circuit continuity checks in accordance with appropriate signalling system recommendations. Circuits failing circuit continuity checks should be removed from service and repair procedures initiated as required.
2.17.2 Interexchange transmission measurement and testing on circuits between exchanges
The exchange may also be equipped within itself or give access to external equipment to perform other transmission tests on circuits. Faulty circuits should be removed from service and repair procedures initiated as required.
3.1 Analogue subscriber lines
For further study.
3.2 Digital subscriber lines
24 3 andŽ
For further study.
4.1 General
The exchange and/or any associated Operations and Maintenance Systems/Centres shall have the capabilities necessary to permit it to be operated, administered, and maintained efficiently while providing service in accordance with an Administration's performance requirements.
3 and 25
The Telecommunications Management Network (TMN) architecture, as described in Recommendation M.30, considers the exchange to be a Network Element (NE) which can interact with Operations Systems (OS) within a TMN. Operations systems may be used at the discretion of Administrations to improve operating efficiencies and service by centralizing and mechanizing operations, administrative and maintenance functions. The number and variety of operations systems will depend on the operating practices of the Administration.
|
The decision to implement TMN principles rests with the Administration. |
|||
|
4.2 4.2.1 |
Operations features Service provisioning and records There should be efficient means of establishing service, testing, discontinuing service and maintaining accurate records for: -- subscriber lines and services (in local exchanges); -- interexchange circuits. |
||
|
4.2.2 |
Translation and routing information There should be efficient means of establishing, testing and changing call processing information, such as translation |
and routing |
information.
4.2.3 Resource utilization
There should be efficient means of measuring performance and traffic flows and to arrange equipment configurations as required to insure efficient use of system resources and to provide a good grade of service to all subscribers (e.g., load balancing).
4.2.4 Exchange observation and measurements
The exchange should provide means for making observations and measurements on Quality of Service and network performance, to satisfy, for example, Grade of Service objectives as covered in Recommendation E.500, or for provisioning purposes. Details of measurements for digital exchanges are given in Recommendation Q.544.
|
4.3 |
Exchange functions related to the TMN Detailed descriptions, definitions, and classifications of TMN functions to which the exchange will contribute is for further study. A partial list of TMN functions is given below. A more complete list is given in Recommendation M.30. Exchanges may have requirements for Operations, Administration and Maintenance functions which are not related to TMN. This is for |
further study.
|
4.3.1 |
Functions |
Functions potentially related to TMN |
|||
|
-- -- -- -- |
Subscriber administration; tariff and charging administration; routing administration; network management; |
||||
|
26 |
3 |
andŽ |
|
-- -- -- -- |
maintenance of subscriber lines; maintenance of circuits between exchanges; exchange maintenance; signalling network maintenance; |
3 and 27 |
|
4.3.2 |
-- -- -- -- -- -- |
administration of hardware configuration; administration of software configuration; external alarms and indications; O&M staff procedures; traffic measurements; quality of service and network performance observation. Information flows |
Generally, information flows will consist of requests/demands to the exchange and responses from the exchange. There will also be autonomous information flows from the exchange (e.g. alarms, programmed response, etc.). Refer to Recommendation Q.513 for information on interfaces to the TMN.
This subject is for further study.
5.1 General
Network management is the function of supervising the performance of a network and taking action to control the flow of traffic, when necessary, to promote the maximum utilization of network capacity.
These functions have application in exchanges within the IDN, and may or may not have application in national networks during the transition period to IDN.
The implementation of network management features and functions in national networks and in specific exchanges will be at the option of Administrations. Likewise the choice of which controls and features to use will be the option of each Administration.
5.1.1 Network management objectives
Information on network management objectives can be obtained from Recommendation E.410, and from the CCITT ``Handbook on Service Quality, Network Maintenance and Management'', ITU, Geneva 1984.
5.1.2 The application of network management in exchanges
In addition to the normal engineering and economic factors, the decision whether or not to provide network management capabilities in a digital exchange will be based on the following considerations:
-- the size of the exchange, the size of circuit groups it serves and the network architecture;
-- the role and importance of the exchange in its own network, or as an access exchange interfacing other exchanges and networks (e.g., international or other exchange networks);
-- the requirement for the exchange to interact for network management purposes with other exchanges and/or network management centres;
-- the features necessary to provide essential services in emergency situations, where other means are not available;
-- alternative approaches such as providing redundancy and special routing methods;
28 3 andŽ
-- the need for managing network resources effectively when overload conditions occur in its own or interworking networks.
Other factors to be considered are:
-- the network management organization, its equipment and selected functions;
-- the possible interactions of both the circuit switched and signalling networks when network management actions are applied under various traffic conditions or network configurations;
-- the potential impact of network management functions on the engineering design and administration of the network and the exchange;
-- the evolution towards IDN and interworking of SPC with non-SPC exchanges in the interim period;
3 and 29
|
-- features; -- |
the proportion of automatic and manual features to be implemented and the rate of introduction of various network management the reduction of exchange processing capacity due to the additional load imposed by network management (if appropriate); |
|
|
-- |
possible additional holding time of equipment in some switching and signalling systems where open numbering is used, if and when |
certain network management controls are applied.
|
5.2 |
Network management elements The basic elements of a network management system to be provided by an exchange or by network management centres are: -- collection of information about network status and performance; -- processing of information for network management decisions; -- delivery to exchanges of network status information and/or commands for control activities; -- activation/deactivation of controls resulting from decisions made in the exchange or a network management centre; -- feedback of status in response to control actions. Descriptions of the functions required in the exchanges to support these elements are given in §§ 5.3 and 5.4. |
|
|
5.3 5.3.1 |
Information provided by an exchange for network management purposes General The term ``information'' is used here as meaning all messages, signals or data in any form, used or provided by the exchange or by a |
network management centre.
5.3.2 Sources of information
The information provided by an exchange for network management will be based on the status, availability and performance and configuration of:
|
-- -- -- -- -- |
circuit groups; exchange processes; common channel signalling link sets; other exchanges with direct links to this exchange; destination exchanges. |
Status information is generated by comparing the current value of load indicators with appropriate threshold values and/or detecting abnormal conditions. Such type of information assumes discrete values and it can be used, without other processing, to activate traffic control routines.
This information should be sent spontaneously in a real-time basis to other exchanges or to a network management centre.
Performance information is obtained by means of traffic measurements and can be used for centralized processing or for network supervision in a network management centre. Such type of information can be sent in a near-real-time basis.
Configuration information is used for a network management data base at exchange level. This information could include:
30 3 andŽ
|
-- -- -- -- -- -- |
threshold values actually used, list of supervised circuit groups, list of supervised signalling circuits, list of supervised processors, list of supervised destination codes, list of primary and alternate routes for specified destinations. |
Details of network measurements are given in Recommendation Q.544.
3 and 31
5.3.3 Processing of network management information in an exchange
Information collected at an exchange for network management purposes may or may not require some form of sorting and assembly (processing) before being used for network management.
Where processing is required, this may be done by the exchange processor, or by a data processing system serving one or more exchanges, or by a network management centre.
5.3.4 Transmittal of information
Network management information may be sent on a scheduled near-real-time basis when triggered by abnormal situations (e.g., overload conditions, alarms, etc.): alternatively, information may be sent on demand, i.e., in response to an external request. Table 3/Q.542 shows the correspondence between sources of information and their transmission mode.
H.T. [T3.542]
TABLE 3/Q.542
center box; lw(90p) | cw(36p) | cw(36p) | cw(36p) .
|
{ Data transmission mode Source of information } Real-time On demand Scheduled _ lw(90p) | cw(36p) | cw(36p) | cw(36p) . |
Status information |
X |
X |
_ lw(90p) | cw(36p) | |
||||
|
cw(36p) | cw(36p) . { Performance and availability information } X X _ lw(90p) | cw(36p) | cw(36p) | cw(36p) . Configuration information |
X _ |
|||||||
|
Table 3/Q.542 [T3.542], p. |
||||||||
|
The destinations of network management information may be: -- within the originating exchange, -- to distant exchanges, -- to a network management centre. |
Information may be carried by the TMN over a dedicated telemetry or data facility, over a common channel signalling network, or over other telephony network facilities as appropriate.
For each mode of transmittal the appropriate interface and protocol requirements, where covered by CCITT Recommendations, should be satisfied.
5.3.5 Presentation of information
Indications of network management controls in effect in an exchange shall be presented on visual indicators and/or printing-type or video display terminals for purposes of advising on-site personnel.
|
Similar displays and/or indicators may also be provided in a co-located and/or distant network management centre. |
||
|
5.4 5.4.1 |
Exchange controls for network management General Network management controls provide the means to alter the flow of traffic in the network, in support of network objectives. Most network |
management controls are applied by, or in the exchange; however, certain actions may be taken external to the exchange. Recommendation E.412 provides specific information on network management controls and gives guidance on their application. Additional information is provided in the CCITT ``Handbook on Service Quality, Network Management and Maintenance''.
32 3 andŽ
5.4.2 Activation and deactivation of controls
Controls in an exchange can be activated, or deactivated, by input from a network management operations system or by direct input from an exchange man-machine interface terminal. In addition, some controls can be activated automatically either by external or internal stimulus, or by a threshold being crossed.
When automatic control operation is provided, means for human override should also be provided.
Controls will usually be activated or deactivated in steps (stages) that are intended to avoid surge effects in the network that could be caused by too much control being added or removed too quickly.
|
A low level threshold may be required to remove controls as appropriate, when traffic conditions have been stabilized. |
||
|
5.4.3 |
Traffic to be controlled Exchanges should be capable of applying a range of network management controls (see Recommendation E.412). The operational parameters of a control can be defined by a set of traffic attributes. As shown in Figure 1/Q.542, these parameters include |
distinctions based on the origin of traffic, for example, customer-dialed, operator-dialed, transit or other classification as may be specified by the Administration. These can be further defined by type of service, particularly by ISDN.
|
Additional attributes can be specified, for example, incoming/outgoing circuit group class, or hard-to-reach status of destinations can be |
||
|
used. |
Further distinctions can be based on the outgoing traffic type, for example, direct-routed, alternate-routed or transit. Figure 1/Q.542, p. |
|
|
5.4.4 |
Network management controls The following is a list of typical network management controls to be considered for implementation in a given exchange. It is desirable that these controls be activated to affect a variable percentage of traffic (for example, 25%, 50%, 75% or 100%). |
Alternatively the number of call attempts routed in a particular period may be controlled (for example 1 calls per minute). It may also be desirable to apply controls on a destination code basis.
These controls are normally activated/deactivated manually from a man-machine interface in the exchange, or from an operations system. The automatic operation of these controls and the need for new controls is for further study.
It is preferable that these controls be provided in international transit exchanges and large transit exchanges in national applications. However, the decision whether or not to provide these controls in local and combined local/transit exchanges is at the discretion of the Administration.
3 and 33
5.4.4.1 Code blocking control
This control bars or restricts routing to a specific destination code. Code blocking can be done on a country code, an area code, an exchange identifying code and, in some cases, on an individual line number.
5.4.4.2 Cancellation of alternative routing
There are two types of cancellation of alternative routing control. One version prevents traffic from overflowing from the controlled route (Alternate Routed From -- ARF). The other version prevents overflow traffic from all sources from having access to the controlled route (Alternate Routed To -- ART). When cancellation of alternative routing is to be provided, both types are recommended.
5.4.4.3 Call gapping
This control sets an upper limit on the number of call attempts allowed to be routed towards the specified destination in a particular period of time (for example, one call per minute).
5.4.4.4 Restriction of direct routing
This control limits the amount of direct routed traffic accessing a route.
5.4.4.5 Skip route
This control allows traffic to bypass a specific route and advance instead to the next route in its normal routing pattern.
5.4.4.6 Temporary alternative routing
This control redirects traffic from congested routes to routes not normally available which have idle capacity at the time. This can be done for subscriber, and/or operator-originated traffic.
5.4.4.7 Circuit directionalization
This control changes both-way operated circuits to one-way operated circuits.
5.4.4.8 Circuit turndown/busying
This control removes one-way and/or both-way operated circuits from service.
5.4.4.9 Recorded announcements
|
These are announcements which give special instructions to operators and subscribers, such as to defer their call to a later time. |
||
|
5.5 5.5.1 |
Automatic controls for network management General This section provides descriptions of some automatic traffic control methods that can be provided in digital exchanges for network |
management purposes.
34 3 andŽ
Automatic, and/or dynamic network management controls represent a significant improvement over static manual controls. These controls, which are pre-assigned, can respond automatically to conditions internally detected by the exchange, or to status signals from other exchanges and can be promptly removed when no longer required.
|
The following are a basic set of automatic methods for use in the telephone network: -- Automatic Congestion Control system (ACC); -- Selective Circuit Reservation control (SCR); -- Hard-to-Reach process (HTR); -- Temporary Trunk Blocking (TTB). |
3 and 35 |
The above list of methods is not exhaustive, but will provide a framework for more advanced controls which may be required in the ISDN.
In the following four sections the typical operation of each control is described, and guidance on the application of the controls is given in § 5.5.6.
5.5.2 Automatic Congestion Control system
The Automatic Congestion Control (ACC) system allows a congested exchange to send a congestion indicator in a backward direction to the preceding exchange. The exchange receiving the congestion indication should respond by reducing the amount of traffic offered to the congested exchange.
The preferred method of conveying the congestion indication is via the relevant common channel signalling system.
a) Detection and transmission of congestion status
An exchange should establish a critical operating system benchmark, e.g., the time required to perform a complete basic cycle of operations. The exchange should continously monitor this benchmark and, when continued levels of nominal performance are not achieved, a state of congestion is declared. Thresholds should be established so that two levels of congestion can be identified, with congestion level 2 (C2) indicating a more severe performance degradation than congestion level 1 (C1). When either level of congestion is detected, the exchange should have the capability to
1) code an ACC indication in the appropriate signalling messages, and
2) notify its network management support system of its current congestion status.
The system can offer benefit, however, by recognizing a single level of congestion. Where this situation exists, it should be regarded as congestion level 2.
b) ACC control operation
Exchanges receiving an ACC indication from an affected exchange or network operations centre should have the capability to institute the appropriate ACC controls and to notify its network management support system of the receipt of an ACC indication.
An exchange receiving an ACC indicator from a congested exchange should activate the assigned ACC controls and start a timer. (The provisional value of the timer is five seconds and is for further study.) Subsequent received ACC indicators restart the timer, when the timer expires, the ACC controls in the exchange are removed. One or more different response categories should be available from which to choose.
To avoid the incorrect application of controls, it is important that an exchange receiving an ACC indication should not re-transmit that indication to a preceding exchange.
c) ACC response
An exchange should have the capability of assigning an ACC response category to individual circuit groups. There should be several categories available from which to choose. Each category would specify how much traffic should be controlled in response to each of the received ACC indicators. The categories should be structured so as to present a wide range of response options to received ACC indicators.
The control options for further processing of calls denied access to the circuit group may be SKIP or CANCEL. The SKIP response allows a call to alternate route to the next circuit group in the routing pattern (if any) while the CANCEL response blocks the call.
Note -- ACC response categories can be set locally in the exchange or by input from a network management center.
Table 4/Q.542 is an example of the flexibility that could be achieved in a control's response to an exchange that is experiencing congestion.
In this example, different control actions would be taken based upon the distinction between Alternate Routed To (ART) and Direct Routed (DR) traffic types. In the future, other distinctions between traffic could be identified that would expand the number of traffic types in Table 4/Q.542. These additional traffic types could be assigned different control percentages (or excluded from ACC control, as in the case of priority calls), to give them different treatment during periods of congestion. An example would be to control hard-to-reach traffic as indicated in § 5.5.4.
Methods used to achieve the percentages are implementation specific. Additional response categories could also be added to Table 4/Q.542 to give greater flexibility and more response options to the ACC control.
36 3 andŽ
H.T. [T4.542]
TABLE 4/Q.542
An example of 2-congestion level ACC percentage
control response table
center box; cw(48p) | cw(48p) | cw(24p) sw(24p) sw(24p) , ^ | ^ | c | c | c. Congestion level Traffic type Response category A
B C _ cw(48p) | lw(48p) | cw(24p) | cw(24p) | cw(24p) . CL1 ART 0 0 100 cw(48p) | lw(48p) | cw(24p) | cw(24p) | cw(24p) .
DR 0 0 0 _ cw(48p) | lw(48p) | cw(24p) | cw(24p) | cw(24p) . CL2 ART 100 100 100 cw(48p) | lw(48p) | cw(24p) | cw(24p) | cw(24p) . DR 0 75 75 _
|
5.5.3 |
Selective Circuit Reservation control |
Tableau 4/Q.542 [T4.542], p. |
The Selective Circuit Reservation (SCR) Network Management control enables a digital exchange to automatically give preference to a specific type (or types) of traffic over others (e.g., direct routed calls over alternate routed calls) when circuit congestion is present or imminent. A digital exchange should provide either the single threshold of multi-threshold version of the countrol, with the latter being preferred due to its greater selectivity.
5.5.3.1 General characteristics
A Selective Circuit Reservation control may be defined, for a given circuit group, by the following parameters:
-- a reservation threshold(s), and
-- a control response.
The reservation threshold defines how many circuits should be reserved for those traffic types to be given preferred access to the circuit group. The control response defines which traffic types should be given a lesser preference in accessing the circuit group, the quantity of each type of traffic to control, and how those calls denied access to the circuit group should be handled. Examples of possible traffic types are Direct Routed (DR), Alternate Routed To (ART), Hard-To-Reach (HTR), and various combinations thereof. The quantity of each type of traffic to be controlled when the threshold is exceeded may be represented by a percentage of the total traffic of that type. The control action options for further processing of calls denied access to the circuit group may be SKIP or CANCEL.
When the number of idle circuits in the given circuit group is less than or equal to the reservation threshold the exchange would, for that call, check the specified control response to determine if the call should be controlled. The SKIP response allows a call to alternate route to the next circuit group in the routing pattern (if any) while the CANCEL response blocks the call.
These parameters should be able to set locally in the exchange or by input from a network management centre. In addition, the network manager should have the capability to enable and disable the control, and to enable the control but place it in a state where the control does not activate (e.g., by setting the reservation threshold to zero).
3 and 37
5.5.3.2 Single-threshold Selective Circuit Reservation control
In this version of the control, only a single reservation threshold would be available for the specified circuit group.
Table 5/Q.542 is an example of the flexibility that could be achieved in the control's response to circuit group congestion. Consider, for example, a case in which a network manager assigns response category ``B'', a reservation threshold of 5 circuits (RT1 = 5), and a control action of SKIP to a circuit group. Then, when the control is enabled, every time the number of idle circuits in the circuit group is less than or equal to five, the exchange SKIPs 50 percent of the alternate routed traffic attempting to access the circuit group. Direct routed traffic has full access to the circuit group because the quantity of direct routed traffic to be controlled is zero percent. Note that the reservation threshold (in this example RT1 = 5) is the same for any of the response categories (A, B and C) that can be assigned to a circuit group. One or more response categories should be available from which to choose.
In the future, other distinctions between traffic could be identified that would expand the number of traffic types in Table 5/Q.542. An example would be to control Hard-To-Reach traffic, as indicated in § 5.5.4, or to give preference to priority calls.
H.T. [T5.542]
TABLE 5/Q.542
An example of a single threshold selective circuit
reservation percentage control response table
center box; cw(48p) | cw(36p) | cw(30p) sw(30p) sw(30p) , ^ | ^ | c | c | c.
{ Circuit group reservation threshold
} Traffic type { Response category assigned to circuit group
} A B C _ cw(48p) | lw(36p) | cw(30p) | cw(30p) | cw(30p) , ^ | l | c | c | c. RT1 ART 25 50 100
DR 0 0 25 _
|
5.5.3.3 |
Multi-threshold Selective Circuit Reservation control |
Table 5/Q.542 [T5.542], p. |
The multi-threshold control would support two reservation thresholds for the specified circuit group. The purpose of multiple reservation thresholds would be to allow a gradual increase in the severity of the control response as the number of idle circuits in the circuit group decreased. The only restriction on the reservation thresholds would be that a reservation threshold associated with a more stringent control must always be less than or equal to the reservation threshold of any less stringent control, in terms of the number of reserved circuits [RT2 RT1 in Table 6/Q.542].
Table 6/Q.542 is an example of the flexibility that could be achieved in the control's response to circuit group congestion with two reservation threshold control. In the future, other distinctions between traffic could be identified that would expand the number of traffic types in Table 6/Q.542, or to give preference to priority calls.
38 3 andŽ
H.T. [T6.542]
TABLE 6/Q.542
An example of a two threshold selective circuit reservation
percentage control response table with HTR capability
center box; cw(48p) | cw(39p) | cw(27p) sw(33p) sw(27p) sw(27p) sw(27p) , ^ | ^ | c | c | c | c | c.
{ Circuit group reservation threshold
} Traffic type { Response category assigned to circuit group
} A B C D E _ cw(48p) | lw(39p) | cw(27p) | cw(33p) | cw(27p) | cw(27p) | cw(27p) , ^ | l | l | l | l | l | l ^ | l | l | l | l | l | l ^ | l | l | l | l | l | l. RT1 { ART-HTR DR-HTR ART-ETR DR-ETR
} 50 0 0 0 75 0 25 0 100 0 50 0 100 0 75 0 100 0 100 0
_ cw(48p) | lw(39p) | cw(27p) | cw(33p) | cw(27p) | cw(27p) | cw(27p) , ^ | l | l | l | l | l | l ^ | l | l | l | l | l | l ^ | l | l | l | l | l | l. RT2 { ART-HTR DR-HTR ART-ETR DR-ETR
} 100 0 50 0 100 25 50 0 100 50 75 25 100 75 100 50 100 100 100 75
_
|
5.5.4 |
Hard-to-reach (HTR) process |
Table 6/Q.542 [T6.542], p. |
The Hard-to-Reach process for network management allows exchanges to automatically make more efficient use of network resources during periods of network congestion.
Part of the improved performance of automatic controls can be derived from the ability to distinguish between destinations that are easy-to-reach (ETR) and destinations that are hard-to-reach (HTR), i.e., destinations with a low answer bid ratio, and applying heavier controls to HTR destinations. This distinction can be based on:
i) internal performance measurements within the exchange/Network Management Operations System (OS) (for example, low Answer Bid Ratio (ABR) to a destination);
ii) similar information gathered by other exchanges;
iii) historical observations of network performance by network managers.
The network manager should have the ability to set the threshold for HTR determination and to assign manually a destination code as HTR. 5.5.4.1 Simplified HTR process components
To provide the fundamental elements of a simplified HTR process, the following capabilities must exist:
a) HTR administration,
b) HTR determination,
c) manually controlling calls as if hard-to-reach.
Items a) and b) may be entirely provided by the exchange or by a Network Management (OS) in cooperation with the exchange(s). Item c) can only be provided in the exchange.
a) HTR administration
Network managers will administer the HTR process to optimize the information obtained about current network performance. In order to properly administer the HTR system, network managers need four capabilities. These capabilities are listed below.
1) Codes to be observed
An exchange should automatically collect ABR data for some destination areas, e.g., countries, area codes, etc. In addition, network managers should have the capability to designate/change destinations an exchange should monitor in greater
3 and 39
detail. An exchange should accept at least three network management designated sets of digits that identify a specific destination area and automatically begin surveillance of the specified destination areas. The specific number of digits to be analyzed is left to the discretion of the administration and may be exchange dependent.
2) Administration of HTR thresholds
There should be a set of thresholds used to monitor destination areas and another set for use when monitoring destinations in greater detail. Network managers should be able to specify/change the values of ``B'' and ``T'' for the pre-established threshold sets and the HTR hysteresis modifiers (see b, sub-section 3), below).
3) Administration of HTR determination exclusion
A network manager should have the capability to exclude destination codes from being determined as HTR. This should prevent these destination codes from automatically being calculated as HTR and prevent these destination codes from being automatically placed on the ``HTR Control'' list. A network manager should also have the ability to restore destination codes to the fully automatic HTR determination function.
4) Administrative review of HTR list
Network managers should have the capability to view the contents of the ``HTR Control'' list, either via a terminal at the exchange or remotely through a Network Management OS. The list should indicate which destination codes have been manually designated as HTR (see c) below). In addition, network managers should have access to a list of those destination codes which have been manually excluded from automatic HTR determination.
b) HTR determination
The capability should exist to determine automatically which destination codes are HTR. This is based on three capabilities.
1) Code measurements
The HTR/ETR status of a destination is based on analyzing the data for groupings of routing digits. An exchange should take measurements based on a sufficient number of routing digits to identify a destination. The exchange should take those measurements necessary to calculate the ABR for each such destination.
2) HTR calculations
Periodically, the ABR for these destination codes under surveillance should be calculated. A recommended time interval is every 5 minutes.
3) Determining destination code HTR/ETR status
|
For each destination code, the capacity should be provided to compare the number of bids and the calculated ABR pre-established thresholds. There should be a set of thresholds applicable to determining HTR destination areas and another set for being monitored in greater detail. A set of pre-established threshold consists of: |
to a set of destinations |
-- B: Bids; the number of calls received by an exchange for a given destination code. This count includes calls that are successfully forwarded to the succeeding exchange as well as calls that fail within the current exchange.
-- T: ETR threshold; the threshold above which a destination code's ABR should be considered ETR.
A destination code would be considered HTR if, based on the 5-minute calculations, the measured number of bids to the code is greater than or equal to threshold ''B'' and the ABR is less than or equal to threshold ``T''.
A destination code that is determined to be HTR should be placed on a ``HTR Control'' list in the exchange.
To avoid having destination codes oscillate on and off the ``HTR Control'' list, hysteresis modifiers should be applied to determine when destination codes should be removed from the ``HTR Control'' list. In succeeding 5-minute periods, these hysteresis modifiers should be applied to both values ``B'' and ``T'' when it is time to recalculate the HTR/ETR status of the destination code.
At the beginning of each 5-minute period, the ``HTR Control'' list should be reviewed. If a destination code that was calculated to be HTR is determined to be no longer than HTR, then it should be removed from the ``HTR Control'' list.
c) Manually controlling calls as if HTR
A network manager should have the capability of specifying any destination code as HTR so as to cause automatic network management control actions to take place within the exchange as indicated in § 5.5.4.2 below. The manually specified destination code(s) may
40 3 andŽ
go on the ``HTR Control'' list. They should not, however, be subject to the 5-minute review and removal procedure described above. They should be removed upon request of a network manager. To this end, a network manager should have the capability of ending this stimulus to identifying a destination code as HTR.
Whenever a network manager adjusts the HTR status of a destination code, that manual action should take precedence over any automatic actions for that destination code.
5.5.4.2 Controlling calls based on HTR status
When a call to a destination code that is on the ``HTR Control'' list is being routed and a manual or automatic network management control is encountered during the processing of the call, the control should take into account the fact that the destination code is HTR. If a destination code is on the ``HTR Control'' list, then the call should be considered HTR for all outgoing circuit groups.
As an example of an automatic network management control incorporating HTR, the Automatic Congestion Control (ACC) Response Percentage Table (Table 4/Q.542) could be expanded to apply more stringent controls to HTR traffic, as shown in Table 7/Q.542. A similar application of the Selective Circuit Reservation Control is possible (see § 5.5.3).
H.T. [T7.542]
TABLE 7/Q.542
Example of automatic congestion control response
percentages with HTR
center box; cw(48p) | cw(39p) | cw(27p) sw(33p) sw(27p) sw(27p) sw(27p) , ^ | ^ | c | c | c | c | c. Congestion level Traffic type Response category A B C D E _ cw(48p) | lw(39p) | cw(27p) | cw(33p) | cw(27p) | cw(27p) | cw(27p) , ^ | l | l | l | l | l | l ^ | l | l | l | l | l | l ^ | l | l | l | l | l | l. CL1 { ART-HTR DR-HTR ART-ETR DR-ETR
} 0 0 0 0 0 0 0 0 100 0 0 0 100 100 0 0 100 100 0 0
_ cw(48p) | lw(39p) | cw(27p) | cw(33p) | cw(27p) | cw(27p) | cw(27p) , ^ | l | l | l | l | l | l ^ | l | l | l | l | l | l ^ | l | l | l | l | l | l. CL2 { ART-HTR DR-HTR ART-ETR DR-ETR
} 100 0 0 0 100 100 0 0 100 100 0 0 100 100 100 0 100 100 100 75
_
|
5.5.5 |
Temporary Trunk Blocking |
Table 7/Q.542 [T7.542], p. |
Temporary Trunk Blocking (TTB) is an alternative method of exchange congestion control for application in national networks.
When an exchange is in a low level overload condition, a Temporary Trunk Blocking signal may be sent to a preceding exchange to indicate that the release or re-occupation of a trunk should be delayed for a short (e.g., 100 s) period of time. This may permit an overall level of up to the maximum possible load in the overloaded exchange without need to generate ACC signals. The preferred method of conveying the TTB signal is via the relevant common channel signalling system.
The exchange receiving the Temporary Trunk Blocking signal will delay the release or the re-occupation of the concerned trunk for a short time. This time should be made changeable by operating personnel command.
The duration of trunk blocking is limited by a timer in the exchange receiving the Temporary Trunk Blocking signal. Therefore, an unlimited blocking of the trunk is avoided.
3 and 41
5.5.6 Application
5.5.6.1 ACC
Generally, where an Administration has introduced or is planning to introduce network management controls, it is considered appropriate for digital transit and large digital combined local/transit exchanges to be provided with full ACC capabilities. Digital local and smaller combined local/transit exchanges should only be provided with ACC receive and control capabilities.
5.5.6.2 SCR
It is considered appropriate for digital transit and large digital combined local/transit exchanges to be provided with a two-threshold Selective Circuit Reservation Network Management Control. Network Management of digital local and smaller combined local/transit exchanges could benefit from having available, ideally, the two threshold or the single threshold Selective Circuit Reservation Network Management Control. The decision whether or not to provide this control in these exchanges is left to the discretion of the various Administrations.
5.5.6.3 HTR
It is considered appropriate for digital transit and large digital combined local/transit exchanges (optionally in conjunction with a Network Management OS) to be provided with full HTR capabilities. Digital local and smaller combined local/transit exchanges should only be provided with the manual HTR and HTR controlling (based on HTR status) capabilities, i.e., those capabilities found in §§ 5.5.4.1 subsection c, and 5.4.4.2 of this Recommendation. It is also recommended that control modifications, based on HTR status, be added to both the ACC and Selective Circuit Reservation capabilities.
5.5.6.4 TTB
It is considered appropriate for TTB to be provided in digital transit and large digital combined local/transit exchanges in national applications. It may be particularly useful in exchanges that may not be provided with ACC capabilities, such as local exchanges.
5.6 Order of application of controls
The order in which various network management controls shall be applied in an exchange is for further study.
DIGITAL EXCHANGE PERFORMANCE DESIGN OBJECTIVES
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 Services Digital Network (ISDN).
The field of application of this Recommendation is more fully defined in Recommendation Q.500. As to the application in an ISDN, transit connections and exchange connections types I, II, III and IV as defined in Recommendation Q.522 are covered (Notes 1 and 2). Other types of connection and variants of these connections may be feasible in ISDN and will be the subject of further study.
42 Fascicle VI.5 -- Rec. Q.543
These performance design objectives are applicable to all exchange implementations at all points in the growth cycle up to the maximum size. These reference loads and performance objectives may be used by manufacturers in designing digital switching systems and by Administrations in evaluating a specific exchange design or for comparing different exchange designs for potential use in the Administration's intended implementation.
These recommended performance design objectives relate to the technical capabilities of exchange design. They are intended to assure that exchanges operating in their intended implementation will be capable of supporting the network grades of service recommended in the E.500-series of Recommendations and will offer a level of performance consistent with the overall network performance objectives given in the I-series of Recommendations. The recommended parameters are design objectives which should not be construed to be grade of service or operating requirements. In actual operation, exchanges will be engineered to provide adequate grades of service as economically as possible and the performance requirements (delays, blocking, etc.) of the exchange in operation will differ from the recommended values for these performance design objectives .
2.1 Reference loads
The given reference loads are traffic load conditions under which the performance design objectives stated in §§ 2.2 to 2.7 are to be met. In order to have a comprehensive characterization of exchange reference loads, supplementary services and other types of services must be taken into account. Administrations may specify hypothetical models for use in computing exchange loading. These models should characterize the sets of traffic parameters and services that are considered to be typical in the intended application of the exchange, and should include the traffic mix (originating-internal, originating-outgoing, incoming-terminating, transit, abandoned, busy non-answer, etc.), the mix of service classes (residential, business, PABX, coin, etc.), the types and volume of supplementary services (call waiting, call forwarding, etc.) and any other pertinent characteristics. Using the above information, it should be possible to ``engineer'' the exchange to produce the model. It should also be possible to determine the maximum size of the exchange by the computations discussed in § 2.1.4.
Reference load A is intended to represent the normal upper mean level of activity which Administrations would wish to provide for on customer lines and inter-exchange activities. Reference load B is intended to represent an increased level beyond normal planned activity levels. (Recommendations E.500 and E.520 recommended that the normal provisioning of international circuits in automatic and semi-automatic operation be based on a particular loss probability during the mean busy hour and the average traffic estimated for the ``five busiest days'' as set down in Recommendation E.500.)
Note 1 -- For the time being, the following definitions and corresponding values are only applicable to 64 kbit/s circuit switched connections, i.e., including transit connections and connection types I, II and III option a). Other rates and transfer modes require further study.
|
Note 2 -- The applicability of this document to connections originating or terminating on PABXs is for further study. |
|||
|
2.1.1 |
Reference load on incoming interexchange circuits a) Reference load A -- 0.7 erlangs average occupancy on all incoming circuits Call attempts/h = @ { .7 × number~of~incoming~circuits } over { verage~holding~time~in~hours } @ |
||
|
Note -- Ineffective call attempts must be included in reference call attempts. b) Reference load B -- 0.8 erlangs average occupancy on all incoming circuits with 1.2 times the call attempts/h for reference load A. Fascicle VI.5 -- Rec. Q.543 |
43 |
2.1.2 Reference load on subscriber lines (originating traffic)
Characteristics of traffic offered to local exchanges vary widely depending upon factors such as the proportions of residence and business lines that are served. The following Table 1/Q.543 provides reference load characteristics for lines typical of four possible local exchange applications. Also provided are representative ISDN cases which are discussed below. Administrations may elect to use other models and/or loads that are more suitable for their intended application.
In the following text, ISDN lines will be referred to as digital lines and non-ISDN lines as analogue lines.
|
2.1.2.1 |
Reference load A |
||||
|
H.T. [T1.543] TABLE 1/Q.543 Subscriber line traffic model a) Non-ISDN subscriber lines with or without supplementary services |
center box; cw(48p) | cw(48p) | cw(48p) . Exchange type Average traffic intensity Average BHCA _ cw(48p) | cw(48p) | cw(48p) . W 0.03 | 1.2 cw(48p) | cw(48p) | cw(48p) . X 0.06 | 2.4 cw(48p) | cw(48p) | cw(48p) . Y 0.10 | 4.8 cw(48p) | cw(48p) | cw(48p) . Z 0.17 | 6.8 _
|
b) |
ISDN digital subscriber access 2B + D |
Table 1/Q.543 a) [T1.543], p. |
The following ISDN models and traffic parameters are provisional and may be revised in subsequent study periods.
H.T. [T2.543]
center box;
cw(36p) | cw(48p) | cw(48p) | cw(84p) . Line type { Average traffic intensity per B channel
} Average BHCA per B channel { Average packets per second per D channel
} _ cw(36p) | cw(48p) | cw(48p) | cw(84p) . Y` 0.05 | 2 { 0.05 (signalling) + Data packets | ua)
} _ cw(36p) | cw(48p) | cw(48p) | cw(84p) . Y`` 0.10 | 4 { 0.1 (signalling) + Data packets | ua)
} _ cw(36p) | cw(48p) | cw(48p) | cw(84p) . Y``` 0.55 | 2 0.05 (signalling) + Data packets | ua) BHCA Busy hour call attempts.
|
a) |
||
|
Data packet rates are for further study. These include teleaction and packet services data. |
||
|
Table 1/Q.543 b) [T2.543], p. |
||
|
44 Fascicle VI.5 -- Rec. Q.543 |
Even though only limited ISDN traffic data is available, the specification of the corresponding reference loads remains an important factor in exchange evaluation. For the case of digital subscriber lines in Table 1/Q.543 | ), access is assumed to utilize the Basic Access with 2B + D channels. The B channels are available for circuit-switched calls, while the D channel is used to carry signalling information or may be used to carry teleaction data and packet switched data. It is assumed that digital lines typically carry traffic comparable with the heavy-traffic analogue lines designated as case Y in Table 1/Q.543 | ). Three cases representing likely ISDN applications are included in the table.
|
Case Y` Case Y`` Case Y``` 1 erlang). |
traffic per pair of B channels comparable to 1 Case Y line. traffic per pair of B channels comparable to 2 Case Y lines. traffic per pair of B channels comparable 1 Case Y line plus some very high traffic (e.g., circuit switched data traffic at |
Each of these digital lines also carries the associated ISDN signalling and data services on the D channel. For the circuit switched calling rates specified in Table 1/Q.543 | ), ISDN signalling is expected to contribute less than 0.05 packet per second per digital subscriber line. The packet rates for D channel ISDN data services can be much larger than this; however, these are left for further study.
2.1.2.2 Reference load B
|
Reference load B is defined as a traffic increase over reference load A of: +25% in erlangs, with +35% in BHCA. Reference load B levels for D channel activity are for further study. |
||
|
2.1.3 |
Impact of supplementary services If the reference model exchange assumes that significant use is made of supplementary services, the performance of the exchange can |
be strongly affected, especially in exchange designs where processor capacity can become a limiting item. The performance delays recommended in §§ 2.3 and 2.4 can be significantly lengthened at a given call load under such circumstances. The Administration or Operating Agency defining the reference model should estimate the fractions of calls which use various supplementary services so that an average processor impact relative to a basic telephone call can be calculated (e.g., possibly by a methodology similar to that of Annex A to this Recommendation).
2.1.4 Exchange capacity
In order to evaluate and compare exchange designs, an Administration will usually want to know the maximum possible size of the exchange for the intended implementation. While several factors may limit exchange capacity, processing capacity will frequently be the limiting factor. The maximum possible number of lines and circuits served by an exchange, while meeting performance objectives , will depend on the mix, volumes and types of traffic and the services expected in the particular implementation.
Two methods of determining exchange processing capacity are provided in the annexes to this Recommendation:
-- Annex A provides an example of methodology for computing processing capacity of an exchange using information provided by the manufacturer and estimates of traffic mix and load provided by the Administration.
-- Annex B provides an example of methodology for estimating the capacity of an exchange by making projections from measurements made on a functioning exchange in the laboratory or in the field. The test exchange must be representative of mix and load of traffic and services expected at maximum size.
2.1.5 Reference loads on other accesses and interfaces
At this time, other applications, such as n × 64 kbit/s on the Primary Rate Interface, are left for further study.
Fascicle VI.5 -- Rec. Q.543 45
2.2 inadequately handled call attempts
2.2.1 Definition
Inadequately handled call attempts are attempts which are blocked (as defined in the E.600-series of Recommendations) or are excessively delayed within the exchange. ``Excessive delays'' are those that are greater than three times the ``0.95 probability of not exceeding'' values recommended in the tables in §§ 2.3 and 2.4. (See Note.)
For originating and transit calls, this inadequately handled call attempt parameter applies only when there is at least one appropriate outlet available.
|
Note -- Provisionally, call request delay is not included in this parameter. Further study is required. |
|||
|
2.2.2 |
Probability of inadequately handled call attempts occurring The values in Table 2/Q.543 are recommended. H.T. [T3.543] TABLE 2/Q.543 |
center box; cw(54p) | cw(54p) | cw(54p) . Type of connection Reference load A Reference load B _ lw(54p) | cw(54p) | cw(54p) . Internal 10DlF2612 4 × 10DlF2612 _ lw(54p) | cw(54p) | cw(54p) . Originating 5 × 10DlF2613 3 × 10DlF2612 _ lw(54p) | cw(54p) | cw(54p) . Terminating 5 × 10DlF2613 3 × 10DlF2612 _ lw(54p) | cw(54p) | cw(54p) . Transit 10DlF2613 10DlF2612 _
|
2.3 |
Delay probability -- non-ISDN or mixed (ISDN -- non-ISDN) environment |
Table 2/Q.543 [T3.543], p. |
The non-ISDN environment is composed of analogue subscriber lines and/or circuits that use either channel associated or common channel signalling.
The ISDN environment is composed of digital (ISDN) subscriber lines and/or circuits that use common channel signalling.
This section defines delay parameters related to non-ISDN environment and mixed (ISDN -- non-ISDN) environment.
When a delay parameter in this section is also applicable to the pure ISDN environment, a reference to the appropriate part of § 2.4 (delay probability -- ISDN environment) is provided.
In the following delay parameters, it is understood that delay timing begins when the signal is ``recognizable'', that is, after the completion of signal verification, where applicable. It does not include line-dependent delays for the recognition of induced voltage conditions or line transients.
The term ``mean value'' is understood to be the expected value in the probabilistic sense.
Where several messages are received at the exchange from a digital subscriber line signalling system (e.g., several alert messages are received from a multi-user configuration), the message that is accepted for call handling is the one considered in determining the start of a given delay interval.
46 Fascicle VI.5 -- Rec. Q.543
Where common channel signalling (including inter-exchange and subscriber line signalling) is involved, the terms ``received from'' and ``passed to'' the signalling system are used. For CCITT Signalling System No. 7, this is designated as the instant the information is exchanged between the signalling data link (layer 1) and the signalling link functions (layer 2). For digital subscriber line signalling, this is designated as the instant the information is exchanged by means of primitives between the data link layer (layer 2) and the network layer (layer 3). Thus, the time intervals exclude the above layer 1 (CCITT Signalling System No. 7), and layer 2 (D channel) times. They do, however, include queuing delays that occur in the absence of disturbances but not any queuing delays that occur in the absence of disturbances but not any queuing delays caused by re-transmission.
2.3.1 incoming response delay -- transit and terminating incoming traffic connections
Incoming response delay is a characteristic that is applicable where channel associated signalling is used. It is defined as the interval from the instant an incoming circuit seizure signal is recognizable until a proceed-to-send signal is sent backwards by the exchange.
|
The values in Table 3/Q.543 are recommended. H.T. [T4.543] TABLE 3/Q.543 center box; lw(90p) | cw(60p) | cw(60p) . Reference load A Reference |
load B _ lw(90p) | cw(60p) | rw(60p) . Mean value | 00 |
|
ms | 00 ms _ lw(90p) | cw(60p) | rw(60p) . |
{ 0.95 probability of not exceeding
|
} | 00 ms |
600 ms _ |
Table 3/Q.543 [T4.543], p. |
2.3.2 local exchange call request delay -- originating outgoing and internal traffic connections
2.3.2.1 For ANALOGUE SUBSCRIBER LINES, call request delay is defined as the interval from the instant when the off-hook condition is recognizable at the subscriber line interface of the exchange until the exchange begins to apply dial tone to the line. The call request delay interval is assumed to correspond to the period at the beginning of a call attempt during which the exchange is unable to receive any call address information from the subscriber.
|
The values in Table 4/Q.543 are recommended. H.T. [T5.543] TABLE 4/Q.543 center box; lw(90p) | cw(60p) | cw(60p) . Reference load A Reference |
load B _ lw(90p) | cw(60p) | rw(60p) . Mean value | 00 |
|
ms | 00 ms _ lw(90p) | cw(60p) | rw(60p) . |
{ 0.95 probability of not exceeding
} | 00 ms 1000 ms
Note -- The above values are understood to apply when a continuous tone, i.e., without a cadence, is used and do not include delays caused by functions such as line tests, which may be used in national networks.
Table 4/Q.543 [T5.543], p.
Fascicle VI.5 -- Rec. Q.543 47
2.3.2.2 For DIGITAL SUBSCRIBER LINES using overlap sending, call request delay is defined as the interval from the instant at which the SETUP message has been received from the subscriber signalling system until the SETUP ACKNOWLEDGE message is pased back to the subscriber signalling system.
|
Note -- In this case this parameter is equivalent to the user signalling acknowledgement delay (see § 2.4.1). The values in Table 5/Q.543 are recommended. H.T. [T6.543] TABLE 5/Q.543 center box; lw(90p) | cw(60p) | cw(60p) . Reference load A Reference load B _ lw(90p) | cw(60p) | |
rw(60p) . Mean value | 00 |
|
ms | 00 ms _ lw(90p) | cw(60p) | rw(60p) . |
{ 0.95 probability of not exceeding
|
} | 00 ms |
1000 ms _ |
Table 5/Q.543 [T6.543], p. |
2.3.2.3 For DIGITAL SUBSCRIBER LINES using en-bloc sending, call request delay is defined as the interval from the instant at which the SETUP message is received from the subscriber signalling system until the call proceeding message is passed back to the subscriber signalling system.
|
The values in Table 6/Q.543 are recommended. H.T. [T7.543] TABLE 6/Q.543 center box; lw(90p) | cw(60p) | cw(60p) . Reference load A Reference |
load B _ lw(90p) | cw(60p) | rw(60p) . Mean value | 00 |
|
ms | 00 ms _ lw(90p) | cw(60p) | rw(60p) . |
{ 0.95 probability of not exceeding
|
} | 00 ms |
1200 ms _ |
Table 6/Q.543 [T7.543], p. |
2.3.3 exchange call set-up delay -- transit and originating outgoing traffic connections
Exchange call set-up delay is defined as the interval from the instant that the information is required for outgoing circuit selection is available for processing in the exchange, or the signalling information required for call set-up is received from the signalling system, until the instant when the seizing signal has been sent to the subsequent exchange or the corresponding signalling information is passed to the signalling system.
48 Fascicle VI.5 -- Rec. Q.543
2.3.3.1 Exchange call set-up delay for transit connections
2.3.3.1.1 For transit traffic connections that involve circuits that use channel associated signalling or a mix of channel associated and common channel signalling, the values in Table 7/Q.543 are recommended.
H.T. [T8.543]
TABLE 7/Q.543
|
center box; lw(90p) | cw(60p) | cw(60p) . ms | 00 ms _ lw(90p) | cw(60p) | cw(60p) . { 0.95 probability of not exceeding } | 00 ms | 00 ms _ |
Reference load A |
Reference load B _ lw(90p) | cw(60p) | cw(60p) . |
Mean value |
| 50 |
Table 7/Q.543 [T8.543], p. 2.3.3.1.2 For transit traffic connections between circuits that use CCITT Signalling System No. 7 signalling exclusively, the requirements of the appropriate signalling system Recommendation should apply, e.g. CCITT Recommendations Q.725 and Q.766 for Tc\duvalue (case of a processing intensive message).
2.3.3.2 Exchange call set-up delay for originating outgoing traffic connections
2.3.3.2.1 For outgoing traffic connections originating from ANALOGUE SUBSCRIBER LINES, the values in Table 8/Q.543 are recommended.
H.T. [T9.543]
TABLE 8/Q.543
|
center box; lw(90p) | cw(60p) | cw(60p) . ms | 00 ms _ lw(90p) | cw(60p) | cw(60p) . { 0.95 probability of not exceeding } | 00 ms | 00 ms _ |
Reference load A |
Reference load B _ lw(90p) | cw(60p) | cw(60p) . Mean value |
| 00 |
Table 8/Q.543 [T9.543], p.
Fascicle VI.5 -- Rec. Q.543 49
2.3.3.2.2 For outgoing traffic connections originating from DIGITAL SUBSCRIBER LINES using overlap sending, the time interval starts when the INFORMATION message received contains a ``sending complete indication'' or when the address information necessary for call set-up is complete.
|
The values in Table 9/Q.543 are recommended. H.T. [T10.543] TABLE 9/Q.543 center box; lw(90p) | cw(60p) | cw(60p) . Reference load A Reference |
load B _ lw(90p) | cw(60p) | rw(60p) . Mean value | 00 |
|
ms | 00 ms _ lw(90p) | cw(60p) | rw(60p) . |
{ 0.95 probability of not exceeding
|
} | 00 ms |
1000 ms _ |
Table 9/Q.543 [T10.543], p. |
2.3.3.2.3 For outgoing traffic connections originating from DIGITAL SUBSCRIBER LINES using en-bloc sending, the time interval starts when the SETUP message has been received from the digital subscriber signalling system.
|
The values in Table 10/Q.543 are recommended. H.T. [T11.543] TABLE 10/Q.543 center box; lw(90p) | cw(60p) | cw(60p) . Reference load A Reference |
load B _ lw(90p) | cw(60p) | rw(60p) . Mean value | |
|
00 ms | 00 ms _ lw(90p) | cw(60p) | rw(60p) . |
{ 0.95 probability of not exceeding
|
} | 00 ms |
1200 ms _ |
Table 10/Q.543 [T11.543], p. |
2.3.4 through-connection delay
Through-connection delay is defined as the interval from the instant at which the information required for setting up a through-connection is available for processing in an exchange, or the signalling information required for setting up a through-connection is received from the signalling system, to the instant at which the appropriate transmission path is available for carrying traffic between the incoming and outgoing exchange terminations.
The exchange through-connection delay does not include an inter-office continuity check, if provided, but does include a cross-office check if one occurs during the defined interval.
When the through-connection is established during call set-up, the recommended values for exchange call set-up delay apply . When the through-connection in an exchange is not established during the exchange call set-up interval, the through-connection delay may then contribute to the network call set-up delay.
50 Fascicle VI.5 -- Rec. Q.543
2.3.4.1 For transit and originating outgoing traffic connections
The values in Table 11/Q.543 are recommended.
H.T. [T12.543]
TABLE 11/Q.543
center box; lw(90p) | cw(72p) | cw(66p) . Reference load A Reference load B _ lw(90p) | cw(39p) | cw(33p) | cw(33p) | cw(33p) .
Without ancillary equipment With ancillary equipment Without ancillary equipment With ancillary equipment _ lw(90p) | cw(39p) | cw(33p) | cw(33p) | cw(33p) . Mean value | 50 ms | 50 ms | 00 ms | 00 ms _ lw(90p) | cw(39p) | cw(33p) | cw(33p) | cw(33p) .
{ 0.95% probability of not exceeding
|
} | 00 ms | 00 ms | 00 ms |
| 00 ms _ |
Table 11/Q.543 [T12.543], p. |
The requirements for multi-slot connections require further study.
2.3.4.2 For internal and terminating traffic connections
For connections terminating on ANALOGUE SUBSCRIBER LINES, the through-connection delay is the interval from the instant at which the called subscriber off-hook condition (answer) is recognizable at the subscriber line interface of the exchange until the through-connection is established and available for the carrying traffic or a consequent signal is sent backwards by the exchange.
The maximum values applying to this parameter are included with those for incoming call indication sending delay in § 2.3.5.
For connections terminating on DIGITAL SUBSCRIBER LINES, the through-connection delay is the interval from the instant at which the CONNECT message is received from the signalling system until the through-connection is established and available for carrying traffic as those indicated by passing to the respective signalling systems of the ANSWER and CONNECT ACKNOWLEDGE messages.
|
The values in Table 12/Q.543 are recommended. H.T. [T13.543] TABLE 12/Q.543 center box; lw(90p) | cw(60p) | cw(60p) . Reference load A Reference |
load B _ lw(90p) | cw(60p) | cw(60p) . Mean value | 50 |
|
ms | 00 ms _ lw(90p) | cw(60p) | cw(60p) . |
{ 0.95 probability of not exceeding
|
} | 00 ms |
| 00 ms _ |
||
|
Table Fascicle VI.5 -- Rec. |
Table 12/Q.543 [T13.543], p. Q.543 51 |
2.3.5 incoming call indication sending delay -- (for terminating and internal traffic connections)
2.3.5.1 For calls terminating on ANALOGUE SUBSCRIBER LINES, the incoming call indication sending delay is defined as the interval from the instant when the last digit of the called number is available for processing in the exchange until the instant that ringing signal is applied by the exchange to the called subscriber line.
It is recommended that the sum of the values for ringing signal sending delay and through-connection delay for internal and teminating traffic connection should not exceed the values in Table 13/Q.543. In addition, it is recommended that the value of the incoming call indication sending delay should not exceed 90% of these values nor the though-connection delay exceed 35% of these values.
H.T. [T14.543]
TABLE 13/Q.543
|
center box; lw(90p) | cw(60p) | cw(60p) . ms | 000 ms _ lw(90p) | cw(60p) | cw(60p) . { 0.95 probability of not exceeding } | 00 ms | 600 ms |
Reference load A |
Reference load B _ lw(90p) | cw(60p) | cw(60p) . |
Mean value |
| 50 |
Note -- The above values assume that ``immediate'' ringing is applied and do not include delays caused by functions such as line tests, which may be used in national networks.
Table 13/Q.543 [T14.543], p.
2.3.5.2 For calls terminating on DIGITAL SUBSCRIBER LINES, the incoming call indication sending delay is defined as the interval from the instant at which the necessary signalling information is received from the signalling system to the instant at which the SETUP message is passed to the signalling system of the called digital subscriber line.
|
In the case of overlap sending in the incoming signalling system, the values in Table 14/Q.543 are recommended. H.T. [T15.543] TABLE 14/Q.543 center box; lw(90p) | cw(60p) | cw(60p) . Reference load A Reference load B _ lw(90p) | cw(60p) | rw(60p) |
. Mean value | |
|
00 ms | 00 ms _ lw(90p) | cw(60p) | rw(60p) . |
{ 0.95 probability of not exceeding
|
} | 00 ms 1000 |
1000 ms _ |
||
|
Table 14/Q.543 [T15.543], p. |
|||
|
52 Fascicle VI.5 |
-- Rec. Q.543 |
|
In the case of en-bloc sending in the incoming signalling system, the values in Table 15/Q.543 are recommended. H.T. [T16.543] TABLE 15/Q.543 center box; lw(90p) | cw(60p) | cw(60p) . Reference load A Reference load B _ lw(90p) | cw(60p) | rw(60p) |
. Mean value | 00 |
|
ms | 00 ms _ lw(90p) | cw(60p) | rw(60p) . |
{ 0.95 probability of not exceeding
|
} | 00 ms |
1200 ms _ |
Table 15/Q.543 [T16.543], p. |
2.3.6 Alerting sending delay -- terminating and internal traffic connections
2.3.6.1 alerting sending delay for terminating traffic
2.3.6.1.1 For calls terminating on ANALOGUE SUBSCRIBER LINES, alerting sending delay is defined as the interval from the instant when the last digit is available for processing in the exchange until the ringing tone is sent backwards toward the calling user.
The values in Table 13/Q.543 are recommended.
2.3.6.1.2 For calls termining on DIGITAL SUBSCRIBER LINES, the alerting sending delay is defined as the interval from the instant that an ALERTING message is received from the digital subscriber line signalling system to the instant at which an ADDRESS COMPLETE message is passed to the interexchange signalling system or ringing tone is sent backward toward the calling user.
|
The values in Table 16/Q.543 are recommended. H.T. [T17.543] TABLE 16/Q.543 center box; lw(90p) | cw(60p) | cw(60p) . Reference load A Reference |
load B _ lw(90p) | cw(60p) | cw(60p) . Mean value | 00 |
|
ms | 50 ms _ lw(90p) | cw(60p) | cw(60p) . |
{ 0.95 probability of not exceeding
|
} | 00 ms |
| 00 ms _ |
Table 16/Q.543 [T17.543], p. |
2.3.6.2 alerting sending delay for internal traffic
2.3.6.2.1 For calls terminating on ANALOGUE SUBSCRIBER LINES, alerting sending delay is defined as the interval from the instant that the signalling information is available for processing in the exchange until ringing tone is applied to an ANALOGUE calling subscriber line or an ALERTING message is sent to a DIGITAL calling subscriber line signalling system.
For calls from ANALOGUE SUBSCRIBER LINES to ANALOGUE SUBSCRIBER LINES, the values in Table 13/Q.543 are recommended.
Fascicle VI.5 -- Rec. Q.543 53
For calls from DIGITAL SUBSCRIBER LINES to ANALOGUE SUBSCRIBER LINES, the values in Table 17/Q.543 are recommended.
H.T. [T18.543]
TABLE 17/Q.543
|
center box; lw(90p) | cw(60p) | cw(60p) . ms | 00 ms _ lw(90p) | cw(60p) | cw(60p) . { 0.95 probability of not exceeding } | 00 ms | 00 ms _ |
Reference load A |
Reference load B _ lw(90p) | cw(60p) | cw(60p) . Mean value |
| 00 |
Table 17/Q.543 [T18.543], p. 2.3.6.2.2 For internal calls terminating on DIGITAL SUBSCRIBER LINES originating from ANALOGUE SUBSCRIBER LINES, alerting sending delay is defined as the interval from the instant that an alerting message is received from the signalling system of the called subscriber's line until ringing tone is applied to the calling subscriber line.
|
The values in Table 13/Q.543 are recommended. Alerting sending delay on internal calls between DIGITAL SUBSCRIBER LINES are covered by Table 28/Q.543. |
||
|
2.3.7 |
ringing tripping delay -- internal and terminating traffic connections Ringing tripping delay is a characteristic that is applicable for calls terminating on ANALOGUE SUBSCRIBER LINES only. It is defined as |
the interval from the instant that the called subscriber off-hook condition is reconizable at the subscriber line interface until the ringing signal at the same interface is suppressed.
|
The values in Table 18/Q.543 are recommended. H.T. [T19.543] TABLE 18/Q.543 center box; lw(90p) | cw(60p) | cw(60p) . Reference load A Reference |
load B _ lw(90p) | cw(60p) | cw(60p) . Mean value | 00 |
|
ms | 50 ms _ lw(90p) | cw(60p) | cw(60p) . |
{ 0.95 probability of not exceeding
|
} | 50 ms |
| 00 ms _ |
Table 18/Q.543 [T19.543], p. |
2.3.8 exchange call release delay
Exchange call release delay is the interval from the instant at which the last information required for releasing a connection is available for processing in the exchange to the instant that the switching network through-connection in the exchange is no longer available for carrying traffic and the disconnection signal is sent to the subsequent exchange, if applicable. This interval does not include the time taken to detect the release signal, which might become significant during certain failure conditions, e.g., transmission system failures.
54 Fascicle VI.5 -- Rec. Q.543
2.3.8.1 For transit traffic connections involving circuits using channel associated signalling or a mix of channel associated and common channel signalling, the values in Table 19/Q.543 are recommended.
H.T. [T20.543]
TABLE 19/Q.543
|
center box; lw(90p) | cw(60p) | cw(60p) . ms | 00 ms _ lw(90p) | cw(60p) | cw(60p) . { 0.95 probability of not exceeding } | 00 ms | 00 ms _ |
Reference load A |
Reference load B _ lw(90p) | cw(60p) | cw(60p) . Mean value |
| 50 |
Table 19/Q.543 [T20.543], p.
For transit traffic connections involving circuits using CCITT Signalling System No. 7 signalling exclusively, the values in Table 35/Q.543 are recommended.
|
2.3.8.7 For originating, terminating and internal traffic connections, the values in Table 20/Q.543 are recommended. H.T. [T21.543] TABLE 20/Q.543 center box; lw(90p) | cw(60p) | cw(60p) . Reference load A Reference load B _ lw(90p) | cw(60p) | cw(60p) |
. Mean value | 50 |
|
ms | 00 ms _ lw(90p) | cw(60p) | cw(60p) . |
{ 0.95 probability of not exceeding
|
} | 00 ms |
| 00 ms _ |
Table 20/Q.543 [T21.543], p. |
2.3.9 exchange signalling transfer delay -- other than answer signal
Exchange signalling transfer delay is the time taken by the exchange to transfer a signal, no other exchange action being required. It is defined as the interval from the instant that the incoming signal is recognizable, or the signalling information is received from the signalling system, until the instant when the corresponding outgoing signal has been transmitted, or the appropriate signalling information is passed to the signalling system.
Fascicle VI.5 -- Rec. Q.543 55
2.3.9.1 For transit traffic connections involving circuits using channel associated signalling or a mix of channel associated and common channel signalling, the values in Table 21/Q.543 are recommended.
H.T. [T22.543]
TABLE 21/Q.543
|
center box; lw(90p) | cw(60p) | cw(60p) . ms | 50 ms _ lw(90p) | cw(60p) | cw(60p) . { 0.95 probability of not exceeding } | 50 ms | 00 ms _ |
Reference load A |
Reference load B _ lw(90p) | cw(60p) | cw(60p) . |
Mean value |
| 00 |
Table 21/Q.543 [T22.543], p.
For transit traffic connections between circuits that use CCITT Signalling System No. 7 signalling exclusively, the requirements of the appropriate signalling system Recommendations should apply, e.g., CCITT Recommendations Q.725/Q.726 for Tc\duvalue (case of a simple message).
2.3.9.2 Exchange signalling transfer delay for originating, terminating and internal traffic involving a mix of ANALOGUE and DIGITAL SUBSCRIBER LINES is left for further study. Exchange signal transfer delay between DIGITAL SUBSCRIBER signalling systems or between DIGITAL SUBSCRIBER LINE signalling systems and CCITT Signalling System No. 7 is covered in § 2.4.2.
2.3.10 answer sending delay
Answer sending delay is defined as the interval from the instant that the answer indication is received at the exchange to the instant that the answer indication is passed on by the exchange toward the calling user. The objective of this parameter is to minimize the possible interruption of the transmission path for any significant interval during the initial response by the called user.
2.3.10.1 For transit traffic involving circuits that use channel associated signalling or a mix of channel associated and common channel signalling, the values in Table 22/Q.543 are recommended.
H.T. [T23.543]
TABLE 22/Q.543
|
center box; lw(90p) | cw(60p) | cw(60p) . ms | 50 ms _ lw(90p) | cw(60p) | cw(60p) . { 0.95 probability of not exceeding } | 50 ms | 00 ms _ |
Reference load A |
Reference load B _ lw(90p) | cw(60p) | cw(60p) . |
Mean value |
| 00 |
Table 22/Q.543 [T23.543], p. 56 Fascicle VI.5 -- Rec. Q.543
More stringent values are recommended where in-band line signalling may be encountered in the national part of a built-up connection. The recommended values are given in Table 23/Q.543.
H.T. [T24.543]
TABLE 23/Q.543
|
center box; lw(90p) | cw(60p) | cw(60p) . 0 ms _ lw(90p) | rw(60p) | rw(60p) . { 0.95 probability of not exceeding } 100 ms 180 ms _ |
Reference load A |
Reference load B _ lw(90p) | rw(60p) | rw(60p) . Mean value |
| 0 ms |
| |
Table 23/Q.543 [T24.543], p.
For transit traffic connections involving circuits that use CCITT Signalling System No. 7 exclusively, the requirements of the appropriate signalling system Recommendations should apply, e.g., CCITT Recommendations Q.725 and Q.766 for Tc\duvalue (case of a simple message).
2.3.10.2 For connections in a terminating exchange, exchange answer sending delay is defined as the interval from the instant that the off-hook condition is recognizable at the ANALOGUE SUBSCRIBER LINE interface on an incoming call or a CONNECT message is received from a DIGITAL SUBSCRIBER LINE signalling system until the instant that an answer indication is sent back toward the calling user.
|
The values in Table 24/Q.543 are recommended. H.T. [T25.543] TABLE 24/Q.543 center box; lw(90p) | cw(60p) | cw(60p) . Reference load A Reference |
load B _ lw(90p) | cw(60p) | cw(60p) . Mean value | 50 |
|
ms | 50 ms _ lw(90p) | cw(60p) | cw(60p) . |
{ 0.95 probability of not exceeding
|
} | 00 ms |
| 00 ms _ |
Table 24/Q.543 [T25.543], p. |
2.3.10.3 For connections in an originating exchange, exchange answer sending delay is defined as the interval from the instant that the answer indication is received from the outgoing circuit signalling system or in the case of an internal call, from the called subscriber's line, until the instant that the answer indication is sent to the calling user. In the case of a call originated from a DIGITAL SUBSCRIBER LINE, the answer indication is a CONNECT message that is sent to the DIGITAL SUBSCRIBER LINE signalling system. If an ANALOGUE SUBSCRIBER LINE originated the call, the answer indication may not be sent.
Fascicle VI.5 -- Rec. Q.543 57
|
The values in Table 25/Q.543 are recommended. H.T. [T26.543] TABLE 25/Q.543 center box; lw(90p) | cw(60p) | cw(60p) . Reference load A Reference |
load B _ lw(90p) | cw(60p) | cw(60p) . Mean value | 50 |
|
ms | 00 ms _ lw(90p) | cw(60p) | cw(60p) . |
{ 0.95 probability of not exceeding
} | 00 ms | 00 ms _
Table 25/Q.543 [T26.543], p.
For ISDN operation involving DIGITAL SUBSCRIBER LINES and CCITT Signalling System No. 7 exclusively, the values in Table 28/Q.543 are recommended.
2.3.11 timing for start of charging (circuit switched calls)
When required, timing for charging at the exchange where this function is performed, shall begin after receipt of an ANSWER indication from a connecting exchange or the called user. The start of timing for charging should occur within the intervals recommended in Table 26/Q.543.
H.T. [T27.543]
TABLE 26/Q.543
|
center box; lw(90p) | cw(60p) | cw(60p) . ms | 75 ms _ lw(90p) | cw(60p) | cw(60p) . { 0.95 probability of not exceeding } | 00 ms | 50 ms _ |
Reference load A |
Reference load B _ lw(90p) | cw(60p) | cw(60p) . Mean value |
| 00 |
Tableau 26/Q.543 [T27.543], p.36 MONTAGE: § 2.4 SUR LE RESTE DE CETTE PAGE
58 Fascicle VI.5 -- Rec. Q.543
Fascicle VI.5 -- Rec. Q.543 59