5i' SECTION 3 DESIGN OBJECTIVES AND MEASUREMENTS Recommendation Q.541 DIGITAL EXCHANGE DESIGN OBJECTIVES - GENERAL 1 General This Recommendation applies to digital local, combined, tran- sit 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 applica- tion 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. 2 General design objectives 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 provid- ing 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 SS 4.4, 4.10.2 - Planned outages). 2.2 Service provisioning and records There should be efficient means of establishing service, test- ing, discontinuing service and maintaining accurate records for: - subscriber lines and services, - interexchange circuits. 2.3 Translations and routing information There should be efficient means of establishing, testing and changing call processing information, such as translation and rout- ing 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.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 pro- cedures for all component parts of the exchange. 3 Integrated Digital Network design objectives 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 con- nection 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 tim- ing 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 synchron- ized 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 syn- chronized 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. The operational performance requirements for the rate of octet slips on an international connection or corresponding bearer chan- nel 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 con- tinent, country, part of a country or countries. 3.4 Relative Time Interval Error (TIE) at the exchange out- put 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 follow- ing 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 deliver- ing 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 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 synchroniza- tion methods are used) requires further study. Any internal operation or rearrangement within the synchroni- zation 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 net- work 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 perfor- mance requirements established in CCITT Recommendation G.822. 4 Availability design objectives 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) = ission time __________________ = 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 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 una- vailability. Thus hardware failure, software malfunctions and unin- tentional outages resulting from craftperson activity are to be counted. 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, unavailabil- ity 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 accumu- lated 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 una- vailable , 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 una- vailability) 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 speci- fied 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 col- lected 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 abil- ity 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. 4.8 Availability independence The design objectives for the unavailability of a single ter- mination 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 una- vailability is mean accumulated intrinsic down time (MAIDT) for individual or groups of terminations, for a given mission time, typically one year. 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 estab- lish 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 impact on service practicable. 4.11 Initial exchange availability performance A system rarely meets all long-term design objectives when first placed into service. The objectives contained in this Recom- mendation 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. 5 Hardware reliability design objectives 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 func- tion 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 max = C 0 + i =1 ~ fIn 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 termina- tions may result in different values for Ci. Recommendation Q.542 DIGITAL EXCHANGE DESIGN OBJECTIVES - OPERATIONS AND MAINTENANCE 1 General This Recommendation applies to digital local, combined, tran- sit 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 appli- cation is defined in the text. Where no such qualification is made, the objective applies to all exchange applications. 2 Maintenance design objectives 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 person- nel 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 appropri- ate, from remote maintenance centre(s) or systems over the recom- mended 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 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. - 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 cor- rupted 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 S 2.5.3; - CRC error reporting, if applicable: a) 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, S 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 func- tion. 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 When all fault conditions have been cleared and alarm indica- tion signal is no longer received, the alarm indication signal and remote alarm indication should be removed within the same respec- tive time limits as specified in S 2.5.3.4 after the conditions have cleared. H.T. [T1.542] TABLE 1/Q.542 Fault conditions and alarms detected by exchange termination functions and consequent actions (excluding interface Vv1) 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 received Yes Yes 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 simultane- ously 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 S 2.5.3.4 applies. The use of error performance monitoring in this table is for further study. Table 1/Q.542 [T1.542], p. 2.5.3.4 Alarm processing 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 mainte- nance 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. - 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 remo- val from service of digital transmission system which are fre- quently 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 con- ditions has to be made by the exchange (see I.600-series of Recom- mendations): - 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 For further study. 2.6 Fault and alarm signal detection and actions at inter- face V1 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 inter- face 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 transmis- sion equipment (e.g., group pilot failure) should be accepted by the exchange as needed to take appropriate action. 2.9 Fault and alarm signal detection and actions for chan- nel associated signalling (2048 and 8448 kbit/s) 2.9.1 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 indi- cation (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 - 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 stan- dards 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 S 2.5.3.4. 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 chan- nel associated channel signalling (1544 kbit/s) Requires further study. 2.11 Fault and alarm signal detection and actions for com- mon 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 SS 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 SS 2.7.2 and 2.7.3 of Recommendation Q.543. 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 considera- tion. 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 func- tions. 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 genera- tion of alarms at the far end exchange due to the removal of cir- cuits from service should be avoided, if possible. 2.13.1 ET functions - Interfaces A, B, V4 The verification of the proper operation of exchange termina- tion functions can be performed by the means of statistical obser- vations 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 S 2.7, the follow- ing 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 Checking the different portions of the path individually in a digital exchange network helps to ensure the continuity of the con- nections 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 ter- minating on the exchange as covered in SS 2.16 and 2.17. 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 transmis- sion performance requirements of Q.543 may be considered to be suf- ficient in order to guarantee the cross office path continuity; - semi-permanent connections may require special supervision procedures which need further study; - supervision of n x 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 cir- cuits 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 con- tinuity 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 cir- cuits. Faulty circuits should be removed from service and repair procedures initiated as required. 3 Subscriber line maintenance and testing design objectives 3.1 Analogue subscriber lines For further study. 3.2 Digital subscriber lines For further study. 4 Operations design objectives 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 pro- viding service in accordance with an Administration's performance requirements. 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 discre- tion of Administrations to improve operating efficiencies and ser- vice 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 Operations features 4.2.1 Service provisioning and records There should be efficient means of establishing service, test- ing, 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 rout- ing 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 com- plete 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 potentially related to TMN - Subscriber administration; - tariff and charging administration; - routing administration; - network management; - maintenance of subscriber lines; - maintenance of circuits between exchanges; - exchange maintenance; - signalling network maintenance; - administration of hardware configuration; - administration of software configuration; - external alarms and indications; - O&M staff procedures; - traffic measurements; - quality of service and network performance obser- vation. 4.3.2 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, pro- grammed response, etc.). Refer to Recommendation Q.513 for infor- mation on interfaces to the TMN. This subject is for further study. 5 Network management design objectives 5.1 General Network management is the function of supervising the perfor- mance of a network and taking action to control the flow of traffic, when necessary, to promote the maximum utilization of net- work 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 func- tions 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 capabili- ties in a digital exchange will be based on the following con- siderations: - 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 ser- vices in emergency situations, where other means are not available; - alternative approaches such as providing redun- dancy and special routing methods; - the need for managing network resources effec- tively when overload conditions occur in its own or interworking networks. Other factors to be considered are: - the network management organization, its equip- ment 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 configura- tions; - the potential impact of network management func- tions 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; - the proportion of automatic and manual features to be implemented and the rate of introduction of various network management features; - the reduction of exchange processing capacity due to the additional load imposed by network management (if appropri- ate); - 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 pro- vided 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 informa- tion 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 SS 5.3 and 5.4. 5.3 Information provided by an exchange for network manage- ment purposes 5.3.1 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 con- figuration 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 detect- ing 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 meas- urements and can be used for centralized processing or for network supervision in a network management centre. Such type of informa- tion 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: - 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 speci- fied destinations. Details of network measurements are given in Recommendation Q.544. 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 informa- tion and their transmission mode. H.T. [T3.542] TABLE 3/Q.542 _____________________________________________________________________ { Data transmission mode Source of information } Real-time On demand Scheduled _____________________________________________________________________ Status information X X _____________________________________________________________________ { Performance and availability information } X X _____________________________________________________________________ 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 net- work, 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 Exchange controls for network management 5.4.1 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 applica- tion. Additional information is provided in the CCITT "Handbook on Service Quality, Network Management and Maintenance". 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 param- eters include distinctions based on the origin of traffic, for example, customer-dialed, operator-dialed, transit or other clas- sification 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 destina- tion 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 interna- tional 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. 5.4.4.1 Code blocking control This control bars or restricts routing to a specific destina- tion code. Code blocking can be done on a country code, an area code, an exchange identifying code and, in some cases, on an indi- vidual 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 recom- mended. 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 Automatic controls for network management 5.5.1 General This section provides descriptions of some automatic traffic control methods that can be provided in digital exchanges for net- work management purposes. 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). 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 con- trols is given in S 5.5.6. 5.5.2 Automatic Congestion Control system The Automatic Congestion Control (ACC) system allows a cong- ested exchange to send a congestion indicator in a backward direc- tion to the preceding exchange. The exchange receiving the conges- tion 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 sig- nalling 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 avail- able 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 experienc- ing 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 dif- ferent treatment during periods of congestion. An example would be to control hard-to-reach traffic as indicated in S 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. H.T. [T4.542] TABLE 4/Q.542 An example of 2-congestion level ACC percentage control response table ________________________________________________________ Response category Congestion level Traffic type A B C ________________________________________________________ CL1 ART 0 0 100 DR 0 0 0 ________________________________________________________ CL2 ART 100 100 100 DR 0 75 75 ________________________________________________________ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Tableau 4/Q.542 [T4.542], p. 5.5.3 Selective Circuit Reservation control 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. Exam- ples 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 net- work 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). 5.5.3.2 Single-threshold Selective Circuit Reservation con- trol 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 S 5.5.4, or to give preference to prior- ity calls. H.T. [T5.542] TABLE 5/Q.542 An example of a single threshold selective circuit reservation percentage control response table ______________________________________ { { A B C ______________________________________ ART 25 50 100 RT1 DR 0 0 25 ______________________________________ | | | | | | | | | | | | Table 5/Q.542 [T5.542], p. 5.5.3.3 Multi-threshold Selective Circuit Reservation con- trol 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 reserva- tion 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 distinc- tions 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. H.T. [T6.542] TABLE 6/Q.542 An example of a two threshold selective circuit reservation percentage control response table with HTR capability _________________________________________________________________________________________________________________________ { { A B C D E _________________________________________________________________________________________________________________________ { 50 0 0 0 75 0 25 0 100 0 50 0 100 0 75 0 100 0 100 0 RT1 _________________________________________________________________________________________________________________________ { 100 0 50 0 100 25 50 0 100 50 75 25 100 75 100 50 100 100 100 75 RT2 _________________________________________________________________________________________________________________________ | | | | | | | | | | | | | | | | Table 6/Q.542 [T6.542], p. 5.5.4 Hard-to-reach (HTR) process 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 thres- hold 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 pro- cess, 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 optim- ize 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 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 desti- nation 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 desig- nated 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 capabili- ties. 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 to a set of pre-established thresholds. There should be a set of thresholds applicable to determining HTR destination areas and another set for destinations being monitored in greater detail. A set of pre-established threshold consists of: - 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 S 5.5.4.2 below. The manually specified destination code(s) may 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 des- tination 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 con- trol 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 S 5.5.3). H.T. [T7.542] TABLE 7/Q.542 Example of automatic congestion control response percentages with HTR _____________________________________________________________________________________________________________________ Response category Congestion level Traffic type A B C D E _____________________________________________________________________________________________________________________ { 0 0 0 0 0 0 0 0 100 0 0 0 100 100 0 0 100 100 0 0 CL1 _____________________________________________________________________________________________________________________ { 100 0 0 0 100 100 0 0 100 100 0 0 100 100 100 0 100 100 100 75 CL2 _____________________________________________________________________________________________________________________ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Table 7/Q.542 [T7.542], p. 5.5.5 Temporary Trunk Blocking 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 Tem- porary 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 over- loaded exchange without need to generate ACC signals. The preferred method of conveying the TTB signal is via the relevant common chan- nel 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. 5.5.6 Application 5.5.6.1 ACC Generally, where an Administration has introduced or is plan- ning 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 Con- trol. 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 Cir- cuit 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 capabil- ities. 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 SS 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. Recommendation Q.543 DIGITAL EXCHANGE PERFORMANCE DESIGN OBJECTIVES 1 General This Recommendation applies to digital local, combined, tran- sit 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. 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 recom- mended in the E.500-series of Recommendations and will offer a level of performance consistent with the overall network perfor- mance 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 Performance design objectives 2.1 Reference loads The given reference loads are traffic load conditions under which the performance design objectives stated in SS 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 ser- vices 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 deter- mine the maximum size of the exchange by the computations discussed in S 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 recom- mended 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 con- nection 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 = 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. 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 representa- tive 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 digi- tal 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 ____________________________________________________________ Exchange type Average traffic intensity Average BHCA ____________________________________________________________ W 0.03 | 1.2 X 0.06 | 2.4 Y 0.10 | 4.8 Z 0.17 | 6.8 ____________________________________________________________ | | | | | | | | | | | | | | | | | | | | | | | | | | | | Table 1/Q.543 a) [T1.543], p. b) ISDN digital subscriber access 2B + D The following ISDN models and traffic parameters are provi- sional and may be revised in subsequent study periods. H.T. [T2.543] ____________________________________________________________________________________________________________________________ Line type { Average traffic intensity per B channel } Average BHCA per B channel { Average packets per second per D channel } ____________________________________________________________________________________________________________________________ Y` 0.05 | 2 { 0.05 (signalling) + Data packets | ua) } ____________________________________________________________________________________________________________________________ Y`` 0.10 | 4 { 0.1 (signalling) + Data packets | ua) } ____________________________________________________________________________________________________________________________ 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 teleac- tion and packet services data. Table 1/Q.543 b) [T2.543], p. 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` traffic per pair of B channels comparable to 1 Case Y line. Case Y`` traffic per pair of B channels comparable to 2 Case Y lines. Case Y``` traffic per pair of B channels comparable 1 Case Y line plus some very high traffic (e.g., circuit switched data traffic at 1 erlang). 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 signal- ling 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 refer- ence 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 pro- cessor capacity can become a limiting item. The performance delays recommended in SS 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 Adminis- tration 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 pro- vided 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 x 64 kbit/s on the Primary Rate Interface, are left for further study. 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 SS 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 _______________________________________________________________ Type of connection Reference load A Reference load B _______________________________________________________________ Internal 10DlF2612 4 x 10DlF2612 _______________________________________________________________ Originating 5 x 10DlF2613 3 x 10DlF2612 _______________________________________________________________ Terminating 5 x 10DlF2613 3 x 10DlF2612 _______________________________________________________________ Transit 10DlF2613 10DlF2612 _______________________________________________________________ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Table 2/Q.543 [T3.543], p. 2.3 Delay probability - non-ISDN or mixed (ISDN - non-ISDN) environment 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 S 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 vol- tage 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 mes- sages are received from a multi-user configuration), the message that is accepted for call handling is the one considered in deter- mining the start of a given delay interval. 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 Signal- ling System No. 7, this is designated as the instant the informa- tion 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 inter- vals 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 queu- ing 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 ___________________________________________________________________________ Reference load A Reference load B ___________________________________________________________________________ Mean value | 00 ms | 00 ms ___________________________________________________________________________ { 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 out- going 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 condi- tion 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 sub- scriber. The values in Table 4/Q.543 are recommended. H.T. [T5.543] TABLE 4/Q.543 _________________________________________________________________________ Reference load A Reference load B _________________________________________________________________________ Mean value | 00 ms | 00 ms _________________________________________________________________________ { 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. 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 sig- nalling 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 S 2.4.1). The values in Table 5/Q.543 are recommended. H.T. [T6.543] TABLE 5/Q.543 ___________________________________________________________________________ Reference load A Reference load B ___________________________________________________________________________ Mean value | 00 ms | 00 ms ___________________________________________________________________________ { 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 sub- scriber signalling system. The values in Table 6/Q.543 are recommended. H.T. [T7.543] TABLE 6/Q.543 ___________________________________________________________________________ Reference load A Reference load B ___________________________________________________________________________ Mean value | 00 ms | 00 ms ___________________________________________________________________________ { 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 originat- ing 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 sig- nalling 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 signal- ling information is passed to the signalling system. 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 associ- ated and common channel signalling, the values in Table 7/Q.543 are recommended. H.T. [T8.543] TABLE 7/Q.543 ___________________________________________________________________________ Reference load A Reference load B ___________________________________________________________________________ Mean value | 50 ms | 00 ms ___________________________________________________________________________ { 0.95 probability of not exceeding } | 00 ms | 00 ms ___________________________________________________________________________ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 ANALO- GUE SUBSCRIBER LINES, the values in Table 8/Q.543 are recommended. H.T. [T9.543] TABLE 8/Q.543 ___________________________________________________________________________ Reference load A Reference load B ___________________________________________________________________________ Mean value | 00 ms | 00 ms ___________________________________________________________________________ { 0.95 probability of not exceeding } | 00 ms | 00 ms ___________________________________________________________________________ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Table 8/Q.543 [T9.543], p. 2.3.3.2.2 For outgoing traffic connections originating from DIGI- TAL 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 ___________________________________________________________________________ Reference load A Reference load B ___________________________________________________________________________ Mean value | 00 ms | 00 ms ___________________________________________________________________________ { 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 DIGI- TAL 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 _________________________________________________________________________ Reference load A Reference load B _________________________________________________________________________ Mean value | 00 ms | 00 ms _________________________________________________________________________ { 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 termi- nations. 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. 2.3.4.1 For transit and originating outgoing traffic con- nections The values in Table 11/Q.543 are recommended. H.T. [T12.543] TABLE 11/Q.543 _____________________________________________________________________________________________________________________________________________________ Reference load A Reference load B _____________________________________________________________________________________________________________________________________________________ Without ancillary equipment With ancillary equipment Without ancillary equipment With ancillary equipment _____________________________________________________________________________________________________________________________________________________ Mean value | 50 ms | 50 ms | 00 ms | 00 ms _____________________________________________________________________________________________________________________________________________________ { 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 S 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 ___________________________________________________________________________ Reference load A Reference load B ___________________________________________________________________________ Mean value | 50 ms | 00 ms ___________________________________________________________________________ { 0.95 probability of not exceeding } | 00 ms | 00 ms ___________________________________________________________________________ | | | | Table 12/Q.543 [T13.543], p. 2.3.5 incoming call indication sending delay - (for ter- minating 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 inter- val 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 sig- nal 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 ___________________________________________________________________________ Reference load A Reference load B ___________________________________________________________________________ Mean value | 50 ms | 000 ms ___________________________________________________________________________ { 0.95 probability of not exceeding } | 00 ms | 600 ms ___________________________________________________________________________ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 sys- tem, the values in Table 14/Q.543 are recommended. H.T. [T15.543] TABLE 14/Q.543 ___________________________________________________________________________ Reference load A Reference load B ___________________________________________________________________________ Mean value | 00 ms | 00 ms ___________________________________________________________________________ { 0.95 probability of not exceeding } | 00 ms 1000 ms ___________________________________________________________________________ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Table 14/Q.543 [T15.543], p. In the case of en-bloc sending in the incoming signalling sys- tem, the values in Table 15/Q.543 are recommended. H.T. [T16.543] TABLE 15/Q.543 ___________________________________________________________________________ Reference load A Reference load B ___________________________________________________________________________ Mean value | 00 ms | 00 ms ___________________________________________________________________________ { 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 ___________________________________________________________________________ Reference load A Reference load B ___________________________________________________________________________ Mean value | 00 ms | 50 ms ___________________________________________________________________________ { 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 sub- scriber line or an ALERTING message is sent to a DIGITAL calling subscriber line signalling system. For calls from ANALOGUE SUBSCRIBER LINES to ANALOGUE SUB- SCRIBER LINES, the values in Table 13/Q.543 are recommended. 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 ___________________________________________________________________________ Reference load A Reference load B ___________________________________________________________________________ Mean value | 00 ms | 00 ms ___________________________________________________________________________ { 0.95 probability of not exceeding } | 00 ms | 00 ms ___________________________________________________________________________ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 sub- scriber line. The values in Table 13/Q.543 are recommended. Alerting sending delay on internal calls between DIGITAL SUB- SCRIBER 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 ___________________________________________________________________________ Reference load A Reference load B ___________________________________________________________________________ Mean value | 00 ms | 50 ms ___________________________________________________________________________ { 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. 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 ___________________________________________________________________________ Reference load A Reference load B ___________________________________________________________________________ Mean value | 50 ms | 00 ms ___________________________________________________________________________ { 0.95 probability of not exceeding } | 00 ms | 00 ms ___________________________________________________________________________ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 con- nections, the values in Table 20/Q.543 are recommended. H.T. [T21.543] TABLE 20/Q.543 ___________________________________________________________________________ Reference load A Reference load B ___________________________________________________________________________ Mean value | 50 ms | 00 ms ___________________________________________________________________________ { 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 sys- tem. 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 ___________________________________________________________________________ Reference load A Reference load B ___________________________________________________________________________ Mean value | 00 ms | 50 ms ___________________________________________________________________________ { 0.95 probability of not exceeding } | 50 ms | 00 ms ___________________________________________________________________________ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Table 21/Q.543 [T22.543], p. For transit traffic connections between circuits that use CCITT Signalling System No. 7 signalling exclusively, the require- ments 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 Sig- nalling System No. 7 is covered in S 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 ___________________________________________________________________________ Reference load A Reference load B ___________________________________________________________________________ Mean value | 00 ms | 50 ms ___________________________________________________________________________ { 0.95 probability of not exceeding } | 50 ms | 00 ms ___________________________________________________________________________ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Table 22/Q.543 [T23.543], p. More stringent values are recommended where in-band line sig- nalling may be encountered in the national part of a built-up con- nection. The recommended values are given in Table 23/Q.543. H.T. [T24.543] TABLE 23/Q.543 ___________________________________________________________________________ Reference load A Reference load B ___________________________________________________________________________ Mean value | 0 ms | 0 ms ___________________________________________________________________________ { 0.95 probability of not exceeding } 100 ms 180 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 SUB- SCRIBER 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 ___________________________________________________________________________ Reference load A Reference load B ___________________________________________________________________________ Mean value | 50 ms | 50 ms ___________________________________________________________________________ { 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 indica- tion 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 sys- tem. If an ANALOGUE SUBSCRIBER LINE originated the call, the answer indication may not be sent. The values in Table 25/Q.543 are recommended. H.T. [T26.543] TABLE 25/Q.543 ___________________________________________________________________________ Reference load A Reference load B ___________________________________________________________________________ Mean value | 50 ms | 00 ms ___________________________________________________________________________ { 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 recom- mended in Table 26/Q.543. H.T. [T27.543] TABLE 26/Q.543 ___________________________________________________________________________ Reference load A Reference load B ___________________________________________________________________________ Mean value | 00 ms | 75 ms ___________________________________________________________________________ { 0.95 probability of not exceeding } | 00 ms | 50 ms ___________________________________________________________________________ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Tableau 26/Q.543 [T27.543], p.36 MONTAGE: S 2.4 SUR LE RESTE DE CETTE PAGE